Agile software developers, just like traditional software
developers, perform analysis activities. Unlike traditional developers,
agilists approach analysis in a highly collaborative manner and do so on a
just-in-time (JIT) basis. Analysis is so important to us we do it
every single day. In this article, I discuss:
The purpose of analysis is to understand what will be
built, why it should be built, how much it will likely
cost to build (estimation), and in what order it should
be built (prioritization).> This is similar to requirements elicitation, the purpose of
which is to determine what your users want to have
built. The main difference is that the focus of
requirements gathering is on understanding your users
and their potential usage of the system, whereas the
focus of analysis shifts to understanding the system
itself and exploring the details of the problem domain.
Another way to look at analysis is that it
represents the middle ground between requirements and
design, the process by which your mindset shifts from
what needs to be built to how it will be built.
What is agile analysis?
From the previous discussion of what an agile
business system analyst does, your agile analysis
efforts should exhibit the following traits:
Agile analysis should be
Agile developers prefer warm communication
techniques such as face-to-face discussion and video
conferencing over cold techniques such as
documentation and email, as described in the
Communication article. Agile
developers prefer to work as closely as possible to
their project stakeholders, following AM's
Stakeholder Participation practice wherever
Agile analysis is highly
(2002) points out analysis and design activities
both rely on each other: estimating is part of
analysis yet that relies on some design being
performed to identify how something could be
implemented and your design efforts rely on
sufficient analysis being performed to define what
needs to be built.
Hence analysis is iterative.
Agile analysis is
(2002) also correctly points out that agile
analysis is incremental, that you don't need to
build systems all in one go.
This philosophy supports the incremental
approach favored by common agile software processes
where the work is broken done into small, achievable
"chunks" of functionality.
These chunks should be implementable within a
short period of time, often as little as hours or
Agile analysis explores and
illuminates the problem space.
Your primary goal is to identify and
understand what your project stakeholders need of
your system. Furthermore,
this information needs to be communicated to
everyone involved with the project, including both
developers and stakeholders.
This promotes understanding of, and agreement
with, the overall vision of your project.
Agile analysis includes
estimation and prioritization of requirements.
It is during
requirements where software development becomes
“real” for project stakeholders.
It is very easy to say that you want
something but much hard to agree to a price for it,
let alone to trade it off for something that is
immediately more important to you.
Agile analysis results in artifacts that are just
If any artifacts are created at all as the
result of your agile analysis (you'll be following
the AM practice
Discard Temporary Models after all)
they should be either agile models or agile
artifacts are typically far from perfect, they just
barely fulfill their purpose and no more.
Here is my definition for agile
Agile analysis is highly evolutionary and
collaborative process where developers and project
stakeholders actively work together on a
just-in-time (JIT) basis to understand the
domain, to identify what needs to be built, to
estimate that functionality, to
functionality, and in the process optionally producing
artifacts that are
just barely good enough.
Figure 1 depicts the
Agile Model Driven Development
(AMDD). During "iteration
0", the first iteration of
an agile project, you need to
get your project organized and
going in the right direction.
Part of that effort is the
initial envisioning of the
requirements and the
architecture so that you are
able to answer critical
questions about the scope, cost,
schedule, and technical strategy
of your project.
Details about the business
domain are identified on
a just-in-time (JIT) basis
during iterations via initial
iteration modeling at the
beginning of each iteration or
modeling storming throughout
the iteration. Analysis is
so important to agilists that we
do it every day.
The Agile Model Driven
Development (AMDD) lifecycle for
Are the artifacts created taking an
agile approach to analysis any different than the ones
created as the result of traditional analysis?
In a way they are.
They are in fact the same types of artifacts, a
use case diagram is a use case diagram after all, but
the way in which they are created are different.
The artifacts are created following the principles and
practices of AM, they are
just barely good enough and
are often discarded so as to travel light.
Table 1 lists
common artifacts used during analysis modeling and
suggests a simple tool with which you could create such
It is interesting to note that this list is meant to be
representative, a more thorough list is presented in the
for Agile Modeling and in the book
Candidate artifacts for analysis modeling.
UML activity diagrams are used during analysis
modeling to explore the logic of a usage scenario
(see below), system use case, or the flow of logic
of a business process. In many ways activity
diagrams are the object-oriented equivalent of flow
charts and data-flow diagrams (DFDs).
Class diagrams show the classes of the system, their
inter-relationships (including inheritance,
aggregation, and association), and the operations
and attributes of the classes. During analysis
you can use class diagrams to represent your
conceptual model which depict your detailed
understanding of the problem space for your system.
A constraint is a restriction on the degree of
freedom you have in providing a solution.
Constraints are effectively global requirements for
A Class Responsibility Collaborator (CRC) model is a
collection of standard index cards, each of which
have been divided into three sections, indicating
the name of the class, the responsibilities of the
class, and the collaborators of the class.
Like class diagrams, CRC models are used during
analysis modeling for conceptual modeling.
Data flow diagram (DFD)
A data-flow diagram (DFD) shows the movement of data
within a system between processes, entities, and
data stores. When analysis modeling a DFD can
be used to model the existing and/or proposed
business processes that your system will support.
Entity/Relationship (E/R) diagram (data diagram)
E/R diagrams show the main entities, their data
attributes, and the relationships between those
entities. Like class diagrams E/R diagrams can
be used for conceptual modeling, in many ways E/R
diagrams can be thought of as a subset of class
Flow charts are used in a similar manner to activity
Robustness diagrams can be used to analyze usage
scenarios to identify candidate classes and major
user interface elements (screens, reports, ...).
Sequence diagrams are used to model the logic of
usage scenarios. Sequence diagrams model the
flow of logic within your system in a visual manner,
enabling you to both explore and validate your
State chart diagram
State chart diagrams depict the various states, and
the transitions between those states, that an entity
exhibits. During analysis modeling state chart
diagrams are used to explore the lifecycle of an
entity that exhibits complex behavior.
System use case
A use case is a sequence of actions that provide a
measurable value to an actor. A system use
case includes high-level implementation decisions in
it. For example, a system use case will refer
to specific user interface components - such as
screens, HTML pages, or reports. System use
cases will also reflect fundamental architectural
decisions, such as the use of ATMs versus cell
phones to access your bank account.
A user interface (UI) prototype models the user
interface of your system. As a part of
analysis modeling it enables you to explore the
problem space that your system addresses in a manner
that your project stakeholders understand.
Remember, the user interface is the system to most
A usage scenario is exactly what its name indicates
- the description of a potential way that your
system is used.
Use case diagram
The use-case diagram depicts a collection of use
cases, actors, their associations, and optionally a
system boundary box. When analysis modeling a
use case diagram can be used to depict the business
functionality, at a high-level, that your system
will support. It can also be used to depict
the scope of the various releases of your system via
the use of color or system boundary boxes.
Analysis is a very important
activity on any software development project, regardless
of paradigm. It is an organizational design
decision to define what roles you will have and what
those roles will do. In traditional development
there is often someone(s) in the role of analyst, and
some organizations even choose to distinguish between
analyst types and will have system analysts (SAs),
business analysts (BAs), business system analysts (BSAs),
data analysts, process analysts, and so on. In
agile development we make different organizational
design decisions. So, although we still perform
analysis we haven't made the decision to have someone in
that specific role.
The nature of
analysis has changed.
Several decades ago analysis was seen as a
transformational process within a serial project
the rising popularity of object-orientation in the
1980s and 1990s analysis was soon seen as part of an
iterative and incremental process, and in the new
millennia the nature of analysis is transforming once
analysis is better envisioned as a highly
collaborative, iterative, and incremental endeavor
involving both developers and stakeholders.> The evolution of the analysis process necessitates an
evolution in the way that business system analysts
(BSAs) work, and in many situations this role arguably
disappears in favor of developers who are
I'd like to acknowledge the input on the
Modeling mailing list
of the following people: James Bielak, Adam Geras, Ron
Jeffries, Kent J. McDonald, Les Munday, Paul Oldfield,
Stephen Palmer, Tom Pardee, Dave Rooney, Gabriel
Tanase, and Paul Tiseo.