Domain and Requirements Analysis
Refine Requirements to Product Backlog Item with Use Case
In Scrum, the product backlog is the single source of requirements that be ordered list of everything; features, stories, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. In the product backlog, the product backlog items (PBI) have the attributes of a description, order, estimate, and value:
By far, the predominant way for a Scrum team to express features in the product backlog is in the form of user stories, which are short, simple descriptions of the desired functionality told from perspective of the user. An example would be, “As a shopper, I can show my current balance amount so that I know how much I have spent.”
Unlike the traditional requirement capturing, User Story focuses on what the user needs instead of what the system should deliver. This leaves room for further discussion of solutions and the result of a system that can really fit into the customers' business workflow, solving their operational problems and most importantly adding value to the organization.
Product Backlog items often include test descriptions that will prove its completeness when “Done.” User stories aren’t just single sentence affairs. The product owner also writes acceptance criteria, which define the boundaries of a user story, and are used to confirm when a story is completed and working as intended. For example, if this is your user story: As a conference attendee, I want to be able to register online, so I can register quickly and cut down on paperwork, the acceptance criteria could include:
Writing the acceptance criteria is the first step of fleshing out the details of your user story.
Use Case can be used to refine product backlog items since Use Cases are used to capture user (actor) point of view while describing functional requirements of the system. They describe the step by step process a user goes through to complete that goal using a software system.
A Use Case is a description of all the ways an end-user wants to "use" a system. Use Cases capture all the possible ways the user and system can interact that result in the user achieving the goal. They also capture all the things that can go wrong along the way that prevent the user from achieving the goal.
A use case is usually created as documents, and generally include this kind of information:
Use Case 01 — Show the current balance amount
This use case allows a mobile application to inquiry the current balance amount in THB of each account and shown on the first screen of the mobile application.
Mobile application (Primary)
Login, before this use case begins the customer has logged onto the system.
Flow of Events:
Alternative Flows (Note alternative flows can be splited to be the Use Case in case of development team cannot deliver both success flow and alternative flows in the Sprint)
2. Condition 2
Pass all Acceptance Test Cases
REST structure with data of <XXX> delivers to mobile applicaiton
Non-Functional Test Exit Criteria
For each use case following the example above is not enough you must have the additional artifacts with it, too. In example the list below:
© 2019 Digcode.com. All rights reserved.