Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Requirement Capturing Techniques

172 views

Published on

A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement.User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template

Use Case and User Story Explained with example

Published in: Technology
  • Be the first to comment

Requirement Capturing Techniques

  1. 1. 1 Requirement Capturing Techniques
  2. 2. HELLO! I am Abhinav Sabharwal You can find me at skyabhinav@gmail.com https://www.linkedin.com/in/abhinavsabharwal/ 2
  3. 3. 3 WHY THIS UPDATE This Presentation Has been Updated One of my friends complained that in my last presentation Basics of requirement gathering (https://www.slideshare.net/skyabhinav/basics-of-requirment-gathering) I have not given proper treatment to User Stories hence this detail presentation. I am now deleting that Presentation from slideshair. I am also deleting my presentation on User Stories(https://www.slideshare.net/skyabhinav/user-storyies-explained) this presentation now contains material of both the presentations and more Thanks Sarbjit Multani (https://www.linkedin.com/in/sarbjit-multani-020abaa4/) for Inspiring this presentation
  4. 4. 1. USE CASE 4
  5. 5. USE CASE ▸In software and systems engineering, a use case is a list of actions or event steps, ▸Defining the interactions between a role (known as an actor) and a system, ▸To achieve a goal. ▸The actor can be a human or other external system. 5
  6. 6. ▸Lets Look at the Structure of Use Case 6 Case ID This is the unique identifier that you use to reference the use case from other artifacts that you create as part of developing your software product You will use the use case ID to trace between the use case and the goals it enables. You will also trace between the use case and the functional and non-functional requirements that support it Title The title, or name of the use case. This should be a simple sentence that describes the use case Author That would be you. Enter the name of the person responsible for authoring the use case. Use Case Version The version of the use case can be used to keep track of each draft or revision of the document Status Draft/Proposal/Approve /Rejected STRUCTURE OF USE CASE
  7. 7. 7 PRE CONDITIONS Description of the affected portions of the state of the system Before Use Case is Started Actors – The people who execute the use case are the actors. Not “Tim” and “Joan,” but rather “Office Clerk” and “Department Supervisor Normal Flow – This is where the description of your use case goes. The goal here is to write just enough to clearly define the use case. The individuals on your team will have the biggest impact on what enough is for you. Most use cases involve some branching or decisions. The normal flow should not include these “if…then” constructs. The normal flow should include the most-common or most-valuable path through the use case. Alternate Flows This is where those uncommon and lower-value paths are documented. Imagine a use case for processing invoices. The normal course would describe how pending invoices are handled. An alternative flow might handle how past-due invoices are handled. A second alternate flow could handle customers with credit-balances in their accounts. STRUCTURE OF USE CASE
  8. 8. 8 Exception Flows Descriptions of what the user will experience when something goes wrong. Post-conditions – Description of the affected portions of the state of the system after the use case has completed. Frequency of use An estimate of how often a particular use case will be exercised Assumptions Any assumptions that are implicit in the definition of the use case STRUCTURE OF USE CASE
  9. 9. 9 USE CASE EXAMPLE ▸Lets Take a Example of a simple Login Screen for Gmail and see how Use Case Will Be
  10. 10. 10 USE CASE EXAMPLE
  11. 11. ▸Lets Look at the Structure of Use Case 11 Case ID 001 Title User Login Author Abhinav Sabharwal Use Case Version 1.0 Status Draft/Proposal/Approve /Rejected USE CASE EXAMPLE
  12. 12. 12 PRE CONDITIONS Browser is available and Open, Internet is available User Has Gmail ID Actors – Registered Gmail User Normal Flow – 1) User Enters email id 2) Users Enter the Password 3) Credentials are successfully authenticated 4) Inbox Screen is Displayed Alternate Flows 1) User Enters email id 2) Users Enter the Password 3) User Cancels The Login Process by Clicking on cancel button 4) User Id and password field are cleared USE CASE EXAMPLE
  13. 13. 13 Exception Flows 1) User Enters email id 2) Users Enter the Password 3) Credentials are NOT successfully authenticated 4) Error Message is Displayed “Invalid User Id or Password” Post-conditions – User Is Able to View Inbox and Read Messages. Frequency of use Rarely/ Regularly /Often Assumptions User Know how to login to Gmail account USE CASE EXAMPLE *Please Note: Post Condition is always in relation to Normal Flow
  14. 14. 2. USER STORIES 14
  15. 15. USER STORIES ▸User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. ▸ ▸User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. ▸ As such, they strongly shift the focus from writing about features to discussing them. ▸User stories is that they can be written at varying levels of detail. 15
  16. 16. USER STORY ▸User Story is only meant to describe a feature, but not describe how to implement it, ▸leaving out the technical aspect, User Story should describe the behavior or flow from user’s perspective 16
  17. 17. USER STORY ▸A user story is a tool used in Agile software development ▸It is used to capture a description of a software feature from an end- user perspective. ▸The user story describes the type of user, what they want and why. ▸A user story helps to create a simplified description of a requirement 17
  18. 18. ▸Lets Look at the Structure of User Story 18 STRUCTURE OF USER STORY
  19. 19. 19 USER STORY EXAMPLE
  20. 20. 20 USER STORY: CHARACTERISTICS ▸A story should be complete and big enough to provide a user with some value ▸ The user story should be user-centric, ▸When the user story is done, the user can do something of value to them
  21. 21. 21 DISCOVER RIGHT STORIES ▸Capture your insights about the users and customers is working with personas. ▸ Personas are fictional characters that are based on first-hand knowledge of the target group. ▸ Personas consist of a name and a picture; relevant characteristics, behaviors, and attitudes; and a goal. ▸The goal is the benefit the persona wants to achieve, or the problem the character wants to see solved
  22. 22. 22 DISCOVER RIGHT STORIES
  23. 23. 23 INVEST IN USER STORY
  24. 24. 24 INVEST IN USER STORY ▸Test user stories by using INVEST acronym ▸Independent — Can the story stand alone by itself ? ▸Negotiable — Can this story be changed or removed without impact to everything else? ▸Valuable — Does this story have value to the end user? ▸Estimable — Can you estimate the size of the story? ▸Small —Is it small enough? ▸Testable — Can this story be tested and verified?
  25. 25. ▸A story should be small enough to be coded and tested within an iteration—ideally just a few days ▸The agile recommendation is to break down a set of user stories into smaller ones, containable into a single sprint duration, or ideally, not more than a week. ▸Avoid having child stories, it is not a good recommendation to have user story in nested hierarchy 25 SIZE & DETAIL OF USER STORY
  26. 26. ▸Sometimes a story will be small enough if we do too much slicing vertically, other time it get way too bigger, as we keep on stuffing the feature in one single user story. ▸This is why we have story points. The points are a fuzzy measurement of how big or small a story is, ▸User Story should be estimated by the engineer(s) who are implementing it or someone with superior knowledge about the work. ▸Organization/team there should have a standard scale for story points measure, so you can compare multiple stories 26 STORY POINT & USER STORY
  27. 27. 27 DoD & CoS FOR USER STORY ▸As you fine-tune your estimation, the team should be able to reliably pick up as many stories as they can handle ▸Define your Definition of Done (DoD) for stories, acceptance criteria or condition of satisfaction (CoS ) ▸This helps set expectations within the team as to when a team should consider something done.
  28. 28. 28 DoD & CoS FOR USER STORY ▸Acceptance criteria complement the narrative: ▸They allow you to describe the conditions that have to be fulfilled so that the story is done. ▸The criteria enrich the story, they make it testable, ▸As a rule of thumb, use three to five acceptance criteria for detailed stories
  29. 29. 3. H - METHOD 29
  30. 30. 30 H - METHOD ▸The H-method is an analysis tool that aids the BA in organizing a fact finding interview with a business representative or system user. ▸Let’s consider a typical interviewing process. ▸Without the use of a framework for organizing an interview, an analyst and business representative will often participate in a relatively unstructured dialogue in which the analyst asks questions such as: ▸Tell me what you do? ▸What does your system do? ▸Who do you interact with? ▸Why is “x” important?
  31. 31. 31 H - METHOD ▸Based on the answers given the analyst will continue to ask follow up questions. ▸The success of the fact finding is typically dependent upon the experience level of the analyst. ▸While this method can work, the analyst will often walk away with several pages of unstructured notes. ▸Important information must then be extracted and organized into something meaningful and useful. ▸ Only then we will be able to determine if we have all of the necessary pieces of information or if there are still gaps in their understanding
  32. 32. 32 H - METHOD ▸Based on the answers given the analyst will continue to ask follow up questions. ▸The success of the fact finding is typically dependent upon the experience level of the analyst. ▸While this method can work, the analyst will often walk away with several pages of unstructured notes. ▸Important information must then be extracted and organized into something meaningful and useful. ▸ Only then we will be able to determine if we have all of the necessary pieces of information or if there are still gaps in their understanding
  33. 33. 33 H - METHOD ▸The H-method uses the following “H” shaped diagram to provide a structured framework to guide the interview and to allow the analyst to captured information in an organized way from the start.
  34. 34. 34 H - METHOD ▸The H-method uses the following “H” shaped diagram to provide a structured framework to guide the interview and to allow the analyst to captured information in an organized way from the start.
  35. 35. 35 H - METHOD ▸Inputs & Outputs ▸By defining the inputs and outputs, the scope can be further refined. ▸By defining what comes into the area, and what is produced, it helps define scope at a lower level of detail. ▸Functionality ▸Functionality will be at different levels of granularity. ▸At the first interview, it is better to keep focused on getting information rather than sorting information.
  36. 36. 36 H - METHOD ▸Data ▸The question "What are the people, places and things you want to keep track of?" is invaluable for a BA. ▸ The vast majority of users don't think in terms of databases. ▸. Data comes up all through a discussion. When it does, drop it in this box. ▸Business Rules ▸As rules emerge, they should be dropped into the business rules box. Like data, they are woven through everything the BA is told.
  37. 37. 37 H - METHOD ▸Business Processes ▸Depending on the scope of the discussion, it may be useful to break it down into discreet business processes. ▸For example, an order fulfillment area may have the following business processes: ▸Order placement ▸Order fulfillment ▸Invoice creation ▸It is up to the Business Analyst to determine the appropriate level of granularity to use when undertaking the analysis
  38. 38. 38 H - METHOD EXAMPLE
  39. 39. 39 H - METHOD EXAMPLE
  40. 40. 40 CONCLUSION ▸There are many methodologies including functional decomposition, DFD, Workflows, Use Cases etc. that can be used ▸IT is up to B.A to choose the one that fits the project, I have explained here three of the most popular ones
  41. 41. 41 THANKS! Any questions? You can find me at skyabhinav@gmail.com

×