BABOK Study Group - meeting 1

BABOK
Study
Group
Meeting 1. Introduction + Requirements
Pawel Zubkiewicz 1http://zubkiewicz.com

Agenda
Introduction – Chapter 1
• Key concepts
• Stakeholders
• BABOK Guide structure
• Underlying Competencies
• Q&A
Requirements
• Requirement definition
• Classification scheme
• States
• Characteristics + SMART
• Attributes
• Relationships
• Q&A
2

Key concepts
• Domain - The problem area
undergoing analysis.
• Soultion - A solution meets a
business need by resolving a
problem or allowing an
organization to take advantage of
an opportunity.
• Requirement
http://zubkiewicz.com

Stakeholders
http://zubkiewicz.com 4

Stakeholders
„By definition, the business analyst is a
stakeholder in all business analysis activities.
The BABOK® Guide is written with the
presumption that the business analysis is
responsible and accountable for the execution of
these activities. „

BABOK Guide structure
Knowledge areas:
• Business Analysis Planning
& Monitoring
• Elicitation
• Requirements Management
& Communication
• Enterprise Analysis
• Requirements Analysis
• Solution Assessment &
Validation
class System
TaskKnowledge area
TechniqueSpecific technique
1..*
1..*
1..*1
0..*
1

class System
TaskKnowledge area
TechniqueSpecific technique
1..*
1..*
1..*1
0..*
1
BABOK Guide structure
Example:
• Requirements Analysis
o Prioritize requirements
• Decision Analysis
• Risk Analysis
• MoSCoW Analysis
• Timeboxing/Budgeting

Input – task - output
Source: CBAP®/CCBA® Certified Business Analysis Study Guide by S.Weese, T.Wagner 8
INPUT OUTPUT
TASK
TECHNIQUES
OTHER TASKS

Input – task - output
Source: CBAP®/CCBA® Certified Business Analysis Study Guide by S.Weese, T.Wagner 9
INPUT OUTPUT
TASK
TECHNIQUES
OTHER TASKS
„The input or output only needs to be
sufficiently complete to allow successive work
to begin.
Similarly, there may be one or many instances of
an output created as part of any given initiative.
Finally, the creation of an output does not
necessarily require that subsequent tasks which
use that work product as an input must begin.”

BABOK – Knowledge Areas &
Tasks
Source: www.projerra.ca

Knowledge Areas (KAs)
Techniques

28 - 03 - 2013http://zubkiewicz.com
Source: The BA Coach

Knowledge Areas:
• Business analysis planning and monitoring. This explains how to decide what you need to do to complete an "analyst
effort" (in other words, how to plan your project). This chapter will help you intelligently decide which stakeholders, tools,
tasks and techniques you will need to get the job done.
• Requirements elicitation. This describes the interview and research process-how to best extract needs from stakeholders
(and even how to recognize needs they don't know they have). Elements such as metrics (tracking the amount of time spent
eliciting requirements) and elicitation techniques (prototyping and brainstorming are just a few) are among the topics
covered.
• Requirements management and communication. This describes how to identify business needs (the why of the project;
whereas requirements are the how) and state the scope of their solutions. As the chapter notes, this is a crucial piece of the
analyst's work. The authors cover the SMART criteria of measurement, along SWOT analysis and other measurement
factors that make identifying this root cause data objective and tangible.
• Enterprise analysis. This outlines the crucial (and sometimes political) process of keeping everyone in the loop and on the
same page regarding your project's direction and progress. The chapter delves into such details as the requirements review
and approval processes (including record-keeping).
• Requirements analysis. This elaborates how to write/state requirements that will meet business needs. Key sections
include methods for prioritizing and organizing your requirements, as well as the most beneficial techniques for requirements
presentation (including state diagrams, prototyping, data flow diagrams, and process modeling, and more).
• Solution assessment and validation. This details how to choose the best solutions for specific business needs (as well as
assessing how well the chosen solution worked after its implementation).This chapter will help you understand risks,
dependencies, and limitations that must be identified before proposing any solution.
Other:
• Underlying competencies. This chapter describes behaviors and competencies common to good analysts, including such
details as innovative thinking, learning one's business and industry, practicing good organizational skills, and ethics. (Rather
that the structure outlined above, sections in this chapter are Purpose, Definition, and Effectiveness Measures.)
• Techniques. This covers the myriad techniques that analysts use to accomplish their work
Source: Modern Analyst

Underlying Competencies

Requirements
• Definition
• Classification scheme
• Characteristics of requirements quality
• SMART
• Attributes
• States
• Relationships
• Other classification

Requirement definition
A requirement is:
1. A condition or capability needed by a stakeholder to
solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed
by a solution or solution 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).

Requirements
classification scheme
• Business Requirements are higher-level statements of the goals, objectives, or
needs of the enterprise. They describe the reasons why a project has been initiated, the objectives that
the project will achieve, and the metrics that will be used to measure its success. Business requirements
describe needs of the organization as a whole, and not groups or stakeholders within it. They are
developed and defined through enterprise analysis.
• Stakeholder 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. Stakeholder requirements serve as a bridge between business requirements
and the various classes of solution requirements. They are developed and defined through requirements
analysis.
• Solution Requirements describe the characteristics of a solution that meet business
requirements and stakeholder requirements. They are developed and defined through requirements
analysis. They are frequently divided into sub-categories, particularly when the requirements describe a
software solution:
o Functional Requirements
o Non-functional Requirements
• Transition Requirements describe capabilities that the solution must have in order to
facilitate transition from the current state of the enterprise to a desired future state, but that will not be
needed once that transition is complete
• Technical Requirements – out of a scope of BABOK Guide

Characteristics of
requirements quality
• Cohesive: A cohesive set of requirements relates to only one thing,
whether that is a business process, business rule, organizational unit,
or so forth. All requirements in a set or model should support its overall
purpose and scope.
• Complete: The entire set of requirements should represent all relevant
requirements. Also each individual requirement should be complete.
Ensure each requirement is self-contained without any missing
information.
• Consistent: Ensure that individual requirements do not contradict each
other or describe the same requirement using different wording. In
addition, the level of detail supplied for each requirement in a set or
model should be the same.
• Correct: Defects in requirements will lead to defects in the resulting
solution

Characteristics of
requirements quality
• Feasible: Each requirement must be implementable within the existing
infrastructure, with the existing budget, timeline and resources available
• Modifiable: Related requirements must be grouped together in order
for requirements to be modifiable. This characteristic is exhibited by a
logical structuring of the requirements.
• Unambiguous: Individual requirements must never be unclear. A
requirement must not allow for multiple divergent valid interpretations of
the requirement.
• Testable: There must be a way to prove that a requirement has been
fulfilled. Each requirement should be testable—that is, it must be
possible to design a test that can be used to determine if a solution has
met the requirement or some other means of determining whether to
accept a solution that meets the requirement.

SMART (5.1.4)
• Specific: describing something that has an observable outcome.
• Measurable: tracking and measuring the outcome
• Achievable: testing the feasibility of the effort
• Relevant: in alignment with the organization’s key vision, mission,
goals
• Time-bounded: has a defined timeframe that is consistent with the
business need

Requirements attributes
• Absolute reference (ID) is a unique numeric (preferred) or textual identifier. The reference is not to
be altered or re-used if the requirement is moved, changed or deleted.
• Author of the requirement If the requirement is later found to be ambiguous the author may be
consulted for clarification.
• Complexity indicates how difficult the requirements will be to implement. This is often indicated
through qualitative scales based on number of interfaces, complexity of essential processes or the
number and nature of the resources required.
• Ownership indicates the individual or group that needs the requirement or will be the business owner
after the project is released into the target environment.
• Priority indicates which requirements need to be implemented first. See below for further discussion on
prioritizing and managing requirements.
• Risks associated with meeting or not meeting the requirements.
• Source of the requirement. Every requirement must originate from a source that has the authority
to define this particular set of requirements. The source must be consulted if the requirement changes, or
if more information regarding the requirement or the need that drove the requirement has to be obtained.
• Stability is used to indicate how mature the requirement is. This is used to determine whether the
requirement is firm enough to start work on. Note that the ongoing presence of large numbers of unstable
core requirements may indicate significant risk to project continuance.
• Status of the requirement, indicating such things as whether it is proposed, accepted, verified,
postponed, cancelled, or implemented.
• Urgency indicates how soon the requirement is needed. It is usually only necessary to specify this
separately from the priority when a deadline exists for implementation.

Requirements attributes
Cara’s Soup
• C - complexity
• A - absolute reference (id)
• R - risks
• A - author
• S - status
• S - stability
• O - ownership
• U - urgency
• P - priority
Cara's Pumpkin Soup
ID
Author Complexity Priority
Ownership Stability Urgency
Status Risks

“Requirements are a special case as an input or output, which should
not be surprising given their importance to business analysis. They are
the only input or output that is not produced by a single task.
Requirements can be classified in a number of different ways
and exist in any of a number of different states.”
Requirements [State or States]
Chapter 1.5.3
Requirements lifecycle - states
State Task Task desc. Input State
Stated
(Unconfirmed)
3.3 Document Elicitation Results
Record the information provided by stakeholders for use
in analysis.
- None -
(Stated)
Confirmed
3.4 Confirm Elicitation Results
Validate that the stated requirements expressed by the
stakeholder match the stakeholder’s understanding of the
problem and the stakeholder’s needs
Stated
Communicated 4.5 Communicate Requirements
Communicating requirements is essential for bringing
stakeholders to a common understanding of requirements - Any state -
Traced 4.2 Mange Req’ts Traceability
Create and maintain relationships between business
objectives, requirements, other team deliverables, and
solution components to support business analysis or other
activities
- Any state -
Approved 4.1 Manage Solution Scope and Req’ts
Obtain and maintain consensus among key stakeholders
regarding the overall solution scope and the requirements
that will be implemented.
Communicated
or Traced
Maintained & Re-
usable
4.3 Maintain Req’ts for Re-use
To manage knowledge of requirements following their
implementation - Any state -
Prioritized 6.1 Prioritize Requirements
A decision process to determine the relative importance of
requirements. Ensures that effort is focused on most
critical items.
- Any state -
Analyzed 6.3 Specify and Model Requirements
Express current or future state of an organization (or
system) using a combination of text, matrices, diagrams,
and models.
-At least
Stated-
Verified 6.5 Verify Requirements
Ensure that the requirements specifications and models
meet the standard of quality.
- Any except
Stated -
Validated 6.6 Validate Requirements
Ensure that all requirements support the delivery of value
to the business and meet stake-holder need.
Verified
Allocated 7.2 Allocate Requirements
Allocate requirements among solution components &
releases to maximize business value
Prioritized or
Approved

Requirements relationships
(4.2.4)
• Necessity: This relationship exists when it only makes sense to implement a
particular requirement if a related requirement is also implemented. This relationship
may be unidirectional or bi-directional.
• Effort: This relationship exists when a requirement is easier to implement if a
related requirement is also implemented.
• Subset: When the requirement is the decomposed outcome of another
requirement.
• Cover: When the requirement fully includes the other requirement. This is a special
case of subset, where the top-level requirement is the sum of the sub-requirements
• Value: When including a requirement affects the desirability of a related
requirement (either increasing or decreasing it). This may occur because the related
requirement is only necessary if the first requirement is implemented, or because only
one of the requirements should be implemented (for instance, when discussing two
features that potentially meet a business requirement).

Other classification (4.3.4)
• Ongoing Requirements.
Ongoing requirements are those requirements that an organizational unit is
required to be able to meet on a continuous basis. These may include
contractual obligations, quality standards, service level agreements, business
rules, business processes, or requirements describing the work products the
group produces.
• Satisfied Requirements.
Even though a requirement has been satisfied, it is still a requirement as long
as the business stakeholders need it. Maintaining these requirements helps
with product enhancements and future system changes. Existing requirements
may also be re-used on related business projects.

Did you enjoy the presentation?
Do you have any questions?
Or maybe you just want to say "thanks"
Just click the pic above to visit my blog http://zubkiewicz.com

BABOK Study Group - meeting 1

More Related Content

What's hot

Similar to BABOK Study Group - meeting 1

Recently uploaded

BABOK Study Group - meeting 1

Editor's Notes