Hoewel het lijkt alsof er tegenwoordig alleen nog met UML wordt gemodelleerd is dit zeker niet het geval, de
op dataflow gebaseerde methoden (zoals bijvoorbeeld Hatley & Pirbhai, Ward & Mellor, Yourdon) bieden een eenvoudiger
manier van werken en zijn vaak beter begrijpbaar voor de verschillende stake-holders. Zeker voor process georiënteerde
projecten met relatief weinig persistente data zijn dataflow modellen vaak beter bruiker dan OO methoden.
Met de methode van Hatley & Pirbhai wordt een systeem specificatie gemaakt. Deze op te leveren beschrijving bestaat
voornamelijk uit dataflow en controlflow diagrammen; deze diagrammen bieden een eenvoudig te interpreteren
beschrijving zowel door de ontwikkelaar als door de opdrachtgever.
Het specificeren van een systeem gebeurt
door een probleem steeds te decomponeren in kleinere en eenvoudiger deelproblemen. Dit decomponeren gaat
door tot er kleine en begrijpelijke probleembeschrijvingen overblijven. De methode van Hatley & Pirbhai
biedt hierbij ondersteuning door een controle op consistentie en volledigheid, tevens worden alle
diagrammen automatisch geïndexeerd.
Het logische systeemmodel (WAT het systeem doet) wordt beschreven in het Requirements model. De allocatie
van het requirements model in een fysieke omgeving wordt vastgelegd in het Architecture model. Requirements
en Architecture model tezamen wordt het System specification model genoemd.
Uitgaande van het system specificatie model wordt een software-ontwerp gemaakt. De processen, zoals die
binnen de analyse fase naar voren zijn gekomen, worden hiertoe ondergebracht binnen taken, deze worden
door het computersysteem daadwerkelijk uitgevoerd.
In het architecture model worden de fysieke entiteiten waaruit het systeem bestaat beschreven, en er
wordt in vastgelegd hoe deze entiteiten met elkaar verbonden zijn. In het architecture model worden
niet-functionele specificaties vastgelegd. Dit zijn de randvoorwaarden waaraan het systeem moet
voldoen.
Niet-functionele eisen zijn bijvoorbeeld:
- Het soort communicatie medium dat naar de devices toe gebruikt wordt (Profibus o.i.d.).
- De gebruikte hardware en de betrouwbaarheidseisen welke hieraan gesteld worden (bijv. het systeem werkt op een Simatic S7-300 PLC, 384KByte intern geheugen, de MTBF is 10000 uur).
- De uitvoering van de user interface (bijv. of dit een toetsenbord is, een schakelpaneel of een aanraakscherm).
Algemeen kan over de methode worden gesteld dat deze de mogelijkheid biedt om problemen abstract te bekijken. Op elk niveau
worden alle onderliggende details afgeschermd. Problemen worden op elk niveau gescheiden in kleinere en zoveel mogelijk van
elkaar onafhankelijke deelproblemen. Op elk niveau biedt het model een overzicht van het systeem of deelsysteem. Dit kan
dan als praatstuk dienen voor overleg met de stake-holders. Abstractie en scheiding der zaken staan centraal binnen de methode.
De methode van Hatley & Pirbhai is semi-formeel. Bij een formele methode ligt alles eenduidig vast, en deze beschrijving
kan slechts op één manier geïnterpreteerd worden. Bij een formele methode zijn de gehele woordenlijst, de syntax en
de semantiek gedefinieerd. Met een formele methode kunnen correctheidsbewijzen geleverd worden en kan automatisch code
gegenereerd worden. Tegenover de formele methode staat de informele: een beschrijving in slechts natuurlijke taal. Controle
op compleetheid en consistentie is hierbij nauwelijks mogelijk. De methode van Hatley & Pirbhai ligt hier tussenin. Er zijn
vaste regels voor het opstellen van de diagrammen, de PSPEC's etc. Het volgen van deze voorschriften geeft een consistent en
compleet geheel.
De methode ondersteunt de belangrijkste software-engineering principes: rigoreusheid, scheiding der zaken, modulariteit,
abstractie, veranderingsgerichtheid en stapsgewijze oplevering. Het resultaat van de analyse is een volledig gedocumenteerde
beschrijving van het systeem. Deze beschrijving dient als leidraad tijdens het software-ontwerp, de implementatie en
de maintenance fase.