Gathering and Documenting Business Requirements

Guidelines

Overview

Business Requirements are high level statements of what the stakeholders need the system to
accomplish. Requirements succinctly list business needs and the deliverables/system functionality
required to meet those needs. Business Requirements should be concerned with the processes and
behavior needed to resolve the problem, not the method or design required to provide the solution.
The solution design will be provided later in the Functional Specifications.

The definition of a Requirements document and the level of detail required varies by organization.
For the University of Chicago, Requirements documentation includes:
Reasons the project has been initiated
Objectives it will achieve
Assumptions and constraints
Criteria that will be used to measure its success
Functional requirements (required features and functionality)
Non-functional requirements (environmental and qualitative conditions, i.e. performance,
reliability, usability, etc)

Poorly defined or incomplete requirements are a major cause of failed projects.

Requirements Work Plan

Objective: Define the work to be accomplished/deliverables and gain client acceptance.

Ensures that all requirements activities are captured

Identifies the appropriate data gathering techniques
Identifies required resources

Format is typically a Work Breakdown Structure that identifies all requirements gathering activities
and the resources required.
1. Define scope of the project (what is included/excluded)*
2. List assumptions and constraints*
3. Identify the major work components for the requirements analysis
4. Break each work component into manageable tasks
5. Identify resources required
6. Review with project sponsor and gain signoff

*These will be copied to Section 1 of the Requirements Document

 Example Requirements Work Plan:

Project: Implement GEMS II Upgrade

Scope:
Upgrade existing GEMS system to new Concur Travel and Expense Management System;
does not include implementation of the travel module nor changes to the payroll interface.

Assumptions and Constraints:

1. Upgrade will be University wide and can be rolled out incrementally by department
2. Existing Payroll interface will work with the upgraded system
3. All departments must be upgraded, as Concur is retiring the existing system in Q1 2010.

Work Plan
1.0 Identify New Reporting Requirements
1.1 Conduct focus group with the major LBCs to determine report requirements
1.2 Create draft reporting requirements
1.3 Generate mock-ups of new reports identified
1.4 Review draft requirements and report mockups with focus groups and gain
signoff
1.5 Incorporate into Requirements Document
2.0 Identify Expense Report Chain of Approval Requirements.
2.1 Create Chain of Approval scenarios for applicable situations
2.2 Conduct working session with Disbursement and major LBCs to validate
chain of approval scenarios
2.3 Based on scenarios, determine configuration requirements
2.4 Incorporate into Requirements Document.

Requirements Gathering

Requirements gathering should be an iterative process; analysis and validation will lead to additional
questions. The following elements are essential to successful requirements gathering:
Involve stakeholders throughout the process. They will help validate requirements and
provide access to the relevant resources
Ensure that all requirements are measurable and can be traced back to business goals
Ensure that all requirements have an owner who can confirm that the requirement has been met

Requirements gathering includes the following steps:

1. Define Solution Scope.

a. What is to be included / excluded
b. Expected benefits
c. Establishes clear functional boundaries as well as integration points with other systems.

Page 2 of 5
2. Determine Current State and Root Cause of the Problem.
Current state provides a baseline and insight into what the true vs. perceived problem is.
Often stakeholders mistake a symptom of the problem to be the root cause. Research
provides insight into the root cause of the problem and how the organization arrived at the
current state.

a. Current documentation. May uncover requirements or solutions that do not occur to

internal stakeholders. However, actual practice often differs from the documented
process.

b. Observation. Allows the analyst to become more familiar with the task and uncover steps
that resources do unconsciously. However, may not be totally accurate as subjects may
alter behavior when being observed.

c. Interviews. Interviews should use a prepared list of open ended questions, but allow for
deviation as new information is learned. Control is required to ensure that the interviewee
does not digress on tangents. Challenge is in knowing what questions to ask, as
interviewees will often answer only what you ask, not what you want/need to know.

i. Begin with open-ended questions

ii. Use closed-ended questions to get details
iii. Ask clarifying questions to elicit examples, definitions and exceptions
iv. Use confirming questions to ensure mutual understanding of the information gathered

d. Structured Walkthrough of the Process. Subject trains observer on how to perform task.
Observer asks questions on underlying thought processes, but must be careful not to direct
the worker or interfere with task performance. This method also helps identify
expectations or preconceptions that users bring to the process.

e. Focus groups can be used for multi-functional processes. Including representatives from
all functions allows understanding of connection, dependency and handoff points and is
good for gaining agreement from all stakeholders. In order to be successful, the BA
should use the following facilitation techniques:

i. Always plan the session

ii. Manage the process so that it does not get sidetracked on tangents, debates or
departmental issues
iii. Encourage participation of all attendees
iv. Maintain impartiality

f. Model the Current State or As-Is. Work, process, activity and/or data flows can be used
to model the current process and system.

3. Gather Requirements
Iterative process; stakeholders do not always know what they want and it may take
several attempts to correctly identify
Need to ensure that the stakeholders are focused on the requirements, not solution

Page 3 of 5
Requirements Documentation

The Requirements Document lists all the information that was elicited during the Discovery phase
and is the foundation for Design and subsequent phases. The Requirements Document is used for:
Management and control to ensure that the project stays in scope and deliverables are
traceable to requirements
Design of the new system and processes
Ensures stakeholder buy-in to the final product
Basis for User Acceptance Testing and project sign-off

The IT Services Requirements template can be found in Sharepoint in PM101/PM101-Templates.

Requirements should be:

Feasible; able implement and maintain within constraints
Necessary; required due to a business or customer need
Be complete; each requirement should be a standalone statement
Consistent; no conflict between requirements
Verifiable; requirement can be validated
Traceable; uniquely identifiable so that it can be tracked
Design independent; specifies what is needed, not how it should be provided

Good requirements focus on:

Who
What
Where
When
Under what constraints

{Who} shall {do what} {where} {when} {under what constraints}. For example: The
handset shall provide the user the ability to access their phonebook in less than 5 seconds
from handset turn on.

Where and when might

be implied by the surrounding requirements
be wherever or whenever, and therefore not necessary to state

The following are general tips that can be used in writing the Requirements Document:
Use active voice to document each requirement; i.e. Track Purchase Orders rather that
Purchase Orders should be tracked
Spell out and define abbreviations the first time used, i.e. Information Technology Services
(ITS)
Maintain consistent level of detail
Categorize requirements into related groups
Examine requirements for consistency, omissions and ambiguity
Prioritize requirements based on customer need

Page 4 of 5
 Use quantitative measures (response time of 1 second or less) instead of qualitative
descriptions (quick response time) so that achievement is measurable

Everyone gets confused about the difference between business requirements, user requirements and
Functional Requirements.
Business Requirements: Business is the central focus. Requirements are tied to strategic,
tactical and operational goals.
User Requirements: User is the central focus. Use case diagrams or other models show user
interaction with the new sysem.
Functional Requirements: System is the central focus. Requirements are tied to capabilities
the system must have to satisfy user and business requirements.

Another common mistake is to document solutions rather than requirements. Solution options
should be documented to show what stakeholders are considering, but are not part of the
requirements.

Due to cost and/or time constraints, it is improbable to find or customize a system that meets all
business requirements. Therefore it is important to prioritize requirements:
Critical (must have): core functionality that system must have in order to be successful
Important (should have): requirements that would enhance performance and should be
included, if possible
Desirable (nice to have): requirements that would enhance performance, but could be left out
if necessary
Out of scope: requirements that will not be included in the project

Once written, requirements need to be validated. It is important to verify that the documented
requirements, assumptions and constraints match those of the stakeholder.
Models help users to visualize requirements
Stakeholder review or walkthroughs can be used to validate clarity and consistency as well as
to ensure stakeholder consensus on requirements
Peer or supervisor review can be used to validate clarity, consistency and that nothing has
been omitted.

Page 5 of 5