Use case specification

Therefore, don t attempt to finish one before proceeding to the next and don t insist on doing them in one order or the other (though most people start with use-cases). Specifically, do not generate many detailed narrative use cases without iterating through a precise modehng cycle. 

Enough has been said about the use case diagram and iteration planning. Now let s look at how to write use case specifications—text specification of use cases. 

The following use case specification is for the Register Compound(s) Use Case. This book is not about how to write use cases. For more detailed discussion about how to write effective uses case specifications, please see Cockbum (2001) and 1. arman (2005). 

There is no standard format for use case specifications. The above is the Alistair Cockburn format, which can be found at his website — alistair. cock-burn.us or in his book (Cockburn, 2001). The template is available for download from the website. Another popular format is the IBM Rational RUP format that can be downloaded from http //www 128.ibm.com/developer-works/ rational/library/4152.html. 

Please note that use case modeling is not associated with any development process. It is even independent of object-oriented technologies. It is a generic tool for capturing functional requirements. I have used use case specifications in ISIS PL projects, and it worked perfectly. 

In an object-oriented world, in addition to capturing functional requirements, use case specifications can be used as a starting point for developing a domain object model, which is discussed in the next chapter. 

Other types of requirements, usually nonfunctional, may not be captured by use case specifications such as performance, scalability, availability, usability, security, and software-hardware constraints. These requirements can be included in the supplementary specifications. Please see Larman (2005) for examples. 

Use case specifications can be visualized using UML Activity Diagrams and System Sequence Diagrams (Larman, 2005). I always find a graphic model easy to understand and communicate. However, these visualized models should be used as supplements, not as a replacement for use case specifications in text. 

In an agile iterative process, not all use case specifications need to be fully developed before the design and implementation starts. Usually, a scope and a vision document are developed with a fist of features that should be included in the system, including a brief description of each feature as in the Brief Description section of the above use case specification. These features are prioritized and planned according to their business values, complexity, and architectural significance (please see Chapter 5). At the beginning of an... 

Never expect that use case specifications are complete and accurate and do not change before the design and implementation work starts. No matter how much time is spent on requirement analysis, there will be omissions, misunderstandings, and unknowns. Often users may not even know how the... 

Use case specifications document functional requirements. The next step is to design the partial system that the current iteration is supposed to deliver. The gap between requirements and design is not trivial, and a bridge between the two is desired. This bridge is what object-oriented analysis is about. The domain analysis object model is not the final design. However, it provides a starting point for the design process. 

One technique that can help you to capture domain objects is to look for nouns in the use case specifications—those terms in bold in UC1 of Chapter 9. The following are the key domain objects from UC1. 

The domain object analysis phase must be very brief in an iterative process. It should be a j-1 day activity after the use case specification is developed. Do not expect the analysis model to be complete, accurate, and unchanging. Many decisions can be, and should be, deferred to the design phase. 

The Business Layer is in the center of CRS where the core business functions reside. Any business application has a workflow—the steps it takes to accomplish one or many tasks or transactions. Clearly analyzing and understanding the workflow is essential to designing the Business Layer correctly. Use case specifications capture workflow from a user s perspective. The System Activity Diagram is an excellent tool to capture system workflow from a system perspective. Figure 12.1 is the System Activity Diagram (CAD) of CRS. 

The use case specification presented in Chapter 9 describes steps in a compound registering process ... 

Develop use case specification documents to capture detailed functional requirements (Chapter 9). Use System Sequence Diagrams and Activity Diagrams as complements. Use case specifications should be developed, communicated, and reviewed at the beginning of each iteration. 

Develop a domain object model based on use case specifications (Chapter 10). This is the bridge between the requirements and the design. 

Communities where increased environmental lead exposures and various toxic endpoints have been explicitly incorporated into a dose—response framework currently highlight health risk characterization using case-specific evidence. Data generated in such communities typically first permit determination of distributions of risk group PbB values, specifically prevalences and incidences of PbB above an accepted health risk threshold. These PbB statistics are then incorporated into health risks using dose—toxic response relationships. 

---