Jag satt nyligen i ett mötesrum fullt av människor med lite olika roller; systemarkitekter, kravledare, produktägare, säkerhetsspecialister, dokumentatörer... Syftet med mötet var att gå igenom ett antal produktinitiativ som hade samlats in för en tid sedan, och att följa upp vårt gemensamma arbete med att bryta ned dessa till mer konkreta features. Utkast till funktionella business-features varvades under diskussionen med arkitekturella features (eller enablers som de nuförtiden kallas enligt SAFe-ramverket som projektet ifråga hämtar inspiration ifrån).
Stämningen i rummet var inte direkt dålig, men jag kände ändå i maggropen att två läger höll på att utkristalliseras. På ena sidan de som argumenterade för att features på alla nivåer skulle betraktas som helt lösningsfria verksamhetsbehov (VEM vill göra VAD) med tydlig koppling till affärsnytta (VARFÖR), och på andra sidan de som argumenterade för features som användbara instruktioner som både talar om för utvecklingsteamen vad som behöver byggas framöver (VAD) och vilka designbeslut de har att förhålla sig till (HUR). Personligen hörde jag till de mer högljudda rösterna i det förstnämnda lägret. Ett tag efter mötet drabbades jag emellertid av en sån där jobbigt gnagande känsla av självinsikt, och jag började spendera lite tid på att försöka förstå varför jag egentligen känt behov av att hålla så hårt på min egen linje istället för att intressera mig för de olika perspektiv som hade funnits representerade i mötesrummet. Det måste ju någonstans finnas en bra förklaring till att ett antal smarta individer lägger så olika innebörd i begreppet ”krav”. Min kollega Alexander skrev på samma tema om en elefant i rummet förra sommaren.
Suzanne Robertson har hjälpt mig att förstå det här med perspektivfrågan på ett teoretiskt plan, även om jag fortfarande kanske glömmer bort mig ibland. Hon brukar använda biblioteket och det datoriserade bibliotekssystemet för att visa hur work scope och product scope kompletterar varandra när dessa båda kontexter modelleras fram parallellt. På den högsta nivån är det slutanvändarens behov som står i centrum, det vill säga låntagaren som förväntar sig att kunna låna böcker när han går till biblioteket. Bibliotekarien, som ju är en del av lösningen i ett fysiskt bibliotek, ingår i arbetsscopet (ursäkta svengelskan). Men i produktscopet för ett nytt boklånesystem flyttar hon ut och blir istället en extern aktör och stakeholder. Beslutet om lösning har alltså påverkat kravbilden. 
I större projekt kan det finnas anledning att partitionera produkten i flera delsystem, vilket borde innebära att vi måste acceptera inte bara två utan ännu fler perspektiv beträffande produktscope, krav och lösning. Även om slutanvändarens krav på den högsta nivån är intakta över tid så blir lågnivåkraven beroende av de lösningar som har valts högre upp i kedjan.
Krav, lösningar och lösningsberoenden på olika nivåer
Betyder detta att just lösningsberoendena är helt centrala att få med i våra beskrivningar och modeller när krav formuleras mellan en godtycklig nivå och en annan? Jag hittade ett inlägg från ambitiösa sajten Svensk kravterminologi. Där har man faktiskt definierat termen krav så här:
Krav Ett uttryck som förmedlar ett behov med dess begränsningar och villkor
”Med dess begränsningar…” Jag tycker att denna one-liner känns klockren (förmodligen bara för att den råkar passa som en handske med bilden jag precis ritade, men ändå). Ju mer jag funderar desto mer lutar jag åt att så snart vi lämnar work scope-nivån och beslutar oss för att bygga någon form av produkt för att lösa ett system- eller ett verksamhetsproblem, så måste vi ta hänsyn till detta produktbeslut som ett lösningsberoende när vi detaljerar kraven på nästa nivå. Annars blir nedbrytningsarbetet helt enkelt inte användbart utan bara mer fluff i ytterligare ett dokument!
Sorry arkitekter, jag lovar att vara lite mer ödmjuk på nästa möte.