One of the primary reasons for project failure is teams having poor requirements management processes. Ineffective requirements management often leads to scope creep, which in turn may cause project cost overrun or project delays.
An effective Requirements Management process is crucial for the success of a product or project and involves collecting, documenting, analyzing, refining, and prioritizing the requirements, building end-to-end traceability, providing a means to track requirements changes, and foster communication among the stakeholders. The goal of each step in this process is to help ensure that the product development or project goals are successfully met.
NEW RESEARCH: LEARN HOW DECISION-MAKERS ARE PRIORITIZING DIGITAL INITIATIVES IN 2024.
The first step in requirements management is to document the requirements or create a requirements backlog. A good requirements document or repository can help your organization save a fortune by providing clear communication between the developer and other stakeholders.
In this article, I will share some useful tips that can help you write crisp and clear requirements.
1. Understand the user needs
Understanding your users’ needs and being able to define the problem statement is the first step for writing better requirements. A good strategy to understand user needs clearly is to find answers to the “three W’s”:
- What – What are we doing?
- Why – Why are we doing it?
- Who – Who is going to benefit from what we are doing?
Finding answers to the “three W’s” can help you immensely in developing a better understanding of the customer’s problems and needs and ultimately how you can reduce or resolve their pain points.
2. Requirements should be unambiguous
While documenting a requirement, make sure to take steps to minimize any vagueness or ambiguity. Ambiguous requirements may lead to misinterpretation, which in turn may result in a great deal of money and energy spent without meeting your customers’ needs. Here are a few tips to make sure that your requirements are unambiguous:
- Consistent terminology should be used while writing the requirements.
- Avoid using jargon or specialized terms, if possible. If used, remember to define them in a glossary to avoid any confusion.
- Using adverbs should be avoided. Using words like quickly, usually, frequently, etc can be confusing since these can not be measured and different people can have different interpretations for these words.
- Using vague indefinable terms like flexible, user friendly, etc should be avoided.
- Avoid negative requirements which specify what should not be done. Instead, phrase them to specify what should be done. For example, instead of writing a requirement as “The application should not allow customers to access internal support tickets”, the requirement can be phrased as “The application should only allow employees to access internal support tickets”.
- Using abbreviations like e.g. and i.e. should be avoided.
3. Requirements should be simple, specific, concise, and comprehensive.
Make sure that the requirements are to the point, crisp and concise, but at the same time should also be able to convey the entire need. Brief statements make it easy to organize the requirements and also enhances readability.
4. Requirements should be testable.
It should be possible for the quality assurance or the testing team to verify if a requirement has been correctly implemented or not. The test should either pass or fail.
To ensure this, while writing the requirements, you should also determine how it would be verified and what would be the acceptance criteria.
5. Requirements should be separate from design and implementation.
While writing requirements, you should avoid explaining how the system will achieve something and should only concentrate on what the system has to achieve. You should focus on the “what” of the system and not on “how”.
You should refrain from designing the system or mentioning specific technologies, programming languages, etc for implementing the requirements.
6. Requirements should be attainable.
It should be technically feasible to implement the requirement within the allocated budget and timeline.
Since you do not live in an ideal world, the requirements you write must be realistic and achievable.
A requirement is attainable if it can be practically implemented within the given schedule and budget by your team.
For example, a requirement like “The application should allow 20,000 users to work concurrently with a response time of less than a second” may be practically feasible, but you need to understand if that can be achieved by your team under the given time and budget.
It’s possible that such a requirement may not be attainable for your team. Hence while writing the requirement, it is important to pay attention and check if it is attainable or not.
7. Requirements should be properly categorized.
The requirements should be categorized appropriately as Business Requirements, Functional Requirements, Non-Functional Requirements, System Requirements, etc. (as per your organizational needs). This helps the stakeholders to identify and concentrate on requirements that are relevant to them.
8. Requirements should be prioritized.
Prioritizing the requirements is the process of ranking them in order of their relative importance to the stakeholders.
Prioritizing the requirements serves two important purposes:
- Scope definition
- Scheduling the implementation.
This helps to make sure that the team is focussing on mandatory requirements first and then on the ‘nice to have’ requirements.
The following are some techniques that can be followed while prioritizing the requirements:
- Grouping or Ranking: In this approach, you can assign a ranking or priority indicator to various requirements. For example, you can assign priority values as high/medium/low or even numerical values.
- Timeboxing/Budgeting: This approach can be used when there are fixed timelines and budgets to achieve the project milestones. This approach is based on the principle of releasing an MVP or base product having necessary features on time rather than releasing a product with all the features at a later date.
- Negotiation or Voting: This approach involves establishing consensus among the stakeholders and prioritizing the requirements based on several votes or inputs.
9. Requirement should be traceable.
Requirements traceability refers to the ability to document and follow the entire lifecycle of a requirement (i.e. its origin, design, specification, implementation, validation, deployment, and use), in both forward and reverse direction and its relationship with other entities.
The purpose of requirements traceability is to ensure that requirements and linked entities are aligned to one another and to manage the effects of the change to one requirement on related entities or vice versa.
Traceability helps with:
- Impact analysis
- Easier identification of inconsistencies and gaps in requirements
- Identification of the scope and complexity of a change
- Assessment of the completion of requirements
- Tracking the status of project or release
A good requirement should always have a unique identifier and its source should always be known.
An example of a bad requirement is: “The email notification from Jira Service Management must include relevant information.”
An example of a good requirement is: “The email notification from Jira Service Management shall include request Id, Summary, Customer Name, Assignee, Status, and priority.”
Conclusion
To conclude, I would like to say that mastering the art of writing good requirements takes a lot of patience and practice. By following the right techniques and with dedicated time and effort, you can take your requirements documenting skills to the next level.
I hope the above tips will help you in writing better requirements and help your organization with a strong foundation for their requirements management process which in turn contributes to the success of your projects or product.
Confluence and Jira by Atlassian are great tools for creating and managing requirements. Reach out to one of our Atlassian Experts if you wish to know more about how you can create and manage requirements using these tools or if you want assistance with your requirements management process. We’d be happy to support you and your team in managing your requirements and also with your Atlassian learning journey.
