“Ours is a world where people don’t know what they want and are willing to go through hell to get it” – Don Marquis
One of the hardest parts of any project is to define requirements – in other words, establishing exactly what the stakeholders (lovely creatures) need (and want) and delivering it. Failing to capture the appropriate requirements will
likely result in disaster.
Tip: Requirements need to be discovered before they can be “gathered”!!!
1 – Elicitation / Gathering
Before kicking off this exercise it’s absolutely vital that you identify the KEY stakeholders, in other words, the key people who will be affected by the project (don’t forget the end-users, they will be the ones using the solution, product, or service). Ask! Ask! Ask!
Requirements are typically elicited through workshops (actively engaging the stakeholder in defining what they need), documented sources, and existing systems and processes.
Some techniques that can be used for this purpose include:
- Brainstorming: technique used to generate and collect multiple ideas related to project and product requirements.
- Stakeholder Interviews: talk with each stakeholder or end-user individually. This allows you to understand each person’s specific views and needs.
- Workshops/Focus groups: bring together prequalified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product, service, or result. This helps you understand how information flows between different divisions or departments.
- Use Cases: this scenario-based technique lets you walk through the whole system or process, step by step, as a user. It helps you understand how the system or service would work. This is a very good technique for gathering functional / non-functional requirements, but you may need multiple “use cases” to understand the functionality of the whole system.
- Questionnaires and surveys: written sets of questions designed to quickly accumulate information from a large number of respondents. Questionnaires and/or surveys are most appropriate with varied audiences, when a quick turnaround is needed, and when respondents are geographically dispersed.
- Prototyping: build a mock-up or model of the system or product to give users an idea of what the final product will look like. Using this, users can address feasibility issues, and they can help identify any inconsistencies and problems. For example, when you have a complete list of requirements after your interviews, you can then build a prototype of the system or product.
- Analyse existing documentation: business documents, project charter/mandate, PID, business case, RAID log (specifically ‘assumptions’), lessons learned log, stakeholder register and other project documents.
Tip: it’s a good idea to keep asking “Why?” for each requirement. This may help you eliminate unwanted or unnecessary requirements.
2 – Categorisation / Analysis
To make analysis easier, consider grouping the requirements into the following categories:
- Business requirements – higher-level needs of the organisation as a whole (ie business issues or opportunities)
- User requirements – needs of a stakeholder or stakeholder group
- Functional requirements (what) – behaviours of the product, how a product/service/solution should function from the end-user’s perspective
- Non-functional requirements (how) – supplement functional requirements and describe the environmental conditions or qualities required for the product to be effective
- Technical requirements – technical aspects a system must fulfil (ie operate on a specific platform, Dynamics 365)
Consideration should also be given to:
- Implementation requirements – temporary capabilities or behaviour required to enable transition from the current state to the desired future state.
- Project requirements – actions, processes, or other conditions the project needs to meet (ie milestone dates, contractual obligations, constraints, etc)
- Quality requirements – any condition or criteria needed to validate the successful completion of a project deliverable or fulfilment of other project requirements (ie tests, certifications, validations, etc).
Once you have gathered and categorised all of the requirements determine which requirements are achievable, and how the system or product can deliver them. Doing the following will certainly help:
- Define requirements precisely – ensure that the requirements are:
- Not ambiguous or vague
- Clearly worded
- Sufficiently detailed so that everything is known (project over-runs and problems usually come from unknowns that were not identified, or sufficiently well-analysed)
- Related to the business needs
- Listed in sufficient detail to create a working system or product design
- Referenced to a project deliverable
- Prioritise requirements – although many requirements are important, some are more important than others, and budgets are usually limited. Therefore, identify which requirements are the most critical, and which are “nice-to-haves”. Moscow is perhaps the most common and one of the most simplest techniques to use. Another simple technique is the Needs-Based prioritisation technique which distinguishes between what people really need versus what they would like to have.
- Resolve conflicting issues – sit down with the key stakeholders and resolve any conflicting requirements issues.
- Analyse feasibility – determine how reliable and easy-to-use the new product or system will be. A detailed analysis can help identify any major problems.
Once everything is analysed, present your key results and a detailed report of the business needs. This should be a written document (ie requirements register, business requirements document, functional requirements document).
Circulate this document among the key stakeholders, end-users, and development teams, with a realistic deadline for feedback. This can help resolve any remaining stakeholder conflicts, and can form part of a “contract” or agreement between you and the stakeholders.
3 – Validation / Sign Off
Make sure you get the signed agreement of key stakeholders, or representatives of key stakeholder groups, saying that the requirements as presented precisely reflect their needs. This formal commitment will play an important part in ensuring that the project does not suffer from scope creep later on.
4 – Change Management
Requirements changes become necessary and sometimes inevitable due to changes in stakeholder / user requirements and changes in business rules and operating environments. Changes to requirements should be documented and controlled formally. Change management is a continuous process throughout a project. The change management process should ensure changes are made systematically and that the requirements document is updated.