Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

BCS - International Diploma > Requirements Definition (K Level 4/5) > Flashcards

Requirements Definition (K Level 4/5) Flashcards

(110 cards)

Start Studying
1
Q

Requirements definition (4.1)

A

“A feature which business
staff need a system
(business or IT) to provide.

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

Rationale for requirements engineering (4.1)

A

RE Frameowork ensures full elicitation/analysis/validation/documentation & management of requirements

Framework helps improve quality and produces well-defined requirements (unambiguous, well-structures, correct & relevant)

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

How would the RE framework be viewed?

A

Iterative not sequential - it can be flexible

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

Stages of RE Framework

A

Elicitation
Analysis
Validation
Documentation
Management

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

What is the relationship between Elicitation/Analysis/Validation

A

Elicitation - Information about requirements
Analysis - Improves the quality: generates gaps and questions and determines if more elicitation needs to take place. Analysis produces defined requirements
Validation - Are we willing to accept these requirements/benchmark them? Any issues identified during validation pushes them back into analysis

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

Why do Requirements Arise?

A

Business changes (operational/business process change) i.e. growth
Strategic change
New business, products, business rules or regulations
Opportunities for improvement
Competition

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

What should be considered when planning the requirement approach?

A

Requirement work must always be conducted pragmatically & RE framework is intended to be as flexible as the situation demands

Organisational standards (r.e. documentation and modelling)
Project approach
Types of Requirement (i.e. is NFR needed?
Nature of the solution (COTS vs Bespoke)

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

How does requirement approach differ for Linear and Agile projects

A

Linear: complete set of requirements needed before development

Agile: RE approach to establish an initial set of outline requirements. A selected subset elaborated at each iteration

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

How does the requirement approach differ depending on nature of solution

A

Bespoke - detailed requirements

COTS - exhaustive detail not needed due to functionality constraints

What elements of POPIT are in scope e.g. big change to organisational processes/role/management?

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

Key activities in Requirements Elicitation

A

‘Drawing out’ requirements from stakeholders

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

Key activities in Requirements Analysis

A

Improve the quality of requirements
Review and analyse requirements: remove duplication, identity gaps (back to elicitation), negotiate conflict, evaluate feasibility and allocate priority

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

Key activities in Requirements Validation

A

Review requirements - assure they’re at the required level of quality

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

Key activities in Requirements Documentation

A

Producing narrative and diagrammatic definitions of requirements

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

Key activities in Requirements Management

A

Managing changes to the defined requirements & ensuring traceability

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

What is often over looked in a project plan?

A

Elicitation & analysis - this is vital so sufficient time should be allocated

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

How are requirements linked?

A

Requirements do not stand alone - lined via hierarchy

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

The hierarchy of requirements

A

Objectives link to Requirements

Business (G/T) constrain Solution (F/NF) requirements

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

What should all requirements be driven by?

A

An organisations objectives/strategy

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

Business (general/technical) requirements should be elaborated to generate what

A

F/NFR

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

Why is the hierarchy of requirement useful?

A
  1. Can trace original business drivers of requirement
  2. Ensures alignment to objective/strategy
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

General to FR/NFR example

A

General: comply with data protection legislation

FR: Record customer details

NFR: restrict access to customer details

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

What can techniques help with?

A

Requirements Elicitation

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

Technique used to elicit requirements

A

Interviews / Workshops / Observation / DA / SA / Surveys & Questionnaires

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

Interviews within Linear Project

A

Conduct structured interviews with stakeholders to elicit detailed requirements.

Sequentially interview relevant individuals to ensure a comprehensive understanding.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Interviews within Agile Project
Iterative interviews aligning with the iterative nature. Interviews focus on specific user stories
26
Workshops within Linear Project
To agree the direction and scope of a project. To discuss alternative, and sometimes conflicting, perspectives. To elicit and agree business and/or system requirements. To examine possible solutions to the requirements.
27
Workshops within Agile
Provide collaborative environment for cross functional teams Workshops conducted iteratively in line with sprint planning (e.g. to select use stories from the back log)
28
Observation within Linear Project
Gather detailed insights into current workflows and identify potential areas for improvement Uncover tacit knowledge / good understanding of people/process/politics
29
Observation within Agile Project
Integrate observation as a constant element throughout the agile development cycle e.g. use as needed to refine requirements
30
Document Analysis within Linear Project
Review and analyse source documentation (e.g. forms/reports) to elicit requirements (may be used to compliment other techniques)
31
Document Analysis within Agile Project
Relevant documentation analysed iteratively as requirements evolve
32
Surveys and Questionnaires within Linear Project
Surveys/Questionnaire designed, distributed and analysed to feed into detailed requirement specification
33
Surveys and Questionnaires within Agile Project
Short targeted questionnaires based on current iteration
34
Scenario Analysis within Linear Project
Deeper dive into process mapping - tells the story of the task Pre-conditions/post-conditions
35
Scenario Analysis within Agile Project
36
Iterative development
a solution evolves through a series of iterations each of which adds features, functionality or performance to what has been developed before.
37
Incremental delivery ?
38
Document analysis to elicit data requirements
Each identified data item can be expanded to elicit requirements e.g. who needs access to it / retention period (archiving requirement)
39
Scenario Analysis is particularly good for extracting what knowledge type
Tacit knowledge
40
Process for developing a scenario
1. Identify task 2. Identify steps/sequence 3. Define control conditions 4. Identify exception situations and responses e.g. for 'confirm booking' exception condition 'payment declined' response 'advise customer to try another payment method'
41
Knowledge Types
Explicit Knowledge (known knowns & known unknowns) Tacit Knowledge (unknown unknowns & unknown knowns)
42
Tacit knowledge
Information that an individual does not articulate or explain May be due to: failure to recognise the information is required / assumption the information is already known
43
How do we move from Tacit to Explicit Knowledge?
ORE Observe (shadowing) Recount (story telling / scenario analysis) Enact (prototype/scenario role play) Report & record Distribute
44
What is the difference between Storytelling & Scenario Analysis?
Storytelling - enterprise level Scenario Analysis - task level
45
Example of Individual & Corporate Tacit & Explicit Knowledge
Individual Tacit: Skills / Intuitiveness Individual Explicit: Tasks/JD/KPIs (often documented) Corporate Tacit: Norms/Organisation history Corporate Explicit: Procedures/Manuals/Processes (often documented)
46
Tacit assumption
The information is so self evident, the analyst is aware
47
Explicit knowledge
At the foremost in the users mind and can be easily articulated
48
What is the link between knowledge types and elicitation techniques?
BA's should be aware that some techniques e.g. Interviews won't help uncover tacit knowledge
49
Techniques suitable for Explicit Knowledge
Easily articulated/documented information: Interviews/Workshops/DA (explicit documented information)
50
Techniques suitable for Tacit Knowledge
Unarticulated, experiential or internalized knowledge Observation/shadowing/scenario analysis
51
Separation between Elicitation and Analysis
Elicitation: 'drawing out' of requirements using investigation technique (workshops/interviews etc.) Analysis: Looks at the quality, relevance, feasibility and priority of requirements found via elicitation by identifying duplication, overlapping & conflicting requirements
52
Why do requirement conflicts exist
Different stakeholder view
53
Tasks in Requirement Analysis
1. Check each requirement supports biz objectives 2. Categorise req (general/technical/functional/NFR) to help check completeness of requirement sets 3. Modelling requirements (use case/class models) to ensure consistency and completeness 4. Check feasibility 5. Prioritise 6. Package for delivery 7. Deal with overlapping, duplicate and conflicting requirements
54
A BA should analyse all requirements to ensure they align with....
1. Biz objectives 2. Biz case
55
Requirements Analysis & Strategic alignment
Task: analyse requirements and ensure they align with biz objectives to ensure the project remains strategically aligned
56
If a requirement does not support business objectives what should we do?
Challenge if it is required
57
Benefits of req categorisation during the analysis phase
Helps check completeness's of requirement sets E.g. General req: Comply with data protection legislation Do we have all functional requirements needed to deliver this? What about NFR's - links to hierarchy of requirements
58
Benefits of modelling requirements during analysis phase
Use case / Class models ensures consistency and completeness
59
Three feasibility elements to consider
Technical (not proven / scalable) Business (could no be a cultural fit) Financial (requirement is not feasible based on budget)
60
Structure requirements during analysis
For FR: i.e. The receptionist shall be able to view the customer name i.e. User story: as a receptionist, I want to view the customers name, so I can personalise my communication
61
Prioritisation of requirements during analysis
Must: mandatory for first increment, cannot meet objectives without it Should: mandatory but may wait until second increment (short-term value without it) Could: beneficial if time/funds allow (not central to objectives) Wont: will not be met (maybe future)
62
Must - Moscow
Must: mandatory for first increment, cannot meet objectives without it
63
Should - Moscow
Should: mandatory but may wait until second increment (short-term value without it)
64
Could - Moscow
Could: beneficial if time/funds allow (not central to objectives)
65
Wont - Moscow
Wont: will not be met (maybe future)
66
Why is prioritisation during analysis important?
ensures that project teams focus on delivering the most valuable and essential elements of the solution
67
Why should a BA 'check for solutions' during analysis
Ensure requirements state business need rather than pre-defined solutions E.g. requirement: know the time Possible solutions: wrist watch/mobile phone/understand position of the sun
68
What can happen once requirements have been prioritised?
Once validated, req can be packaged for delivery
69
How to deal with conflicting requirements?
1. identify conflict (different stakeholder perspective) 2. negotiate/facilitation resolution discussion 3. if no room for compromise, decision passed to higher authority
70
How to deal with overlapping/duplicate requirements?
- Separate overlapping into atomic requirements - Remove straight duplication or merge (consulting owner)
71
Quality characteristic of requirements:
CCCCURTT Clear Concise Consistent Correct Unambiguous Relevant Testable Traceable
72
'Clear' requirement (CCCCURTT)
Expressed in clear language Avoids phrases such as 'and' 'until' - suggest more than one requirement
73
'Concise' requirement (CCCCURTT)
Expressed in a sentence or using formal standards e.g. user stories
74
'Consistent' requirement (CCCCURTT)
Consistent format/ does not contradict other requirements
75
'Correct' requirement (CCCURTT)
Describes something that is actually required to meet objectives
76
Unambiguous requirement (CCCCURTT)
Two people should not have a different understanding of how it should be delivered - avoid synonyms and homonyms
77
'Relevant requirement' (CCCCURTT)
Within project scope
78
'Testable' requirement (CCCCURTT)
May be tested to confirm the requirement has been met
79
'Traceable' requirement (CCCCURTT)
To business actors/source of requirement
80
Quality checklist for user stories
INVEST Independent: discrete/atomic Negotiable: brief description that forms basis for elaboration/collaboration Valuable: offer value to customer Estimatable: estimate effort required for implementation Small: to be completed within single iteration Testable: inclusion of specific measures to evaluate if it's been met
81
How does 'slicing' apply to the RE framework?
- not sensible to complete elicitation before analysis - ongoing iterative process - high priority requirements should be analysed first so they're 'ready' for development (for incremental delivery) whilst elicitation ongoing
82
How does 'slicing' apply to requirements?
- Req may have multiple scenarios & likely the scenarios that different levels of priority - Highest priority given to happy path for immediate development - alternate paths: deferred to a later release (or removed completely and dealt with manual intervention)
83
Why is requirements slicing based upon business priorities essential?
Essential if required delivery timescales are to be met
84
What can be used in requirements analysis to ensure user-centric solutions
User analysis and profiling
85
Benefits of user analysis and profiling in analysis?
allows for a deep understanding of user needs, leading to more tailored and user-centric solutions
86
What is user role analysis?
Developing an understanding of how a user (homogenous group with a common interest) engage with a business area or system - helps to understand what req they have
87
What is a 'user' in user role analysis?
homogenous group with a common interest e.g. customer
88
Why is user role analysis useful?
- a means of identifying where stakeholders have common interests or requirements; - a more efficient approach to eliciting and analysing requirements; - a strong basis for analysing scenarios, stakeholder perspectives (see Chapter 6), use cases and user stories
89
How can user role analysis be broken down?
Personas
90
What is a persona?
more detailed example of a specific user (to explore particular demographics, needs and wants, limitations, accessibility etc).
91
Why are personas helpful?
further validate/support the need for specific requirements to be met and to help define the workings of the solution.
92
Example of personas and there use in requirements analysis
Persona 1: User with a particular disability Helps explore: accessibility requirements Persona 2: Hacker/user with malicious intent Helps explore: security requirements
93
What can be used in conjunction with a persona?
Customer Journey Map
94
Customer Journey Map
demonstrate the points of contact between a given user and the business/process
95
Why are customer journey maps and personas often used together?
to fully explore the needs and behaviours of specific users, rather than the generic “user”
96
Customer Journey elements
Role Persona Persona Goal Stages (e.g. awareness/research/purchase/use) Touchpoints (interactions between the organisation & customer) RAG Assessment Emotional Response Potential Opportunities
97
Customer Journey & requirements
Pain points become opportunities for improvement - requirements for the final solution
98
Rationale for requirements validation
Review of the elicited and analysed requirements to ensure they represent the full set of needs of the customer group
99
Aim of requirements validation
Agreement that the defined requirements state the features/characteristic the solution will fulfil
100
The validation process differs based on ...
The lifecycle used - linear vs agile 'light touch' to formal sign off
101
Linear - formal validation process
1. Review group formation (Sponsor/SME/Biz owner/BA/PMO/Developers/Testers/Solution architects/Moderator/Scribe/Chair 2. Review full BRD documentation 3. Outcomes: significant rework, amendments needed or confirmation as satisfactory (base lined)
102
Formal review group roles
(Sponsor/SME/Biz owner/BA/PMO/Developers/Testers/Solution architects/Moderator/Scribe/Chair
103
Once base lined, subsequent changes need to go through...
Formal change and version control
104
Potential concerns and solutions of formal review process
1. stakeholders too busy - BA/PM should emphasise the risks with incorrect requirement. Informal 1-1 meetings can be held (not ideal) 2. BRD too large - section by section review where only relevant stakeholders invited
105
What is the sponsor concerned with during requirements review
Req align with biz objectives
106
Agile validation is less ___ than linear
Formal
107
Agile validation process
1. a straightforward outline of a requirement may be accepted as “valid" 2. Backlog maintained - refined until 'ready' for development . Informal review of user stories may occur Main concern is that the requirements allocated to an iteration and 'ready'
108
What is agile validation concerned with?
requirements allocated to an iteration are ready for development (in a sufficiently designed state)
109
What is the essence of all validation (linear or agile)
ensures that if we deliver the states requirements, we will get what we need out of the solution
110
Why does the backlog need to be validated at the start?
To ensure the backlog is sufficiently formed - further validation is required

BCS - International Diploma (7 decks)

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