Managing Complex Requirements - Part 4

In Part-3 of this series, we discussed a simple anatomy of business requirements and raised couple of questions – ‘Is it enough if we focus on INVEST in large projects? What else should we do in order to manage complex requirements?’    In this post, I will share my thoughts and some takeaways.

Severability:  Severability of a user story (or user case or a piece of requirement) is an indicator of the level of connectedness or interdependency it has with other user stories or epics.  High severability indicates that a user story can be developed and deployed anytime in the development cycle in any iteration.  Low severability indicates high level of connectedness or dependency.  Obviously, developing and deploying user stories with low severability requires significant amount of planning, dependency resolution and regression testing.

How does severability relate to complexity?  Let me try to answer.  If you have an epic or user story with high severability and if it is complex, it is relatively easier to deal with it.  You can design, develop, test and deploy by budgeting extra time for analyzing and understanding the complex requirement and designing appropriate test scenarios.  You can treat that as a separate release comprising of two or more iterations.  Presumably, there will be very little or no rework on the rest of the system.

On the other hand, if you have to deal with a complex user story or epic with medium or low severability, you will find it very challenging. This is because you need to understand all dependencies, resolve them and sequence the development activities (and make it part of your ongoing prioritization exercise). When you ignore this, you accumulate technical debt. This can lead to significant refactoring at a later stage.

When you do iterative and incremental development using Agile methods, you need to understand the severability of epics and user stories and manage dependencies by means of proactive architecture or design, backlog prioritization and release planning.  Project teams will be able to identify a greater number of user stories that can be constructed and tested with minimum need for rework  or impact on related stories when

1. Architecture and design trade-offs, other decision making, and issue resolutions happen in a timely manner and architecture sub-systems are mature enough,
2. Release planning is effective, and
3. Prioritization of backlog is based on business needs as well as dependencies.

In a way, this approach can improve our ability to deliver user stories or features as individual (and independent) components or apps.

So, what are the takeaways?

1. Build architecture and design components or sub-systems and mature them iteratively as early as you can. Avoid procrastination.  In the name of ‘Agile’ do not let all aspects of your technical components (or sub-systems) emerge all the time until you complete the final iteration.
2. Validate if user stories can include all related NFRs in your project.  In some projects this may not be possible. In that case, you will have to plan for technical stories to address NFRs at regular intervals to suit your release plan.
3. At iteration level, focus on INVEST.  At release level or product roadmap level, focus on everything else discussed in this blog series.  If your project is large, consider disciplined or structured parallel agile development teams working at multiple levels such as features, design/architecture, independent verification etc.
4. Focus on proactive grooming and creating INVEST stories for upcoming iterations. If user stories are volatile inside iterations, find ways to improve grooming sessions.  With multiple parallel small teams moving forward in sustainable pace, you will need the right number of teams working on identifying and creating user stories for upcoming iterations.
5. Identify complex requirements and come up with techniques to deal with them. Complex requirements will need extra grooming expertise and efforts as compared to other requirements. Resolve dependency issues of complex requirements. Follow techniques such as TDD, ATDD, or BDD and ensure high level of collaboration with business at the time of development, testing and acceptance.

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!

 

Managing Complex Requirements - Part 3

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. In Part-2 of this series, I shared a classification scheme and potential opportunities or advantages.  In Part-3 we will discuss about some basics and connect with what is happening in the Agile world.   I am planning to end this series with Part-4 and share some takeaways.

Anatomy of Business Requirements:  At a broad level, business requirements can be categorized as functional and non-functional requirements.  That is a simple categorization for this discussion and it holds true in most cases.  A major source of business requirements in product development organizations is market demands - also known as market requirements.

There are many types of non-functional requirements as shown in this diagram - you can add Security, Compliance, etc. to the list.  If there are more, let me know through your comments.



In Agile world, team members are getting habituated to visualizing requirements as user stories. That is ok. However, understanding this simple classification or categorization of requirements is a fundamental need.

In small projects it may be possible to define non-functional requirements (NFR) along with user stories so that each user story carries related NFR as well. However, in large projects or programs attempting to define NFRs with user stories is not sufficient to cover all NFRs.  You will need to create technical stories to address or cover system level NFRs.

Complexity can be on either side – functional or non-functional. Functional complexity can be dealt with in several ways or means - e.g., close collaboration with business users, requirements workshops, prototyping, POCs, active feedback, early acceptance etc. Complexity in non-functional requirements poses different kind of challenges. There are ways to deal with such challenges.   For example, architecture patterns, design patterns, code optimization techniques, tool selection, test strategy and so on help us in many of these non-functional areas.

So, what is the point?  It is obvious. Understand where you anticipate complexity and deal with it.  It is about anticipation, awareness and action planning.



In Agile projects, we talk about epics and user stories.   Functional requirements are either explicitly or implicitly seen as a group of epics belonging to individual modules.  Epic is a large business case or scenario. It is broken into multiple user stories.  We all know that.  However, let me tell you, when you attempt to draw a diagram like this for an enterprise agile project, it is not going to be clear and simple like this one!  This is because a good number user stories can be interrelated.

So, what?  Understand the relationships among epics and user stories.  You may come across situations wherein user stories are related to each other. Remember use cases and their relationships - a) includes and b) extends. Similar relationships can exist among epics and user stories.  This will help you further understand the complexity in terms of such relationships and dependencies.

INVEST is a popular acronym in agile world.  INVEST stands for Independent, Negotiable, Valuable, Estimatable, Small and Testable.  User stories that satisfy these six properties enable project teams in creating software that satisfies acceptance criteria and delivers business value.  You will find more information on INVEST in Chapter 2 ‘Writing Stories’ of User Stories Applied for Agile Software Development.  Click this link to download the free PDF of this chapter.

Now, the questions are, ‘Is it enough if we focus on INVEST in large projects? What else should we do in order to manage complex requirements?’  I will share some thoughts and answer this in the next part. That is going to be the final part in this series.

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!

Managing Complex Requirements - Part 2

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:

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!

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!