Requirements Analysis and Design Definition Flashcards

(54 cards)

1
Q

RADD Tasks

A

Specify and model requirements
vErify requirements
vAlidate requirements

define Requirements architecture
define design Options
Analyze potential value and Recommend solution

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Purpose of Specify and Model Requirements task

A

to transform elicitation results into requirements and designs by refining them through analysis and synthesis.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Inputs to Specify and Model Requirements task

A

Elicitation Results (any state)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Elements of Specify and Model Requirements task

A

Model Requirements
Analyze Requirements
Represent Requirements and Attributes
Implement the Appropriate Levels of Abstraction

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Guidelines and Tools for Specify and Model Requirements task

A
Modelling Notations/Standards
Modelling Tools
Requirements Architecture
Requirements Life Cycle Management Tools
Solution Scope
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Stakeholders for Specify and Model Requirements task

A

Any stakeholder

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Outputs of Specify and Model Requirements task

A

Requirements (specified and modelled)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Purpose of Verify Requirements task

A

to ensure that requirements and designs specifications and models meet quality standards and are usable for the purpose they serve.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Tasks using Requirements (specified and modelled)

A

Verify Requirements

Validate Requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Inputs to Verify Requirements task

A

Requirements (specified and modelled)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Elements of Verify Requirements task

A

Characteristics of Requirements and Designs Quality
Verification Activities
Checklists

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Guidelines and Tools for Verify Requirements task

A

Requirements Life Cycle Management Tools

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Stakeholders of Verify Requirements task

A

All stakeholders

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Outputs of Verify Requirements task

A

Requirements (verified)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Purpose of Validate Requirements task

A

to ensure that all requirements and designs align to the business requirements and support the delivery of needed value.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Inputs to Validate Requirements task

A

Requirements (specified and modelled)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Tasks using Requirements (verified) output

A

Approve Requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Elements of Validate Requirements task

A

Identify Assumptions
Define Measurable Evaluation Criteria
Evaluate Alignment with Solution Scope

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Guidelines and Tools for Validate Requirements task

A

Business Objectives
Future State Description
Potential Value
Solution Scope

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Stakeholders of Validate Requirements task

A

All stakeholders

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Outputs of Validate Requirements task

A

Requirements (validated)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Tasks using Requirements (validated) output

A

Define Design Options

Measure Solution Performance

23
Q

Purpose of Define Requirements Architecture task

A

is to ensure that the requirements collectively support one another to fully achieve the objectives

24
Q

Inputs to Define Requirements Architecture task

A

Information Management Approach
Requirements (any state)
Solution Scope

25
Elements of Define Requirements Architecture task
Requirements Viewpoints and Views Template Architectures Completeness Relate and Verify Requirements Relationships Business Analysis Information Architecture
26
Guidelines and Tools for Define Requirements Architecture task
Architecture Management Software Legal/Regulatory Information Methodologies and Frameworks
27
Stakeholders of Define Requirements Architecture task
Domain Subject Matter Expert, Implementation Subject Matter Expert, Project Manager, Sponsor, Tester Any Stakeholder
28
Outputs of Define Requirements Architecture task
Requirements Architecture
29
Tasks using Requirements Architecture output
Prioritize Requirements Assess requirements Changes Specify and Model Requirements Define Design Options
30
Purpose of Define Design Options task
to define the solution approach, identify opportunities to improve the business, allocate requirements across solution components, and represent design options that achieve the desired future state.
31
Inputs to Define Design Options task
Change Strategy Requirements (validated, prioritized) Requirements Architecture
32
Elements of Define Design Options task
Define Solution Approaches Identify Improvement Opportunities Requirements Allocation Describe Design Options
33
Guidelines and Tools for Define Design Options task
Existing Solutions Future State Description Requirements (traced) Solution Scope
34
Stakeholders of Define Design Options task
``` Domain SME Implementation SME Operational Support Project Manager Supplier ```
35
Outputs of Define Design Options task
Design Options
36
Tasks using Design Options output
Define Change Strategy | Analyze Potential Value and Recommend Solution
37
Purpose of Analyze Potential Value and Recommend Solution task
to estimate the potential value for each design option and to establish which one is most appropriate to meet the enterprise’s requirements.
38
Inputs to Analyze Potential Value and Recommend Solution task
Potential Value | Design Options
39
Elements of Analyze Potential Value and Recommend Solution task
Expected Benefits Expected Costs Determine Value Assess Design Options and Recommend Solution
40
Guidelines and Tools for Analyze Potential Value and Recommend Solution task
Business Objectives Future State Description Risk Analysis Results Solution Scope
41
Stakeholders for Analyze Potential Value and Recommend Solution task
``` Customer Domain SME End User Implementation SME Project Manager Regulator Sponsor ```
42
Outputs of Analyze Potential Value and Recommend Solution task
Solution Recommendation
43
Tasks using Solution Recommendation output
Define Change Strategy
44
Model Categories (RAP CD)
``` Rationale Activity Flow People & Roles Capability Data & Information ```
45
Quality Characteristics of Requirements (FACt CUP CUT)
``` Feasible Atomic Complete Consistent Unambiguous Prioritized Concise Understandable Testable ```
46
Verify Requirements Techniques (AIM-R)
Acceptance and Evaluation Criteria Item Tracking Metrics and KPIs Reviews
47
"Representations"
A tangible business deliverable resulting from clarifying either the need (requirements) or the solution (designs).
48
Two types of requirements models
Matrices (mostly text) | Diagrams (graphical with some text)
49
Verification activities to be done
``` Completeness checks Comparison checks Correctness checks Compliance checks Terminology checks Examples to clarify ```
50
Quality criteria used to examine requirements relationships (DUNCC)
``` Defined Unambiguous Necessary Correct Consistent ```
51
Examples of ways to improve current state
Increased efficiencies Increased access to information Additional capabilities
52
Design Option elements (BABOSO)
``` business policies and business rules affected stakeholders business processes operational business decisions software applications organizational structures ```
53
Types of expected costs
``` schedule and effort support purchase and/or implementation resources opportunity ```
54
Considerations when assessing design options | A RODeO
``` Available resources Relationships with proposed vendor Other constraints Dependencies between requirements Other factors ```