- ✓Requirements elicitation is the process of discovering what stakeholders need from a system through structured engagement.
- ✓Interviews allow analysts to probe individual stakeholders in depth, while workshops bring multiple stakeholders together to resolve conflicts and build consensus.
- ✓Functional requirements describe specific capabilities the system must provide; non-functional requirements address qualities such as performance, reliability, and usability.
- ✓Prototyping is a powerful elicitation technique that helps stakeholders articulate requirements by reacting to a concrete demonstration rather than abstract descriptions.
- ✓Requirements management continues throughout the project; a change control process ensures that new or evolving requirements are assessed and incorporated in a controlled way.
Listen to the full episode inside the course. Enrol to access all 80 episodes, plus assignments, tutor support and Student Finance funding.
Start learning →Alex: Today we're focusing on getting requirements right. Sam, why is requirements elicitation considered one of the hardest parts of systems development?
Sam: Because it's fundamentally a communication and understanding problem, not a technical one. You're trying to accurately understand and document what someone else needs, often when they don't have precise language for it themselves, when different stakeholders have conflicting needs, and when the full implications of one requirement on another may not be apparent until later. Getting it wrong at this stage causes problems that compound through every subsequent phase of development.
Alex: What are the main techniques for eliciting requirements?
Sam: Interviews are one-to-one conversations where you explore an individual stakeholder's needs, priorities, and constraints in depth. They're good for detailed exploration but time-intensive. Workshops bring multiple stakeholders together to discuss requirements collectively, surface conflicts, and build shared understanding; they're efficient for generating a shared view but require skilled facilitation to prevent the conversation being dominated by the most vocal participants.
Alex: What about prototyping?
Sam: Prototyping is one of the most effective elicitation techniques available. Showing stakeholders a working prototype, even a very simple one, generates much richer feedback than asking them to describe requirements in the abstract. People find it much easier to say 'yes, this is what I meant' or 'no, this is not right, I actually meant something more like this' when they can interact with something concrete. Low-fidelity prototypes, like paper mockups or simple wireframes, are often enough to generate valuable requirements discussions.
Alex: How do you express requirements clearly once you've gathered them?
Sam: The key is to separate what from how. A requirement should describe what the system must do or what quality it must have, not how it should be implemented. 'The system shall send a confirmation email within two minutes of a successful order being placed' is a well-formed functional requirement. 'The system shall use SendGrid for email' is a design decision, not a requirement, and locks in an implementation choice that should be made during design.
Alex: What's the difference between functional and non-functional requirements?
Sam: Functional requirements describe specific things the system must do: the functions and features it must provide. Non-functional requirements describe the qualities the system must have: performance, security, reliability, usability, maintainability, and scalability. Non-functional requirements are often more challenging to elicit and specify precisely, because they describe qualities rather than behaviours. But they're frequently the requirements that cause the most problems if they're not addressed properly.
Alex: How do you manage requirements as they change during a project?
Sam: Through change control. Every proposed change to the requirements should go through a formal process: document the change, assess its impact on scope, cost, and schedule, get approval from the appropriate stakeholder, and update the requirements documentation. Without change control, scope creep quietly expands the project beyond what was originally agreed, leading to overruns and disappointed stakeholders.
Alex: Brilliant. Thanks Sam. We move into Unit 12: Network Management next.