Software Requirements Engineering
1
Types of Requirements
IEEE Std 830 – 1998
http://ieeexplore.ieee.org/xpl/standardstoc.jsp?isnumber=15571&i
sYear=1998
Defines the following kinds of requirements:
1. Functional
2. External interfaces
3. Performance
4. Logical database
5. Design constraints: standards compliance; software systems
attributes
6. Software system attributes: reliability; availability; security;
maintainability; portability
2
External Interfaces
3
Requirements Specification for Real-Time
Systems
Specification methods: formal, informal, semiformal
4
Formal Methods in Software Specification
There are three general uses for formal methods:
•Consistency checking
•Model Checking
•Theorem Proving
Formal methods also provide opportunities for reusing.
Example from the nuclear monitoring system:
p  q
pr
interrupt A
1.1. If interrupt A occurs then task B stops executing
1.2. Task A begins executing upon arrival of
1.3. Either task A is executing and task B is not, or task B is
executing and task A is not, or both are not executing
(r  q)  (r  q)  (r  q)
p – interrupt A arrives; q – task B is executing; r – task A is executing
5
6
Finite State Machine
7
Finite State Machine
8
Mealy Automaton
9
Statecharts
10
Statecharts
Chain reaction:
Orthogonal states: if state Y consists of and components A and D, Y is
called an orthogonal product of A and D. If Y is entered from outside,
both states A and D are entered simultaneously. Communication
between the and states can be achieved via global memory, whereas
synchronization can be achieved through broadcast communication.
Broadcast communication is depicted by the transition of orthogonal
states based on the same event.
Broadcast communication can describe a chain reaction.
11
Petri Nets
12
Petri Nets
13
Petri Nets
14
Requirements Analysis with Petri Nets
They can be used for race condition and deadlock identification
15
Structured Analysis and Design
16
Structured Analysis and Design
17
Object-Oriented Analysis and the Unified
Modeling Language
18
UML Class Diagrams
19
Requirements Document
20
Software Requirements Organization
21
Requirements to Software Requirements
1. Correct
2. Unambiguous (not subject to different interpretations)
3. Complete
4. Consistent (no contradicting requirements)
5. Ranked for importance
6. Verifiable
7. Modifiable (information hiding)
8. Traceable
22
Language Issues
23
Requirements Validation
24
Software System Design
Software Properties
1. Reliability
1.1. r(t) – probability that time T of failure is greater than t:
r (t )  P(T  t )
1.2. Failure function
1.3. Mean time to first
failure (MTFF) and
Mean time between
failures (MTBF)
25
Software Properties
2. Correctness (close to reliability)
3. Performance
4. Usability
5. Interoperabililty (ability of coexist and cooperate with other
systems. Can be measured in terms of compliance with open
system standards)
6. Maintainability - a system in which changes are are easy
to implement
6.1. Evolvability (how easy to incorporate new)
6.2. Repairability (how easy to fix bugs)
7. Portability
8. Verifiability
26
27
Basic Software Engineering Principles
1. Rigor and Formality – use mathematical and algorithmic
descriptions
2. Separation of Concerns – Divide-and-Conquer
3. Modularity
28
Cohesion and Coupling
29
Basic Software Engineering Principles
4. Anticipation of Change
5. Generality
6. Incrementality – increment provides additional functionality,
brings the product closer to the final one
7. Traceability – a high level of traceability ensures that the
software requirements flow down through the design and code and
then can be traced back up at every stage of the process.
Traceability can be obtained by providing links between all
documentation and the software code
30
The Design Activity
31
Procedural-Oriented Design
Top-down or bottom-up approaches. Parnas partitioning uses
principle of information hiding. A list of difficult decisions of things
which are likely to change is prepared. Modules are then designated
to hide the eventual implementation of of each design decision or
feature from the rest of the system. Thus, only the function of the
module is visible to other modules, not the method of
implementation. Changes in these modules are not likely to affect
the rest of the system.
32
Structured Design and Analysis
33
Structured Design and Analysis
Data Dictionary is supported:
•Entry type (data flow, data store, terminator, process)
•Name
•Alias
•Description
•Found in
Real-Time Extensions of SASD
Dashed lines are used to show control flow and solid bars show
“stored” control commands (control stores)
34
Relationship between Data and Control Flow
Diagrams
35
Design in Procedural Form Using FSM
36
Object-Oriented Design
OO languages are characterized by data abstraction, inheritance,
polymorphism and messaging.
•Open-Closed Principle – classes should be open to extensions but
closed to modifications
•Once and Only Once – any aspect of the software system should
exist in only one copy
•Dependency Inversion Principle – high-level modules should not
depend on low-level modules
37
OO Design Using UML
38
UML Diagrams
1. Activity diagrams – close to flow charts but can model
parallel activities
2. Class diagrams
3. Collaboration diagrams – show messages passed between
objects
4. Component diagrams – are made of components, interfaces
and relationships
5. Deployment diagrams – show real-world nodes and
deployment of components in them
6. Object diagrams are related to class diagrams
7. Sequence diagrams are related to collaboration diagrams
8. Statechart Diagrams
39
UML Sequence Diagrams
40
UML Collaboration Diagrams
41
UML Statechart Diagrams
42
UML Activity Diagrams
43
UML Deployment Diagrams
44