Requirement Capturing Techniques

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

41

THANKS!

Any questions? You can find me at [email protected]