Why a Requirements Strategy and a Requirements Plan helps to streamline your work

When working with testing it is very common to have a test strategy and a test plan so as to conduct effective and well thought out test work. However, within the requirements engineering field, this kind of documentation seldom exists. This leads one to wonder whether structure, order and planning are less important when it comes to requirements management.

Given that requirements are the single largest source of defects when building IT systems, it is obviously of huge importance that we work in a structured way with the requirements. Requirements management is the foundation to building the right system in the right way.

The work begins with determining the organization’s requirements strategy. For each system or maintenance object the requirements strategy is complemented by a requirements plan that describes in detail how requirements engineering is to be done in this situation. We also need to plan how handovers to maintenance are going to be carried out, both to be able to further refine the system as well as to achieve reusable requirements.

Requirements management in general is not as mature as other parts of the development process. For example, it has only been possible to get a certification within requirements management for the last few years, but within the testing and project management arenas, certification courses have been available on the market for many years.

There seldom is a conscious decision not to invest in requirements management, but it has been easier to identify and fix problems in other parts of the overall development process.

Now is the time to take the next step by introducing the concepts of requirement strategy and requirements plan

The Requirements Strategy describes the organization’s approach to requirements management

A requirements strategy is a description of how requirements work is to be carried out within projects, departments, and other types of assignments in your organization. It is a document that helps to set the right level of ambition. The requirements strategy describes what tasks are involved in requirements management, how requirements development should work and how to follow up and document requirements work. The requirements strategy is then input into the requirements plan.

A requirements strategy may concern a system or a maintenance object and describes who does what, how, when and why on a general level. On the other hand, a requirements plan is more detailed and describes only one situation, for example one release of a system. In smaller systems the plan may apply to all releases for the coming year.

A good requirements strategy should typically cover three areas: requirements management, requirements development, and monitoring and documentation of requirements.

The requirements management section describes the tasks performed by the requirements manager. It typically includes sections describing:
– How planning of requirements is done
– How to conduct risk analysis
– How to handle versions of requirements and requirements documents
– Traceability between requirements, test cases and bug reports
– Prioritization and validation of requirements
– Approval process for requirements
– Change Management

The requirements development section typically describes:
– The organization’s requirements management process
– How to conduct business analysis and in which areas it should be done
– Which requirements gathering techniques are available and when they are best used
– How to develop and detail requirements at different levels

The monitoring and requirements documentation section describes:
– How to document requirements
– The document templates that exist and what tools are used
– Any metrics that should be used

The requirements strategy is at a general level and has to be adapted to the context, for example for a specific release. This may mean dropping some requirements gathering techniques that do not suit the individual project, or not doing risk analysis in situations when it’s already made by central IT department for all IT systems. It is important to clearly justify deviations from the requirements strategy. Additionally, make sure to get approval by the appropriate person in the organization.

The Requirements plan describes the requirements work of this assignment

When there is a requirements strategy, you can focus on creating a requirements work plan for the current release. The plan describes the requirements areas included in the release, which requirements analysts who will work with the requirements areas, which stakeholders they will cooperate with, and the schedule of the work to be performed. A requirements plan corresponds to a test plan for test work and it can be seen as a project plan for requirements management. The requirements work plan describes who should do what and when to do it.

If you even need to mention the requirements strategy in the requirements plan it is probably to describe the deviations you make and why you have decided to make these deviations from the established requirements strategy. When a requirements strategy exists you can quickly produce a requirements plan.

Just as you expect that project managers anchor the project plan, it is important to anchor your requirements plan with its stakeholders. Stakeholders can be the project manager, business representatives, requirements analysts, development team and testing team, but of course there may be others that you also need to identify who are also affected by your requirements plan. If your requirements plan is anchored and accepted everyone knows what you will deliver and the feedback you will have received on the content will have led to a better requirements plan.

Executing the requirements job

Once the requirements plan is done, it is time to begin the real requirements analysis. Based on the established requirements plan, you work through area after area of ​​requirements. Obviously, situations arise where the requirements plan needs to be updated and adapted to a changed reality. But you handle these changes with the help of incident reporting and by ensuring that your stakeholders are aware of the change that is needed in the requirements plan.

Handover of requirements to maintenance

In many organizations it is very important that when requirements management is completed, it is handed over to maintenance. The requirements manager’s job is not completed before the requirements are submitted to and accepted by the recipient. Handover to the maintenance team means that you as requirements manager need to have ensured early on that you have someone to deliver the material to. The recipient should have been participating or had insight into the requirements management. Both you and the recipient have to agree on which documents to be submitted, the format of the documents, and in what way the content of the material is to be reviewed in order to be accepted. The plan for the handover needs to be included in the schedule in the requirements plan together with handover criteria. The recipient makes the decision when the requirements are handed over. If the recipient does not agree that the material is delivered in a proper way, it’s not. This is important because otherwise chances are high that the requirements will not be managed and serve as a basis for future changes.

Structure and planning will help you do a better job

It is easier to focus on requirements analysis if you have determined the rules for how to carry out a requirements analysis and plan structure for the implementation of the assignment. If we do not have to reinvent the wheel and decide what requirements analysis means to us, if we can expect that requirements already exist and are at a good level that we can continue to develop, if we know how the requirements process looks like, we can focus on performing requirements analysis for the different requirement areas at the right time with the right resources in an expected and controlled way.
We benefit from thinking ahead. This increases the probability that the work will be easy and painless. Thinking and planning ahead gives you more time to build the system that the business needs while reducing the risk of errors in requirements.

Generally speaking, one can say that mature companies spend 30% of the total project time on requirements engineering. And you? How much time you spend engineering your requirements?

To be able to handle the requirements in a structured way, you will need a specialized tool. Are you still using Word or Excel as a requirements management tool? Take a look at ReQtest, the cloud-based solution for managing both requirements and testing.