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 | |