Duration: 2 Days
Course Overview
Capturing and documenting high-quality requirements has been proven to reduce project failure more than any other single element in the business-project life-cycle. Whether you are developing your product internally, or putting the specifications out to tender, high-quality requirements documentation will save you money, time, and sub-optimal implementations.
Business analysts, project, program, and portfolio managers, and members of the management, testing team, development team, or procurement who wish to understand the issues around high-quality requirements.
How can I attend my course?
Course Content
Day One
• Identifying Business Needs
• The Requirements Engineering Process
• Eliciting high-quality requirements
• Analysing elicited requirements
Introduction
• What are requirements?
• Why do we need requirements?
• Where do we use requirements
• The business analysis process model
Activity: Elicit a Requirement
Eliciting High-Quality Requirements
• What did we miss?
• Functional versus non-functional requirements
• Tacit knowledge and ignorance
Investigation Techniques to Elicit Tacit Knowledge
• Observation
• Ethnographic studies
• Protocol analysis
• Shadowing
Activity: Identifying Your Stakeholders
Working with Stakeholders
• The Stakeholder Communication Model
• Conducting interviews, workshops, and focus groups
• Common areas:
• Preparation
• Openings
• Closing
• Serial summarisation
• The interview process
• Tools and techniques for requirements workshops
• Divergent and convergent thinking
• VAKOG – Maximizing audience attention
• Brainstorming, brain writing, affinity diagramming
• Using prototypes to elicit emergent needs
Analysing the Elicited Requirements
• Creating use case diagrams
• Modelling the “as-is” and “to-be” processes
• Prioritisation by value or for delivery
• MoSCoW
• Prioritisation using time boxing
• Checking value with value stream mapping
Day Two
• Analysing requirements (continued)
• Documenting requirements
• Managing requirements
Activity: Modelling the “as-is” Process
• Creating a cross-functional process map
Activity: Creating the “to-be” Process
The Requirements Documentation Model
• Using questions: Requirements in Requests for Information
• Formal documentation: Requirements as statements
• Informal to formal documentation: Iterating with use cases
• Selecting how to document your requirements
Activity: Documenting Requirements
Verifying Requirements Quality
• What can we check?
• Verifying requirements by class of requirement
• Using IEEE-1998-830 as a standard for well-formed requirements
• Converting use cases into test scripts
Activity: Checking Your Requirements
Validating the Requirements
• Validation methods and techniques
• Reviews
• Walk-throughs
• Inspections
• Signing off the baselined requirements
The Requirements Management Model
• Introducing Configuration Management
• The value of traceability in the management model
• Implementing A Change Control Board (CCB)
• Assessing impact and cost of requirements changes
• Delivering the Requirements