babok study group - meeting 5

1

BABOKStudyGroup

Meeting 5. Requirements Analysis

http://zubkiewicz.comPaweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2 [email protected]

http://zubkiewicz.com/


2

Requirements Analysis




3

BABOK – Knowledge Areas & Tasks


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


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


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


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


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)


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?


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.




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




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




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





http://zubkiewicz.com/babok-guide-study-group-part-5/

babok study group - meeting 5

Software