What are complex requirements? How challenging is managing them? How can we succeed in managing complex requirements? This is what I am planning to cover in this blog series. In Part-1of this series, I shared my thoughts analyzing and understanding requirements in terms of factors such as complexity, stability, clarity, and availability. That is the first step.
The next step is to come up with a classification scheme for such factors. For example, requirements can be classified as simple, medium or complex in terms of complexity. There are scientific approaches to derive and define this classification.
Stability of requirements can be classified in to three levels. In every project you will find requirements that are very stable – the number of such requirements will vary from project to project. For example, in reengineering projects, a vast majority of requirements will be stable requirements whereas in new product development, the number of stable requirements will be very low and the number of volatile requirements will be very high.
Clarity is about understandability as well as testability of requirements at the initial stage of their availability. Requirements that are ambiguous will require considerable communication and coordination efforts in order to refine and make them clear.
Availability is about the availability of subject matter experts or business users who know the business problem very well and can help you define and refine requirements. In Agile world, this is about the availability of product owners and related business users who are going to assist the product owner in identifying and prioritizing product backlog, identifying Sprint backlog , grooming user stories, defining acceptance criteria, attending product demos and accepting user stories.
When we apply this classification, we get an opportunity to group requirement under different segments. When we do this,
1) Team members’ perception on ‘managing complex requirements’ will move closer to reality. There will no longer be a nagging feeling of complexity everywhere.
2) Project managers can identify risks related to requirements and arrive at mitigation plans for such risks.
3) Program managers or senior leaders can identify the right set of requirements that can be assigned to remote or virtual teams and assign requirements that belong to the other end of spectrum to teams that are co-located with business users.
4) Product owners can take proactive measures in requirement analysis, elicitation, grooming etc. and eliminate the anti-pattern of grooming of users stories within iterations.
So, what is the point? Requirement prioritization is necessary but not sufficient. In Agile parlance, prioritization and reprioritization of product backlog is necessary but not sufficient. Managing requirements by analyzing and understanding them in terms of factors such as complexity, stability, clarity, and availability will make product backlog management effective especially in large, complex projects or programs.
In addition to this, we need effective dependency management in order to create release plans. Isn't it? This post must have triggered some interesting thoughts and questions in your mind. Please feel free to share and we will discuss.
In Part-3 of this series, I am going to share some more critical factors to be considered while managing complex requirements.
Other Posts on Requirements Engineering: