BABOK Study Group Meeting 5. Requirements Analysis http:// zubkiewicz.com 1 Paweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 [email protected]
1
BABOKStudyGroup
Meeting 5. Requirements Analysis
http://zubkiewicz.comPaweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 [email protected]
2
Requirements Analysis
http://zubkiewicz.comPaweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 [email protected]
3
BABOK – Knowledge Areas & Tasks
http://zubkiewicz.comPaweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 [email protected]
Source: www.projerra.ca
5.4 Define Solution Scope
05/01/2023Paweł Zubkiewicz 4
6 – Requirements AnalysisTask Name Inputs Elements Techniques Stakeholders Outputs 6.1 Prioritize Requirements A decision process to determine the relative importance of requirements. Ensures that effort is focused on most critical items.
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
6.2 Organize Requirements Create a set of views of requirements.
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
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.
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
6.4 Define Assumptions & Constraints Identify assumptions, limitations, or restrictions that may influence the 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
6.5 Verify Requirements Ensure that the requirements specifications and models meet the 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.6 Validate Requirements Ensure that all requirements support the delivery of value to the business and meet stake-holder 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
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.comPaweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 [email protected]
Elements• Basis for Prioritization• Challenges
o Non-negotiable Demandso Unrealistic Tradeoffs
Prioritization of requirements ensures that analysis and implementation efforts focus on the most critical requirements.
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.comPaweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 [email protected]
Elements• Levels of Abstraction• Model Selection
o User Classes, Profiles, or Roles
o Concepts and Relationships.
o Eventso 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
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.comPaweł Zubkiewicz TOGAF 9, OCEB, CCBA,
ArchiMate 2 [email protected]
Elements• Text• Matrix Documentation• Models• Capture Requirements
Attributes• Improvement
Opportunities
To analyze expressed stakeholder desires and/or the current state of the organizationusing a combination of textual statements, matrices, diagrams and formal models.
8
6.4 Define Assumptions and Constraints
http://zubkiewicz.comPaweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 [email protected]
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 Constraintso 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
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.comPaweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 [email protected]
Elements• Characteristics of
Requirements Quality• Verification Activities
Requirements verification ensures that requirements specifications and models meetthe necessary standard of quality to allow them to be used effectively to guide furtherwork
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.comPaweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 [email protected]
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 thedelivery of value to the business, fulfill its goals and objectives, and meet a stakeholderneed.
11
V&VVerify 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.comPaweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 [email protected]
Verify requireme
nts 6.5
Validate requireme
nts 6.6
Build or buy
Solution (out of
BABOK)
Validate Solution
7.5
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.comPaweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 [email protected]
13
Q1Your 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,013B. There is not enough information to know as the risk for Project B has not been quantified.C. $235,987D. $567,000
Answer: C
http://zubkiewicz.comPaweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 [email protected]
14
Q2A 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,000B. There is not enough information to know how much the solution will cost the organization.C. $109,000D. $456,000
Answer: A
http://zubkiewicz.comPaweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 [email protected]
Paweł Zubkiewicz 15
And remember6.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.com
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.comhttp://zubkiewicz.com