3 20050524 Analysis Functional Reqs 분석
Upcoming SlideShare
Loading in...5
×
 

3 20050524 Analysis Functional Reqs 분석

on

  • 557 views

 

Statistics

Views

Total Views
557
Views on SlideShare
556
Embed Views
1

Actions

Likes
0
Downloads
12
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    3 20050524 Analysis Functional Reqs 분석 3 20050524 Analysis Functional Reqs 분석 Presentation Transcript

    • 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
    • Reminder: V model requirements acceptance analysis test integration specification test architecture system design integration modul/algorithm modul test design implementation
    • 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
    • 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
    • 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.)
    • 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).
    • 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
    • Context diagram Elements: System (Function) Partner in the environment (Interface) Flow/Exchange of - Data - Information - Energy - Mass - …
    • 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
    • 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?)
    • Use cases: Example ACC Use cases: Activation De-activation Keeping speed constant Keeping distance to front object constant
    • 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?
    • 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
    • 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
    • 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
    • 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 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
    • 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!
    • 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!
    • 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
    • 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
    • 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
    • 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)
    • MSC Example /4: High level MSCs MSC Produktionszyklus (from Grabowski et al, at- Automatisierungstechnik, 12/2001) Initialisierungsphase Initialzustand ProduktionAC ProduktionBDC
    • 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
    • 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
    • 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
    • Outlook Next part: Analysis of qualitative (non-functional) requirements