Managing Complex Requirements – Part 1

 

What are complex requirements?  How challenging is it to manage them?  How can we succeed in managing complex requirements?  This is what I am planning to cover in this blog series.

So, have you got complex requirements to manage? Here are some high-level things you need to consider.

1. Do your homework - let the creators of requirements (e.g. Business analysts) think through, specify requirements and put them for review before communicating it to a broad set of audience.
2. Create test scenarios with test data -  complex scenarios need illustrations of multiple paths with test data.
3. Conduct walk-through -  walk-through enables collaboration and improves understanding.
4. Facilitate Q&A sessions.
5. Involve the creator (Business analyst or business user) in test case /test data reviews and testing.

Well, these are well-known guidelines.  In spite of these, managing complex requirements continues to be a complex affair.   Why? In most cases it is not about the complexity of requirements. It is about something else. So, it is worth understanding how project teams perceive something as a complex requirement.

In one of my projects, there was a constant issue reported by team members. It was about complex and changing requirements.  When we analyzed the situation we found that only 20% of the requirements were very complex or highly complex. 80% of the requirements were not so complex – they were either simple or medium in terms of complexity – obviously, we had our own approach or mechanism to decide complexity of requirements.

‘So, what is the real issue here? Is it about managing complex requirements?’ I enquired my team members.

‘About 20% of our requirements are complex but in general requirements are not stable. We see changes every other day.’

‘So, is this about ongoing changes to requirements?’

‘There is more to it.  We are not very clear about some of the requirements. So, we ask questions to understand different scenarios. In this process, requirements evolve.’

'What else?’

‘Some of the business users or product owners are very busy. They are not available to answer our questions.  We have to do several follow-ups. That makes things complex.’

‘Oh. Ok. Our issues are because of several factors – complexity of requirements, requirement stability, clarity of different scenarios, and availability of business users or subject matter experts. Is that right?’

‘Yes. That is right.’

That was a learning moment that helped me understand that managing complex requirements is not about complex requirements alone!   That is about the complexity of managing requirements because of factors such as complexity, stability, clarity, availability and so on.

 

One way to manage requirements is to analyze and understand requirements in terms of such factors and deal with them.  How do you manage complex requirements?  How do you do it when you follow Agile methods such as Scrum or XP or DSDM or SAFe or a home-grown method?  In Part-2 of this series, I am going to share some thoughts on how requirements can be categorized and effectively managed from this point-of-view.

 

Other Posts on Requirements Engineering:

1. Changing Requirements: You Have a Role to Play!
2. Requirements Specification: The Weak Links
3. Requirement Engineering: Ten Principles
4. Requirement Engineering: Specifications in which form?
5. Requirement Engineering: Asking Context-Free Questions
6. Requirements Engineering = Elicitation + Analysis and Negotiation + Specification or Documentation + Validation!