Use Case - Introduction
Download as PPT, PDF3 likes461 views
This document discusses best practices for requirements gathering and use case modeling. It explains that requirements define the necessary capabilities and constraints for a software project. Requirements should be gathered from three perspectives: business goals and objectives, user interactions and workflows, and technical specifications. The key best practices for effective requirements gathering are to properly scope the problem domain, define discrete use cases, validate use cases with stakeholders, determine the right elicitation strategy, and maintain a project glossary. Following these practices helps ensure requirements capture the needs of all stakeholders and provide a solid foundation for project success.
![Best practices
action verb + [qualified] object
eq: place order, request product or
service
avoid vague verbs, such as do or
process
bad example: do ticketing](https://image.slidesharecdn.com/usecasesfortoastmaster-124114598103-phpapp02/85/Use-Case-Introduction-14-320.jpg)
Use Case - Introduction
- 3. Why are Requirements important 1/3 budget to correct errors originate from requirements Defining requirements is crucial to all project stakeholders Many techniques and models available USE CASE MODEL
- 4. Why should you be interested ? IDEO Story: Biker water bottle – heart valve Multidiscipline cooperation
- 5. What are Requirements It covers : Functional requirements User requirements Nonfunctional requirements Quality attributes: performance, security, archiving, database defined operational capabilities business needs satisfy
- 6. Software Requirements Three perspectives: Business level User level Technical level
- 7. Business Level Clarify business’ goals and objectives Define the vision to achieve it Ensure building the right software Define correct project stakeholders: including direct users (actors)
- 8. User Level Use cases : are “voice of customers” • interaction • has name • step-by-step • exception conditions • variant paths
- 9. Technical Level Technical requirements Functional requirements based on user requirements Nonfunctional requirements
- 10. Software Requirements Recap: Business level User level Technical level
- 11. 5 Best Practices Scope the domain Scope your use cases Validate use cases Determine the strategy to elicit requirements Develop a project glossary
- 12. 1. Scope the Domain Manage avoidable scope creep Be flexible on unavoidable market and business condition changing
- 13. How to name a Use Case What’s in a name ? Well named use cases enable business customers to easily infer who the actor is
- 14. Best practices action verb + [qualified] object eq: place order, request product or service avoid vague verbs, such as do or process bad example: do ticketing
- 15. 2. Scope Your Use Cases A use case addresses a single actor goal is not overly complex avoid partial processes in the business
- 16. 2. Scope Your Use Cases Frame each use case with: triggering events event responses
- 17. 3. Validate Use Cases Questions to validate: help achieve goals and visions ? address the problem ? key differentiator ? address all stakeholders ? priority for initial release ?
- 18. 4. Determine Your Elicitation Strategy Commercial software: market surveys, on-site visits, facilitated workshops In-house business system with large user base: review help desk logs, reusing existing requirements, workshops Smaller user base: facilitated workshops and observation.
- 20. 5. Develop Glossary communication gaps between software vs business people each side has its acronyms and jargon glossary should be a living, vital part
- 21. Summary Software Requirements: Business User Technical Best Practices: scope domain scope use cases validate use cases elicit requirements glossary
- 22. Q & A Reference: Ellen Gottesdiener, “Use Cases: Best Practices”, IBM, 6/11/2003
Editor's Notes
- #3: Here is how we visualize a software project
- #4: Typical software projects spend roughly one-third of their overall budget correcting errors that originate in requirements project stakeholders such as clients, end users, develoeprs, testers and managers Years of experience led to development of a number of techniques and models to assist the process Use case model is the most well-known
- #5: Toastmasters: How innovation is produced from multidiscipline cooperation. Maybe you are interested to change job ? Traditional water bottle designs require the user to bite a dispensing spout to pull it out, but this new bottle features a self-closing valve that opens only when the bottle is squeezed.
- #6: To understand Use Case, first let’s take a look at Requirements. Requirements are the defined operational capabilities of a system or process that must exist to satisfy a business need. User requirements: tasks that users need to achieve using the software.
- #7: Requirements don’t come out of thin air. They are products of systematic discovery and definition process where analyst plays a key role. Software requirements came from process of thinking through three perspectives of requirements.
- #8: At the highest level (or business level), you begin by understanding and clarifying the business’ goals and objectives. Then you define the vision on how to achieve it. You ensure that you will build the right software. In addition, you also define the correct project stakeholders.
- #9: This is where use cases come in. Use cases describes the interaction between an external actor and the system, thereby documenting a major function that the system will perform. At a minimum it has a name and contains of step by step actions. It sometimes include exception conditions and variant paths.
- #10: Technical requirements include functional requirements based on user requirements and nonfunctional requirements
- #11: use cases lie in-between the business and technical perspectives and provide the basis on which all development and testing is based
- #13: scope creep: scope of the projects expands as the work proceeds requirements may change because of changing market and business conditions -> unavoidable manage the avoidable scope creep
- #14: The first step to manage the scope is to create use cases and just name the use cases, and not the details.
- #15: Fifth Third
- #18: Ensure that each one is necessary to meet the business opportunities in your product vision. To validate, answers the following questions; How does this uc help us achieve our goals and visions Does this use case address some aspect of the problem in our problem statement ? Does this use case differentiate our product in some way ? Do we have use cases to address all the stakeholder and user groups we identified in our vision statement Which use cases will be implemented in our initial release ?
- #20: A man is flying in a hot air balloon and realizes he is lost. He reduces height and spots a man down below. He lowers the balloon further and shouts: "Excuse me, can you tell me where I am?" The man below says: "Yes you're in a hot air balloon, hovering 30 feet above this field." "You must be a software developer," says the balloonist. "I am," replies the man. "How did you know?" "Well," says the balloonist, "everything you have told me is technically correct, but it's of no use to anyone." The man below says, "You must work in business as a manager." "I do," replies the balloonist, "but how did you know?" "Well," says the man, "you don't know where you are or where you are going, but you expect me to be able to help. You're in the same position you were before we met but now it's my fault."