What is a requirement?
A feature or characteristic requested by a stakeholder that forms part of a solution. It defines what a system should provide and how well it should perform.
What is the purpose of the Requirements Engineering (RE) framework?
To help business analysts systematically elicit, analyse, validate, document, and manage requirements so there is a clear foundation for developing business and software solutions.
What are the five core activities in the Requirements Engineering framework?
• Requirements elicitation – gathering requirements from stakeholders
• Requirements analysis – reviewing requirements for clarity and duplication
• Requirements validation – stakeholders review and approve requirements
• Requirements documentation – creating a structured requirements document
• Requirements management – controlling and maintaining requirements throughout the project
Who are the main business representatives involved in requirements engineering?
• Project sponsor – ensures business objectives are met
• Product owner – manages the product backlog and makes product decisions
• Subject Matter Expert (SME) – provides specialist domain knowledge and best practices
• Business staff – operational users who implement processes and use the system
Who are the members of the project team in requirements engineering and their roles?
• Project manager – responsible for project delivery and objectives (defined in TOR/PID)
• Business analyst – elicits, analyses, and documents requirements
• Developer – builds the software solution based on requirements
• Software tester – attempts to find faults and prove where the system does not work
What are the two main categories of requirements?
- Business requirements (general and technical)
- Solution requirements (functional and non-functional)
What are general business requirements and what do they include?
Broad organisational rules and policies which can be broken down into more detailed requirements. Examples include:
• Business constraints – budget, timescale, resources
• Business standards/policies – customer service, environmental or inclusion policies
• Business continuity – managing and preventing disruption from incidents
• Legal requirements – e.g. GDPR
• Branding – logos, fonts, colours, language
• Cultural and language requirements
What are technical business requirements?
Organisation-wide technical policies or constraints such as:
• Hardware requirements
• Software standards
• Interoperability between systems
• Internet or network requirements
What are functional requirements?
Features or operations a system must perform such as:
• Data entry
• Data processing
• Reporting
What are non-functional requirements?
Requirements that define the performance or quality of a system, including:
• Performance
• Security and access permissions
• Backup and recovery
• Archiving and retention
• Robustness and availability
• Capacity and capability
What usability and accessibility factors may be included in non-functional requirements?
• Usability, learnability, efficiency, memorability, satisfaction
• Error handling
• Accessibility for cognitive, physical/motor, hearing, or visual disabilities
What other requirement types may exist besides business and solution requirements?
• User interface requirements
• Transition requirements
What are requirements elicitation workshops and what techniques are used?
Workshops are collaborative sessions to discover and visualise requirements using:
• Visualisation – rich pictures, mind maps
• Modelling – business process, data, and use case models
• Scenario analysis – walking through step-by-step transactions
• Prototyping – wireframes or prototype screens/reports
What is tacit knowledge?
Knowledge that is personal, experience-based, context-specific, and difficult to explain or document. It cannot easily be codified but can be transferred through experience and training.
Where can tacit knowledge hide in organisations?
• Skills – analysed with protocol analysis
• Taken-for-granted information
• Conceptual requirements – discovered using scenarios, prototypes, brainstorming, storytelling, wireframes
• Tacit assumptions – identified using ethnography
• Intuitive understanding – analysed with protocol analysis and decision tables
What are examples of organisational tacit knowledge?
• Norms of behaviour
• Communication styles
• Organisational culture
• Organisational stories
• Formal and informal networks
What are the key elements of requirements analysis?
• Categorisation – grouping requirements
• Modelling – representing requirements visually
• Prioritisation – determining importance of requirements
What are requirements filters and what do they check?
Filters review elicited requirements to ensure they are well-formed by:
• Unravelling multiple requirements in one statement
• Removing duplicates or overlaps
• Confirming relevance
• Evaluating feasibility
• Removing conflicts
• Ensuring requirements are not actually solutions
What quality criteria should requirements meet?
Requirements should be:
• Consistent
• Clear
• Concise
• Correct
• Relevant
• Unambiguous
• Testable
• Traceable
What feasibility areas are checked during requirements filtering?
• Technical feasibility
• Business feasibility
• Financial feasibility
What is INVEST and what does it stand for?
A guideline for good requirements or user stories:
• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable
What is the MoSCoW technique for prioritising requirements?
• Must have – essential requirements
• Should have – important but not vital
• Could have – desirable but not necessary
• Won’t have this time – excluded for this release
What are business rules?
Rules that define or constrain how an organisation operates and therefore influence system requirements.
What are the different types of business rules?
• Constraints – what may or may not be done
• Action governance – rules based on criteria such as age/status
• Data constraints – defined through data models or CRUD matrices
• Operational guidance – rules for transactions or decision-making
• Decision conditions – represented using activity diagrams, BPMs, or decision tables
• Calculations – formulas expressed using structured English or pseudocode
