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 5. Requirements Analysis
http://zubkiewicz.com 1
Paweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate...
Requirements Analysis
http://zubkiewicz.com
Paweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2
pawel@zubkiewicz.com
2
BABOK – Knowledge Areas &
Tasks
http://zubkiewicz.com
Paweł Zubkiewicz TOGAF 9, OCEB, CCBA,
ArchiMate 2 pawel@zubkiewicz.c...
6 – Requirements Analysis
7/30/2016Paweł Zubkiewicz 4
ask Name Inputs Elements Techniques Stakeholders Outputs
1 Prioritiz...
6.1 Prioritize Requirements
Techniques
• General
o Decision Analysis (9.8)
o Risk Analysis (9.24)
• MoSCoW
• Timeboxing/Bu...
6.2 Organize Requirements
Techniques
• Business Rules Analysis (9.4)
• Data Flow Diagrams (9.6)
• Data Modeling (9.7)
• Fu...
6.3 Specify and Model Reqs
1. Acceptance and Evaluation Criteria
Definition (9.1) ▶
2. Business Rules Analysis (9.4) ▶
3. ...
6.4 Define Assumptions and Constraints
http://zubkiewicz.com
Paweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2
pawel@zubki...
6.5 Verify Requirements
Techniques
• General
o Acceptance and Evaluation
Criteria Definition (9.1)
o Problem Tracking (9.2...
6.6 Validate Requirements
Techniques
• Acceptance and
Evaluation Criteria
Definition (9.1)
• Metrics and Key
Performance I...
V&V
Verify Req. Validate Req.
• Are the requirements of the highest
quality?
• Do they meet the organizational
standards f...
Opportunity cost
• At the project level, opportunity cost refers to the benefits that
could have been achieved with an alt...
Q1
Your organization is trying to determine which one of two
opportunities they will pursue. The Project A is worth $235,9...
Q2
A business analyst is helping management determine which
solution they should choose. As it happens that the organizati...
And remember
6.6.4.5 Ultimately, each requirement must be traceable to
the objectives in the business case, and should als...
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 5

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

Subject of this presentation: Requirements Analysis.

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

Published in: Software
  • Be the first to comment

BABOK Study Group - meeting 5

  1. 1. BABOK Study Group Meeting 5. Requirements Analysis http://zubkiewicz.com 1 Paweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 pawel@zubkiewicz.com
  2. 2. Requirements Analysis http://zubkiewicz.com Paweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 pawel@zubkiewicz.com 2
  3. 3. BABOK – Knowledge Areas & Tasks http://zubkiewicz.com Paweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 pawel@zubkiewicz.com Source: www.projerra.ca 5.4 Define Solution Scope 3
  4. 4. 6 – Requirements Analysis 7/30/2016Paweł Zubkiewicz 4 ask Name Inputs Elements Techniques Stakeholders Outputs 1 Prioritize Requirements decision process to determine e relative importance of equirements. Ensures that fort is focused on most critical ems. Business case (5.5) Business need (5.1) Requirements Requirements Management Plan (2.5) Stakeholder list, roles, responsibilities (2.2) Implicit Input: BA plan(s) (2.3) 1. Basis for prioritization: Business value; Business or techni-cal risk; Implementation difficulty; Likelihood of success; Regulation or policy compliance; Relationship to other Requirements; Stakeholder agreement; Urgency 2. Challenges: Non-negotiable demands, General: Decision analysis (9.8) Risk analysis (9.24) Other: MoSCoW analysis Timeboxing/budgeting Voting Domain SME Implementation SME Project Manager Sponsor Requirements [Prioritized] (6.1) Implicit Output: BA perf metrics 2 Organize Requirements reate a set of views of equirements. Org process assets Requirements (stated) (3.3) Solution scope (5.4) Implicit Input: BA plan(s) (2.3) 1. Levels of abstraction 2. Model selection: User classes, profiles, roles; Con- cepts and Relationships; Events; Processes; Rules General: Business rule analysis (9.4) Data modeling (9.7) Organizational modeling (9.19) Scenarios & use cases (9.26) User stories (9.33) Data flow diagrams (9.6) Functional decomposition (9.12) Process modeling (9.21) Scope modeling (9.27 Domain SME End User Implementation SME Project Manager Sponsor Requirements Structure (6.2) Implicit Output: BA perf metrics 3 Specify and Model equirements xpress current or future state an organization (or system) sing a combination of text, atrices, diagrams, and odels. Requirements (stated) (3.3) Requirements structure (6.2) Implicit Input: BA plan(s) (2.3) 1. Text 2. Matrix documentation 3. Models 4. Capture requirement attributes 5. Improvement Opportunities General: Acceptance and evaluation criteria (9.1) Data dictionary & glossary (9.5) Data modeling (9.7) Interface analysis (9.13) Non-functional req. analysis (9.17) Process modeling (9.21) Scenarios & use cases (9.26) State diagrams (9.29) Any Requirements [Analyzed] (6.3) Implicit Output: BA perf metrics <--- any stakeholder 4 Define Assumptions & onstraints entify assumptions, limitations, r restrictions that may influence e set of viable solutions. Stakeholder concerns (3.3) Implicit Input: BA plan(s) (2.3) 1. Assumptions 2. Business constraints 3. Technical constraints General: Problem tracking (9.20) Risk analysis (9.24) Implementation SME Project Manager All stakeholders Assumptions & Constraints (6.4) Implicit Output: BA perf metrics 5 Verify Requirements nsure that the requirements pecifications and models meet e standard of quality. Requirements (any except stated) Implicit Input: BA plan(s) (2.3) 1. Characteristics of quality: Cohesive; Complete; Consistent; Correct; Feasible; Modifiable; Un- ambiguous; Testable 2. Verification activities General: Acceptance and evaluation criteria (9.1) Problem tracking (9.20) Structured walkthrough (9.30) Other: Checklists All stakeholders Requirements [Verified] (6.5) Implicit Output: BA perf metrics 6 Validate Requirements nsure that all requirements upport the delivery of value to e business and meet stake- older need. Business case (5.5) Stakeholder, solution, or Transition requirements (verified) Implicit Input: BA plan(s) (2.3) 1. Identify assumptions 2. Define measurable evaluation criteria 3. Determine business value 4. Determine dependencies for benefits realization 5. Evaluation alignment with business case and opportunity cost General: Acceptance and evaluation criteria (9.1) Metrics & KPI (9.16) Prototyping (9.22) Risk analysis (9.24) Structured walkthrough (9.30) All stakeholders Requirements [Validated] (6.6) Implicit Output: BA perf metrics Business rule analysis (9.4) Data flow diagrams (9.6) Functional decomposition (9.12) Metrics and KPI (9.16) Organizational modeling (9.19) Prototyping (9.22) Sequence diagrams (9.28) User stories (9.33)
  5. 5. 6.1 Prioritize Requirements Techniques • General o Decision Analysis (9.8) o Risk Analysis (9.24) • MoSCoW • Timeboxing/Budgeting o All in/ All out / Selective • Voting http://zubkiewicz.com Paweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 pawel@zubkiewicz.com 5 Elements • Basis for Prioritization • Challenges o Non-negotiable Demands o Unrealistic Tradeoffs Prioritization of requirements ensures that analysis and implementation efforts focus on the most critical requirements.
  6. 6. 6.2 Organize Requirements Techniques • Business Rules Analysis (9.4) • Data Flow Diagrams (9.6) • Data Modeling (9.7) • Functional Decomposition (9.12) • Organization Modeling (9.19) • Process Modeling (9.21) • Scenarios and Use Cases (9.26) • Scope Modeling (9.27) • User Stories (9.33): http://zubkiewicz.com Paweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 pawel@zubkiewicz.com 6 Elements • Levels of Abstraction • Model Selection o User Classes, Profiles, or Roles o Concepts and Relationships. o Events o Processes. o Rules The purpose of organizing requirements is to create a set of views of the requirements for the new business solution that are comprehensive, complete, consistent, and understood from all stakeholder perspectives.
  7. 7. 6.3 Specify and Model Reqs 1. Acceptance and Evaluation Criteria Definition (9.1) ▶ 2. Business Rules Analysis (9.4) ▶ 3. Data Dictionary and Glossary (9.5) ▶ 4. Data Flow Diagrams (9.6) ▶ 5. Data Modeling (9.7) ▶ 6. Functional Decomposition (9.12) ▶ 7. Interface Analysis (9.13) ▶ 8. Metrics and Key Performance Indicators (9.16) ▶ 9. Non-functional Requirements Analysis (9.17) ▶ 10. Organization Modeling (9.19) ▶ 11. Process Modeling (9.21) ▶ 12. Prototyping (9.22) ▶ 13. Scenarios and Use Cases (9.26) ▶ 14. Sequence Diagrams (9.28) ▶ 15. State Diagrams (9.29) ▶ 16. User Stories (9.33) http://zubkiewicz.com Paweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 pawel@zubkiewicz.com 7 Elements • Text • Matrix Documentation • Models • Capture Requirements Attributes • Improvement Opportunities To analyze expressed stakeholder desires and/or the current state of the organization using a combination of textual statements, matrices, diagrams and formal models.
  8. 8. 6.4 Define Assumptions and Constraints http://zubkiewicz.com Paweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 pawel@zubkiewicz.com 8 Elements • Assumptions • Business Constraints o They may reflect budgetary restrictions, time restrictions, limits on the number of resources available, restrictions based on the skills of the project team and the stakeholders, a requirement that certain stakeholders not be affected by the implementation of the solution, or any other organizational restriction. • Technical Constraints o may include development languages, hardware and software platforms, and application software that must be used. Technical constraints may also describe restrictions such as resource utilization, message size and timing, software size, maximum number of and size of files, records and data elements. Technical constraints include any enterprise architecture standards that must be followed. Identify factors other than requirements that may affect which solutions are viable.
  9. 9. 6.5 Verify Requirements Techniques • General o Acceptance and Evaluation Criteria Definition (9.1) o Problem Tracking (9.20) o Structured Walkthrough (9.30) • Checklists http://zubkiewicz.com Paweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 pawel@zubkiewicz.com 9 Elements • Characteristics of Requirements Quality • Verification Activities Requirements verification ensures that requirements specifications and models meet the necessary standard of quality to allow them to be used effectively to guide further work
  10. 10. 6.6 Validate Requirements Techniques • Acceptance and Evaluation Criteria Definition (9.1) • Metrics and Key Performance Indicators (9.16) • Prototyping (9.22) • Risk Analysis (9.24) • Structured Walkthrough (9.30) http://zubkiewicz.com Paweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 pawel@zubkiewicz.com 10 Elements • Identify Assumptions • Define Measurable Evaluation Criteria • Determine Business Value • Determine Dependencies for Benefits Realization • Evaluate Alignment with Business Case and Opportunity Cost The purpose of requirements validation is to ensure that all requirements support the delivery of value to the business, fulfill its goals and objectives, and meet a stakeholder need.
  11. 11. V&V Verify Req. Validate Req. • Are the requirements of the highest quality? • Do they meet the organizational standards for documenting reqs? • Do they meet the characteristics of excellent requirements? • Do the requirements describe a solution that will bring business value? • Will the solution meet the project objectives and solve the original business problems? http://zubkiewicz.com Paweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 pawel@zubkiewicz.com 11 Verify requirements 6.5 Validate requirements 6.6 Build or buy Solution (out of BABOK) Validate Solution 7.5
  12. 12. Opportunity cost • At the project level, opportunity cost refers to the benefits that could have been achieved with an alternative investment rather than this one. In other words, it is the cost of what you cannot do or have because you chose to invest in this project instead of another one. • This concept can also be applied to decisions made within a project. For example, if a project team spends time and energy implementing a feature in a software application, that effort cannot be applied towards additional testing, training for the users, bug fixes, or other project work. That lost work represents the opportunity cost of the decision. • The opportunity cost of any decision is equal to the value of the best alternative use of those resources. http://zubkiewicz.com Paweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 pawel@zubkiewicz.com 12
  13. 13. Q1 Your organization is trying to determine which one of two opportunities they will pursue. The Project A is worth $235,987 and Project B is worth $567,000 but carries significant risk. The organization elects to purse Project B and not Project A. What is the opportunity cost in this scenario? A. $331,013 B. There is not enough information to know as the risk for Project B has not been quantified. C. $235,987 D. $567,000 Answer: C http://zubkiewicz.com Paweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 pawel@zubkiewicz.com 13
  14. 14. Q2 A business analyst is helping management determine which solution they should choose. As it happens that the organization can only choose one of the two solutions due to time and resource restrictions. Solution A worths $456,000 to the organization while solution B worths $565,000 to the organization. While solution A costs less, it is less risky and takes less time to complete so management elects to seize Solution A. What is the opportunity cost? A. $565,000 B. There is not enough information to know how much the solution will cost the organization. C. $109,000 D. $456,000 Answer: A http://zubkiewicz.com Paweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 pawel@zubkiewicz.com 14
  15. 15. And remember 6.6.4.5 Ultimately, each requirement must be traceable to the objectives in the business case, and should also minimize the opportunity cost of implementation. http://zubkiewicz.comPaweł Zubkiewicz 15
  16. 16. 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 16

×