Requirements Definition (K Level 4/5) Flashcards
Requirements definition (4.1)
“A feature which business
staff need a system
(business or IT) to provide.
Rationale for requirements engineering (4.1)
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 would the RE framework be viewed?
Iterative not sequential - it can be flexible
Stages of RE Framework
Elicitation
Analysis
Validation
Documentation
Management
What is the relationship between Elicitation/Analysis/Validation
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
Why do Requirements Arise?
Business changes (operational/business process change) i.e. growth
Strategic change
New business, products, business rules or regulations
Opportunities for improvement
Competition
What should be considered when planning the requirement approach?
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 does requirement approach differ for Linear and Agile projects
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 does the requirement approach differ depending on nature of solution
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?
Key activities in Requirements Elicitation
‘Drawing out’ requirements from stakeholders
Key activities in Requirements Analysis
Improve the quality of requirements
Review and analyse requirements: remove duplication, identity gaps (back to elicitation), negotiate conflict, evaluate feasibility and allocate priority
Key activities in Requirements Validation
Review requirements - assure they’re at the required level of quality
Key activities in Requirements Documentation
Producing narrative and diagrammatic definitions of requirements
Key activities in Requirements Management
Managing changes to the defined requirements & ensuring traceability
What is often over looked in a project plan?
Elicitation & analysis - this is vital so sufficient time should be allocated
How are requirements linked?
Requirements do not stand alone - lined via hierarchy
The hierarchy of requirements
Objectives link to Requirements
Business (G/T) constrain Solution (F/NF) requirements
What should all requirements be driven by?
An organisations objectives/strategy
Business (general/technical) requirements should be elaborated to generate what
F/NFR
Why is the hierarchy of requirement useful?
- Can trace original business drivers of requirement
- Ensures alignment to objective/strategy
General to FR/NFR example
General: comply with data protection legislation
FR: Record customer details
NFR: restrict access to customer details
What can techniques help with?
Requirements Elicitation
Technique used to elicit requirements
Interviews / Workshops / Observation / DA / SA / Surveys & Questionnaires
Interviews within Linear Project
Conduct structured interviews with stakeholders to elicit detailed requirements.
Sequentially interview relevant individuals to ensure a comprehensive understanding.
Interviews within Agile Project
Iterative interviews aligning with the iterative nature.
Interviews focus on specific user stories
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.
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)
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
Observation within Agile Project
Integrate observation as a constant element throughout the agile development cycle e.g. use as needed to refine requirements
Document Analysis within Linear Project
Review and analyse source documentation (e.g. forms/reports) to elicit requirements (may be used to compliment other techniques)
Document Analysis within Agile Project
Relevant documentation analysed iteratively as requirements evolve
Surveys and Questionnaires within Linear Project
Surveys/Questionnaire designed, distributed and analysed to feed into detailed requirement specification
Surveys and Questionnaires within Agile Project
Short targeted questionnaires based on current iteration
Scenario Analysis within Linear Project
Deeper dive into process mapping - tells the story of the task
Pre-conditions/post-conditions
Scenario Analysis within Agile Project
Iterative development
a solution evolves through a series of iterations each of which adds features, functionality or performance
to what has been developed before.
Incremental delivery ?
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)
Scenario Analysis is particularly good for extracting what knowledge type
Tacit knowledge
Process for developing a scenario
- Identify task
- Identify steps/sequence
- Define control conditions
- Identify exception situations and responses e.g. for ‘confirm booking’ exception condition ‘payment declined’ response ‘advise customer to try another payment method’
Knowledge Types
Explicit Knowledge (known knowns & known unknowns)
Tacit Knowledge (unknown unknowns & unknown knowns)
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
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
What is the difference between Storytelling & Scenario Analysis?
Storytelling - enterprise level
Scenario Analysis - task level
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)
Tacit assumption
The information is so self evident, the analyst is aware
Explicit knowledge
At the foremost in the users mind and can be easily articulated
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
Techniques suitable for Explicit Knowledge
Easily articulated/documented information:
Interviews/Workshops/DA (explicit documented information)
Techniques suitable for Tacit Knowledge
Unarticulated, experiential or internalized knowledge
Observation/shadowing/scenario analysis
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
Why do requirement conflicts exist
Different stakeholder view
Tasks in Requirement Analysis
- Check each requirement supports biz objectives
- Categorise req (general/technical/functional/NFR) to help check completeness of requirement sets
- Modelling requirements (use case/class models) to ensure consistency and completeness
- Check feasibility
- Prioritise
- Package for delivery
- Deal with overlapping, duplicate and conflicting requirements
A BA should analyse all requirements to ensure they align with….
- Biz objectives
- Biz case
Requirements Analysis & Strategic alignment
Task: analyse requirements and ensure they align with biz objectives to ensure the project remains strategically aligned
If a requirement does not support business objectives what should we do?
Challenge if it is required
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
Benefits of modelling requirements during analysis phase
Use case / Class models ensures consistency and completeness
Three feasibility elements to consider
Technical (not proven / scalable)
Business (could no be a cultural fit)
Financial (requirement is not feasible based on budget)
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
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)
Must - Moscow
Must: mandatory for first increment, cannot meet objectives without it
Should - Moscow
Should: mandatory but may wait until second increment (short-term value without it)
Could - Moscow
Could: beneficial if time/funds allow (not central to objectives)
Wont - Moscow
Wont: will not be met (maybe future)
Why is prioritisation during analysis important?
ensures that project teams focus on delivering the most valuable and essential elements of the solution
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
What can happen once requirements have been prioritised?
Once validated, req can be packaged for delivery
How to deal with conflicting requirements?
- identify conflict (different stakeholder perspective)
- negotiate/facilitation resolution discussion
- if no room for compromise, decision passed to higher authority
How to deal with overlapping/duplicate requirements?
- Separate overlapping into atomic requirements
- Remove straight duplication or merge (consulting owner)
Quality characteristic of requirements:
CCCCURTT
Clear
Concise
Consistent
Correct
Unambiguous
Relevant
Testable
Traceable
‘Clear’ requirement (CCCCURTT)
Expressed in clear language
Avoids phrases such as ‘and’ ‘until’ - suggest more than one requirement
‘Concise’ requirement (CCCCURTT)
Expressed in a sentence or using formal standards e.g. user stories
‘Consistent’ requirement (CCCCURTT)
Consistent format/ does not contradict other requirements
‘Correct’ requirement (CCCURTT)
Describes something that is actually required to meet objectives
Unambiguous requirement (CCCCURTT)
Two people should not have a different understanding of how it should be delivered - avoid synonyms and homonyms
‘Relevant requirement’ (CCCCURTT)
Within project scope
‘Testable’ requirement (CCCCURTT)
May be tested to confirm the requirement has been met
‘Traceable’ requirement (CCCCURTT)
To business actors/source of requirement
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
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
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)
Why is requirements slicing based upon business priorities essential?
Essential if required delivery timescales are to be met
What can be used in requirements analysis to ensure user-centric solutions
User analysis and profiling
Benefits of user analysis and profiling in analysis?
allows for a deep understanding of user needs, leading to more tailored and user-centric solutions
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
What is a ‘user’ in user role analysis?
homogenous group with a common interest e.g. customer
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
How can user role analysis be broken down?
Personas
What is a persona?
more detailed example of a specific user (to explore particular demographics, needs and wants, limitations,
accessibility etc).
Why are personas helpful?
further validate/support
the need for specific requirements to be met and to help define the workings of the solution.
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
What can be used in conjunction with a persona?
Customer Journey Map
Customer Journey Map
demonstrate the points of contact between a given user and the business/process
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”
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
Customer Journey & requirements
Pain points become opportunities for improvement - requirements for the final solution
Rationale for requirements validation
Review of the elicited and analysed requirements to ensure they represent the full set of needs of the customer group
Aim of requirements validation
Agreement that the defined requirements state the features/characteristic the solution will fulfil
The validation process differs based on …
The lifecycle used - linear vs agile
‘light touch’ to formal sign off
Linear - formal validation process
- Review group formation
(Sponsor/SME/Biz owner/BA/PMO/Developers/Testers/Solution architects/Moderator/Scribe/Chair
- Review full BRD documentation
- Outcomes: significant rework, amendments needed or confirmation as satisfactory (base lined)
Formal review group roles
(Sponsor/SME/Biz owner/BA/PMO/Developers/Testers/Solution architects/Moderator/Scribe/Chair
Once base lined, subsequent changes need to go through…
Formal change and version control
Potential concerns and solutions of formal review process
- stakeholders too busy - BA/PM should emphasise the risks with incorrect requirement. Informal 1-1 meetings can be held (not ideal)
- BRD too large - section by section review where only relevant stakeholders invited
What is the sponsor concerned with during requirements review
Req align with biz objectives
Agile validation is less ___ than linear
Formal
Agile validation process
- a straightforward outline of a
requirement may be accepted as “valid” - 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’
What is agile validation concerned with?
requirements allocated to an iteration are ready for development (in a sufficiently designed state)
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
Why does the backlog need to be validated at the start?
To ensure the backlog is sufficiently formed - further validation is required
