Joel on Software

Joel on Software   Joel over Software

 

Andere "Joel on Software" artikelen in het Nederlands

Andere "Joel on Software" artikels in het Engels

Email de auteur (uitsluitend in het Engels)

 

Pijnloze Functionele Specificaties - Deel 2: Wat is een Spec?


Door Joel Spolsky
Vertaald door Mark Tetrode
3 Oktober 2000

(Heb je deel één al gelezen? Zo niet, die is hier.)

Deze serie artikelen gaat over functionele specificaties, niet over technische specificaties. Mensen verwarren deze vaak. Ik weet niet of er standaard definities voor zijn, maar dit versta ik eronder.

  1. Een functionele specificatie beschrijft hoe een produkt werkt van uit het standpunt van de gebruiker. Het maakt niet uit hoe de dingen worden geïmplementeerd. Het beschrijft de mogelijkheden. Het specificeert schermen, menu's dialogen, et cetera.
  2. Een technische specificatie beschrijft de interne implementatie van het programma. Het beschrijft data structuren, relationele database modellen, keuzee van programmeertalen en tools, algoritmes, enzovoorts.

Als je een produkt ontwerpt, van binnen en van buiten, is het allerbelangrijkste de 'gebruikers-ervaring'. Welke schermen zijn er, hoe werken ze, wat doen ze? Later ga je je zorgen maken om van hier naar daar te komen. Je moet geen programmeertaal kiezen voor je besloten hebt wat je produkt gaat doen. In deze serie artikels praat ik alleen over de functionele specificaties.
 
Ik heb een kort voorbeeld spec geschreven die je een idee moet geven hoe een goede functionele specificatie eruit moet zien. Lees deze eens, voor we verder gaan.

Heb je die gelezen?

Niet waar. Ga die nu lezen en kom dan terug naar deze pagina, dan kunnen we verder spreken wat een goede spec moet en niet moet hebben. Ik wacht hier wel op je. Dank je.

(geduldig wachtend...)

picture-OldSanJuan:

Ah, goed. Je bent terug.

Hier zijn een aantal dingen die ik in een spec zet.

Een disclaimer. Pure zelfverdediging. Als je in een paragraaf zoiets zet als "Deze spec is niet volledig", dan komen de mensen niet naar je bureau om je ermee om je oren te slaan. Als de tijd vordert, en de spec begint af te raken, kan je het veranderen in "deze spec is volledig naar mijn beste mogelijkheden, maar als er iets ontbreek, vertel het me dan." Dat herinnert me aan iets wat elke spec moet hebben:

Een auteur. Eén auteur. Sommige firma's denken dat een spec geschreven dient te worden door een team. Als je al eens geprobeert heb om te schrijven in een groep weet je dat er geen ergere marteling is. Laat dit schrijven in een groep maar over aan management consulting firma's met legers van nieuw-universitair-afgestudeerden die moeten doen alsof ze druk bezig zijn om hun exorbitante prijzen te rechtvaardigen. Jouw specs moeten eigenaar zijn en worden geschreven door één persoon. Als je een groot produkt maakt, splits het dan op in onderdelen, en geef laat verschillende medewerkers aan de spec schrijven. Andere bedrijven denken dat dit egoïstisch of niet "goed teamwork" is dat één persoon de credits krijgt door z'n naam op de spec te zetten. Onzin. Mensen moeten verantwoordelijkheid en eigenaarschap nemen van de dingen die ze beschrijven. Als er iets mis is met de spec moet er een spec eigenaar zijn, wiens naam op de spec afgedrukt staat, die verantwoordelijk is om het op te lossen. 

Scenario's. Wanneer je een produkt ontwerpt, moet je enkele echte scenario's in je hoofd hebben hoe de mensen het gaan gebruiken. Anders eindig je met een produkt dat niet voldoet aan de wensen van de gebruikers (zoals de Cue?Cat). Stel je de verschillende doelgroepen voor die jouw produkt moeten gaan gebruiken, en beeld je een fictief maar stereotiepe gebruiker van elke doelgroep in, die het produkt zal gebruiken. Hoofdstuk 9 van mijn UI ontwerp boek (gratis online te verkrijgen) spreekt over die fictieve gebruikers en scenario's. Hier moet je die gebruiken. Hoe levendiger en realistisch het scenario, hoe beter werk je zal leveren in het ontwerpen van een produkt voor je echte of fictieve gebruikers. Dit is waarom ik veel verzonnen details stop in mijn specs.

Non-doelen. Wanneer je samen met een team een produkt maakt heeft iedereen wel een echte of ingebeelde feature waar ze niet zonder kunnen. Als je die allemaal zou implementeren kost dit oneindig veel tijd en veel te veel geld. Je moet direct features weglaten, en de beste manier hiervoor is om een sectie in de spec op te nemen waar je beschrijft wat je niet gaat doen. Een niet-doel kan een feature zijn die er niet inkomt ("geen telepatische user interface!") of iets algemeners ("We geven niet om performance in deze release. Het produkt kan traag zijn, zolang het maar goed werkt. Als we de tijd krijgen in versie 2 zullen we de tragen delen proberen te versnellen.") Deze non-doelen zullen waarschijnlijk aanleiding geven tot nogal wat discussie, maar het is belangrijk om de zo snel mogelijk openbaar te maken. "Dat gaan we dus niet doen", zoals George senior het zegt. 

Een overzicht. Dit is zoals de inhoudsopgave voor je spec. Het kan een simpel stroomdiagram zijn, of een uitgebreide architectuur discussie. Iedereen zal dit lezen om het algemene idee te vatten, en dan zijn de details ook veel duidelijker.

Details, details, details. Eindelijk kom je bij de details. De meeste mensen zullen dit overslaan totdat ze zo'n detail willen kennen. Een goede manier om dit te doen, als je een web-type service ontwerpt, is om elk mogelijk scherm een naam te geven, en een hoofdstuk te schrijven dat elk scherm tot in het laatste detail beschrijft.

Details zijn het allerbelangrijkste ding in een functionele specificatie. Je hebt gezien in de voorbeeld spec hoe ik tot in het allerkleinste detail schrijf over alle foutmogelijkheden voor de login pagina. Wat als het email adres niet correct is? Wat als het wachtwoord fout is. Al deze mogelijkheden corresponderen met echte code die geschreven zal worden, maar belangrijker nog, deze zaken corresponderen met beslissingen die iemand zal moeten maken. Iemand moet beslissen wat de politiek is voor een vergeten wachtwoord. Als je dat niet beslist, kan de code niet geschreven worden. De spec moet deze beslissing documenteren.

Open issues. Voor de eerste versie van de spec mogen er nog open issues zijn. Als ik een eerste versie schrijf heb ik altijd veel open issues, maar ik markeer deze (door een speciale stijl zodat ik erop kan zoeken) en, indien mogelijk beschrijf ik de alternatieven. Op het moment dat de programmeurs beginnen te coderen moeten deze zijn opgelost. (Misschien denk je dat het OK is om de programmeurs te laten beginnen met het gemakkelijke deel, en jij zal die open issues later wel oplossen. Slecht idee. Je zal al genoeg problemen hebben om de nieuwe issues op te lossen, die voorkomen wanneer de programmeurs de implementatie gaan doen, zonder al die oude open issues ook nog te moeten oplossen, waarvan je vroeger al wist en toen had kunnen oplossen. Daarbij, de manier van oplossen van een niet triviale open issue kan een grote impakt hebben op de manier waarop de code geschreven gaat worden.)

Notities. Denk, terwijl je de spec schrijft, aan de verschillende doelgroepen: programmeurs, testers, marketing, technische schrijvers, etc.  Als je de spec schrijft denk je wellicht aan nuttige feiten en feitjes die behulpzaam kunnen zijn voor één van deze groepen. Ik beschrijf, bijvoorbeeld, enkele techische implementatie-details als "Technische Notities". Marketing mensen negeren deze. Programmeurs houden hiervan. Mijn specs zitten tjokvol met "Test Notities", "Marketing Notities" en "Documentatie Notities".

Specs zijn levend. Sommige programmeer-team gebruiken een "waterval" mentaliteit: we ontwerpen het programma in eens, schrijven een spec, drukken die af, gooien die naar de programmeurs en we gaan naar huis. Al wat ik hierop kan zeggen is "Ha ha ha ha ha ha ha ha!"

Deze aanpak is de reden dat specs zo'n slechte reputatie hebben. Veel mensen hebben tegen me gezegd: "specs zijn waardeloos, niemand volgt ze, ze zijn altijd te oud, ze beschrijven nooit het produkt."

Pardon? Misschien zijn jouw specs te oud en beschrijven ze het produkt niet. Mijn specs worden vaak bijgewerkt. Het bijwerken gaat voort als het produkt is ontwikkelt en nieuwe beslissingen worden gemaakt. De spec zal altijd ons gezamelijk begrip reflecteren hoe het produkt zal werken. De spec zal enkel bevroren worden op het moment dat het produkt code-compleet is (dus wanner alle functionaliteit beschikbaar is, maar er nog test en debugging werk te doen is.)

Om ieders werk te vergemakkelijken breng ik niet dagelijks een nieuwe versie uit. Gewoonlijk heb ik een bijgewerkte versie op een of andere server zodat het team die als referentie kan gebruiken. Bij milestones druk ik een kopie af van de spec, met revisie-markeringen zo dat de mensen niet alles moeten herlezen -- ze kunnen aan de revisie-markeringen zien welke veranderingen er gemaakt zijn.

Wie moet die specs nu schrijven? Lees er alles over in deel 3.



De originele versie van dit artikel verscheen in het Engels onder de naam Painless Software Specifications Part 2  

Joel Spolsky is de oprichter van Fog Creek Software, een klein softwarebedrijf in New York. Hij studeerde af aan de Yale universiteit, en heeft als programmeur en manager gewerkt bij Microsoft, Viacom en Juno.


De inhoud van deze pagina's vertegenwoordigt de mening van één persoon.
Alle inhoud Copyright ©1999-2005 door Joel Spolsky. Alle rechten voorbehouden.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky