Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

BCS - International Diploma > Requirements Management and Documentation (K Level 4/5) > Flashcards

Requirements Management and Documentation (K Level 4/5) Flashcards

1
Q

Rationale for requirements management (5.1)

A

Managing changes to the defined/baselines requirements & ensuring the desired level of traceability is achieved

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Elements of requirements management
ii. Source of requirement (5.1)

A

The person/document that raised the requirement

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Elements of requirements management
v. Change Control (5.1)

A

Defining and implementing a process to manage change (DACDIR)

  1. Document: document change request
  2. Analyse: alignment to biz objectives? impact on other requirements? timeframe? budget?
  3. Consult: with relevant stakeholders (owner of original requirement
  4. Decide
  5. Implement/reject: version control
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Traceability
1. Vertical Traceability Hierarchy (5.1)

A

Business Strategy/Objectives

Business requirements

Solution requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Traceability
1. Vertical Traceability (5.1)

A
  • Tracing a requirement up or down the hierarchy
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Traceability
1. Horizontal Traceability - Why is this useful? (5.1)

A

Backwards from: when clarifications are needed/requirements are in conflict

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Version Control
- Configuration management process
(5.3)

A
  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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Version Control
- Version Numbering
Why is this useful (5.3)

A

Any movements are clearly recorded and version numbers used for comparison & to ensure all parties are working with the correct version

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Version Control
What is CI?

A

Configurable items = the deliverables to be bought under configuration (individual requirements/BRD/Models)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

Tools in requirements management (5.4)

A

a. Functionality provided by tools:
i. Storage of documentation
and models.
ii. Linkage and cross-referencing.
iii. Change and version
control.
iv. Access restrictions.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

Version Control
- Levels of configuration items (individual req/document)

A

CI include: individual requirement, sets of requirement (BRD) & associated models

Version numbers apply to each individual CI item

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

Requirement management
Storage of documentation & models (Explain & Justify) (5.4)

A

Requirement management tools can store and organise documentation (BRD/Models etc.)

Offer a central repository for easy access/retrieval of these documents

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

Requirement management
Linkage and cross-referencing (Explain & Justify) (5.4)

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

Requirement management
Change and version control (Explain & Justify) (5.4)

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

Requirement management
Access restrictions (Explain & Justify) (5.4)

A

Ensures only authorised individuals can view/edit requirements. Important for data integrity & security

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

Requirement management

Storage of documentation & models
- Relationship to other requirement management tools (5.4)

A
  • 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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

Requirement management

Linkage & cross referencing
- Relationship to other requirement management tools (5.4)

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q

Requirement management

Change & version control
- Relationship to other requirement management tools (5.4)

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
36
Q

Requirement management

Access restrictions
- Relationship to other requirement management tools (5.4)

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
37
Q

Legal issues and business analysis

Examples of legal issues relevant to business analysis (5.6)

A

Data protection

Disability access

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
38
Q

Data protection: rationale, principles and impact on requirements. (5.6)

A

DP = crucial for safeguarding individual privacy & ensuring the ethical & legal handling of personal information

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
39
Q

Data protection: impact on requirements. (5.6)

A

BAs must consider DP regulations e.g. GDPR when eliciting/specifying requirements & ensure systems handle personal data ethically and securely

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
40
Q

Disability Access: Rationale, Principles, and Impact on Requirements (5.6)

A

Imperative to create inclusive & accessible solutions (ensure organisation aligns with social responsibility and legal requirements promoting equal opportunities)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
41
Q

Disability Access: Impact on Requirements (5.6)

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
42
Q

What tools can help BA identify legal issues? (5.6)

A

PESTLE

  • Used as part of analysis but ongoing
  • Follow change control process if new regulation/law comes in
  • Explored via personas for specific req
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
43
Q

Requirement Categories (5.5)

A

Business & Solution

Business (General & Technical)
Solution (Functional & NFR)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
44
Q

Business requirement sub categories (5.5)

A

General
Technical

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
45
Q

Solution requirement sub categories (5.5)

A

Functional
Non- functional

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
46
Q

What requirements are associated with enterprise level? (5.5)

A

Business requirements (General & Technical)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
47
Q

What requirements are associated with product/service level ? (5.5)

A

Solution (Functional & NFR)
They tell us what we need the system to do

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
48
Q

What sits above all requirements? (5.5)

A

The business objectives (all requirements should vertically align to biz objectives)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
49
Q

6 types of General (business) Requirement? (5.5)

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
50
Q

4 types of Technical (business) Requirement? (5.5)

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
51
Q

5 types of Functional (solution) Requirement? (5.5)

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
52
Q

Relationship between requirement categories (5.5)

A

NFR’s (generally) constrain FR

Business requirements constrain functional requirements

All requirements should vertically align to business objectives

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
53
Q

Relationship between NFR’s and FR? (5.5)

A

NFR’s (generally) constrain FR

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
54
Q

Relationship between business and solution requirements? (5.5)

A

Business requirements constrain functional requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
55
Q

What are functional requirements (5.5)

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
56
Q

What can be used to summarise functional requirements (5.5)

A

CRUD

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
57
Q

Functional requirement examples (5.5)

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
58
Q

What are non-functional requirements (5.5)

A

Define HOW WELL the functional requirements will be provided

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
59
Q

10 Types of NFR (5.5)

A

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
Q

NFR Example (5.5)

A

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
Q

How can functional requirements be delivered (5.5)

A
  • By the software product
  • By process changes or task enhancements
  • removal (if too costly/time consuming)
62
Q

In what event would functional requirements be not delivered by the software product (5.5)

A

If too costly or time consuming to be included in the software product.

Removal may also be considered

63
Q

General requirement (5.5)

A

Documents high-level business constraints and policies.

64
Q

Technical requirement (5.5)

A

Documents high-level technical constraints and policies.

65
Q

General requirement example (5.5)

A

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
Q

Example technical requirement (5.5)

A

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
Q

Two types of documentation styles (5.7)

A

Text based (requirement catalogue/user story)
Diagrammatic (data model/use case diagram / business process model)

68
Q

Example of text based documentation? (5.7)

A

Text based (requirement catalogue/user story)

69
Q

Example of diagrammatic documentation? (5.7)

A

Diagrammatic (data model/use case diagram / business process model)

70
Q

Elements of requirement catalogue (5.7)

A

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
Q

Elements of requirement catalogue (5.7)

Purpose of identifier

A

Each requirement should have a unique identifier – ensures correct requirements are developed and discussed

72
Q

Elements of requirement catalogue (5.7)

Purpose of Name

A

Context/hints at content of requirement - beyond that of the unique identifier

73
Q

Elements of requirement catalogue (5.7)

Purpose of description

A

Describes the feature the new system (biz/IT) needs to address

74
Q

Elements of requirement catalogue (5.7)

Purpose of business area

A

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
Q

Elements of requirement catalogue (5.7)

Purpose of type of requirement

A

Helps check completeness’s of requirement sets

76
Q

Elements of requirement catalogue (5.7)

Purpose of author

A

Author: Identifies the analyst responsible for eliciting and documenting the requirement.

76
Q
A
77
Q

Elements of requirement catalogue (5.7)

Purpose of source

A

Specifies the originating person or information source for the requirement, offering insights into its origin.

78
Q

Elements of requirement catalogue (5.7)

Purpose of owner

A

Designates the business stakeholder with decision-making authority for the requirement.

79
Q

Elements of requirement catalogue (5.7)

Purpose of priority

A

Indicates the level of priority for the requirement, guiding the focus on critical aspects during development.

Moscow

80
Q

Elements of requirement catalogue (5.7)

Purpose of rationale/justification

A

Offers the business justification for the requirement, often cross-referenced to specific benefits in the business case.

81
Q

Elements of requirement catalogue (5.7)

Purpose of cross-referenced requirements

A

Identifies related requirements, providing a comprehensive view of dependencies and connections.

82
Q

Elements of requirement catalogue (5.7)

Purpose of cross-referenced documents

A

Specifies documents linked to the requirement, enhancing contextual understanding.

83
Q

Elements of requirement catalogue (5.7)

Purpose of Acceptance criteria

A

Outlines the criteria for formal agreement that the requirement has been successfully delivered.

84
Q

Elements of requirement catalogue (5.7)

Purpose of status/resolution

A

Records the outcome of the requirement, whether implemented, deferred, merged, or dropped.

85
Q

Elements of requirement catalogue (5.7)

Purpose of version number/date

A

Captures the history of the requirement, including version numbers and dates, ensuring traceability and change control.

86
Q

What does documentation approach depend on (5.7)

A

Project approach

87
Q

Documentation approach - Linear (5.7)

A
  • Requirements documented before development
  • reviewed/agreed by business and maintained as changes occur
88
Q

Documentation approach - Agile (5.7)

A
  • Documentation produced where necessary (often user stories)
  • Requirements defined in outline in early stages with detail emerging during product development
89
Q

Documentation commonly used in Linear projects (5.6)

A

Requirement catalogue

90
Q

Documentation commonly used in agile projects (5.6)

A

User stories (may be supplemented by models)

91
Q

Documentation detail depends on… - examples? (5.6)

A

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
Q

What is a user story (5.6)

A

Brief, informal description which provides basis for further conversation

93
Q

What is a user story the basis for (5.6)

A

Further conversation

94
Q

3C’s framework for user stories (5.6)

A

Card (format - ensures conciseness)
Conversation (placeholder for further discussion)
Confirmation (AC)

95
Q

Format of user story (5.6)

A

“As a {user role}, I want {feature} so that I can {reason}.”

96
Q

Why is documentation crucial in requirements engineering? (5.6)

A
  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
Q

How often should documentation be revisited or referred to in the requirements engineering process? (5.6)

A

Documentation should be revisited/referred to at each stage of the process, as illustrated by the requirements engineering framework.

98
Q

What factors influence the variation in documentation during requirements engineering?

A

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
Q

Documentation style of general requirement vs functional requirement

A

General: Narrative
- source /owner important

Functional: use case models or user stories

100
Q

Documentation and continuous improvement (5.6)

A

approach to documentation should be iterative and open to improvement

101
Q

What do requirements documentation and modelling ensure?

A

These techniques ensure that standardised, accurate and complete
documentation is produced and maintained for both individual
requirements and the entire requirements set

102
Q

Rationale for modelling requirements (5.7)

A
  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
Q

Why are conceptual models useful? (5.7)

A

Represent high-level abstractions of a system.
They help in understanding the system’s structure and behavior.

104
Q

Purpose of use case model (5.7)

A

Describe a piece of system functionality that delivers value to the actor
focuses on the ‘what’ not the ‘how’

105
Q

Purpose of data models (5.7)

A

Data models represent the structure and relationships within a database.

106
Q

What sort of model is a use cade model (5.7)

A

Functional model

107
Q

What does a full use case model contain (5.7)

A

Use case diagram
use case description

108
Q

How can use cases be fulfilled (5.7)

A

Software product
Manual business process

109
Q

What naming convention is applied to use cases? (5.7)

A

Verb noun i.e. make payment / cancel ticket

110
Q

Why are use cases useful? (5.7)

A

Use Case Diagrams summarise functional requirements for the IT/Business system. They represent the user perspective and needs

111
Q

What are the levels in a use case diagram? (5.7)

A

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
Q

Examples of actors in a use case model (5.7)

A

Human i.e user
Non-human i.e. another system/time

113
Q

2 relationship types of use cases (5.7)

A

«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
Q

What can be used to support a use case diagram? (5.7)

A

Use case description

115
Q
A

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
Q

What can a use case description be supported by? (5.6)

A

A process flow diagram (rather than step by step)

117
Q

What does a use case not capture/consider? (5.6)

A

Information needed / data

118
Q

Examples of data models (5.6)

A

(Entity) Relationship Diagram (ERD) & Class Diagrams

119
Q

What is a class diagram? (5.6)

A

Conceptual model of the data that needs to be held

120
Q

Elements of class diagram (5.6)

A

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
Q

How should multiplicities be read? (5.6)

A

At the end of the association

122
Q

What does a class model not consider?

A

Technology/Processes/Constraints (i.e time)

It is conceptual

123
Q

How is a class represented in a class model?

A

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
Q

What does an association represent in a class model?

A

A logical/meaningful correspondence between classes

e.g. Customer MAKES booking
Passenger TRAVELS on train

125
Q

Business rules and use case diagrams

A

Access restrictions: e.g. only managers can approve expenses (constraint)

Operational guidance: e.g. steps to define how commission is calculated

126
Q

Where can use cases diagrams be used?

A

Throughout the RE process (eliciting, analysing
and validating requirements.)

127
Q

Use case diagrams within elicitation stage

A
  • Identify use case (functional req)
  • help understand how actors (users/other system) interact with the system
128
Q

Use case diagrams within analysis stage

A

System boundary helps identify dependencies/ interactions beyond the system

Identify gaps to be explored further (maybe back to elicitation)

129
Q

Use case diagrams within validation stage

A

Ensuring stakeholder agreement - a picture paints a thousand words

Refinement of use cases

130
Q

Object vs class - class model

A

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
Q

Purpose of data models

A

Represents and describes system data requirements.

132
Q

Grouping of data - class model

A

Class model represents groupings of data items (attributes)

Classes act as templates for specific types of objects.

133
Q

Relationships between groupings - class model

A

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
Q

Optionality - Class model

A

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
Q

Why cross check models?

A

alignment, exposing omissions or errors & increase quality of overall solution

136
Q

What tool can be used to cross check models

A

CRUD Matrix

137
Q

Potential actions from CRUD matrix

A
  • Missing use cases?
  • Are classes required? (no CRUD)
138
Q

What two elements are in CRUD matrix

A

Classes & use case

139
Q

Data models and business rules

A

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
Q

What is prototyping?

A

Modelling tool where a ‘representation system’ is created

141
Q

Why is prototyping useful?

A

Elicit/elaborate requirements

Stakeholders can visualise / enhances communication

142
Q

Drawbacks / consideration factors of prototyping

A

Can lead to scope creep / cause unrealistic expectations

143
Q

Advantages/disadvantages of agile documentation approach

A

+
reduces the maintenance overhead of managing a detailed requirements document while the solution is being developed

-

could lead to inconsistencies and scope creep

144
Q

Errors and omissions identified from CRUD

A

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
Q

What do use cases do to classes within CRUD

A

Manipulate the data

146
Q

What is acceptance criteria

A

Tests that the required feature has been delivered correctly

BCS - International Diploma (7 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions