Writing requirements is part of an analyst’s day-to-day routine. It may be a change request that has to be translated to specific requirements, a completely new system that has to be decomposed into requirements or some requirements concerning transitioning phase.
In any case, the quality of your requirements will determine the effort and accuracy of the project’s deliverables. Quality and agreed requirements are the basis of developing solutions that will provide value to customers and will increase their satisfaction.
What is a Requirement?
Α requirement is a statement on how a specific aspect is supposed to work in a system in order to fulfill the needs of the customers. It is a description of what should be done in order to achieve the desired future as perceived by the customers. A requirement is supposed to guide the development team in order to understand what should be implemented and also to serve as a checkpoint for evaluating the result.
Do not overpass Depth
First what we need is to understand is that there are different types of requirements. Different requirements classification schemas exist. However, in my perspective we can be sure that regardless of the classification, those types typically depict the depth and the technical detail of the requirement itself. A project in the early phase may require high-level business requirements that are aligned with the goals and objectives of the project and mirror the high-level aspirations of the client. As the team moves forward to the solution those requirements can be more detailed and specific. So, in order to assess a requirement as “good” we always need to consider the phase of the project and the available information that time. Its fine at the beginning of the project to depict a general idea in more abstract requirements and then progressively dive into more details. We cannot know every detail from the beginning. But we need to have something in order to progressively reach the point of detail of the requirement that is enough for the development effort and the needs of the stakeholders.
The benefits of Well-Structured Documentation
Let’s begin with documentation. The importance of the documentation is found in the need of achieving clearance to all stakeholders and agreement of what will be done. How do we want the new system to function? What are the key processes that the system will support? All those answers should be found in a requirements document and not be diffused into different places like notes, emails or in the mind of the businesspeople or developers. Documentation is the trigger of discussions between stakeholders and the basis of an agreement with the time horizon. Requirements document most probably will follow the system in all his lifecycle and can serve as a knowledge base that can progressively be expanded at a mature level. Also, contractual agreements and responsibilities may derive from requirements documents.
The structure of a requirements document should be tailored to cover the needs of the stakeholders and the specific characteristics of the project. Many organizations have introduced a structured typical set of requirements documents that need to be completed for every solution or initiative that consists of multiple solutions. Some others not. However, it is crucial to consider continuity. Take for example, a new colleague or a new stakeholder. The requirements document is the way for an introduction and a way of knowledge transfer.
Have in mind a person that does not know the details of the project. She/He should be able by reading a requirements document to understand at a certain level what a specific system will be like and how it is supposed to work. The requirements document should depict a holistic overview of the system and a clear depiction of the interdependencies. Do not forget that after the implementation of the solution the maintenance of the system will take place, as well as, possible expansion. Well-written requirement documents contribute to the effort for scalability and adaptability.
Good Requirements are Verified Requirements
Verified is a requirement that meets specific quality standards. The following are some of these standards:
- Each Requirement should have a unique identification like a title and/or an ID and some additional fields if needed in order to have a way for recognizing them. Some requirements management systems also allow having specific labels that you can use to search for the requirement.
- It is a good approach for each requirement to be understood, meaning that you are not supposed to read every existing requirement in order to understand one single requirement. However, this goal is not easily feasible and that’s why specific connections between requirements may exist. Also, reference to another requirement can be made in the description.
- Two persons reading the same requirement should have a shared understanding of what is about and not have to use creativity to fill logical gaps. Less effort and time for explanations will be required if the author of the requirement put himself in the reader’s position and try to understand their perspective.
- The author of the requirement should consider and understand the big picture and demonstrate systems thinking. The sum of the requirements should consist of a harmonic whole. Zoom out as well zoom in is something necessary before finalizing requirements.
- Α requirement should describe something that it’s feasible in technical terms to be developed. A requirement is not wishful thinking or a philosophical essay. Also, test cases or at least the possibility of producing user stories should be ensured before finalizing a requirement.
Good Requirements are Validated Requirements
Let’s now move on to the validation process of requirements. A good requirement should be validated. Validation is thinking about the value that the requirements provide having in mind the project as well as organizational context. Validation has to do with the content itself. What is written in a requirement, if this makes sense, and if it is aligned with the overall goals and project scope.
Validation is accompanied by business thinking as well as system thinking. Is the requirement depicting something that will lead to the development of a solution component that will provide value to the customers? Is this requirement making sense in the context we are working? Will this requirement contribute to better outcomes for the clients?
Answering the above questions requires of course deep business domain knowledge and a holistic understanding of the customers' aspiration and needs.
Ask …
- Is the requirement understandable by a person who was not being involved in detail with the project?
- Will a new colleague be able to understand what the system is expected to do by reading the requirements document?
- Will the dev team that will read this document understand what is needed to be done without much effort and clarifying questions?
- Is the requirement feasible and realistically testable? Can I prepare test cases for that requirement?
- Is the origin of the requirement clearly stated?
- Does the requirement describe something that the stakeholders want and have agreed on?
- Will this requirement contribute to achieving the desired future state?
Author: George Sioutzos