There are different levels of requirements gathering which need to be conducted at different periods of time during the lifecycle of a project. This article sets out a brief description of each of the type of requirements, why, how this relates to traceability and some examples.
- Further articles on gathering goals / objectives – How to gather benefits and requirement justifications using NLP, A technique for identifying project scope
- Further articles on Stakeholder requirements – Using NLP to explain ambiguity from gathering and documenting requirements, What to include in a Business Requirements Document (BRD)
- Further articles on Solution requirements – Using a use case model for estimating and planning, The benefits of using Story boards to gather requirements, Interview with Andy Barnett (UML expert), Are your stakeholders using different words when describing data to mean the same thing?, What are Non Functional requirements, why they are important and common mishaps (part 1), Gathering Non Functional requirements and who to involve (Part 2)
It is the role of the Business Analyst to gather, document and ensure traceability between these requirements. Adhering to these categories will also help identify missing requirements as they should all align with each other.
See below for some examples to help with differentiating.
| Business Objectives / Goals | Stakeholder requirements | Solution requirements | Transition requirements |
| To increase sales on-line by 20% in 12 months. | To be able to identify customer interests to understand current trends.
To enable customers to part exchange old stock for new. To push marketing messages to customers. To collect customer and contact details. |
Functional requirements
Produce MI reports to identify what current stock is being purchased and trends. To create a new web page which enables customers to part exchange old stock for new. To collate customer contact details in a database and send out marketing messages monthly by email. Business rules There should be a check that the old stock to be exchanged cannot be more than 3 years old. Non functional requirements To be available 24×7. To support volumes of an estimated 2000 concurrent users. |
Existing customer contact details must be migrated onto the new system.
Internal staff must have training on how to use the Reporting tool and how data is structured. |
Thoughts? Questions? Please share in the comments.
If you have found this article useful then you might like my book – The Business Analysis Handbook – Techniques and Questions for better Business Outcomes. The book is available from www.koganpage.com and all major print and e-book retailers.
An interesting article. I would add one other crucial element and that is the problem statement. The problem statement should be precise and contain measures of impact. without this, you cannot set meaningful objectives or validate any requirements. Then I would say the types of requirements follow on nicely.
Agree. Good point. It’s important that the requirements resolve the problems in the first place so need to know that first. Thanks Peter.
An very interesting and insightful article indeed. Following the notes stated here would reduce headaches of trying to incorporate stakeholders requirements at the end of the project which at times might require a total system design change. Point in case, stakeholders know of upcoming investments and possible branches/business entities for the near future that operational staff are not aware of, they are mainly concerned with the solution to meet their day to day operations. At a point of commissioning the project the stakeholders then bring out the vision of more branches/business entities. With a rigid system you might just need to totally redesign the whole system to incorporate the stakeholders vision. Great article indeed, Thanks!
Thanks Magareth for the feedback and for the good summary from reading the article.