RADD - Details Flashcards
Common formats for specifying and modelling requirements
- matrices
- diagrams
Categories used to group models, along with the specific models within those categories
- 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
Reasons to decompose BA information - what you’d be looking for as part of analyzing requirements
- 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
Dependencies that affect the level of decomposition (level of detail) to use as part of analyze requirements
- knowledge and understanding of the stakeholders
- potential for misunderstanding or miscommunication
- organizational standards
- contractual or regulatory obligations
Characteristics of quality requirements
FACt CUP CUT
Remember this FACt, to win the CUP you can’t CUT quality
- feasible
- atomic
- complete
- consistent
- unambiguous
- prioritized
- concise
- understandable
- testable
Requirements verification activities
- 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
Purpose of a requirements architecture
- 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
Items for which requirements viewpoints frequently include standards and guidelines
- 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
Examples of viewpoints
- business process models
- data models and information
- user interactions, including use cases and / or user experience
- audit and security
- business models
Quality criteria used to examine each relationship between requirements (requirements architecture)
- defined (there is a relationship and it has a type)
- necessary
- correct
- unambiguous
- consistent
Solution approaches (high level options)
- create
- purchase
- combination of both
Common examples of opportunities (define design options)
- increase efficiencies
- improve access to information
- identify additional capabilities
Design options usually consist of many design components, each described by a design element.
This is what design elements may describe.
- 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
When analyzing potential value and recommending solutions, expected costs can include these items.
- timeline
- effort
- operating costs
- purchase and / or implementation costs
- maintenance costs
- physical resources
- information resources
- human resources
When analyzing potential value and recommending solutions, expected benefits (value) can include these items.
- benefits
- reduced risk
- compliance with business policies and regulations
- improved user experience
- any other positive outcome
