Agile Requirements - Dag voor de Requirements Engineer - DiVetro

Arnhem 01 november 2017

Agile requirementsDag van de Requirements Engineer

Dennis Geluk

ww

w.d

ivetr

o.n

l

Roadmap

01/11/2017 2Agile requirements

REQUIREMENTS

ww

w.d

ivetr

o.n

l

Sli.do

01/11/2017 Agile requirements 3

Stelling: Agile requirements bestaan!

ww

w.d

ivetr

o.n

l

Requirement by Wikipedia

… a requirement is a singular documented physical and functional need that a particular design, product or process must be able to perform. ….

It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder.

… Requirements are also an important input into the verification process, since tests should trace back to specific requirements. …. When iterative methods of software development or agile methods are used, the system requirements are incrementally developed in parallel with design and implementation. With the waterfall model requirements are developed before design and implementation


ww

w.d

ivetr

o.n

l

Requirement by Wikipedia


a singular documented … functional need that a … must be able to

performWhen iterative or agile methods

are used, the system requirements are incrementally developed in

parallel with design and implementation

a statement that identifies a necessary … of a system to have

value to a …

an important input into the verification process, tests should

trace back to requirements

With the waterfall model requirements are developed before

design and implementation

ww

w.d

ivetr

o.n

l

Manifesto for Agile Software Development


Working software

Responding to change

Individuals and interactions

Customer collaboration

ww

w.d

ivetr

o.n

l

Manifesto for Agile Software Development


Working software

Responding to change

Individuals and interactions

Customer collaboration

ww

w.d

ivetr

o.n

l

Sli.do


Wat betekent “working software over comprehensivedocumentation”?

ww

w.d

ivetr

o.n

l

Documentation by Wikipedia

1. Requirements – Statements that identify attributes, capabilities, characteristics, or qualities of a system. This is the foundation for what will be or has been implemented.

2. Architecture/Design – Overview of software. Includes relations to an environment and construction principles to be used in design of software components.

3. Technical – Documentation of code, algorithms, interfaces, and APIs.

4. End user – Manuals for the end-user, system administrators and support staff.

5. Marketing – How to market the product and analysis of the market demand.


ww

w.d

ivetr

o.n

l

Stakeholders voor requirements / documentatie


TEAM TEAM(S)• Feature teams

STAKEHOLDERS• Business• Security / Safety• Beheerorganisatie• Support• …

ww

w.d

ivetr

o.n

l

De noodzaak van documentatie


• Complexiteit

• Levensduur oplossing

• Aantal teams

• Teamgrootte

• Geografische locaties

• Domeinkennis team

• Toegang tot domein experts (PO)

• Wet- en regelgeving / Ernst van fouten

• Aantal Stories

ww

w.d

ivetr

o.n

l

Sli.do


Wat is het primaire doel van een user story?

ww

w.d

ivetr

o.n

l

User story by Wikipedia

Description consisting of one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function. User stories are used with agile software development methodologies as the basis for defining the functions a business system must provide, … …Often limited in detail by what can be hand-written on a small paper notecard.

A user story encapsulates the action of one function making it possible for software developers to create a vertical slice of their work


ww

w.d

ivetr

o.n

l

User story by Wikipedia

Description consisting of one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function. User stories are used with agile software development methodologies as the basis for defining the functions a business system must provide, … …Often limited in detail by what can be hand-written on a small paper notecard.

A user story encapsulates the action of one function making it possible for software developers to create a vertical slice of their work


ww

w.d

ivetr

o.n

l

• Eenheid van werken

• Scherpe afbakening van (functionele) scope binnen sprint

• Acceptatiecriteria

• Geprioriteerd

• Geschat in complexiteit

• Overzicht van (ontwikkelde) functionaliteit van het systeem als geheel

• Afbakening van functionele scope binnen project

• “Acceptatiecriteria” voor systeem als geheel


Documentatie vs User Story

Documentatie User story

ww

w.d

ivetr

o.n

l

Just enough & Just in time documentatie

1. Start op abstract en hoog niveau (Big picture)

2. Fit for purpose (vorm)• One size does not fit all

• Wisselende detailniveaus

3. Discipline• Voeg alleen details toe indien het nodig is

• Voeg alleen details toe wanneer het nodig is


ww

w.d

ivetr

o.n

l

Backlog en “Big picture”


Actor 01

(from

Actors)

Actor 02

(from

Actors)

Actor 03

(from

Actors)

(from Heavy Molecule)

Use Case 01


Use Case 02


Use Case 03


Use Case 04

Actor 06

(from

Actors)

Actor 05

(from

Actors)

«include»

Stories maken samen een big picture

De big picture kan opgedeeld worden in stories

ww

w.d

ivetr

o.n

l

Fit for purpose – just enough


Supplementary Requirements

Test scenario's

Glossary Domain model Business rulesUse Case Narrative

Use Case Realisation

UX

ww

w.d

ivetr

o.n

l

Indien meer details benodigd zijn


• Complexiteit • Ambiguïteit

• Use cases overstijgende requirements • Aantal scenario’s

• Veiligheids, financiële of wettelijke requirements

• Relatie tussen glossaryitems

ww

w.d

ivetr

o.n

l

Just-in-time

Just-in-time is een subjectief begrip

• Just-in-time kan zijn:• Sequentieel proces van Requirements, Development en Test• Parallel proces van Requirements, Development en Test• Iedere andere combinatie

• Just-in-time kan beïnvloed worden door:• Volwassenheidsniveau van de organisatie / team in agile werken• Organisatiestructuur (hiërarchische cultuur)

• Focus op wat “echt” nodig is op een bepaald moment


ww

w.d

ivetr

o.n

l

Just-in-time en Just-enough

Just-in-time en Just-enough hebben een relatie met elkaar

• Het detailniveau is afhankelijk van het moment waarop je het nodig hebt• Wat later nodig is, kan nu je beeld vertroebelen

• Wat nu genoeg is, kan later onvoldoende zijn

• Voeg nooit details toe omdat het kan


ww

w.d

ivetr

o.n

l

Agile requirements - conclusie


Agile requirements bestaan niet

Agile projecten bestaan wel

Agile projecten vereisen een andere manier van denken en werken dan een meer traditionele omgeving

Just-in-time requirements met just-enough details

ww

w.d

ivetr

o.n

l

Meer informatie

• divetro.nl/publicaties/analyse/• 3 overeenkomsten en 3 verschillen tussen use cases en user stories

• Agile requirements bestaan niet

• Requirements zijn geen eenpansmaaltijd

• Efficiënte analyse: Just Enough in de praktijk

• Agile en Requirements e-book

• Etc…

• Use-Case 2.0 ebooks

• practicelibrary.ivarjacobson.com


[email protected]

Dennis Geluk

[email protected]

+31 (0)6 13 476 892

+31 (0)26 443 67 90ww

w.d

ivetr

o.n

l

Parkstraat 74 | 6828 JL Arnhem