Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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
Requ...
Key concepts
• Domain - The problem area
undergoing analysis.
• Soultion - A solution meets a
business need by resolving a...
Stakeholders
http://zubkiewicz.com 4
Stakeholders
http://zubkiewicz.com 5
„By definition, the business analyst is a
stakeholder in all business analysis activi...
BABOK Guide structure
http://zubkiewicz.com
Knowledge areas:
• Business Analysis Planning
& Monitoring
• Elicitation
• Req...
class System
TaskKnowledge area
TechniqueSpecific technique
1..*
1..*
1..*1
0..*
1
BABOK Guide structure
http://zubkiewicz...
Input – task - output
Source: CBAP®/CCBA® Certified Business Analysis Study Guide by S.Weese, T.Wagner 8
INPUT OUTPUT
TASK...
Input – task - output
Source: CBAP®/CCBA® Certified Business Analysis Study Guide by S.Weese, T.Wagner 9
INPUT OUTPUT
TASK...
BABOK – Knowledge Areas &
Tasks
http://zubkiewicz.com
Source: 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 n...
Underlying Competencies
http://zubkiewicz.com 14
http://zubkiewicz.com 15
Requirements
• Definition
• Classification scheme
• Characteristics of requirements quality
• SMART
• Attributes
• States
...
Requirement definition
A requirement is:
1. A condition or capability needed by a stakeholder to
solve a problem or achiev...
Requirements
classification scheme
• Business Requirements are higher-level statements of the goals, objectives, or
needs ...
Characteristics of
requirements quality
• Cohesive: A cohesive set of requirements relates to only one thing,
whether that...
Characteristics of
requirements quality
• Feasible: Each requirement must be implementable within the existing
infrastruct...
SMART (5.1.4)
• Specific: describing something that has an observable outcome.
• Measurable: tracking and measuring the ou...
Requirements attributes
• Absolute reference (ID) is a unique numeric (preferred) or textual identifier. The reference is ...
Requirements attributes
Cara’s Soup
• C - complexity
• A - absolute reference (id)
• R - risks
• A - author
• S - status
•...
“Requirements are a special case as an input or output, which should
not be surprising given their importance to business ...
Requirements relationships
(4.2.4)
• Necessity: This relationship exists when it only makes sense to implement a
particula...
Other classification (4.3.4)
• Ongoing Requirements.
Ongoing requirements are those requirements that an organizational un...
Did you enjoy the presentation?
Do you have any questions?
Or maybe you just want to say "thanks"
Just click the pic above...
Upcoming SlideShare
Loading in …5
×

BABOK Study Group - meeting 1

2,429 views

Published on

Presentation slides from my BABOK Study Group that I led.

Those materials will help you pass BABOK certification exams. Study Group was aimed at individuals self preparing to CCBA or CBAP exams.

Please visit my blog: http://zubkiewicz.com/

Published in: Technology
  • Be the first to comment

BABOK Study Group - meeting 1

  1. 1. BABOK Study Group Meeting 1. Introduction + Requirements Pawel Zubkiewicz 1http://zubkiewicz.com
  2. 2. 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
  3. 3. 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. 4. Stakeholders http://zubkiewicz.com 4
  5. 5. Stakeholders http://zubkiewicz.com 5 „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. „
  6. 6. 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
  7. 7. 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. 8. Input – task - output Source: CBAP®/CCBA® Certified Business Analysis Study Guide by S.Weese, T.Wagner 8 INPUT OUTPUT TASK TECHNIQUES OTHER TASKS
  9. 9. 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.”
  10. 10. BABOK – Knowledge Areas & Tasks http://zubkiewicz.com Source: www.projerra.ca
  11. 11. Knowledge Areas (KAs) http://zubkiewicz.com Techniques
  12. 12. Knowledge Areas (KAs) 28 - 03 - 2013http://zubkiewicz.com Source: The BA Coach
  13. 13. 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. 14. Underlying Competencies http://zubkiewicz.com 14
  15. 15. http://zubkiewicz.com 15
  16. 16. Requirements • Definition • Classification scheme • Characteristics of requirements quality • SMART • Attributes • States • Relationships • Other classification http://zubkiewicz.com 16
  17. 17. 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
  18. 18. 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
  19. 19. 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 http://zubkiewicz.com
  20. 20. 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.
  21. 21. 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
  22. 22. 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.
  23. 23. 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
  24. 24. “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
  25. 25. 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).
  26. 26. 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. 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.com http://zubkiewicz.com 27

×