Chapter - 2 The Requirements Process

Project Blastoff

Imagine launching a rocket. 10 – 9 – 8 – 7 – 6 – 5 – 4 – 3 – 2 – 1 – blastoff! If all it needed were the ability to count backward from 10, then even Andorra1 would have its own space program. The truth of the matter is that before we get to the final 10 seconds of a rocket launch, a lot of preparation has taken place. The rocket has been fueled, and the course plotted—in fact, everything that needs to be done if the rocket is to survive and complete a successful mission.

Blastoff is also known as “project initiation,” “kickoff,” “charter,” “project launch,” and many other things. We use the term “blastoff” to describe what we are trying to achieve—getting the requirements project launched and flying.

Quick and Dirty Modeling

Models can be used at any time in the Volere life cycle, we show his activity as “Prototype the Work.” There are, of course, formal models such as you would find in UML or BPMN, but a lot of the time business analysts can make productive use of quick sketches and diagrams to model the work being investigated. One quick and dirty modeling technique we should mention here is using Post-it notes to model functionality; each note can be used to represent an activity, and the notes can be rapidly rearranged to show different ways the work is done or could be done. We find that stakeholders relate to this way of modeling their business processes, and are always willing to participate with hands-on manipulation of the Post-its to what they think the work should be. We discuss this kind of modeling more fully in Chapter 5, Investigating the Work.

Writing the Requirements

A major problem in system development is misunderstood requirements. To avoid any misunderstanding, the analysts must write their requirements in an unambiguous and testable manner, and at the same time ensure that the originating stakeholder understands and agrees with the written requirement before it is passed on to the developers. In other words, the analysts write the requirements so as to ensure that parties at either end of the development spectrum are able to have an identical understanding of what is needed.

--------------------------------------------

Project Drivers—reasons and motivators for the project

1 The Purpose of the Project—the reason for making the investment in building the product and the business advantage that you want to achieve by doing so.

2 The Client, the Customer, and Other Stakeholders—the people with an interest in or an influence on the product

3 Users of the Product—the intended end users, and how they affect the product’s usability Project Constraints—the restrictions on the project and the product

4 Requirements Constraints—the limitations on the project, and the restrictions on the design of the product

5 Naming Conventions and Definitions—the vocabulary of the project

6 Relevant Facts and Assumptions—outside influences that make some difference to this product, or assumptions that the developers are making Functional Requirements—the functionality of the product

7 The Scope of the Work—the business area or domain under study

8 The Scope of the Product—a definition of the intended product boundaries and the product’s connections to adjacent systems

9 Functional and Data Requirements—the things the product must do and the data manipulated by the functions Non-functional Requirements—the product’s qualities

10 Look and Feel Requirements—the intended appearance

11 Usability and Humanity Requirements—what the product has to be if it is to be successfully used by its intended audience

12 Performance Requirements—how fast, big, accurate, safe, reliable, robust, scalable, and long-lasting, and what capacity

-------------------------------------------------------------

Rabbit—small, fast, and short-lived. Rabbit projects are typically smaller projects with shorter lifetimes, where close stakeholder participation is possible. Rabbit projects usually include a lesser number of stakeholders.

Horse—fast, strong, and dependable. Horse projects are probably the most common corporate projects—they are the “halfway house” of formality. Horse projects need some formality—it is likely that there is a need for written requirements so that they can be handed from one department to another. 

Elephant—solid, strong, long life, and a long memory. An elephant project has a need for a complete requirements specification. If you are outsourcing the work, or if your organizational structure requires complete, written specifications, you’re an elephant.