Chapter 10: Establishing the Requirements (10%) Flashcards
typical problems with requirements
- Lack of relevance to the project objectives
- Lack of clarity in the wording
- Ambiguity
- Duplication and conflict between requirements
- Poorly expressed requirements
- Requirements that assume a solution (rather than stating what is needed from the solution)
- Uncertainty from the users about what they expect
- Users omit requirements
- Varying and inconsistent requirements
- users and analysts taking knowledge for granted
how can we address the problem of :
Lack of relevance to the project objectives
OSCAR
Objectives
Scope
Constraints
Authority
Resources
- don’t assume knowledge
- recognise different stakeholder viewpoints
core activities in the Requirements Engineering framework
Requirements elicitation
Requirements analysis
Requirements validation
Requirements documentation
Requirements management
Requirements Elicitation is concerned with
gathering requirements from stakeholders
Requirements Analysis is concerned with
review/analyse requirements to:
- remove duplication/error
- negotiate conflicts and contradictions
- evaluate feasibility
- allocate priorities
Requirements Validation is concerned with
stakeholders review requirements (to assure they’re defined at required level of quality)
Requirements Documentation is concerned with
producing narrative + diagrammatic definitions of requirements (at varying levels of accuracy + completion)
Requirements Management is concerned with
managing changes to defined requirements + ensuring desired level of traceability is achieved
2 main groups of actors in RE:
business representatives
project team
roles in business representatives group
project sponsor
product owner
SME
business staff (people who apply the new business processes + use new IT system)
what responsibilities does project sponsor have
- agree PID (project initiation document)
- make funds + resources available
- resolve conflicting requirements
- sign off requirements document
- accept deliverables at project end
- deliver the benefits
- confirm benefits have been realised
product owners responsibilities:
- manage product backlog (ensure priorities have been identified + align with business needs)
- identify backlog items to be developed in each product development iteration
- make decisions on behalf of organisation regarding product development + resolve requirement conflicts
- ensure product development stays on track
SME responsibility is to give business advice regarding requirements, particularly when the organisation wishes to…
- adopt latest industry best practise/innovations
- introduce a new product/process that isn’t fully understood
Business staff responsibilities
articulate both
- functional requirements
- non-functional requirements
actors in project team
project manager
business analyst
developers
software testers
project manager responsibilities
- planning project
- allocating work
- monitoring progress
- taking corrective action
BA responsibilities
- carrying out RE work (ensure requirements are defined, in line with project approach/standards, provide basis to solution)
- work closely with business staff (elicitation, analysis, documentation of requirements)
developer responsibilities
(creates the software product in line with business requirements)
- check technical feasibility of requirements
- help analyst understand implication of requirements
- produce prototypes
- help business users visualise what they’ve requested
tester responsibilities
- tyring to prove the system does not work + identify where this is the case
- review requirements to ensure they’re feasible
- ensure acceptance criteria properly defined
categories within General requirements (business)
- business constraints (budget, timescale, resources)
- business policies
- business continuity (ability to recover from incidents that hinder continued operation)
- legal
- branding
- cultural
- language
categories within Technical requirements (business)
hardware
software
interface
internet (technical policies governing the use of internet/ web-enabled services)
categories within Functional requirements (solution)
data entry (+ processing, reporting)
data maintenance
procedural
retrieval requirements
categories within Non-functional requirements (solution)
performance (speed)
security + access
backup + recovery
archiving + retention
robustness
availability
usability
accessibility
capacity + scalability (volumes of data to be stored/ transactions to be processed/ no. stakeholders to be supported)
(increase scale of coverage of solution to accommodate more transactions/ stakeholders)
(think ‘ilities’)
most effective requirement elicitation techniques in a workshop
- visulations
- modelling
CSF analysis
scenario analysis
prototyping
other requirement elicitation techniques
interviews
document analysis
approaches for uncovering tacit knowledge and key techniques used:
Observe: observation, shadowing
Recount: storytelling, scenario analysis
Enact: prototyping, scenario role-play
4 tasks included in requirements analysis:
- categorising requirements
- modelling requirements (using Class models or Use case diagrams)
- prioritising requirements (can use RAG or MoSCoW)
- Defining requirements (can apply filters)
are these individual level of knowledge tacit or explicit?
task definitions, job descriptions, targets, volumes, frequencies
explicit
are these individual level of knowledge tacit or explicit?
skills, values, taken-for-granted knowledge, intuitiveness
tacit
are these corporate level of knowledge tacit or explicit?
norms, culture, networks, organisation history, back story
tacit
are these corporate level of knowledge tacit or explicit?
procedures, style guides, processes, knowledge sharing repositories, manuals, company reports
explicit
define MoSCoW
Must have (mandatory, solution not acceptable w/o)
Should have (mandatory, but may be deferred to 2nd increment)
Could have (desirable but solution acceptable w/o)
Want to have (but won’t have this time)
requirement filters are used to examine elicited requirements and produce well-formed set.
what are the key analysis filters?
- unravel multiple requirements
- check for overlapping/duplicates
- confirm relevance
- evaluate feasibility (technical, business + financial)
- remove conflicts
- check for solutions
- confirm quality (clear, concise, consistent, relevant, unambiguous, correct, testable, traceable)
what does INVEST stand for
each user story/backlog item should be:
Independent
Negotiable
Valuable (to users/ customers)
Estimatable
Small (suitable size for iteration planning)
Testable (have specific measure to evaluate if it’s been achieved)
what is INVEST used for
provides quality check to evaluate + improve user stories
2 categories of business rules to consider + their sub-categories
what techniques are helpful to elicit and document the rules?
Constraints
- Action governance (use narrative statements)
- Data constraints (use data models + definitions, CRUD matrices)
Operational guidance
- decision conditions (activity diagrams, BPM, decision tables, tables, matrices)
- calculations (arithmetical formulae, structured English, pseudocode)
