1 CMPT 275 Software Engineering Requirements Analysis Phase Requirements Analysis 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, UML Analysis models  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)

Janice Regan, 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  Primary classes  Use cases and Scenarios (formal and informal)  Use case Diagram  Class (object) Diagram

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

Janice Regan, Class Diagrams  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, UML: Class Diagrams Class Name ClassDetailed Class Relationships: Dependency Association: application-related Generalization Class Name Attributes Methods Association: aggregation Association: composition Stereotype Analysis Only Class Name Realization

Janice Regan, Relationships: 1  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  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 CatalogResource Game board squares part whole part

Janice Regan, Relationships: 2  Association:  Application-specific: patron checks out a 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 Patron Resource  Is checked out by staff book

Janice Regan, Relationships: 3  Association:  Bi directional Each object knows about the other (arrows are optional)  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. Patron Resource  Is checked out by student video

Janice Regan, Relationships: 4  Association:  Application-specific: patron checks out a 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..*, * Patron Resource checks out  faculty painting

Janice Regan, Actors and Entities (classes)  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

Janice Regan, Sample Association  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.  Actor not equivalent to entity Patron Actor Patron Entity Book Entity 0..* Put on hold

Janice Regan, Relationships: 5  Association:  Uni directional Overdue letter knows about the resources (single arrow is not optional) but the resources do not know about the overdue letter  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 Overdue letterResource 1

Janice Regan, Relationships: 6  Generalization: book, music CD, videos are resources Resource Book Video Music CD general specific

Janice Regan, Relationships: 7  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

Relationships: 8  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 Janice Regan,

Association classes  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) Janice Regan, studentseminar student seminar registration

Relationships: 9  Consider a system for recording appointments in a medical clinic  Each patient can have many appointments with each doctor. Janice Regan, patient doctor patient doctor appointment 1..* 0..* 1..*

Janice Regan, Class Exercise  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)

Janice Regan, Class exercise  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