Requirements Analysis and Design Definition Flashcards

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
Q

Elements of Define Requirements Architecture task

A

Requirements Viewpoints and Views
Template Architectures
Completeness
Relate and Verify Requirements Relationships
Business Analysis Information Architecture

26
Q

Guidelines and Tools for Define Requirements Architecture task

A

Architecture Management Software
Legal/Regulatory Information
Methodologies and Frameworks

27
Q

Stakeholders of Define Requirements Architecture task

A

Domain Subject Matter Expert, Implementation Subject Matter Expert, Project Manager, Sponsor, Tester

Any Stakeholder

28
Q

Outputs of Define Requirements Architecture task

A

Requirements Architecture

29
Q

Tasks using Requirements Architecture output

A

Prioritize Requirements
Assess requirements Changes
Specify and Model Requirements
Define Design Options

30
Q

Purpose of Define Design Options task

A

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
Q

Inputs to Define Design Options task

A

Change Strategy
Requirements (validated, prioritized)
Requirements Architecture

32
Q

Elements of Define Design Options task

A

Define Solution Approaches
Identify Improvement Opportunities
Requirements Allocation
Describe Design Options

33
Q

Guidelines and Tools for Define Design Options task

A

Existing Solutions
Future State Description
Requirements (traced)
Solution Scope

34
Q

Stakeholders of Define Design Options task

A
Domain SME
Implementation SME
Operational Support
Project Manager
Supplier
35
Q

Outputs of Define Design Options task

A

Design Options

36
Q

Tasks using Design Options output

A

Define Change Strategy

Analyze Potential Value and Recommend Solution

37
Q

Purpose of Analyze Potential Value and Recommend Solution task

A

to estimate the potential value for each design option and to establish which one is most appropriate to meet the enterprise’s requirements.

38
Q

Inputs to Analyze Potential Value and Recommend Solution task

A

Potential Value

Design Options

39
Q

Elements of Analyze Potential Value and Recommend Solution task

A

Expected Benefits
Expected Costs
Determine Value
Assess Design Options and Recommend Solution

40
Q

Guidelines and Tools for Analyze Potential Value and Recommend Solution task

A

Business Objectives
Future State Description
Risk Analysis Results
Solution Scope

41
Q

Stakeholders for Analyze Potential Value and Recommend Solution task

A
Customer
Domain SME
End User
Implementation SME
Project Manager
Regulator
Sponsor
42
Q

Outputs of Analyze Potential Value and Recommend Solution task

A

Solution Recommendation

43
Q

Tasks using Solution Recommendation output

A

Define Change Strategy

44
Q

Model Categories (RAP CD)

A
Rationale
Activity Flow
People & Roles
Capability
Data & Information
45
Q

Quality Characteristics of Requirements (FACt CUP CUT)

A
Feasible
Atomic
Complete
Consistent
Unambiguous
Prioritized
Concise 
Understandable
Testable
46
Q

Verify Requirements Techniques (AIM-R)

A

Acceptance and Evaluation Criteria
Item Tracking
Metrics and KPIs
Reviews

47
Q

“Representations”

A

A tangible business deliverable resulting from clarifying either the need (requirements) or the solution (designs).

48
Q

Two types of requirements models

A

Matrices (mostly text)

Diagrams (graphical with some text)

49
Q

Verification activities to be done

A
Completeness checks
Comparison checks
Correctness checks
Compliance checks
Terminology checks
Examples to clarify
50
Q

Quality criteria used to examine requirements relationships (DUNCC)

A
Defined
Unambiguous
Necessary
Correct
Consistent
51
Q

Examples of ways to improve current state

A

Increased efficiencies
Increased access to information
Additional capabilities

52
Q

Design Option elements (BABOSO)

A
business policies and business rules
affected stakeholders
business processes
operational business decisions
software applications
organizational structures
53
Q

Types of expected costs

A
schedule and effort
support
purchase and/or implementation
resources
opportunity
54
Q

Considerations when assessing design options

A RODeO

A
Available resources
Relationships with proposed vendor
Other constraints
Dependencies between requirements
Other factors