Requirements Management and Documentation (K Level 4/5) Flashcards
Rationale for requirements management (5.1)
Managing changes to the defined/baselines requirements & ensuring the desired level of traceability is achieved
Elements of requirements management (5.1)
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.
Elements of requirements management
i. Identifying requirements (5.1)
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
Elements of requirements management
ii. Source of requirement (5.1)
The person/document that raised the requirement
Elements of requirements management
ii. Source of requirement - why is this useful (5.1)
- For backwards traceability
- provides additional information / justifies existence
- Useful for considering changes to the req: helps clarify the impact of the change/support decisions
Elements of requirements management
iii. Owner of requirement (5.1)
Owner has repsonsibility for the business area affected by the requirement
- may be called upon to make decisions
Elements of requirements management
iii. Owner of requirement - why is this useful (5.1)
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
Elements of requirements management
iv. Cross-references for the requirement (5.1)
Related requirements & documents should be cross-references so further elaboration/information can be accessed easily
Elements of requirements management
iv. Cross-references for the requirement
- why is it useful (5.1)
- Cross referencing guards against inconsistency/ fragmentation
- supports impact analysis (will the change affect other requirements)
Elements of requirements management
v. Change Control (5.1)
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
Elements of requirements management
vi. Version Control / Configuration Management (5.1)
- 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
Elements of requirements management
vii. Storage of documented requirements (5.1)
- 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
Elements of requirements management
vii. Storage of documented requirements
- What can be used to support this? (5.1)
Automated software tools
- Can supports: access issues/document linkage (e.g. cross referencing)/version number
Traceability (5.1)
Types / Why important
- 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
Traceability
1. Vertical Traceability Hierarchy (5.1)
Business Strategy/Objectives
Business requirements
Solution requirements
Traceability
1. Vertical Traceability (5.1)
- Tracing a requirement up or down the hierarchy
Traceability
1. Vertical Traceability
- Why is this useful? (5.1)
Answer questions about alignment with general/technical requirements and ultimately policies/strategies/objectives
Traceability
1. Horizontal Traceability (5.1)
‘Backwards from’
- what’s the source? Who raised it?
‘Forwards to’
- what happened to this requirement
Traceability
1. Horizontal Traceability - Why is this useful? (5.1)
Backwards from: when clarifications are needed/requirements are in conflict
Explain the Change Control Process
- Why is this vital (5.2)
Creates a robust audit trail of any changes made to requirements and ensures any changes are justified
Sources of change (5.2)
External factors:
- legal/regulatory changes
- competitive forces
Internal factors:
- change of key stakeholders/altered business priorities/change in project scope
Change Control
- Issues if Change Control not followed (5.2)
- 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
Version Control
- Configuration management process
Why is this needed? (5.3)
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
Version Control
- Configuration management process
Examples? (5.3)
- Movement from draft to baseline (version number reflects baseline status)
- Changes to baselined requirements
Version Control
- Configuration management process
(5.3)
- CI created in draft form (indicated by version number)
- Validation carried out (new version number reflects baseline status)
- If further changes, new version is renumbered
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
Version Control
What is CI?
Configurable items = the deliverables to be bought under configuration (individual requirements/BRD/Models)
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.
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
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
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
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.
Requirement management
Access restrictions (Explain & Justify) (5.4)
Ensures only authorised individuals can view/edit requirements. Important for data integrity & security
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
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
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
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
Legal issues and business analysis
Examples of legal issues relevant to business analysis (5.6)
Data protection
Disability access
Data protection: rationale, principles and impact on requirements. (5.6)
DP = crucial for safeguarding individual privacy & ensuring the ethical & legal handling of personal information
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
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)
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
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
Requirement Categories (5.5)
Business & Solution
Business (General & Technical)
Solution (Functional & NFR)
Business requirement sub categories (5.5)
General
Technical
Solution requirement sub categories (5.5)
Functional
Non- functional
What requirements are associated with enterprise level? (5.5)
Business requirements (General & Technical)
What requirements are associated with product/service level ? (5.5)
Solution (Functional & NFR)
They tell us what we need the system to do
What sits above all requirements? (5.5)
The business objectives (all requirements should vertically align to biz objectives)
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
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
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
Relationship between requirement categories (5.5)
NFR’s (generally) constrain FR
Business requirements constrain functional requirements
All requirements should vertically align to business objectives
Relationship between NFR’s and FR? (5.5)
NFR’s (generally) constrain FR
Relationship between business and solution requirements? (5.5)
Business requirements constrain functional requirements
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
What can be used to summarise functional requirements (5.5)
CRUD
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
What are non-functional requirements (5.5)
Define HOW WELL the functional requirements will be provided
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)
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)
How can functional requirements be delivered (5.5)
- By the software product
- By process changes or task enhancements
- removal (if too costly/time consuming)
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
General requirement (5.5)
Documents high-level business constraints and policies.
Technical requirement (5.5)
Documents high-level technical constraints and policies.
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.
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.
Two types of documentation styles (5.7)
Text based (requirement catalogue/user story)
Diagrammatic (data model/use case diagram / business process model)
Example of text based documentation? (5.7)
Text based (requirement catalogue/user story)
Example of diagrammatic documentation? (5.7)
Diagrammatic (data model/use case diagram / business process model)
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.
Elements of requirement catalogue (5.7)
Purpose of identifier
Each requirement should have a unique identifier – ensures correct requirements are developed and discussed
Elements of requirement catalogue (5.7)
Purpose of Name
Context/hints at content of requirement - beyond that of the unique identifier
Elements of requirement catalogue (5.7)
Purpose of description
Describes the feature the new system (biz/IT) needs to address
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
Elements of requirement catalogue (5.7)
Purpose of type of requirement
Helps check completeness’s of requirement sets
Elements of requirement catalogue (5.7)
Purpose of author
Author: Identifies the analyst responsible for eliciting and documenting the requirement.
Elements of requirement catalogue (5.7)
Purpose of source
Specifies the originating person or information source for the requirement, offering insights into its origin.
Elements of requirement catalogue (5.7)
Purpose of owner
Designates the business stakeholder with decision-making authority for the requirement.
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
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.
Elements of requirement catalogue (5.7)
Purpose of cross-referenced requirements
Identifies related requirements, providing a comprehensive view of dependencies and connections.
Elements of requirement catalogue (5.7)
Purpose of cross-referenced documents
Specifies documents linked to the requirement, enhancing contextual understanding.
Elements of requirement catalogue (5.7)
Purpose of Acceptance criteria
Outlines the criteria for formal agreement that the requirement has been successfully delivered.
Elements of requirement catalogue (5.7)
Purpose of status/resolution
Records the outcome of the requirement, whether implemented, deferred, merged, or dropped.
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.
What does documentation approach depend on (5.7)
Project approach
Documentation approach - Linear (5.7)
- Requirements documented before development
- reviewed/agreed by business and maintained as changes occur
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
Documentation commonly used in Linear projects (5.6)
Requirement catalogue
Documentation commonly used in agile projects (5.6)
User stories (may be supplemented by models)
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
What is a user story (5.6)
Brief, informal description which provides basis for further conversation
What is a user story the basis for (5.6)
Further conversation
3C’s framework for user stories (5.6)
Card (format - ensures conciseness)
Conversation (placeholder for further discussion)
Confirmation (AC)
Format of user story (5.6)
“As a {user role}, I want {feature} so that I can {reason}.”
Why is documentation crucial in requirements engineering? (5.6)
- Enables communication between project team - ensure consistency
- Provides biz managers and staff (owners and source) with a firm basis for validation
- Testing / development work uses documentation as an input (with AC)
- 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
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.
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
Documentation style of general requirement vs functional requirement
General: Narrative
- source /owner important
Functional: use case models or user stories
Documentation and continuous improvement (5.6)
approach to documentation should be iterative and open to improvement
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
Rationale for modelling requirements (5.7)
- To provide a visual representation of the intended solution - unambiguous communication
- Confirm functional requirements and identify errors.
3.Enhance understanding for both analysts and stakeholders.
Why are conceptual models useful? (5.7)
Represent high-level abstractions of a system.
They help in understanding the system’s structure and behavior.
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’
Purpose of data models (5.7)
Data models represent the structure and relationships within a database.
What sort of model is a use cade model (5.7)
Functional model
What does a full use case model contain (5.7)
Use case diagram
use case description
How can use cases be fulfilled (5.7)
Software product
Manual business process
What naming convention is applied to use cases? (5.7)
Verb noun i.e. make payment / cancel ticket
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
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
Examples of actors in a use case model (5.7)
Human i.e user
Non-human i.e. another system/time
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)
What can be used to support a use case diagram? (5.7)
Use case description
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
What can a use case description be supported by? (5.6)
A process flow diagram (rather than step by step)
What does a use case not capture/consider? (5.6)
Information needed / data
Examples of data models (5.6)
(Entity) Relationship Diagram (ERD) & Class Diagrams
What is a class diagram? (5.6)
Conceptual model of the data that needs to be held
Elements of class diagram (5.6)
CALM
- Classes (datagroups)
Things/Events/Places/People & Organisaions - Attributes (information to be held of the classes)
- Logical Associations (between classes)
- 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)
How should multiplicities be read? (5.6)
At the end of the association
What does a class model not consider?
Technology/Processes/Constraints (i.e time)
It is conceptual
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)
What does an association represent in a class model?
A logical/meaningful correspondence between classes
e.g. Customer MAKES booking
Passenger TRAVELS on train
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
Where can use cases diagrams be used?
Throughout the RE process (eliciting, analysing
and validating requirements.)
Use case diagrams within elicitation stage
- Identify use case (functional req)
- help understand how actors (users/other system) interact with the system
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)
Use case diagrams within validation stage
Ensuring stakeholder agreement - a picture paints a thousand words
Refinement of use cases
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.
Purpose of data models
Represents and describes system data requirements.
Grouping of data - class model
Class model represents groupings of data items (attributes)
Classes act as templates for specific types of objects.
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.
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.
Why cross check models?
alignment, exposing omissions or errors & increase quality of overall solution
What tool can be used to cross check models
CRUD Matrix
Potential actions from CRUD matrix
- Missing use cases?
- Are classes required? (no CRUD)
What two elements are in CRUD matrix
Classes & use case
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
What is prototyping?
Modelling tool where a ‘representation system’ is created
Why is prototyping useful?
Elicit/elaborate requirements
Stakeholders can visualise / enhances communication
Drawbacks / consideration factors of prototyping
Can lead to scope creep / cause unrealistic expectations
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
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.?
What do use cases do to classes within CRUD
Manipulate the data
What is acceptance criteria
Tests that the required feature has been delivered correctly
