RADD - Details

Question 1

Common formats for specifying and modelling requirements

Answer 1

• matrices
• diagrams

Question 2

Categories used to group models, along with the specific models within those categories

Answer 2

• people and roles
  
  • organizational modelling
  • roles and permissions matrix
  • stakeholder list / map / personas
• rationale
  
  • decision modelling
  • scope modelling
  • business model canvas
  • root cause analysis
  • business rules analysis
• activity flow
  
  • process modelling
  • use cases and scenarios
  • user stories
• capability
  
  • business capability analysis
  • functional decomposition
  • prototyping
• data and information
  
  • data dictionary
  • data flow diagrams
  • data modelling
  • glossary
  • state modelling
  • interface analysis

Question 3

Reasons to decompose BA information - what you’d be looking for as part of analyzing requirements

Answer 3

• anything that must change to meet the business need
• anything that should stay the same to meet the business need
• missing components
• unnecessary components
• any constraints or assumptions that impact the components

Question 4

Dependencies that affect the level of decomposition (level of detail) to use as part of analyze requirements

Answer 4

• knowledge and understanding of the stakeholders
• potential for misunderstanding or miscommunication
• organizational standards
• contractual or regulatory obligations

Question 5

Characteristics of quality requirements

Answer 5

FACt CUP CUT

Remember this FACt, to win the CUP you can’t CUT quality

• feasible
• atomic
• complete
• consistent
• unambiguous
• prioritized
• concise
• understandable
• testable

Question 6

Requirements verification activities

Answer 6

• checking for compliance with organizational performance standards for business anlysis, such as using the right tools and methods
• checking for correct use of modelling notation, templates, or forms
• checking for completeness within each model
• comparing each model against other relevant models, checking for elements that are mentioned in one model but are missing in other models, and verifying that the elements are referenced consistently
• ensuring the terminology used in expressing the requirement is understandable to stakeholders and is consistent with the use of those terms within the organization
• adding examples where appropriate for clarification

Question 7

Purpose of a requirements architecture

Answer 7

• understand which models are appropriate for the domain, solution scope, and audience
• organize requirements into structures relevant to different stakeholders
• illustrate how requirements and models interact with and relate to each other, and show how the parts fit together into a meaningful whole
• ensure the requirements work together to achieve the overall objectives
• make trade-off decisions about requirements while considering the overall objectives

Question 8

Items for which requirements viewpoints frequently include standards and guidelines

Answer 8

• model types used for requirements
• attributes that are included and sconsistently used in different models
• model notations that are used
• analytical approaches used to identify and maintain relevant relationships among models

Question 9

Examples of viewpoints

Answer 9

• business process models
• data models and information
• user interactions, including use cases and / or user experience
• audit and security
• business models

Question 10

Quality criteria used to examine each relationship between requirements (requirements architecture)

Answer 10

• defined (there is a relationship and it has a type)
• necessary
• correct
• unambiguous
• consistent

Question 11

Solution approaches (high level options)

Answer 11

• create
• purchase
• combination of both

Question 12

Common examples of opportunities (define design options)

Answer 12

• increase efficiencies
• improve access to information
• identify additional capabilities

Question 13

Design options usually consist of many design components, each described by a design element.

This is what design elements may describe.

Answer 13

• business policies and business rules
• business processes to be performed and managed
• people who operate and maintain the solution, including their job functions and responsibilities
• operational business decisions to be made
• software applications and application components used in the solution
• organizational structures, including interactions between the organization, its customers, and its suppliers

Question 14

When analyzing potential value and recommending solutions, expected costs can include these items.

Answer 14

• timeline
• effort
• operating costs
• purchase and / or implementation costs
• maintenance costs
• physical resources
• information resources
• human resources

Question 15

When analyzing potential value and recommending solutions, expected benefits (value) can include these items.

Answer 15

• benefits
• reduced risk
• compliance with business policies and regulations
• improved user experience
• any other positive outcome

Question 16

Factors to take into consideration when assessing each design option to ensure that it represents the most effective trade-offs (analyze potential value and recommend solution)

Answer 16

• available resources
• constraints on the solution
• dependencies between requirements
• relationships with proposed vendors
• dependencies on other initiatives
• corporate culture
• sufficient cash flow for investment