A Case for Use Cases

1. A Case for Use Cases Crystal Farmer Verizon Communications E-Business Group August 11th 2000

2. Introduction The lifecycle of system developing can be broken down into 7 activities: • Requirements Gathering – documenting the functions that the application should perform for the users in the users language, from the users perspective. • Analysis – a logical solution that satisfing the requirements but not necessarily taking physical constraints into account • Design – changing the logical solution to work effectively with the physical constraints and producing specifications to direct the construction effort • Construction – using the design to produce working code; writing code, compiling, debugging • Testing – producing a complete system by testing, detecting and recording issues, fixing problems and getting acceptance • Deployment – fitting the application into the production environment • Maintenance – Administering and making changes to the system to adapt to business and technology changes, system issues and politics

3. Requirements Requirements are the foundation of a system and the base for the development process. Effective requirements are pivotal to producing a system that meets the needs of the users. Requirements Documentation can be broken down into 3 parts: • Requirements Gathering – the activity of bringing requirements together • Requirements Definition – the activity of documenting and organizing them into something meaningful and understandable • Requirements Specification – is the document that results from the previous activities An appropriate and complete requirements specification makes successful implementation possible.

4. Problems with Requirements Requirements gathering can be ineffective and / or underemphasized for the following reasons: • Takes to long • Documents the wrong thing • Makes assumptions about activities that haven’t happened yet • Are often completed just in time to do it over again due to changes on business Other common mistakes that get people off track with requirements are: • Embedded Design – anything that relates to HOW a system should operate rather than WHAT it needs to accomplish is design and should not be part of requirements. • Vagueness – if a requirement does not contribute positively to shaping the application design it is to vague to be useful. • Computer Industry Language – requirements must always be in the users language.

5. Communication of Requirements Very important early on in the lifecycle is good communication of the functionality of the proposed system to the users. Ways to do this are: • Requirements Specifications – being a list its easy to have duplicate and / or conflicting requirements and there is no cohesive view of what the system will accomplish • Data Flow Diagrams – these introduce technical elements not nessacary at this point and tend to confuse the users • Entity Relationship Diagrams – do not provide much meaning to users • Prototypes – are good demonstration but can lead to the users misperception that the prototype is the system and can cause users to get caught up in the details of the interface • Use Cases – documentation that focuses on the interactions (the “going ins” and “coming outs”) has more relevance to the users.

6. UML Use Cases are part of a comprehensive language called Unified Modeling Language. UML is a notation not a methodology; it helps structure the documentation rather than guiding the building of the system. The Use Case Diagram is the driver for the rest. • Use Case Diagram • Sequence Diagram • Collaboration Diagram • Statechart Diagram • Activity Diagram • Class Diagram • Object Diagram • Component Diagram • Deployment Diagram A Use Case has two parts: • Use Case Diagram – is an overview of the system interactions. Its simplicity makes it a great communication tool. • Use Case - is text detailing what the system must do.

7. Goals of Use Cases The goals of Use Cases are: • Use Cases are meant to show the interactions between the system and the entities external to the system. • Use Cases should not include any implementation specific language (ie. Specific people, departments, interface references, if-else-then statements) • Use Cases should always be in users vocabulary. Although they will become more detailed as the lifecycle proceeds it is important to start at a general level. • The number of Use Cases should be very small. Most systems would have 20-50 use cases.

8. Use Case Template

9. Use Case Diagram Customer Create Work Order Technician Service Rep

10. Use Case Driven Approach These are some guiding principles for Requirements gathering and documentation success: • Reduce Risk • Focus on Business Interactions. • Reduce Volume. • Reduce Duplicates and Inconsistencies. • Create requirements that users can understand easily. • Create requirements that are useful to designers developers and project managers. • Leave a requirements trail. • Leave design until later. • Keep the plan in mind.

11. Four Steps Requirements gathering includes these steps: • Façade – outline and high level description • Filled – broadening and deepening • Focused narrowing and pruning • Finished – touching up and fine tuning This is an Iterative and Incremental approach which helps reduce risk by treating risky items early in the life cycle

12. The Iterations Through out the iteration you create and refine several ‘tools’ that define the requirements deliverable set. The tools provide comprehensive coverage of that part of the development lifecycle. • Problem Statement – outlines the business problem to be solved • Statement of Work – defines the scope, general work plan and staffing • Risk Analysis – lists the risks that may influence development • Prototype – software mock-up of user interface • Use Cases and Uses Case Diagrams – should be the centerpiece of requirements gathering • Business Rule Catalog – written or unwritten rules on how a company conducts business

13. Facade Iteration The purpose of the first iteration is to document and understand the major interactions you expect the users to have with the proposed system. You identify actors, users, user group management and start a business rules catalog. Facade use cases contain minimum information You may ask: • Who wants the system built? Who Doesn’t? • What elements of the system were previously ruled out? • Is the project visible to upper management? • How long has this idea been kicked around? When the Façade Iteration is complete; every use case identified has been documented, the problem statement is complete, statement of work is complete, and risk analysis is begun.

14. Filled Iteration The objective of the Filled Iteration is to create a comprehensive set of use cases and business rules that describe the application functionality, this is the meat of the requirements gathering. You will breakout detail use cases, create filled use cases, document nonfunctional requirements, add business rules and pretest filled use cases. Filled use cases are rough but contain a lot of detail When the Filled Iteration is complete; all use cases should be identified and documented, the business rules catalog partially complete and scenarios for use cases begun.

15. Focused Iteration The focused iteration separates the essential from the nice-to-have. You now select only the best options and include only these in the scope. You will create the context matrix, remove duplicate processes and bring each use case to ‘focus’. Focused use cases describes the users interaction with the system, they are honed to provide a solution to a limited set of business problems. They should be clear and crisp. You may ask: • Is there duplicate functionality? • Are any of the processes overly complex? • Is the level of detail consistent? • Have we inadvertently removed any essential parts? When the Focused Iteration is complete; every use case and use case diagram has been documented, the problem statement is complete, statement of work is complete, risk analysis is ongoing and business rules catalog almost complete.

16. Finished Iteration In the finished Iteration you integrate the nonfunctional requirements with the use cases, add user interface requirements and package the documentation for the design effort. You also get signoff at this point and baseline the requirements Finished use cases are the primary input to the design phase, the nouns and actors in a use case influence the identification of objects in an object oriented application development. You may ask: • Are interfaces consistent? • Are standards followed? The Finished Iteration deliverables are completion of all steps in the Iteration and completed baselined requirements document.

17. Waterfall vs. Iterative and Incremental Lifecycle The Waterfall is a steady linear lifecycle with well defined milestones. Iterative and Incremental are more circular adaptive approaches. Waterfall methodology has been an industry mainstay for several decades. “Finish one phase before starting the next”. This makes sense in small context but not in a larger one. In the Iterative and Incremental the focus is on producing code as soon as humanly possible and the real milestones are the completion of use case. This reduces risks for developers by letting them try things out earlier. Because of the complex nature of business entire lifecycles cannot go more than six months without seriously risking the automation of obsolete requirements. It is more Important to adapt than to Predict.

18. The Use Case Team In addition to the analyst who writes the use case the use case team should include: • Subject Matter Experts – A primary source for requirements that understands business rules and processes. • Designers – since use cases are the primary input to the design phase a design team representative should provide feedback and this should be incorporated in the use cases • Testers – since tests are based on use cases its appropriate for a tester to be involved • Sign-off Authority – this role should approve the use case template and standards document.

19. Conclusion Requirements gathering is a problem for many projects. The Fuzzy nature of requirements can make working with them slippery and unintuitive for most people. Use cases are a tool that addresses the specification & communication concerns associated with requirements gathering. Use cases can drive the entire application development process whether you use the Iterative, Incremental, Waterfall or other methodology and they help increase quality and decrease efforts in the requirements activities.

20. References • Daryl Kulak and Eamonn Guiney, Use Cases: Requirements in Context, ACM Press, 2000. • Rational Unified Process