Brainscape's Knowledge GenomeTM

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


See full index

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

Requirements Definition (K Level 4/5) Flashcards

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
Q

Interviews within Agile Project

A

Iterative interviews aligning with the iterative nature.

Interviews focus on specific user stories

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

Workshops within Linear Project

A

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.

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

Workshops within Agile

A

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)

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

Observation within Linear Project

A

Gather detailed insights into current workflows and identify potential areas for improvement

Uncover tacit knowledge / good understanding of people/process/politics

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

Observation within Agile Project

A

Integrate observation as a constant element throughout the agile development cycle e.g. use as needed to refine requirements

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

Document Analysis within Linear Project

A

Review and analyse source documentation (e.g. forms/reports) to elicit requirements (may be used to compliment other techniques)

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

Document Analysis within Agile Project

A

Relevant documentation analysed iteratively as requirements evolve

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

Surveys and Questionnaires within Linear Project

A

Surveys/Questionnaire designed, distributed and analysed to feed into detailed requirement specification

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

Surveys and Questionnaires within Agile Project

A

Short targeted questionnaires based on current iteration

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

Scenario Analysis within Linear Project

A

Deeper dive into process mapping - tells the story of the task

Pre-conditions/post-conditions

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

Scenario Analysis within Agile Project

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

Iterative development

A

a solution evolves through a series of iterations each of which adds features, functionality or performance
to what has been developed before.

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

Incremental delivery ?

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

Document analysis to elicit data requirements

A

Each identified data item can be expanded to elicit requirements e.g. who needs access to it / retention period (archiving requirement)

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

Scenario Analysis is particularly good for extracting what knowledge type

A

Tacit knowledge

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

Process for developing a scenario

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

Knowledge Types

A

Explicit Knowledge (known knowns & known unknowns)
Tacit Knowledge (unknown unknowns & unknown knowns)

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

Tacit knowledge

A

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

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

How do we move from Tacit to Explicit Knowledge?

A

ORE
Observe (shadowing)
Recount (story telling / scenario analysis)
Enact (prototype/scenario role play)
Report & record
Distribute

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

What is the difference between Storytelling & Scenario Analysis?

A

Storytelling - enterprise level
Scenario Analysis - task level

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

Example of Individual & Corporate Tacit & Explicit Knowledge

A

Individual Tacit: Skills / Intuitiveness
Individual Explicit: Tasks/JD/KPIs (often documented)

Corporate Tacit: Norms/Organisation history
Corporate Explicit: Procedures/Manuals/Processes (often documented)

46
Q

Tacit assumption

A

The information is so self evident, the analyst is aware

47
Q

Explicit knowledge

A

At the foremost in the users mind and can be easily articulated

48
Q

What is the link between knowledge types and elicitation techniques?

A

BA’s should be aware that some techniques e.g. Interviews won’t help uncover tacit knowledge

49
Q

Techniques suitable for Explicit Knowledge

A

Easily articulated/documented information:

Interviews/Workshops/DA (explicit documented information)

50
Q

Techniques suitable for Tacit Knowledge

A

Unarticulated, experiential or internalized knowledge

Observation/shadowing/scenario analysis

51
Q

Separation between Elicitation and Analysis

A

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
Q

Why do requirement conflicts exist

A

Different stakeholder view

53
Q

Tasks in Requirement Analysis

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

A BA should analyse all requirements to ensure they align with….

A
  1. Biz objectives
  2. Biz case
55
Q

Requirements Analysis & Strategic alignment

A

Task: analyse requirements and ensure they align with biz objectives to ensure the project remains strategically aligned

56
Q

If a requirement does not support business objectives what should we do?

A

Challenge if it is required

57
Q

Benefits of req categorisation during the analysis phase

A

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
Q

Benefits of modelling requirements during analysis phase

A

Use case / Class models ensures consistency and completeness

59
Q

Three feasibility elements to consider

A

Technical (not proven / scalable)
Business (could no be a cultural fit)
Financial (requirement is not feasible based on budget)

60
Q

Structure requirements during analysis

A

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
Q

Prioritisation of requirements during analysis

A

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
Q

Must - Moscow

A

Must: mandatory for first increment, cannot meet objectives without it

63
Q

Should - Moscow

A

Should: mandatory but may wait until second increment (short-term value without it)

64
Q

Could - Moscow

A

Could: beneficial if time/funds allow (not central to objectives)

65
Q

Wont - Moscow

A

Wont: will not be met (maybe future)

66
Q

Why is prioritisation during analysis important?

A

ensures that project teams focus on delivering the most valuable and essential elements of the solution

67
Q

Why should a BA ‘check for solutions’ during analysis

A

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
Q

What can happen once requirements have been prioritised?

A

Once validated, req can be packaged for delivery

69
Q

How to deal with conflicting requirements?

A
  1. identify conflict (different stakeholder perspective)
  2. negotiate/facilitation resolution discussion
  3. if no room for compromise, decision passed to higher authority
70
Q

How to deal with overlapping/duplicate requirements?

A
  • Separate overlapping into atomic requirements
  • Remove straight duplication or merge (consulting owner)
71
Q

Quality characteristic of requirements:

A

CCCCURTT
Clear
Concise
Consistent
Correct
Unambiguous
Relevant
Testable
Traceable

72
Q

‘Clear’ requirement (CCCCURTT)

A

Expressed in clear language
Avoids phrases such as ‘and’ ‘until’ - suggest more than one requirement

73
Q

‘Concise’ requirement (CCCCURTT)

A

Expressed in a sentence or using formal standards e.g. user stories

74
Q

‘Consistent’ requirement (CCCCURTT)

A

Consistent format/ does not contradict other requirements

75
Q

‘Correct’ requirement (CCCURTT)

A

Describes something that is actually required to meet objectives

76
Q

Unambiguous requirement (CCCCURTT)

A

Two people should not have a different understanding of how it should be delivered - avoid synonyms and homonyms

77
Q

‘Relevant requirement’ (CCCCURTT)

A

Within project scope

78
Q

‘Testable’ requirement (CCCCURTT)

A

May be tested to confirm the requirement has been met

79
Q

‘Traceable’ requirement (CCCCURTT)

A

To business actors/source of requirement

80
Q

Quality checklist for user stories

A

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
Q

How does ‘slicing’ apply to the RE framework?

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

How does ‘slicing’ apply to requirements?

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

Why is requirements slicing based upon business priorities essential?

A

Essential if required delivery timescales are to be met

84
Q

What can be used in requirements analysis to ensure user-centric solutions

A

User analysis and profiling

85
Q

Benefits of user analysis and profiling in analysis?

A

allows for a deep understanding of user needs, leading to more tailored and user-centric solutions

86
Q

What is user role analysis?

A

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
Q

What is a ‘user’ in user role analysis?

A

homogenous group with a common interest e.g. customer

88
Q

Why is user role analysis useful?

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

How can user role analysis be broken down?

A

Personas

90
Q

What is a persona?

A

more detailed example of a specific user (to explore particular demographics, needs and wants, limitations,
accessibility etc).

91
Q

Why are personas helpful?

A

further validate/support
the need for specific requirements to be met and to help define the workings of the solution.

92
Q

Example of personas and there use in requirements analysis

A

Persona 1: User with a particular disability
Helps explore: accessibility requirements

Persona 2: Hacker/user with malicious intent
Helps explore: security requirements

93
Q

What can be used in conjunction with a persona?

A

Customer Journey Map

94
Q

Customer Journey Map

A

demonstrate the points of contact between a given user and the business/process

95
Q

Why are customer journey maps and personas often used together?

A

to fully explore the needs and behaviours
of specific users, rather than the generic “user”

96
Q

Customer Journey elements

A

Role
Persona
Persona Goal
Stages (e.g. awareness/research/purchase/use)
Touchpoints (interactions between the organisation & customer)
RAG Assessment
Emotional Response
Potential Opportunities

97
Q

Customer Journey & requirements

A

Pain points become opportunities for improvement - requirements for the final solution

98
Q

Rationale for requirements validation

A

Review of the elicited and analysed requirements to ensure they represent the full set of needs of the customer group

99
Q

Aim of requirements validation

A

Agreement that the defined requirements state the features/characteristic the solution will fulfil

100
Q

The validation process differs based on …

A

The lifecycle used - linear vs agile
‘light touch’ to formal sign off

101
Q

Linear - formal validation process

A
  1. Review group formation

(Sponsor/SME/Biz owner/BA/PMO/Developers/Testers/Solution architects/Moderator/Scribe/Chair

  1. Review full BRD documentation
  2. Outcomes: significant rework, amendments needed or confirmation as satisfactory (base lined)
102
Q

Formal review group roles

A

(Sponsor/SME/Biz owner/BA/PMO/Developers/Testers/Solution architects/Moderator/Scribe/Chair

103
Q

Once base lined, subsequent changes need to go through…

A

Formal change and version control

104
Q

Potential concerns and solutions of formal review process

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

What is the sponsor concerned with during requirements review

A

Req align with biz objectives

106
Q

Agile validation is less ___ than linear

A

Formal

107
Q

Agile validation process

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

What is agile validation concerned with?

A

requirements allocated to an iteration are ready for development (in a sufficiently designed state)

109
Q

What is the essence of all validation (linear or agile)

A

ensures that if we deliver the states requirements, we will get what we need out of the solution

110
Q

Why does the backlog need to be validated at the start?

A

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.
© 2024 Bold Learning Solutions. Terms and Conditions