Requirements

This section introduces tips that support an agile, rapid, evolutionary approach to requirements, in addition to those already covered in other chapters, such as XP's Planning Game and story cards. Note that many of the tips emphasize face-to-face communication and "low-tech high-touch" common themes in agile methods.

Agile Modeling

Agile Modeling is a set of values and practices consistent and complementary to all the IID methods, and applicable during requirements analysis. See p. 37 for a summary.

Defining and Keeping the Vision

Establishing and reiterating a common vision is frequent advice from agile leaders. It may seem absurd to highlight such an "obvious" idea, but in over 10 years of post-project reviews with hundreds of project members, Standish Group analysts [Johnson02] did not find even two people who stated the same purpose or vision for their project!

Sometimes the military is used as an example of an unhealthy, rigid management system, but modern battlefield leadership is different. Adaptation to unpredictable battle events (as in agile development) is paramount. Therefore, the leadership emphasizes that fighters know the mission goal or vision, rather than concentrating on a fixed plan.

Microsoft values this as well; it is key in the Microsoft Solutions Framework IID method:

Use high-level vision statements and outline specifications to get projects going.

How? Step one is to form a vision, discussed in some of the following tips, such as creating a vision box and product sheet.

Step two is to reinforce it. Jeff Sutherland, a Scrum founder, emphasizes that one of the key communication responsibilities of the Scrum Master during the daily Scrum meeting is to help the team recall a common project vision aligned with the business objectives.

The Product Vision Box

This is a creative, quick practice to craft a common vision, first created and promoted by Bill Shakelford and Jim Highsmith [Highsmith01], creator of the agile method Adaptive Software Development. The steps are:

1. During day one of the first requirements workshop, break into several small groups. Give each group a box (such as a cereal box).

2. The goal of each group is to create the cover (front and back) of a product box, as though the product were to be sold in a shrink-wrap box.

3. Define and place on the box a name, graphics, a few key front-cover selling points for the front, and details (features, operating requirements, and so on) for the back.

4. Each group presents the results.

5. Coalesce the results into a common Moore-style vision statement or common vision box.

A Moore-Style Vision Statement

The vision boxes can be input to a simple, focused vision statement. In Geoffrey Moore's well-known Crossing the Chasm, he recommends the following format for a vision statement, which has been widely adopted, including within the UP:

For (target customer)

Who (statement of the need or opportunity)

The (product name) is a (product category)

That (key benefit, compelling reason to buy)

Unlike (primary competitive alternative)

Our product (statement of primary differentiation)

Following the agile modeling practice to display models publicly, this statement goes on the wall in large font.

Product Sheets

Marketing and requirements experts in product companies promote the early creation of a product data sheet (feature bullets, comparisons, and so forth). It helps clarify the vision and define high-level requirements; plus, the physical limit (one side of one page) forces prioritization and brevity. However, this practice is not only useful for product developers; it helps teams building internal systems who want a more agile approach to requirements analysis. As with vision boxes, a complementary tip is to have several teams create them in parallel and coalesce the results.

Evolutionary Requirements Workshops

Although requirements workshops are an old idea (also under the banner of JAD Joint Application Design sessions), the iterative and evolutionary approach is to hold several of them, one per iteration during the early iterations, interspersed with programming. Keep them short and timeboxed, such as one or two days. In the first workshop, there is an emphasis on defining a vision and scope, and identifying functions and features at a high level (such as just the names of use cases and features). However, most non-functional requirements (e.g., load, internationalization) need early exploration in detail, as these have a significant architectural impact.

As an example: a project ultimately composed of 20 iterations might hold four requirements workshops across the first four iterations. The goal after four workshops is that 80% or more of the requirements are defined in detail, but in contrast to the waterfall, with the benefit of insight from early programming, evaluation, and feedback. Note also that by the end of the same four iterations, perhaps only 10% of the software is developed.

In the first workshop, for example, the team may discover and name 20 use cases (the same applies if features rather than use cases are used). They now have an estimate that the goal of 80% detailed requirements after four workshops will mean that 16 use cases should be written. Yet, in the first workshop they explore and write only two (i.e., 10%) of the highest risk and most architecturally significant in a detailed use case format. Combined with analysis of the product's nonfunctional requirements, that's usually enough to get started with architectural work and early programming.

Perhaps the second workshop team discovers three new use cases, eliminates two, and writes 8/21 in detail, refining existing ones, and so on. Figure 11.13 illustrates the process.

Figure 11.13. sample completion of artifacts in 5 of 20 iterations.

Include in each workshop developers who spend time working on the software. It is useful to demo and discuss the results of the most recent iteration. Feedback from building some of the software is crucial to refine and evolve the growing requirements.

This is not the only way to stage evolutionary requirements analysis; pipelining (see p. 251) is another.

The art and science of running a successful workshop is well-covered in Requirements by Collaboration: Workshops for Defining Needs by Ellen Gottesdiener.

Tracking Requirements Across Iterations

At the very least, track the lifecycle or status of each request (feature, use case, scenario, bug fix) as they transition through the iterations. XP does status tracking in the simplest way that could possibly work, for example, three piles of cards: "not done," "underway," and "done." Similarly, the Scrum Product Backlog spreadsheet includes a status column.

For use cases that will be completed within one iteration, the use case name is the requirements tracking tag for example, "Handle Returns." On the other hand, when a complex use case has to be built by different scenarios across several iterations, the trackable requirements tag is a scenario name, not a use case name. If Cockburn's (popular) naming style is used, each scenario has a tag such as "3a" or "4c". Thus, the requirement tracking system can track labels such as "Process Sale-main success" or "Process Sale-3a".

Direct User Involvement in Requirements and Product

Research [KC94] shows that project failure is reduced when there is increased direct involvement and links between the ultimate clients or users of a new software product and developers. Plus, as an obvious corollary, fewer indirect links via intermediaries and customer proxies (such as business analysts). There are many techniques explicit within IID methods to support this, such as XP's Whole Team Together (Onsite Customer), UP's requirements workshops, and the Scrum demo to users at each iteration. Another popular practice is to send some developers as trainees in the client or target customer setting.

Use Cases are OK

It is a misunderstanding to equate iterative or agile methods with "no detailed written requirements." That value is unique to XP, and is enabled in XP by the presence of onsite customers in the project room who can verbally explain or create the requirements as needed. The other methods, although all are in favor of avoiding excessive documents, allow or support detailed written requirements, created iteratively and interspersed with early programming.

Unless it is an XP project, when written functional requirements are needed, consider use cases (for example, "Provision a Switch"). XP's promotion of feature-oriented "story card" requirements does not mean use cases are unskillful, or wrong for use in other methods. Note, for example, that the well-known agile methodologist Alistair Cockburn (author of Agile Software Development) is also an expert in and promoter of use cases, and author of Writing Effective Use Cases.

Use cases have the advantage of pulling a set of requirements together organizing them in the context of scenarios of use. Plus, use case scenarios (e.g., "order, and pay with credit card") make excellent goals for an iteration, because by implementing a scenario you are forced to design and build across many architecturally significant components, from the UI to the database, for example. And, you must early on resolve and test the quality requirements (e.g., reliability, usability) associated with the scenarios. That said, use cases don't fit for all products; sometimes a feature-oriented (e.g., "support EJB 2.0") or combination approach is more relevant.

Note that meaningful use case work is not drawing a UML use case diagram, but writing detailed use case text. In a workshop this is best done with a projector, so several people can easily view the text.

A popular approach to writing use cases is described in Cockburn's Writing Effective Use Cases.

Quantification Is OK

In the name of being more agile, do not succumb to being vague or sloppy about the details of quality requirements, such as load, response times, usability, and so forth. Most of these need quantification and means of measurement to be of much use. Evo places special emphasis on this value. "The UI needs to be usable," "The system should be maintainable," "The system needs to have good performance under high load," and so forth. These statements do not suffice, expressed verbally or in writing.

On outsourced projects run with an agile method or otherwise both the client and service provider need quantified and measurable quality requirements written down in order to avoid messy disputes. Although the Agile Manifesto encourages customer collaboration over contract negotiation, it is a fact of life that misunderstandings about the "…ilities" often lead to severe dissatisfaction or law suits. I sometimes serve as an expert witness; it happens.

Agile Manifesto

GUIs with Glue

Another practical agile requirements tip is to first prototype UIs and UI navigation (in collaboration with clients) using paper, pen, sticky notes, and so forth, on a wall. This well-known technique goes by many names, but my favorite is Luke Hohmann's "GUIs with glue." Use large sheets of paper to represent Web pages or windows. Place small blue sticky notes on these sheets to represent information and pink sticky notes for UI controls (e.g., a button).

To quickly model navigation between Web pages or windows, consider sketching a UML statechart on a whiteboard, where the states represent the windows or pages, and the transition events represent the UI navigation gestures (for example, clicking a button). See Figure 11.14.

Figure 11.14. UML statechart sketch for UI navigation

A recommended text on usability engineering is Don't Make Me Think! by Steve Krug; many texts and Web sites cover "GUIs with glue" agile flavored UI prototyping.

Brainstorming

Brainstorming is useful and quick during both requirements and joint planning. Most think they know the technique, but surprising few follow its official and important rule. It is, simply:

When hearing and recording the ideas, no one should comment or laugh.

The facilitator should record, not react. Keep the ideas flowing.

Brainwriting

Brainwriting is a fast adjunct or alternative to brainstorming during a requirements or planning workshop. People are given many index cards or paper scraps. On the topic at hand (e.g., requirements? tasks?), they write a short note on each card as ideas emerge. The cards are collected, and the team does affinity clustering.

Affinity Clustering

Affinity clustering is a rapid technique to dynamically group things such as brainwriting cards into cohesive sets. It is usually done by placing the cards randomly on the floor. The team collaborates to organize the cards into the dynamic sets that emerge, such as "database task cards" or "payment feature cards." The results can be posted in groups on walls, or visualized in a mind map.

Mind Maps

Mind maps are another agile-oriented hand-drawing technique to quickly elicit, organize, and expand high-level requirements during a workshop. Deceptively simple, I'm always impressed by how they help the creative discovery process during rapid requirements analysis (Figure 11.15). When facilitating, I sometimes take the output of a brainwriting and affinity clustering session, and mind-map the result. There are several good Web sites; a classic text on the subject is The Mind Map Book by the founder, Tony Buzan.

Figure 11.15. sample mind map

Team Rotation Writing

Another quick, collaborative technique for requirements or planning is rotation writing. <N> people sit in a circle, each with a laptop computer. For five or ten minutes, they write on the topic at hand (requirements? tasks?). Then they stop and pass their computer to their neighbor, while they themselves receive another computer. The same approach can be achieved with a wireless network and sharable Wiki pages. Each person starts by reviewing the unfamiliar material, and then enhances it, inspired by the new ideas they see. Rotation continues until each person has worked on each computer document. After the meeting, one person receives all the documents, groups and merges the ideas, which are then later reviewed and refined by the whole team together in a second meeting.