Why is a requirements strategy of help to me?

To clarify why a requirements strategy is important, here are examples of problems that can occur if there is no documented strategy.

Very different requirements strategies

You are assigned to work as requirements manager and will work with a number of existing systems. You find that in one of the systems the requirements are on a very detailed level, in another system the requirements are on a higher level and in a third there are no documented requirements whatsoever. How should you behave in this situation? What level should you choose for your assignment? How will you ensure that you understand the requirements when the documented knowledge about the requirements is at such different levels?

What do you do if you have been assigned responsibility for leading the requirements work, and there is no requirements strategy for your business? Here are some of the most common situations and how a requirements strategy might be of help.

No requirements strategy

You create a requirements strategy for the assignment without having something to start from. How many times have other requirements managers done the same thing earlier for their assignments? Is this really the best use of your time, reinventing the wheel?

If an established requirements strategy were already in existence, it is likely that the system would have had a reasonably similar level of requirements documentation. Then it would have been easier to get acquainted with what was already done and to define the borders of this new assignment. The requirements strategy should make it easy to clearly set the right level of detail for the requirements in this assignment. There is a high probability that the requirements should be on the same level as previously developed requirements.

Reuse an old requirements strategy

You reuse a requirements strategy written by one of your colleagues for a previous assignment. But does it really fit your current assignment? Perhaps it has already been tweaked and surely decisions have been made based on the previous assignment that you are not aware of. And was the requirements strategy really that good from the beginning?

A requirements strategy automatically provides a set of decisions about how requirements gathering is to be done in your organization, so you do not have to think about what is applicable or invent your own routines. Instead you can focus of what is relevant to your current assignment. You still have to choose what requirements gathering techniques to use of the ones that are available. When it comes to prioritizing requirements you have to choose what is most appropriate in this particular case. The requirements strategy guides you but you will still have to decide how to use it.

New in the role

You are brand new as a requirements manager and have no previous experience in planning and managing requirements. Your boss has asked you to do it because you seem to have some free time. How do you choose the right requirements gathering and prioritization techniques to use? What is an appropriate level of details to document requirements? Is the challenge too big and the threshold slightly too high?

A requirements strategy helps you to realize what it is to be done and what is expected of the role. The strategy makes it possible to focus on managing requirements instead of trying to find out what the role entails and how to do the job.

Practical benefits of the requirements plan

Here are some typical problems in which a requirements plan can be helpful.

Missed requirements

You have completed the requirements management phase and the requirements team is long gone and working on other assignments. Now you hear from business representatives that some requirements areas were completely missed. Why did you not get information about these areas earlier?

A requirements plan forces you to analyze what requirements areas are included in the assignment. You must also determine your stakeholders. Since the requirements plan is anchored by its stakeholders you will get help to ensure that no requirements area is missed. The plan will also help you to ensure that no stakeholder is missed.

Requirements are badly ordered

You have started with easier requirements areas to get comfortable in your role. When you start handing over requirements areas to development, it becomes clear that they are delivered in the wrong order. The more complex areas are not even started on and other areas are linked to other not started areas to be worthwhile to start working with them. How could you have foreseen this?

Again, analysis of requirements and anchoring the areas with the stakeholders early on would had given you feedback on applicable order in which the various stakeholders had wished the requirements to be delivered. This because some of your stakeholders, are architects, developers and testers that have specific requirements. With this knowledge you had been able to adjust the order of the requirements analysis in order to meet all the different needs that exist and create a common plan that all could accept.

Requirements gathering will take longer than expected

You have begun the requirements analysis phase. You notice that the work is taking longer than expected and that you therefore will not be able to catch everything. Was it possible to see that the need was greater than you had planned for and therefore that there was no possibility to meet the planned time?

Scheduling in conjunction with deciding the requirements areas is the key to success. This work will help you to see how many requirements analysts needed, combined with how long it will take to perform requirements analysis of the different areas. The risk to misjudge the number of resources needed is reduced by proper planning before starting work.

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 and witness a world of difference!