CBAP/BABOK v1.6 Cards

(1) A condition or capability needed by a stakeholder2 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).

Business Requirements, User Requirements, Functional Requirements, Quality of Service Requirements, Assumptions and constraints, and Implementation requirements

Quality of Service Requirements capture conditions that do not directly relate to the
behavior or functionality of the solution, but rather describe environmental
conditions under which the solution must remain effective or qualities that the
systems must have. They are also known as non-functional or supplementary
requirements. They are further described in the Requirements Analysis and
Documentation KA.

Business Requirements are higher-level statements of the goals, objectives, or needs of the enterprise. They describe such things the reasons why a project is initiated, the things that the project will achieve, and the metrics which will be used to measure its success. They are detailed further in the Enterprise Analysis KA.

Assumptions and constraints identify aspects of the problem domain that are not
functional requirements of a solution, and will limit or impact the design of the
solution. They are further described in the Requirements Analysis and Documentation
KA.

User Requirements are statements of the needs of a particular stakeholder or class of
stakeholders. They describe the needs that a given stakeholder has and how that
stakeholder will interact with a solution. User Requirements serve as a bridge
between Business Requirements and the various classes of solution requirements.

Implementation requirements describe capabilities that the solution must have in
order to facilitate transition from the current state of the enterprise to the desired
future state, but that will not be needed once that transition is complete. They are
further described in the Solution Assessment and Validation KA.

• Enterprise Analysis
• Requirements Planning and Management
• Requirements Elicitation
• Requirements Communication
• Requirements Analysis and Documentation
• Solution Assessment and Validation

Enterprise Analysis is the collection of pre-project or early project activities and
approaches for capturing the necessary view of the business to provide context to
requirements and functional design work for a given initiative and/or for long term
planning.

It also describes the Business Analysis activities that take place for organizations to
Analyze the business situation in order to fully understand business problems and ▶▶opportunities.
Assess the capabilities of the enterprise in order to understand the change needed ▶▶to meet business needs and achieve strategic goals.
Determine the most feasible business solution approach.▶▶
Define the solution scope and develop the business case for a proposed solution.▶▶
Define and document business requirements (including the business need, required ▶▶capabilities, solution scope, and business case).

how stakeholder needs are analyzed, structured and
specified for use in the design and implementation of a solution.

Business Goals and Objectives and Stated Requirements

the collection of activities and
considerations for expressing the output of the requirements analysis and documentation
to a broad and diverse audience

Requirements Planning and Management Knowledge Area defines the resources and
tasks associated with the planning and management of requirements gathering activities
throughout the requirements process.

the business analysis tasks necessary to ensure that the
solution meets the stakeholder objectives, is thoroughly tested, and is implemented
smoothly.

after the executive team of the organization
develops strategic plans and goals

information is gathered to propose
new programs and supporting projects to management for a go/no go decision whether
to select, prioritize and fund a new project

after the benefits of project
outcomes are measured and analyzed

Strategic Plan Development, Strategic Goal Development, Business Architecture Development, Feasibility Studies, Business Case Development, New Project Proposal, Selecting and Prioritizing New Business Opportunities, Launching New Projects, Managing Projects for Value, Tracking Project Benefits

Conduct competitive analysis and benchmark studies that serve as input to
the strategic planning process

Help plan and facilitate strategic planning sessions.

facilitate strategic goal setting sessions

leads the discussion of development and maintenance of the current and future state Business Architecture.

collaborate with subject matter experts (the business sponsor,
business representative(s) and IT management) to scope the proposed
project, make time and cost estimates, quantify business benefits and
prepare the business case.

collaborate with subject matter experts and facilitates the team to:
Identify solution options
Examine the feasibility of each option
Determine the most viable option

collect the relevant information about the proposed new project and provides the executive presentation and decision package to the business
sponsor to propose a new project to the organizational project investment
governance body.

help plan and facilitate portfolio management
meetings, and present the proposal for new projects

support the PM in initiating and planning the new
project by eliciting, analyzing, documenting and validating business requirements and
collaborating with the architect during initial design

strategic themes as the building blocks of the strategy

work with the PM to update the Business Case to provide management with information to make investment project decisions

reflect financial performance goals,
include goals relating to customer value and business
operations that drive value
include capabilities of human resources and other corporate assets

ensure metrics and measurements are in place, analyzed and
reported to the business sponsor to track actual vs. expected benefits as
documented in the business case

(1) reduce costs through on-line customer ordering, (2) increase the number of highvalue
customers through acquisitions, and (3) increase revenue per customer by
increasing the services provided per customer.

Enterprise Analysis is conducted

Corporate Scorecards or Balanced Scorecards

• Investigating current strategy
• Assessing the current technology structure vs
business vision
• Identifying ongoing business issues
• Competitiveness and profitability

concurrently and iteratively

• Scoping and defining the new business opportunity
• Preparing the Business Case
• Creating and maintaining the Business Architecture
• Conducting Feasibility Studies to determine the optimum business solution• Conducting the initial Risk Assessment
• Preparing the Decision Package.

• Strategic Plan / Goals / Objectives
• Business Problem / Opportunity
• Current State Business Architecture

• Business Architecture Framework
• Business Architecture Artifacts
• Alignment of Problem / Oppty
to the business
• Gap Analysis Results

• Strategic Plan / Goals / Objectives
• Business Problem / Opportunity
• Business Architecture Artifacts

• Business Feasibility Study
• Strategic Alignment
• Technical Alignment
• Alternative Solution Ranking
& Recommendation

• Strategic Plan / Goals / Objectives
• Business Problem / Opportunity Definition
• Business Architecture Artifacts
• Business Feasibility Study
• Alternative Solution Ranking & Recommendation

• Strategic Fit
• Business Objectives & High Level Requirements
• Root Cause Analysis
• Rationale for Option Selected
• Product Description & Scope
• Assumptions & Constraints
• Initial Project Approach & Resourcing
• Major Project Milestones & Funding Requirements

• Strategic Plan / Goals / Objectives
• Business Problem / Opportunity Definition
• Business Architecture Artifacts
• Business Feasibility Study
• Proposed Project Scope definition

• Business Case Summary Presentation
• Business Case Report

• Business Architecture Artifacts
• Business Feasibility Study
• Proposed Project Scope definition
• Business Case Report

• Initial Risk Rating
• Proposed Risk Responses

• Business Architecture Artifacts
• Business Feasibility Study
• Proposed Project Scope definition
• Business Case Report
• Initial Risk Rating & Proposed Risk Response

• Collated Package of Enterprise Activity Products
• Enhanced Business Case Report
• Recommendations
• Executive / Sponsor Briefing Material

Requirements Planning and Management Knowledge Area
• Requirements Gathering Knowledge Area
• Requirements Communication Knowledge Area

....set of documentation that defines an organization’s current
and future capabilities.

• Business Architecture
• Information Architecture
• Application Architecture
• Technology Architecture
• Security Architecture

• Documenting the current Business Architecture in terms of the business structure
and components describing the product and/or service strategy, and the organizational, functional, process, information, and geographic aspects of the
business environment.
• Developing the future Business Architecture to depict the strategic vision in
practice.
• Analyzing the gaps between the current and future state Business Architectures to
determine the extent of change required to realize the future state objectives.
• Providing a context in which change initiatives (projects) can be assessed and
helping identify new business opportunities that need to be pursued.

• • General business practices
• Industry domains
• IT-enabled business solutions
• Current and emerging business concepts, strategies and practices
• How various lines of business within the organization interact
• Business concepts for organizing enterprise knowledge
• Standard architectural principles and semantics, including an understanding of
how business issues drive information systems requirements
• Standard business concepts and guidance as to how to

• Determine the scope of the effort
• Plan the activities
• Create or update the documents and drawings
• Conduct a quality review of the Business Architecture components.

• Determine appropriate framework and approach
• Determine the architectural documents and drawings
• Select appropriate resources
• Select relevant business architectural viewpoints, e.g., lines of business, or
business units
• Identify appropriate tools and techniques
• Determine how the architectural components will be stored.

• Executive and middle management
• Individual contributors
• Project and operational teams
• Shareholders
• Customers and end users
• Government and regulatory bodies.

• The Zachman Framework
• The POLDAT framework

• Component Business Models
• Business Process Models
• Class Models
• Use Case Models
• Business Scenarios
• Knowledge Management

ascertain the likelihood of
each potential solution alternative’s probability of satisfying the business need in terms of economic, operational and technical feasibility. The outcome of the feasibility study is a
recommended solution option to be further defined in a business case.

Help organizations understand the competitive environment, enabling them to make informed decisions

• reliable data
• application of proven statistical methods
• market research

• Strategic planning and goal setting
• High level business issues and problems descriptions
• Business architecture framework.

• Determine requirements for the study
• Determine objectives, scope and approach, and plan the effort
• Conduct a current state assessment
• Identify potential solutions
• Determine the feasibility of each option
• Document and communicate the results of the study, and obtain approval to
develop the Business Case for the recommended solution.

• Develop benefit criteria upon which alternative solutions will be evaluated
• Define scope of study activities
• Define study deliverables
• Review all of the information developed in steps 1 and 2 with the sponsor to validate requirements and scope
•

• Determine appropriate framework and approach
• Determine the architectural documents and drawings
• Select appropriate resources
• Select relevant business architectural viewpoints, e.g., lines of business, or
business units
• Identify appropriate tools and techniques
• Determine how the architectural components will be stored.

• Executive and middle management
• Individual contributors
• Project and operational teams
• Shareholders
• Customers and end users
• Government and regulatory bodies.

• The Zachman Framework
• The POLDAT framework

• Component Business Models
• Business Process Models
• Class Models
• Use Case Models
• Business Scenarios
• Knowledge Management

ascertain the likelihood of
each potential solution alternative’s probability of satisfying the business need in terms of economic, operational and technical feasibility. The outcome of the feasibility study is a
recommended solution option to be further defined in a business case.

Help organizations understand the competitive environment, enabling them to make informed decisions

• reliable data
• application of proven statistical methods
• market research

• Strategic planning and goal setting
• High level business issues and problems descriptions
• Business architecture framework.

• Determine requirements for the study
• Determine objectives, scope and approach, and plan the effort
• Conduct a current state assessment
• Identify potential solutions
• Determine the feasibility of each option
• Document and communicate the results of the study, and obtain approval to
develop the Business Case for the recommended solution.

• Develop benefit criteria upon which alternative solutions will be evaluated
• Define scope of study activities
• Define study deliverables
• Review all of the information developed in steps 1 and 2 with the sponsor to validate requirements and scope
•

Strategy, Business Area, Locations, Data and Info, Infrastructure, Processes, Competitive Arena

Do nothing.

• Describe the solution option in as much detail as possible
• Identify methods to assess the alternative
• Identify expected results
• Define assessment steps
• Undertake feasibility analysis for each option.
• Review results to ensure completeness.
•

•

Feasibility Study Report

• Exec Summary
• Business Problem/Oppty Statement
• Feasibility Study Reqs
• Individual solution option analysis
•
•

• Current State Assessment
• Study Planning Effort
• Identification of Solution Options
• Assessment of feasibility of each solution option

• Standard Project Mgmt
• Brainstorming
• WBS

• Brainstorming
• Six Sigma for process improvement
• Business Process Re-engineering
• Cause and Effect Analysis/Diagramming

Conducting the Analysis of Feasibility of individual solution options

Provide a documented basis for building the business case

• Describing the business environment in enough detail to provide context
• Describing the business requirements in enough detail to understand the
business needs
• Defining the scope of the work that must be performed

• Business objectives
• Expected deliverables
• Business assumptions and constraints
• Statement of work

• Strategic planning and goal setting
• Business architecture development and documentation
• Business opportunity and/or problem definition
• Feasibility studies to conduct alternative solution analysis and determine the
recommended solution

The activities to size the proposed project so that estimates can be made of costs, resources requirements and project duration.

• Work Breakdown Structure
• Initial product analysis in a Product Breakdown Structure (PBS) which is a decomposition product components
• System Interface Analysis

During preparation of the business case.

A high-level visual view of the business solution to be built, and identifies the entities that interface

Use Case Models

Describes the justification for the project in terms of the value to be added to the business as a result of the project outcomes vs. the cost to develop the new
solution

• Strategic planning and goal setting
• Business architecture framework
• Feasibility studies
• Proposed project scope definition

• Identify and Quantify the Benefits
• Identify and Quantify the Costs
• Prepare the Business Case
• Determine the Measurement Process for the Costs and Benefits.

Enterprise Analysis

How they will be assessed and measured

• Strengths
• Weaknesses
• Opportunities
• Threats

Business Case preparation

• SWOT Analysis
• Financial Valuation
• Cost-Benefit Analysis
• Activity based Costing

• Discounted Cash Flow
• Net Present value
• Internal Rate of Return
• Average Rate of Return
• Pay Back Period

Compare the costs of implementing a solution against the benefits gained from it

A technique that measures the development and
performance cost of activities, resources, and items

Determine if the proposed project carries more risk than the organization is willing to bear.

• Identifying project risks
• Assessing risk probability and impact
• Planning risk responses
• Assessing organizational readiness and calculating an overall risk rating.

• Identifying and analyzing business risks
• Identifying and analyzing financial risks
• Identifying and analyzing technical risks.

The analysis of the probability of the risk occurring, and the impact if the risk does occur.

• Quantify change management risk, impacts and response plans
• Describe and quantify the risk to the organization of doing nothing
• Calculate an overall risk rating for the proposed initiative in terms of costs, time, and quality of the business operations.

The initial risk rating, which is included in the Business Case document

risk probability, impact assessment, overall risk rating analysis

An actionable set of information regarding the
proposed new project to the organizational decision makers. It is part of the business case preparation.

To select the right investment
path from the mix of potential opportunities including (1) research initiatives, (2) new
product development activities, (3) information technology enhancements, (4) internal
business improvement projects, and (5) new business endeavors. Through

The Requirements Planning and Management Knowledge Area

• Business environment analysis from KA Enterprise Analysis
• Enterprise requirements scope from KA Enterprise Analysis
• Feasibility assessment from KA Enterprise Analysis

• List of project team members assigned to the project and team member roles
• List of stakeholders and their relationship to the project
• List of requirements gathering tasks and division of work
• Tool(s) used to gather and communicate requirements

Project Roles

• Current Project Plan
• Initial project docs
• Project Charter
• Project standards docs

• Exec Sponsor
• Proj Mg
• BA
• Developer
• Qual Assurance Analyst
• Trainer
• Appl Architect
• Data Modeler
• DBA
• Infrastructure Analyst
• Information Arch
• Solution Owner
• SME
• Stakeholder

The solution owner is responsible for defining and approving the project scope and ensuring that it aligns with the business strategy

The information architect is responsible for assessing the
overall data requirements of an information system project.

The infrastructure analyst designs the overall hardware and
software infrastructure and environment needed to meet the application development and operational requirements.

A person or group that has a stake or interest in the uccess of a project.

A tool useful to illustrate usual responsibilities of the roles
involved in planning and managing requirements

[R]esponsible does the work,
[A]ccountable is the decision maker (only one)
[C]onsulted must be consulted prior to the work and gives input
[I]nformed is on a need to know basis after the work is done

Cost, Delivery, Scope and Resource Needs

Questionnaire, Web Survey, Interview

The questionnaire takes time to develop and receive responses from recipients

The incovering of commonalities

A method that applies to a team of business analysts that is designed to the define the work division and co-ordinate the information and knowledge transfer among the team
members.

Requirements Work Plan

Subject Matter Expertise, Complexity, Previous Work Experience with Stakeholders, Geography and Culture, Areas of Interests, Physical Limitations, Availability

It provides flexibility based on different factors

It does not consider the Business Analysts’ time commitment to the system development component, process improvement and/or organizational change project

Core Business Concepts and Policies, Functional and Non-Functional reqs, Project Docs

A systematic approach to capture, collect and share tacit knowledge in order for it to become explicit knowledge

• Verbal
• Non-Verbal
• Structured Walk-Through/Peer Reviews
• Status Meetings
• Debriefing Meetings
• Central Repository
• Mentorship

Requirements Analysis and Management KA

• Insufficient user involvement
• Ambiguous requirements.
• Missing, incorrect, and conflicting requirements
• Lack of requirements management and planning, such as requirements change
control
• Scope Creep

The project manager

The BA

All project stakeholders.

Every requirement that has an associated risk

• Likelihood
• Impact (cost, schedule, scope, quality, benefits)
• Intervention Difficulty
• Precision of assessment
• Mitigation Strategy
• Action Plan
• Contigency Plan

A status of each identified risk so that each may be controlled in a methodical, timely and orderly manner

All project stakeholders

• Risk Status
• Risk Observation Details

Controls requirement risk in such a way that surprises are eliminated

• Impact
• Mitigation Stategy
• Action Plan
• Contingency Plan
• Lessons Learned

• Risk Materialization
• Lessons Learned

SDLC Methodology is the overall proces of desiggning and developing information systems. Project methdology is all phases required to complete the project.

• Waterfall
• Iteritive
• Agile

The process of modifying the project plan in response to events that have occurred during project execution

The requirements baseline

The Requirements baseline and the requirements management plan

The Requirements Analysis and Management KA

Centralized and Dispersed

Time and Cost

The Requirements Management plan

• New Software Development (in-house)
• Outsourced Development
• Software Maintenance
• Software Package Selection
• Process improvement
• Organizational Change

They determine the quality and timeliness of requirements deliverables and the solution

• Requirements Elicitation
• Requirements Analysis and Documentation
• Requirements Communication
• Solution Assessment and Validation

The process of modifying the project plan in response to events that have occurred during project execution

The requirements baseline

The Requirements baseline and the requirements management plan

The Requirements Analysis and Management KA

Centralized and Dispersed

Time and Cost

The Requirements Management plan

• New Software Development (in-house)
• Outsourced Development
• Software Maintenance
• Software Package Selection
• Process improvement
• Organizational Change

They determine the quality and timeliness of requirements deliverables and the solution

• Requirements Elicitation
• Requirements Analysis and Documentation
• Requirements Communication
• Solution Assessment and Validation

• A selection of all activities for the entire requirements process (Requirements
Elicitation to Solution Assessment and Validation)
• List of activities with a detailed description of each activity, and the types of resources
required to complete each activity e.g. a Work Breakdown Structure (WBS).
• Logical dependencies between activities i.e. determination of predecessors.

To have a complete set of business and user requirements once all requirements activities are complete

When there is a WBS for the elicitation phase with assigned resources

• The availability of tools and technologies in an organization
• Project timeline
• Budget constraints

The BAs justification for the selection

Project Type and Project Scope

When a WBS is complete with assigned resources

The selection of the documentation type that best communicates the project requirements

Those activities that best provide a design based on the requirements

Completed and approved requirements (baselined)

All preceding requirements
related activities need to be successfully completed: Requirements Elicitation,
Requirements Analysis and Documentation, and Requirements Communication.

When there is a WBS of tasks created

scope (work to do), schedule (time to do it in), and resources (budget for the project)

A significant point or event in the project

Reviews the list of requirements activities with the Project Sponsor and Project Manager to define and agree on each milestone and the associated requirements activities

The Project Sponsor and Project Manager

A task that cannot be decomposed further.

List of requirements

List of components and dependencies associated with each requirement

Assigns an available resource and defines a time estimate for each requirement task

List of requirements with estimated times for each (may be part of the CRS)

Establishes and maintains a requirements baseline, maintains tracing, indentifies change impacts, manages scope creep

A line or standard by which the changes to requirements are compared.

Change Management

Assists in managing change following baselining.

All preceding requirements
related activities need to be successfully completed: Requirements Elicitation,
Requirements Analysis and Documentation, and Requirements Communication.

When there is a WBS of tasks created

scope (work to do), schedule (time to do it in), and resources (budget for the project)

A significant point or event in the project

Reviews the list of requirements activities with the Project Sponsor and Project Manager to define and agree on each milestone and the associated requirements activities

• Traceability aids scope management
• Traceability aids change impact analysis
• Traceability aids risk based testing

• Source
• Rationale
• Requirements
• Design or Test
• Interfaces

The process of controlling changes to the requirements of the systems development component, process improvement and/or organizational change

• Review and compare the requirement change with existing requirements
• Commence the organization’s change control process to obtain approval and sign-off for inclusion

New baselined requirements and updated trace matrix

A quantitative measure of a process or product

Measurements of the type associated with the project

Cost
Effort
Schedule
Risk
Resources

Measurements associated directly wit the product of the project

Defects
Performance
Size

the creation of the project plan and any associated standard documents

Those responsible in approving the project cost, resources, and scheduling

Product fitness for its intended purpose
Product quality

To identify and uncover any assumptions held by the stakeholders related to the product

Exec Sponsor
Product Manager

All project team members

During the product testing and risk review o fthe project plan.

Team members involved in product testing of project planning

Defining the optimum reporting period for different levels of eporting information

Pre-defined and ad-hoc reports

• Time (i.e. schedule)
• Cost (i.e. budget)
• Resources (Who and how much)
• Features (Any feature creep occurring)
• Quality (Defects versus plan)

The BA

Trend Analysis

• the stakeholders,
• the requirements documentation and the deliverables that will be
created,
• the appropriate technique(s) to elicit requirements that will be employed,
• the requirements traceability strategy that will be followed,
• the requirements’ attributes that will be captured, and
• the outputs of requirements elicitation

Business organization and the domain

The minimum requisite needed to contian the requirements elicitiation activities

Business domain
Corporate Culture
Environment
Analyst Skills
Requirements Deliverables

Project team members
Stakeholders

Develop a clear and concise definition of the area of interest
Define a time limit
Decide who will be included
Develop evaluation criteria

Many ideas are elicited rapidly
Promotes creativity

A means to elicit requirements of an existing system by studying available documentation and identifying relevant information

When the objective is to details an as-is system for new functionality or updates to an existing system
When there are no SMEs available

Leveraging of existing material
Means to cross check requirements from other elicitation techniques

Time consuming
Limited to documentation in place (as-is)
Risk of out-of-date documentaiton

Elicitation of ideas and attitudes about a product or service in an interactive environment

Trained moderators

Business domain
Corporate Culture
Environment
Analyst Skills
Requirements Deliverables

Project team members
Stakeholders

Develop a clear and concise definition of the area of interest
Define a time limit
Decide who will be included
Develop evaluation criteria

Many ideas are elicited rapidly
Promotes creativity

A means to elicit requirements of an existing system by studying available documentation and identifying relevant information

When the objective is to details an as-is system for new functionality or updates to an existing system
When there are no SMEs available

Leveraging of existing material
Means to cross check requirements from other elicitation techniques

Time consuming
Limited to documentation in place (as-is)
Risk of out-of-date documentaiton

Elicitation of ideas and attitudes about a product or service in an interactive environment

Trained moderators

Homogenous - individuals with similar characteristics
Heterogenous - Individuals with diverse characteristics

Save time and cost
Effective for learning attitudes and deisres

Trust
Incosistencies in data collected
Need a moderator
Scheduling

Brainstorming
Document Analysis
Observations
Prototyping
Reverse Engineering
Interview
Interface Analysis
Survey/Questionnaire
Requirements Workshop
Focus Group

Analysis intitiated by the PM and BA with the Stakeholders to agree upon system interfaces

User to system
System to sytem
Sytem to external hardware

BAs and GUI designers
Software Designers and Data Modelers

Context diagramming or domain modeling

Provides accuracy to project scope and delivery timeline
Promotes collaboration with other project members/teams

Structured - Uses a pre-defined set of questions to elicit answers
Unstructured - Open-ended discussion with nothing pre-defined

Close-ended - used to elicit a single response
Open-ended - used to elicit a dialog or series of answers/steps

Encourages participation
Direct technique
Allows for discussion
Possible to have follow-up immediately

Time commitment
Training necessary
Transcription possibly needed

Assessing the work environment of the SME

When documenting details about current processes or there is an intention to change a process

Passive - No questions asked. All note taking until process ends.
Active - direct dialog and possible active participation

BAs conducting workflow analysis, process modeling, process re-engineering
Designers creating interface requirements

Realistic and practical insight
Elicits detail from communication

Disruptive to working environment

Elicitation technique used to uncover and visualize interface requirementsprior to application design/development

Horizontal - Shallow, wide view of the system functionality
Vertical - Deep, narrow view of system functionality

Evolutionary - Extension of the intial interface reqs to a full-functioning system
Throw -away - quick interface analysis using simple tools

Early user feedback and interaction
Inexpensive if "throw-away" used
Early demonstration of feasibility if "Evo" type is used

Takes time
May lead to unrealistic expectation of functionality
Leads to the Hows, instead of the Whats

Structured requirements review to drive out scope, discover new reqs, define prioritization

JAD

Elicits detailed requirements in short amount of time
Promotes collaboration
Costs less than interviews

Stakeholder availability
Success dependent on participant expertise

An elicitation technique that extracts requirements from implemented software code

Black Box - System studied without examination of internal structure
White Box - Inner workings of system studied

Understanding of product functionality
System compatibilities
System limitations
Can help transform obsolete products

Cost benefit
Project scope

Current system investment protection
Provides detailed and current reqs

Expensive and time consuming
Copyright restrictions

Gathers information from many people in an anonymous format using a set of written questions

Closed - respondent selects from available answers
Open-ended - Respondent answers at will

Effective in obtaining quantitative data when using close-ended
Effective in yielding insights not available in other techniques when using open-ended
Effective when respondents are geopgraphically dstributed

Questioans may be left unanswered or answered incorrectly
Not good for capturing data on behaviors

Requirements are validated
Consensus is obtained
The project team is capable of implementing the requirements

Structure REqs
Create business domain model
Analyze User Reqs
Analyze Functional Reqs
Analyze Supplementary Quality of Service Reqs
Determine Assumptions and Constraints
Determine requirements attributes
Document Requirements
Validate Requirements
Verify Requirements

Fully Specified Requirements

Business Process Analysis
Object Oriented Analysis
Structured Analysis

A methodology that focuses on theimprovement of enterprise processes in order to maximize achievement of its business mission and associated objectives

A methodology that views information management systems as a collection of classes that pass messages to one another and whic contain data (attribs) and operations that are used to create and modify those attribs

The identification of use cases

Modeling the identification of complex use cases interaction between use cases or the process across multiple use cases

A methodology that views the system primarily as a collection of processes executed by the system.

The data, as it is an input and/or output of processes

Activity Diagrams
Use Cases Models
Domain Diagrams
Class Models
Sequence Diagrams

Flowcharts
Data Flow Diagrams
Functional decomp Diagrams
ERDs

To refine the boundary and solution scope definitions developed in Enterprise Analysis in order to ensure the problem model provides an accurate requirements boundary

The Requirements Elicitation KA

To allow for continuous understanding in order to prevent future waste of resources by going down the wrong path

Scope Determination of the problem domain

Where other actors interact with the system
Where other systems provide or extract data from the solution
Where time initiates activity for the solution

The structuring of the problem domain into similar functional or organizational relationships to describe the logical breakdown

To ensure that the problem is separated into sub-problems that interact as independently as possible

Decomposition of the high-level goal in order to satisfy stakeholder needs

A service that the solution provides to fulfill one or more stakeholder needs

The final solution of the analysis

The identification of high level functions of an organization and the break down of them into processes/sub-processes

The creation of an enhancement that is tied to an existing architectural structure or business process.

Understand impacts to business areas or systems

Verify scope and assess work to be done

The solution model

To describe the current and future state of the enterprise in order to obtain an accurate understanding of the as-is environment

Identify and document multiple work units performing identical functions
Identify and document multiple users performing the same work

Description of the as-is system and processes plus the to-be solution

To capture requirements that affect a particular user/user group and ensure the stakholder needs are addressed

Application distribution and use
Number of stakeholder groups
Solution complexity
Level of consensus among stakeholders

They must have been elicited

To describe the desired behavior of the solution

Specific system action or response that includes the effect that a solution must have within the problem domain, how a user interacts with the system and standards that muct be complied with

The definition of the boundary solution model that is created when the business domain model is created.

Capabilities of the solution
Conditions for the Solution to operate
Constraints that prevent operation

Event/Condition
Subject
Imperitive
Action Verb
Object
Rule
Outcome

Describes when a requirement must be fulfilled or a condition in which the solution is operating?

When there is a complex, but uniform structure which can be broken down into elements that apply to every table entry

Traceability and Prioritization

The relationship between items of information such as order or organizational structure

A template for expressing reqs that may combine textual elements, matrices, and diagrams

When the problem domain is well known
When the solution is easy to construct
When there is little collaboration needed
When there is little need for ongoing maintenance
When the scope is unlikely to grow

Simplification of reality to allow focus
Comprehension of complexity
Explanation from varying perspectives
Ensures all aspects are considered
Translate easily into solution design

The capture of requirements from a specific perspective

A view is not exclusive and its requirements may be referenced in all views that are relevant

To represent requirements of a business area

Entities that are in the problem domain and the relationships between them

Geez who cares? But the answer is:
The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.

Introduction of parties attending presentation
Statement of presentation objectives
Project background
Presentation/review of deliverable
Agreement of actions/changes required
Review of deliverable status (e.g. signed off, not signed off, etc.)

Project Life Cycle

The balanced scorecard (Robert Kaplan and David Norton 1996) provides an effective technique to frame strategic goals. In this model, goals are partitioned into four dimensions: financial, customer, internal operations, and learning and innovation, as described below.

Each model identifies a basic building block of the business, and includes the people, processes and technology needed by the component to deliver value to the customer.

An Entity Relationship Diagram (ERD) is a visual representation of a data structure.
Because they describe things that are significant to the enterprise (e.g. Customers, Products, Employees, Invoices, etc.), ERDs are useful in describing the structure of the business itself, and many of the rules by which it is governed.

....to record the conflict in the Requirements Issues Log.

Create read, update delete rights to users and groups. Good in software system development. Not applicable to business process analysis.

People, processes, technology

Component Business Model identifies a basic building block of the business, and includes the people, processes and technology needed by the component to deliver value to the customer.

Activity Diagrams, Data Flow Diagrams, Flowcharts, Sequences Diagrams, State Machine Diagrams

Use cases and text

The project team, who will use them in the design and development of the system

Appropriate framework and approach

Functional decomposition identifies the high-level functions of an organization or proposed solution and then breaks down those processes into sub-processes and activities. This can be done as part of a systems development or business process analysis project. The goal is to break functions down into smaller pieces to allow for analysis of the detail processes and to ensure coverage of all significant processes

A feature is a service that the solution provides to fulfill one or more stakeholder needs.Features are high-level abstractions of the solution that must later be expanded into fullydescribed functional and supplemental requirements. They allow for early priority and scope management and for validating the stakeholders’ view of the solution.

'An Entity Relationship Diagram has four main components:
Entities: an entity represents a group of uniquely identifiable people, places, things or concepts about which a business area needs information. (e.g. Customers, Products, Employees, Invoices, etc.).
Attributes: an attribute is one of the individual pieces of information that describes an entity (e.g. Customer Name, Product Price, Employee Number, Invoice Date). Unique Identifiers: a unique identifier is an attribute, or a combination of attributes, that will uniquely identify each separate occurrence of an entity (e.g. Customer Number, Invoice Number, Social Insurance Number).
Relationships: a relationship is a significant business association between two entities. It reflects how data from one entity needs to be used in conjunction with data from another entity. It also reflects a “business rule” of the enterprise.
At each end of a relationship line, a notation indicates the minimum and maximum number of occurrences of one entity that may be associated with the other entity. This notation is known as the “cardinality” of the relationship. A variety of notations are in popular use, all expressing the same general concept.
The possible permutations of minimum and maximum cardinality are:
Zero or one
Zero or more
One and only one
One or more'

The Quality Assurance process includes development of a test plan/strategy for the solution, execution of the test plan, and incident (defect) tracking of problems. The Business Analyst will assist these activities by providing detailed business knowledge and helping to find the cause of any problems

D. obtain requirements signoff