Define Requirements Approach and Project Scope:
- Requirements: Features needed by business staff from a system.
- Requirements Engineering Framework: Includes elicitation, analysis, validation, documentation, and management. It’s non-linear and involves stakeholder engagement.
- Adapting Requirements Engineering: Factors include organizational standards, project approach, types of requirements, and nature of the solution.
- Project Initiation Document (PID)/Terms of Reference (ToR): Includes Objectives, Scope, Constraints, Authority, Resources (OSCAR), and aligns requirements with business objectives.
Elicit Requirements:
- Knowledge Types: Tacit (implicit) and explicit, individual and corporate.
- Techniques for Tacit Knowledge: Observation, storytelling, scenario analysis, prototyping.
- Elicitation Techniques: Interviews, workshops, observation, shadowing, storytelling, scenario analysis, role-play, prototyping, document analysis.
- Selecting Techniques: Based on project approach, resources, and stakeholder expertise.
- Suitability for Agile and Linear Approaches: Different techniques suit different development methodologies.
Record Requirements (Documentation):
- Categories of Requirements: Business (general, technical) and solution (functional, non-functional).
- Importance of Documentation: Ensures consistency, communication, validation, and supports development.
- Documentation Styles: Text-based and diagrammatic.
- Requirements Catalogue: Records source, owner, name, business area.
- User Stories: Standard format to communicate needs: “As a {user role} I want {feature} so that I can {reason}.”
Build Models and Prototypes:
- Modelling Functional Requirements: Conceptualizes the solution, confirms scope, provides clarity.
- Purpose of Modelling: Clarifies requirements, defines business rules, ensures consistency.
- UML Diagrams: Use case diagrams (actors, use cases, system boundary, associations) and class diagrams (classes, attributes, associations, multiplicities).
- CRUD Matrix: Shows which functions create, read, update, or delete data.
- Prototyping: Visualizes requirements, increases stakeholder understanding, confirms requirements.
Collaborate and Communicate with Stakeholders:
- Stakeholder Roles: Includes project sponsor, product owner, SMEs, and business stakeholders.
- Requirements Validation: Ensures solution features meet requirements through review and agreement.
- Validation Approaches: Informal and formal reviews.
- Agile Validation: Involves backlog initiation, maintenance, prioritization, and defining acceptance criteria.
- Formal Validation: Involves Business Requirements Document (BRD) and review groups.
Analyse, Prioritise and Assure the Quality of Requirements:
- Purpose of Analysis: Ensures requirements are clear, organized, and documented.
- MoSCoW Technique: Prioritizes requirements as Must have, Should have, Could have, and Won’t have.
- Quality Criteria: Clear, concise, consistent, relevant; checks for duplication, feasibility.
- Slicing Requirements: Allows incremental and linear development.
- Business Rules Analysis: Includes constraints, operational guidance, data models, CRUD matrices, activity diagrams, business process models.
- Testability: Ensures requirements can be tested to confirm they are delivered as intended.
User Analysis and Profiling:
- Techniques: User role analysis and personas.
- Customer Journey Map: Demonstrates user interaction points with the business/process.
Requirements Management and Traceability:
- Traceability: Establishes origin and ownership of requirements.
- Requirements Management: Ensures traceability, ownership, and alignment with business objectives.
- Elements of Management: Identification, cross-referencing, origin and ownership, software support, change control, configuration management.
- Change Control Process: Documents, analyzes, consults, decides, implements or rejects changes.
- Version Control: Allocates identifiers and version numbers to track changes.
- Forms of Traceability: Horizontal (forwards and backwards) and vertical.
Glossary
- Requirements: Features needed by business staff from a system.
- Requirements Engineering Framework: Includes elicitation, analysis, validation, documentation, and management.
- Project Initiation Document (PID)/Terms of Reference (ToR): Document that includes Objectives, Scope, Constraints, Authority, Resources (OSCAR) and aligns requirements with business objectives.
- Tacit Knowledge: Implicit knowledge that is difficult to articulate.
- Explicit Knowledge: Knowledge that can be easily communicated and documented.
- User Stories: Standard format to communicate needs: “As a {user role} I want {feature} so that I can {reason}.”
- UML Diagrams: Visual representations of system functions and data requirements.
- CRUD Matrix: Shows which functions create, read, update, or delete data.
- MoSCoW Technique: Prioritizes requirements as Must have, Should have, Could have, and Won’t have.
- Customer Journey Map: Demonstrates user interaction points with the business/process.
- Traceability: Establishes origin and ownership of requirements.
- Change Control Process: Documents, analyzes, consults, decides, implements or rejects changes.
- Version Control: Allocates identifiers and version numbers to track changes.
Glossary with Examples
- Requirements: Features needed by business staff from a system. Example: A retail company needs a system to manage inventory levels and sales data.
- Requirements Engineering Framework: Includes elicitation, analysis, validation, documentation, and management. Example: A software development project where requirements are continuously refined based on stakeholder feedback.
- Project Initiation Document (PID)/Terms of Reference (ToR): Document that includes Objectives, Scope, Constraints, Authority, Resources (OSCAR) and aligns requirements with business objectives. Example: A PID for a new marketing campaign outlining the objectives, scope, constraints, authority, and resources needed.
- Tacit Knowledge: Implicit knowledge that is difficult to articulate. Example: The experience of a senior manager.
- Explicit Knowledge: Knowledge that can be easily communicated and documented. Example: Documented procedures.
- User Stories: Standard format to communicate needs: “As a {user role} I want {feature} so that I can {reason}.” Example: “As a customer, I want to be able to track my order status online so that I can know when it will be delivered.”
- UML Diagrams: Visual representations of system functions and data requirements. Example: A use case diagram showing interactions between customers and the order management system.
- CRUD Matrix: Shows which functions create, read, update, or delete data. Example: A CRUD matrix for a database system showing which operations can be performed on customer data.
- MoSCoW Technique: Prioritizes requirements as Must have, Should have, Could have, and Won’t have. Example: Categorizing features for a new website using the MoSCoW technique.
- Customer Journey Map: Demonstrates user interaction points with the business/process. Example: Mapping the customer journey to identify pain points and opportunities for improvement.
- Traceability: Establishes origin and ownership of requirements. Example: Using traceability matrices to track requirements from inception to implementation.
- Change Control Process: Documents, analyzes, consults, decides, implements or rejects changes. Example: Using a change control board to review and approve requirement changes.
- Version Control: Allocates identifiers and version numbers to track changes. Example: Using version control to manage different versions of requirements documents.