Agile Requirements Modeling: Strategies for Agile Teams

Table of Contents

1. Agile requirements modeling in a nutshell
   • Initial requirements envisioning
   • Iteration modeling
   • JIT model storming
   • Acceptance test-driven development (ATDD)
2. Where do requirements come from?
3. Core practices
4. Types of requirements
5. Potential requirements artifacts
6. Techniques for eliciting requirements
7. Common requirements modeling challenges
8. Agile requirements change management

1. Agile Requirements Modeling in a Nutshell

Figure 1 depicts the Agile Model Driven Development (AMDD) lifecycle, which depicts how Agile Modeling (AM) is applied by agile software development teams. The critical aspects which we’re concerned about right now are initial requirements modeling, sprint modeling, model storming, and acceptance test-driven development (ATDD). The fundamental idea is that you do just barely enough modeling at the beginning of the project to understand the requirements for your system at a high level, then you gather the details as you need to on a just-in-time (JIT) basis.

Figure 1. The AMDD lifecycle (click to enlarge).

1.1 Initial Requirements Modeling

At the beginning of an initiative you need to take several days to envision the high-level requirements and to understand the scope of the release (what you think the system should do). Your goal is to get a gut feel for what the effort is all about, not to document in detail what you think the system should do: the documentation can come later, if you actually need it. For your initial requirements model my experience is that you need some form of:

1. Usage model. As the name implies usage models enable you to explore how users will work with your system. This may be a collection of essential use cases on a Unified Process (UP) team, a collection of features for a Feature Driven Development (FDD) tea , or a collection of user stories for an Extreme Programming (XP) team, or any of the above on a Disciplined Agile team.
2. Initial domain model. A domain model identifies fundamental business entity types and the relationships between then. Domain models may be depicted as a collection of Class Responsibility Collaborator (CRC) cards, a slim UML class diagram, or even a slim data model. This domain model will contain just enough information: the main domain entities, their major attributes, and the relationships between these entities. Your model doesn’t need to be complete, it just needs to cover enough information to make you comfortable with the primary domain concepts.
3. User interface model. For user interface intensive solutions you should consider developing some screen sketches or even a user interface prototype.

What level of detail do you actually need? My experience is that you need requirements artifacts which are just barely good enough to give you this understanding and no more. For example, Figure 2 depicts a simple point-form use case. This use case could very well have been written on an index card, a piece of flip chart paper, or on a whiteboard. It contains just enough information for you to understand what the use case does, and in fact it may contain far too much information for this point in the lifecycle because just the name of the use case might be enough for your stakeholders to understand the fundamentals of what you mean. Figure 3, on the other hand, depicts a fully documented formal use case. This is a wonderful example of a well documented use case, but it goes into far more detail than you possibly need right now. If you actually need this level of detail, and in practice you rarely do, you can capture it when you actually need to by model storming it at the time. The longer your team goes without the concrete feedback of working software, the greater the danger that you’re modeling things that don’t reflect what your stakeholders truly need.

Figure 2. A point-form use case.

Figure 3. A detailed use case.

1.2 Sprint Modeling

Sprint modeling is part of your overall sprint planning efforts performed at the beginning of an sprint. You often have to explore requirements to a slightly more detailed level than you did initially, modeling just enough so as to plan the work required to fulfill a given requirement.

1.3 Model Storming

Detailed requirements are elicited, or perhaps a better way to think of it is that the high-level requirements are analyzed, on a just in time basis. When a developer has a new requirement to implement, perhaps the “Enroll in Seminar” use case of Figure 2, they ask themselves if they understand what is being asked for. In this case, it’s not so clear exactly what the stakeholders want, for example we don’t have any indication as to what the screens should look like. They also ask themselves if the requirement is small enough to implement in less than a day or two, and if not then the reorganize it into a collection of smaller parts which they tackle one at a time. Smaller things are easier to implement than larger things.

To discover the details behind the requirement, the developer (or developers on teams which take a pair programming approach), ask their stakeholder(s) to explain what they mean. This is often done by sketching on paper or a whiteboard with the stakeholders. These “ model storming sessions” are typically impromptu events and typically last for five to ten minutes (it’s rare to model storm for more than thirty minutes because the requirements chunks are so small). The people get together, gather around a shared modeling tool (e.g. the whiteboard), explore the issue until their satisfied that they understand it, and then they continue on (often coding). Extreme programmers (XPers) would call requirements modeling storming sessions “customer Q&A sessions”.

In the example of identifying what a screen would look like, together with your stakeholder(s) you sketch what the want the screen to look like, drawing several examples until you come to a common understanding of what needs to be built. Sketches such as this are inclusive models because you’re using simple tools and modeling techniques, this enabling the Agile Modeling (AM) practice of Agile Stakeholder Participation. The best people to model requirements are stakeholders because they’re the ones who are the domain experts, not you.

For a detailed example of how to go about requirements modeling, read the article Agile Requirements Modeling Example.

1.4 Acceptance Test Driven Development (ATDD)

Test-driven development (TDD) (Beck 2003; Astels 2003), is an evolutionary approach to development which that requires significant discipline and skill (and good tooling). The first step is to quickly add a test, basically just enough code to fail. Next you run your tests, often the complete test suite although for sake of speed you may decide to run only a subset, to ensure that the new test does in fact fail. You then update your functional code to make it pass the new tests. The fourth step is to run your tests again. If they fail you need to update your functional code and retest. Once the tests pass the next step is to start over (you may first need to refactor any duplication out of your design as needed). As Figure 4 depicts, there are two levels of TDD:

1. Acceptance TDD (ATDD). With ATDD you write a single acceptance test, or behavioral specification depending on your preferred terminology, and then just enough production functionality/code to fulfill that test. The goal of ATDD is to specify detailed, executable requirements for your solution on a just in time (JIT) basis. ATDD is also called Behavior Driven Development (BDD).
2. Developer TDD. With developer TDD you write a single developer test, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test. The goal of developer TDD is to specify a detailed, executable design for your solution on a JIT basis. Developer TDD is often simply called TDD.

Figure 4. How ATDD and developer TDD fit together.

2. Where Do Requirements Come From?

Your stakeholders – direct or indirect users, managers, senior managers, operations staff members, support (help desk) staff members, testers, developers working on other systems that integrate or interact with your, and maintenance professionals – are the only OFFICIAL source of requirements (yes, developers can SUGGEST requirements, but stakeholders need to adopt the suggestions). In fact it is the responsibility of stakeholders to provide, clarify, specify, and prioritize requirements. Furthermore, it is the right of stakeholders that developers invest the time to identify and understand those requirements. This is concept is critical to your success as an agile modeler – it is the role of stakeholders to provide requirements, it is the role of developers to understand and implement them.

Does that imply that you sit there in a stupor waiting for your stakeholders to tell you what they want? No, of course not. You can ask questions to explore what they have already told you, arguably an analysis activity, motivating them to specify in greater detail what they want and perhaps even to rethink and modify their original requirement(s). You can suggest new requirements to them, the key word being SUGGEST, that they should consider and either accept (perhaps with modifications) or reject as an official requirement. To identify potential requirements you may also, often with the aid of your stakeholders, work through existing documents such as corporate policy manuals, existing legacy systems, or publicly available resources such as information on the web, books, magazine articles, or the products and services of your competitors. Once again, it is your stakeholders that are the ultimate source of requirements, it is their decision and not yours. I cannot be more emphatic about this.

Where do your stakeholders get ideas from? They will often have pet peeves about the existing environment, “I really wish we could do this.”, will see things that their competitors can do that they can’t, may want to avoid problems that they’ve experienced in the past with other systems, or may simply have a vision for a new feature. Some stakeholders, in particular operations staff and senior IT management, may have requirements based on the need to integrate with existing or soon-to-be existing systems or requirements motivated by an IT strategy such as reducing the number of computing platforms within your organization. The point to be made is that your stakeholders should be formulating requirements based on a wide range of inputs, something that you may want to ensure is happening by asking questions.

I have often found that there is significant value in involving someone with a relevant expertise to the system that I am building to help identify potential requirements for my system. For example, in the case of an e-commerce system I would likely want to bring in someone with international design experience, tax law expertise, or logistics expertise. This approach is particularly valuable when your organization is building a system that includes aspects that it is not familiar with, perhaps your e-commerce system is your first attempt at serving international customers. I’ll often bring external experts in for a day or two and with several stakeholders “pick their brains” for relevant issues that we may be missing due to our inexperience. It’s a great way to make sure we’re covering our bases, particularly when we are defining the initial scope for the initiative, and to get stakeholders thinking beyond their current environment. However, recognize that there is a danger with this approach – your external experts may suggest ideas that sound good but aren’t actually required right now. In other words, you still need to work through a suggestion from an outside expert just as you would any other.

3. Core Practices

There are several “best practices” which should help you to become more agile with your requirements modeling efforts:

1. Stakeholders actively participate
2. Adopt inclusive models
3. Take a breadth-first approach
4. Model storm details just in time (JIT)
5. Prefer executable specifications over static documentation
6. Your goal is to implement requirements, not document them
7. Create platform independent requirements to a point
8. Smaller is better
9. Question traceability
10. Explain the techniques
11. Adopt stakeholder terminology
12. Keep it fun
13. Obtain management support
14. Turn stakeholders into developers
15. Treat requirements like a prioritized stack

4. Types of Requirements

I’m a firm believer in separating requirements into two categories:

1. Behavioral. A behavioral requirement describes how a user will interact with a system (user interface issues), how someone will use a system (usage), or how a system fulfills a business function (business rules). These are often referred to as functional requirements.
2. Non-behavioral. A non-behavioral requirement describes a technical feature of a system, features typically pertaining to availability, security, performance, interoperability, dependability, and reliability. Non-behavioral requirements are often referred to as “non-functional” requirements due to a bad naming decision made by the IEEE (as far as I’m concerned non-functional implies that it doesn’t work).

It’s important to understand that the distinction between behavioral and non-behavioral requirements is fuzzy – a performance requirement describing the expected speed of data access is clearly technical in nature but will also be reflected in the response time of the user interface which affects usability and potential usage. Access control issues, such as who is allowed to access particular information, is clearly a behavioral requirement although they are generally considered to be a security issue which falls into the non-behavioral category. Loosen up a bit and don’t allow yourself to get hung up on issues such as this. The critical thing is to identify and understand a given requirement, if you mis-categorize the requirement who really cares?

5. Potential Requirements Artifacts

Because there are several different types of requirements, some or all of which may be applicable to your situation, and because each modeling artifact has it’s strengths and weaknesses, you will want to have several requirements modeling artifacts in your intellectual tool kit to be effective. Table 1 summarizes common artifacts for modeling requirements, artifacts that are described in greater detail in the article Artifacts for Agile Modeling. The type(s) of requirement that the artifact is typically used to model is indicated as well as a potential “simple” tool that you can use to create the artifact (the importance of using simple tools was discussed earlier in the section Some Philosophy).

Table 1. Candidate artifacts for modeling requirements.

An important thing to remember is that although there are several artifacts that you can potentially use for requirements gathering that doesn’t mean that you need to use all of them on any given initiative. You should understand when it is appropriate to use each artifact, knowledge that enables you to follow the practice Apply The Right Artifact(s) to your situation at hand.

The underlying process often motivates artifact choice. On the home page I indicate that AM is used in conjunction with another process, such as Scrum, Kanban, or SAFe. Very often the underlying process will prefer certain primary requirements artifact(s), an issue that you must consider when requirements modeling.

6. Techniques for Eliciting Requirements

There are several techniques for eliciting requirements, summarized in Table 2. Each technique has trade-offs, the implication is that you’ll need to learn several if you want to become adept at eliciting requirements, and each can be applied in both an agile and non-agile manner (I suggest that you keep it as agile as possible).

Table 2. Requirements elicitation techniques.

7. Common Requirements Modeling Challenges

To be agile at requirements modeling you need to be in a situation where it is possible to succeed, and for many teams this unfortunately is not the case. Very often requirements modeling efforts are undermined by your environment – it is common to discover that an organization’s culture isn’t conducive to effective software development efforts or stakeholders do not understand the implications of their decisions. In this section I identify common problems that many development teams face when it comes to requirements modeling and discuss potential solutions for dealing with those problems. These common challenges (follow the links to find out how to overcome them) are:

1. Limited access to stakeholders
2. Geographically dispersed stakeholders
3. Stakeholders do not know what they want
4. Stakeholders change their minds
5. Conflicting priorities
6. Too many stakeholders want to participate
7. Stakeholders prescribe technology solutions
8. Stakeholders are unable to see beyond the current situation
9. Stakeholders are afraid to be pinned down
10. Stakeholders don’t understand modeling artifacts
11. Developers don’t understand the problem domain
12. Stakeholders are overly focused on one type of requirement
13. Stakeholders require significant formality regarding requirements
14. Developers don’t understand the requirements

8. Agile Requirements Change Management

Agile software development teams embrace change, accepting the idea that requirements will evolve throughout an initiative. Agilists understand that because requirements evolve over time that any early investment in detailed documentation will only be wasted. Instead agilists will do just enough initial modeling to identify their scope and develop a high-level schedule and estimate; that’s all you really need early on, so that’s all you should do. During development they will model storm in a just-in-time manner to explore each requirement in the necessary detail.

Because requirements change frequently you need a streamlined, flexible approach to requirements change management. Agilists want to develop software which is both high-quality and high-value, and the easiest way to develop high-value software is to implement the highest priority requirements first. Agilists strive to truly manage change, not to prevent it, enabling them to maximize stakeholder ROI. Your software development team has a stack of prioritized requirements which needs to be implemented – XPers will literally have a stack of user stories written on index cards. The team takes the highest priority requirements from the top of the stack which they believe they can implement within the current iteration. Scrum suggests that you freeze the requirements for the current iteration to provide a level of stability for the developers. If you do this then any change to a requirement you’re currently implementing should be treated as just another new requirement.

Figure5 overviews the agile approach to managing the work items potentially needed to be accomplished by the team (you may not actually have sufficient time or resources to accomplish all items). This strategy reflects the risk-value approach promoted by the Disciplined Agile (DA) tool kit. This approach to work management which is an extension to the Scrum methodology’s Product Backlog approach to requirements management. Where Scrum treats requirements like a prioritized stack, DAD takes it one step further to recognize that not only do you mplement requirements as part of your daily job but you also do non-requirement related work such as take training and review work products of other teams. New work items, including defects identified as part of your user testing activities, are prioritized by your stakeholders and added to the stack in the appropriate place. Your stakeholders have the right to define new requirements, change their minds about existing requirements, and even reprioritize requirements as they see fit. However, stakeholders must also be responsible for making decisions and providing information in a timely manner.

Figure 5. Agile requirements change management process.

Developers are responsible for estimating the effort required to implement the requirements which they will work on. Although you may fear that developers don’t have the requisite estimating skills, and this is often true at first, the fact is that it doesn’t take long for people to get pretty good at estimating when they know that they’re going to have to live up to those estimates. For more information, read Agile Change Requirements Management.