requirement capturing techniques
TRANSCRIPT
1
Requirement Capturing Techniques
HELLO! I am Abhinav Sabharwal You can find me at [email protected] https://www.linkedin.com/in/abhinavsabharwal/
2
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
1. USE CASE
4
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
▸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
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
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
USE CASE EXAMPLE ▸Lets Take a Example of a simple Login Screen for Gmail and see how Use Case Will Be
10
USE CASE EXAMPLE
▸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
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
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
2. USER STORIES
14
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
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
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
▸Lets Look at the Structure of User Story
18
STRUCTURE OF USER STORY
19
USER STORY EXAMPLE
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
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
DISCOVER RIGHT STORIES
23
INVEST IN USER STORY
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?
▸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
▸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
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
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
3. H - METHOD
29
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
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
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
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
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
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
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
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
H - METHOD EXAMPLE
39
H - METHOD EXAMPLE
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
