1 CMPT 275 Software Engineering Requirements Analysis Phase Requirements Analysis Activity...

1

CMPT 275Software EngineeringRequirements Analysis Phase

Requirements Analysis Activity(Identifying Objects, Scenarios)

Janice Regan, 2008-2014

Janice Regan, 2008-2014 2

Requirements Analysis You made a list of functional requirements

Describe the required interactions between the system and its environment (independent of implementation)

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


Requirements Analysis 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)


Requirements Analysis 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


Requirements Analysis ActivitySoftware

DeveloperClient/User

Update SRS

Questions

Use Case Centered Development (UCCD)

System Context Diagram

Use Cases

Primary Classes

Use Case Diagram

State Diagram

ClassDiagram Scenarios


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, analysis models

Dynamic behavior

state diagrams, collaboration diagrams sequence diagrams


From use cases to classes 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

Consider additional use cases one by one, adding the additional primary classes and relationships between classes


Primary Classes (objects) Primary Classes are abstractions that describe the

attributes and behaviors of sets of objects According to the rational unified process (RUP)

Primary classes can be of one of three types, Primary Entity classes represent entities

(objects) present in conceptualization Primary Boundary Classes model interfaces

with external entities (actors) Primary Control Classes model coordination

and sequencing of events/calculations and manipulation of instances of entity classes


From use cases to classes 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 Entity Classes

Boundary Classes

Control Classes


Use case diagram for ATM

Identified primary entity class, account

Bank customer

database

Deposit

Transfer

Withdraw


account

Example: ATM analysis model dispenser

Cashier interface

Money receptor

withdrawal

transfer

deposit

Bank customer

database

Database query orresponse

Database query orresponse translator


<<control>>transfer

Example: ATM analysis model

transfer

<<Boundary>>dispenser

<<control>>withdrawal

<<Boundary>>receptor

<<control>>deposit

<<Boundary>>Cashier interface

<<entity>>account

<<Boundary>>Database interface


Primary Entity Classes Model phenomena or concepts

real life objects or events in the application domain

Other objects, events or concepts handled by the system

Require long term or persistent storage of information describing their instances (objects).

May be passive or active (encapsulate complex behavior related to the information it represents)

Isolate changes to the data they represent


Identifying Primary Entity Classes

Look for application domain (real world) things and roles that the use case is tracking or manipulating

Look for application domain (real world) events that the use case is tracking or manipulating

Look for recurring references to objects in the use case (recurring nouns)


Identifying Primary Entity Classes 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 ? 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


Primary Entity Class ? 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)


Primary Entity Class ?

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.


Boundary Classes Model the interaction of a system and its actors

Receiving information from the actor Presenting information to the actor

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)

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 Actor interfaces with parts of the system

(ATM client interface)

Identify forms needed to enter data (Ballot entry form)

Identify messages (notices) used to respond to actor input


Control Classes Control complex sequences of events or

calculations DO NOT DO calculations/tasks USE functionality of classes, coordinating execution order

of tasks done by and events important to the entity classes (>2) involved

Do not usually represent a concrete object in the real world

Do not deal with interaction with actors The lifespan of the object should cover the use

case duration or the duration of the user session


Support Classes Container classes

e.g.: List and Hash Table classes

Service classes

e.g.: Stream classes

They are not present in conceptualization of software system

The need for these classes identified during design


Formal Scenario Development Scenarios are derived from use cases

Scenarios are like informal scenarios, but are more formally structured

Use cases are abstract because they do not reference specific values

Scenarios are concrete because they do reference specific and plausible values

Multiple scenarios may be required for a single use case


Example: Scenario #1 Use Case Name: CheckInResource (#7)

Scenario: Paul returns an overdue book by coming to the library counter.

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


Example: Scenario #1 (cont) 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 lets Eva know that Paul owes the library $5 (max.).


Example: Scenario #1 (cont) 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.


Example: Scenario #1 (cont) 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


Example: Scenario #2 Use Case Name: CheckInResource (#7)

Scenario: Paul returns an overdue book by putting it in the return box.

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).


Example: Scenario #2 (cont) 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.


Example: Scenario #2

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.


Example: Scenario #2

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.

1 CMPT 275 Software Engineering Requirements Analysis Phase Requirements Analysis Activity...

Documents

Transcript of 1 CMPT 275 Software Engineering Requirements Analysis Phase Requirements Analysis Activity...