1. CMPT 275 Software Engineering
Requirements Analysis activity (use case diagrams, Class activity)
Janice Regan,

2. Class Project: Requirements Analysis
Object Oriented paradigm
Requirements Gathering Activity: Develop informal scenarios to help you derive your software requirements specifications
Requirement specification Activity: Build an ‘analysis model’ representing the user’s/client’s view of the system
‘analysis model’ includes a list of functional and non-functional requirements. Each functional requirement represent all or part of at least one function/activity
Functional requirements are not dependent on specific methods of implementation
Janice Regan,

3. Class Project: Requirements Analysis
Next you will proceed using use case centered development (UCCD) to analyze that model
System Context Diagram
Identifying Actors and developing Use Cases
Use case Diagrams
Primary classes
Use cases and Scenarios (formal and informal)
Class (object) Diagram
State Diagrams
Janice Regan,

4. Requirements Analysis Activities
Software Developer
Client/User
Update SRS
Use Case Centered Development (UCCD)
Questions
Use Case
Diagram
Use Cases
Class
Diagram
System
Context
Diagram
Primary
Classes
Scenarios
State
Diagram
Janice Regan,

5. Use Cases
Specify the behaviour of the system from the user’s perspective
Provides value to at least one user of the system
Describe a sequence of actions, performed by the system, to yield a result desired by that user
The behavior of the system is expressed without specifying how the behavior is implemented (What is behavior, not how is it done)
To get started generalize an informal scenario (or closely related set of informal scenarios)
Informal scenarios are a good starting point
Janice Regan,

6. UML: Unified Modeling Language
Object-Oriented Paradigm modelling notation
Clear and effective way to model many aspects of a software system using a commonly understood language
Programming language independent
Enables a variety or analysis and design techniques
A subset of UML will be used in this course
Janice Regan,

7. UML: Unified Modeling Language
Used in this course for analysis models of
System functionality (use case diagrams, use cases and scenarios)
Objects and their static relationships (class diagrams)
Dynamic behavior (state diagrams, collaboration diagrams sequence diagrams)
Janice Regan,

8. Use Case Diagrams Depicts overall behavior of s/w system
Models the context of a system (what is part of the system what external entities interact with the system)
AND
Models the requirements of a system, the desired behavior of the system (what the system should do from an external viewpoint, not how it should do it)
Janice Regan,

9. Use Case Diagrams Depicts overall behavior of software system
Depicts interaction between
use cases and actors
use cases and use cases
actors and actors
Depicts a set of use cases, a set of actors, and the relationships between the use cases and actors
Janice Regan,

10. UML: Use Case Diagrams Actor Use case Use case name Relationships:
Dependency
(extension and inclusion)
Association (communication)
Generalization
Janice Regan,

11. Part of Use Case Diagram: Shows Communication
Relation between actor and use case is a communication if
Actor initiates use case
Actor supplies information to use case
Actor receives information from use case
Use case initiates another use case
Part of Use Case Diagram: Shows Communication
Use Case
Janice Regan,

12. Relationships: Dependency
Dependency: Class A is said to depend on class B if
A uses at least one feature of B, e.g., it accesses one of B’s data fields or invokes one of its methods.
Changing the specification of B may change A (A uses or depends on B) but not necessarily the reverse A B
Janice Regan,

13. Use Case Diagrams Dependency Relationship: <<include>>
Encapsulates common logic required by several use cases into one included use case
Used for factoring out common behaviour (promote “reuse”)
Can also be used to break a large and complicated used case into smaller more manageable parts
Source Use Case or Base Use Case
inclusion use case
or target use case
<<include>>
Janice Regan,

14. Use Case Diagrams Dependency Relationship: <<include>>
Make Meat Pie
<<include>>
<<include>>
Make Apple Pie
Make Pie Crust
<<include>>
Make Cherry Pie
Janice Regan,

15. LMS: Partial Use Case Diagram
BrowseResource
Check out resource
<<include>>
Verify Patron
ReserveResource
<<include>>
CheckInResource
Patron
<<include>>
Librarian
Determine Overdue Charge
Janice Regan,

16. Use Case Diagrams Dependency Relationship: <<extend>>
Extension use case defines logic that may be required during a base use case
Exceptional logic that is not always needed
Can be a conditionally executed separate subflow (label with condition)
One of several possible flows that may be inserted at a given point governed by interaction with the actor
Janice Regan,

17. <<extend>>
Use Case Diagrams
Dependency Relationship: <<extend>>
Source use case extends the behavior of the target use case
Allows options to be extension cases
Source Use Case
or Extension Use Case
Target Use Case
Or Base Use Case
<<extend>>
Janice Regan,

18. Use Case Diagrams Dependency Relationship: <<extend>>
Make optional cherry
crème topping
<<extend>>
Make cherry pie
<<extend>>
Baking in Microwave
<<extend>>
Baking in Convection oven
Janice Regan,

19. Use Case: overlapping roles (good practice indicates 1 initiating actor per use case)
Recording Grades
Design Course
Regular Faculty
Record Grades
Registrar
Sessional Lecturer
Janice Regan,

20. Relationship Resource Book Video Music CD
Generalization: book, music CD, videos are resources
Resource
general
specific
Book
Video
Music CD
Janice Regan,

21. Use Case: overlapping roles (1 initiating actor per use case)
Recording Grades
Record Grades
Instructor
Registrar
Design Course
Sessional
Lecturer
Regular
Lecturer
Janice Regan,

22. Modeling the context of a system From: Booch, Rumbaugh, Jacobson
Credit Card Validation System
Perform Transaction
Retail
Institution
Process Customer Bill
Customer
Reconcile Transactions
Financial
Institution
Manage Customer
Account
Individual
Customer
Corporate
Customer
Janice Regan,

23. Constructing a Use Case Diagram
Identify all actors (primary and secondary)
For each actor
Identify each function the actor expects from the system (can consider the whole system or a few requirements at a time)
Name each of these functions, and consider it to be a use case
Janice Regan,

24. Constructing a Use Case Diagram
Analyze the use cases
Determine which actor (one only) or which use case initiates each use case
Find any actions common to multiple use cases.
Use the <<include>> dependency to connect the use case for the common action to the original use cases
Find any actions that are done rarely/sometimes
Use the <<extend>> dependency to factor out use cases that are extensions
Janice Regan,

25. Validation & Verification
Are we building the right product?
To facilitate validation we number our functional requirements and propagate these numbers throughout our models and source code, validating that all functional requirements are parts of the system.
Verification:
Are we building the product right?
Janice Regan,