- ✓Business requirements describe what a system or project must achieve from the perspective of the organisation and its stakeholders.
- ✓Stakeholder engagement is the primary method for uncovering requirements; different stakeholders will have different, sometimes conflicting, needs.
- ✓Technical feasibility assessment determines whether the proposed approach is achievable with available technology, skills, and resources.
- ✓Functional requirements describe specific capabilities the system must have, while non-functional requirements address qualities like performance and security.
- ✓A business-aware computing professional adds greater value by understanding why a system is needed, not just how to build it.
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 looking at exploring business requirements and stakeholder needs. Sam, why does a computing project need to engage with business requirements at all?
Sam: Because computing projects exist to serve a purpose for an organisation or its users, not just to demonstrate technical competence. A system that's technically impressive but doesn't meet the actual needs of the business or its users is a failure. Understanding requirements from a business perspective is what ensures the project delivers genuine value.
Alex: How do you go about discovering what those requirements are?
Sam: Stakeholder engagement is the primary approach. Stakeholders are anyone who has an interest in or is affected by the project's outcome. They include the end users who will use the system, the managers or owners of the processes the system will support, and often technical colleagues who need to integrate or maintain the system. You engage with them through interviews, workshops, questionnaires, and by reviewing existing documentation like process maps and complaints logs.
Alex: What's the difference between what stakeholders say they want and what they actually need?
Sam: This is one of the classic challenges in requirements gathering. Stakeholders often describe solutions rather than problems: 'we need a new spreadsheet' when the real need is 'we need a faster way to track stock levels'. Your job as a requirements analyst is to dig beneath the surface request to understand the underlying business need, and then explore what solution would genuinely address it. Techniques like asking 'why' several times to get to the root need, sometimes called the Five Whys, are helpful here.
Alex: What makes a requirement well-defined?
Sam: A good requirement is specific enough to be actionable, measurable so you can verify it's been met, and unambiguous so that different people reading it will understand it the same way. 'The system should be fast' is a poor requirement. 'The system shall return search results within two seconds for 95 percent of queries under normal load' is a good requirement. The difference is precision and testability.
Alex: What is technical feasibility, and why does it matter at the requirements stage?
Sam: Technical feasibility is the assessment of whether the proposed approach can actually be implemented with available technology, skills, and resources. It's important to assess this early because discovering late in a project that a requirement is technically infeasible is extremely costly. Sometimes stakeholders request things that are technically impossible or would require extraordinary resources, and part of the analyst's role is to explain those constraints and explore alternative approaches.
Alex: How do you record requirements?
Sam: Functional requirements, describing what the system must do, are often recorded as user stories in agile projects or as structured requirement statements in more formal projects. Non-functional requirements, describing the qualities the system must have, such as performance, security, and availability, are typically documented separately. Both types should be numbered and prioritised, so that the most important ones are clear and the team knows what to focus on if time is short.
Alex: Brilliant. Thanks Sam. In the next lesson we get into the practical work of project planning.