Embedded Software Engineering
 Part 3: Analysis of Functional
         Requirements

           Prof. Dr.-Ing. Stefan Kowa...
Reminder: V model

requirements                                                        acceptance
  analysis              ...
How to do requirements analysis

Reminder:                        • “Online”
                                 • Includes f...
Two analysis paths

               technically       requirements      business
                 oriented          elicita...
Design viewed as an optimization problem


requirements     analysis of                        analysis of
analysis       ...
Analysis of Functional Requirements

Manifest your understanding of the elicitated requirements
(make them clear to you).
...
Analysis of Functional Requirements –
       First step: Define System Boundaries
  Interfaces between system and environm...
Context diagram

Elements:

  System (Function)

  Partner in the environment
  (Interface)

  Flow/Exchange of
  -   Data...
Context diagram: Example ACC

                                     Driver

What if sensor     indicate operation,        s...
Analysis of Functional Requirements –
    Second Step: Understand „Black Box“ behavior
  Capture functional requirements a...
Use cases: Example ACC

Use cases:
  Activation
  De-activation
  Keeping speed constant
  Keeping distance to front objec...
Use case relations/ use case diagrams

In OOA, use cases can have relations:
- includes
- extends
- generalizes (with inhe...
Textual description of use cases

Several templates in literature.
From lecture OOSK by Prof. Lichter:
-   Name
-   Aim
- ...
Textual description of use cases:
             Example ACC activation
Name: Activating ACC
Aim: ACC must be operational
Pr...
Textual description of use cases:
            Example ACC activation /2
Standard sequence (steps, actions/events):
1    Dr...
Your try

Use cases:
  Activation
  De-activation
  Keeping speed constant
  Keeping distance to front object constant
Textual description of use cases:
Example Keeping distance to front object constant
 Name:
 - Keeping distance to front ob...
Textual description of use cases:
Example Keeping distance to front object constant /2
     Standard sequence (steps, acti...
Sequence of actions/events in use cases can be
represented graphically by Sequence diagrams/MSCs
  Basic idea:
  Represent...
Graphical representation of use cases:
          Sequence diagrams/MSCs /2
Origin:
- OSI Time Sequence Diagrams (standardi...
MSC Example: production plant
         (from Kowalewski, at-Automatisierungstechnik, 9/2001)



Produktion                ...
MSC Example /2:                    MSC ProduktionAC
                                                                      ...
MSC Example /3:                    MSC AlternativeProdukte
                                                               ...
MSC Example /4:
 High level MSCs
                                    MSC Produktionszyklus
    (from Grabowski et al, at-
...
Example for sequence diagram:
             Use case ACC activation
Name: Activating ACC
Aim: ACC must be operational
Pre-c...
Example for sequence diagram:
           Use case ACC activation (2)
Standard sequence (steps, actions/events):
1    Drive...
MSC for use case „ACC activation“

      driver             sensor                  ACC                  ESP

alt         ...
Outlook


Next part:

Analysis of qualitative (non-functional) requirements
Upcoming SlideShare
Loading in …5
×

3 20050524 Analysis Functional Reqs 분석

432 views

Published on

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
432
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
15
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

3 20050524 Analysis Functional Reqs 분석

  1. 1. Embedded Software Engineering Part 3: Analysis of Functional Requirements Prof. Dr.-Ing. Stefan Kowalewski Chair “Informatik XI”, Embedded Software Laboratory RWTH Aachen University kowalewski@informatik.rwth-aachen.de Summer term 2005
  2. 2. Reminder: V model requirements acceptance analysis test integration specification test architecture system design integration modul/algorithm modul test design implementation
  3. 3. How to do requirements analysis Reminder: • “Online” • Includes first Requirements Elicitation ad-hoc analysis - Collect the requirements from customers, marketing, system engineers etc. Requirements Analysis - Analyse whether the requirements are actually what the customers, marketing, system engineers etc. want. • “Offline” • Results will be presented to the customer after analysis • Several iterations possible
  4. 4. Two analysis paths technically requirements business oriented elicitation oriented non-functional functional reqs requirements (first version) (first version) requirements analysis of analysis of analysis functional reqs qualities functional driving specification qualities architecture design
  5. 5. Design viewed as an optimization problem requirements analysis of analysis of analysis functional reqs qualities functional spec driving qualities = optimization = optimization constraints criteria design = optimization Find best or good enough solution (measured by qualities) among all admissible solutions (given by functional spec.)
  6. 6. Analysis of Functional Requirements Manifest your understanding of the elicitated requirements (make them clear to you). Structure and present them in different form to the customer (e.g., build models or derive test cases), such that the customer can then compare your understanding with his/her original intentions. Do not begin designing the system! Why? - Customer will discuss design issues with you. - Design solution will become part of specification document and reduce degree of design freedom. How? - Regard system as black box (in this phase).
  7. 7. Analysis of Functional Requirements – First step: Define System Boundaries Interfaces between system and environment What must be designed, what is given? → Needed for agreement on content of the project → One possible model: Context diagram
  8. 8. Context diagram Elements: System (Function) Partner in the environment (Interface) Flow/Exchange of - Data - Information - Energy - Mass - …
  9. 9. Context diagram: Example ACC Driver What if sensor indicate operation, select speed, would be part selected speed, activate, current speed , de-activate of system? current distance activate Radar sensor Engine object distance, object velocity ACC acceleration/ controller decelaration brake force ESP car speed, system lateral acceleration, yaw rate
  10. 10. Analysis of Functional Requirements – Second Step: Understand „Black Box“ behavior Capture functional requirements as they manifest themselves at the interface between system and environment. → One possible tool: Use Cases Use case = A coherent piece of functionality of the system that is visible (in black-box form) from outside the system. Elements outside the system which are involved in the use case are called actors. In embedded systems, actors are mostly sensors and actuators (but also users). OOA Definition of use case (see OOSK, Prof. Lichter): A sequence of interactions between an actor/actors and a system triggered by a specific actor which produces a result for an actor. (applicable to continuous control functions?)
  11. 11. Use cases: Example ACC Use cases: Activation De-activation Keeping speed constant Keeping distance to front object constant
  12. 12. Use case relations/ use case diagrams In OOA, use cases can have relations: - includes - extends - generalizes (with inheritance of interaction relations) This offers possibility to reuse use cases. Aim: Structure functionality. } Your opinion? Use case diagrams: System boundary Use case Use case 1 diagram for ACC Actor 1 relation Use case 2 Actor 2 example?
  13. 13. Textual description of use cases Several templates in literature. From lecture OOSK by Prof. Lichter: - Name - Aim - (Level) - Pre-condition - Post-condition - Post-condition in case of failures - Actors - Trigger - Standard sequence (steps, actions/events) - Alternatives/exceptions
  14. 14. Textual description of use cases: Example ACC activation Name: Activating ACC Aim: ACC must be operational Pre-condition: ACC is not activated; car is running; radar sensor is available; ESP, engine ECU are running; CAN is available; cruise speed is selected; current speed is in [30 ; 180 km/h] Post-condition: ACC operation is indicated to driver Post-condition in case of failures: failure to activate ACC is indicated to driver Actors: driver, radar sensor, ESP Trigger: driver operates ACC activation interface
  15. 15. Textual description of use cases: Example ACC activation /2 Standard sequence (steps, actions/events): 1 Driver operates ACC activation interface 2 ACC activates radar sensor 3 radar sensor acknowledges availability 4 ACC checks that current speed is in [30 ; 180 km/h] 5 ACC indicates operability Alternatives/exceptions: 3a1 no response from radar sensor 3a2 ACC indicates failure 4a1 current speed is not in [30 ; 180 km/h] 4a2 ACC de-activates radar 4a3 ACC indicates failure
  16. 16. Your try Use cases: Activation De-activation Keeping speed constant Keeping distance to front object constant
  17. 17. Textual description of use cases: Example Keeping distance to front object constant Name: - Keeping distance to front object constant Aim: - Keeping distance constant without driver interaction Pre-condition: - ACC is active Post-condition: - current distance is displayed, distance is as specified, in speed control if necessary Post-condition in case of failures: - indication of failure, de-activate ACC Actors: - engine CU, ESP, driver, sensor Trigger: - detection of a front object
  18. 18. Textual description of use cases: Example Keeping distance to front object constant /2 Standard sequence (steps, actions/events): 1 Get distance and object speed 2 Get own speed, lateral acceleration, yaw rate 3 Compare current with desired distance 4 Adjust speed accordingly 5 Display distance 6 Go back to 1 as long as object is in front Alternatives/exceptions: Your turn!
  19. 19. Sequence of actions/events in use cases can be represented graphically by Sequence diagrams/MSCs Basic idea: Represent interaction between system and actors by a temporally ordered exchange of messages Fundamental elements: - System, actors: vertical lines - Message exchange: horizontal arrows Actor System Temporal Message order (qualitative) Sequences are only possible, not a complete behavioral specification!
  20. 20. Graphical representation of use cases: Sequence diagrams/MSCs /2 Origin: - OSI Time Sequence Diagrams (standardized 1991!) - ITU-T SG 10: Message Sequence Charts, 2000 - ITU-T SG 10: Algebraic semantics of MSCs, 1996 UML adopted MSCs, renamed them to sequence diagrams and changed/added some elements/representations - Examples: Lifelines for objects stimulus and response Actor System Actor System stimulus response
  21. 21. MSC Example: production plant (from Kowalewski, at-Automatisierungstechnik, 9/2001) Produktion Produktion C-Teile D-Teile C Lager C D Lager C-Teile D-Teile C Roboter D Greifplatz C D Greifplatz C-Teile D-Teile Diskriminator C C D C D D A A B A B B Förderband Ortsschalter
  22. 22. MSC Example /2: MSC ProduktionAC Roboterplatz basic MSC FabrikFürC Produktionszelle FabrikFürD (from Grabowski et al, at- Automatisierungstechnik, 12/2001) Initialzustand NeuesTeil (A) A-Teil erkennen und C-Teil greifen Gegriffen T ProdZeit Produkt montieren und Produktion ausliefern eines neuen C-Teils Produkt (AC) NächstesTeil Vorhanden (C) Initialzustand
  23. 23. MSC Example /3: MSC AlternativeProdukte Roboterplatz inline expressions FabrikFürC Produktionszelle FabrikFürD (from Grabowski et al, at- Automatisierungstechnik, 12/2001) Initialisierungsphase alt NeuesTeil (A) Gegriffen Produkt NächstesTeil (AC) Vorhanden (C) NeuesTeil (B) Gegriffen Gegriffen Produkt (BDC) NächstesTeil Vorhanden Vorhanden (D) (C)
  24. 24. MSC Example /4: High level MSCs MSC Produktionszyklus (from Grabowski et al, at- Automatisierungstechnik, 12/2001) Initialisierungsphase Initialzustand ProduktionAC ProduktionBDC
  25. 25. Example for sequence diagram: Use case ACC activation Name: Activating ACC Aim: ACC must be operational Pre-condition: ACC is not activated; car is running; radar sensor is available; ESP, engine ECU are running; CAN is available; cruise speed is selected; current speed is in [30 ; 180 km/h] Post-condition: ACC operation is indicated to driver Post-condition in case of failures: failure to activate ACC is indicated to driver Actors: driver, radar sensor, ESP Trigger: driver operates ACC activation interface
  26. 26. Example for sequence diagram: Use case ACC activation (2) Standard sequence (steps, actions/events): 1 Driver operates ACC activation interface 2 ACC activates radar sensor 3 radar sensor acknowledges availability 4 ACC checks that current speed is in [30 ; 180 km/h] 5 ACC indicates operability Alternatives/exceptions: 3a1 no response from radar sensor 3a2 ACC indicates failure 4a1 current speed is not in [30 ; 180 km/h] 4a2 ACC de-activates radar 4a3 ACC indicates failure
  27. 27. MSC for use case „ACC activation“ driver sensor ACC ESP alt driver wants to activate ACC activate acknowledgement get speed speed in [30,180] km/h indicate operability driver wants to activate ACC activate not available indicate failure driver wants to activate ACC activate acknowledgement get speed speed not in [30,180] indicate failure
  28. 28. Outlook Next part: Analysis of qualitative (non-functional) requirements

×