Hoe gedetailleerd zijn jullie Business Requirements?

[dakathefox]

Momenteel zit ik in een interne discussie over de gedetailleerdheid van de Business Requirements. Ik ben van mening dat ik zo gedetailleerd mogelijk moet zijn, mijn collega zegt het tegenovergestelde. Graag zou ik jullie feedback daarop willen horen.

Scenario:
Op basis van een Rest API, willen we een overzicht tonen in een specifiek scherm.

Mijn insteek:
Ik schrijf user-stories, waarbij ik per user aangeef wat ze moeten kunnen doen:
- De gebruiker kan zoeken binnen 1 of meer van de velden
- De gebruiker kan veld "naam" sorteren van A-Z of van Z-A
- De gebruiker kan veld "datum" sorteren van nieuw naar oud en van oud naar nieuw.
- De gebruiker kan veld "datum" filteren op datum van/tot
- Etc...

Collega:
"Zet maar gewoon dat je een lijst wilt tonen. Ik snap wel dat je dat wilt filteren, sorteren, etc, en dat verwerken we wel in de technische requirements".

[TommieW]

"Ik snap wel dat je wil filteren(...)" Assumption is the mother of all fuck-ups!

Als ik mij niet vergis, is het idee van business requirements dat je exact op papier hebt staan wat de bedoeling is. Vanuit de business zou dit dan ook gecheckt en geaccordeerd moeten worden. Dan heeft iedereen de verwachtingen op één lijn zitten.

Stel je hebt dadelijk je product af, tenminste dat denk je. Vervolgens komt de business met de eis dat ze willen filteren op kolom A en tegelijk sorteren op kolom B. Als je business requirements zo specifiek mogelijk zijn, dan kan je makkelijker terugkoppelen dat men daar niet om gevraagd hebt.
Als je business requirements zo vaag mogelijk zijn, dan wordt het al snel een welles-nietes spelletje.

[Marber]

Je kan voor filtering standaard-requirements afstemmen. Bijvoorbeeld alle lijsten moeten op alle velden gefilterd kunnen worden. (Zelfde geldt voor andere zaken die vaak terugkomen).

Dan hoef je daarna alleen de uitzonderingen te specificeren.

Deze aanpak maakt meteen inzichtelijk of het de moeite waard is om standaard componenten te ontwikkelen/aan te kopen

[MvHMontySCOUT]

Schrijft diegene die de technische requirements schrijft ook het testplan? Indien nee, hoe wordt voorkomen dat het er verschillen tussen het testplan en de technische requirements ontstaan? want dan is de devver by default die er dan weer achteraan kan gaan wat wenselijk is.

In het geval van een lijst, zou ik het als volgt omschrijven.
Kolommen:
- Naam, string, filterable. sortable asc, desc
- Datum, date, filterable from/to by date, format: (format)

etc. Kort en bondig, en iedereen blij.


Waar het bij ons vaak mis gaat, is rollen & rechten en de minor happy flows, die worden vaak niet goed omschreven maar we zijn een klein team dus daar komen we wel uit. (of een sprint later)

[dakathefox]

Duidelijke feedback. Dank u!

[Jumpman]

Aannames zijn killing. Maak het zo smart mogelijk voor je klant/afnemer en ook wanneer hij/zij welke functionals krijgt opgeleverd. Je gaat anders discussies krijgen die je niet wilt en die tijd kosten. Laat ook zien in planning wat functionele en technische items zijn waar je aan werkt. Technische items daar heeft de gebruiker misschien niet direct wat aan, maar zijn wel belangrijk voor bijvoorbeeld het optimaliseren.

[MAX3400]

Op basis van je startpost lees ik "eigenlijk" het volgende: al doende tijdens implementatie schrijven / doen we requirements afstemmen.

Wel vreemd want de requirements zouden geborgd moeten zijn in een globaal en een low-level technisch design welke opgesteld en gevalideerd zijn door mensen anders dan de uitvoerende programmeur.

Anders krijg je een beetje het WC-eend verhaal

[Ed Vertijsment]

Ik weet niet hoe ver wij aan dezelfde kant zitten, volgens mij gaat het bij jullie om een intern project en zijn jullie dus zelf ook klant. Ik zit aan de ontwikkelaarsqant en zie dus vooral wat er gevraagd wordt, hoewel we ze ook samen opstellen met de klant.

Hoe dit gebeurt verschilt per project. De ene klant heeft heel goed de verwachtingen uitgeschreven. De verwachtingen worden dan omgezet in user stories en een voor een geïmplementeerd.

De andere klant spreekt een meer globale wens uit en koopt ontwikkelaars tijd in, wij ontzorgen de klant dan door de details in te vullen. Aan het einde reserveren we dan tijd om de laatste aanpassingen te doen waar de klant dat nog wil.

Het laatste scenario kan niet altijd maar heeft als voordeel dat de details uitgedacht kunnen worden als het project al veel concreter is. Dat maakt keuzes maken makkelijker.

In beide gevallen is er eigenlijk altijd wel één consistente factor, de requirements veranderen naarmate het project vordert. Te veel detail hierin is dus veelal weggegooide moeite en te strict eraan vasthouden levert vaak iets op wat geen waarde heeft.

De kunst is IMHO om hier een goede balans in te vinden. Er is volgens mij ook geen beste manier om het te doen. Je zult moeten proberen wat het beste werkt voor elk project.

[MrMonkE]

Testers vinden usecases ook wel leuk.
Weten ze wat iets moet doen en dat helpt aanzienlijk bij het testen.

[Ed Vertijsment]

MrMonkE schreef op zaterdag 20 april 2019 @ 12:35:
Testers vinden usecases ook wel leuk.
Weten ze wat iets moet doen en dat helpt aanzienlijk bij het testen.

Interessant punt, het lijkt mij dat het, het "werk" makkelijker maak maar ook per sé beter? Ik kan mij voorstellen dat een tester die zonder verwachtingen ergens in gaat gemakkelijker de edge cases opzoekt waar je ook wilt testen.

[MrMonkE]

Ed Vertijsment schreef op zaterdag 20 april 2019 @ 12:48:
[...]


Interessant punt, het lijkt mij dat het, het "werk" makkelijker maak maar ook per sé beter? Ik kan mij voorstellen dat een tester die zonder verwachtingen ergens in gaat gemakkelijker de edge cases opzoekt waar je ook wilt testen.

Testers duiken overal in het zijn net katten en zoeken en vinden ALLES. Gek wordt ik er soms van.
Maar zolang ze goed beschrijven wat ze gedaan hebben om het 'stuk te maken' is het win-win. Goede testers doen dat altijd en die beperken zich niet tot de use-cases maar proberen altijd de boel te zieken. Bizar wat ze soms boven water krijgen.

[n9iels]

Ik leer op school bij de opleiding Informatica dat je deze requirements zo specifiek mogelijk moet maken. Het liefst zelfs met acceptatie criteria en test cases erbij.


Nu tijdens mijn afstudeerstage kom ik erachter waarom dit handig is. Ten eerste is een goede uitgeschreven requirement makkelijker te schatten. Dus je kunt makkelijker voorspellen hoeveel werk je kunt verzetten.
Daarnaast voorkomt het dat je onnodige dingen doet. Is het sorteren van AZ wel echt nodig? Zo niet kom je daar liever snel achter, zodat je je tijd nuttig kunt besteden.

Als laatste helpt het enorm met overzicht. Het is super fijn om na het afronden van je taak ook gewoon echt klaar te zijn.

[Crazy D]

In de praktijk wil je voorkomen dat je echt alle punt-komma's (ver) van te voren beschrijft. In 1e instantie benoemen dat je wilt kunnen zoeken en filteren is wat mij betreft voldoende. Zodra het dichter bij uitvoering gaat komen, is het wel belangrijk om te weten welke velden je wilt filteren en sorteren, dat kan immers bepaalde technische gevolgen hebben of simpelweg uitermate omslachtig (codes warvan de omschrijving in de database in het Engels staan en pas tijdens het tonen op het scherm vertaald worden naar de taal van de gebruiker). En voor je inschatting maakt het over het algemeen niet heel veel uit of je 2 of 4 zoekvelden hebt, maar 4 kost natuurlijk meer tijd dan 2.

Of je specifiek bijvoorbeeld ook datum-traject als criterium benoemd hangt misschien af van de techniek, in Exact Synergy heb je eigenlijk standaard datum-ranges met standaard opties voor huidige maand, vorig jaar, etc). Dat ga je dan niet specifiek benoemen tenzij je in een bepaald geval echt 1 datum-veld wilt (afwijking t.o.v. de standaard functionaliteit). Maar dat je wilt kunnen zoeken op datumveld-x moet je wel benoemd hebben voordat je kunt gaan bouwen. Dat is uiteindelijk ook een onderdeel van de test en acceptatie.

Ervaring leert (helaas) wel dat gebruikers vaak pas echt kunnen bepalen wat handig is qua filtering en sortering, als er iets is dat getoond kan worden en ze echt zelf achter de knoppen kunnen zitten om hun werk te doen... In de praktijk kies ik dus meestal de weg: bepaal zo goed mogelijk welke kolommen je wilt tonen, sorteren doe ik vaak op alle kolommen tenzij anders benoemd, en pak 1 of 2 zoek-velden waarvan 200% duidelijk is: die zijn nodig. En na de 1e tests komt er toch altijd wat uit, pak dan de extra zoekvelden mee.

[Anoniem: 80910]

Ik zal het anders doen: functioneel ontwerp, technisch ontwerp. Dus algemeen in functioneel ontwerp, specifiek in technisch ontwerp. Functioneel ontwerp vaak bij klant besproken, technisch ontwerp vaak intern gehouden en kan zo gedetailleerd naar wens van de implementators gemaakt worden.

[MSalters]

TommieW schreef op vrijdag 19 april 2019 @ 10:50:

Stel je hebt dadelijk je product af, tenminste dat denk je. Vervolgens komt de business met de eis dat ze willen filteren op kolom A en tegelijk sorteren op kolom B. Als je business requirements zo specifiek mogelijk zijn, dan kan je makkelijker terugkoppelen dat men daar niet om gevraagd hebt.
Als je business requirements zo vaag mogelijk zijn, dan wordt het al snel een welles-nietes spelletje.

En precies hierom lopen overheidsprojecten dus miljoenen uit.

Nee, dus niet omdat de business requirements voor de UI aan het begin incorrect waren. Nee, omdat de bedrijven die de opdracht aangenomen hebben best weten dat je UI's niet volledig vooraf tekstueel kunt bescrhijven. Die gaan dus precies in de mode van TommieW hierboven. "hebben jullie niet gezegd, is meerprijs".

Specificeer dus de feitelijke eisen: "gebruikers moeten in tabel T de rijen X,Y en Z kunnen vinden binnen 3 seconden". Welke filter- en sorteeropties daarvoor handig zijn is geen business probleem, maar een UI probleem. De business eis is dat de gebruikers productief zijn.

[Standeman]

Eigenlijk heel simpel. Requirements die je over 6 maanden wil implementeren zijn globaal omschreven, requirements die je over 2 weken gaat implementeren zeer specifiek. Door regelmatig met de klant samen te komen en komend werk te specificeren ontwikkel je wat de klant wil en kan gebruiken.

Want laten we eerlijk zijn, de klant heeft meestal ook geen idee wat hij precies wil over 6 maanden.

[Grvy]

Standeman schreef op dinsdag 23 april 2019 @ 15:28:


Want laten we eerlijk zijn, de klant heeft meestal ook geen idee.

FTFY

[Hydra]

@FitsSprits Alles waar je vooraf aannames op doet zijn een risico; die aannames kunnen verkeerd zijn en dan moet je het naderhand weer aanpassen. Alleen het opschrijven van 'ongeveer alles' heeft een flinke overhead, helemaal als het werk betreft dat ver in de toekomst ligt. Het antwoord op je vraag is dus; precies genoeg. En dat antwoord heb je inderdaad geen hol aan

Het is ook vooral een kwestie van ervaring. Op den duur ga je bepaalde dingen zien aankomen, dat gebruikers naar aanleiding van functionaliteit A ook functionaliteit A-accent willen. Dit is dus vooral een kwestie van veel samen zitten, schetsen, "wat als" scenario's voorleggen, en wat hier dan uitkomt opschrijven.

Bottom line wil ik dus precies genoeg informatie hebben om m'n werk te kunnen doen zonder daarna nog grote veranderingen te moeten maken. Helemaal voorkomen ga je dat nooit natuurlijk, en "goed genoeg" is vaak pragmatischer dan perfect. Ik zelf kom dus ergens uit tussen jou en je collega.

Standeman schreef op dinsdag 23 april 2019 @ 15:28:
Eigenlijk heel simpel.

Het is simpel maar niet makkelijk

Crazy D schreef op zaterdag 20 april 2019 @ 14:46:
Ervaring leert (helaas) wel dat gebruikers vaak pas echt kunnen bepalen wat handig is qua filtering en sortering, als er iets is dat getoond kan worden en ze echt zelf achter de knoppen kunnen zitten om hun werk te doen... In de praktijk kies ik dus meestal de weg: bepaal zo goed mogelijk welke kolommen je wilt tonen, sorteren doe ik vaak op alle kolommen tenzij anders benoemd, en pak 1 of 2 zoek-velden waarvan 200% duidelijk is: die zijn nodig. En na de 1e tests komt er toch altijd wat uit, pak dan de extra zoekvelden mee.

Daarom werk je met user interfaces over 't algemeen met wireframes / prototypes. Een UI gaat toch pas 'leven' als het zichtbaar is. Zelfs als back-ender pak ik er regelmatig iets als Balsamic bij om wat ik bedoel zichtbaar te maken. Puur tekstueel / verbaal werkt niet: de gemiddelde gebruiker volgt ons niet (en dat is ons manco, niet dat van de gebruiker).

MSalters schreef op dinsdag 23 april 2019 @ 14:40:
En precies hierom lopen overheidsprojecten dus miljoenen uit.

Nee, dus niet omdat de business requirements voor de UI aan het begin incorrect waren. Nee, omdat de bedrijven die de opdracht aangenomen hebben best weten dat je UI's niet volledig vooraf tekstueel kunt bescrhijven. Die gaan dus precies in de mode van TommieW hierboven. "hebben jullie niet gezegd, is meerprijs".

Mwa, het is wel iets complexer dan dat. Het probleem is over 't algemeen dat er in overheidsprojecten gewoon absoluut geen consensus is over wat er precies moet komen. Voor die centrale gemeentelijke basisadministratie bijvoorbeeld moest er een consensus op de workflow komen binnen een groep van 20 gemeentes. Dus een paar honderd ambtenaren, die zelf absoluut niks anders doen dan overal tegen zijn, moeten het eens worden.

Het klopt zeker wel dat de Caps en Ordina's hier handig misbruik van maken (heb het destijds met Logica ook bij het UWV gezien), maar dat het iedere keer zo misgaat ligt wel primair aan de overheid zelf. In het bedrijfsleven wordt er veel harder gestuurd en snappen ze dat tijd geld is.

[ Voor 60% gewijzigd door Hydra op 23-04-2019 16:13 ]

[Angeloonie]

Het ligt ook grotendeels aan het vertrouwen dat je hebt in die collega. Heb je veel ervaring in samenwerken met hem (of haar), of is dit de eerste keer dat jullie samenwerken? En hoe lang werkt de ontwikkelaar al op een bepaald systeem?

Ik werk zelf samen met een ontwikkelaar (nu zo'n 8 jaar al), en we begrijpen elkaar wederzijds. Mijn "user stories" zijn dan ook niet meer dan gewoon een business requirement, met hier en daar wat specifieke info (veld dit moet X doen) om het net iets duidelijker te maken. Maar over het algemeen heeft hij aan minimale info al genoeg om te snappen wat er gedaan moet worden.

Ik kan mij voorstellen dat als het systeem nieuw is en de ontwikkelaar ook, en de relatie ook nog vers is je misschien wel meer wilt vastleggen. Maar dan zou ik het gewoon beperken tot hoofdlijnen en niet per veldje vastleggen wat het moet doen. Ook een mockup van een schermpje zegt vaak al veel meer dan een lijstje requirements.

De echte opzet van "User Stories" met acceptance criteria, testcases etc. vind ik echt onzin en tijdverspilling. Als een ontwikkelaar snapt wat je wilt bereiken met een bepaalde functie/aanpassing, dan is dát de kern.
M.a.w.: bespreek met je ontwikkelaar wat je wilt gaan doen, en wat het op het userproces doet. Dan snappen ze wat je wilt gaan doen en vullen ze zelf de details wel in. Dus niet "ik wil veld X met Y en Z toevoegen", maar "we willen inzicht krijgen in zus en zo, en als we dit veld hebben kunnen we dat direct zien".
Zo krijgt de ontwikkelaar ook meer kennis van de business kant, en dit gaat je in een later stadium zeker helpen.

[Rowwan]

User story != Requirement...

User stories zijn "disposables". Die verzin je, implementeer je, en kijk je nooit meer na. Je gebruikt ze om werk te plannen.

Requirements zijn voor de lange termijn. Voor de klant, en om tegenaan te testen.

[labee]

Maar inderdaad vertrouwen is van invloed en of de developers intern zijn of extern zitten.
Maar ik hoor userstories. Dus dan lees ik scrum en dan is de refinement sessie heel belangrijk om het niveau van details duidelijk te maken, zodat iedereen weet wat er gebouwd moet worden en of het daarmee testbaar is.