CMPT 275 Software Engineering: Requirements Analysis

CMPT 275
Software Engineering
Requirements Analysis Phase
Requirements Analysis Activity
(Identifying Objects, Scenarios)
Requirements Analysis
D You made a list of functional requirements
Describe the required interactions between the
system and its environment (independent of
implementation)
D You made list of non-functional requirements

QUALITY REQUIREMENTS: Usability, reliability,
performance, maintainability
CONSTRAINTS or PSEUDO REQUIREMENTS:
Implementation (tools, languages), interface (to
external systems), operation (admin, management),
packaging, Legal
Janice Regan, 2008 2
1
D Now you need to validate and verify your
requirements to assure that they are
Complete: all required features must be
described
Consistent: no two requirements in the
specification may contradict each other
Unambiguous: no requirement can be
interpreted in two different and contradictory
ways
Correct: Only features desired by the client /
developer are included not unintended extra
features (problems)
D You continued to build your analysis model
and verify/validate your requirements by
Identifying the actors for your system
Building a system context diagram to clarify
what is part of your proposed system
Identifying and developing informal scenarios
that describe all functions of your system
Building use cases based on groups of related
informal scenarios
Building a functional model of your system by
investigating relationships between use cases
and actors and making a use case diagram
2
Requirements Analysis Activity
Software
Client/User Developer
Update SRS
Use Case Centered Development (UCCD)
Use Case
Questions Diagram Use Cases
Class Primary System

Diagram Scenarios Context
Classes Diagram
State
Diagram
UML: Unified Modeling Language

D Used in this course for analysis models of
System functionality
use case diagrams, use cases and scenarios
Objects and their static relationships
class diagrams, analysis models
Dynamic behavior
state diagrams, collaboration diagrams

sequence diagrams
3
From use cases to classes
D Consider one use case, make a class
diagram
1. Identify primary classes to describe the
objects involved in a use case
2. Add the relationships between these classes
extracted from the use case and / or the
requirements satisfied by the use case
D Consider additional use cases one by one,

adding the additional primary classes and
relationships between classes
Primary Classes (objects)

D Primary Classes are abstractions that describe the
attributes and behaviors of sets of objects
D According to the rational unified process (RUP)
Primary classes can be of one of three types,
D Primary Entity classes represent entities
(objects) present in conceptualization
D Primary Boundary Classes model interfaces
with external entities (actors)
D Primary Control Classes model coordination
and sequencing of events/calculations and
manipulation of instances of entity classes
4
From use cases to classes
D For the Rational Unified Process
For each use case need at least one interface
class
For each used case need one (rarely more)
control class
For each use case identify primary entity
classes to describe the objects involved
Make a class diagram for each class, then
combine. Or make a analysis model for one
use case, then add additional use cases
UML for RUP analysis models

D Entity Classes
D Boundary Classes
D Control Classes
5
Use case diagram for ATM
Deposit
Transfer
Bank database
customer
Withdraw
D Identified primary entity class, account
Example: ATM analysis model

dispenser withdrawal
Database
query or
Cashier response Database
interface translator query or
response
Bank transfer account

customer Money
receptor
deposit database
6
Primary Entity Classes
D Model phenomena or concepts
real life objects or events in the application
domain
Other objects, events or concepts handled by
the system
D Require long term or persistent storage of
information describing their instances (objects).
D May be passive or active (encapsulate complex
behavior related to the information it represents)
D Isolate changes to the data they represent
Identifying Primary Entity Classes
D Look for application domain (real world)

things and roles that the use case is
tracking or manipulating
D Look for application domain (real world)
events that the use case is tracking or
manipulating
D Look for recurring references to objects in
the use case (recurring nouns)
7
Identifying Primary Entity Classes
D To identify entities that should be represented by
primary classes select nouns from the use case
and functional requirements for the use case,
inspect each noun (start with recurring nouns) for
the following properties
Retained information
Common attributes (different instances)
Multiple attributes
Needed services
Common operations
Primary Entity Class ?

D Retained information
Primary entity classes require long term or
persistent storage of information describing
their instances (objects).
Consider some examples from the LMS
Patron
Home phone number of each patron
Book
All of these examples require persistent storage

of information describing their instances
8
D Multiple attributes, Common attributes
Is there more than one attribute (other noun)
describing the candidate for primary class?
Home phone number of patron ? NO
Book (title, publisher, call number, …)
Patron (type, home phone #, address …)
Can these attributes be used to describe each

object in the candidate primary class?
YES (for Book and Patron)

D Needed services, common services
Are operations needed to manipulate the
persistent data?
Do such operations need to be available to other
classes?
Books, patrons and home phone numbers must be
added, removed, and information describing them
must be updated. Not enough, what else
Books and patrons must have services to update their
values when a patron checks out, checks in, reserves,
or requests a book.
9
Boundary Classes
D Model the interaction of a system and its actors
Receiving information from the actor
Presenting information to the actor
D Represent abstractions of API’s, sensors, input
/ output devices, external data repositories,
forms …
Model conceptually what requests and information
exchanged (no details of how or interface, just what)
D Each boundary class should be associated with
at least on actor. Each actor should be
associated with at least one boundary class
Identifying Boundary Classes

D Actor interfaces with parts of the system
(ATM client interface)
D Identify forms needed to enter data
(Ballot entry form)
D Identify messages (notices) used to
respond to actor input
10
Control Classes
D Control sequence of events, coordination between
classes
D May represent complex sequences of calculations
not related to one specific entity class
D Do not usually represent a concrete object in the
real world
D Do not deal with interaction with actors or with
management of persistent data
D The lifespan of the object should cover the use
case duration or the duration of the user session
Support Classes
D Container classes
e.g.: List and Hash Table classes
D Service classes
e.g.: Stream classes
D They are not present in conceptualization

of software system
D The need for these classes identified
during design
11
Formal Scenario Development
D Scenarios are derived from use cases
D Scenarios are like informal scenarios, but

are more formally structured
D Use cases are abstract because they do
not reference specific values
D Scenarios are concrete because they do
reference specific and plausible values
D Multiple scenarios may be required for a
single use case
Example: Scenario #1
D Use Case Name: CheckInResource (#7)
D Scenario: Paul returns an overdue book by

coming to the library counter.
D Preconditions:
Eva the Librarian has successfully gained access
to the LMS.
LMS is ready to go (DB has been populated and
LMS has been initialized).
Options screen is displayed
12
Example: Scenario #1 (cont)
D Main flow of events:
Patron Paul (a student) comes up to the counter
and wishes to return the Quantum Physics book
he borrowed the previous semester.
Eva the librarian takes the book Paul is handing
out to her selects CHECKINRESOURCE option and
types in its valid Dewey call number.
The LMS displays the information related to the
Quantum Physics book on the screen and let
Eva know that Paul owes the library $5 (max.).

D Main flow of events: (cont)
Eva notifies Paul of his overdue charge and
Paul, after searching throughout all his
pockets, produces a $5 bill.
Eva makes sure that Paul's record is now
clean and that no one has requested the
book. Since no one has, Eva verifies by
looking at the screen that the book has been
checked in properly.
Paul wishes Eva "Good day" and departs.
13
D Post conditions:
Paul’s record is now showing that he has
returned the Quantum Physics book and that
he has paid the overdue charge. The
Quantum Physics book has now a status of
"reshelve", today's date as a date of return,
date of loan has been cleared and so as the
due date.
NO NEED FOR EXCEPTIONAL FLOW OF EVENTS!!!

Each exceptional flow of events would be another
scenario
D Use Case Name: CheckInResource (#7)
D Scenario: Paul returns an overdue book by

putting it in the return box.
D Preconditions:
Eva the Librarian has successfully gain access
to the LMS.
LMS is ready to go (DB has been populated
and LMS has been initialized).
14
D Main flow of events
Patron Paul (a student) has deposited the
Quantum Physics book he borrowed the
previous semester in the return box.
Eva the librarian takes the book from the
return box and types in its Dewey call
number.
D Main flow of events (Cont)
The LMS displays the information related to
the Quantum Physics book on the screen and
lets Eva know that the borrowing patron Paul
owes the library $5. Eva makes sure that
Paul's record reflects such overdue charge.
Then Eva ensures that no one has requested
the book. Since no one has, Eva verifies
looking at the screen that the book has been
checked in properly.
15
D Post conditions:
Paul record now showing an overdue charge
of $5 (since it was overdue by quite a few
weeks). The Quantum Physics book has now
a status of "reshelve", today's date as a date
of return, date of loan has been cleared and
so as the due date.
16

CMPT 275 Software Engineering: Requirements Analysis

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

CMPT 275 Software Engineering: Requirements Analysis

Diunggah oleh

Hak Cipta:

Format Tersedia

CMPT 275

D You made list of non-functional requirements

Use Case Centered Development (UCCD)

Class Primary System

Janice Regan, 2008 5

UML: Unified Modeling Language

 use case diagrams, use cases and scenarios

 Objects and their static relationships

 class diagrams, analysis models

 state diagrams, collaboration diagrams

D Consider additional use cases one by one,

Primary Classes (objects)

UML for RUP analysis models

Janice Regan, 2008 10

D Identified primary entity class, account

Janice Regan, 2008 11

Example: ATM analysis model

Bank transfer account

Janice Regan, 2008 13

Identifying Primary Entity Classes

D Look for application domain (real world)

Janice Regan, 2008 14

Janice Regan, 2008 15

Primary Entity Class ?

 Home phone number of each patron

 All of these examples require persistent storage

 Patron (type, home phone #, address …)

 Can these attributes be used to describe each

Janice Regan, 2008 17

Primary Entity Class ?

Janice Regan, 2008 18

Identifying Boundary Classes

Janice Regan, 2008 20

D They are not present in conceptualization

D Scenarios are like informal scenarios, but

D Scenario: Paul returns an overdue book by

Janice Regan, 2008 25

Example: Scenario #1 (cont)

Janice Regan, 2008 26

NO NEED FOR EXCEPTIONAL FLOW OF EVENTS!!!

D Scenario: Paul returns an overdue book by

Janice Regan, 2008 28

Janice Regan, 2008 29

Janice Regan, 2008 30

Janice Regan, 2008 31

Anda mungkin juga menyukai

use case diagrams, use cases and scenarios

Objects and their static relationships

class diagrams, analysis models

state diagrams, collaboration diagrams

Home phone number of each patron

All of these examples require persistent storage

Patron (type, home phone #, address …)

Can these attributes be used to describe each