|
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.
I begin this article by arguing that the role of
analysts on software development projects needs to
evolve. A discussion of what I believe “agile
analysis” is follows, and finally I suggest modeling
artifacts appropriate to agile analysis efforts.
This section has been replaced with
Rethinking the Role of Business Analysts. The
basic idea is that traditional business analysts are a
good idea for traditional/serial project teams but
questionable for agile project teams. What you
really want is someone with analysis skills who can help
transfer those skills to other team members, you don't
want someone who only specializes in business analysis.
A business analyst may also take on the role of
stakeholder/customer on an agile project if actual
stakeholders aren't readily available. They may
also lead an
initial requirements envisioning effort during
Iteration 0.
Let’s begin by describing what
agile analysis isn’t:
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
communication rich.
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
Active
Stakeholder Participation practice wherever
possible.
-
Agile analysis is highly
iterative.
As Martin
(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
incremental. Martin
(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
days.
-
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
estimation and prioritization of
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
good enough.
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
documents. Such
artifacts are typically far from perfect, they just
barely fulfill their purpose and no more.
Here is my definition for agile
analysis:
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 prioritize the
functionality, and in the process optionally producing
artifacts that are
just barely good enough.
4. Analysis Through the
Lifecycle
Figure 1 depicts the
lifecycle of
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
by
modeling storming throughout
the iteration. Analysis is
so important to agilists that we
do it every day.
Figure
1.
The Agile Model Driven
Development (AMDD) lifecycle for
software projects.
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
an artifact.
It is interesting to note that this list is meant to be
representative, a more thorough list is presented in the
article Artifacts
for Agile Modeling and in the book
Agile
Modeling.
Table 1.
Candidate artifacts for analysis modeling.
|
Artifact
|
Simple Tool
|
Description
|
| Activity
Diagram |
Whiteboard |
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
Diagram |
Whiteboard |
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. |
| Constraint
definition |
Index card |
A constraint is a restriction on the degree of
freedom you have in providing a solution.
Constraints are effectively global requirements
for your project. |
| CRC
model |
Index cards |
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) |
Whiteboard |
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) |
Whiteboard |
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 diagrams. |
| Flow
chart |
Whiteboard |
Flow charts are used in a similar manner to
activity diagrams. |
| Robustness
diagrams |
Whiteboard |
Robustness diagrams can be used to analyze usage
scenarios to identify candidate classes and major
user interface elements (screens, reports, ...). |
| Sequence
diagram |
Whiteboard |
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 logic. |
| State
chart diagram |
Whiteboard |
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 |
Paper |
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. |
| UI
prototype |
Whiteboard |
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
people. |
| Usage
scenario |
Index card |
A usage scenario is exactly what its name
indicates – the description of a potential way
that your system is used. |
| Use
case diagram |
Whiteboard |
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. |
The nature of
analysis has changed.
Several decades ago analysis was seen as a
transformational process within a serial project
lifecycle. With
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
again. Today
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
generalizing specialists.
I’d like to acknowledge the input on the
Agile
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.
 |
|
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. |
 |
|
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 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. |
I actively work with clients around the world to
improve their information technology (IT) practices as
both a mentor/coach and trainer. A full description of
what I do, and how to contact me, can be
found here.
You may be interested in my two-day
Agile Requirements Workshop: Something Old, Something
New, Something Borrowed, Nothing Blue.
|
