“THE CLIENT” Statement of Business

Requirements (SoBR)

Prepared By: Trice Johnson

IIBA Houston

Version: 1.0
Version Date: July 9, 2009

<Enter Confidentiality Statement Here>

―THE CLIENT‖ Confidential & Proprietary
This documentation is extremely sensitive; please limit distribution. No part of this
document may be photocopied, disclosed, or otherwise provided to third parties.
 <Enter the document name and version here>
Version: 1.0,

Revisions
Project Name: Corporate Intranet Redesign Project (Mock Scenario)
Prepared By: Trice Johnson Document Version No.:
Reviewed By: ―The Client‖ Review Date

Revision History
Ver. No. Ver. Date Revised By Description
1.0 06.09.2009 T. Johnson Mock version of a project for the July 9, 2009 IIBA Houston Chapter meeting

Distribution List
From Date Phone/Fax/Email
Trice Johnson 06.09.2009 In Person

To Action* Date Phone/Fax/Email

IIBA Meeting Participants Review 06.09.2009 In Person

* Action Types: Approve, Review, Inform, File, Action Required, Attend Meeting, Other (please specify)

―Writing Good Requirements‖ – Trice Johnson i

IIBA Houston Chapter
 <Enter the document name and version here>
Version: 1.0,

TABLE OF CONTENTS
Revision History ............................................................................................................ i
Distribution List ............................................................................................................. i
1. INTRODUCTION ................................................................................ 3
2. EXECUTIVE SUMMARY .................................................................... 4
2.1. Problem Statement ............................................. Error! Bookmark not defined.
2.2. Business Need ................................................................................................... 5
2.3. Key Objectives ................................................................................................... 5
2.4. Stakeholder Matrix ............................................................................................. 5
3. SCOPE MANAGEMENT .................................................................... 6
3.1. Scope Objectives ............................................................................................... 6
3.2. In Scope Requirements ...................................................................................... 6
3.3. Out of Scope Requirements ............................................................................... 7
4. CONSTRAINTS, ASSUMPTIONS, & RISKS ...................................... 7
4.1. Constraints ......................................................................................................... 7
4.2. Assumptions....................................................................................................... 7
4.4. Risks .................................................................................................................. 8
5. GAP ANALYSIS ................................................................................. 8
6. AS-IS PROCESS MAP ....................................................................... 9
7. TO-BE PROCESS MAP ................................................................... 10
8. TO BE REQUIREMENT LIST ........................................................... 11
9. HIGH LEVEL FUNCTIONAL REQUIREMENTS ............................... 12
10. USE CASE SCENARIOS ................................................................. 13
11. USE CASE DIAGRAMS ................................................................... 15
12. DOCUMENT ORGANIZATIONAL SIGNOFFS ................................. 17

―Writing Good Requirements‖ – Trice Johnson ii

IIBA Houston Chapter
 <Enter the document name and version here>
Version: 1.0,

1. INTRODUCTION

The ―THE CLIENT‖ Statement of Business Requirements (SoBR) is intended for use by the
business/project sponsor, Subject Matter Experts (SMEs) and, development team, and internal
business analysts. It is intended to capture relevant business objectives and requirements salient
to the project or program to be developed. Specifically, this document is intended to:
Establish and articulate the prioritized business objectives
Establish existing / as-is business process flows and business scenarios
Clearly document the vision and needs of key stakeholders and/or project sponsors, in
addition to inputs from the Project Manager, technical lead, and development team
Document constraints, assumptions, dependencies and risks related to capturing and
documenting business requirements
Provide the functional requirements based upon and aligned with the business
needs/requirements from the sponsor, stakeholders, and Subject Matter Experts (SMEs)

―Writing Good Requirements‖ – Trice Johnson 3

IIBA Houston Chapter
 <Enter the document name and version here>
Version: 1.0,

2. Executive Summary
This document has been prepared for ―The Client‖ and key staff for business and technology
planning and design purposes.
The purpose of this document is to present an overview of the current business processes involved
in and associated with the organization‘s existing Intranet system. This document presents a
business architecture view that supports ―The Client‘s‖ goal to implement improvements to the
enterprise Intranet environment.
The SoBR is divided into five major parts:
Part 1 – Executive Summary: Provides a concise description of the business issue, and
provides insight on how the business expects the problem to be solved.
Part 2 – Scope Management: Describes the process for managing the ―The Client‖
requirements process, and for maintaining requirements baselines.
Part 3 – Constraints, Assumptions, & Risks: Constraints describe a circumstance that
poses as a bottleneck or restricts a process or system from achieving its potential.
Assumptions describe circumstances and events that need to occur for the project to be
successful but are outside the total control of the project team. Risks are circumstances or
events that exist outside of the control of the project team and will have an adverse impact
on the project if they occur.
Part 4- Gap Analysis: The gap analysis describes the variance between an organization‘s
existing processes, business requirements and current capabilities and process or
technology areas that require improvements.
Part 5- Statement of Business Requirements: A description of the current business and
the key issues and pain-points that should be addressed in the To-Be solution. This includes
the As-Is and To-Be process maps, requirements list, high level functional requirements, use
case scenarios, and diagrams.

2.1. Problem Statement

One of the biggest challenges end users within the organization currently face is the inability to
efficiently find information. In fact, the cost of this inefficiency is significant to the company‘s bottom
line. After a detailed assessment of the existing Intranet environment, management determined that
the issue relates to constraints of poorly architected and designed information (or content lacking in
architecture and design). The assessment also discovered that the existing navigation structure is
non-intuitive and causes challenges for users to easily find and use information they need in order
to effectively perform their jobs.
When users attempt to locate information, they find that content that is either incomplete or has
gaps and provides only a piece of what they are looking for, or outdated information that has not
been kept current. Even more troubling is the scenario where an end user needs a specific piece of
information and the search results in a large amount of irrelevant information due to unorganized
data. Finally, the certain file formats such as PDF files that do not allow for search, leave end users
without an automated method to locate required information.

―Writing Good Requirements‖ – Trice Johnson 4

IIBA Houston Chapter
 <Enter the document name and version here>
Version: 1.0,

2.2. Business Need

―The Client‖ has a need to replace their existing corporate Intranet site with the intent to evolve it to
a world-class solution that will:
Facilitate improved communication amongst employees enterprise-wide
Provide application systems and services that employees need to perform their jobs
Promote collaboration across disparate geographic location
The primary goal of this project is to provide a centralized information repository for a proactive
communications strategy to help employees search, locate, and acquire business information
quickly and consistently.
To address this need, the project team will use a five-stage methodology to enable successful
development and implementation of this new intranet capability.
Stage 1—Information Gathering and Analysis
Stage 2—Information Architecture Design/WireFrames
Stage 3—Development and Testing
Stage 4—Site Population and Launch
Stage 5—Deployment

2.3. Key Objectives

The goal of this project is to design a robust corporate Intranet system with the goal of supporting
the following enterprise activities:
Migrating from one-way communication mode, where users are simply publishing
material, to an interactive and collaborative environment
The sharing of knowledge and ideas in a single, secure, reliable environment
The effective management of disparate information and document management

2.4. Stakeholder Matrix

Stakeholder/SME Knowledge Area Engagement Strategy

CIO and Project Sponsor who
Jane Doe oversees all aspects of technology
within the organization
President and CEO responsible for
John Smith providing the overall vision and
guidance
Project Director- Responsible for all
Joe Smith
aspects of the site redesign
Project Manager – Responsible for
Jane Smith
managing the project
Visionary Workshop, JAD,
Technical Design Sessions,
Strategy Sessions
Visionary Workshop,
Strategy Sessions
Project Status Meetings,
Strategy Sessions
Project Status Meetings,
Strategy Sessions, JAD

―Writing Good Requirements‖ – Trice Johnson 5

IIBA Houston Chapter
 <Enter the document name and version here>
Version: 1.0,

3. Scope Management
The purpose of the Scope Management section is to describe the process for managing the ―The
Client‖ requirements process, and for maintaining requirements baselines. Having a clearly defined
scope helps to set expectations, and ensures that requirement tasks are executed with precision.

3.1. Scope Objectives

The objectives of scope management are to prioritize and approve requirements changes, manage
any resultant changes to the requirements baselines, and maintain requirements traceability
throughout the system life cycle. Additional objectives include:
 Identify in scope requirements that will be managed in the Corporate Intranet Redesign
project
 Identify out of scope requirements that will not be managed in the Corporate Intranet
Redesign project

3.2. In Scope Requirements

In scope refers to business requirements that will be defined, collected, or managed in Phase I of
this project.

In-Scope Item Description Phase

Implement an improved Corporate Intranet site
that will facilitate stronger communication and
easier access to information. The new system will
1.0 New Intranet Site Phase I
streamline the process of collaboration and
sharing business information across the
enterprise.
Design an intuitive navigational framework that is
1.1 New navigation structure efficient and directly aligns with anticipated user Phase I
task flows.
Create a logical information hierarchy that is
1.2 Improved taxonomy scalable and helps to reduce the number of clicks Phase I
it takes for users to find information timely
Implement a powerful enterprise search engine
New Search Capability
2.0 reducing the amount of time it takes for users to Phase I
(Indexing)
find business information, files, documents, etc.
Implement content feed capability with features
External Integration
3.0 allowing users to pull in information from external Phase I
Capability
websites (e.g., news, market summary, etc)

―Writing Good Requirements‖ – Trice Johnson 6

IIBA Houston Chapter
 <Enter the document name and version here>
Version: 1.0,

3.3. Out of Scope Requirements

Out of scope refers to business requirements that will not be defined, collected, or managed in
Phase II of this project.

Out of Scope Item Description Phase

Full Content Management
1.0 Phase II
System
Automated Document
2.0
Approval

4. Constraints, Assumptions, & Risks

4.1. Constraints

This section identifies project constraints including restrictions or limitations, either internal or
external to the project or company organizations (i.e. sales, provisioning, operations, financial,
functionality, etc.) that will affect the performance of the Corporate Intranet Redesign project.

Constraints inhibit or hinder action; restrict the freedom in designing and delivering a solution.
Constraint ID Constraint Description
CONS-1 Scope modifications could negatively impact the scheduled delivery date of this product
The tight resource pool may constrain the ability of the project manager to ‗crash‘ the
CONS-2 schedule should that become necessary. ‗Crashing‘ is a process of assigning additional
resources to the critical path activities to reduce the overall project schedule.

4.2. Assumptions

This section identifies the critical assumptions that apply to the Customer Request (CR).
Assumptions are the conditions and factors of the project, environment, or personnel that are
considered true, real, or certain without proof or demonstration. These may include best-guess
decisions.
Assumption ID Assumption Description
ASUM-1 All proposed scope changes will be managed via structured Change Control Processes

An initial level of availability has been established for personnel assigned either part or
ASUM-2 full time to this project, and will be used as the basis for developing the project schedule

Both the business and IT will make every reasonable effort to minimize changes to
ASUM-3 agreed upon scope

―Writing Good Requirements‖ – Trice Johnson 7

IIBA Houston Chapter
 <Enter the document name and version here>
Version: 1.0,

4.3. Risks

This section identifies the outcome of the risk assessment that applies to the Customer Request
(CR) from a business perspective. A risk is an uncertain circumstance or event that, should it occur,
would have an adverse effect on the program/project‘s objectives.
Risk Ranking
Risk ID Risk Description
(Low/Medium/High)
Risk management will be conducted throughout the
RISK-1 project based on a methodology that reflects ―The High
Client‘s‖ policies & procedures

RISK-2 Lack of sufficient IT development resources to develop & High

test all agreed upon functionality

5. Gap Analysis

ID Requirement Pain Point Value/Metric

Improve the ability to
GAP-1 quickly search for and
retrieve information
GAP-2 Improve the navigation
structured to a more
organized function
GAP-3 Optimize the search
capability with a more
intuitive search interface &
sophisticated indexing
capabilities
Finding information within our
current Intranet environment is
time-consuming and frustrating for
end users due to lack of content
organization
The current Intranet navigation
structure is non-intuitive and
contributes to lost productivity
The existing Intranet has an
inefficient search engine that
dramatically reduces the search
time for users seeking business
information
Reduce average search time
from 6 minutes to 1 minute or
less
Decrease the percentage of
30% productivity loss to less
than 5%
Reduce the average cost of
wasted productivity related to
searches from $10,000 per
employee annually to $10.00
per employee annually

―Writing Good Requirements‖ – Trice Johnson 8

IIBA Houston Chapter
 <Enter the document name and version here>
Version: 1.0,

6. As-Is Process Map

This section describes the ―As-Is‖ or current state business, information, and/or technology
environment and identifies issues associated with the process. The goal of the analyst is to work
with the process owners or SMEs to understand key process steps performed, that can later be
translated into an actionable and realistic business and design architectures expressed within
business functions, business scenarios, and To-Be requirements.

ID Process Business Issue

User starts process by Although user has been authenticated by the network server,
entering Intranet URL the current portal environment does not recognize the
AIP-1
and signs into portal authentication, so user must sign in with same network
credentials
Content is not organized. Users are forced to search through
System displays the numerous site links to locate information
AIP-2
home page The navigation structure is not standardized or consistent
which makes it difficult for users to find information timely
The ―Search‖ function is located at the bottom of the screen.
This is non-intuitive and the user must know to scroll to the
bottom of the screen to find the ―Search‖ feature
User selects the
―Search‖ function to When users enter keywords within the search field, the results
AIP-3 search for specific that are returned are mismatched with the phrase(s) entered
content Users can not enter multiple keywords/phrases within the
search field due to field constraints
Users are forced to enter ―Boolean‖ characters to utilize the
search function and get accurate results returned
User navigates to the
accurate results Since the existing portal does not contain ―breadcrumbs‖
returned from the (navigation aid to keep track of locations within the portal),
AIP-4
search and selects the users are unable to easily navigate to their previous location
content/file when moved from the existing page

―Writing Good Requirements‖ – Trice Johnson 9

IIBA Houston Chapter
 <Enter the document name and version here>
Version: 1.0,

7. To-Be Process Map

This section describes the ―To-Be‖ or future state business, information, and/or technology
environment and identifies business improvement opportunities to help fulfill key project or business
objectives outlined by project sponsors and stakeholders. The goal of the analyst is to assess the
results of the ―As-Is‖ information and design a new process that will achieve dramatic results for the
business and/or operations in critical, contemporary measures of performance such as cost, quality,
service and speed.

ID Process Process Improvement

The process starts when the user
Users logged on the network server will be
TBP-1 launches the Intranet portal
automatically logged into the corporate portal

Content is organized by organizational department or

System displays home page with
TBP-2 customizable options
User navigates to the ―Search‖
function visibly located in the upper
TBP-3 right hand corner of the portal
screen
User navigates to the correct
search result and selects
information.
TBP-4
value chain structure
Navigation structure is logical & intuitive and aligns
with each organization‘s process composition
New search capabilities similar to the way that
―Google‖ and ―Yahoo‖ search behaves where users
enter a keyword (without Boolean characters) and
exact matches are returned
Search provides users with the ability to enter multiple
terms and submits returns based on values entered
System opens new window/tab to display selected
information
System displays ―breadcrumb‖ within the top part of
the portal screen
System keeps user at previous location within the
portal until he/she elects to navigate away from the
location

―Writing Good Requirements‖ – Trice Johnson 10

IIBA Houston Chapter
 <Enter the document name and version here>
Version: 1.0,

8. To Be Requirement List

X-REF
REQ-ID To-Be Requirement Title
(To-Be)

REQ-1 Portal Log In TBP-1

REQ-2 Content Organization TBP-2

REQ-3 Navigation Structure TBP-2

REQ-4 Search Function TBP-3

REQ-5 Search Results TBP-4

REQ-6 Navigation Tracking (―Breadcrumbs‖) TBP-4

―Writing Good Requirements‖ – Trice Johnson 11

IIBA Houston Chapter
 <Enter the document name and version here>
Version: 1.0,

9. High Level Functional Requirements

The High-Level Functional Requirement (HLFR) describes the function or activity that a system
must perform. This section will contain a unique name and number, a high level description of what
the system should accomplish and data inputs. The information described in this section will be
used to help drive consensus on key functions or activities required to design the ―THE CLIENT‖
system, and to track the requirements through the development of the system.
Process Title: Portal Log In
System shall recognize user log in credentials based on network server
FR-1
authentication
System shall automatically log the user into the portal environment if authenticated
FR-2 via network server
Process Title: Content Organization
System shall display content based on an organized taxonomy that aligns with the
FR-3
business and user task flows
Process Title: Navigation Structure
Site pages shall have a consistent ―look and feel‖ allowing users to find the same
FR-4 navigation bars (global navigation) across the top of each page, enabling easy
movement throughout the portal
FR-5 System shall provide an intuitive and logical navigation hierarchy that matches the
user task flows, and reduces the existing number of clicks
Process Title: Search Function
System shall provide a fully customizable capability, enabling users to design pre-
FR-6
defined searches that display results in place
System will allow users to perform searches against more than 100 document types
FR-7 including HTML, XML, PDF, word processing formats, spreadsheets formats,
presentation formats, and other common business formats.
System will delete ―stop words‖ which will save system resources by eliminating from
FR-8 further processing, as well as potential matching, those terms that have little value in
finding useful documents in response to a customer's query
Process Title: Search Results
System shall provide the ability for users to save search results and retrieve saved
FR-9
searches from a designated portal location

FR-10 System will rank page results based on algorithm determined by the process owners
(details in supplementary artifact)
Process Title: Navigation Tracking (“Breadcrumbs”)
System shall provide breadcrumb navigation, displaying a dynamically generated set
FR-11 of links at the top of Web pages, to show users their current position in the site
hierarchy

―Writing Good Requirements‖ – Trice Johnson 12

IIBA Houston Chapter
 <Enter the document name and version here>
Version: 1.0,

10. Use Case Scenarios

Use Case ID: UC1 (Mock Scenario)

Use Case Name: Log Into Portal
Created By: Trice Johnson Reviewed By:
Date Created: Date Last Updated:

Actors: Intranet User

Description: This use case describes how the Intranet user will manage the portal log
in process.
Trigger: The Intranet User selects the corporate Intranet URL
Preconditions:  The User is successfully logged into the network system
 The User has entered the URL within the IE explorer window
Postconditions:  The User is seamlessly logged into the portal
 The home page screen is displayed to the User
Normal Flow: 1. User Log In
1.1. The use case starts when the User enters the portal URL into the
IE window or selects the bookmarked page from “Favorites”
1.2. The system seamlessly passes the user credentials
1.3. The system will display the portal “Home” page
Exception Flow: 1. User Not Authenticated
1.1. The use case starts when the User enters the portal URL into the
IE window or selects the bookmarked page from “Favorites”
1.2. If the user is not logged on the server, the system will display a
page that shows “User not logged on corporate network and is
unable to view information on the Corporate Intranet Portal”
1.3. System (security) prevents user from viewing the portal
Business Rules:  The system will recognize user log in information and
organization and display relevant data on the Home page based
on their group profile
Notes and Issues:

―Writing Good Requirements‖ – Trice Johnson 13

IIBA Houston Chapter
 <Enter the document name and version here>
Version: 1.0,

Use Case ID: UC6 (Mock Scenario)

Use Case Name: Search Information
Created By: Trice Johnson Reviewed By:
Date Created: Date Last Updated:

Actors: Intranet User

Description: This use case describes how the Intranet user will use the search feature
within the portal environment.
Trigger: The Intranet User navigates to the Search field and enters a keyword(s)
Preconditions:  The User is successfully logged on the portal
 The User has entered a relevant keyword in the Search field
Postconditions:  The system will display relevant search results based on the
keyword(s) entered in the Search field
Normal Flow: 1. User Search
1.1. The use case starts when the User navigates to the “Search”
window and enters a keyword (s)
1.2. Once the User submits the keyword in the Search field, the
system returns applicable search results in the center of the
portal page
1.3. The User tabs to the information, document, or file, and selects
by clicking the link
1.4. ….etc
Exception Flow: 2. User Aborts Search
1.5. The use case starts when the User navigates to the “Search”
window and enters a keyword (s)
2.1. Once the User selects the Search Submit button, the system will
attempt to retrieve the search results
2.2. User clicks the “Stop” button on the IE toolbar to stop the search
process
2.3. System aborts search and returns User to the main portal page
Business Rules:
Notes and Issues:

―Writing Good Requirements‖ – Trice Johnson 14

IIBA Houston Chapter
 <Enter the document name and version here>
Version: 1.0,

11. Use Case Diagrams

―Writing Good Requirements‖ – Trice Johnson 15

IIBA Houston Chapter
 <Enter the document name and version here>
Version: 1.0,

Sample Supplementary Artifact

―Writing Good Requirements‖ – Trice Johnson 16

IIBA Houston Chapter
 <Enter the document name and version here>
Version: 1.0,

12. Document Organizational Signoffs

The Document Organizational Signoffs section contains official signoffs of the responsible
Organization(s). There must be a signoff from the sponsoring organization who submitted
the original Statement of Business Requirements (SoBR). Signoff by the sponsoring
organization project manager is required as well as other impacted functional areas.

Document Organizational Signoffs

Sponsor Name Title Date

Stakeholder Name Title Date

Stakeholder Name Title Date

Project Mgr Name Title Date

―Writing Good Requirements‖ – Trice Johnson 17

IIBA Houston Chapter