How to write good requirements and types of requirements? Requirements are the starting point for everything – project scoping, cost estimation, scheduling, coding, testing, and release management. If the requirements captured doesn’t serve the purpose that are supposed to do; there is hardly any benefit in spending time and money behind it. There are about five common traps that results in ineffective and non-verifiable defects:
- Not understanding requirements;
- Not having continuous dialogue with stakeholders;
- Not getting consensus;
- Not involving other disciplines early; and
- Not limiting scope and requirements creep.
Thus good quality requirements should
- Establish a common understanding between the project sponsor, customers, developers and other stakeholders
- Improve customer confidence in the products to be delivered
- Provide a roadmap to development
So how to get the right requirements and make sure they are of quality ones. Some of the official channels that Business Analyst try to get requirements of a client could be interaction with end users or sponsors, business cases, request for proposals, regulations and so on. In a seminal article titled Writing good requirements is a lot like writing good code, Jim Heuman, a Requirements Management evangelist talks in detail about how to write good quality requirements. A lot of articles are available in public domain that talks about how to write good requirements. Essentially the core principles revolve around a requirement being Simple, Verifiable, Necessary, Achievable, and Traceable. We will discuss some of the techniques used to capture requirements later. Provided below are some of the resources that will help you in writing good requirements.
A Business Analyst’s soft skills are equally important to succeed in this endeavor. I am sure you must have seen a similar picture that shows to what extend understanding the requirements of a customer can go wrong. Some of the common mistakes a business analyst makes while requirements gathering and analysis are incorrect assumptions, not using the correct level of abstraction, contradicting and inconsistency between requirements and finally over specifying requirements to a specification level. Even using simple language, avoiding generic phrases and using correct grammar becomes handy while writing good requirements.
In our earlier post, we defined requirements as a condition or capability needed by a user to solve a problem or achieve an objective. Often the client provides a high level requirement in the form of a need. These needs, expectations and concepts must be identified, analyzed and elaborated into a set of business requirements. Key requirements in this set should be traced back to the business case provided relating to the need and client’s vision.
At a broad level, requirements could be divided into functional and non-functional requirements. Functional requirements provide the high level description of how a system of product should function from the end user’s perspective. It provides the essential details of the system for both business and technical stakeholders. Expectations are expressed and managed using functional requirements. Some of the key aspects functional requirements try to address are for whom the product is built, how is it expected to be used, what are the interactions and any guidelines to be followed. Non-functional requirements represent mainly the qualities (expectations and characteristics of the system) and constraints (for example Governmental regulations).
When it compared to requirements levels – we can start with the Requirements Pyramid as shown below . It essentially starts from the stakeholder needs at the top to the test cases that verify the implemented requirements at the bottom.
Figure 1: Requirements Pyramid
Next time we will discuss why baselining the requirements
About the Author
