Length: 2 Days
Developing User Requirements Training Workshop
A good user requirements document is one that correctly identifies the customer and relevant stakeholders, correctly understands what the customer needs and wants and can differentiate between these, and is both specific enough and broad enough to prevent scope creep.
Additionally, user requirements that are especially effective also detail the jobs to be done (functional requirements), the problems to be prevented and outcomes to be achieved, usability requirements, the roles and responsibilities, the overall process, the risks, the process controls and managerial approval processes and technical requirements.
In software development, user requirement documents and specifications are documents usually used in software engineering that specifies what the user expects the software to be able to do.
Once the required information is completely gathered it is documented in a URD (user requirement document), which is meant to spell out exactly what the software must do and becomes part of the contractual agreement.
A customer cannot demand features not in the URD, while the developer cannot claim the product is ready if it does not meet an item of the URD.
The URD can be used as a guide for planning cost, timetables, milestones, testing, etc. The explicit nature of the URD allows customers to show it to various stakeholders to make sure all necessary features are described.
It’s important to understand that formulating a user requirement document requires negotiation to determine what is technically and economically feasible.
What is often overlooked is that preparing a user requirement document is one of those skills that lies between a science and an art, requiring both software technical skills and interpersonal skills.
A user requirements specification does not have to be a long and complex document, but it should contain basic elements, such as:
- Key figures and hard numbers
- Operational information and any constraints
- Timeframes and dates
- An overview of what the facility and the system being supplied should do
- Future projections
The specifications of a user requirements document should be produced by the client, though if the expertise or resource is unavailable a third party such as a consultant can be used or a supplier if you have chosen to partner with one.
Developing User Requirements Training Workshop by Tonex
Developing User Requirements Training Workshop provides guidelines and skills to plan and write well-defined and well-formed, testable, verifiable, validateable user requirements. Attendees will learn to enhance their requirements writing skills and system/product development processes starting with elicitation and stakeholders involvement.
User Requirements are the foundation for building any successful product or system.
Determine WHAT the product/project or system must do and drive the user requirements development. User Requirements are used to determine [verify] if the project team built the product/project or the system correctly. User requirements development process identifies the activities needed to produce a set of complete and verifiable user requirements. User requirements will also be validated based on user’s operational needs.
User Requirements development process includes a set of activities that will produce requirements for the project, product, system or the sub-systems.
Everything should be made as simple as possible, but not simpler.
“Requirements” are defined as “something that governs what, how well, and under what conditions a product will achieve a given purpose.”
- Stakeholder involvement is essential for validating the user requirements. Are these the correct user’s requirements?
- Elicitation techniques enables the discovery and understanding of the needed requirements by the users.
- A trade study is used to analyze and compare alternative requirements and their cost impacts on the project.
- Traceability of user’s requirements to needs & requirements are critical. Support documentation, and constraining policies [e.g., safety, security ot reliability requirements].
Developing User Requirements Training Workshop Objectives:
- List attribute of well-defined user requirements
- Identify the motivations behind writing well defined user requirements
- Explain value proposition of well-formed, unambiguous, validated requirements to enhance your development processes and achieving success
- Describe the process to complete a user requirements specification document
- Steps in Writing and Assembling the Requirements Document
- List steps in Stakeholder Involvement and Elicitation
- Methods to identify the needs of the stakeholders who directly interact with the product or the system
- Describe challenges in defining user requirements for complex products and systems
- Understand why User Requirements Specifications are written early in the validation process, typically before the system is created
- List the elements in User Requirements Model Roadmap
- Define Activity Diagram, Actor Map, Actor Table and Business Policies
- List Cross-Cutting Activities related to developing User Requirements
- Define the role of Project Management Practices
- Risk Management, Metrics and Configuration Management
- Define the role of Decision Gates and Decision Support/Trade Studies
- List steps in Technical Reviews
- Define techniques in User Requirements Traceability
- List methods and techniques for User Requirements Validation
Who Should Attend
- Analysts
- Project and program managers
- Subject Matter Experts (SMEs)
- Agile Product Owners
- Project Leaders and Managers
- Software Engineers
- System Engineers
- Systems Analysts
- Software Testers
- Solution Architects
- and anyone else involved in planning and writing and managing user requirements
Topics Include:
- Requirements Development Process
- User Requirements Planning
- Eliciting Requirements Techniques
- Stakeholders Involvement Processes
- Developing Requirements
- Analyzing Requirements
- Writing and Validating the Requirements
- Check Requirements Completeness
- Methods to Verifying Requirements
- Methods to Validating Requirements
- Managing Baselines and Changes to the Requirements
Developing User Requirements Workshop Activities
- Templates, tools and exercises with real projects to assist in gathering user requirements and getting the correct stakeholders involved
- Tools and techniques to review requirements to make sure they are complete and address all of the users needs
- Mechanics to participate in the user requirements walkthrough
- Tools to ensure the correct requirements are being developed [validating the requirements]
- Techniques to gain stakeholder approval and support for the user requirements
- Mechanisms to track the requirements development activities
Course Agenda
User Requirements Development Process
- What are the user requirements?
- The requirements development process
- Elicit, analyze, verify, specify, verify, validate and manage
- Sources for requirements
- Rules for writing business requirements
- User requirement structures
- TONEX user requirement development template
- Steps in developing effective use requirements
- Stakeholder challenges in developing effective use requirements
- Identifying relevant stakeholders
- Identifying and managing requirements
- Differences and Similarities between Functional versus Non-Functional Requirements
- Modeling User’s Concerns as Non-Functional Requirements
- Categorizing and Characterizing Non-Functional Requirements
Techniques to Identify User Requirements
- Eliciting Requirements Techniques
- Concept of Operations
- User needs, expectations, goals, and objectives
- Operation from the user’s perspective
- Major external interfaces, high level functional requirements, and stakeholders
- Feasibility Study
- Conceptual high-level design and requirements
- Project Plan
- Review plans, configuration management plans, and risk plans
- Controlling the requirements development
- Configuration management
- Process to control changes to the requirements and manage the baseline documentation
- Risk management
- How to monitor, control, and mitigate high risk requirements
- Enablers
- Reviews
- How to identify defects, conflicts, missing, or unnecessary requirements
- Requirements review control gate
- Formal reviews
- To approve the final set of requirements
- Stakeholder involvement
- Rules for validating the requirements
- Elicitation
- Discovery and understanding of the needed requirements
Stakeholders Involvement Processes
- Processes Activities
- Develop requirements
- Stakeholder needs and input products
- Techniques to create prioritized, de-conflicted, and validated requirements with the stakeholders
- Write and document requirements
- Characteristics of “good” system requirements
- Necessary, testable, clear, concise, technology-independent, feasible, and stand-alone requirements
- The base to build upon ( baseline)
- Managing changes to the requirements
- Check completeness
- A complete set of requirements
- Functions that are needed to satisfy the stakeholder needs
- Associated performance, environmental, and other non-functional requirements
- Analyze, refine, and decompose requirements
- Tools to examine each requirement to see if it meets the characteristics of a good
- Requirement decomposition
- Refined set of requirements
- Validate requirements
- Each requirement must be validated to ensure that these are the correct requirements
- Stakeholder walkthroughs and tracing requirements to an associated need
- Manage requirements
- Accepted requirements and the baseline
- Changes to the requirements
Developing User Requirements
- Develop requirements
- To gather, analyze and develop requirements from the Concept of Operations (CONOPS), stakeholder needs, objectives and other external requirement
- Write and document requirements
- Functional and performance requirements into the appropriate requirements documents
- Initial Capabilities Document (ICD)
- Capability Development Document (CDD)
- Capability Production Document (CPD)
- Capability Development Tracking and Management
- Requirements development in the project timeline
- Requirements policy or standards
- Cataloging Non-Functional Requirements
- Quantitative Performance Requirements
Measurable Requirements
- Constraints vs. Non-Functional Requirements
- Constraining (Environmental) Elements
- Analyzing Stakeholder needs and requirements
- Bad Requirements
- Missing Requirements
- Inconsistent Requirements
- Issues with identifying Non-Functional Requirements
- Exercise: Non-Functional in Your Environment
- Non-Functional Performance Requirements
- Evaluating Performance Requirements
- Requirements Decomposition
- How do I fit these activities to my project? [Tailoring]
- What should I track in this process step to reduce project risks and get what is expected? [Metrics]
Requirements Analysis Process
- Requirement completeness
- Requirements attributes [quality factors] assignment
- Requirement’s priority, risk, cost, owner, date, verification and validation methods
- Verification methods
- Demonstration, analysis, test, and inspection
- Validation methods
- Demonstration, analysis, test, and inspection
- Stakeholders approval
- The baseline [reference point for future decisions] establishment
- Development, testing, support, deployment, production, training, and disposal
- Functional, Performance, Environmental, and Non – Functional Requirements
Analyzing Requirements Attributes
- Necessary [trace to a user need]
- Concise [minimal]
- Feasible [attainable]
- Testable [measurable]
- Technology Independent [avoid “HOW to” statements unless they are real constraints on the design of the system]
- Unambiguous [Clear]
- Complete [function fully defined]
Guidelines for Writing Requirement Statements
- Principles of well-defined requirements
- Syntax and active voice
- Requirements construct
- Well-formed, bad and irrelevant requirements
- Stakeholder requirements and needs
- What are effective requirement statements?
- Structured requirement statements
- System thinking
- Exercise: Working with requirements
- Techniques and tools to identify Functional Requirements
- Performance Requirements
- Enabling Requirements
- Training, operations, maintenance support, development, testing, production, deployment, and disposal
- How to separate Interface Requirements?
- Environmental Requirements
- Non-functional
- Reliability, availability, safety, and security
Writing and Validating the Requirements
- Check Requirements Completeness
- Characteristics of good requirements
- Good requirements statements
- Traceability to the source
- Traceability to the operational needs
- Attributable to an authoritative source
- Requirements unique identifier
- Test the wording of the requirement from different stakeholders’ perspectives
- Specific and singularity
- Measurability
- Functions assessment as quantitatively or qualitatively
- Performance factors
- Testability
- Vague statements
- Consistency and compatibility
- Feasibility
- Implementation-free
- Critical performance and level of acceptance
- Requirements analysis measures
- Measures of Effectiveness (MOEs)
- Measures of Performance (MOPs)
- Key Performance Parameters (KPPs)
Methods to Verifying and Validating Requirements
- Requirements verification vs. validation
- Methods to Validating Requirements
- Managing Baselines and Changes to the Requirements
- Validation Terminology
- User Requirement Specifications
- Functional Requirements (Functional Requirement Specifications)
- Validation Plans (VP)
- Validation Master Plans (VMP)
- Risk Assessment (RA)
- Test Plan / Test Protocol
- Operational Qualification (OQ)
- Performance Qualification (PQ)
- Requirements Traceability Matrix
- Validation Summary Report
- Change Control for Validated Systems
- Auditing and Assessments
- Verification and Validation checklists