9.2 Classic Mistakes: Make Them and Move On

Tables 9.1 through 9.7 describe the classic mistakes people make when they're gathering and specifying requirements, particularly those mistakes related to use cases. The tables are organized into general areas: perspective, thriftiness, messiness, overengineering, mismanagement, context, and notation. You can use them as a reference, and perhaps it would be good to bring them out from time to time to remind the team of the usual mistakes that happen. If you and your team tend to err in a particular way ”say, overengineering ”you can put more focus on that section in your discussions.

Table 9.1. Classic Mistakes of Perspective

Number

Classic Mistake

Issues and Concerns

Related Sections

001

Creating inside-out use cases

It is easy for developers to create inside-out use cases, which operate from the perspective of the application and not the user . The problem is that users often don't understand this perspective because it is not natural for them.

2.3.1.2 No Implementation-Specific Language

002

Including user interface details in use cases

Embedding user interface details in use cases is actually quite acceptable ”after requirements have been gathered. But during requirements gathering, keep user interface details out. They serve only as a distraction from the interactions that need to occur.

1.5.4 Prototypes

2.3.1.2 No Implementation-Specific Language

003

Expanding the system boundary

It is difficult to keep in mind the scope of the system you're developing. For example, if a security identification system is connected to your application, is it inside the boundary? Or is it an actor? Or should it not be shown on use case diagrams? It depends on whether this project team is responsible for implementing and testing it. If it is an integrated component, it's inside the boundary and not shown in the use case diagram. If it is a separate system done by a separate team, it becomes an actor.

2.3.2.1 Actors and Roles

004

Creating use case interactions that don't provide value to an actor

Use cases must generally provide value to an actor. The actor doesn't necessarily have to be the same one who provides the input for the use case.

2.3.1.1 Interactions That Provide Value to Actors

Table 9.2. Classic Mistakes of Thriftiness

Number

Classic Mistake

Issues and Concerns

Related Sections

001

Skipping iterations

There is a tendency to skip iterations in requirements, especially for those coming from a big-bang waterfall mind-set . For very small projects, it may sometimes make sense, but usually it is wise to go through the four iterations or at least to address all the individual steps detailed in the iteration chapters if fewer iterations are required.

Chapter 4,The Facade Iteration

Chapter 5, The Filled Iteration

Chapter 6, The Focused Iteration

002

Skipping interview notes that don't fit

If some requirements from the interviews don't fit into the current iteration, people tend to skip them, thinking that they'll come back in the iteration they're supposed to. They might not! Keep free-form notes that don't fit the use cases or business rules of the current iteration and review these notes during each subsequent iteration.

Chapter 4, The Facade Iteration

Chapter 5, The Filled Iteration

Chapter 6, The Focused Iteration

003

Holding on to use cases that don't belong

Thrifty people hate to throw things away. However, extraneous use cases or business rules that don't belong should be tossed. Version control is helpful here. Throw things away. If you need them later, you can go back a version or two and retrieve them.

Chapter 7, Managing Requirements and People

Table 9.3. Classic Mistakes of Messiness

Number

Classic Mistake

Issues and Concerns

Related Sections

001

Keeping temporary requirements lists

A common mistake is to keep a contraband list of requirements off to the side and then incorporate the requirements into the use cases as they make sense. This means you're doing the work twice; the second time you're just changing the format of the requirements from a list to use cases. This is an acceptable first step into the world of use cases, but it should not become a practice, simply because it is extra work.

Chapter 1, The Trouble with Requirements

Chapter 3, A Use-Case-Driven Approach to Requirements Gathering

002

Grouping use cases or business rules poorly

It helps a lot to group the use cases, but this is difficult to do. Group use cases and business rules in ways that make sense to the stakeholders. Group use cases using UML packages. Group business rules using category columns in the business rules catalog.

Chapter 7, Managing Requirements and People

003

Having use cases without an owner

Each use case should have an owner. Use cases that are not assigned ownership are often not modified consistently throughout the iterations.

Chapter 7, Managing Requirements and People

004

Having use cases with too many owners

A use case that has too many owners will die a death no less painful than those use cases without any owner. No one really owns it, and people make contradictory changes to the use case, wasting precious time.

Chapter 7, Managing Requirements and People

005

Including too many cross-references in use case text

Some use case textbooks list various ancillary sections in their use case templates that duplicate information from the use case diagram or other places. Don't include these sections. This is duplicate work that you will have to spend time modifying when things change later in the lifecycle or during maintenance. Here is a subset of these sections: actor lists, included use cases, activity diagrams, user interface, sequence diagrams, subordinate use cases, participating classes. Two exceptions: a primary actor (just one) and extension points.

2.3.3 The Use Case Template

006

Not keeping use cases and business rules in a database

The need to cross-reference, sort , and list the use case titles and business rules means that a database or spreadsheet is the most appropriate place for use cases, especially for a large system.

Chapter 7, Managing Requirements and People

007

Trying to build extensive exception logic into the basic course of events

The purpose of the Exception Paths section in the template is to document paths that occur when something goes wrong. Don't try to put all this in the Basic Course of Events section.

2.3.1.2 No Implementation-Specific Language

2.3.1.3 User-Appropriate Level of Detail

2.3.3 The Use Case Template

Table 9.4. Classic Mistakes of Overengineering

Number

Classic Mistake

Issues and Concerns

Related Sections

001

Neglecting useful tools within use cases

A use case does not have to be text only. Within a use case, it is perfectly acceptable, even encouraged, to have diagrams, tables, flowcharts, or any other graphic representation that best tells what is happening in the use case. Decision tables for complex logic are a great example.

2.3.3 The Use Case Template

002

Creating CRUD use cases first

CRUD table maintenance is often an acceptable use case, but these use cases should not be the first ones you work on. The first use cases to be created should be those that provide the most value to the actors. CRUD value is almost always subordinate to the major business processes.

 

003

Using computer terminology in use cases

During the requirements activity, all use cases should be in language that the users understand. No computer terminology (LANs, WANs, GUI elements, servers, workstations, screens, windows , and so on) should be used.

2.3.1.2 No Implementation-Specific Language

004

Writing pseudocode for use case text

Use cases are descriptions of interactions between actors and an application. They are not pseudocode or code. They should be written in English (or Spanish or French) and not in OCL, OQL, or anything else remotely machine-readable

2.3.1.2 No Implementation-Specific Language

2.3.3 The Use Case Template

005

Assuming that the extend relationships between use cases dictate class inheritance in design

This is more a mistake of analysis or design. It is natural to assume that the extend relationships shown in the use cases will translate into inheritance relationships in a class diagram. There is no correlation between extend and class inheritance in design.

 

006

Assuming that the include relationships between use cases dictate class responsibilities in design

This is a mistake of analysis or design (or both). It is natural to assume that the include relationships shown in the use cases will translate to specific classes that should be extracted and assigned specific responsibilities. There is no correlation between include and class creation or responsibility assignment in design.

 

007

Confusing actors with specific people or organizational positions

Actors are roles. One person might play several roles, and one role might be played by several people. To avoid redesigns when organizational or staffing changes occur, you should not couple actor definitions to specific people or organizational positions.

2.3.2.1 Actors and Roles

008

Making business process assumptions that are not verified

There's the way things should work, and then there's the way they do work. While you're creating use cases and business rules, verify, verify, verify. Common sense has nothing to do with it.

Chapter 4, The Facade Iteration

Chapter 5, The Filled Iteration

Chapter 6, The Focused Iteration

009

Putting everything into one use case diagram

This is extremely common. Why not show every possible use case in one diagram and depict the relationships between all? This is a classic mistake because it is too much for users to take in all at once. Instead, break the system into use case packages, show all packages on one diagram, and then break down the packages into use cases.

5.2.1.2 Review Use Case Granularity

010

Putting everything into one use case

There should be one use case that describes the entire application: the system context use case. However, it should be at such an abstract level that it is useful only as a general scope statement. Some system context use cases contain a Basic Course of Events that is pages and pages long. This is an abstraction mismatch and should not be done. No use cases should have more than two pages of text for the basic course of events.

5.2.1.2 Review Use Case Granularity

011

Abstracting too much

What? We've been telling you to abstract all along! Can you have too much of a good thing? Of course. How do you tell? Ask your users. If you've abstracted the functionality to such a degree that your users don't understand it anymore, it's too much.

5.3.4 Abstraction Filter

012

Using IF-THEN-ELSEs in the use cases

Pseudocode in use cases can make users uncomfortable.

5.2.2.7 Document Exceptions

013

Creating hierarchies of use cases

This is a holdover from the "bad ole days" of functional decomposition. All use cases should be created at the same level of detail. Don't create "high level" use cases and then "more detailed" and "really detailed." You'll lose perspective on the original business problem.

4.3.2 The Hierarchy Killer

Table 9.5. Classic Mistakes of Mismanagement

Number

Classic Mistake

Issues and Concerns

Related Sections

001

Trying to force simultaneous iterations

Iterations can certainly overlap. However, we've known several managers who think that everything should happen at the same time because it makes their project plans end by the date promised to management. This is the wrong reason. Let iterations overlap naturally, but don't force the issue or a lot will fall through the cracks. If iterations are happening simultaneously , there should be separate teams per iteration.

 

002

Allowing an imbalance between experience and inexperience

In requirements gathering, a few inexperienced analysts often get paired with too few experienced analysts. Worse yet, no one has business knowledge. Requirements are the most pivotal artifact of the lifecycle. Reduce your investment in them at your peril.

Chapter 7, Managing Requirements and People

003

Packaging use cases too late

Use case packages are your tool for reducing complexity on diagrams. Use them early and often. If there is a set of functionality that you don't need to deal with right now, lump it into a package and let it sit until the time is right.

5.2.1.2 Review Use Case Granularity

004

Using packages to hide complexity that you're trying to avoid

The purpose of packages is to hide complexity. However, if you use packages of use cases to hide a part of the system that you don't yet understand, you're only putting off the inevitable task of learning that part of the application. If you put it off until later in the requirements activity, you risk running past your deadline when the package turns out to be a lot more complex than you originally thought.

4.3.7 Packages as Placeholders for Functionality

Table 9.6. Classic Mistakes of Context

Number

Classic Mistake

Issues and Concerns

Related Sections

001

Confusing include, precondition, and assumption

As long as you use consistent definitions of these three terms, your use cases will be meaningful. We've provided some definitions that make sense to us, but you can use your own, as long as they're applied consistently. And, to be safe, steer clear of include and extend unless you are extending an earlier release of a product and don't want to change the original use cases.

5.3.2 IPA Filter

002

Using two columns in the Basic Course of Events section in use case template

This is quite common, and it is even advocated in some textbooks. Here's the question to answer. Usually use cases are interactions between one actor and the application. What happens when multiple actors get involved? Do you then create three columns? Or put both actors in the left column? This seems like a good idea until you try it in complex situations.

2.3.3 The Use Case Template

003

Confusing include and extend

Confusing the use case adornments is very common. Remember, includes (formerly uses ) is like a function call; extends is like inheritance.

2.3.2.2 Associations

004

Underusing use cases during the lifecycle

We believe that use cases are extremely useful after requirements gathering is complete.

Chapter 8 Requirements Traceability

Table 9.7. Classic Mistakes of Notation

Number

Classic Mistake

Issues and Concerns

Related Sections

001

Using use cases as scenarios

It's easy to confuse use cases with scenarios. Use cases represent a fairly abstract actor interaction that provides value to the actor. Scenarios are instantiated from use cases and provide specific interactions with specific value.

2.3.4 Paths and Scenarios

002

Using weak verbs in use case names

Use case names are extremely important because they identify the interaction. Poor names are usually too vague or misleading.

4.3.5 Verb Filter

003

Using weak nouns in use cases

Nouns that are computer-specific or just plain bland not only do not help with interpretation of the use case text but also point to vague areas of understanding by the requirements analyst.

4.3.6 Noun Filters

004

Portraying application parts as actors

It is common for analysts familiar with only part of the application to take another section of the application and put it outside the boundary of the use case as an actor. This is right only when the outside application part is not the responsibility of this team.

2.3.2.1 Actors and Roles

005

Underusing preconditions and postconditions

Preconditions and postconditions provide an excellent scope management feature for use case creation. If the analyst, the user, and the project manager agree on the preconditions and postconditions for a use case, the analyst is free to find the steps that take the use case from the before to the after. Preconditions and postconditions provide the analyst with a liberating structure.

2.3.3 The Use Case Template

006

Using secondary actors inappropriately

Secondary actors should be shown on use case diagrams when the application is likely to require information about them ”that is, when the secondary actors are likely to become classes in the class diagram during analysis and design.

2.3.2.1 Actors and Roles

007

Forgetting that actors can become classes

During analysis and design, the classes that provide the values in use cases are designed and assigned responsibilities. However, actors also become classes when it is important to store information about those actors.

2.3.2.1 Actors and Roles

008

Overusing adornments

The inherent mistake here is thinking of a use case diagram as a system design or data design. It's not. If the adornments ( extend, include , and so on) are starting to clutter the use case diagram, it probably means that the mind-set of the team needs to be pointed toward requirements instead of design.

2.3.2.2 Associations

009

Confusing who extends whom

It is easy to confuse the extender with the extendee. The specialization use case should be at the blunt end of the arrow, and the general use case should be at the sharp end of the arrow.

2.3.2.2 Associations



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