ITEC-630 Fall 2008
Prof. J. Alberto Espinosa




Describe the body of knowledge of business analysis
Describe the requirements process
Introduction to business process modeling

Source: International Institute of Business Analysis (iiBA)

 See iiBA: http://download.theiiba.org/default.asp?fileid=26&categoryid=3
 Enterprise analysis
 Requirements planning and management
 Requirements elicitation
 Requirements analysis
 Communication and documentation
 Solution assessment and validation

 Enterprise architecture:
– “The explicit description and documentation of the current and desired relationships among business and management processes and information technology .”
– U.S. Office of Management and Budget, Circular A-130
– “The blueprint for creating enterprise-wide systems in alignment with business needs”
– It involves preparing all diagram , models and descriptions of: all business processes , functions , information and technology infrastructure
– It often involves analyzing the current architecture, conducting gap analysis and developing a target architecture along with a transition plan
 The business analyst needs to understand the enterprise strategies, which provides “the context” in which enterprise analysis is conducted
 In modern, complex, dynamic and fast-paced business environments, the enterprise strategy and information technology are tightly aligned, but the strategy evolves rapidly, presenting substantial challenges for business analysts.
 In large complex organizations, senior business analysts are key participants in the strategic planning process.

It involves:
 Identifying team roles: project manager, business analysts, developers, quality assurance analysts, trainers, application architects, data modeler, database analyst, infrastructure analyst, information architect, subject matter (functional) experts, etc.
 Identifying stakeholders (who will provide requirements information): executive sponsor, solution owner (client), end users, functional managers, investors, etc.
 Distribute responsibilities amongst business analysts and other team members and define coordination, team communication and knowledge sharing mechanisms and processes
 Define risk monitoring and management approach for each identified risk
 Define the requirements and system development method (e.g., traditional, object oriented, unified modeling language —UML, etc.)
 Define the requirements and system development process (e.g., system development life cycle, iterative, unified process —UP)
 Manage requirements change and scope: requirements creep is a big problem
 Define and collect project metrics and reporting mechanisms
 Other project planning and project management activities

A “key” BA task – it provides the foundation for solutions to business needs – it helps develop a thorough understanding of the business process that will be automated and the essential needs of the system.
It involves:
 Eliciting the these essential needs from stakeholders – dependent on the knowledge and willingness of stakeholders to share information

“Trawl” for knowledge : business processes, baseline system, target system
 Methods: interviews, surveys, focus groups, requirements workshops, observations, prototyping, written documents, etc.
 Analyze all interfaces – human and external systems
 Document (i.e., record) all requirements identified (and the source) – requirements notes, cards, etc.
 Establish priorities and verification (measurement) parameters
 Beware of “scope creep”

“The objective is to define and describe the characteristics of an acceptable solution to a business problem, so that the project team has a clear understanding of how to design and implement it”
(iiBA)
It involves:
 Developing analysis models and artifacts
 Can be textual or diagrams – beware of over-diagramming
 And “transitional artifacts” that connect the multiple models – e.g.
CRUD and other matrices
 Methods: business process analysis, object-oriented (OO) analysis, structured analysis
 Requirements: functional, non-functional, project, assumptions, constraints, etc.

The objective is to develop an accurate understanding of the business problem and clearly articulate the solution.
It involves:
 Communication skills are critical – two ways: not only clearly articulating things verbally and in writing, but also listening effectively
 Selecting the appropriate models, artifacts and other requirements documents formats.
 Describing models and text artifacts clearly, accurately and concisely
 Key deliverable: “requirements specification” representing the BA’s
“demonstrated understanding” of the business and processes that need to be handled by the system and its necessary capabilities.
 These specs will serve as the foundation for: effort estimation, budgeting, resource allocation, contractual terms, and implementation planning, etc.
 Preparing effective presentations for clients and stakeholders.

Two key aspects: (1) evaluation if the proposed solution meets business needs
(and the architecture analysis) and (2) if the solution was implemented correctly
(per requirements)
Evaluate proposed solution, it involves:


Requirements reviews to evaluate if they are accurate, complete, clear, non-redundant, consistent (with architecture and business needs), feasible, correctly prioritized, etc.
Obtaining signoff from clients and stakeholders – helps buy in and reduce “feature churn”
Evaluate correct implementation, it involves:
 Working with Quality Assurance teams
 Mapping analysis artifacts to design artifacts


Mapping implemented system features to requirements artifacts
Black box testing of the system implemented
– e.g., using test cases
 Evaluating non-functional requirements and technologies used
 Evaluating usability and interfaces (human and system)

 In simple terms, requirements are things the product needs to do (i.e., useful functionality for its user) and the capabilities and qualities that it must have (i.e., non-functional)
 IEEE definition:
1. A condition or capability needed by a user to solve a problem or achieve an objective
2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed documents
3. A documented representation of a condition or capability as in (1) or (2)

Find, understand, record and communicate:
• Functional Requirements (behavioral)
 What the system needs to do: “The work”
 Your articulation of functional requirements becomes is your
“demonstrated understanding” of the business processes your system needs to automate – Eric Bristow, Deloitte Consulting
• Non-functional Requirements (non-behavioral)
– the qualities of the system (e.g., speed, reliability, capacity)
• Project Requirements
– costs, deliverables, deadlines, etc.
• Prepared using a “System Requirements Process”
• Articulated in a “System Requirements Specification”

Requirements Analysis is
Key to Successful Development
 Several studies have documented that requirements errors cost the most and that poor requirements are the main cause of software failure
GAO’92; Faulk’92; Bohem’81; Curtis’88
“The hardest single part of building a software system is deciding what to build. ...No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”
Fred Brooks (1987)
No Silver Bullet: Essence and Accidents of SW Engineering







Users, Customers, other Stakeholders
(e.g., employees, management, selected customers)
Standards (e.g., GAAP)
Policy/Legal (e.g. government regulations)
System Documentation
(e.g. current system being replaced, could be manual)
Business Process Documentation
(e.g. current business memos, manuals, practices)
Subject Matter Experts
(e.g. experts on the business domain)

Role That Good
Requirements Play





For clients: requirements describe what will be developed and perhaps provide a contractual basis for the development
For project manager: provide a basis for project planning and measuring progress
For the developers: provide the functionality to be designed and coded
For testers: provide the basis on which test
For users: documentation and training

Capturing Requirements is Difficult
Need to:
 Find out what is required by/from the system




Understand these requirements and their implications
Communicate (text and models) this understanding to users, customers, designers and other stakeholders
Manage them – i.e., record them in a traceable manner and ensure that as requirements change, they are updated and the impact of the change is understood
Quality and fit – i.e., ensure that system meets the requirements







“Running a net through the organization to catch every possible requirement source” (Robertson & Robertson)
With experience, you learn where to fish to find what you want
Start with documents from the project “blastoff” meeting with your client
Elicit further requirements through: interviews, requirements workshops, questionnaires, observations, job protocol analysis, prototyping, review of existing documents
Systematically “catch” and record all requirements
Document anything that sounds like a requirement using an organized form or template like: the Volere Requirement Shell



– Determine who to be interviewed
– Prepare for, plan & schedule each interview
– Open the interview: introduction, purpose, permissions (to tape, etc.)
– Conduct the interview: semi-structured, open ended questions, mail questions in advance, let users digress, don’t agree or disagree on anything (just capture)
– Close the interview: summarize things, confirm facts
– Follow up : resolve conflicts; close-ended questions












Approx 2 days before each UP iteration
Multiple stakeholders participate: multiple perspectives of the system
It fosters clear communications between
Requirement Analysts, users and other stakeholders
Fosters sense of participation and project ownership
Helps accelerate requirements elicitation process
Facilitators are often used
Need a scribe to document the discussion
Need rules for participation and problem resolution
Need a process that fosters preparation
Pre-specify expected deliverables
Use artifacts that foster communication with the client:
A Business Process Model (or Map) is an excellent tool for this







The system you are gathering requirements for will automate one or more business processes
Therefore, it is very important that the requirements analysts and clients develop common ground on what these business processes are
The best way to achieve this is to develop a business process model and get the client to sign off on it
The idea is to develop a vision of “the work” that needs to be done, looking ONLY at the business aspects of the process
A business process model (BPM) fosters communication between the requirements team and the client; and within the team
It provides an excellent starting base to begin to articulate the system requirements

Cross Functional Flowchart
BPM Symbols
Process Name
Phase 1 Name
Begining
Process Flow
Yes
Phase 2 Name
Process 2 if
Decision 1 is Yes
Page 2
Process 1
Connect from/to another page
Decision 1 No
Process 2 if
Decision 1 is No
Annotations: use this symbol to embed comments
End
Database operation
Printed output

 All BPM diagrams have one start and one end symbols.
 If there are two or more distinct sub-processes , it is OK to break up the BPM into two sub-models , but each must have a start and end symbols.
 If you have many sub-processes you can create one master BPM that includes “Pre-Defined Process” symbols and then create a separate BPMs for each of these predefined sub-processes.
 You can include many symbols in the diagram to add clarity to your process descriptions. Some symbols just add clarity (e.g., comment, database store, printout), whereas others have very specific rules on how to use them.
 More BPM guidelines: http://www.edrawsoft.com/flowchart-symbols.php






BPMs are used to document business processes , NOT systems actions – focus on understanding and documenting what people do and what the key processes are, rather than what the system solution will do.
That is, you need to understand the business processes before you can suggest a solution.
However, it often helps to distinguish the baseline BPM (what the client does) from the target BPM (what the client wants). You can add notations and other symbols to distinguish baseline from target processes
Similarly, it sometimes helps to distinguish processes that are carried out manually from those that are handled by applications .
So, you can also add notations and other symbols to distinguish manual from system driven processes
More importantly, this is NOT hard science – if you can do anything to add descriptive clarity to your BPM, by all means

Some Rules for BPM Symbols


Process Step (box): can have more than one input but only have one output ; if you think you need two outputs you probably need a decision symbol that evaluates which output path to follow; the input and output lines must connect to another symbol (process box, decision, start, end, etc.); NEVER leave process steps alone —they must have input(s) and output.
Pre-Defined Process (box with double vertical borders): use this symbol to indicate complex process steps that need to be further explained in more detail —it is not a bad idea to put a page reference next to these symbols that connect the diagram to BPM that diagrams the sub-process
 Decision (diamond): have one input and at least two possible outcomes ; it may have more than two outcomes but this may point to more complex process steps that are better described in a “pre-defined process”; all outcomes must be labeled (e.g., “yes”, “no”, “option 1”)— NEVER leave decision outcomes unlabeled


Functional bands or swim lanes: show which functions, departments or roles are associated with a symbol; when flowcharts have functional bands the diagram becomes a “cross-functional flowchart”
Page connector: use this symbol when your diagram spans more than one page; ALWAYS label the symbol with a page number that matches the actual page where the related diagram is
 You can add other symbols to add clarity (e.g., database, printout, etc.); Label these symbols as needed for clarity

Car Rental Operations
BPM Example
Cross-Functional Flowchart
Paperwork
Vehicle
Available?
Yes
Vehicle
Ready?
Yes
Find
Vehicle
Location
Check
Status
Approve rental?
Yes
Record approval
No
No
Retrieve docs
No
Vehicle
Options
Notify
Client
Inquire
Status
Report
Status to
Client
Prepare
Contract
Record
Contract
Delivery
Submit
Contract
Notify
Location to Client
Give Car Keys
& Contract to
Client
Enter agency
Select
Vehicle
Sign
Contract
Leave
Agency

Master BPM Example
Each Pre-Defined Sub-Process Box Has its Own BPM Diagram
“Pre-Defined Process”
symbol used for more complex process steps with a page connector. In this case P.3 should have a separate BPM showing all the steps of this pre-defined process
Master Business Process Model
Start Phase 1 Phase 2 End
Begin
Sub-Process
1.1
P.2
Decision A No More
Which subprocess?
P.3
Sub-Process
2.1
Option A
Please Proceed
Sub-Process
Step A
End
Decision B
Sub-Process
Step B
Sub-Process
3.2
P.4
Option B
Regular process step symbol used for simpler steps
Page symbol to help navigate to the sub-process BPM

Cross-Functional Flowchart
BPM Example
Project Baselining Flow Chart
Start
Initiation Phase Baseline Phase
10
Is Prioritization required?
Yes
No
2
Enter Priority Data
1
New project developed and approved
4
Back to PM
No
8
Enter Project Data
3
Receives project information from
PM
5
Enters project data into Finance
Module
7
Receives award information from
Acquisitions
9
Prepares Project
Schedule and cost
Baseline Report
End

Robertson & Robertson’s “ Volere Template ”
 Project Drivers : purpose, stakeholders, actors
 Project Constraints : constraints, glossary, assumptions
 Functional Requirements : use cases, class diagrams
 Non-functional Requirements :
“ilities” & other qualities
 Project Issues : off-the-shelf, costs, risks, etc.
Template for this course’s project : an adaptation of the Volere Template