An overview of Requirements Analysis (RA) Knowledge Areas from IIBA BABoK version 2.

2. Enterprise
Analysis
Business Analysis
Planning &
Monitoring
Requirements
Elicitation
Requirements
Analysis
Solution
Assessment &
Validation
Underlying
Competency
Requirements
Management &
Communication
Techniques
Concepts
BABoK®Version2Release2009

4.  Describes the tasks and techniques to analyze stated
requirements in order to define the required capabilities of a
potential solution that will fulfil stakeholder needs.
 Covers the definition of stakeholder requirements
 Covers the definition of solution requirements
 May be performed to develop models of the current state of an
organization
 Performance of all requirements analysis activities are governed
by the business analysis plans

8.  Business Case
 Business Need
 Requirements
 RMP
 Stakeholder List
Input
Prioritize Requirements
Task
 Requirements [Prioritized]
Output
Techniques
 Decision Analysis
 Risk Analysis
 MoSCoW analysis
 Timeboxing
 Voting
Stakeholders
 SME (Domain/Implementation)
 Project Manger
Sponsor

14. Risk of Failure
Need
Low Medium High
LowMediumHigh
The need of requirements
from operational
perspective
If not implemented what’s
the risk

18.  Presentation
 Prototype
 Business Process
 High-level Usecase
 Presentation
 Prototype
 Functional Usecase
 UAT Test cases/ Scenarios
 Detail Usecase's
 Workflows
 UML Diagrams
 Data Models

19. • Over the life of a systems development project, the project team
works from the abstract to the concrete:
– Abstract (Requirements)
• Business Requirements
• Business Processes
– Becoming Less Abstract (Analysis – the WHAT)
• Use Cases
• Test Cases
– Becoming Concrete (Design – the HOW)
• Static (class diagrams) and Dynamic (interaction diagrams) Models
• Data Models
– Concrete (Produce)
• Code
• Infrastructure – hardware and software platforms

20. Business Requirements
Business Process Design
Business Requirements Matrix/ Document
Functional Requirements
Usecase Design
Functional Requirements Matrix/ Document
Data Model Business Rules
Process Rules
Object Model
User Interface Model

21.  Organizational Process Assets
 Requirements [Stated]
 Solution Scope
Input
Organize Requirements
Task
 Requirements Structure
Output
Techniques
Business Rules Analysis
Data Flow Diagrams
Data Modelling
Functional Decomposition
Organization Modelling
Process Modelling
Scenarios and Use Cases
Scope Modelling
User Stories
Stakeholders
 Customer
 End User
 Project Manager
 Subject Mater Expert

27.  Requirements [Stated]
 Requirements Structure
Input
Specify and Model Requirements
Task
 Stakeholder or Solution
Requirements
Output
Techniques
Acceptance and Evaluation Criteria Definition
Business Rules Analysis
Data Dictionary and Glossary
Data Flow Diagrams
Data Modelling
Functional Decomposition
Interface Analysis
Metrics and Key Performance Indicators
Non-functional Requirements Analysis
Organization Modelling
Process Modelling
Prototyping
Scenarios and Use Cases
Sequence Diagrams
State Diagrams
User Stories
Stakeholders
All Stakeholder

35. Conceptual Process
High Level Process Maps
Detail Process
Task/Activities
Implementation Process
VAC
VAC
EPC
BPMN
BPMN
Value Added Chain Diagrams
Event Driven Process Chain
Business Process Modeling Notation

37. Develop Actor List
Develop Initial
Use Case List
Develop Initial
Use Case Diagram
Write Use Case
Documents
Develop
Activity Diagram
Refine Use
Case Diagram
Business
Requirements
Usecase
Document
Activity
Diagrams
Usecase
Diagrams

38. Outside the system
 Human
 Peripheral device - hardware
 External system or subsystem
 Time
Use a singular noun to name
In the context of system interactions, a
single role of multiple physical users.
Single role, many users
OR
One user, many roles

39. A use case name should:
 Consist of 2 to 4 words
 Begin with a verb
Examples:
 Place Order
 Edit Customer Information
 Submit Invoice for Approval
<Usecase Name>

40. Check Status
Login
Track User Action

41. Usecase Documentation:
 Usecase Name
 Usecase Description/Goal
 Actor(s)
 Pre-Conditions
 Post-Conditions
 Basic Flow
 Alternate Flows
 Exception Flows
 Business Rules

42. Detailed Use Case: UC001 {Usecase Identifier} Create Customer Order {Usecase Name}
Description The Order Clerk enters the Customer Installation Order information and submits the order for processing.
Actor(s) Order Clerk (a.k.a. the user)
Order Management System (a.k.a. the system)
Pre-Conditions 1. The user has selected an active customer for whom the order is to be processed (e.g., from use case UC View
Customer Information).
Post-Conditions 1. An order has been successfully submitted for processing (Order Process State is ‘Submitted’).
Basic Flow {Usecase main flow}
1 The user requests that a new Order be created for the selected Customer.
2 The system creates a prospective order (RULE001.1 New Order is Prospective)
3 The system displays the following prospective order information:
a. Customer Name
4 The user specifies the following prospective order information:
a. Service/Product, selected from a list of services/products
b. Primary Service Location (invoke UC Maintain Location Associations)
5. Etc.
Integrated Business Rules with
Usecase flow

43.  Have the actors’ activities been
identified?
 Is the flow of events complete
and sequenced properly?
 Does the use case describe
queries and responses of data?
 Are the use cases described in
short simple sentences?
 Have all use case documents
used the template?
 Is an open issue list being
maintained?
 Are similar scenarios consolidated
into one use case?

46.  Stakeholder Concerns
Input
Define Assumptions &
Constraints
Task
Assumptions and Constraints
Output
Techniques
Risk Analysis Problem Tracking
Stakeholders
All Stakeholder

51. Requirements [Any Except Stated]
Input
Verify Requirements
Task
Requirements [Verified]
Output
Techniques
 Acceptance and Evaluation Criteria Definition
 Problem Tracking
 Structured Walkthrough
Checklists
Stakeholders
All Stakeholders

56. User Story Title: Customer withdraws cash
As a customer,
I want to withdraw cash from an ATM,
so that I don’t have to wait in line at the bank.
Acceptance Scenario 1: Account is in credit
Given the account is in credit
And the card is valid And the dispenser contains cash
When the customer requests cash

59. Business Case
Stakeholder, Solution, or Transition
Requirements [Verified]
Input
Validate Requirements
Task
Requirements [Validated]
Output
Stakeholders
All Stakeholders
Techniques
Acceptance and Evaluation Criteria Definition
Metrics and Key Performance Indicators
Prototyping
Risk Analysis
Structured Walkthrough