Topic 9: Requirements Definition and Prioritisation Agile Development Topic 9: Requirements Definition and Prioritisation NCC Education - Title Master

Topic 9 Coverage This topic will cover: What is a requirement? Defining the requirements Requirements in the Atern lifecycle Requirements and modelling The Requirement Lifecycle

What is a Requirement? Group Exercise DSDM ATERN Approach and Principles What is a Requirement? Group Exercise List as many words or phrases as you can that mean “requirement”. ATERN S1 Approach 3

What is a Requirement? In simple terms, a requirement is a: feature function service constraint that the solution needs to perform or exhibit.

Defining the Requirements DSDM ATERN Requirements Definition and Prioritisation Defining the Requirements Define a requirement along with its Acceptance Criteria as measurable targets at all levels. Give it a unique ID Keep details of: source owner business benefit priority other? Consider: As a …I need … in order to … ATERN S5reqdef 5

Functional Requirements Functional requirement is “what”, not “how”. Make it SMART Specific Measurable Achievable Realistic Timely Wording - functional requirement: “We need the ability to …” “As a … I need … in order to …” Not in conflict with, or overlapping, other requirements.

Non-Functional Requirements Non-functional requirements are about “how well” we do the functional requirements, i.e. with what: security availability portability maintainability external interfaces design constraints performance response time etc. (see notes) May be global or related to just one functional requirement. May need extra time in the plan!

Structure of Requirements Requirement Decomposition Feasibility: A very high level set of requirements is established Foundations: A high level set of prioritised requirements is established (a PRL) User stories Exploration and Engineering: Each requirement may decompose into more detailed requirements At some point, it may not need to be written down, but evolved as part of iterative development (prototyping)

Requirements and Modelling Handle Reservations M R1.1 Make a reservation M R1.2 Make a conference booking W Amend a reservation S Make an individual booking R1.1.1 M R1.1.2 Cancel a reservation M R1.1.3 Produce occupancy report C

Requirements in the Atern Lifecycle DSDM ATERN Prototyping, Timeboxing and Estimating Requirements in the Atern Lifecycle Less Less Outline Plan Delivery Plan Timebox Plan(s) Typically <10 requirements Typically <100 requirements Do not go into requirements detail too early Requirement Detail Estimate Accuracy Do not be held hostage to early estimates Typically >100 requirements More More ATERN S7 Prototyping TimeboxandEst 10

What is MoSCoW? W C Must haves: S Should haves: M fundamental to system without them, system unworkable/useless minimum usable subset guaranteed to be developed Should haves: important requirements would be mandatory, but workaround exists system will still be useful/usable without them

What is MoSCoW? Could haves: Won't have this times: W would add business benefit more easily left out of this increment than Should Haves  Won't have this times: valuable requirements, but can wait until a later increment Note: All prioritisation is with respect to a clear project objective. M S C W

The Requirement Lifecycle Each requirement must be subject to: Elicitation Workshops, model-building, interviews, observation, scenarios Analysis Realistic? Ambiguous? Combination of requirements? Aligned with business? Validation Prototypes, reviews, models, testing Management Traceability, stability, change management

Summary What is a requirement? Functional and non-functional requirements Requirements in the Atern lifecycle Requirements and modelling The Requirement Lifecycle

Topic 9 – Requirements Definition and Prioritisation Any Questions? NCC Education - End Slide Master