Requirements Management and Documentation (K Level 4/5) Flashcards
(148 cards)
1
Q
Rationale for requirements management (5.1)
A
Managing changes to the defined/baselines requirements & ensuring the desired level of traceability is achieved
2
Q
Elements of requirements management (5.1)
A
i.Identifying requirements.
ii. Source of the requirement.
iii. Owner of the requirement.
iv. Cross-references for the requirement.
v. Change control.
vi. Version control.
vii. Storage of the documented requirements.
3
Q
Elements of requirements management
i. Identifying requirements (5.1)
A
Each requirement should have a unique identifier - v important to know which req is under discussion or being developed
- Can be linked to type of requirement e.g. T001/T002 for technical
- Can include version number
4
Q
Elements of requirements management
ii. Source of requirement (5.1)
A
The person/document that raised the requirement
5
Q
Elements of requirements management
ii. Source of requirement - why is this useful (5.1)
A
- For backwards traceability
- provides additional information / justifies existence
- Useful for considering changes to the req: helps clarify the impact of the change/support decisions
6
Q
Elements of requirements management
iii. Owner of requirement (5.1)
A
Owner has repsonsibility for the business area affected by the requirement
- may be called upon to make decisions
7
Q
Elements of requirements management
iii. Owner of requirement - why is this useful (5.1)
A
Identifying an owner is useful if decisions need to be made about the requirement e.g. disagreements about requirements or changes to budget/timescale which may reprioritise /discontinue the requirement
8
Q
Elements of requirements management
iv. Cross-references for the requirement (5.1)
A
Related requirements & documents should be cross-references so further elaboration/information can be accessed easily
9
Q
Elements of requirements management
iv. Cross-references for the requirement
- why is it useful (5.1)
A
- Cross referencing guards against inconsistency/ fragmentation
- supports impact analysis (will the change affect other requirements)
10
Q
Elements of requirements management
v. Change Control (5.1)
A
Defining and implementing a process to manage change (DACDIR)
- Document: document change request
- Analyse: alignment to biz objectives? impact on other requirements? timeframe? budget?
- Consult: with relevant stakeholders (owner of original requirement
- Decide
- Implement/reject: version control
11
Q
Elements of requirements management
vi. Version Control / Configuration Management (5.1)
A
- Each change is recorded, creating an audit trail
Without effective configuration management problems can occur: identifying the latest requirement version / out of date requirements may be introduced / incorrect requirements may be used during development
12
Q
Elements of requirements management
vii. Storage of documented requirements (5.1)
A
- Requirements should be stored securely (can be supported by software)
- Appropriate access restrictions (who can view/edit - ensuring right stakeholders during change control process can view)
- Amendments only via change control process (if approved - new version is re-numbered
13
Q
Elements of requirements management
vii. Storage of documented requirements
- What can be used to support this? (5.1)
A
Automated software tools
- Can supports: access issues/document linkage (e.g. cross referencing)/version number
14
Q
Traceability (5.1)
Types / Why important
A
- Vertical and horizontal
- allows us to track the development throughout development lifecycle (why does it exist? what becomes of it?) or vertically to confirm alignment with overall strategy
15
Q
Traceability
1. Vertical Traceability Hierarchy (5.1)
A
Business Strategy/Objectives
Business requirements
Solution requirements
16
Q
Traceability
1. Vertical Traceability (5.1)
A
- Tracing a requirement up or down the hierarchy
17
Q
Traceability
1. Vertical Traceability
- Why is this useful? (5.1)
A
Answer questions about alignment with general/technical requirements and ultimately policies/strategies/objectives
18
Q
Traceability
1. Horizontal Traceability (5.1)
A
‘Backwards from’
- what’s the source? Who raised it?
‘Forwards to’
- what happened to this requirement
19
Q
Traceability
1. Horizontal Traceability - Why is this useful? (5.1)
A
Backwards from: when clarifications are needed/requirements are in conflict
20
Q
Explain the Change Control Process
- Why is this vital (5.2)
A
Creates a robust audit trail of any changes made to requirements and ensures any changes are justified
21
Q
Sources of change (5.2)
A
External factors:
- legal/regulatory changes
- competitive forces
Internal factors:
- change of key stakeholders/altered business priorities/change in project scope
22
Q
Change Control
- Issues if Change Control not followed (5.2)
A
- Scope creep: additional features may be introduced without thorough evaluation
- Delays: every unmanaged change can disrupt the project timeline
- Quality Compromise: Unplanned & invalidated changes can lead to defects/errors
23
Q
Version Control
- Configuration management process
Why is this needed? (5.3)
A
Configuration management ensures project artefacts are updated in a disciplined manner - any movements are clearly recorded and version numbers used for comparison & to ensure all parties are working with the correct version
24
Q
Version Control
- Configuration management process
Examples? (5.3)
A
- Movement from draft to baseline (version number reflects baseline status)
- Changes to baselined requirements
25
Version Control
- Configuration management process
(5.3)
1. CI created in draft form (indicated by version number)
2. Validation carried out (new version number reflects baseline status)
3. If further changes, new version is renumbered
26
Version Control
- Version Numbering
Why is this useful (5.3)
Any movements are clearly recorded and version numbers used for comparison & to ensure all parties are working with the correct version
27
Version Control
What is CI?
Configurable items = the deliverables to be bought under configuration (individual requirements/BRD/Models)
28
Tools in requirements management (5.4)
a. Functionality provided by tools:
i. Storage of documentation
and models.
ii. Linkage and cross-referencing.
iii. Change and version
control.
iv. Access restrictions.
28
Version Control
- Levels of configuration items (individual req/document)
CI include: individual requirement, sets of requirement (BRD) & associated models
Version numbers apply to each individual CI item
29
Requirement management
Storage of documentation & models (Explain & Justify) (5.4)
Requirement management tools can store and organise documentation (BRD/Models etc.)
Offer a central repository for easy access/retrieval of these documents
30
Requirement management
Linkage and cross-referencing (Explain & Justify) (5.4)
Software tools can aid with document/requirement linkage
Useful: impact analysis (a change in one requirements might impact another - cross referencing helps analyse interdependencies) & tracing version history
31
Requirement management
Change and version control (Explain & Justify) (5.4)
CC - modifications to requirements are managed systematically (Inc. tracking changes, documenting reasons, and ensuring that changes are approved before implementation)
VCis closely related, focusing on managing different versions of documents to facilitate rollback if needed and maintain a clear audit trail of changes over time.
32
Requirement management
Access restrictions (Explain & Justify) (5.4)
Ensures only authorised individuals can view/edit requirements. Important for data integrity & security
33
Requirement management
Storage of documentation & models
- Relationship to other requirement management tools (5.4)
- Foundation/pre-requisite for other tools
E.g. Cross referencing relies on a well organised storage system
E.g. Change/version control need a centralized repository where different versions can be stored/changes tracked
34
Requirement management
Linkage & cross referencing
- Relationship to other requirement management tools (5.4)
Heavily relies on a well organized storage system
Relationship with change/version control: if a change is proposed to one requirement, cross referencing helps identify other impacted requirements - ensures all changes are analysed thoroughly/ensure integrity
35
Requirement management
Change & version control
- Relationship to other requirement management tools (5.4)
Relationship with cross referencing: if a change is proposed to one requirement, cross referencing helps identify other impacted requirements - ensures all changes are analysed thoroughly/ensure integrity
Relationship with access restrictions : change control involves collaboration with different stakeholders. Access restrictions control who can review/approve changes & ensures the change control process is secure/transparent
36
Requirement management
Access restrictions
- Relationship to other requirement management tools (5.4)
Relationship with access restrictions : change control involves collaboration with different stakeholders. Access restrictions control who can review/approve changes & ensures the change control process is secure/transparent
Relationship with cross referencing: controls who can establish/modify links between requirements. Prevents unauthorised/ accidental changes that could affect traceability
37
Legal issues and business analysis
Examples of legal issues relevant to business analysis (5.6)
Data protection
Disability access
38
Data protection: rationale, principles and impact on requirements. (5.6)
DP = crucial for safeguarding individual privacy & ensuring the ethical & legal handling of personal information
39
Data protection: impact on requirements. (5.6)
BAs must consider DP regulations e.g. GDPR when eliciting/specifying requirements & ensure systems handle personal data ethically and securely
40
Disability Access: Rationale, Principles, and Impact on Requirements (5.6)
Imperative to create inclusive & accessible solutions (ensure organisation aligns with social responsibility and legal requirements promoting equal opportunities)
41
Disability Access: Impact on Requirements (5.6)
Need to consider disability access requirements. PESTLE can help
Examples: Captions for audio content for dead users / contrast and color requirements to aid visually impaired users
42
What tools can help BA identify legal issues? (5.6)
PESTLE
- Used as part of analysis but ongoing
- Follow change control process if new regulation/law comes in
- Explored via personas for specific req
43
Requirement Categories (5.5)
Business & Solution
Business (General & Technical)
Solution (Functional & NFR)
44
Business requirement sub categories (5.5)
General
Technical
45
Solution requirement sub categories (5.5)
Functional
Non- functional
46
What requirements are associated with enterprise level? (5.5)
Business requirements (General & Technical)
47
What requirements are associated with product/service level ? (5.5)
Solution (Functional & NFR)
They tell us what we need the system to do
48
What sits above all requirements? (5.5)
The business objectives (all requirements should vertically align to biz objectives)
49
6 types of General (business) Requirement? (5.5)
Business Constraints: Budget/Timescales/Resources
Business Policies: Standards/ Business rules
Legal: Legislative/Regulatory
Branding: Images/style guide
Cultural: Vision/approach & Management style
Language: International boundaries/spelling
50
4 types of Technical (business) Requirement? (5.5)
Hardware: IT & other hardware
Software: Operating systems/Package applications/Networking/Communications
Interoperability
Standards for communicating between systems and devices
Internet
Policies on internet use & web services / cloud
51
5 types of Functional (solution) Requirement? (5.5)
CRUD + Procedural
Create i.e. data entry
Read/retrieve i.e. reporting & responding
Update i.e. changes to data
Delete
Procedural i.e. Implementation of business rules
52
Relationship between requirement categories (5.5)
NFR's (generally) constrain FR
Business requirements constrain functional requirements
All requirements should vertically align to business objectives
53
Relationship between NFR's and FR? (5.5)
NFR's (generally) constrain FR
54
Relationship between business and solution requirements? (5.5)
Business requirements constrain functional requirements
55
What are functional requirements (5.5)
Functional requirements set out the features that a solution should provide
They are WHAT the system must do, functionality it must offer
Often summarised as CRUD
56
What can be used to summarise functional requirements (5.5)
CRUD
57
Functional requirement examples (5.5)
The system shall:
(Create)
Hold details of all customers including name, address,credit limit, date of first order
(Update)
Allow changes to be made to customer details
(Read)
Report on all orders placed in the last week
(Delete or Update)
Orders can be cancelled
(Procedural, business rule)
An insurance policy can have a maximum of 3 policyholders
58
What are non-functional requirements (5.5)
Define HOW WELL the functional requirements will be provided
59
10 Types of NFR (5.5)
Performance (speed)
Security (data/information)
Access (who - permissions and constraints)
Backup & recovery (protection)
Archiving & retention (duration/methods)
Robustness (reliability)
Business continuity ( disaster) In the book
Availability (99.9% / ad hoc etc)
Usability (ease of use)
Accessibility (insurance)
Capacity (scalability-volume)
60
NFR Example (5.5)
Only the Accounts Supervisor may change a customer’s credit limit
(access requirement)
Reprint the report on demand
(availability requirement)
Respond to an enquiry on available customer credit within 5 seconds
(performance requirement)
61
How can functional requirements be delivered (5.5)
- By the software product
- By process changes or task enhancements
- removal (if too costly/time consuming)
62
In what event would functional requirements be not delivered by the software product (5.5)
If too costly or time consuming to be included in the software product.
Removal may also be considered
63
General requirement (5.5)
Documents high-level business constraints and policies.
64
Technical requirement (5.5)
Documents high-level technical constraints and policies.
65
General requirement example (5.5)
The system must comply with the General Data Protection Regulation (GDPR) to ensure the lawful processing and protection of personal data.
All official documentation and customer communication should be available in English and Spanish to accommodate the diverse language preferences of our stakeholders.
66
Example technical requirement (5.5)
The system should run on the latest version of the operating system and be compatible with Microsoft Office 365 for seamless integration.
The system should support the latest versions of major web browsers (Chrome, Firefox, Safari) and be responsive across various screen sizes for a consistent user experience.
67
Two types of documentation styles (5.7)
Text based (requirement catalogue/user story)
Diagrammatic (data model/use case diagram / business process model)
68
Example of text based documentation? (5.7)
Text based (requirement catalogue/user story)
69
Example of diagrammatic documentation? (5.7)
Diagrammatic (data model/use case diagram / business process model)
70
Elements of requirement catalogue (5.7)
i. Identifier.
ii. Name.
iii. Description.
iv. Business area.
v. Type of requirement.
vi. Author.
vii. Source.
viii. Owner.
ix. Priority.
x. Rationale/justification.
xi. Cross-referenced
requirements.
xii. Cross-referenced
documents.
xiii. Acceptance criteria.
xiv. Status/resolution.
xv. Version number and date.
71
Elements of requirement catalogue (5.7)
Purpose of identifier
Each requirement should have a unique identifier – ensures correct requirements are developed and discussed
72
Elements of requirement catalogue (5.7)
Purpose of Name
Context/hints at content of requirement - beyond that of the unique identifier
73
Elements of requirement catalogue (5.7)
Purpose of description
Describes the feature the new system (biz/IT) needs to address
74
Elements of requirement catalogue (5.7)
Purpose of business area
What business are is affected by the requirement (should link to owner)
Maybe useful during impact analysis - is this business area ‘ready’ to successfully accept this change
75
Elements of requirement catalogue (5.7)
Purpose of type of requirement
Helps check completeness’s of requirement sets
76
Elements of requirement catalogue (5.7)
Purpose of author
Author: Identifies the analyst responsible for eliciting and documenting the requirement.
76
77
Elements of requirement catalogue (5.7)
Purpose of source
Specifies the originating person or information source for the requirement, offering insights into its origin.
78
Elements of requirement catalogue (5.7)
Purpose of owner
Designates the business stakeholder with decision-making authority for the requirement.
79
Elements of requirement catalogue (5.7)
Purpose of priority
Indicates the level of priority for the requirement, guiding the focus on critical aspects during development.
Moscow
80
Elements of requirement catalogue (5.7)
Purpose of rationale/justification
Offers the business justification for the requirement, often cross-referenced to specific benefits in the business case.
81
Elements of requirement catalogue (5.7)
Purpose of cross-referenced requirements
Identifies related requirements, providing a comprehensive view of dependencies and connections.
82
Elements of requirement catalogue (5.7)
Purpose of cross-referenced documents
Specifies documents linked to the requirement, enhancing contextual understanding.
83
Elements of requirement catalogue (5.7)
Purpose of Acceptance criteria
Outlines the criteria for formal agreement that the requirement has been successfully delivered.
84
Elements of requirement catalogue (5.7)
Purpose of status/resolution
Records the outcome of the requirement, whether implemented, deferred, merged, or dropped.
85
Elements of requirement catalogue (5.7)
Purpose of version number/date
Captures the history of the requirement, including version numbers and dates, ensuring traceability and change control.
86
What does documentation approach depend on (5.7)
Project approach
87
Documentation approach - Linear (5.7)
- Requirements documented before development
- reviewed/agreed by business and maintained as changes occur
88
Documentation approach - Agile (5.7)
- Documentation produced where necessary (often user stories)
- Requirements defined in outline in early stages with detail emerging during product development
89
Documentation commonly used in Linear projects (5.6)
Requirement catalogue
90
Documentation commonly used in agile projects (5.6)
User stories (may be supplemented by models)
91
Documentation detail depends on... - examples? (5.6)
Stage of analysis: in early stages high level documentation may be sufficient
Nature of solution: Off the shelf require less detailed documentation
Project approach: Linear - detail upfront. Agile - detail evolving throughout iterations
92
What is a user story (5.6)
Brief, informal description which provides basis for further conversation
93
What is a user story the basis for (5.6)
Further conversation
94
3C's framework for user stories (5.6)
Card (format - ensures conciseness)
Conversation (placeholder for further discussion)
Confirmation (AC)
95
Format of user story (5.6)
"As a {user role}, I want {feature} so that I can {reason}."
96
Why is documentation crucial in requirements engineering? (5.6)
1. Enables communication between project team - ensure consistency
2. Provides biz managers and staff (owners and source) with a firm basis for validation
3. Testing / development work uses documentation as an input (with AC)
4. Enhances analysis: Used to clarify understanding/cross checked for completeness/identify gaps & generate further questions
ensure that standardised, accurate and complete
documentation is produced and maintained for both individual
requirements and the entire requirements set
97
How often should documentation be revisited or referred to in the requirements engineering process? (5.6)
Documentation should be revisited/referred to at each stage of the process, as illustrated by the requirements engineering framework.
98
What factors influence the variation in documentation during requirements engineering?
Documentation will vary based on the method used to deliver requirements and the solution, considering the project approach and the type of requirement e.g. General requirement: narrative (with source/owner important) or functional data requirement where a data model is more appropriate
99
Documentation style of general requirement vs functional requirement
General: Narrative
- source /owner important
Functional: use case models or user stories
100
Documentation and continuous improvement (5.6)
approach to documentation should be iterative and open to improvement
101
What do requirements documentation and modelling ensure?
These techniques ensure that standardised, accurate and complete
documentation is produced and maintained for both individual
requirements and the entire requirements set
102
Rationale for modelling requirements (5.7)
1. To provide a visual representation of the intended solution - unambiguous communication
2. Confirm functional requirements and identify errors.
3.Enhance understanding for both analysts and stakeholders.
103
Why are conceptual models useful? (5.7)
Represent high-level abstractions of a system.
They help in understanding the system's structure and behavior.
104
Purpose of use case model (5.7)
Describe a piece of system functionality that delivers value to the actor
focuses on the ‘what’ not the ‘how’
105
Purpose of data models (5.7)
Data models represent the structure and relationships within a database.
106
What sort of model is a use cade model (5.7)
Functional model
107
What does a full use case model contain (5.7)
Use case diagram
use case description
108
How can use cases be fulfilled (5.7)
Software product
Manual business process
109
What naming convention is applied to use cases? (5.7)
Verb noun i.e. make payment / cancel ticket
110
Why are use cases useful? (5.7)
Use Case Diagrams summarise functional requirements for the IT/Business system. They represent the user perspective and needs
111
What are the levels in a use case diagram? (5.7)
Rectangle - System boundary (part/whole)
Stick figures - System Actors (/user roles) interacting with the system (their goals)
Circles with verb noun - system functionality
Association - shows how the interaction between actors and the system
112
Examples of actors in a use case model (5.7)
Human i.e user
Non-human i.e. another system/time
113
2 relationship types of use cases (5.7)
«Include» (ALWAYS) e.g. after given bill , take payment / buy ticket, receive ticket
- Dotted arrow with head pointing towards second piece of functionality
«Extend» (IF) e.g. customer order food «extend» order wine (IF the customer wants to order wine) e.g. buy item, apply discount
- Dotted arrow with head pointing towards first piece of functionality (functionality it is dependant on)
114
What can be used to support a use case diagram? (5.7)
Use case description
115
Pre conditions (i.e. customer must have an account)
Triggering event
Step by step narrative between the system & the user
Goal
Post conditions (i.e. view what they have access to)
Should also include: Name/ID/Description/Actors/Pre-conditions/Main scenario + Alternative flows/Post-conditions
116
What can a use case description be supported by? (5.6)
A process flow diagram (rather than step by step)
117
What does a use case not capture/consider? (5.6)
Information needed / data
118
Examples of data models (5.6)
(Entity) Relationship Diagram (ERD) & Class Diagrams
119
What is a class diagram? (5.6)
Conceptual model of the data that needs to be held
120
Elements of class diagram (5.6)
CALM
1. Classes (datagroups)
Things/Events/Places/People & Organisaions
2. Attributes (information to be held of the classes)
3. Logical Associations (between classes)
4. Multiplicities (How many instances one class can be associated with in another class
- Read “Each ‘class’ is associated with #..’ of the ‘other class’”
(5. operations)
121
How should multiplicities be read? (5.6)
At the end of the association
122
What does a class model not consider?
Technology/Processes/Constraints (i.e time)
It is conceptual
123
How is a class represented in a class model?
A simple rectangle with the name of the class in the top compartment
Always written as a noun phrase i.e. Customer / BankAccount (Camel case)
124
What does an association represent in a class model?
A logical/meaningful correspondence between classes
e.g. Customer MAKES booking
Passenger TRAVELS on train
125
Business rules and use case diagrams
Access restrictions: e.g. only managers can approve expenses (constraint)
Operational guidance: e.g. steps to define how commission is calculated
126
Where can use cases diagrams be used?
Throughout the RE process (eliciting, analysing
and validating requirements.)
127
Use case diagrams within elicitation stage
- Identify use case (functional req)
- help understand how actors (users/other system) interact with the system
128
Use case diagrams within analysis stage
System boundary helps identify dependencies/ interactions beyond the system
Identify gaps to be explored further (maybe back to elicitation)
129
Use case diagrams within validation stage
Ensuring stakeholder agreement - a picture paints a thousand words
Refinement of use cases
130
Object vs class - class model
An object is an instance of a class
E.g. Object: each employee within a HR system
Class 'a template': an employee - generic definition of the data to be held about employees
Objects are the things that a system manipulates in order to realise required functionality; classes are templates for a particular type of object.
131
Purpose of data models
Represents and describes system data requirements.
132
Grouping of data - class model
Class model represents groupings of data items (attributes)
Classes act as templates for specific types of objects.
133
Relationships between groupings - class model
Associations in class modelling represent relationships between data groupings (classes).
Multiplicities define the degree of relationships, indicating how many instances of one class can be associated with another.
134
Optionality - Class model
Optionality in relationships defined by multiplicities.
Multiplicities indicate minimum and maximum instances, representing types of optionality.
Example: '*' denotes no upper limit in the association.
135
Why cross check models?
alignment, exposing omissions or errors & increase quality of overall solution
136
What tool can be used to cross check models
CRUD Matrix
137
Potential actions from CRUD matrix
- Missing use cases?
- Are classes required? (no CRUD)
138
What two elements are in CRUD matrix
Classes & use case
139
Data models and business rules
Data models help analyse business rules
E.g. class model depict entities and their attributes - business rules can govern attributes (what information should be captured)
E.g. business rule: attribute of price cannot be negative / 11 digits in phone number
E.g. Multiplicity: Reflect constraints on occurrences E.g. a line manager can have a maximum of 5 direct reports
140
What is prototyping?
Modelling tool where a 'representation system' is created
141
Why is prototyping useful?
Elicit/elaborate requirements
Stakeholders can visualise / enhances communication
142
Drawbacks / consideration factors of prototyping
Can lead to scope creep / cause unrealistic expectations
143
Advantages/disadvantages of agile documentation approach
+
reduces the maintenance overhead of managing a detailed requirements document while the solution is being developed
-
could lead to inconsistencies and scope creep
144
Errors and omissions identified from CRUD
Use case for creating customer but nothing about deleting, is there an omission here?
A class may not have any elements of crud against use cases, is this required.?
145
What do use cases do to classes within CRUD
Manipulate the data
146
What is acceptance criteria
Tests that the required feature has been delivered correctly
