1. UML Diagrams: Sequence Diagrams The Requirements Model, and The Dynamic Analysis Model
Prof. Hany H. Ammar, CSEE, WVU, and
Dept. of Computer Science, Faculty of Computers and Information, Cairo University

2. Outline The Requirements Model and the Analysis model
Introduction to Requirements Engineering
Importance of Sequence Diagrams
Rules of sequence diagrams
Use Cases and Sequence Diagrams
The System Sequence Diagrams
The Sound Recorder Example
The E-Commerce Example
Other Examples

3. The Requirements Model and the Analysis Model
Elicitation
Process
Functional/
Nonfunctional
Requirements
Use Case Diagrams/
Sequence Diagrams
(the system level)
The Object-Oriented
Analysis
Process
Static Analysis
Dynamic Analysis
- Class Diagrams
- State Diagrams/
Refined Sequence
Diagrams (The object
level)

4. What is Requirements Engineering ?

5. What is Requirements Engineering?
Requirements Management:
Requirements management activities include evaluating the impact of proposed changes, tracing individual requirements to downstream work products, and tracking requirements status during development
Several Requirements management tools are available in industry

6. What is Requirements Engineering?
Major Requirements Management Tools:
1. Caliber-RM by Technology Builders, Inc.;
2. RequisitePro by Rational Software Corporation;
3. RTM Workshop by Integrated Chipware, Inc.;

7. What is Requirements Engineering?
Requirements Elicitation
is the process of gathering the different types of requirements from suitable stakeholders.
Business requirements describe why the product is being built and identify the benefits for both the customers and the business.
User requirements, describe the tasks or business processes a user will be able to perform with the product. (Developing use-cases)
Functional requirements describe the specific system behaviors that must be implemented (Developing usage scenarios)
Non-functional requirements, describe the non-functional features such as quality attributes of Reliability, Performance, availability, and maintainability.

8. What is Requirements Engineering?
Requirements analysis:
Requirements analysis includes decomposing high-level requirements into detailed functional requirements, constructing graphical requirements models or logical models (structured Analysis models, or Object-Oriented Analysis models) (for developers), and building prototypes.
Analysis models and prototypes provide alternative views of the requirements, which often reveal errors and conflicts that are hard to spot in a textual SRS.

9. What is Requirements Engineering?
Requirements Specification
Specification key practice is to write down the requirements in some accepted, structured format as you gather and analyze them.
The objective of requirements development is to communicate a shared understanding of the new product among all project stakeholders.
Historically, this understanding is captured in the form of a textual SRS document written in natural language, augmented by appropriate analysis models. (to be discussed in detail)

10. What is Requirements Engineering?
Requirements Verification
Verification involves evaluating the correctness and completeness of the requirements, to ensure that a system built to those requirements will satisfy the users’ needs and expectations. The goal of verification is to ensure that the requirements provide an adequate basis to proceed with design
Prototyping (or executable specifications) is a major technique used in verification. Examples include GUI development for user requirements verification, and Formal requirements specification environments

11. Importance of Sequence Diagrams
Depict object interactions in a given scenario identified for a given Use Case
Specify the messages passed between objects using horizontal arrows including messages to/from external actors
Time increases from Top to bottom

12. Rules of Sequence Diagrams
Sequence Initiation

13. Rules of Sequence Diagrams
Identify objects needed to support use case, determine sequence of internal events following the external initiating event
Diagrams that are not initiated with an external actor represent only a partial sequence
Partial sequence diagrams should clearly identify the actor initiated sequence diagrams from which they are launched

14. Rules of Sequence Diagrams
Messages specified on interactions can be synchronous or asynchronous
Synchronous call

15. Rules of Sequence Diagrams
Asynchronous call

16. Rules of Sequence Diagrams
Display operation names on call arrows

17. Rules of Sequence Diagrams
 Compound and Simple Iteration

18. ‘included’ sequence diagrams

19. Showing alternate behavior in a sequence diagram

20. Showing Extension Point

21. Specifying Timing Requirements

22. Requirements Elicitation Process Step 4
Requirements Elicitation Process Step 4. Refining Use Cases using System Sequence Diagrams
System sequence diagrams establish the dynamic behavior in terms of key scenarios of the system for each use case
The system sequence diagram models a scenario of the system interactions with the environment for a given use case
Input/output events are clearly identified in each sequence diagram,
The State of the system before and after each event are also depicted
Different diagrams model scenarios with the normal flow of events and the abnormal flow of events

23. Sequence Diagrams and Use Cases System Sequence Diagram
The use case diagram
Of system S
The sequence diagram of use case UC1 for system S

24. UML Use Case Diagrams: The Requirements Model
Study

25. UML Use Case Diagrams: The Requirements Model Digital Sound Recorder Case Study
A sequence diagram displays object interactions arranged in a time sequence capturing a specific scenario of interactions in a use case supported by the system
Time

28. Example: Use Case Diagram of E-Commerce Example

32. Place Requistion

35. Other Examples of Sequence Diagrams

36. A Simple Example of Using UML2
EXAMPLE: SATELLITE CONTROL SYSTEM

37. Example of Software Architecture Using UML2
SATELLITE CONTROL SYSTEM Architecture

38. A Simple Example Using UML2
SATELLITE CONTROL SYSTEM Architectural behavior