Requirement Gathering Process

23th Feb 2013

Topics
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
2
Confidential 2010 Syntel, Inc.

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 3
Confidential 2010 Syntel, Inc.

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 necessary attribute, 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 or other formally imposed documents.

4 4
Confidential 2010 Syntel, Inc.

Components of Requirements Engineering

Requirements Engineering

Requirements Development

Requirements Management

Elicitation

Analysis

Specification

Validation

5 5
Confidential 2010 Syntel, Inc.

Requirements gathering 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
Confidential 2010 Syntel, Inc.

Types of Requirements
Types of Requirements

Business Requirement

User Requirements

Solution Requirements

Transition Requirements

7 7
Confidential 2010 Syntel, Inc.

Types of Requirements
According to BABOK, there are four basic types of requirements. When considering the types of requirements, there are three levels of detail and structure. Business requirements are the highest level and the broadest in terms of detail. User requirements are loosely structured and discuss the needs of the system in terms easily understood by all stakeholders involved. Lastly, solution and transition requirements consist 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 8
Confidential 2010 Syntel, Inc.

Business Requirements
Business requirements are high-level requirements that specify the objectives that the business expects to achieve in a project. This type of 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 better to know how problem statements and other business requirements do not necessarily adhere to the rigid structure other lower-level requirements must follow to be clearly understood by the developers. Features may consist of three or four words whereas problem statements may be the length of a narrative.
9 9
Confidential 2010 Syntel, Inc.

User Requirements
User requirements are requirements that specify what the user needs in terms of the system. This type of requirement describes user 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, or other interested parties that are impacted by the system.

10 10
Confidential 2010 Syntel, Inc.

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 :

User Stories

Requirement Patterns

Functional Specification

11 11
Confidential 2010 Syntel, Inc.

User Stories
User stories are method used with Agile development that present requirements from the perspective of an actor. User stories provides guidance 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
Solution Requirements

Functional Requirements

NonFunctional Requirements
12 12

Confidential

2010 Syntel, Inc.

Functional Requirements
Functional requirements describe the behaviour and information that the solution will manage. This type of requirement specifies functionality 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 13
Confidential 2010 Syntel, Inc.

Non-Functional Requirements
According to BABOK, non-functional requirements capture conditions that do not directly relate to the behaviour or functionality of the solution, but rather describe 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 system shall allow the user to access his/her account 24*7 days a week.
The

14 14
Confidential 2010 Syntel, Inc.

Transition Requirements
Transition requirements do not address the solution, but rather the enterprise-wide transition to the solution. It describe capabilities that the 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 requirements are defined during solution assessment to support the necessary change to the organization. Transition requirements include training, data conversions and regulatory compliance.

15 15
Confidential 2010 Syntel, Inc.

Difference Between a Requirement and Its Attributes

Too many requirements in a project cause it to fail. While, incomplete requirements could also provide the same outcome. A method of fixing these common requirement development problems is to use attributes, which are items that are needed to make a requirement complete.
Requirement The 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 16
Confidential 2010 Syntel, Inc.

Identify Stakeholders and Elicit Stakeholder Needs

Identify Stakeholders

The first step in gathering requirements is to identify the stakeholders involved 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. It highly benefits business analysts to listen to different viewpoints when attempting to develop the most complete set of stakeholder needs.

17 17
Confidential 2010 Syntel, Inc.

Identify Stakeholders and Elicit Stakeholder Needs

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 review the most effective elicitation techniques for the project, analyzing what the project team has learned about impacted stakeholders.

18 18
Confidential 2010 Syntel, Inc.

Elicit Stakeholder Needs

.

19 19
Confidential 2010 Syntel, Inc.

List of possible elicitation methods

Interviews Observation Requirement Workshops Focus Groups and Surveys Activity Sampling Document Review

20 20
Confidential 2010 Syntel, Inc.

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 a limited vocabulary. Requirements specification vocabulary should be uncomplicated and clear to mitigate the risk of confusion.

21 21
Confidential 2010 Syntel, Inc.

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 or attach lists, figures, graphs, tables, and models.
Document Requirements

Requirements can be documented with user stories, requirement patterns, and functional specifications. User stories are a method commonly used with Agile development that present requirements from the point of view of an actor.

22 22
Confidential 2010 Syntel, Inc.

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 to ensure 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 23
2010 Syntel, Inc.

Confidential

Examples of Requirements
Functional Requirements

1. Archival and Storage 2. Master Data 3. Configuration 4. Report 5. Dashboards 6. Searches and Filters 7. System Interface 8. User Interface 9. Transaction Processing

24 24
Confidential 2010 Syntel, Inc.

Examples of Requirements
Non-Functional Requirements

1. Availability 2. Accessibility 3. Audit, control, and reporting 4. Backup and Restore 5. Accuracy 6. Capacity, current and forecast 7. Certification 8. Concurrency 9. Disaster recovery 10.Deployment

25 25
Confidential 2010 Syntel, Inc.

Examples of Requirements
Transition Requirements

1. Documentation
a) Support Documentation b) User Documentation 2. Data Conversion

a) Data Conversions b) Temporary Interfaces

26 26
Confidential 2010 Syntel, Inc.

Examples of Requirements
Process Change Requirements

1. Business Rules 2. Customer Relationship 3. Process Flow 4. Supplier Relationship 5. Workflow

27 27
Confidential 2010 Syntel, Inc.

Thank You

Syntel is Committed to Excellence in Service. Our mission is to create new opportunities for our clients by harnessing our passion, talent, and innovation!