In de probleemstelling is het doel van het project in één zin beschreven. We nemen als voorbeeld de probleemstelling voor de terrasjesapp van caféketen “het bolleke”. Deze luidt:
“Ontwerp een interactief systeem waarmee klanten van “het bolleke” vanaf het terras zelf een bestelling kunnen plaatsen.”
Nadat duidelijk is welke taken het systeem moet gaan uitvoeren en wie de gebruikers zijn, kan een programma van eisen worden opgesteld. Deze eisen worden geformuleerd in de zogenaamde requirements. De eisen kunnen worden onderverdeeld in functionele en niet-functionele eisen. Een functionele eis geeft gewenst gedrag van het systeem weer, terwijl niet-functionele eis een kwaliteitseis is waaraan het systeem moet voldoen. Een niet-functioneel requirement is bijvoorbeeld dat de app onder zowel IOS als Android moet kunnen werken. Onze aandacht gaat vooral uit naar de functionele eisen. Dat zijn de eisen die gesteld worden aan de taken van het systeem en die zijn gebaseerd op het al eerder besproken gebruikersprofiel.
Hieronder zie je een overzicht van de requirements voor de terrasjesapp:
Doelen/eisen worden vaak te vaag en vrijblijvend geformuleerd. Een eis dat het systeem moet beschikken over een gebruiksvriendelijke interface is een goed voornemen, maar hoe wordt dat gemeten. Over wat een gebruiksvriendelijke interface is, verschillen de meningen. Requirements waarin wensen, intenties of goede voornemens staan, zijn daarom geen goede requirements. Er moet vastgesteld kunnen worden welk resultaat wanneer wordt bereikt. Dat kan door het SMART formuleren van doelen/eisen. SMART staat voor:
Het programma van eisen is opgesteld op grond van een gesprek tussen de eigenaar van caféketen “het bolleke” en de ontwerper. Het zou kunnen dat na het testen van het prototype door een groep geselecteerde klanten de requirements aangevuld worden. Voor nu geven ze een goed beeld van welke afspraken er gemaakt zijn tussen de eigenaar en de ontwerper.