Andre, als je dit vertaalt naar disciplines dan is eerst de discipline Business process modelling aan de slag. In een goed project of juist voordat een goed project start zijn de gewenste processen uitgewerkt en de te automatiseren onderdelen in kaart gebracht. Dit wordt in samenwerking met andere disciplines uitgevoerd die zich aan de voorkant bevinden zoals programmamanagement en enterprise architectuur.
 
In het project heb je in moderne software ontwikkelingen geen FO's meer. Je constatering is ook correct: Voordat je aan de schermen begint werk je eerst een Use Case Model (het wat) uit waarin de actoren en activiteiten van die actoren op het systeem in kaart worden gebracht. Use cases worden nog verder gespecificeerd met o.a. activity diagrams, ook een soort processen, maar dan op gedetailleerder level. Dan gaat een software architect/analist aan de slag met het Analyse Model (het hoe). Hierin worden de use case specificaties vertaald daar software componenten. Bijvoorbeeld webservices en schermen. Dus dan pas komen de schermen aan bod. Deze drie modellen worden enigszinds gelijktijdig ontwikkeld maar wel in de genoemde afhankelijkheden. Alles kan je dan nog iteratief doen of in waterval.
 
Dus resume: Ja, ben eens met de stelling, en binnen moderne software ontwikkeling is hier volgens mij ook een goede andere werkwijze voor om daadwerkelijk op te leveren wat door de business wordt gevraagd.

Goed punt. FO bestaat nu een jaar of 40-45 en er zijn inderdaad alternatieven mogelijk. Ook in Nederland zijn daar al oplossingen voor. Waarbij inderdaad de business centraal staat. Ik sta open om elkaar eens te ontmoeten.

What's in a name?
Het nut van een functioneel ontwerp is dat je in meer functionele termen met je (interne of externe) klant / opdrachtgever kunt praten over wat je nu gaat ontwikkelen. En technisch ontwerp is vaak dusdanig technisch en gedetailleerd dat dit onleesbaar is voor de klant / eindgebruiker. Dat is immers geen IT-er.
Dat in de loop van de tijd de inhoud van een FO en de wijze waarop deze tot stand komt verandert, is logisch. We zijn immers (gelukkig) een vakgebied dat zich ontwikkeld en aanpast aan veranderde omstandigheden en nieuwe inzichten.
 
Om meteen te stellen dat het FO niet bijdraagt aan een betere oplossing is alleen naar mijn idee gevaarlijk. Je loopt het risico dat veel IT-ers voor wie het denken in business termen een uitdaging is, nu denken geen FO meer te hoeven maken en alleen in voor de business onbegrijpelijke technische termen een oplossing beschrijven. Op enig moment in het project zal er echter overeenstemming moeten zijn tussen business en IT over wat er moet worden gerealiseerd. Dat kan alleen in voor de business begrijpelijke termen. Ter ondersteuning van deze afstemming is een document bedacht met de naam functioneel ontwerp. Dat we met voortschrijdend inzicht er achter zijn gekomen dat dit FO beter op een andere manier tot stand kan komen, wil niet zeggen dat de bijdrage van een FO aan een goede oplossing ter discussie moet worden gesteld. Ik ben het eens met de geconstateerde tekortkomingen, de te snel gemaakte keuzes en het nut van bijvoorbeeld use cases. Maar om meteen te stellen dat het FO geen bijdrage levert aan de kwaliteit van de oplossing gaat wat ver.
 
De kwaliteit van de oplossing wordt naar mijn idee namelijk niet bepaald door een FO (dat eigenlijk alleen de functionele beschrijving van de oplossing is), maar meer door het samenspel van IT en business bij het vaststellen hoe business processen het beste kunnen worden verbeterd en al dan niet kunnen worden ondersteund met IT. In een te vroeg stadium keuzes maken die beperkend werken, zegt meer iets over de tekortkomingen in dat proces dan over het nut van een FO. Het FO is en blijft volgens mij nog steeds een onmisbaar middel om gedurende het project afstemming te krijgen tussen business en IT over de op te leveren functionaliteit. Het proces om tot een FO te komen is helaas echter in de praktijk nog voor veel verbetering vatbaar, getuige de voorbeelden in het artikel van André.

De stelling dat detaillistische ontwerpen beperkend werken is te boud: in de agile projecten die ik doe werkt het juist vaak heel erg verhelderend om deze tegen gebruikers aan te houden. Al die modellen en diagrammen zegt hen juist niks. Dat geldt vaak ook voor het FO: een brij aan tekst die -alles bij elkaar- zo veel informatie bevat dat "nee" zeggen moeilijk is en "ja" zeggen leidt tt onaangename verrassingen in de acceptatietest.
Ik zou voorstellen dat we niet weer een model, methode of aanpak gaan hanteren om betere software te realiseren, maar vooral dicht tegen eindgebruikers aan gaan zitten en onze communicatie op de ontvanger afstemmen in plaats van andersom.

Ik ben het op een aantal vlakken eens met André, maar zeker niet met zijn conclusies. Ik onderschrijf de reactie van Rick en Anko dat een FO een belangrijke stap is om vanuit de business over te gaan naar de techniek. Dat er verkeerde FO's geschreven worden is helder, maar om dan daarmee meteen de hele stap overboord te zetten is wat te drastisch.
 
Ik las het artikel met interesse en toen ik las dat André voorstelt een stap terug te doen, dacht ik: eindelijk. Yes. Weer iemand die het begrijpt. Maar helaas pakt de schrijver nog niet ver genoeg terug. Natuurlijk moet je het geheel beschouwen. Maar ook dat brengt je niet bij de kern. Veranderen doe je niet voor de lol. Je wil iets bereiken! Iets dat je zonder de verandering niet zou bereiken. Daar ligt dus de kern van het terug stappen: Waarom moet er veranderd worden? Wat is dan het doel van de business en waarom wordt dat niet bereikt? De grootste belemmering in het bereiken van het doel is het grootste probleem van de organisatie en dat moet je opruimen.
Het FO is het de beschrijven van de oplossing op dat probleem. En dat is een onmisbare stap in elk project!

@Anko Tijman
Ben het helemaal met je eens. Juist de User Centered Design methode is volgens mij de juiste manier tegenwoordig. Een vroege en continue focus op de (eind)gebruikers en hun taken, emperische metingen van het gedrag en iteratief design.