Many traditional project teams run into trouble when they try to define all of the requirements up front, often the result of a misguided idea that developers will actually read and follow what the requirements document contains.  The reality is that the requirements document is usually insufficient, regardless of how much effort goes into it, the requirements change anyway, and the developers eventually end up going directly to their stakeholders for information anyway (or they simply guess what their stakeholders meant).  Agilists know that if they have the ability to elicit detailed requirements up front then they can also do the same when they actually need the information.  They also know that any investment in detailed documentation early in the project will be wasted when the requirements inevitably change.  Agilists choose to not waste time early in the project writing detailed requirements documents because they know that this is a very poor way to work.

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. Best 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, iteration 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.

1.1 Initial Requirements Modeling

At the beginning of a project 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 project 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 Rational Unified Process (RUP) project, a collection of features for a Feature Driven Development (FDD) project, or a collection of user stories for an Extreme Programming (XP) project. 
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 projects 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 project 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 Iteration Modeling

Iteration modeling is part of your overall iteration planning efforts performed at the beginning of an iteration.  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 project 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.

With ATDD you are not required to also take a developer TDD approach to implementing the production code although the vast majority of teams doing ATDD also do developer TDD. As you see in Figure 4, when you combine ATDD and developer TDD the creation of a single acceptance test in turn requires you to iterate several times through the write a test, write production code, get it working cycle at the developer TDD level. Clearly to make TDD work you need to have one or more testing frameworks available to you.  For acceptance TDD people will use tools such as Fitnesse or RSpec and for developer TDD agile software developers often use the xUnit family of open source tools, such as JUnit or VBUnit.  Commercial testing tools are also viable options.  Without such tools TDD is virtually impossible.  There are several important benefits of ATDD.  First, the tests not only validate your work at a confirmatory level they are also in effect executable specifications that are written in a just-in-time (JIT) manner.  By changing the order in which you work your tests in effect do double duty.  Second, traceability from detailed requirements to test is automatic because the acceptance tests are your detailed requirements (thereby reducing your traceability maintenance efforts if you need to do such a thing).  Third, this works for all types of requirements -- although much of the discussion about ATDD in the agile community focuses on writing tests for user stories, the fact is that this works for use cases, usage scenarios, business rules, and many other types of requirements modeling artifacts. The greatest challenge with adopting ATDD is lack of skills amongst existing requirements practitioners, yet another reason to promote generalizing specialists within your organization over narrowly focused specialists.

2. Where Do Requirements Come From?

Your project 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 project stakeholders to provide, clarify, specify, and prioritize requirements.  Furthermore, it is the right of project 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 project 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 project 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 project 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 project 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 project 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 project 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 project 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 project 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 project, and to get project 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. Best 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 project, and because each modeling artifact has it’s strengths and weaknesses, you will want to have several requirements modeling artifacts in your intellectual toolkit 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 project.  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 software process, such as eXtreme Programming (XP) or the Unified Process (UP), whose scope is the full lifecycle.  Very often the underlying process will prefer certain primary requirements artifact(s), in the case of XP user stories and for the UP use cases, an issue that you must consider when requirements modeling.  See the articles  AM and XP and AM and UP for further details.

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 project 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 project 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 project stakeholders

2. Geographically dispersed project stakeholders

3. Project stakeholders do not know what they want

4. Project stakeholders change their minds

5. Conflicting priorities

6. Too many project stakeholders want to participate

7. Project stakeholders prescribe technology solutions

8. Project stakeholders are unable to see beyond the current situation

9. Project stakeholders are afraid to be pinned down

10. Project stakeholders don’t understand modeling artifacts

11. Developers don’t understand the problem domain

12. Project stakeholders are overly focused on one type of requirement

13. Project 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 a project.  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 project scope and develop a high-level schedule and estimate; that’s all you really need early in a project, 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.    

Figure 5 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 approach reflects the Open Unified Process (OpenUP)'s approach to work management which is an extension to the Scrum methodology's approach to requirements management.  Where Scrum treats requirements like a prioritized stack called a product backlog, OpenUP takes it one step further to recognize that not only do you implement requirements as part of your daily job but you also do non-requirement related work such as take training, go on vacation, review products of other teams, and so on.   New work items, including defects identified as part of your user testing activities, are prioritized by your project stakeholders and added to the stack in the appropriate place.  Your project 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. 

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.

9. Recommended Resources

Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.

		The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams.  Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development.  The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD).  The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
		The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with.  These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler.  This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer).  The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.

10. Translations

• Belorussian translation by Patric Conrad
• Chinese translation by Gao Lucky

Let Us Help

We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer.  A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.