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!