dr. jörg dörr - software engineering · - black-box view of the system - description of the...
Post on 07-Aug-2020
2 Views
Preview:
TRANSCRIPT
© Fraunhofer IESE
REQUIREMENTS ENGINEERINGLECTURE 2015/2016
Dr. Jörg Dörr
RE for Embedded Systems- Part 1
Requirements Engineering
Lecture Outline
• Embedded systems and their characteristics
• Requirements specifications (for embedded systems)
• Embedded-systems software specification
Requirements Engineering
Some application domains
Consumer Electronics
Automobiles
Railway
Aviation
Military
Requirements Engineering
Characteristics
Microprocessor-based and operates within a larger system• Interaction with the environment
- Often directly
• Application-specific control logic- Complex functionality e.g. flight control- Execution of specific tasks e.g. cameras- Specific hardware (ASIC, Microcontroller, FPGA, etc.)
• Constrained for resources- Limited memory- Limited power
Battery operated Low heat dissipation Sophisticated power management.
- Limited area
• Low manufacturing costs• Portable
Requirements Engineering
A closer look
CMOS Light Sensor
Electronic shutter (Actuator)
Microprocessor
Memory (Software)A/D conversion
ASIC / FPGA
D/A conversion
Requirements Engineering
A closer look
PASIC FPGA
Memory
Sensors Actuators
A/D D/A
SW 1
SW 2
Physical System Boundary
Environment
Env.Input
OutputTo Env.
Requirements Engineering
Additional characteristics
• Real-time behavior- Button pressed do task by deadline.- Real-time does not mean fast
• Event-driven/ reactive behavior - Shutter pressed Open Lens - Always ready for reaction to external event.
• Concurrent behavior- Move Window Up, Set Cruise Speed
• Communicating processes- Set child lock, Open rear door
• Non-functional guarantees- Safety: If the brake is pressed, the car does not accelerate- Performance: Process 100 requests per minute- Dependability: Failure rate ≤ 10-4 failures / month- …
• Fault Tolerance- Not a property; rather a means for achieving dependability
Other means include fault prevention, fault masking, etc.
Requirements Engineering
Outline
• Embedded systems and their characteristics
• Requirements specifications (for embedded systems)
• Embedded-systems software specification
Requirements Engineering
Requirements specifications
• What are specifications?
- Specifications state the requirements for a machine which, when correctly implemented, will achieve the desired change in the environment.
- Accurate description of what the machine must do at its interface to its environment.
E.g. If loss of separation is detected, issue an alert warning
This is one specification statement for a requirement on allowable separation between aircraft in flight
Requirements Engineering
Requirements categories• Functional
• Non-functional
- Performance
- Resource consumption
- Dependability Safety
Reliability
Maintainability
Integrity
Availability
• Other categories also exist.
Requirements Engineering
Outline
• Embedded systems and their characteristics
• Requirements specifications (for embedded systems)
• Embedded-systems software specification
Requirements Engineering
Embedded System Software Specification
Specification model• What does the specification contain?• What should be documented?
Logical system model• What is the system?• Where is the system boundary?• What should be considered ?
Specification processes• What steps to perform and how?• Cleanroom software engineering
• Sequence-based Specification
Specification methods• How to document?
• Tables• What language to use?
• SCR
Requirements Engineering
Logical system model
Controller(HW + SW)
Sensors Actuators
A/D D/A
Environment
Input devices Output devices
Env.Input
OutputTo Env.
Requirements Engineering
Embedded System Software Specification
Specification model• What does the specification contain?• What should be documented?
Logical system model• What is the system?• Where is the system boundary?• What should be considered ?
Specification processes• What steps to perform and how?• Cleanroom software engineering
• Sequence-based Specification
Specification methods• How to document?
• Tables• What language to use?
• SCR
Requirements Engineering
Specification model
Logical System Boundary
Environment
Controller System Boundary
I(t) O(t)M(t) C(t)SOFIN OUT
REQ, NAT
Input Device Boundary
Output Device Boundary
Requirements Engineering
Specification model
• System requirements document - AKA System requirements specification (SRS)- Black-box view of the system- Description of the environment
Constraints from the environment e.g., physical laws
- Constraints relevant for the machine to be built- Assumptions
Document whose content is defined by mathematical relations
David Parnas and Jan Madey. Functional Documents for Computer Science. Science of Computer Programming, Elsevier, 1995
Informally known as the Four Variable Model
Requirements Engineering
Before we continue
• Elementary set-theoretic concepts- Relation
AH: Set of {Age, Height}: {{20, 170}, {25,170}, {30,180}, {35,185}}
- Function NA: Set of {Name, Age}: {{A, 20}, {B, 25}, {C, 30}, {D, 35}} A well-behaved relation
- Domain For a function f or a relation r domain Dom (f ) or Dom (r ) : X-values Dom(AH): {20, 25, 30, 35}
- Range For a function f or a relation r range Ran (f ) or Ran (r ) : Y-values Ran(NA): {20, 25, 30, 35}
Requirements Engineering
4 variable model – variables
• Monitored variables mi(t)
- Variables whose values influence output of the machine / system
- Exist outside the system boundary
Often physical quantities
- Values often vary with time
• Mathematically
- m(t): R Value
“m”: function assigning a time dependent real value.
- M(t) : {m1(t), m2(t), …, mn(t)} : Vector of monitored variables
Requirements Engineering
4 variable model – variables
• Controlled variables ci(t)
- Variables whose values are determined by the system
- Exist outside the system boundary
Often physical quantities
- Values often vary with time
• Mathematically
- c(t): R Value
“c” : function assigning a time dependent real value.
- C(t) : {c1(t), c2(t), …, cn(t)} : Vector of controlled variables
Requirements Engineering
Specification model
Logical System Boundary
Environment
Controller System Boundary
I(t) O(t)M(t) C(t)SOFIN OUT
REQ, NAT
Input Device Boundary
Output Device Boundary
Requirements Engineering
4 variable model – variables
• Input variables
- Input variables ii(t) Variables whose values are the result of measurement of mi(t)
• Output variables oi(t) Variables whose values are the result of computation by the machine
• For all () mi(t) there exists () a corresponding ii(t)
• ci(t) oi(t)
- Vice-versa need not be true
- Often ii(t) and oi(t) will be discrete and digital If the machine is HW/SW control logic
Requirements Engineering
Specification model
Logical System Boundary
Environment
Controller System Boundary
I(t) O(t)M(t) C(t)SOFIN OUT
REQ, NAT
Input Device Boundary
Output Device Boundary
Requirements Engineering
4 variable model – relations
• NATural constraints expressed as a relation between the vectors of monitored variables M(t) and controlled variables C(t)
- Dom (NAT): values of M(t)
- Ran (NAT): values of C(t)
- {M(t), C(t)} NAT if and only if (iff) environment (nature) permits the behavior
Requirements Engineering
4 variable model – relations
• REQuirements specified as a relation between the vectors of monitored variables M(t) and controlled variables C(t)
- Dom (REQ): values of M(t)
- Ran (REQ): values of C(t)
- {M(t), C(t)} REQ iff system should permit the behavior
Requirements Engineering
4 variable model – more relations
• INput device description is a relation between monitored variables M(t) and Input variables I(t)
• OUTput device description is a relation between output variables O(t) and controlled variables C(t)
• SOFtware requirements specified as a relation betweenInput variables I(t) and output variables O(t)
- Dom (SOF): values of I(t)
- Ran (SOF): values of O(t)
- {I(t), O(t)} SOF iff software should permit the behavior
Requirements Engineering
Properties
• This should ALWAYS be true
- Dom (REQ) (is superset of) Dom (NAT)
or document is incomplete
- If (Dom (NAT REQ) = Dom (NAT) Dom (REQ)) also holds then REQ is considered feasible with respect to NAT
Else system breaks laws of nature
• Software behavior is acceptable if
M(t), C(t), I(t), O(t) [IN(M(t), I(t)) SOF(I(t),O(t)) OUT(O(t), C(t)) NAT(M(t), C(t))]
→ REQ(M(t), C(t))
Requirements Engineering
4 variable model – Summary
Requirements Engineering
Embedded System Software Specification
Specification model• What does the specification contain?• What should be documented?
Logical system model• What is the system?• Where is the system boundary?• What should be considered ?
Specification processes• What steps to perform and how?• Cleanroom software engineering
• Sequence-based Specification
Specification methods• How to document?
• Tables• What language to use?
• SCR
Requirements Engineering
Box-Structure Development Process
• How do we begin with specification (of embedded systems / software)? - Identify system boundary
Interfaces- Input- Output
- Define what is true at system boundary Relation between input and output
- Define constraints on the system Also a relation between input and output
Requirements Engineering
Cleanroom software engineering
A process for developing and certifying high-reliability software
• Foundations
- Software specifications are mathematical functions mapping a domain set to a range set.
- Software programs are rules for computing this mathematical function
- Well defined functions are complete, consistent and correct
Requirements Engineering
Cleanroom software engineering
• Completeness
- A response is defined for every input (or input history)
- Each element of the domain set mapped to at least one element of the range set
• Consistency
- Each element of the domain set mapped to exactly one element of the range set
• Correctness
- Requirement vs. Specification
- Judgment vs. Proof/ Reasoning
- Explicit traceability
Requirements Engineering
Cleanroom software engineering
• Key process activities
- Incremental box-structure development
Function-based specification and refinement
- Statistical process control
- Verification
- Certification
We will look at this today
Requirements Engineering
Function based specification
• Incremental development by refinement
• Verification to check if refinement satisfies abstraction
Recursive usage in the same order
Requirements Engineering
Function based specification
• S: Stimulus
• SH: Stimulus history
• R: Response
• State and procedure free
• Specification of usage history
- Document sequences of stimuli
- Document required behavior for all possible combination of stimuli
Required for analysis and agreement before committing resources
Definition of behavior to be implemented
Definition of behavior to be expected during testing
• Specify Black box behavior using sequence based specification (SBS)
Requirements Engineering
Function based specification
• Definition of state-space
• Semantics
(Old State, S) (New State, R)
• State preserves stimulus history
• Many possible state boxes for a given black box
• Abstraction is important
Requirements Engineering
Function based specification
• Clear box: State box by procedure
- Sequence do f1; f2 enddo
- Alternation if c then f1 else f2 endif
- Iteration while c do f1 enddo
- Concurrence do f1 f2 enddo
This is traditionally done AFTER specification
i.e. Development
Requirements Engineering
Embedded System Software Specification: Next Class
Specification model• What does the specification contain?• What should be documented?
Logical system model• What is the system?• Where is the system boundary?• What should be considered ?
Specification processes• What steps to perform and how?• Cleanroom software engineering
• Sequence-based Specification
Specification methods• How to document?
• Tables• What language to use?
• SCR
© Fraunhofer IESE
38
Questions
top related