Bij het ontwikkelen van een systeem is het nodig om het totaalbeeld te behouden. Zonder dit totaalbeeld is het onmogelijk om de juiste keuzes te maken of het project nu groot of klein is. Beslissingen zijn bijvoorbeeld nodig om niet het budget te overschrijden, om een bepaalde deadline te behalen of om te bepalen wat de kern is van het systeem. Bij het maken van dit overzicht worden lang niet alle requirements in kaart gebracht. Het use case diagram is een prima methode om dit overzicht te verkrijgen. Het toont de requirements van een systeem op hoofdlijnen.
Scope
Ook met het use case diagram blijft het moeilijk om de scope van een systeem en het project te beheren. Met de scope bepalen we de omvang van wat er ontworpen wordt in tegenstelling tot een bestaand ontwerp of het beeld van dit ontwerp van een andere ontwerper. Scope discussies zijn altijd lastig, dit zal iedere ontwerper bevestigen. Toch bestaan er goede middelen om de scope discussies te beperken in een project. Een voorbeeld hiervan is de binnen/buiten scope lijst beschreven door Alistar Cockburn (afkomstig van Rob Thomsett).
De binnen/buiten scope lijst bestaat uit drie kolommen waar de eerste kolom kort het onderwerp beschijft. De tweede kolom geeft aan of het onderwerp binnen scope van het project is. De derde kolom geeft aan of het onderwerp buiten de scope van het project valt.
Ieder keer dat een discussie dreigt af te wijken van het onderwerp wordt de lijst aangevuld met het afwijkende onderwerp. Er wordt aan de stakeholders gevraagd of het onderwerp binnen of buiten de scope hoort.
Functionele scope
De functionele scope refereert naar de diensten en processen die het te ontwerpen systeem ondersteund die worden behandeld in de use cases. Deze scope wordt op het zelfde moment ingevuld als het vinden van de use cases. De binnen/buiten scope lijst helpt al tijdens dit proces. Een andere goede tool is de actor/doel lijst. Deze lijst toont alleen de diensten en processen van het systeem die binnen de scope vallen.
De actor/doel lijst heeft vier kolommen. De eerste kolom bevat de primaire actor. Deze actor hebben de doelstelling die in de tweede kolom wordt opgenomen. Zorg dat deze doelstelling kort en krachtig is. Vaak is een werkwoord en een zelfstandig naamwoord voldoende. De derde kolom bevat de business waarde vanuit de stakeholders. Dit kan een getal zijn van 1 tot 5. De vierde kolom is de complexiteit die wordt bepaald door het ontwikkelteam. Ook dit is een getal van 1 tot 5.
De actor/doel lijst toont alleen de diensten en processen van het systeem die binnen de scope vallen.
Deze actor/doel lijst helpt tijdens de discussie met de stakeholders. Als het budget beperkt is zullen niet alle doelen in een keer kunnen worden gehaald binnen dit budget. Ook al zou er onbeperkt budget zijn is het goed om te bepalen welke doelen als eerte behaald moeten worden. Zo zullen doelen met een hoge business waarde en een lage complexiteit als eerste ontwikkeld kunnen worden.
Use case diagram
Nu duidelijk is geworden wat binnen en buiten de scope valt, en wat de doelen zijn van de diverse actoren kan het use case diagram worden opgemaakt. Dit diagram biedt het overzicht tijdens het project en is een goede methode om stakeholders te wijzen op de afgesproken functionele scope. Iedere discussie die tijdens het project volgt kan worden getoetst aan het use case diagram. Wel is het goed om discussies in zekere mate te documenteren met bijvoorbeeld de binnen/buiten scope lijst. Deze kunnen helpen om de toekomst van het systeem te bepalen. Naar alle waarschijnlijkheid volgt er na de afronding van het project namelijk een tweede versie of uitbreiding van het systeem.