The Workflow

There are some things that never seem to change, even in the fast-paced world of software development. One of those things is the Iron Triangle. The Iron Triangle is a natural law that pits three forces against each other:

The capabilities and quality of the system
The development schedule
The cost of the development

The Iron Triangle mandates that the magnitude of two of these forces determines the magnitude of the third, or, as it has been heard in uncounted development shops over the years : Its good, fast, or cheap ”pick two! (In the new Internet economy the flexibility to pick two is often restricted. Commonly, it now must be good and fast from the customer's viewpoint. Unfortunately, from the developer's viewpoint, it may be only fast.)

This simple law of software development makes it imperative that we clearly understand the desired capabilities of the system. This is the one factor (that is, good ”the capabilities and quality of the system) of the three that we can most easily control. Understanding what we want to build before we begin to build is a major first step toward reducing the risk of failure with our projects. This is why we must clearly define the requirements (that is, the desired capabilities) of the system. We build to and test against the requirements. They are our foundation for change and our contract with the business clients . They are not just words on paper. They are critically important.

Our goals for requirements definition are to

Establish the scope of the system we are to build
Establish a detailed understanding of the desired capabilities of the system

Establishing the scope of the system is often a great personal challenge to the development manager or team leader of the project. This can also be a severe cultural shock to an organization. At this early phase in the development life cycle, our customers (that is, the business people for whom we are building this system) are often like children in a candy store. They want everything. And like those children they never seem to have the money to pay for it all. Unfortunately, those of us on the development side often must play the role of the strict parent, denying our customer's sweet tooth. This can be a career-shortening task if not done properly and gently, which is why we must also meet the second goal of developing a detailed understanding of the desired system capabilities. Indeed, this provides the foundation for achieving the first goal of establishing the system's scope. Bob once worked with a project manager who joined an organization in which the software people often just did whatever they were told by the business clients. This manager came in and through the simple act of prioritizing requirements into this delivery, next delivery, third delivery, and so on he was given the nickname Dr. No. He caused quite an uproar by simply saying, No, that will have to go in the next delivery. However, after the cultural trauma abated, he turned out to be one of the most successful project managers that organization ever had.

The Use Case Model

The major artifact that results from requirements definition is the use case model of the system. But didn't we already develop a use case model while modeling the business? Correct, but the use case model to be developed now is the model of the system those business workers and business actors will use to perform their specific business functions. (For those people who don't do business modeling as part of their development process, this is the level of use case modeling at which they typically begin. Also, most texts and articles you may read that discuss use cases typically do so beginning at this level.) Indeed, the elements of the business model (business actors, business workers, business entities, and so on) become part of the system use case model. This gives you a jump start by preloading your use case model with these elements.

Supporting the use case model are use case descriptions that elaborate the basic information and detailed flow of the use case. These descriptions should follow a standard format tailored to the organization's needs. There are many examples of use case description templates available in the literature on this topic. However, they should contain, at the minimum:

Identifying information ( name of the use case, who is responsible for the use case, date and/or other revision information)
A basic description of the use case
The basic flow of the use case
Alternate flows and the conditions that trigger them

A more robust description may contain sections on:

Limitations
Preconditions (the required state of the system, or conditions that must be true, for the use case to be executed)
Postconditions (possible states of the system after the execution of the use case)
Assumptions
Inclusion and extension points (if using includes and extends relationships with this use case) and so forth

Examples of such a form appear in Appendix B.

Often, businesses that have an existing system being updated or replaced also have existing documentation on that system, or if they are building a new system, they have used a methodology where technical specifications are written first. This can create confusion when the development team intends to employ use cases also. Questions like What do we do now? and What do we do first ”the use cases or the specs ? are asked often. It really doesn't matter. If you have specifications or other supplemental information, they can be a great source for identifying actors, use cases, classes, timing, and other important information. If you have none, building a use case model can help you in building your specifications. Use the information you have to your best advantage and do not allow your progress to be hobbled by excessive devotion to the letter of the law of a specific methodology. Use cases can be used for both capturing existing requirements and eliciting new requirements.