Requirements Analysis Phase
Requirements Analysis activity
Janice Regan, 2008-2014 1




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 nonfunctional requirements. Each functional requirement represent all or part of at least one function/activity
Functional requirements are not dependent on specific methods of implementation
2 Janice Regan, 2008-2014

 Role: clear and effective way to represent and analyze (model) various aspects of software system
 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)
3 Janice Regan, 2008-2014

 Next you will proceed using use case centered development (UCCD) to analyze that model






System Context Diagram
Identifying Actors and developing Use Cases
Primary classes
Use cases and Scenarios (formal and informal)
Use case Diagram
Class (object) Diagram
4 Janice Regan, 2008-2014

Client/User
Software
Developer
Update SRS
Use Case Centered Development (UCCD)
Questions
Janice Regan, 2008-2014
Class
Diagram
Use Case
Diagram
Use Cases
Scenarios
Primary
Classes
State
Diagram
System
Context
Diagram
5

 Models the composition of classes and the relationships between classes


Shows a set of classes, interfaces, and collaborations (used in design), and their relationships

Dependency, generalization, and association relationships are represented
Models a static perspective (emphasizes structure not behavior of the system) of the system

Primarily supports the definition of functional requirements of a system. (services the system provides to users)
Janice Regan, 2008-2014 6

Class
Class Name
Methods
Relationships:
Dependency
Association: application-related
Association: aggregation
Association: composition Generalization Realization
Janice Regan, 2008-2014
Detailed Class
Class Name
Attributes
Stereotype
Analysis Only
Class Name
Class Name
Class Name
7

 Association:

Aggregation: catalog has resources

ONLY distinguishes a whole from a part, may be a part of multiple wholes, destroying the catalog does not destroy the resources
 whole Catalog Resource part
Composition: game board is composed of squares

Strong aggregation: square can be part of 1 board only, destroying the board (whole) must destroy the squares (parts) as well whole
Janice Regan, 2008-2014
Game board squares part
8

 Association:

Application-specific: patron checks out a resource
Patron
0..1
staff
 Is checked out by
0..8
book
Resource
 Application specific Association: The label
“  Is checked out by” indicates what action this relation between classes represents. Such labels are used to identify associations with actions other than obvious ones such as uses
Janice Regan, 2008-2014 9

 Association:

Bi directional Each object knows about the other (arrows are optional)
Patron
0..1
student
 Is checked out by
0..4
video
Resource
 Roles: A patron may be a faculty member a student …, we can use a role, the text next to the patron box to indicate that the relation shown applies only to the specialized patron class student.
10 Janice Regan, 2008-2014

 Association:

Application-specific: patron checks out a resource
Patron
0..1
faculty checks out 
0..2
painting
Resource
 Multiplicity of an association: # of entities
“from this side” that can be associated with an entity ‘of the other side’, exact: n, range: 0..1, 0..n, 1..n, set: 1, 3..20, unspecified: 1..*, *
11 Janice Regan, 2008-2014






The patron entity (primary entity class) is not the same as the patron actor.
The patron primary entity class contains attributes describing the actor and methods to manipulate those attributes within the LMS.
The patron actor is external to the system and acts on the system,
The patron entity (class) is part of the system
When building a class diagram consider the interactions of the classes not the actors
12 Janice Regan, 2008-2014

Patron
Entity
0..*
Put on hold
0..* Book
Entity
 Patron entity is associated with the book entity through the “put on hold” relationship


Patron and Book attributes will be updated to reflect the hold
Patron and Book methods may be used to update the information.
Patron Actor

Janice Regan, 2008-2014
Actor not equivalent to entity
13

 Association:

Uni directional Overdue letter knows about the resources (single arrow is not optional) but the resources do not know about the overdue letter
1
Overdue letter Resource

 report classes can know about the class they report without those classes knowing about them
Also useful for relating classes to classes defining complex attribute
14 Janice Regan, 2008-2014

 Generalization: book, music CD, videos are resources general
specific
Janice Regan, 2008-2014
15

 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
16 Janice Regan, 2008-2014

 Association Class

Add attributes, operations to associations

Usually used when a relation between classes
A and B is a many to many association

Helps you represent the case when there can be only one association between each member a of class A and each member b of class B
17 Janice Regan, 2008-2014

student
1..100
0..6
seminar student
1..100
0..6
registration seminar


Consider a course registration system.
Lower diagram gives additional information: each student has only one association with each seminar.
(A student cannot register twice in one seminar)
18 Janice Regan, 2008-2014

patient
1..* patient
0..* doctor doctor


Consider a system for recording appointments in a medical clinic
Each patient can have many appointments with each doctor.
0..* appointment
1..*
19 Janice Regan, 2008-2014







You will have 2-3 minutes to discuss with your team what classes you will need in the class diagram
After your discussions, I will choose one requirement or one group of requirements
You will have another 1-2 minutes to decide how to add that requirement to the class diagram
I will then choose a team randomly and ask one of the team members to come and add that requirement to the class diagram
I will repeat this until all requirements have been added
After each requirement is added we will discuss what has been added, and other ways of adding the same requirement (if any)
20 Janice Regan, 2008-2014


Consider a University (we will be building a registration system)






Instructors are part of one or more departments
A course offering is a course offered in a particular term
Each course offering is taught by one instructor
2 offerings of the same course can have different instructors
Instructors teach course offerings (<=4 per term)
Students take course offerings (<=8 per term)




Students can be full time students or part time students
Faculties consist of departments
Departments offer course offerings
Students are part of one department

We want to build a class diagram for this university
21 Janice Regan, 2008-2014