dr. jörg dörr - software engineering · - black-box view of the system - description of the...

© 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


Some application domains

Consumer Electronics

Automobiles

Railway

Aviation

Military


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


A closer look

CMOS Light Sensor

Electronic shutter (Actuator)

Microprocessor

Memory (Software)A/D conversion

ASIC / FPGA

D/A conversion


A closer look

PASIC FPGA

Memory

Sensors Actuators

A/D D/A

SW 1

SW 2

Physical System Boundary

Environment

Env.Input

OutputTo Env.


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.


Outline





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 categories• Functional

• Non-functional

- Performance

- Resource consumption

- Dependability Safety

Reliability

Maintainability

Integrity

Availability

• Other categories also exist.


Outline





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


Logical system model

Controller(HW + SW)

Sensors Actuators

A/D D/A

Environment

Input devices Output devices

Env.Input

OutputTo Env.









• SCR


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


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


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}


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



• 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


Specification model


Environment



REQ, NAT





• 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


Specification model


Environment



REQ, NAT




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


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


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


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))


4 variable model – Summary









• SCR


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


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



• 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



• Key process activities

- Incremental box-structure development

Function-based specification and refinement

- Statistical process control

- Verification

- Certification

We will look at this today


Function based specification

• Incremental development by refinement

• Verification to check if refinement satisfies abstraction

Recursive usage in the same order



• 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)



• 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



• 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


Embedded System Software Specification: Next Class







• SCR