This contribution to the debate regards precise requirements and the UML.

A Brief Summary in English:

Match the needs.

No matter if you’re going to develop your system, integrate components, purchase services or adapt OTS-software, you always have to specify clear business needs and requirements. Because of SW complexity, beware of “IT red tape” whose symptoms are marathon meetings without a horizontal, relevant, straightforward communication between business and IT. Many people (including Dr. Jacobson) emphasize the kinship of SW with other industries. Others (including Dr. Szyperski) point out the peculiarity of SW as the product becomes intertwined into its blueprint. Which side is more right than the other depends on which level of complexity is implied on the other side of the comparison, in “other industries”: one of a tire shop or one of an off-shore platform.

Bid preparation and requirement specification take precision and time in all knowledge industries, with no exception for IT. Even if our component vendors do a significant part of the work, substantial knowledge is still needed within the enterprise: on product architecture, component configuring, strategic or unique proprietary components and last but not least, on how to effectively meet a variety of requirement patterns and needs. To communicate these requirements, it’s key to know the basics of each other’s ”worlds” and to be aware of what information the other side expects. Lean specs, focusing on What rather than How are excellent – but they’re the opposite of fuzzy officialese full of logical gaps and contradictions. That’s why we’ve had a (1) world standard since 1997 for all SW blueprints, based on decades of experience by hundreds of businesses.

 

Published in Swedish by the IDG in Computer Sweden, debate page, http://computersweden.idg.se/, April 14th, 2003:

Matcha behovsprofiler.

Oavsett om man bygger eget, integrerar komponenter, upphandlar tjänster eller anpassar färdigt från hyllan så måste man ändå tydligt specificera verksamhetens behov och krav. Tvärtemot den välkända svepande jämförelsen med bilar så spänner programvaror från ”bilar för dummies” enkelt upp till rymdfärjans eller offshore-plattformens komplexitet. Trots eget civilekonomexamen i baggaget (eller pga.) vill jag varna för en byråkratikultur i IT-frågor som yttrar sig i maratonmöten utan horisontell kommunikation ”till punkt” mellan verksamhet och IT.

 

De finns väldigt många (inklusive Ivar Jacobson) som betonar likheterna mellan mjukvara och industri, i synnerhet när det gäller komponenttänkandet. Men det finns också en del som hellre betonar olikheterna, däribland Microsofts komponentguru Szyperski som på OT-Land hävdar att programvara är en blandning utan motstycke: matte, datalogi, produkter, kundkrav osv, där ritningen och produkten tenderar att flyta ihop.

Vilken sida som prickar flest rätt beror helt på vilken komplexitet man underförstår i sin jämförelse med ”övrig industri”: däckfirmans eller Nordsjöplattformens. Parallellerna finns i komplex, kunskapsintensiv industri snarare än i däcklagret. Givet Jumbons eller Rymdfärjans påfrestningar på däcken är det, tvärtemot Eides argumentation, livsviktigt med exakta krav som resulterar i rätt gummiblandning. Offertberedning och kravspecifikationer är ett noggrant och tidskrävande arbete i alla kunskapsindustrier, på den punkten är IT inget undantag. Även om vi kan lägga ut mycket på komponentleverantörer, behövs ändå djup intern kunskap i företaget om produktarkitektur, komponentkonfigurering, strategiska eller unika egna komponenter och sist men inte minst om hur man effektivt tillmötesgår olika behovsprofiler och kravmönster.

 

För kommunikationen mellan kravställare och IT är det avgörande att känna till grunderna i varandras ”världar” och framförallt vad den andra sidan kan behöva få reda på (och att därmed kunna utelämna en massa ovidkommande information utan att missa viktiga krav). Smala kravspecar som fokuserar på VAD hellre är HUR är utmärkt – men de är samtidigt raka motsatsen till svävande tvetydig prosa full med logiska luckor och motsägelser. Det är just därför vi sedan 1997 har en (1) världsstandard för mjukvarudokumentation, baserad på decennier av erfarenheter i hundratals IT-företag: däckgrabbarna behöver inga exakta krav - men i komplexa kunskapsprodukter fungerar resonemanget endast där ingen som helst koppling mellan behoven och lösningen önskas…

Milan Kratochvíl, Kiseldalens (konsult, UML-utbildare, autor: UML Xtra Light – How to Specify Your SW Requirements).

 

Back, Kiseldalens Top Page