1http://zubkiewicz.com

BABOKStudyGroup

Meeting 1. Introduction + Requirements

Pawel Zubkiewicz

2

AgendaIntroduction – Chapter 1

• Key concepts• Stakeholders

• BABOK Guide structure• Underlying Competencies

• Q&A

Requirements• Requirement definition• Classification scheme

• States• Characteristics + SMART

• Attributes• Relationships

• Q&A

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

4

Stakeholders

http://zubkiewicz.com

5

Stakeholders

http://zubkiewicz.com

„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

http://zubkiewicz.com

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

http://zubkiewicz.com

Example:• Requirements Analysis

o Prioritize requirements• Decision Analysis• Risk Analysis• MoSCoW Analysis• Timeboxing/Budgeting

8

Input – task - output

Source: CBAP®/CCBA® Certified Business Analysis Study Guide by S.Weese, T.Wagner

INPUT OUTPUTTASK

TECHNIQUES

OTHER TASKS

9

Input – task - output

Source: CBAP®/CCBA® Certified Business Analysis Study Guide by S.Weese, T.Wagner

INPUT OUTPUTTASK

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

http://zubkiewicz.comSource: www.projerra.ca

Knowledge Areas (KAs)

http://zubkiewicz.com

Techniques

Knowledge Areas (KAs)

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

Knowledge Areas (KAs)

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

http://zubkiewicz.com

14

Underlying Competencies

http://zubkiewicz.com

15http://zubkiewicz.com

16

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

http://zubkiewicz.com

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).

http://zubkiewicz.com

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 Requirementso 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

http://zubkiewicz.com

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

IDAuthor Complexity Priority

Ownership Stability UrgencyStatus 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 waysand exist in any of a number of different states.”

Requirements [State or States]

Chapter 1.5.3

Requirements lifecycle - statesState Task Task desc. Input StateStated (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 TraceabilityCreate 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’tsObtain 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.

27

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.comhttp://zubkiewicz.com