ETS170 Requirements Engineering

Storlek: px

Starta visningen från sidan:

Download "ETS170 Requirements Engineering"

Mats Öberg
för 5 år sedan
Visningar:

1 ETS170 Requirements Engineering Lecture 4: Specification, part 3: Special interfaces: Lau:5 Requirements in the life cycle: Lau: 7 Björn Regnell

2 Overview of styles for specifying functional requirements (Swedish terminology) Datakravstilar: Datamodell ( =E/R-diagr.) Dataordlista Reguljära uttryck Virtuella fönster Funktionella kravstilar: Kontextdiagram Händelse- & Funktionslistor Produktegenskapskrav Skärmbilder & Prototyper Uppgiftsbeskrivningar Egenskaper från uppgifter Uppgifter och stöd (Levande) Scenarier Högnivåuppgifter Användningsfall Uppgifter med data Dataflödesdiagram Standardkrav Krav på utvecklingsprocessen Funktionella detaljer: Enkla och sammansatta funktioner Tabeller & Beslutstabeller Textuella processbeskrivningar Tillståndsdiagram Övergångsmatriser Aktivitetsdiagram Klassdiagram Samarbetsdiagram Sekvensdiagram Speciella gränssnitt Rapporter Plattformskrav Produktintegration Tekniska gränssnitt

3 Special interfaces Summary Platform requirements Requirements on what the product shall run on now and in the future Dealing with existing and planned platforms Can be very complex and technically detailed depending on the product and contracting situation Technical interfaces Requirements on interactions with other systems Many different ways to specify technical interfaces Performance and capacity requirements can be very difficult to understand and validate Prototype and test the communication early Note that the recently recent research field of software product line engineering is not covered by Lauesen.

4 Variability modelling in software product lines with reqt

5 Fig 5.2 Platform requirements We have a platform R1: Product shall run on Pentíum PC s with 128 MB. Many older PC s still used, so tasks 2.1 to 2.5 must be supported on with 64 MB. R2: Our IT staff have expertice in Oracle. Product must use same database platform. R3: Product shall run on MS Windows release xx.yy. Supplier shall for 3 years port his product to new releases within months from release date. We want a new platform anyway R4: Customer expects to switch to client-server running OS zz. Supplier shall specify server memory and server speed needed to obtain capacity and response time for Rxx. We want software and hardware (maybe) R5: Supplier shall deliver hardware + software. Supplier shall upgrade if capacity becomes inadequate for the load specified in xx. R6: Product shall run on Pentium PC s with 128 MB. As an option, total delivery may include the PC s and hardware support. From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

6 Fig 5.3A Who can integrate? Customer??? Customer s IT dept Hotel system Account system? Main contractor Product supplier?

7 Fig 5.4 Main contractor Embedded 3rd party product DB sys Hotel system Account system Visible 3rd party product Main contractor Telephone system Joint design work The optimal split. Exists? Willing? Cost vs. market Sub-contractor From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

8 Fig 7.3 Comparing proposals Hotel system evaluation Proposals 0 (bad) - 5 (excellent) A B C Normal requirements Weakest requirements Total product points Understand our problem Track record Solidity Total points Base price Option 1: Floor map Option 2: From the buyers perspective Ideal evaluation Proposals A B C Business value (NPV) Supplier s price Internal investment costs Net value Perhaps better to do more systematic prioritization? From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

9 Fig 7.4 Customer s rating Task: 1.2 Checkin Proposal B Purpose: Give guest a room... Rating: 3 Frequency:... Sub-tasks: 1. Find room. Problem: Guest wants neighbor rooms; price bargain. 2. Record guest as checked in. 3. Deliver key. Problem: Guests forget to return the key; want two keys. Variants: 1a. Guest has booked in advance. Problem: Guest identification fuzzy. Assessment: Floor map developed as an option. Very convenient display of bargain prices. If guest is not booked, cumbersome to switch to that task. No support for electronic keys. Tests show no tolerance for spelling errors. Very long search time for names. From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

10 Fig 7.5 Supplier s proposal Task: 1.2 Checkin Purpose: Give guest a room... Frequency:... Sub-tasks: 1. Find room. Problem: Guest wants neighboor rooms; price bargain. 2. Record guest as checked in. 3. Deliver key. Problem: Guests forget to return the key; want two keys. Variants: 1a. Guest has booked in advance. Problem: Guest identification fuzzy. Proposal: Floor map developed as an option. See outline on page xx. See room screen p. yy. See guest screen and check-in screen, p. zz We provide no support for electronic keys. Planned for release 5 in 1.5 years. User may search for any field using wildcarding. From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

11 High risk requirements Quality("performance") has Spec("The response time shall be at most 0.5 seconds on average when moving from one screen to another. The response time shall never be above 2 seconds.") Suppler A: We didn't notice any problems. Our response time is of that magnitude. Supplier B: We don't care. We'll find a way out later. Suppler C: We state as an assumption that 95% of the cases will be sufficient. Supplier D: We fulfill the requirement although it will be expensive. Supplier E: We tell the customer what it would cost and why, and then offer a reasonable alternative. Eventually, we offer the full solution as an expensive option. [Lauesen: 7.5, p. 310]

12 Fig 5.5 Technical interfaces Hotel system Account system Communication channel Physical channel: File, TCP/IP, object calls... Message formats: Data descr, call params Protocol: State diagram, sequence diagram formal data descr, SDL... Semantics: about what? E/R, tasks, activity diagrams Verify early: Functional prototypes From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

13 Fig 7. Requirements in product life cycle Inception Elicitation Formulation Checking Tender Writing proposal Design & program Contract Comparing proposals Next release Accept test Reqs management & release planning

14 Fig 7.6 Design and program R1: System shall store data according to this data model... R2: Product shall have screen pictures and menus as shown in... R3: Product shall record that a room is under repair... R4: Product shall support check-in according to task description... R5: At most 1 of 5 novices shall have critical usability problems during check-in. R6: Storing a booking shall take less than 1 second on average. R7: Pre-calculation of repair orders shall hit within 5% of actual costs. How to trace and verify these during development? From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

Spårbarhet (Traceability) Ändringar i intressenternas behov, önskemål och tekniska antaganden kan kräva radikal omvärdering av kravens relevans.

Framåt från krav package samples.simple; Källa Bakåt från krav Dependecy Req F8: Color Bakåt till krav public class Hello1 { public void printhello() { System.out.

15 Spårbarhet (Traceability) Ändringar i intressenternas behov, önskemål och tekniska antaganden kan kräva radikal omvärdering av kravens relevans. Ansvar för kravuppfyllelse behöver kopplas till systemkomponenter så att ansvarighet och påverkansanalys kan utrönas Framåt till krav Requirements document Req A1: Printing Framåt från krav package samples.simple; Källa Bakåt från krav Dependecy Req F8: Color Bakåt till krav public class Hello1 { public void printhello() { System.out.println( "Hello!" ); } } Design/ Kod/Test Hur intressenterna medverkat till kraven är viktig information vid validering. Kravuppfyllelse behöver verifieras och design utan krav ( gold-plating ) behöver undvikas.

16 To Do Read Lau: 5, 7 Exercise 3: Functional requirements (Lau:2-4) Lab 1: mandatory preparations (see tutorial on reqt) Start plan/work on bonus chance exam problem proposals: Follow instructions on slides from Lecture 2! Deadline: W4 & W PMv2 deadline was today Upcoming project deadlines: W4: meeting with project supervisor: discuss scope & plan W6: Release R2 Mon 0900 with draft release plan & check list W6: Validation Report Fri 0900 (see course program guidelines)

Relevanta dokument

Inför labb. Föreläsning 5 Funktionella krav forts Validering. Övningarna. Fortsättning. Christin Lindholm

Inför labb. Föreläsning 5 Funktionella krav forts Validering. Övningarna. Fortsättning. Christin Lindholm Föreläsning 5 Funktionella krav forts Validering Christin Lindholm Inför labb Förberedelseuppgift ligger på hemsidan Redovisas på labb Får inte göra labben om den inte är gjord Labb den 12 oktober kl.