Chapter 2. Moving to Use Cases

Storytelling reveals meaning without committing the error of defining it.

”H ANNAH A RENDT

The computer industry has struggled to find a way to represent functionality to users. We have always tended to produce what we're comfortable with: diagrams and specifications that are loaded with terminology and notation that looks a lot more like computer code than anything a user would understand. The traditional modes of expressing functionality to users early in the lifecycle are as follows :

  • Requirements specifications

  • Functional decompositions

  • Data-flow diagrams (DFDs)

  • Entity-relationship diagrams (ERDs)

  • Prototypes

Typically, requirements are specified in lists and expressed in terms of "the system shall." These lists are often grouped by functionality or subsystem. In such lists, it's easy to inadvertently write duplicate or conflicting requirements, and it happens often. The requirements specification does not provide the users with a cohesive view of what the system will accomplish; it is merely an itemization of each of the various functions, as if the functions could be extracted and treated independently.

The system shall . . .

graphics/02inf01.jpg

What requirements lists intend to provide is a comprehensive catalog of every function that the system should perform. Although it seems only natural to list these functions, it turns out that there are better ways to represent this information and provide a better structure than a list.

We recommend that requirements lists be dropped from the analyst's toolbox.

Functional decompositions are a remnant of the older analysis and design approaches.

graphics/02inf02.jpg

Often in an attempt to "divide and conquer" a complex software application, a team will use a method called functional decomposition. This tool takes the major function of the system, the highest level "function" (also sometimes called activity/process/action ) and breaks it down into subprocesses, and sub-subprocesses, and so on. Eventually, the processes are small enough to become a program (in computer programming terms). The highest-level function is usually called "Process Insurance Policy," "Process Requisition," or "Process" whatever.

This approach has been abandoned in the software industry for several reasons. First, it is tightly linked to structured systems development, meaning COBOL programs and mainframes. It is not usable for an application that will be Web-based or object-oriented once it is coded. Second, by dividing and conquering using "processes" it is easy to lose the connection to the "things" that we care about, the entities that become "objects" or "classes" in analysis and design. And, as we review later in section 4.3.2, hierarchies of requirements are not desirable for a well-designed software application. And third, functional decomposition has proven it is not capable of handling the contemporary complexity of today's information systems.

DFDs are useful for technical people but tend to confuse users.

graphics/02inf03.jpg

Dataflow diagrams (DFDs) help show a system as a set of groups of interacting processes. We consider them to represent the dynamic view of the system. The data flows from one process to another and then stops in a data store. External entities, such as an outside department or computer system, are referenced whenever they have involvement in the flow of data. Because DFDs focus on what happens inside the system, they are the main input into system design. In our experience, users seem to be confused by these diagrams because the line between system and user responsibility is fuzzy. DFDs also contain a lot more detail than users are prepared to wade through. Some of these details, such as how many data stores are used and what they store, do not concern the users at all.

As with requirements lists, we recommend that DFDs be dropped from the requirements analyst's toolbox. DFDs introduce many technical elements into the requirements picture that are not necessary at this point. DFDs can be replaced by use cases and class, sequence, statechart, and activity diagrams in the Unified Modeling Language (UML).

NOTE:

DFDs can still be useful in design, particularly with non-object-oriented systems. Just don't consider them a requirements artifact.


Entity-relationship diagrams (ERDs) show how the data is stored in an application. They show details of entities, attributes, and relationships. This diagram can also be used to represent a logical data model and dictate the structure of a relational database. However, ERDs do nothing to show dynamic interaction, and they must always be used along with DFDs to show a complete picture to the users. The difference between a dynamic type of expression (DFDs) and a static or persistent expression (ERDs) is irrelevant and confusing to users.

ERDs are critical for database design, but they are not meant for user consumption.

graphics/02inf04.jpg

We recommend that ERDs, too, be dropped from the requirements analyst's toolbox. ERDs are still required if you want to create a logical data model after requirements have been gathered, but ERDs do not provide much meaning to users and seem foreign to them.

Prototypes were long held to be the elixir for good requirements capture, but now we realize that they can help much more with proof-of-concept tasks .

graphics/02inf05.gif

Prototypes give users a realistic demonstration of what a system will be able to do when it is completed. These mock-up versions of the system concentrate on the user interface and omit all or most of the background coding. Prototypes are greeted with enthusiasm by users because they help them understand the possibilities much better than do paper diagrams. However, users' enthusiasm is problematic because they immediately get caught up in the details of the user interface and the mock-up data. Soon, they are spending more time requesting button moves and color changes than they are spending focusing on the functionality. Prototypes also lead users to the misperception that the prototype is the system, and they become impatient when it takes weeks or months to develop the actual system. Prototypes also encourage the team to continue quick-and-dirty coding after actual system development begins, evolving the prototype into the final system.

We recommend that prototypes no longer be used as a requirements tool. Instead, they should be used to support use cases and the business rules catalog, which become the central focus of the requirements phase.

Traditional requirements specifications are often never used again after they are produced. DFDs and ERDs are useful for moving into programming and database design, but they do not mean much to users. Prototypes are meaningful to users, but they encourage them to concentrate on the details of user interface implementation and not on the requirements of the system. What's needed is a new medium between users and system designers.



Use Cases. Requirements in Context
Use Cases: Requirements in Context (2nd Edition)
ISBN: 0321154983
EAN: 2147483647
Year: 2002
Pages: 90

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net