1. Software Requirements Engineering

2. Types of Requirements
IEEE Std 830 –
Defines the following kinds of requirements:
Functional
External interfaces
Performance
Logical database
Design constraints: standards compliance; software systems attributes
Software system attributes: reliability; availability; security; maintainability; portability

3. External Interfaces

4. Requirements Specification for Real-Time Systems
Specification methods: formal, informal, semiformal

5. 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:
1.1. If interrupt A occurs then task B stops executing
1.2. Task A begins executing upon arrival of interrupt A
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
p – interrupt A arrives; q – task B is executing; r – task A is executing

7. Finite State Machine

8. Finite State Machine

9. Mealy Automaton

10. Statecharts

11. 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.

12. Petri Nets

13. Petri Nets

14. Petri Nets

15. Requirements Analysis with Petri Nets
They can be used for race condition and deadlock identification

16. Structured Analysis and Design

17. Structured Analysis and Design

18. Object-Oriented Analysis and the Unified Modeling Language

19. UML Class Diagrams

20. Requirements Document

21. Software Requirements Organization

22. Requirements to Software Requirements
Correct
Unambiguous (not subject to different interpretations)
Complete
Consistent (no contradicting requirements)
Ranked for importance
Verifiable
Modifiable (information hiding)
Traceable

23. Language Issues

24. Requirements Validation

25. Software System Design
Software Properties
Reliability
1.1. r(t) – probability that time T of failure is greater than t:
1.2. Failure function
1.3. Mean time to first failure (MTFF) and Mean time between failures (MTBF)

26. 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

28. Basic Software Engineering Principles
Rigor and Formality – use mathematical and algorithmic descriptions
Separation of Concerns – Divide-and-Conquer
Modularity

29. Cohesion and Coupling

30. 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

31. The Design Activity

32. 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.

33. Structured Design and Analysis

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

35. Relationship between Data and Control Flow Diagrams

36. Design in Procedural Form Using FSM

37. 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

38. OO Design Using UML

39. UML Diagrams
Activity diagrams – close to flow charts but can model parallel activities
Class diagrams
Collaboration diagrams – show messages passed between objects
Component diagrams – are made of components, interfaces and relationships
Deployment diagrams – show real-world nodes and deployment of components in them
Object diagrams are related to class diagrams
Sequence diagrams are related to collaboration diagrams
Statechart Diagrams

40. UML Sequence Diagrams

41. UML Collaboration Diagrams

42. UML Statechart Diagrams

43. UML Activity Diagrams

44. UML Deployment Diagrams