1 / 34

Writing Effective Use Cases

Writing Effective Use Cases. Presenter Name: Marcia Stinson Marcia.stinson@ravenflow.com. Presented by Marcia Stinson Senior Consultant Ravenflow. Are Projects Really So Different?. All projects are different Different needs Different users All projects are the same

vance
Download Presentation

Writing Effective Use Cases

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Writing Effective Use Cases Presenter Name: Marcia Stinson Marcia.stinson@ravenflow.com Presented by Marcia Stinson Senior Consultant Ravenflow

  2. Are Projects Really So Different? • All projects are different • Different needs • Different users • All projects are the same • All need clear requirements • All need a way to trace user requirements to the delivered product • The success of all projects is measured by the results the product provides

  3. What are Requirements? • A contract between development and users • What will be provided by the product • i.e. features or capabilities • What standards or regulations will be followed • How the user will use the product • User interactions with the system (use cases) • What will NOT be provided by the product • What is out of scope NOTE: there is no mention here of format or structure of the requirements.

  4. Some Say It’s Getting Better But… • Statistics published in 2006 and 2007 indicate that as “few” as 1/3 of projects are classified as failures (Communications of the Association for Computing Machinery, Nov 2007). • If true, this is certainly a big improvement over the 2004 Standish report that 2/3 of projects were classed as “challenged”. • However that is small comfort if you are part of the 1/3 or your company reallocated resources from your successful project to one that is failing. • The list of culprits is still familiar: • Lack of user input • Incomplete requirements and specifications • Changing requirements and specifications • Lack of executive support • Technology incompetence • Et al • Many systems claim to provide solutions to these problems but if we truly are still seeing 1/3 failure rates, we’re far from perfect.

  5. The Payoff for Getting Requirements Right Upfront • Application projects that either fail or are considered less than successful 60% More Successful Projects • Application projects that fall short of the intended return on investment 40% Higher Project ROI • Application projects that are cancelled outright prior to completion 30% Fewer Cancelled Projects • Percentage of total project cost due to rework resulting from poorly defined business requirements Less Rework Costs 20% • Annual business cost (US) associated with requirements induced project delays $30B Higher Profitability Source: Gartner, NIST, SEI, Standish Reports & Ravenflow analysis

  6. The Requirements Lifecycle Inception Mission Analysis System Analysis Development Deployment User Acceptance Testing System Capability Testing Unit Testing Usually created by a customer. Descriptive text,. Must be analyzed and turned into requirements. (Word) Requires discussions with end users. Defines high level user capabilities to be created or transformed by the system. Traced to user tests. (word, Visio, RM tool, RAVEN) Defines how the system will perform the required functions. Traced to system tests. (Rhapsody, Word, RM Tool, Visio) Detailed design to determine code modules and hardware components tha t need to be built. (Rational Rose, TAU, design tools) A final set of requirements is archived and saved for future reference. Requirements Artifacts Concept of Operations Business Request Vision Document System Requirements System models Allocation tables Technical Requirements Detailed Design Database Design Finalize all Requirements User Requirements Use Cases Activity Diagrams

  7. Some Current Development Methodologies • Water Fall Development • Iterative Development • Rational Unified Process (RUP) • Spiral Development • Rapid Application Development (RAD) • Agile Software Development All methodologies go through the same phases of development. Some are more formal than others.

  8. Different Views of a System System view User/stakeholder view A more technical and detailed view of the system. A view of the functions the system must perform. User’s perspective of the system. Limited to what the user sees. A very technical and detailed view of the items that are built to create the system. There is overlap in the views. There must be some understanding of other views at all levels. Technical view More technical detail is added as each view of the system is developed.

  9. Types of Use Cases • Business Use Cases • Describe how actor(s) perform a business process • Bomb threat procedure • Actors are typically organizations or departments • Application Use Cases • Describe how a user interacts with a system to perform a user process • Registering a credit card online • Actors are typically an end user and a system • System Use Cases • Describe how a system performs a function or how a system interacts with other systems • Validate ATM PIN • Actors are systems or subsystems • Technical Use Cases • Describe how a subsystem behaves to perform a system function or how a subsystem interacts with other subsystems • Communication between a cell phone and the cell tower

  10. Types of Use Cases Business Analyst System Analyst Business Use Cases Detailed Use Cases System/System Interactions Details of System Functions User/System Interactions Bank Customer/ATM Machine Driver/Automobile Photographer/Camera Caller/Cell Phone ATM Machine/Bank Automobile/GPS System Camera/Memory card Cell Phone/Cell Tower Developer Technical Use Cases Subsystem/Subsystem Interactions ATM Processor/Money Dispenser Engine/Power Train Autofocus/Light Metering System Display/Internal Memory

  11. What’s so great about use cases? • Technique for eliciting vaguely understood and unspoken requirements • Users can read and understand • Integrates with screen prototyping, user testing, system testing • Used to schedule incremental development • Inherent traceability • Facilitate reuse – developed and shared

  12. Use Cases are a Form of Requirements • User shall….. • User shall….. • User shall….. The system displays the login screen to the user. The user sends login information to the system. . Describes user interaction with the system (Textual model) List of formal requirements (Textual representation) User System Activity diagram (Visual representation)

  13. What is Visual Requirements Definition? Visual Requirements Definition (RD) complements Requirements Management (RM) solutions by enabling better: • Analysis of Customer RequirementsIdentify core processes and elicit the customer needs and requirements for optimizing the processes • Specification of Requirements Describe, organize, analyze and document processes & requirements in a consistent, business-oriented way • Validation of Requirements Share, collaborate, review and verify processes & requirements with all stakeholders from customers to development.

  14. Why model?

  15. The Flow Diagram Process • Identify all actors • Create one Flow Diagram for each Actor • List each capability the Actor will perform • Describe how capabilities fit in to the overall system design • Use arrows to indicate flow between capabilities • Add conditionals if they help understand how the system will work

  16. From Flow Diagram to Use Cases Each capability requires at least one use case. Log in Register account View account list View Estatements Transfer funds Withdraw funds Log off YES Is user registered? NO Log in Register account View account list View Estatement Transfer funds Withdraw funds Log off

  17. Use Case Details • Defined through a sequence of steps • Each step produces a result • Are realistic representations of how the user will use the system • Give developers direct insight into how stakeholders envision using the system • Provide a basis for technical requirements • Provide a basis for acceptance testing NOTE: Use cases are a form of requirements.

  18. Basic Use Case Guidelines • Active voice • Complete simple sentences • Clear transfer of control • Complete conditionals • Looping (Alternates) • Early termination of a use case (Exceptions) • Consistent level of detail

  19. A Poorly Written Use Case – Why? The Crisis Management Team sends an Emergency Alert. (to?) The IT Team sends Emergency Alert Email to the Entire Organization! The Crisis Management Team sends an Emergency Alert to the Security Organization. The Security Organization performs a walk through of the facility. If employees are found, (who looks for employees?) then the Security Organization escorts the employees out of the building. Otherwise, if the Security Organization finds no employees, then building is locked. (not active voice?) (Otherwise, what happens if employees are not found?) The Crisis Management Team sends an Emergency Alert to the Local Police. RAVEN identifies requirements errors for you.

  20. Keys to Developing Business Use Cases • Start with the simplest path (no problems) • Determine what can occur at each step and document the results • Document the other paths that can occur • Document resulting requirements (if required) • Keep the right level of detail • User actions only in user column • System responses that user sees in system column • Do not include system actions that the user does not see unless it is important to document additional steps. These will be developed during the system requirements phase. • Be careful to get Pre- and Post-Conditions right

  21. Transitioning to Detailed System Use Cases Business Use cases Detailed System Use cases Business Use Cases User System There is a process for getting from user focused use cases to detailed system use cases.

  22. Levels of Use Cases Example Bank Detailed System User Payment Processor System The System validates that payment amount is greater than zero. The System validates the payment information. The user submits the payment to the System. The System validates that payment amount is at least minimum payment. The System validates that payment amount is less that current statement Balance. The System validates that date is less than 30 days from current date. The Bank validates the Account Information. The System submits account information to the Bank. The Bank sends account Approval to the System. The System submits the payment. The System submits the payment information to the Payment Processor. The Payment Processor accepts the payment. The Payment Processor sends confirmation received message to the System. The System displays a payment confirmation message to the user. The System displays a payment confirmation message to the user.

  23. A Use Case Example • The user enters username and password. If the password is more than 30 days old, then the system asks the user to enter a new password. The user enters a password. If the password has been used in the last six months, then the password is not valid. The system performs a String function to determine the length of the password. The system loops through each character in the password and calls the TYPE function for each. The system determines if there is at least one character and one number in the password. If these tests all pass, then the password is valid. Otherwise, an error message is displayed. If the login is valid then the user is logged in to the system and views the account summary screen.

  24. Correcting Level of Detail Move these details to a system use case. Validate Password - If the password has been used in the last six months, then the password is not valid. The system performs a String function to determine the length of the password. The system loops through each character in the password and calls the TYPE function for each. The system determines if there is at least one character and one number in the password. If these tests all pass, then the password is valid.

  25. Active Voice • The user enters username and password. If the password is more than 30 days old, then the system asks the user to enter a new password. The user enters a password. The system validates the password. If the password is not valid, then an error message is displayed. If the login is valid then the user is logged in to the system and views the account summary screen. Items in RED indicate passive voice. We will correct these.

  26. Corrected Use Case • The user enters username and password. If the system determines that the password is more than 30 days old, then the system displays a new password prompt. The user enters a password. The system validates the password. If the system determines that the password is not valid, then the system displays an error message. If the system determines that the login is valid then the system displays the account summary screen.

  27. Transfer of Control • The user enters username and password and submits it to the system. If the system determines that the password is more than 30 days old, then the system displays a new password prompt to the user. The user enters a password in the system. The system validates the password. If the system determines that the password is not valid, then the system displays an error message to the user. If the system determines that the login is valid then the system displays the account summary screen to the user.

  28. Complete Conditionals • The user enters username and password and submits it to the system. • If the system determines that the password is more than 30 days old, then the system displays a new password prompt to the user. The user enters a password in the system. The system validates the password. If the system determines that the password is not valid, then t he system displays an error message to the user. • Otherwise, the system displays the account summary screen to the user. • Otherwise, the system displays the account summary screen to the user.

  29. Test Development Requirements Test Plans Requirements (use cases) and test plans should be developed together. Test plans are not an afterthought.

  30. Creating a Test Plan from a Use Case • Actor steps become the test case step • Responses to those steps are the expected results • One test case for each “path” through the use case • Basic path • Conditionals (alternates and exceptions) • Use cases provide a good basis for determining: • Complexity of a use case • Level of effort required to validate the use case

  31. When is change embraced? Pain of current situation Pain of the change

  32. A Solid Solution Advise Your People • Business analysis & requirements training certified by IIBA • Consulting & advisement from experienced practitioners Transform Your Approach • A best practices methodology for getting requirements right • Works with both structured and agile development projects Provide the Tooling • A suite of products for business & requirements analysis • Designed specifically for use during requirements definition phase of projects by all levels of system engineers

  33. It’s so complicated…. Use Case 101 Use Case Methodology Use Case Modeling Use Case Best Practices How to Write Use Cases Or is it?? It takes discipline and determination. Read. Learn. Determine how to fit use cases into your process.

  34. Ravenflow Professional Services • Professional Services Team • Business requirements experts • Best-practice advisory services • Specialists & practitioners in: • Requirements elicitation & definition • Business process improvement • Facilitation & stakeholder validation • Senior Consultants and Business Analysts • Training Services • Instructor-led on-site training classes • Train-the-trainer programs • Training curriculum includes: • Writing Effective Business Use Cases • Writing and Validating Requirements with RAVEN • Requirements Elicitation Techniques • RAVEN Administration & Management • Advanced Template Customization • Consulting Services • Requirements facilitation • Requirements definition process assessment and project review • Business process assessment, analysis, and improvement • Merger and acquisition integration • Staff augmentation

More Related