8/14/2019 Statement of Business Requirements_IIBA Presentation Final
1/18
THE CLIENT Confidential & Proprietary
This documentation is extremely sensitive; please limit distribution. No part of thisdocument may be photocopied, disclosed, or otherwise provided to third parties.
THE CLIENT Statement of BusinessRequirements (SoBR)
Prepared By: Trice JohnsonIIBA Houston
Version: 1.0Version Date: July 9, 2009
8/14/2019 Statement of Business Requirements_IIBA Presentation Final
2/18
Version: 1.0,
Writing Good Requirements Trice JohnsonIIBA Houston Chapter
i
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)
8/14/2019 Statement of Business Requirements_IIBA Presentation Final
3/18
Version: 1.0,
Writing Good Requirements Trice JohnsonIIBA Houston Chapter
ii
TABLE OF CONTENTSRevision 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
8/14/2019 Statement of Business Requirements_IIBA Presentation Final
4/18
Version: 1.0,
Writing Good Requirements Trice JohnsonIIBA Houston Chapter
3
1. INTRODUCTION
The THE CLIENTStatement of Business Requirements (SoBR) is intended for use by thebusiness/project sponsor, Subject Matter Experts (SMEs) and, development team, and internalbusiness analysts. It is intended to capture relevant business objectives and requirements salientto 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, inaddition to inputs from the Project Manager, technical lead, and development team
Document constraints, assumptions, dependencies and risks related to capturing anddocumenting business requirements
Provide the functional requirements based upon and aligned with the businessneeds/requirements from the sponsor, stakeholders, and Subject Matter Experts (SMEs)
8/14/2019 Statement of Business Requirements_IIBA Presentation Final
5/18
Version: 1.0,
Writing Good Requirements Trice JohnsonIIBA Houston Chapter
4
2. Executive Summary
This document has been prepared for The Client and key staff for business and technologyplanning and design purposes.
The purpose of this document is to present an overview of the current business processes involvedin and associated with the organizations existing Intranet system. This document presents abusiness architecture view that supports The Clients goal to implement improvements to theenterprise Intranet environment.
The SoBR is divided into five major parts:
Part 1 Executive Summary: Provides a concise description of the business issue, andprovides insight on how the business expects the problem to be solved.
Part 2 Scope Management: Describes the process for managing the The Clientrequirements process, and for maintaining requirements baselines.
Part 3 Constraints, Assumptions, & Risks: Constraints describe a circumstance thatposes 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 besuccessful but are outside the total control of the project team. Risks are circumstances orevents that exist outside of the control of the project team and will have an adverse impacton the project if they occur.
Part 4- Gap Analysis: The gap analysis describes the variance between an organizationsexisting processes, business requirements and current capabilities and process ortechnology areas that require improvements.
Part 5- Statement of Business Requirements : A description of the current business andthe key issues and pain-points that should be addressed in the To-Be solution. This includesthe As-Is and To-Be process maps, requirements list, high level functional requirements, usecase scenarios, and diagrams.
2.1. Problem StatementOne of the biggest challenges end users within the organization currently face is the inability toefficiently find information. In fact, the cost of this inefficiency is significant to the companys bottomline. After a detailed assessment of the existing Intranet environment, management determined thatthe issue relates to constraints of poorly architected and designed information (or content lacking inarchitecture and design). The assessment also discovered that the existing navigation structure isnon-intuitive and causes challenges for users to easily find and use information they need in orderto effectively perform their jobs.
When users attempt to locate information, they find that content that is either incomplete or hasgaps 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 ofinformation and the search results in a large amount of irrelevant information due to unorganizeddata. Finally, the certain file formats such as PDF files that do not allow for search, leave end userswithout an automated method to locate required information.
8/14/2019 Statement of Business Requirements_IIBA Presentation Final
6/18
Version: 1.0,
Writing Good Requirements Trice JohnsonIIBA Houston Chapter
5
2.2. Business NeedThe Client has a need to replace their existing corporate Intranet site with the intent to evolve it toa 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 proactivecommunications strategy to help employees search, locate, and acquire business informationquickly and consistently.
To address this need, the project team will use a five-stage methodology to enable successfuldevelopment and implementation of this new intranet capability.
Stage 1 Information Gathering and Analysis
Stage 2 Information Architecture Design/WireFramesStage 3 Development and Testing
Stage 4 Site Population and Launch
Stage 5 Deployment
2.3. Key ObjectivesThe goal of this project is to design a robust corporate Intranet system with the goal of supportingthe following enterprise activities:
Migrating from one-way communication mode, where users are simply publishing
material, to an interactive and collaborative environmentThe 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
Jane DoeCIO and Project Sponsor whooversees all aspects of technologywithin the organization
Visionary Workshop, JAD,Technical Design Sessions,Strategy Sessions
John Smith President and CEO responsible forproviding the overall vision andguidance
Visionary Workshop,Strategy Sessions
Joe Smith Project Director- Responsible for allaspects of the site redesignProject Status Meetings,Strategy Sessions
Jane Smith Project Manager Responsible formanaging the projectProject Status Meetings,Strategy Sessions, JAD
8/14/2019 Statement of Business Requirements_IIBA Presentation Final
7/18
Version: 1.0,
Writing Good Requirements Trice JohnsonIIBA Houston Chapter
6
3. Scope ManagementThe purpose of the Scope Management section is to describe the process for managing the TheClient requirements process, and for maintaining requirements baselines. Having a clearly definedscope 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, manageany resultant changes to the requirements baselines, and maintain requirements traceabilitythroughout the system life cycle. Additional objectives include:
Identify in scope requirements that will be managed in the Corporate Intranet Redesignproject
Identify out of scope requirements that will not be managed in the Corporate IntranetRedesign project
3.2. In Scope RequirementsIn scope refers to business requirements that will be defined, collected, or managed in Phase I ofthis project.
In-Scope Item Description Phase
1.0 New Intranet Site
Implement an improved Corporate Intranet sitethat will facilitate stronger communication andeasier access to information. The new system willstreamline the process of collaboration andsharing business information across theenterprise.
Phase I
1.1 New navigation structureDesign an intuitive navigational framework that isefficient and directly aligns with anticipated usertask flows.
Phase I
1.2 Improved taxonomyCreate a logical information hierarchy that isscalable and helps to reduce the number of clicksit takes for users to find information timely
Phase I
2.0 New Search Capability(Indexing)
Implement a powerful enterprise search enginereducing the amount of time it takes for users tofind business information, files, documents, etc.
Phase I
3.0 External IntegrationCapability
Implement content feed capability with featuresallowing users to pull in information from external
websites (e.g., news, market summary, etc)
Phase I
8/14/2019 Statement of Business Requirements_IIBA Presentation Final
8/18
Version: 1.0,
Writing Good Requirements Trice JohnsonIIBA Houston Chapter
7
3.3. Out of Scope RequirementsOut of scope refers to business requirements that will not be defined, collected, or managed inPhase II of this project.
Out of Scope Item Description Phase
1.0 Full Content ManagementSystem Phase II
2.0 Automated DocumentApproval
4. Constraints, Assumptions, & Risks
4.1. Constraints
This section identifies project constraints including restrictions or limitations, either internal orexternal 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
CONS-2The tight resource pool may constrain the ability of the project manager to crash theschedule should that become necessary. Crashing is a process of assigning addit ionalresources 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 areconsidered true, real, or certain without proof or demonstration. These may include best-guessdecisions.
Assumption ID Assumption Description
ASUM-1 All proposed scope changes will be managed via structured Change Control Processes
ASUM-2 An initial level of availability has been established for personnel assigned either part orfull time to this project, and will be used as the basis for developing the project schedule
ASUM-3Both the business and IT will make every reasonable effort to minimize changes toagreed upon scope
8/14/2019 Statement of Business Requirements_IIBA Presentation Final
9/18
Version: 1.0,
Writing Good Requirements Trice JohnsonIIBA Houston Chapter
8
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/projects objectives.
Risk ID Risk DescriptionRisk Ranking
(Low/Medium/High)
RISK-1Risk management will be conducted throughout theproject based on a methodology that reflects TheClients policies & procedures
High
RISK-2 Lack of sufficient IT development resources to develop &test all agreed upon functionality
High
5. Gap Analysis
ID Requirement Pain Point Value/Metric
GAP-1 Improve the ability toquickly search for andretrieve information
Finding information within ourcurrent Intranet environment istime-consuming and frustrating forend users due to lack of contentorganization
Reduce average search timefrom 6 minutes to 1 minute orless
GAP-2 Improve the navigationstructured to a moreorganized function
The current Intranet navigationstructure is non-intuitive andcontributes to lost productivity
Decrease the percentage of30% productivity loss to lessthan 5%
GAP-3 Optimize the searchcapability with a moreintuitive search interface &sophisticated indexingcapabilities
The existing Intranet has aninefficient search engine thatdramatically reduces the searchtime for users seeking businessinformation
Reduce the average cost ofwasted productivity related tosearches from $10,000 peremployee annually to $10.00per employee annually
8/14/2019 Statement of Business Requirements_IIBA Presentation Final
10/18
Version: 1.0,
Writing Good Requirements Trice JohnsonIIBA Houston Chapter
9
6. As-Is Process MapThis section describes the As -Is or current state bu siness, information, and/or technologyenvironment and identifies issues associated with the process. The goal of the analyst is to workwith the process owners or SMEs to understand key process steps performed, that can later betranslated into an actionable and realistic business and design architectures expressed withinbusiness functions, business scenarios, and To-Be requirements.
ID Process Business Issue
AIP-1
User starts process byentering Intranet URLand signs into portal
Although user has been authenticated by the network server,the current portal environment does not recognize theauthentication, so user must sign in with same networkcredentials
AIP-2 System displays thehome page
Content is not organized. Users are forced to search throughnumerous site links to locate information
The navigation structure is not standardized or consistentwhich makes it difficult for users to find information timely
AIP-3
User selects theSearch function tosearch for specificcontent
The Search f unction is located at the bottom of the screen.This is non-intuitive and the user must know to scroll to thebottom of the screen to find the Search feature
When users enter keywords within the search field, the resultsthat are returned are mismatched with the phrase(s) entered
Users can not enter multiple keywords/phrases within thesearch field due to field constraints
Users are forced to enter Boolean characters to utilize thesearch function and get accurate results returned
AIP-4
User navigates to theaccurate resultsreturned from thesearch and selects thecontent/file
Since the existing portal does not contain breadcrumbs(navigation aid to keep track of locations within the portal),users are unable to easily navigate to their previous locationwhen moved from the existing page
8/14/2019 Statement of Business Requirements_IIBA Presentation Final
11/18
Version: 1.0,
Writing Good Requirements Trice JohnsonIIBA Houston Chapter
10
7. To-Be Process MapThis section describes the To-Be or future state business, information, and/or technologyenvironment and identifies business improvement opportunities to help fulfill key project or businessobjectives outlined by project sponsors and stakeholders. The goal of the analyst is to assess theresults of the As -Is information and design a new process that will achieve dramatic results for thebusiness and/or operations in critical, contemporary measures of performance such as cost, quality,service and speed.
ID Process Process Improvement
TBP-1 The process starts when the userlaunches the Intranet portal Users logged on the network server will beautomatically logged into the corporate portal
TBP-2 System displays home page withcustomizable options
Content is organized by organizational department orvalue chain structure
Navigation structure is logical & intuitive and alignswith each organizations process composition
TBP-3
User navigates to the Searchfunction visibly located in the upperright hand corner of the portalscreen
New search capabilities similar to the way thatGoogle and Yahoo search behaves where usersenter a keyword (without Boolean characters) andexact matches are returned
Search provides users with the ability to enter multipleterms and submits returns based on values entered
TBP-4
User navigates to the correctsearch result and selectsinformation.
System opens new window/tab to display selectedinformation
Sys tem displays breadcrumb within the top part of the portal screen
System keeps user at previous location within theportal until he/she elects to navigate away from thelocation
8/14/2019 Statement of Business Requirements_IIBA Presentation Final
12/18
Version: 1.0,
Writing Good Requirements Trice JohnsonIIBA Houston Chapter
11
8. To Be Requirement List
REQ-ID To-Be Requirement TitleX-REF
(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
8/14/2019 Statement of Business Requirements_IIBA Presentation Final
13/18
Version: 1.0,
Writing Good Requirements Trice JohnsonIIBA Houston Chapter
12
9. High Level Functional RequirementsThe High-Level Functional Requirement (HLFR) describes the function or activity that a systemmust perform. This section will contain a unique name and number, a high level description of whatthe system should accomplish and data inputs. The information described in this section will beused 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
FR-1 System shall recognize user log in credentials based on network serverauthentication
FR-2System shall automatically log the user into the portal environment if authenticatedvia network server
Process Title: Content Organization
FR-3 System shall display content based on an organized taxonomy that aligns with thebusiness and user task flows
Process Title: Navigation Structure
FR-4Site pages shall have a consistent look and feel allowing users to find the samenavigation bars (global navigation) across the top of each page, enabling easymovement throughout the portal
FR-5 System shall provide an intuitive and logical navigation hierarchy that matches theuser task flows, and reduces the existing number of clicks
Process Title: Search Function
FR-6 System shall provide a fully customizable capability, enabling users to design pre-defined searches that display results in place
FR-7System will allow users to perform searches against more than 100 document typesincluding HTML, XML, PDF, word processing formats, spreadsheets formats,presentation formats, and other common business formats.
FR-8System will delete stop words which will save system resources by eliminating fromfurther processing, as well as potential matching, those terms that have little value infinding useful documents in response to a customer's query
Process Title: Search Results
FR-9 System shall provide the ability for users to save search results and retrieve savedsearches 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)
FR-11System shall provide breadcrumb navigation, displaying a dynamically generated setof links at the top of Web pages, to show users their current position in the sitehierarchy
8/14/2019 Statement of Business Requirements_IIBA Presentation Final
14/18
Version: 1.0,
Writing Good Requirements Trice JohnsonIIBA Houston Chapter
13
10. Use Case Scenarios
Use Case ID: UC1 (Mock Scenario)
Use Case Name: Log Into PortalCreated By: Trice Johnson Reviewed By:
Date Created: Date Last Updated:
Actors: Intranet UserDescription: 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 In1.1. The use case starts when the User enters the portal URL into the
IE window or selects t he bookmarked page from Favorites 1.2. The system seamlessly passes the user credentials1.3. The system will display the portal Home page
Exception Flow: 1. User Not Authenticated1.1. The use case starts when the User enters the portal URL into the
IE window or sele cts 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 isunable to view information on the Corporate Intranet Portal
1.3. System (security) prevents user from viewing the portalBusiness Rules: The system will recognize user log in information and
organization and display relevant data on the Home page basedon their group profile
Notes and Issues:
8/14/2019 Statement of Business Requirements_IIBA Presentation Final
15/18
Version: 1.0,
Writing Good Requirements Trice JohnsonIIBA Houston Chapter
14
Use Case ID: UC6 (Mock Scenario)Use Case Name: Search Information
Created By: Trice Johnson Reviewed By:Date Created: Date Last Updated:
Actors: Intranet UserDescription: 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 thekeyword(s) entered in the Search field
Normal Flow: 1. User Search1.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 theportal page
1.3. The User tabs to the information, document, or file, and selectsby 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 willattempt to retrieve the search results
2.2. User clicks the Stop button on the IE toolbar to stop the searchprocess
2.3. System aborts search and returns User to the main portal pageBusiness Rules:
Notes and Issues:
8/14/2019 Statement of Business Requirements_IIBA Presentation Final
16/18
Version: 1.0,
Writing Good Requirements Trice JohnsonIIBA Houston Chapter
15
11. Use Case Diagrams
8/14/2019 Statement of Business Requirements_IIBA Presentation Final
17/18
Version: 1.0,
Writing Good Requirements Trice JohnsonIIBA Houston Chapter
16
Sample Supplementary Artifact
8/14/2019 Statement of Business Requirements_IIBA Presentation Final
18/18
Version: 1.0,
Writing Good Requirements Trice JohnsonIIBA Houston Chapter
17
12. Document Organizational SignoffsThe Document Organizational Signoffs section contains official signoffs of the responsibleOrganization(s). There must be a signoff from the sponsoring organization who submittedthe original Statement of Business Requirements (SoBR). Signoff by the sponsoringorganization 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
Top Related