1. Week 2 The Object-Oriented Approach to Requirements

2. Analysis Phase Activities
Gather Information
Involves gathering lots of information
Can get information from people who will be using the system
By interviewing them
By observing them
Can get other information by reviewing documents and policy statements (e.g. At a bank)
Can involve the analyst actually doing some or part of the task to get a feel for what is done
In order to automate order-entry you may need to become an “expert” on the task (knowing how orders are processed)
Need to understand current and future users, locations, system interfaces, possible solutions, etc.

3. Define System Requirements
Involves modelling
Logical Model
Any model that shows what the system is required to do without committing to any one technology – requirements model is logical
Physical Model
Any model that shows how the system will actually be implemented
Models are often graphical in nature
Data flow diagrams (DFDs)
Entity-relationship diagrams (ERDs)

4. Prioritize Requirements
Important to establish which functional and technical requirements are most critical
Why? Since resources are always limited and you want to address the most important things
If not addressed can lead to “scope creep”, where the scope of the project just seems to expand over time

6. Requirements Diagrams: Traditional and OO Models

7. Simple Use Case with an Actor

8. Use Case Diagram with System Boundary

9. Use Case of Customer Support System

10. All Use Cases Including Customer

11. Use Case Diagram for Inventory System

12. <<Includes>> Relationships
Documents situation where one use case requires the services of a common subroutine
Another use case is developed for this common subroutine
A common use case can be reused by multiple use cases

13. Example of Order-Entry Subsystem with <<Includes>> Use Cases

14. Developing a Use Case Diagram
Starting points for use case development
Use event table
Identify all actors of the system
Identify functions actors perform with system
Develop flow of activities to identify various scenarios
Common internal use cases can be identified and separated into different use cases

15. Use Case Detailed Descriptions
Scenario, or use case instance, details sequence of activities within use case
Shows actor interacting with computer system step-by-step to carry out business activity
May have several scenarios for single use case
Analysts prefer to write narrative descriptions of use cases instead of building activity diagrams
Three levels: brief, intermediate, and fully developed description

16. Brief Description of Create New Order Use Case

17. Intermediate Description of the Telephone Order Scenario for Create New Order

18. Intermediate Description of the Web Order Scenario for Create New Order

19. Fully Developed Description of Telephone Order Scenario for Create New Order

20. Fully Developed Description of Web Order Scenario for Create New Order

21. Activity Diagrams
Used to document work flow of business process activities for each use case scenario
Standard UML diagram
Can support any level of use case description
Helpful in developing system sequence diagrams

22. Activity Diagram: Telephone Order Scenario

23. Activity Diagram: Web Order Scenario

24. Identifying Inputs and Outputs – The System Sequence Diagram
Collaboration diagram
Emphasizes objects that interact together to support a use case diagram
May be used alone or with sequence diagram
System sequence diagram
Shows sequence of interactions between objects and flow of events in a single use case
Focuses on message details
Used more frequently in industry

25. Sample System Sequence Diagram (SSD)

26. SSD Notation
Actor represented by stick figure – person (or role) that “interacts” with system by entering input data and receiving output data
Object notation is rectangle with name of object underlined – shows individual object and not class of all similar objects
Lifeline is vertical line under object or actor to show passage of time for object
Messages use arrows to show messages sent or received by actor or system

27. SSD Lifelines Vertical line under object or actor:
Shows passage of time
If vertical line dashed:
Creation and destruction of thing is not important for scenario
Long narrow rectangles:
Activation lifelines emphasize that object is active only during part of scenario

28. SSD Messages
Internal events identified by the flow of objects within a scenario
Requests from one actor or object to another to do some action
Invokes a particular method

29. Repeating Message

30. Developing a System Sequence Diagram
Begin with detailed description of use case from fully developed form or activity diagrams
Identify input messages
Describe message from external actor to system using message notation
Identify and add any special conditions on input message, including iteration and true/false conditions
Identify and add output return messages

31. Simplified Activity Diagram of the Telephone Order Scenario

32. SSD of Simplified Telephone Order Scenario for Create New Order Use Case

33. Activity Diagram: Web Order Scenario

34. SSD of the Web Order Scenario for the Create New Order Use Case

35. Problem Domain Modeling – The Domain Model Class Diagram
Class diagram is focal point of object-oriented development
Provides definition of system components
Contains important class structural information for implementation with object-oriented programming
Provides conceptual data model to describe classes for database definition
Consists of problem domain classes and implementation classes

36. Example of Domain Model Class Diagram

37. RMO Domain Model Class Diagram

38. Integrating Object-Oriented Models
Complete use case diagram is needed to understand total scope of new system
Domain model class diagrams also should be as complete as possible for entire system
With iterative approach, only construct use case descriptions, activity diagrams, and system sequence diagrams for use cases in iteration
Development of a new diagram often helps refine and correct previous diagrams

39. Relationships Between OO Requirements Models