Software vereisten. Het opstellen van de vereisten

Transcriptie

1 Software vereisten Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 1 Het opstellen van de vereisten Het proces van het tot stand brengen van de services die de klant vraagt van een systeem en de beperkingen waaraan het is onderworpen. De vereisten zelf zijn beschrijvingen van de systeem services en de beperkingen en verplichtingen. Ze worden gegenereerd tijdens het vereisten engineering process. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 2

2 Wat is een software vereiste? Kan varieren van een abstracte beschrijving van een service tot een gedetailleerde mathematishe functionele specificatie. Vereisten kunnen dienen als basis voor een prijsofferte als voor het contract zelf Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 3 Types van vereisten User vereisten Een uiteenzetting in natuurlijke taal samen met diagrammen van de services die het systeem voorziet en zijn operationele beperkingen. Wordt geschreven voor klanten. Systeem vereisten Een gestructureerd document met gedetailleerde beschrijvingen van de systeemfuncties, services en operationele beperkingen. Het definieert wat moet geïmplementeerd worden en kan deel uitmaken van een contract tussen klant en softwarehuis. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 4

3 Voor wie bestemd? Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 5 Functionele en niet-functionele vereisten Functionele vereisten Omschrijvingen van services die het systeem moet voorzien, hoe het systeem moet reageren op bepaalde ingevoerde gegevens en hoe het systeem zich dient te gedragen in specifieke situaties. Niet-functionele vereisten Beperkingen op de diensten of functies aangeboden door het systeem zoals tijdsbeperkingen, wettelijke verplichtingen, standaarden, etc. Domein vereisten Vereisten afkomstig van het toepassingsdomein van het systeem die karakteristieken van dat domein reflecteren. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 6

4 Het LIBSYS systeem Een bibliotheeksysteem dat een eenvoudige interface vooziet tot een aantal databases met artikels in verschillende bibliotheken. Gebruikers kunnen voor een persoonlijke studie artikels zoeken, downloaden en afdrukken. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 7 Voorbeelden van Functionele vereisten De gebruiker zal in de mogelijkheid zijn om te zoeken in het initiele set van alle databases of kan een subset ervan selecteren. Het systeem zal geschikte viewers voozien voor de gebruiker om de documenten te kunnen lezen. Aan ieder order zal een uniek nummer (ORDER_ID) worden toegekend dat de gebruiker zal kunnen kopieren naar de permanente opslagruimte van zijn account. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 8

5 Niet-functionele vereisten Deze definieren systeemeigenschappen en verplichtingen zoals betrouwbaarheid, responstijd en opslagvereisten. Beperkingen zijn de mogelijkheden van I/O devices etc. Proces vereisten kunnen ook gespecificeerd zijn door een specifiek CASE systeem te verplichten of een progammeertaal of een ontwikkelingsmethode. Niet-functional vereisten kunnen meer kritisch zijn dan functionele vereisten. Indien hieraan niet is voldaan, is het systeem waardeloos. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 9 Voorbeelden van niet-functionele vereisten Product vereisten 8.1 De user interface van LIBSYS zal worden geimplementeerd als eenvoudig HTML zonder frames of Java applets. Organisatorische vereisten Alle documenten van het ontwikkelingsproces zullen voldoen aan de normen beschreven in XYZCo-SP-STAN-95. Externe vereisten De gegevens over de klanten in het systeem opgeslagen, zullen voldoen aan de wet van 8 december 1992 betreffende de bescherming van de persoonlijke levenssfeer. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 10

6 Meetbare vereisten Property Speed Size Ease of use Reliability Robustness Portability Measure Processed transactions/second User/Event response time Screen refresh time M Bytes Number of ROM chips Training time Number of help frames Mean time to failure Probability of unavailability Rate of failure occurrence Availability Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Percentage of target dependent statements Number of target systems Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 11 Domein vereisten Zijn afgeleid van het toepassingsdomein en beschrijven systeem karakteristieken die verband houden met het domein. Domein vereisten kunnen nieuwe functionele vereisten zijn, beperkingen op bestaande vereisten. Als niet voldaan is aan de domein vereisten kan het systeem onbruikbaar zijn. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 12

7 Library system domein vereisten Er zal een standaard user interface zijn voor alle databases, gebaseerd op de Z39.50 standaard. Omwille van copyright beperkingen mogen sommige documenten door de gebruiker niet op electronische drager worden bewaard. Ze mogen wel worden afgedrukt op een lokale printer of naar een netwerk printer worden gestuurd. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 13 Vereisten beschreven voor de gebruiker Moeten functionele en niet functionele vereisten op een dergelijke manier voorstellen dat ze ook kunnen begrepen worden door gebruikers zonder grondige technische kennis. Gebruiker vereisten kunnen gedefinieerd worden in natuurlijke taal, tabellen en diagrammen die door alle gebruikers begepen worden. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 14

8 Problemen met natuurlijke taal Gebrek aan duidelijkheid Functionele en niet functionele vereisten worden door mekaar weergegeven Sommige vereisten kunnen onbewust worden samengevoegd. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 15 LIBSYS requirement 4..5 LIBSYS zal een financieel accounting systeem voorzien dat allen betalingen bijhoudt van de gebruikers van het systeem. Systeem managers kunnen dit systeem configureren zodat kortingen kunnen gegeven worden aan regelmatige gebruikers. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 16

9 Problemen met het opstellen van vereisten In het voorbeeld worden conceptuele database vereisten gemengd met gedetailleerde informatie Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 17 Richtlijnen voor het schrijven van vereisten Maak een standaard formaat dat gebruikt wordt voor de omschrijving van alle vereisten. Gebruik de taal op een consistente manier: Gebruik zal voor verplichte vereisten Gebruik kan voor vereisten die wenselijk zijn. Maak een opsplitsing tussen de verschillende delen van de vereisten. Vermijd het gebruik van computer jargon. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 18

10 Systeem vereisten Meer gedetailleerde specificaties van systeemfuncties, diensten en beperkingen dan de gebruiker vereisten. Ze worden beschouwd als een basis voor het systeemontwerp. Ze kunnen ingebouwd worden in het systeemcontract. Systeem vereisten kunnen geïllustreerd of gedefinieerd worden met systeemmodellen besproken in hoofdstuk 8. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 19 Vereisten vs ontwerp In principe, stellen vereisten WAT het systeem zou moeten DOEN en het ontwerp zou moeten beschrijven HOE dit zal gebeuren. In de praktijk zijn vereisten en ontwerp onafscheidbaar Een systeem architectuur kan ontworpen worden om de vereistentestructureren; De samenwerking van het systeem met andere systemen kan design vereisten genereren; Het gebruik van een specieke ontwerpmethode kan een domain vereiste zijn. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 20

11 Problemen met NL specificatie Ambigiteit Lezer en schrijver moeten de woorden op eenzelfde manier interpreteren. NL is van nature uit ambiguous zodat dit echt moeilijk is. Over-flexibiliteit Hetzelfde kan op verschillende manieren in een specificatie worden gezegd. Geen modularisatie NL structuren zijn niet geschikt om systeem vereisten te structureren. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 21 Alternatieven voor een specificatie in NL Notation Structured natural language Design description languages Graphical notations Mathematical specifications Description This approach depends on defining standard forms or templates to express the requirements specification. This approach uses a language like a programming language but with more abstract features to specify the requirements by defining an operational model of the system. This approach is not now widely used although it can be useful for interface specifications. A graphical language, supplemented by text annotations is used to define the functional requirements for the system. An early example of such a graphical language was SADT. Now, use-case descriptions and sequence d iagrams are commonly used. These are notations based on mathematical concepts such as finite-state machines or sets. These unambiguous specifications reduce the arguments between customer and contractor about system functionality. However, most customers don t understand formal specifications and are reluctant to accept it as a system contract. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 22

12 Specificaties in een gestructureerde taal Vrijheid van de opsteller van de vereisten wordt beperkt door een voorgedefinieerd template. Alle vereisten worden geschreven op een standaard wijze. De terminologie gebrukt in de beschrijving kan gelimiteerd worden. De voordelen van NL (uitdrukkingsvermogen) blift bewaard maar de specificatie wordt uniformer. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 23 Form-based specificaties Definitie van de functie of de entiteit. Beschrijving van de inputs en hun oorsprong. Beschrijving van de outputs en hun bestemming. Aanduiden van andere vereiste entiteiten. Pre en post condities (indien toepasbaar). Eventuele neveneffecten van de functie. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 24

13 Form-based node specificatie Insulin Pump/Control Software/SRS/3.3.2 Function Compute insulin dose: Safe sugar level Description Computes the dose of insulin to be delivered when the current measured sugar level is in the safe zone between 3 and 7 units. Inputs Current sugar reading (r2), the previous two readings (r0 and r1) Source Current sugar reading from sensor. Other readings from memory. Outputs CompDose Ğ the dose in insulin to be delivered Destination Main control loop Action: CompDose is zero if the sugar level is stable or falling or if the level is increasing but the rate of increase is decreasing. If the level is increasing and the rate of increase is increasing, then CompDose is computed by dividing the difference between the current sugar level and the previous level by 4 and rounding the result. If the result, is rounded to zero then CompDose is set to the minimum dose that can be delivered. Requires Pre-condition Post-condition Side-effects None Two previous readings so that the rate of change of sugar level can be computed. The insulin reservoir contains at least the maximum allowed single dose of insulin.. r0 is replaced by r1 then r1 is replaced by r2 Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 25 Specificatie met beslissingstabellen Gebruikt als supplement voor NL. Voornamelijk bruikbaar wanneer een aantal mogelijkheden moeten gedefinieerd worden. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 26

14 Tabular specification Condition Action Sugar level falling (r2 < r1) CompDose = 0 Sugar level stable (r2 = r1) CompDose = 0 Sugar level increasing and rate of increase decreasing ((r2-r1)<(r1-r0)) Sugar level increasing and rate of increase stable or increasing. ((r2-r1) (r1-r0)) CompDose = 0 CompDose = round ((r2-r1)/4) If rounded result = 0 then CompDose = MinimumDose Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 27 Grafische modellen Worden meestal gebruikt voor het beschrijven van toestoestandsveranderingen of voor het beschrijven van sequenties van acties. Verschillende grafische modellen worden uitgelegd in hoofdstuk 8. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 28

15 Sequentie diagrammen Tonen de opeenvolging van events die plaatsgrijpen tijdens de interactie van een gebruiker met het systeem. Het verloop in functie van de tijd gebeurt van links naar rechts en van boven naar beneden Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 29 Interface specificatie De meeste systemen moeten werken met andere systemen en de interfaces moeten worden gespecificeerd als deel van de vereisten. Er kunnen 3 types van interface worden gedefinieerd: Procedurele interfaces; Data structures die worden uitgewisseld; Voorstellingen van data. Formele notaties zijn een effectieve techniek voor interface specificatie. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 30

16 PDL interface description interface PrintServer { // defines an abstract printer server // requires: interface Printer, interface PrintDoc // provides: initialize, print, displayprintqueue, cancelprintjob, switchprinter void initialize ( Printer p ) ; void print ( Printer p, PrintDoc d ) ; void displayprintqueue ( Printer p ) ; void cancelprintjob (Printer p, PrintDoc d) ; void switchprinter (Printer p1, Printer p2, PrintDoc d) ; } //PrintServer Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 31 Het vereisten document Het vereisten document is het officiële (schriftelijk) rapport van wat vereist is van de systeem ontwikkelaars. Moet zowel een definitie van de gebruikers vereisten bevatten als een specificatie van de systeem vereisten Het is GEEN ontwerp document. Voor zover als mogelijk moet het stellen WAT het systeem moet doen eerder dan HOE dit moet gebeuren. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 32

17 Gebruikers van het vereisten document Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 33 IEEE vereisten standaard Definieert een generieke structuur voor een vereisten document dat moet worden aangemaakt voor elk specifiek systeem. Inleiding. Algemene omschrijving. Specifieke vereisten. Bijlagen. Index. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 34

18 Structuur van het vereisten document Voorwoord Inleiding Glossary Definitie van de gebruikers vereisten Systeem architectuur Systeem vereisten specificatie Systeem modellen Systeem evolutie Bijlagen Index Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 35 Key points Vereisten stellen wat het systeem moet doen en definieren beperkingen op de werking en de implementatie. Functionele vereisten stellen de services die het systeem moet voorzien. Niet-functionele vereisten leggen verplichtingen op aan het te ontwikkelen systeem of aan het ontwikkelings proces. Gebruiker vereisten beschrijven op een algemeen niveau wat het systeem moet doen. Ze worden beschreven in NL, tabellen en diagrammen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 36

19 Key points Systeem vereisten moeten de functies vermelden die het systeem moet voorzieb. Een software vereisten document is een aanvaarde beschrijving systeem vereisten. De IEEE standaard is een bruikbaar startpunt voor het definieren van meer gedetailleerde specifieke vereisten. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 37