Requirement is a word often bandied about by many stakeholders involved with projects. Before we delve into what makes up a good requirement, let’s define what the word means and encompasses, why it is important to ensure a level of quality control when documenting them, and who utilises them within a project.
What are requirements? Business Analysis Body of Knowledge® (BABOK® v3)1 and the IEEE Glossary of Software Engineering Terminology2 provide this definition:
- Condition or capability needed by a user to solve a problem or achieve an objective.
- Condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
- Documented representation of a condition or capability in (1) or (2).
So, it is a condition or capability that is documented during the lifecycle of a project. BABOK® also provides further elaboration on what they are through a requirements classification schema where they are broken down into:
- Business requirements – business goals, objectives and outcomes
- Stakeholder requirements – needs of stakeholders to meet the business requirements and bridge the gap to solution requirements
- Solution requirements – a more widely understood definition of a requirement which describes the capabilities of a solution, which can be separated into functional and non-functional requirements
- Transition requirements– describe solution capabilities and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete
From this we understand that requirements have a broad definition and should convey holistically how a business will “solve a problem or achieve an objective” and define how a solution (system or system component) may contribute to that goal.
Common ways to document requirements include use cases, user stories, declarative statements, business rules, data modelling and process modelling (although these are generally backed by declarative statements). Design Thinking and other methodologies may also bring into play other ways of documenting requirements such as personas, journey maps and wireframes. Regardless of what stage in the project lifecycle or what method is utilised to document requirements, the quality should be high. Many stakeholders are reliant on this documentation as it is used to create a common understanding and provide confidence on moving into future project stages. Project resources utilise documented requirements for different purposes:
- To aid Subject Matter Experts (SME) and Sponsors understanding of why, what, and how the business will transform through a project
- To provide guidance to Architects designing the solution
- To enable Change Managers to understand the change being introduced and how that will impact the people within or outside the organisation
- To aid Developers in understanding what they need to build within a solution
- To inform Testers what to test both functionally and for business acceptance
- To aid Training Specialists to define what training people should receive to embed the business change
The consequences of poorly defined requirements may lead to inferior solution design, inadequate functionality, unclear test cases or unknown people impacts of any change. This can lead to the project not meeting objectives, not delivering to scope or over-running on schedule or budget. So, the importance of good requirements is paramount to project success.
What resources are available to help a person responsible for documenting requirements? What characteristics should a good requirement have? BABOK®, IEEE Standard 830 and PMI Guide for Business Analysis all have a section devoted to the characteristics of good requirements. BABOK® is generic in approach and focuses on each individual requirement as it encompasses a broad definition of requirements, whilst IEEE focuses on the software requirement specification (SRS) as a whole, and PMI relates to user stories only. There is commonality across these three guidelines on characteristics and these are shared in the table below.
Table of good requirement characteristics3
|
BABOK (Characteristics) |
IEEE Std 830-1998
(Characteristics of an SRS) |
PMI Guide for Business Analysis
(Characteristics of user story – INVEST) |
| Atomic – Independent of other requirements. | Independent – User story is independent so it can be estimated and built on its own. | |
| Complete – Enough to guide further work and at the appropriate level of detail for work to continue. Varies through methodology and stage of the project. | Complete In reference to the entire SRS – All significant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces. | Estimable – User stories have enough detail for the development team to provide a rough estimate of size. |
| Consistent – Aligned with the identified needs of the stakeholders and not conflicting with other requirements. | Consistent – Consistency refers to internal consistency. It is internally consistent if, and only if, no subset of individual requirements described in it conflict. | |
| Concise – Contains no extraneous and unnecessary content. | ||
| Feasible – Reasonable and possible within the agreed-upon risk, schedule, and budget, or considered feasible enough to investigate further through experiments or prototypes. | Correct – An SRS is correct if, and only if, every requirement stated therein is one that the software shall meet. | |
| Unambiguous – The requirement must be clearly stated in such a way to make it clear whether a solution does or does not meet the associated need. | Unambiguous – An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation. | |
| Testable – Able to verify that the requirement or design has been fulfilled. | Verifiable – A requirement is verifiable if, and only if, there exists some finite cost-effective process with which a person or machine can check that the software product meets the requirement. | Testable – The characteristic that determines whether a story can be finitely tested by a test team and if the customer understands how to accept the final requirement as done. |
| Prioritised – Ranked, grouped, or negotiated in terms of importance and value against all other requirements. | Ranked for importance and/or stability – Each requirement in an SRS has an identifier to indicate either the importance or stability of that requirement. | Valuable – Where each story has value to the business, or the customer and the backlog is ranked based on that value. |
| Understandable – Represented using common terminology of the audience. | ||
| Negotiable – The characteristic in adaptive methodologies that ensures that too much information is not captured up front because all user stories and the details surrounding them should be negotiable. | ||
| Small – In the adaptive sense, small means that the story is small enough for the development team to complete it within a single time-boxed iteration. |
If the above table provides guidelines on characteristics of a good requirement, then what is a bad one? Some common mistakes made by requirements documenters are shared in the table below.
Table of bad requirement examples
| Type | Example | |
| Using jargon or specialised terms as these can create confusion for the reader. Avoid unless you cannot, and then provide a glossary in the documentation. | The system shall allow a user to create a blanket order. | |
| Use of adverbs such as quickly, frequently, usually. These cannot be measured and therefore are not testable. | The system shall refresh the information displayed on the screen frequently. | |
| Using indefinable terms such as user friendly, intuitive, flexible. These are ambiguous and again untestable or verifiable. | The input screen for a user should be user friendly. | |
| Writing in the negative instead of phrasing in the positive on what should be done. | The system shall not be available to users on the weekend. | |
| Requirements that are statements on implementation instead of need – i.e. How something is to be provided instead of What is needed. | The system shall provide a database.
|
|
| Use of nonspecific words or acronyms such as etc, and/or, TBD. | The system shall provide a listing of departments etc. | |
| If “and” or “but” used in a requirement, there may be more than one requirement in the statement. Always ensure that requirements are Atomic. | The system shall provide the opportunity to book the flight, purchase a ticket, reserve a hotel room, reserve a car, and provide information about attractions. | |
Documented requirements can take many different forms, and a requirement has a very broad definition provided by BABOK®, but the key factor as a person who documents requirements is their quality.
The difference between a good vs a bad requirement is to take time to review them, as you document, against the characteristics provided by either BABOK®, IEEE or PMI. Keep the characteristics handy and ensure you build this review into your plan as a Business Analyst, whether working alone or with other Business Analysts. Some other recommendations to help in ensuring quality requirements:
- Utilise your requirements traceability matrix as the means to check that each requirement is Atomic
- Build in peer reviews into the process of documenting and managing requirements, if there is more than one Business Analyst
- Utilise the project testers as a litmus test on quality and the right level of granularity. Experienced testers are your friend and can spot a badly documented requirement at 100 paces
Documenting good quality requirements is essential for the success of a project and like all things it does take practice.
References
1 BABOK v3 A Guide to the Business Analysis Body of Knowledge Version 3.0 published 2015.
2 “IEEE Standard Glossary of Software Engineering Terminology,” in IEEE Std 610.12-1990 , vol., no., pp.1-84, 31 Dec. 1990,: 10.1109/IEEESTD.1990.101064.
3 Business Analysis body of knowledge (BABOK) v3 – Requirements analysis and design definition
IEEE Recommended Practice for Software Requirements Specifications – June 1998 – characteristics of a good SRS
PMI Guide for Business Analysis – Verify requirements.
