Chapter Learning Goals

Transcription

1 Chapter Learning Goals D-Requirements Distinguish C- (Customer) requirements from D- (Detailed) requirements Be equipped with options for organizing D-requirements by class - by use case by feature - by event... Be able to complete requirements be detailed enough to enable all design and complete implementation be able to express the non-functional requirements Martin Jud NDS-I SWE I 1 Requirement Types D-Requirements Problem Space Needs Solution Space C-Requirements D-Requirements Features System-Requirements Lastenheft Software Specification Pflichtenheft Martin Jud NDS-I SWE I 2 Aus der Vorlesung Softwareengineering von Jörg Hofstetter HTA Luzern

2 D-Requirements Das Pflichtenheft Martin Jud NDS-I SWE I 3 Aus der Vorlesung Informationstechnik von Berend Denkena u. Kirsten Tracht am ifw der Uni Hannover D-Requirements C- vs. D-Requirements - Beispiel C-Requirement (Feature): #1: Eine Lichtquelle kann zeitgesteuert ein-/ausgeschaltet werden. D-Requirement (Software Specification): Timer. #T1: Ein Timer ist frei programmierbar. Für jedes Zeitereignis kann eine Aktion definiert werden. #T2: Einmale Zeitereignisse: Datum/Uhrzeit - Auflösung Minuten. #T3: Zyklische Ereignisse: minütlich, stündlich, täglich, Wochentag. #T4: Mögliche Aktionen: Lichtquelle ein/aus. #T5: Protokoll, welches Timer bei Ereignis-Eintritt aussendet: Zeit/Datum Art Aktion Martin Jud NDS-I SWE I 4 Aus der Vorlesung Softwareengineering von Jörg Hofstetter HTA Luzern

3 Types of Requirements D-Requirements 1. Functional requirements the application's functionality 2. Non-functional requirements 2.1 Performance speed capacity (traffic rates) memory usage RAM disk 2.2 Reliability and availability 2.3 Error handling 2.4 Interface requirements how the application interacts with the user, and with other applications 2.5 Constraints accuracy tool and language constraints e.g. FORTRAN 88 must be used design constraints standards to be used hardware platforms to be used 3. Inverse requirements what the application does not do Martin Jud NDS-I SWE I 5 D-Requirements: SRS IEEE Specific ( D- ) Requirements 3. Specific requirements (non-oo) 3. Specific requirements (OO) 3.1 External interfaces 3.2 Functions 3.3 Performance requirements 3.4 Logical database requirements 3.5 constraints Standards compliance 3.6 Software system attributes Reliability Availability Security Maintainability Portability 3.7 Organizing the specific requ System mode -- or User class -- or Objects (see right) -- or Feature -- or Stimulus -- or Response -- or Functional hierarchy -- or Additional comments -- or 3.1 External interface requirements User interfaces Hardware interfaces Software interfaces Communications interfaces 3.2 Classes/Objects Class/Object Attributes (direct or inherited) Attribute Functions (services, methods, direct or inherited) Functional requirement Performance requirements 3.4 constraints 3.5 Software system attributes 3.6 Other requirements Martin Jud NDS-I SWE I 6

4 SRS Chap. 3 Organization (OO Style) D-Requirements: SRS 3. Specific requirements 3.1. External interface requirements User interfaces Hardware interfaces Software interfaces Communications interfaces 3.2. Classes/Objects -- see section tbd Performance requirements 3.4. constraints 3.5. Software system attributes 3.6. Other requirements Martin Jud NDS-I SWE I 7 SRS Chap. 3 Organization (Functional Style) D-Requirements: SRS 3. Specific requirements 3.1. External interface requirements User interfaces Hardware interfaces Software interfaces Communications interfaces 3.2. Functions 3.3. Performance requirements 3.4. constraints 3.5. Software system attributes 3.6. Other requirements Martin Jud NDS-I SWE I 8 Aus der Vorlesung Softwareengineering von Jörg Hofstetter HTA Luzern

5 D-Requirements: SRS Specific requirements (Section 3 of the SRS) Describe all of the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements. Requirement should be externally perceivable and include a description of every input (stimulus) into the system, every output (response) from the system, and all functions performed by the system in response to an input or in support of an output. The following principles apply: Requirements should be cross-referenced to earlier documents. Requirements should be uniquely identifiable. Martin Jud NDS-I SWE I 9 excerpt from IEEE Std 830, 1998 IEEE D-Requirements: Vorgehen A path through requirements 1. Gather stakeholder needs 2. From stakeholder needs create the Vision with features 3. Use the features to create the use case model 4. Detail the use cases into scenarios and the object model Martin Jud NDS-I SWE I 10 Adapted from cs3733-e04 SWE slides by Gary F. Pollice, Worcester Polytechnic Institute, MA

6 D-Requirements: Vorgehen Finden der Analyseklassen aus Aktivitäten des Geschäftsprozessmodells werden UseCases des Systemanforderungsmodells Register for Course Customer Request for Information Send Comment Billing jeder UseCase wird durch Klassen mit den Stereotypen «entity» «boundary» oder «control» verfeinert. 1..* Bank Kunde Geldausgabe Abhebung User Interface Konto besitz 1..* Transfer Konto aus Instanzen des Geschäftsprozessmodells werden Klassen im Analysemodell. Geldannahme Einzahlung Martin Jud NDS-I SWE I 11 Sinngemäss aus Realisierung einer Unternehmensanwendung by Günter Ruck, MID GmbH D-Requirements: Vorgehen Analyseklassen Stereotypen Analysis classes may be stereotyped as one of the following: Boundary classes Control classes Entity classes These stereotypes are specially useful in helping you to identify classes in analysis and early design. Martin Jud NDS-I SWE I 12 Aus dem Rational Unified Process Rational Software Corporation

7 D-Requirements: Vorgehen Find Classes for Requirements 1. Develop a comprehensive, non-overlapping collection of use cases. 2. Draft candidate classes or objects and methods (e.g. using the noun / verb technique) 3. Create a sequence diagram for every use case. - take care in identifying the classes and objects 4. Gather the classes used in the sequence diagrams. 5. Determine essential additional domain classes. 6. Classify the detailed functional requirements by these classes. 6.1 list each attribute as a requirement 6.2 list each specific object of this class that must exist 6.3 list each function required of objects in this classification 6.4 list the events that all objects of the class must react to Martin Jud NDS-I SWE I 13 D-Requirements: Eigenschaften Desired Properties of Requirements Traceability Verfolgbarkeit Testability Testbarkeit Unambiguity Eindeutigkeit Priority Priorität Completeness Vollständigkeit Consistency Konsistenz Use these Properties for Inspection Martin Jud NDS-I SWE I 14 Aus der Vorlesung Softwareengineering von Jörg Hofstetter HTA Luzern

8 Traceability D-Requirements: Eigenschaften Martin Jud NDS-I SWE I 15 Adapted from cs3733-e04 SWE slides by Gary F. Pollice, Worcester Polytechnic Institute, MA D-Requirements: Eigenschaften Traceability Matrix Martin Jud NDS-I SWE I 16 Adapted from cs3733-e04 SWE slides by Gary F. Pollice, Worcester Polytechnic Institute, MA

9 Tracing and Testing of Functional D-Requirements D-Requirements: Eigenschaften # Functional Requirement 278 validated by Unit Test trace implemented by applies to... ABCD! trace Code EFGH " Martin Jud NDS-I SWE I 17 D-Requirements: Eigenschaften Functional vs. Non-Functional Requirements Requirements Test phase phase Functional Requirement tested by Unit Test + Inspect assignment Implementation " $ # Martin Jud NDS-I SWE I 18

10 D-Requirements: Eigenschaften Link from Source to Requirement /** <a href="requanal\# EngagingForeignCharacter "> Engagement Requirement 1 ("Engaging a foreign character") </a>.... Implementation comments.... */ The purpose of this method is stated in SRS. The purpose is not repeated with the source code. public engageforeigncharacter( ) {..... } Martin Jud NDS-I SWE I 19 Testability D-Requirements: Eigenschaften The system shall display the difference in salary between the client and the world wide average for the same trade - - can't be tested because the average mentioned cannot be determined (event though it exists). Better: The system shall display the difference in salary between the client and the estimated world-wide average for the same trade as published by the United Nations on its website at the time of the display... Martin Jud NDS-I SWE I 20

11 D-Requirements: Eigenschaften Ambiguity The player can decide the qualities of Encounter characters. At any time? Probably not. Would have to test under all circumstances, many not intended, incurring unnecessary expense, and producing a wrong result. % & Whenever all foreign players are absent from the area containing the player's main character, the player may change the quality values of this character, keeping the sum total of the quality values unchanged. The PlayerQualityWindow, (see section tbd) is used for this purpose. Changes take effect four seconds after the OK button is pressed. Martin Jud NDS-I SWE I 21 Constistency No contradictions among requirements. Requirement 14. Only basic food staples shall be carried by game characters Requirement 223. Every game character shall carry water Requirement 497. Flour, butter, milk and salt shall be considered the only basic food staples. Martin Jud NDS-I SWE I 22

12 D-Requirements: Eigenschaften Prioritizing D-requirements [essential] [desirable] [optional] Every game character has the same set of qualities. Each area has a set of preferred qualities. The player s character shall age with every encounter. The age rate can be set at setup time. Its default is one year per encounter. Martin Jud NDS-I SWE I 23 D-Requirements: Prozess Status after initial draft Result of updating after C- requirements Result of updating after D- requirements Table 4.5 Updating the Project on Completing D-Requirements Milestones Initial More detailed More detailed Risks Identify Retire risks identified previously; seek more risks Retire risks identified; identify more risks Schedule Very high level Preliminary project schedule More detailed: shows class & method development tasking Personnel ate C- requirements engineers Engineers designated for D-requirements analysis ate software architects Cost Estimation Crude estimates First estimates based on job content Improved estimate based on more specific function points and/or past experience Martin Jud NDS-I SWE I 24

13 D-Requirements: Prozess Tracking Requirements Status Requirement Priority Not Fraction completeready for ed Integration number Essential Optional started 1/3 2/3 Inspection for Unit tested Responsible engineer Desirable Inspected tested Martin Jud NDS-I SWE I 25 D-Requirements: Prozess Concurrent Development of Requirements and Architecture Martin Jud NDS-I SWE I 26 Aus einem STRAW 01 Paper von Bashar Nuseibeh