Hoofdstuk 6
Software requirements
INTRODUCTIE
Belangrijk in dit hoofdstuk is het onderscheid tussen functionele en nietfunctionele eisen, en ook het onderscheid tussen gebruikerseisen (user requirements) en systeemeisen (system requirements). Functionele eisen beschrijven de diensten die het systeem aan de gebruiker levert. Niet-functionele eisen zijn randvoorwaarden daaraan, zoals snelheid en betrouwbaarheid. Gebruikerseisen beschrijven welke diensten het systeem de gebruiker verstrekt en aan welke randvoorwaarden het moet voldoen. Deze moeten volledig zijn, maar niet al te gedetailleerd. Ze moeten ook voor niet-technici goed te begrijpen zijn. Ze worden geformuleerd in (eventueel gestructureerde) natuurlijke taal, aangevuld met figuren en diagrammen. Systeemeisen zijn een gedetailleerde uitwerking van de gebruikerseisen. Deze moeten volledig zijn en geen ruimte laten voor misverstanden. Ze worden opgesteld in gestructureerde natuurlijke taal, in een speciale specificatietaal of grafische notatie, of met behulp van een wiskundig formalisme. Een specificatietaal kan ook een wiskundig formalisme zijn. LEERDOELEN
Na het bestuderen van dit hoofdstuk wordt verwacht dat u − het verschil weet tussen functionele en niet-functionele eisen – weet wat domeineisen zijn en hoe die zich verhouden tot functionele en niet-functionele eisen – drie soorten niet-functionele eisen kunt noemen en van elke soort ten minste twee voorbeelden kunt geven – in een gegeven specificatie functionele en niet-functionele eisen kunt onderscheiden – het verschil weet tussen gebruikerseisen, systeemeisen en een ontwerpspecificatie – onvolledigheden, dubbelzinnigheden en tegenstrijdigheden herkent in een eenvoudige specificatie in (semi-)natuurlijke taal – gebruikerseisen voor een eenvoudig systeem kunt opstellen in gestructureerde natuurlijke taal – kunt uitleggen wat wordt verstaan onder specificatie van de benodigde interfaces, en drie typen van deze interfaces kunt noemen – weet uit welke onderdelen een specificatiedocument bestaat.
OUN
49
Software engineering
LEERKERN 6.1
Functional and non-functional requirements
Domeineisen (domain requirements) worden in paragraaf 6.1.3 (bladzijde 125) besproken. Het gaat hier om extern opgelegde eisen, die voor de gebruiker van het systeem niet direct van belang zijn. De opsomming in het begin van paragraaf 6.1 is ongelukkig, omdat deze wederzijdse uitsluiting suggereert, terwijl domeineisen zowel functioneel als niet-functioneel kunnen zijn. 6.1.2
NON-FUNCTIONAL REQUIREMENTS
bladzijde 122
Figure 6.3 bevat termen die mogelijk onbekend zijn.
Usability
– Usability is gebruiksvriendelijkheid. Het gaat daarbij bijvoorbeeld om de tijd die het kost om met het systeem om te leren gaan, om hoe goed het gebruikersfouten opvangt en hoe makkelijk het aan te passen is aan de stijl van werken van een individuele gebruiker. – Portability is overdraagbaarheid. Een systeem is overdraagbaar wanneer het in verschillende omgevingen kan draaien, dus bijvoorbeeld onder verschillende bedrijfssystemen of op verschillende soorten hardware. – Interoperability duidt aan in hoeverre een systeem kan samenwerken met andere systemen. Voorbeelden zijn de mogelijkheid om in een tekstverwerker illustraties te importeren die met een ander pakket gemaakt zijn, of in een programmeertaal code (bijvoorbeeld procedures of klassen) te gebruiken die in een andere taal zijn geschreven.
Portability
Interoperability
Een bekend voorbeeld van software waaraan om juridische redenen een externe (domein)eis werd gesteld, is LimeWire. Met dit programma kunnen gebruikers muziekbestanden van elkaar kopiëren. De voorganger Napster gebruikte een centrale server om te registreren welke bestanden op een bepaald moment beschikbaar waren; deze centrale registratie werd in een reeks processen voor de meeste muziek onwettig verklaard. De opvolger moest dus zo worden ontworpen dat ook die registratie decentraal verliep. Over de ethische kant hiervan is natuurlijk ook veel te zeggen (en ook veel gezegd). De precieze betekenis van de maatstaven voor betrouwbaarheid uit figure 6.6 vindt u op bladzijde 209 van het tekstboek (figure 9.10). 6.1.3 bladzijden 125-126
50
DOMAIN REQUIREMENTS
Welke (functionele of niet-functionele) eisen nu precies domeineisen genoemd kunnen worden, ligt niet eenduidig vast. We noemden hiervoor al het voorbeeld van LimeWire; de afwezigheid van een centrale server is duidelijk een domeineis. Het voorgeschreven gebruik van een programmeertaal door de klant, omdat die taal standaard is binnen de eigen organisatie is geen domeineis maar een niet-functionele implementatie-eis. Een domeineis geldt dus voor het hele domein, niet voor een enkel bedrijf of project in het domein.
OUN
Hoofdstuk 6 Software requirements
Het voorbeeld uit figure 6.7 is echter minder duidelijk. Volgens Sommerville is dit een domeineis, maar met even veel recht is deze berekeningswijze helemaal geen eis te noemen, maar gewoon een definitie van de term vertraging. Iedere domeinspecifieke applicatie heeft een lijst van termen met hun betekenissen binnen dat domein. OPGAVE 6.1
Maak exercise 6.3 uit het tekstboek. Het personal identification number is de pincode van de pas. 6.2
User requirements
OPGAVE 6.2
Waarom pleit Sommerville voor het gebruik van natuurlijke taal bij user requirements terwijl daar toch zoveel bezwaren aan kleven? bladzijde 128 punt 2
Sommerville noemt de eis dat de maatgeving voor een rooster zowel in centimeters als in inches getoond kan worden, een niet-functionele eis. Dat is onterecht. Het is weliswaar een detail dat mogelijk niet thuis hoort in de gebruikerseisen, maar het betreft een aspect van een geboden dienst en is dus wel degelijk een functionele eis.
OPGAVE 6.3
Maak exercise 6.4 uit het tekstboek. 6.3
System requirements
OPGAVE 6.4
Wat is de dubbelzinnigheid in ‘Shoes must be worn; dogs must be carried’?
ZELFTOETS
1
Leg uit wat het verschil is tussen gebruikerseisen en systeemeisen.
2
Maak exercise 6.7 uit het tekstboek.
3
Een bedrijf ontwikkelt een nieuw soort polshorloge, dat ook bij de overgang van een tijdzone de juiste tijd blijft aangeven. Enkele eisen aan dit systeem zijn de volgende. 1 Het horloge past de getoonde tijd en datum zelf aan bij het overschrijden van tijdzones en zo nodig ook bij het overschrijden van landsgrenzen (in verband met eventueel hanteren van een verschil tussen zomer- en wintertijd). 2 De nauwkeurigheid van de plaatsbepaling is dezelfde als die van GPS, namelijk met een mogelijke afwijking van ongeveer 30 meter. 3 Het horloge maakt gebruik van GPS om vast te stellen waar het zich bevindt. 4 Het beschikt zelf over de nodige gegevens om deze positie om te zetten in een tijdzone.
OUN
51
Software engineering
5 Het horloge heeft een levensduur van ongeveer vijf jaar. 6 De benodigde software wordt ontwikkeld in Java, in overeenstemming met bedrijfspolitiek. a Welke van deze eisen zijn functioneel en welke zijn niet-functioneel? b Van welk type zijn de niet-functionele eisen?
52
4
a Wat wordt in dit hoofdstuk verstaan onder specificatie van de benodigde interfaces? b Welke drie soorten van dergelijke interfaces kent u? c Bij het schrijven van Java-programma’s maakt u veelvuldig gebruik van bestaande klassen. Van welk type zijn de interfaces van deze bestaande componenten en hoe zijn ze gedefinieerd?
5
a Welke partijen die betrokken zijn bij de ontwikkeling van software, gebruiken het eisendocument en voor welk doel? b Noem tenminste zes onderdelen van een dergelijk document.
OUN
Hoofdstuk 6 Software requirements
TERUGKOPPELING 1
6.1
Uitwerking van de opgaven
Solution 6.3 Ambiguities and omissions include: – Can a customer buy several tickets for the same destination together or must they be bought one at a time? – Can customers cancel a request if a mistake has been made? – How should the system respond if an invalid card is input? – What happens if customers try to put their card in before selecting a destination (as they would in ATM machines)? – Must the user press the start button again if they wish to buy another ticket to a different destination? – Should the system only sell tickets between the station where the machine is situated and direct connections or should it include all possible destinations? Als we uitgaan van de Nederlandse situatie, is er in elk geval nog één onduidelijkheid, namelijk welke kaartsoorten er gekocht kunnen worden (alleen enkele reis en retour, of ook railrunners, fietskaarten, weekendretours en dergelijke; alleen tweede klas of ook eerste klas, met of zonder korting).
6.2
Gebruikerseisen zijn onder meer bedoeld voor eindgebruikers en managers van de klantorganisatie. Daarvan kan niet verwacht worden dat ze een formele specificatie kunnen lezen.
6.3
Een mogelijke uitwerking is de volgende (deze specificatie is gebaseerd op de werking van de NS-kaartautomaten met touch-screen). Op de website van de NS vinden we (2008) de volgende informatie voor reizigers:
Uitleg bij de kaartautomaat met aanraakscherm Door het volgen van onderstaande stappen, bemachtigt u binnen een minuut een kaartje bij de snelle kaartautomaat met aanraakscherm. Hieronder vindt u een korte uitleg over het gebruik van de kaartautomaat met aanraakscherm. U maakt uw keuze door de bestemming of kaartsoort op het scherm aan te raken. In 3 stappen heeft u de beschikking over het door u gewenste kaartje: 1. Raak uw keuze op het scherm aan. 2. Voer PINpas of Chipknip in 3. Pak kaartje / kaartjes uit bakje. Nader uitgewerkt: 1. U kiest voor ‘Enkele reis’, ‘Dagretour’, 5-Retourkaart’, ‘Weekendretour’ of ’Railrunner’. Als u opteert voor ‘Overige kaartjes’ (linksonder in de hoek) verschijnen de kaartsoorten: ‘Dagkaarten’, ‘Treintaxi’, Maandkaarten’, ‘ICE Toeslag’ en ‘Overgangsbewijzen 2- 1’ op uw scherm. U kunt ook een kaartje kopen bij deze kaartautomaat naar populaire bestemmingen in België / Luxemburg / Frankrijk en Duitsland.
OUN
53
Software engineering
Voor de kaartsoorten ‘Enkele reis’, ‘Dagretour’, ’Weekendretour’, 5-Retourkaart’ en ‘Maandtrajectkaarten’ geldt dat u onderstaande stappen dient te doorlopen. 2. Raak de eerste letter aan van uw bestemming en kies nog een tweede letter als dit wordt aangegeven. 3. Kies uw bestemming door deze aan te raken op het scherm. 4. Maak een keuze uit eerste of tweede klas (met uitzondering van ‘Jeugdmaandtrajectkaart’) 5. Kies ‘Vol tarief’ of ‘Met korting’ (met uitzondering van ‘Maandtrajectkaarten’) 6. Kies reisdatum (vandaag of zonder datum). 7. Kies hoeveel kaartjes u wilt (met een maximum van vier kaartjes - met uitzondering van ‘Maandkaarten’). 8. Kies hoe u wilt betalen (snel en veilig met PINpas of Chipknip). 9. Voer uw betaalpas in een volg de instructies op het betaalschermpje. 10. Neem uw kaartje(s) uit het bakje. Heeft u op het scherm gekozen voor de kaartsoort ‘Dagkaart fiets’, ‘Dagkaart hond’, ‘ICE Toeslag’, ‘Railrunner’of ’Treintaxi’ dan doorloopt u de stappen: 6 tot en met 10. Heeft u op het scherm gekozen voor de kaartsoort ‘Overgangsbewijzen 2- 1’: - keuzedag 60+, dan doorloopt u de stappen: 7 tot en met 10 - dagkaart, dan doorloopt u de stappen: 5 tot en met 10 - enkele reis of retour, dan doorloopt u de stappen: 2 tot en met 10 Heeft u op het scherm gekozen voor één van de overige ’Dagkaarten’ dan doorloopt u de stappen: 4 tot en met 10.
(Bron: http://www.ns.nl, 2008)
Uitwerking van de specificatie: 1 Kaartautomaat voor de spoorwegen 1.1 Het systeem verkoopt de meest courante kaartsoorten voor alle bestemmingen binnen Nederland; de klant betaalt met een pinpas. 1.2 Een geslaagde kaartverkoop verloopt als volgt: 1 De klant start de transactie door een kaartsoort te kiezen. 2 De klant selecteert een bestemming. 3 De klant selecteert een klasse (eerste of tweede klas) . 4 De klant geeft aan of gereisd wordt met korting. 5 De klant kiest de reisdatum. 6 De klant kiest het aantal kaartjes. 7 De klant kiest de betalingswijze. 8 De klant voert een pas in. 9 De klant voert een pincode in. 10 De klant bevestigt de opdracht, en neemt de pas uit. 11 Het kaartje wordt gedrukt en uitgegeven. 1.3 Tot en met stap 8 kan de klant de transactie op ieder moment onderbreken door een foutknop in te drukken; het systeem keert dan terug naar de begintoestand. 1.4 Als de klant tijdens de eerste vijf stappen gedurende dertig seconden geen invoer geeft, wordt de transactie onderbroken en keert het systeem terug naar de begintoestand. 1.5 Als de klant een ongeldige pas invoert, wordt dit gemeld, wordt de klant gemaand de pas terug te nemen en keert het systeem terug naar de begintoestand. 1.6 Als de klant een ongeldige pincode invoert, krijgt deze twee keer de gelegenheid om dit te herstellen. Bij een derde foutieve invoer wordt de pas ingenomen. Het systeem meldt dat de pas is ingenomen wegens driemaal invoeren van een foute pincode en keert terug naar de begintoestand.
Voor de andere kaartsoorten (zie na punt 10 van de NS-tekst) kunnen alternatieve specificaties opgesteld worden.
54
OUN
Hoofdstuk 6 Software requirements
6.4
De formulering laat in het midden wat nu precies de verplichting is. Men moet altijd schoenen aan hebben, maar men hoeft niet altijd een hond bij zich te hebben! 2
Uitwerking van de zelftoets
1
Zie bladzijde 118 van het tekstboek.
2
Solution 6.7 There are many possibilities here. Some suggestions are shown in Table 6.1. TABLE 6.1
Non-functional requirements
Non-functional requirement
Description
Examples
Performance
Performance requirements set out limits to the performance expected of the system. These may be expressed in different ways depending on the type of system e.g. number of transactions processed per second, response time to user requests, etc.
The system must process at least 150 transactions per second.
Defines specific standards or methods which must be used in the development process for the system.
The system design must be developed using an objectoriented approach based on the UML process.
Implementation
The maximum response time for any user request should be 2 seconds.
The system must be implemented in C++, Version 3.0. Usability
Defines requirements which relate to the usability of the system by end-users.
All operations which are potentially destructive must include an undo facility which allows users to reverse their action. (This is an example of a functional requirement which is associated with a non-functional requirement) All operations which are
potentially destructive must be highlighted in red in the system user interface. Safety
3
Safety requirements are concerned with the overall safe operation of the system.
The system must be certified according to Health and Safety Regulations XYZ 123.
a Eisen 1, 3 en 4 zijn functionele eisen; de andere eisen zijn nietfunctioneel. b Eisen 2 en 5 zijn producteisen. Eis 2 is een performance-eis. Eis 5 past niet goed in de classificatie van figure 6.3; dat komt omdat het beschouwde horloge een volledig systeem is dat uit meer dan software bestaat. Eis 6 is een implementatie-eis.
OUN
55
Software engineering
56
4
a Het gaat hier om de interfaces van bestaande systemen waar het nieuw te bouwen systeem mee samen moet werken, en dus niet om gebruikersinterfaces. b Zie bladzijde 135 van het tekstboek. c Dit zijn procedurele interfaces; ze zijn gespecificeerd in de APIspecificaties.
5
a Zie figure 6.16 op bladzijde 137 van het tekstboek. b Zie bladzijde 139 van het tekstboek.
OUN
