A technical discussion on Use Case Best Practices06/11/0 3Use Cases:Best PracticesBy Ellen GottesdienerImproving software development capability2Use Case Best Practices Introduction • 2Table of ContentsIntroduction......................................................................................................................... 3How Use Cases Help You Define Software Requirements ................................................ 3The Business Level.......................................................................................................... 3The User Level................................................................................................................. 4The Technical Level......................................................................................................... 4Documenting Requirements............................................................................................. 4Listening to the “Voice of the Customer”........................................................................ 4Getting Started with Use Cases .......................................................................................... 4Scope the Domain............................................................................................................ 5Generating Use Case Names......................................................................................... 5Scope Your Use Cases..................................................................................................... 6Defining Events ............................................................................................................ 6Validate Use Cases as They Emerge................................................................................ 7Define the Requirements Models You’ll Need................................................................ 7Determine Your Elicitation Strategy................................................................................ 8Settle on a Standard Format for Your Use Cases............................................................. 9Develop a Glossary to Define a Common Language ....................................................... 9Seven Tips for Writing Successful Use Cases...................................................................10Tip 1: Develop Your Use Cases Iteratively ..................................................................10Tip 2: Involve Users Directly........................................................................................10Tip 3: Depict Your Use Cases Visually ........................................................................12Tip 4: Use Your Use Cases to Harvest Nonfunctional Requirements ..........................12Tip 5: Prioritize Your Use Cases and Use Case Scenarios............................................13Tip 6: Trace Your Use Cases.........................................................................................13Tip 7: Verify Your Use Cases .......................................................................................14Conclusion.........................................................................................................................15Glossary............................................................................................................................15References .........................................................................................................................17Author Bio ........................................................................................................................18Improving software development capability3Use Case Best Practices Introduction • 3IntroductionAs an analyst, you have the crucial task of defining the requirements for software that is to be built oracquired. Your task is crucial for a number of reasons. If software teams fail to define excellentrequirements, projects suffer from a variety of problems, including quality shortfalls, failure to meetschedules, ever-expanding user requirements, and, in the end, customer dissatisfaction. Thefinancial costs are enormous. Depending on which study you read, typical software projects spendroughly one-third of their overall budget correcting errors that originate in requirements.Whether you are defining requirements for new software, software that will be purchased, or existingsoftware to be enhanced or maintained, it’s easy to see why a clear understanding of requirements isone of the most important determiners of project success. Moreover, the task of defining high-qualityrequirements is crucial to all the project stakeholders: clients, end users, developers, testers, andmanagers.Years of experience in defining requirements have led to the development of a number of techniquesand models to assist in the process. Among these, perhaps the most well-known model is the usecase, the focus of this paper. If you have experience with use cases, you know how pivotal they arefor supporting many project activities, and you may be wondering how to improve your use casemodeling to save time and energy. If you are new to use cases, you want to know the bottom line bestpractices for getting started. This paper’s goal is to provide practical advice to both novice andexperienced use case modelers.How Use Cases Help You Define Software RequirementsTo understand how use case modeling helps you define excellent requirements, let’s first take aquick look at requirements. Requirements are the defined operational capabilities of a system orprocess that must exist to satisfy a business need. Requirements are the underpinning of allsoftware development.The generic term requirement covers both functional requirements and nonfunctional requirements.Functional requirements evolve from user requirements—tasks that users need to achieve using thesoftware. Nonfunctional requirements, on the other hand, cover quality attributes of the softwaresuch as performance, system needs such as security and archiving, and technical constraints suchas language and database. In the end, both functional and nonfunctional requirements must be clearto the development and client communities, who may not have a easy means of communicating withone another.Requirements don’t come out of thin air. They are the product of a systematic discovery anddefinition process in which analysts play a key role. Software requirements derive from a process