requirement gathering process (1)

7/29/2019 Requirement Gathering Process (1)

1/28

Requirement GatheringProcess

23th Feb 2013


2/28

Confidential 2010 Syntel, Inc.

Topics

2

1)Introduction

2)What is a Requirement?

3)Components of Requirements Engineering

4)Requirements gathering activities

4)Types of Requirements

5)Difference Between a Requirement and Its Attributes

6)Identify Stakeholders and Elicit Stakeholder Needs

7)Develop and Organize Requirements

8)Check Requirements


3/28


3

Introduction

According to a recent survey over 30% of all IT projects are ultimately

cancelled and over 50% of all projects fail due to overrunning costs,late deliveries, and functionality deficiencies. One third of all failed

and cancelled projects surveyed in the report had cost overruns

averaging 189% and time-to-market delays averaging an astonishing

222%. In addition, almost 40% of necessary features and functions

were not delivered.

The problems related to failed and cancelled projects are directly

related to requirement problems such as lack of user input,

incomplete requirements, and undocumented changing requirements.

3


4/28


4

What is a Requirement?

A requirement is a statement of a business need-a feature or function

that a stakeholder wants. A requirement identifies a necessaryattribute, capability, characteristic, or quality that adds value to a

system from the perspective of a stakeholder. Requirement

specifications serve as a basis for the design and implementation

stages.

As per Business Analysis Body of Knowledge (BABOK) by IIBA,

sufficiently defines a requirement as:

A condition or capability that must be met or possessed by a solution

or solution component to satisfy a contract, standard, specification orother formally imposed documents.

4


5/28


Requirements Engineering

5

Components of Requirements Engineering

5

Requirements Development Requirements Management

Elicitation Analysis Specification Validation


6/28


Requirementsgathering activities

Identify the people who can determine the requirements. They must

have knowledge of the business need.

Hold requirements gathering workshops and interviews.

Obtain and analyse any relevant documentation.

Document the requirements.

Circulate requirements for review and feedback.

Make updates and seek sign-off.

6


7/28


Types of Requirements

7


7

Business Requirement

UserRequirements

SolutionRequirements

TransitionRequirements


8/28


8


According to BABOK, there are four basic types of requirements.

When considering the types of requirements, there are three levels ofdetail and structure.

Business requirements are the highest level and the broadest interms of detail. User requirements are loosely structured and

discuss the needs of the system in terms easily understood by allstakeholders involved. Lastly, solution and transition requirementsconsist of the lowest level of details, describing exactly what is

needed to convey the appropriate message to the design team.

Solution and transition requirements should follow a strict format.

8


9/28


9

Business Requirements

Business requirements are high-level requirements that specify the

objectives that the business expects to achieve in a project. This typeof requirement provides the why behind the decision to implement

the chosen solution.

Business requirements should include the project constraints,objectives, vision statement, problem statement, business case.

An Example of Business requirement is Problem, It is always betterto know how problem statements and other business requirements do

not necessarily adhere to the rigid structure other lower-levelrequirements must follow to be clearly understood by the developers.

Features may consist of three or four words whereas problemstatements may be the length of a narrative.

9


10/28Confidential 2010 Syntel, Inc.

10

User Requirements

User requirements are requirements that specify what the user

needs in terms of the system. This type of requirement describesuser goals and tasks that users must be able to perform with the

system.

The content of a user requirement is not as detailed as the lowest

level of requirementsno technical jargon used in user requirements.

In User requirements a stakeholder can be customers, developers,users, orother interested parties that are impacted by the system.

10



11

Solution Requirements

Solution requirements are the lowest level and most detailed

requirements that are used to design and implement the system.These requirements often have acceptance criteria or a lower level of

detail that can be described by attaching requirement attributes.

Common ways of writing Solution requirements :

11

User Stories

Requirement Patterns

Functional Specification



12

User Stories

User stories are method used with Agile development that present

requirements from the perspective of an actor. User stories providesguidance on how to write requirements by using templates to write

particular types of requirements such as performance, archival and

storage, report and query.

Solution requirements are commonly broken down into two categories

12

SolutionRequirements

FunctionalRequirements

Non-Functional

Requirements



13

Functional Requirements

Functional requirements describe the behaviour and information that

the solution will manage. This type of requirement specifiesfunctionality that the developers must build into the system to enable

users to accomplish desired tasks, thereby satisfying business

requirements or objectives.

Features of Functional Requirements uses simple language

not ambiguous

contains only one point

specific to one type of user

describes what and not how

The customer must place an order within two minutes of registering

13



14

Non-Functional Requirements

According to BABOK, non-functional requirements capture conditions

that do not directly relate to the behaviour or functionality of thesolution, but ratherdescribe environmental conditions under which

the solution must remain effective or qualities that the system must

have. A non-functional requirement states how the system must

perform, but there is no way to physically build the requirement.

An example of a functional requirement is

The system shall allow the user to access his/her account 24*7days a week.

14



15

Transition Requirements

Transition requirements do not address the solution, but rather the

enterprise-wide transition to the solution. It describe capabilities thatthe solution must have to facilitate a successful transition from the

current state of the enterprise to a desired future state, but that will

not be needed once that transition is complete.

Transition requirements are not commonly reused,these requirementsare defined during solution assessment to support the necessary

change to the organization.

Transition requirements include training, data conversions and

regulatory compliance.

15



16

Difference Between a Requirement and ItsAttributes

Too many requirements in a project cause it to fail. While, incomplete

requirements could also provide the same outcome. A method offixing these common requirement development problems is to use

attributes, which are items that are needed to make a requirement

complete.

RequirementThe system shall provide an online employee directory.

Attributes:

Shall display employee last name, first name, location, and employee ID number.

Shall be sorted and displayed in alphabetical order.

Shall be able to search for an employee using the last name.

Shall comply with corporate usability and design standards.

16

d if k h ld d li i k h ld



17

Identify Stakeholders and Elicit StakeholderNeeds

Identify Stakeholders

The first step in gathering requirements is to identify the stakeholdersinvolved with the project. The problems of incomplete requirements and a

lack of user input are often due to a poor identification of all project

stakeholders.

It is important to define the different types of stakeholders within the

organization because of unique perspective and set of requirements. Ithighly benefits business analysts to listen to different viewpoints when

attempting to develop the most complete set of stakeholder needs.

17

d if S k h ld d li i S k h ld



18

Identify Stakeholders and Elicit StakeholderNeeds

Elicit Stakeholder Needs

It is important that users are able to define the system that they are to

use. However, users often have a difficult time describing a new or

improved system, but they know what their problem is and why they

would like it fixed.

The responsibility of a business analyst is to gather all stakeholder

needs and analyze those needs to create requirement specifications.

An important task for business analysts is to research and reviewthe most effective elicitation techniques for the project, analyzing what

the project team has learned about impacted stakeholders.

18



19

Elicit Stakeholder Needs

.

19



20

List of possible elicitation methods

Interviews

Observation

Requirement Workshops

Focus Groups and Surveys

Activity Sampling

Document Review

20



21

Develop and Organize Requirements

Rigid Structure

A rigid grammatical structure, while seemingly redundant at times,

helps to ensure there is only one interpretation of a requirement.

Word Choice

The business analyst also needs to ensure the words chosen to

convey the requirement statement are the best choice.

The best requirements statements are simple, direct and have alimited vocabulary. Requirements specification vocabulary should be

uncomplicated and clear to mitigate the risk of confusion.

21



22

Develop and Organize Requirements

Complete The Requirement

Few requirements are complete without some sort of extra details.

Often, the business analyst needs to create attributes for

requirements orattach lists, figures, graphs, tables, and models.

Document Requirements

Requirements can be documented with user stories, requirementpatterns, and functional specifications. User stories are a methodcommonly used with Agile development that present requirements

from the point of view of an actor.

22



23

Check Requirements

Requirements should be validated on two separate occasions in the

duration of a project: once the specifications have been written and

once the bundles have been created. Business analyst needs toensure the requirements not only hold up to the qualities of good

requirements but that they will achieve the desired business

objectives.

Requirements must be :-

Accurate

Atomic

Complete

Modifiable

Practical Prioritized

Traceable

Unambiguous

Valuable

23



24

Examples of Requirements

Functional Requirements

1.Archival and Storage2. Master Data3. Configuration

4. Report5. Dashboards6. Searches and Filters7. System Interface8. User Interface9. Transaction Processing

24



25


Non-Functional Requirements

1.Availability2.Accessibility3.Audit, control, and reporting

4. Backup and Restore5.Accuracy6. Capacity, current and forecast7. Certification8. Concurrency9. Disaster recovery10.Deployment

25



26


Transition Requirements

1. Documentation

a) Support Documentation

b) User Documentation

2. Data Conversion

a) Data Conversions

b) Temporary Interfaces

26



27


Process Change Requirements

1. Business Rules2. Customer Relationship3. Process Flow

4. Supplier Relationship5. Workflow

27


28/28

Syntel is Committed to Excellence in Service.

Our mission is to create new opportunities for our clients by harnessing ourpassion, talent, and innovation!

Thank You

requirement gathering process (1)

Documents