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.
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
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
· 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 3 of 5