Gathering requirements is the initial and pivotal phase of the Software Development Life Cycle (SDLC). It involves compiling a concise set of business and technical requirements that the selected solution is expected to support by the project’s end.
The requirements gathering process assists business analysts and project teams in documenting all necessary business objectives and information, including requirements, needs, resources, risks, stakeholders, and more, to plan the project meticulously. Requirements are also a valuable input into the testing process, to confirm that what was delivered supports what was requested.
The key to documenting effective business requirements is to start from the desired outcome of the change project and work back. Ask “what success looks like”, then frame everything from the perspective of what the business wants to be able to do, without any reference to how the requirement will be delivered (no solutioning). Also, don’t fall into the common trap of mistaking existing process steps for requirements - there is always more than one way to get from A to B, so don’t constrain your organisation by insisting the new solution has to mirror the current, inefficient process steps.
Requirements need to be written in a way that enable technology suppliers to understand what functionality you need their solution to support, along with which capabilities are non-negotiable vs those which are simply “nice-to-have”.
This means it’s ill-advised to simply throw a requirements excel-spreadsheet at business stakeholders and expect them to fill it in without support, as they are unlikely to know how to phrase their requirements in a way that achieves this.
The responsibility of gathering requirements therefore typically falls on a business analyst who is able to bring the business and technical requirements together. The BA acts as a liaison between the business stakeholders and the project team, ensuring that all relevant information is captured and understood.
| Address Business Needs | Identify and address the underlying business needs that the project aims to fulfil. |
|---|---|
| Clarify Project Goals | Provide a clear understanding of the project goals, objectives and priorities |
| Are Written Clearly | Make sure ambiguous or unclear requirements are avoided by seeking clarification from stakeholders. |
| Frame Objectives & priorities from the End Users’ Perspective | Aligns the project with user expectations. |
Prioritisation can be applied to requirements/User Stories, tasks, products, use cases, acceptance criteria and tests, although it is most commonly applied to requirements/ User Stories. Balanced priorities are needed to decide the effort allocated to core functionality and contingency activity.
MoSCoW is a technique to understand and manage priorities. The letters stand for:
| Must Have | These provide the Minimum Usable SubseT (MUST) of requirements which the project guarantees to deliver. These may be defined using some of the following: o No point in delivering on target date without this o Not legal without it o Unsafe without it o Cannot deliver a viable solution without it Ask the question ‘what happens if this requirement is not met?’ If the answer is ‘cancel the project – i.e. there is no point in implementing a solution that does not meet this requirement’, then it is a Must Have requirement | | --- | --- | | Should Have | Should Have requirements are defined as: o Important but not vital o May be painful to leave out, but the solution is still viable o May need some kind of workaround, e.g. management of expectations, some inefficiency, an existing solution, paperwork etc. The workaround may be just a temporary one One way of differentiating a Should Have requirement from a Could Have, is by reviewing the degree of pain caused by the requirement not being met, measured in terms of business value or numbers of people affected. | | Could Have | Could Have requirements are defined as: o Wanted or desirable but less important o Less impact if left out (compared with a Should Have) These are the requirements that provide the main pool of contingency, since they would only be delivered in their entirety in a best-case scenario. When a problem occurs and the deadline is at risk, one or more of the “Could haves” provide the first-choice of functionality that can be dropped from scope. | | Won’t Have | These are requirements which the project team has agreed will not be delivered as part of the project scope. They should be recorded in the Prioritised Requirements List, which avoids them being informally reintroduced at a later date. This also helps to manage expectations that some requirements will simply not make it into the Deployed Solution, at least not this time around. Won’t Haves can be very powerful in keeping the focus on the more important Could Haves, Should Haves and particularly the Must Haves. |