From Use case to User Story
•Download as ODP, PDF•
70 likes•15,047 views
A use case training given on July 2009 to team in Fifth Third to start using Use Case as part of project execution.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (6)
Similar to From Use case to User Story
Similar to From Use case to User Story (20)
Recently uploaded
Recently uploaded (20)
From Use case to User Story
- 1. FROM USE CASE to USER STORIES
- 11. Use Case Concepts and Definitions
- 32. Use cases Process Flow
- 35. Actor-Goal List L Find unfinished task and reject it Reject unfinished task Support H Receive request and approve it Approve Request Approver H Make change in edit group and send it Submit Change Request Requestor Prio Brief Descriptions Goals Actor
- 38. Use Case Best Practices
- 64. User Stories Scrum methodology
- 69. Use Case vs User Stories When to use What
- 71. Documentation Overhead source : http://tynerblain.com
- 73. Level of Details captured source : http://tynerblain.com
- 74. Level of Reader expertise source : http://tynerblain.com
- 76. Q&A
Editor's Notes
- discuss background, and explain about segments and at the end of each segments I will pause for any discussions
- Here is how we visualize a software project
- 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
- You might say that this is more for the IT folks, that is not completely true. Example is IDEO story. How innovation is produced from multidiscipline cooperation You will also be involved from .
- 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.
- 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.
- 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.
- This is where use cases come in. Use cases is the interaction between an external actor and the system
- Technical requirements include functional requirements based on user requirements and nonfunctional requirements
- Use cases are fundamentally a text form. The scenario describes how the system should respond to a request of a primary actor to deliver a specific goal of that actor.
- (bullet points first) Incidentally actor can be a person, job title or a thing, although generally it is a role The SuD is also an actor.
- A scenario describes a sequence of steps that are executed in order to fulfill the goal the use case is supposed to deliver.
- We just discussed about some of the use cases components, now we’ll look into the detail of different properties of the each use case
- There are different scope depends on the type of use cases
- From Alistair Cockburn.
- How do we develop use cases
- example is shown in the table
- 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
- The first step is to just name the use cases, and not the details
- best practice on how to give a name
- elicit: to draw or bring out or forth; educe; evoke: to elicit the truth; to elicit a response with a question.
- This is different than the Design Scope
- trigger: customer wants money, responses: ATM gave out the money
- a context diagram is a simple diagram that represents the system as a single ‘black box” surrounded by its major interfaces, thus showing the system in its environment.
- 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 ?
- A requirement model is a set of models which acts as a blueprint for a software product. Example are: event lists, use cases, context diagrams, data models, business rules, actor maps, storyboards Defining requirement is a discovery process for users and customers. It evolve from the process of users trying out their requirements through models. Using multiple views (behavior, structure, dynamics, or control ) gives a rich context for eliciting user requirements and aligns with separation of concerns.
- The list is with order of increasing complexity
- 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."
- conventionally you read use case diagrams from left to right, with actors initiating use cases on the left and actors that receive use case results on the right. Also put primary actor on the top.
- When use case A specializes use case B (or B generalizes A) you express that A is “a kind of” B, implying that whatever applies to B also applies to A. A adds to or may override behavior of B.
- A typical example is a Summary use case that includes User Goal use cases, or User Goal use case that includes some reusable Subfunction use case. The included use case is typically not complete on its own and is required part of the larger use cases.
- Karl Wieger’s Structured Requirements Software Requirements, 2nd Edition, Karl E. Wiegers .
- See next screen. Formal and informal use cases describes different permutations. Use case brief may use single paragraph. User stories provides the least context. http://tynerblain.com/blog/2009/02/02/user-stories-and-use-cases/comment-page-1/#comment-497898
- http://tynerblain.com/blog/2009/02/02/user-stories-and-use-cases/ Use case briefs may be a single paragraph use case
- User stories, as it has less overhead of documentation, it also captures less detail. It is ok with assumption the communication is high. At some point it becomes inefficient.
- The level of conversation will be influenced by the level of the reader domain expertise. If the reader already understand the requirements, user stories might be enough. When the developer team struggles to implement the stories, then a more structured documentation is needed. Can the writer trust the reader will understand with brief information ?