Scott is Practice Leader Agile Development, IBM Rational
In This Issue
- How Much Initial Requirements Modeling Should You Do?
- Hot Links
How Much Initial Requirements Modeling Should You Do?
For all the hubbub about communication within the Agile community we appear to be really poor about describing what we actually do in practice. For example, one of the practices that Agile teams commonly follow is to do a bit of high-level requirements modeling at the beginning of a project to help set the overall business direction for the effort. In the Dr. Dobb's 2007 Agile Adoption Survey we found that 77.7 percent of Agile teams were doing this and that of those 86 percent were finding the effort a worthwhile investment. Although the vast majority of Agilists appear to do such modeling it's pretty rare to hear about it. So I thought I'd share some ideas with you about what we actually do in practice.
Initial high-level requirements modeling, along with initial high-level architecture modeling, is one of the strategies promoted by Agile Model Driven Development (AMDD) for scaling agile software development. The quick answer for how much modeling you need to do at the beginning of a project is "just enough". The slightly longer answer is that for the vast majority of projects this is very likely only a few days of effort and perhaps an entire week for more complex situations. The really long answer follows.
One of the nasty realities of software development is that early in the project someone invariably asks questions such as "What are you going to build?", "How much do you think it's going to cost?", "What benefits will be gained?", and "How long do you think it's going to take?" Although these questions are difficult to answer accurately at first, most organizations insist that development teams show that they have a basic understanding of the scope and the financial aspects of their endeavor before they are given significant funding. To address these needs you're going to have to do some initial requirements modeling although that doesn't mean that you need to spend weeks or even months documenting and reviewing the requirements in great detail.
For a business application I would consider do some high-level usage modeling, domain modeling, and some user interface (UI) prototyping. The usage model would likely be composed of a collection of use cases where the important ones would be described with a few bullet points and the less important ones would just be named. The domain model would indicate the major business entity types and the relationships between them but wouldn't get into details such as listing attributes. The UI prototype may be something as simple as paper prototypes or sketches of critical screens/pages or as complex as a working prototype of those screens. The UI is the system to end users, so it's critical to your initial success that you show that you have a viable strategy for implementing a usable UI.
It's important to recognize that you don't need the details, you just need enough information to answer the business questions that you're being asked. If a list of bullet points is good enough for you to make a reasonable guess as to the relative effort of implementing a use case then only capture that information for now. The details, if you ever need them, can be gathered on a Just-In-Time (JIT) basis via model storming during the project. Trying to capture the details behind requirements early in the project is called "Big Requirements Up Front (BRUF)". BRUF can seem like a good idea in theory, but in practice proves to be quite risky because of the high-levels of wastage which it motivates.
Sadly many traditionalists will tell you that you need to model everything up front in detail. They believe this for several reasons. First, that's what they've been trained to do, that's what they've been doing throughout their entire IT careers, and they've been told that working otherwise is ineffective. Second, many people have chosen to specialize in modeling activities and as a result that's what they do because that's their only viable options. Third, they're often forced to create detailed, up front estimates and plans in a misguided attempt to reduce project risk (this strategy inevitably increases project risk because it motivates a host of questionable development activities). Fourth, they're convinced that they can't get access to stakeholders throughout the project, a self-fulfilling prophecy because traditionalists have trained stakeholders over the years that they're only needed during the requirements and user acceptance testing phases. Fifth, many traditionalists, perhaps the majority, don't really believe that BRUF is a good idea but are forced into it by everyone else in the organization. It's interesting that when you get all of the major decision makers together in a single room how quickly people will come to the conclusion that none of them really want to do BRUF but that they thought that everyone else needed to work this way.
There are several potential end products of your initial requirements modeling efforts. First, the initial "requirements stack" that Agilists are always talking about has to come from somewhere, and that somewhere is your initial requirements modeling effort. Second, you might want to invest in the definition of an initial project vision, an idea that both the Rational Unified Process (RUP) and the Project Management Institute (PMI) has promoted for over a decade. A good project vision can be as simple as a few bullet points or a paragraph and shouldn't be any more than a page. Traditional organizations, particularly those that made the mistake of instantiating RUP in a heavy manner, or the advice of the PMI in a heavy manner, will often invest far too much time in vision statements. Don't worry, you can easily choose to create concise project visions which get the job done. Third, because you'll likely need to give presentations to key project stakeholders overviewing the project you'll likely want to create a couple of scope diagrams which describe the business. UML use case diagrams or traditional business process models are usually pretty good at this. If you spend more than a couple of hours sketching these diagrams on a whiteboard and then transcribing them into a tool to pretty them up you've gone too far.
In summary, do just enough initial high-level requirements modeling at the beginning of an Agile software development project. You don't need a lot of detail, nor do you need a lot of documentation, but you do need an initial understanding of the scope. By building an initial vision of what you're going to build, and by addressing fundamental business questions surrounding costs and benefits, you'll quickly put your project on firm ground.
Hot Links
Survey Says... Agile Has Crossed the Chasm summarizes the results of the 2007 Dr. Dobb's Agile Adoption Survey.
Agile Model Driven Development (AMDD) summarizes AMDD and shows how initial modeling fits into the overall picture.
Agile on a Fixed Budget provides strategies for taking an agile approach to development even when the budget, schedule, and or scope is constrained.
For a detailed discussion of initial requirements modeling on agile software development projects -- including examples -- visit www.agilemodeling.com/essays/initialRequirementsModeling.htm.
You can explore architectural issues on software development projects without having to write extraneous documentation. Initial architectural modeling strategies are described at www.agilemodeling.com/essays/initialArchitectureModeling.htm.
Examining the 'Big Requirements Up Front (BRUF) Approach' overviews and discusses evidence as to why comprehensive modeling up front puts your project at risk.
Agile Documentation strategies are described in detail at www.agilemodeling.com/essays/agileDocumentation.htm.
The Agile Alliance homepage is the best starting point for anyone interested in learning more about agile software development.
The Agile Models Distilled page provides links to overviews of a wide variety of models.
The principles of Agile Modeling v2 are described at www.agilemodeling.com/principles.htm.
The practices of Agile Modeling v2 are described at www.agilemodeling.com/practices.htm.
Check out the Agile Modeling mailing list at www.agilemodeling.com/feedback.htm.
