Software Requirements Engineering
-
Upload
rinah-solomon -
Category
Documents
-
view
17 -
download
0
description
Transcript of Software Requirements Engineering
![Page 1: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/1.jpg)
1
Software Requirements Engineering
![Page 2: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/2.jpg)
2
Types of Requirements
IEEE Std 830 – 1998 http://ieeexplore.ieee.org/xpl/standardstoc.jsp?isnumber=15571&isYear=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
![Page 3: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/3.jpg)
3
External Interfaces
![Page 4: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/4.jpg)
4
Requirements Specification for Real-Time Systems
Specification methods: formal, informal, semiformal
![Page 5: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/5.jpg)
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
qp rp
)()()( qrqrqr
p – interrupt A arrives; q – task B is executing; r – task A is executing
![Page 6: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/6.jpg)
6
![Page 7: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/7.jpg)
7
Finite State Machine
![Page 8: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/8.jpg)
8
Finite State Machine
![Page 9: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/9.jpg)
9
Mealy Automaton
![Page 10: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/10.jpg)
10
Statecharts
![Page 11: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/11.jpg)
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.
![Page 12: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/12.jpg)
12
Petri Nets
![Page 13: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/13.jpg)
13
Petri Nets
![Page 14: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/14.jpg)
14
Petri Nets
![Page 15: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/15.jpg)
15
Requirements Analysis with Petri Nets
They can be used for race condition and deadlock identification
![Page 16: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/16.jpg)
16
Structured Analysis and Design
![Page 17: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/17.jpg)
17
Structured Analysis and Design
![Page 18: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/18.jpg)
18
Object-Oriented Analysis and the Unified Modeling Language
![Page 19: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/19.jpg)
19
UML Class Diagrams
![Page 20: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/20.jpg)
20
Requirements Document
![Page 21: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/21.jpg)
21
Software Requirements Organization
![Page 22: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/22.jpg)
22
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
![Page 23: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/23.jpg)
23
Language Issues
![Page 24: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/24.jpg)
24
Requirements Validation
![Page 25: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/25.jpg)
25
Software System DesignSoftware Properties
1. Reliability
1.1. r(t) – probability that time T of failure is greater than t:
)()( tTPtr 1.2. Failure function
1.3. Mean time to first failure (MTFF) and Mean time between failures (MTBF)
![Page 26: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/26.jpg)
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
![Page 27: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/27.jpg)
27
![Page 28: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/28.jpg)
28
Basic Software Engineering Principles
1. Rigor and Formality – use mathematical and algorithmic descriptions
2. Separation of Concerns – Divide-and-Conquer
3. Modularity
![Page 29: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/29.jpg)
29
Cohesion and Coupling
![Page 30: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/30.jpg)
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
![Page 31: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/31.jpg)
31
The Design Activity
![Page 32: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/32.jpg)
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.
![Page 33: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/33.jpg)
33
Structured Design and Analysis
![Page 34: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/34.jpg)
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)
![Page 35: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/35.jpg)
35
Relationship between Data and Control Flow Diagrams
![Page 36: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/36.jpg)
36
Design in Procedural Form Using FSM
![Page 37: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/37.jpg)
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
![Page 38: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/38.jpg)
38
OO Design Using UML
![Page 39: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/39.jpg)
39
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
![Page 40: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/40.jpg)
40
UML Sequence Diagrams
![Page 41: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/41.jpg)
41
UML Collaboration Diagrams
![Page 42: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/42.jpg)
42
UML Statechart Diagrams
![Page 43: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/43.jpg)
43
UML Activity Diagrams
![Page 44: Software Requirements Engineering](https://reader035.fdocuments.us/reader035/viewer/2022062422/568135d5550346895d9d41b7/html5/thumbnails/44.jpg)
44
UML Deployment Diagrams