1 requirements - 1. 2 software development activities application domain objects subsystems class......

1

Requirements - 1

2

Software Development Activities

Application

Domain Objects

SubSystems

class...class...class...

Implementation

Domain Objects

SourceCode

Test Cases

?

Expressed in Terms Of

Structured By

Implemented

ByRealized By Verified By

SystemDesign

ObjectDesign

Implemen-tation

Testing

class....?

RequirementsElicitation

Use CaseModel

RequirementsAnalysis

3

Types of Projects

• Greenfield Engineering– Development starts from scratch, no prior system

exists, the requirements are extracted from the end users and the client

• Re-engineering– Re-design and/or re-implementation of an existing

system using newer technology

• Interface Engineering– Resign of the user interface of an existing system

4

Requirements Elicitation

• Challenging activity• Requires collaboration of people with different

backgrounds– User has application domain knowledge– Developer has implementation domain knowledge

• Define the system– Easy to define (and then solve) the wrong problem

5

Requirements Process

• Requirements Elicitation– Definition of the system in terms understood by

the customer

• Analysis– Technical specification of the system in terms

understood by the developer.

6

Products of Requirements Process


analysis model:Model

systemspecification

:Model

Analysis

7

System Specification vs Requirements Analysis Model

• Both focus on the requirements from the user’s view of the system.

• System specification uses natural language (derived from problem statement)

• Requirements analysis model uses formal or semi-formal notation (e.g., UML)

8

Types of Requirements

• Functional requirements: Describe the interactions between the system and its environment independent from implementation– The watch system must display the time based on its

location

9


• Nonfunctional requirements: User visible aspects of the system not directly related to functional behavior. – The response time must be less than 1 second– The accuracy must be within a second– The watch must be available 24 hours a day

except from 2:00am-2:01am and 3:00am-3:01am

10


• Constraints (“Pseudo requirements”): Imposed by the client or the environment in which the system will operate– The implementation language must be JAVA. – Must interface to the dispatcher system written in

1956.

11

Requirements Elicitation Activities

• Identify actors• Identify scenarios• Identify use cases• Identify relationships among use cases• Refine use cases• Identify nonfunctional requirements• Identify participating objects

12

Actors• What’s an ACTOR?

– An external entity that interact with the system– Can be human or an external system

• How do we identify them?– Which user groups are supported by the system to perform their

work– Which user groups execute the system’s main function?– Which user groups perform secondary function, such as

maintenance and administration?– Will the system interact with any external hardware or software

system?

• The choice of actors helps us to define the system boundary, and the system boundary helps us to identify the actors

13

Example: SatWatch

SatWatch is a wrist watch that displays the time based on its current location. It uses GPS satellites to determine its location and internal data structures to convert this location into a time zone. Satwatch adjusts the time and date displayed as the watch owner crosses time zones and political boundaries (e.g., standard time vs. daylight savings time)

When a new country or institutes different rules for daylight saving time, the watch owner may upgrade the software of the watch using the WebifyWatch serial devices and a personal computer connected to the Internet. SatWatch complies with the physical electrical, and software interfaces defined by WebifyWatch API2.0.

14

Tools

Bridging the gap between user and developer …– Scenario:

• Example of the use of the system in terms of a series of interactions between the user and the system

• Concrete / Real / Phenomenon– Use case:

• Abstraction that describes a class of scenarios• Concept

15

Scenarios

• “A narrative description of what people do and experience as they try to make use of computer systems and applications” [M. Carrol, Scenario-based Design, Wiley, 1995]

• A concrete, focused, informal description of a single feature of the system used by a single actor.

• Scenarios can have many different uses during the software lifecycle

16

Types of Scenarios

• As-is scenario– Used in describing a current situation. Usually used

during re-engineering. The user describes the system.

• Visionary scenario– Used to describe a future system. Usually described

in greenfield engineering or reengineering. – Often can not be done by the user or developer alone– Can be viewed as an inexpensive prototype

17

Types of Scenarios

• Evaluation scenario– User tasks against which the system is to be

evaluated

• Training scenario– Step by step instructions designed to guide a

novice user through a system

18

Heuristics for finding Scenarios• Ask yourself or the client the following questions:

– What are the primary tasks that the system needs to perform?

– What data will the actor create, store, change, remove or add in the system?

– What external changes does the system need to know about?

– What changes or events will the actor of the system need to be informed about?

19

Heuristics for finding Scenarios

• Insist on task observation if the system already exists (interface engineering or reengineering)– Ask to speak to the end user, not just to the

software contractor– Expect resistance and try to overcome it

20

Scenario Example: Warehouse on Fire

• Bob is driving down main street in his patrol car and notices smoke coming out of a warehouse. His partner, Alice, reports the emergency from their car.

• Alice reports the address of the building, a brief description of its location (i.e., north west corner), and an emergency level. In addition to a fire unit, she requests several paramedic units on the scene given that area appear to be relatively busy. She confirms her input and waits for an acknowledgment.

21

Scenario Example: Warehouse on Fire (continued)

• John, the Dispatcher, is alerted to the emergency by a beep of his workstation. He reviews the information submitted by Alice and acknowledges the report. He allocates a fire unit and two paramedic units to the Incident site and sends their estimated arrival time (ETA) to Alice.

• Alice receives the acknowledgment and the ETA.

22

Observations about Warehouse on Fire Scenario

• Concrete scenario– Describes a single instance of reporting a

fire incident.– Does not describe all possible situations in

which a fire can be reported.

• Participating actors– Bob, Alice and John

23

Next goal, after the scenarios are formulated:

• Find a use case in the scenario that specifies all possible instances of how to report a fire– Example: “Report Emergency “ in the first paragraph of the

scenario is a candidate for a use case

• Describe this use case in more detail – Describe the entry condition – Describe the flow of events – Describe the exit condition – Describe exceptions– Describe special requirements (constraints, nonfunctional

requirements)

24

Example of steps in formulating a use case

• First name the use case– Use case name: ReportEmergency

• Then find the actors– Generalize the concrete names (“Bob”) to participating actors

(“Field officer”)– Participating Actors:

• Field Officer (Bob and Alice in the Scenario)• Dispatcher (John in the Scenario)• ?

• Then concentrate on the flow of events– Use informal natural language

25


• Formulate the Flow of Events (Figure 4-7):– The FieldOfficer activates the “Report Emergency” function on

her terminal. FRIEND responds by presenting a form to the officer.

– The FieldOfficer fills the form, ... The FieldOfficer also describes possible responses to the emergency situation. Once the form is completed, the FieldOfficer submits the form, …

– The Dispatcher reviews the submitted information and creates an Incident in the database by invoking the OpenIncident use case. The Dispatcher …

– The FieldOfficer receives the acknowledgment and the selected response.

26


• Write down the exceptions:– The FieldOfficer is notified immediately if the connection

between her terminal and the central is lost.– The Dispatcher is notified immediately if the connection

between any logged in FieldOfficer and the central is lost.

• Identify and write down any special requirements:– The FieldOfficer’s report is acknowledged within 30

seconds. – The selected response arrives no later than 30 seconds

after it is sent by the Dispatcher.

27

How to Specify a Use Case (Summary)

• Name of Use Case• Actors

– Description of actors involved in use case

• Entry condition – Use a syntactic phrase such as “This use case starts when…”

• Flow of Events – Free form, informal natural language

• Exit condition – Start with “This use cases terminates when…”

• Exceptions – Describe what happens if things go wrong

• Special Requirements – List nonfunctional requirements and constraints

28

Use Case Model for Incident Management

ReportEmergency

FieldOfficer DispatcherOpenIncident

AllocateResources

29

Why use cases work• Utterly comprehensible by the user

– Use cases model a system from the users’ point of view (functional requirements)

• Define every possible event flow through the system• Description of interaction between objects

• Great tools to manage a project. Use cases can form basis for whole development process

– User manual– System design and object design– Implementation– Test specification– Client acceptance test

• An excellent basis for incremental & iterative development

30

Requirement– 2

31

Use Case Associations

• Developing a Use Case model involves breaking up use cases in search of simpler ones

• Use case association = relationship between use cases

• Three types supported in UML: – Extends– Include– Generalization (not in text)

32

Extend• A base use case implicitly includes the

behavior of another use case at one or more extension points

• Generally used to factor out behavior that is optional or occurs only under certain conditions

• E.g. alternate or exceptional cases

Exception case Normal case<<extend>>

33

<<extend>>

Check Order Status

Cancel Order

<<extend>>

E.g. In the course of checking on the status of an order, the user finds that the item ordered won’t be in stock for 2 months. The user decides to cancel the order.

34

Include• One use case explicitly includes the behavior

of another use case at a specified point within a course of action

• Useful in factoring out behavior that would otherwise occur in multiple use cases

Base case Included case<<include>>

35

<<include>>

View account

Login

<<include>>

Place order<<include>>

36

Generalization• Parent use case defines behavior that the

child use cases can inherit and override• Similar to inheritance in classes

Parent Use Case

Child Use Case

37

Generalization

Perform Search

Search by Author

Search by Title

Search by Date

38

How do I find use cases?• Select a narrow vertical slice of the system (i.e. one

scenario) – Discuss it in detail with the user to understand the user’s

preferred style of interaction

• Select a horizontal slice (i.e. many scenarios) to define the scope of the system. – Discuss the scope with the user

• Find out what the user does– Task observation (Good)– Questionnaires (Bad)

• Draw and revise use case diagram– Discuss with the user

39

From Use Cases to ObjectsTop Level Use Case

Level 2 Use Cases

Level 3 Use Cases

Operations

ParticipatingObjects

Level 2

Level 1

Level 2

Level 3 Level 3

Level 4 Level 4

Level 3

A B

40

Finding Participating Objects in Use Cases

• Find terms that developers or users need to clarify in order to understand the flow of events

• Identify real world entities that the system needs to keep track of. Examples: FieldOfficer, Dispatcher, Resource

41

Finding Participating Objects in Use Cases

• Identify real world procedures that the system needs to keep track of. – Example: EmergencyOperationsPlan

• Identify data sources or sinks. – Example: Printer

• Identify interface artifacts. – Example: PoliceStation

• Do textual analysis to find additional objects (Use Abott’s technique)

• Model the flow of events with a sequence diagram

42

Abbott’s Heuristics

Part of Speech Model Component Example

Proper Noun Object Fred

Common Noun Class Student

Doing Verb Operation Selects

Being Verb Inheritance Is a kind of

Having Verb Aggregation Has

Modal Verb Constraints Must be

Adjective Attribute Full-time

43

Identifying Nonfunctional Requirements -1

• User interface and human factors– What kind of interface? What’s the level of user expertise?

• Documentation– What level of documentation

• Hardware considerations– Hardware compatibility, interaction with other hardware system

• Performance characteristics– How responsive? How many concurrent users should it

support?

• Error handling and extreme conditions– Which exception should be handled? How? What’s the worst

environment in which the system is expected to perform?

44

Identifying Nonfunctional Requirements

• Quality issues– How reliable/available/robust?

• System modifications– Anticipated scope of future change? Who will perform

change?

• Physical environment– Where will the system be deployed? Weather condition?

• Security issues– Should the system be protected against external intrusions?

• Resource issues– Constraints on resource

45

Analysis - (1)

Analysis

46

Overview of Analysis

• Formalize the specification produced during requirements elicitation

• Developers build a model of the application domain– What are the objects?– What are their attributes?– How do the actors and the system interact?

• Why do we call it ANALYSIS?– Define analysis

47

Analysis1. A separating or breaking up of any whole into its parts so as

to find out their nature, proportion, function, relationship, etc. Webster’s New World Dictionary

48

Products of requirements elicitation and analysis

SystemDesign

system model:Model

systemspecification

:Model

analysis model:Model


Analysis

49

The Analysis Model

analysismodel:Model

dynamicmodel:Model

objectmodel:Model

functionalmodel:Model

use casediagram:View

classdiagram:View

statechartdiagram:View

sequencediagram:View

50

UML: Class and Instance Diagrams

Inspector

joe:Inspector

mary:Inspector

anonymous:Inspector

Class Diagram

Instance Diagram

51

Analysis Concepts

• Types of objects modeled in analysis– Entity– Boundary– Control

• Associations used in analysis model– Multiplicity– Aggregation

• Generalization

52

Analysis Objects

• Entity– Persistent information tracked by the system– Correspond to the nouns in the uses cases– E.g. Book

• Boundary– An object with which the actor of a use case interacts with

the system (e.g., form)

• Control– Represent the tasks performed by the user and supported

by the system– E.g. Display (verb)

53

Analysis Objects

• Why the three types?– Results in smaller and more specialized objects– Leads to models that are more resilient to change

• Interface most likely to change– Will help with sequence diagrams– Control objects serve as “connecting tissue”

between users and stored data

• Object types originated in Smalltalk:– Model, View, Controller (MV)

54

Example: 2BWatch Objects

<<entity>>Year

<<entity>>Month

<<entity>>Day

<<control>>ChangeDateControl

<<boundary>>LCDDisplayBoundary

<<boundary>>ButtonBoundary

• UML provides the stereotype mechanism to present new modeling elements– stereotype is a string enclosed by angle brackets, which is attached to a UML

element, such as a class or an association – It enables modelers to create new kinds of building blocks that are needed in their

domain

• Use naming convention: suffix “Control”, “Boundary”

55

1-to-1 and 1-to-many Associations

Has-capital

One-to-one association

One-to-many association

City

name:String

Workorder

schedule()

StickyNote

x: Integery: Integerz: Integer

*

Country

name:String

56

Object Instance Diagram

Example for 1-to-many

:Sticky

x,y,z=(-1,0,5)

:WorkOrder :Sticky

x,y,z=(1,10,1)

:Sticky

x,y,z=(10,1,2)

57

Many-to-Many Associations

Work on **Mechanics Plane

58

Aggregation

• Models "part of" hierarchy• Useful for modeling the breakdown of a product

into its component parts• UML notation: uses a small diamond to indicate the

assembly end of the relationship.

59

weight

Automobile

serial numberyearmanufacturermodelcolor

drivepurchase

AggregationEngine

horsepowervolume

onoff

3,4,5

Wheel

diameternumber of bolts

2,4

Door

openclose

Battery

ampsvolts

chargedischarge

1

Brakelight

onoff

* 1

60

Inheritance• Models "kind of" hierarchy• Powerful notation for sharing similarities among classes

while preserving their differences• UML Notation: An arrow with a triangle

Cell

MuscleCellBloodCell NerveCell

StriateSmoothRed White PyramidalCortical

61

Aggregation vs Inheritance

• Both associations describe trees (hierarchies)– Aggregation tree describes a-part-of relationships

Inheritance tree describes "kind-of" relationships

• Aggregation relates instances (involves two or more different objects)

• Inheritance relates classes (a way to structure the description of a single object)

62

Directory

FileSystemElement

File

1

*

A Directory can contain any number of FileSystemElements (a FileSystemElement is either a File or a Directory). A given FileSystemElement, however, is part of exactly one Directory.

Example: Hierarchical File System

63

Example: Nonhierarchical file system

Directory

FileSystemElement

File

*

*

A Directory can contain any number of FileSystemElements (a FileSystemElement is either a File or a Directory). A given FileSystemElement can be part of many Directory (ies).

64

Analysis Activities

• Identifying entity objects• Identifying boundary objects• Identifying control objects• Mapping use cases to objects• Identifying associations among objects• Identifying object attributes• Modeling nontrivial behavior with statecharts• Modeling generalization relationships• Reviewing the analysis model

65

Identifying Boundary Objects

• System interfaces with actors• Collect information from the actor and

translate it into a form that can be used by other objects in the system

• Use a coarse level– Allows the interface to change without having to

change the analysis model

66

Heuristics for identifying boundary objects

• Identify data entry forms/windows (e.g.

EmergencyReportForm, ReportEmergencyButton)• Identify messages system sends to user (e.g.,

AcknowledgementNotice)• Do not model visual aspects of the system –

use mock-ups or prototypes• Use the user’s terms as opposed to

implementation terms

67

Identifying Control Objects

• Coordinate between boundary and entity objects

• Usually do not have a real world counterpart• Relate closely to use case• Responsible for collecting information from

boundary objects and relaying it to entity objects

68

Heuristics for identifying control objects

• Identify a small number of control objects per use case. Each flow of events should have a control object.

• Identify a control object for each actor• A control object should exist for only one use

case. (Its lifespan should be just one use case.)

69

Example: Login to Internet Bookstore

• Actor: Customer• Use case - flow of events

– The customer clicks the login button on the home page.

– The system displays the login page.– The customer enters his/her user ID and password

and clicks the OK button.– The system validates the login information against

the accounts data.– The system returns the customer to the home

page.

70


• Entity objects– Customer– Account

• Boundary Objects– Home page– Login page– Buttons?

• Control Objects– Display

71

Object Modeling• Main goal: Find the important abstractions• Steps during object modeling

– 1. Class identification– 2. Find the attributes– 3. Find the methods– 4. Find the associations between classes

• Order of steps– Goal: get the desired abstractions– Order of steps secondary, only a heuristic– Iteration is important

72

How do you find classes?• Learn about problem domain: Observe your client• Apply general world knowledge and intuition• Take the flow of events and find participating

objects in use cases– Do a textual analysis of scenario or flow of events

(Abbott Textual Analysis, 1983)– Nouns are good candidates for classes

• Apply design patterns (later)• Try to establish a taxonomy

73

Example: Scenario from Problem Statement

• Jim Smith enters a store with the intention of buying a toy for his 3 year old child.

• The store owner gives advice to the customer. The advice depends on the age range of the child and the attributes of the toy.

• Jim selects a dangerous toy which is unsuitable for the child.

• The store owner recommends a safer doll. • Note: Help must be available within less than one

minute.

74

Abbot’s Heuristics Part of speech Model component Example

Proper noun object Jim Smith

Improper noun class Toy, doll

Doing verb method Buy, recommend

being verb inheritance is-a (kind-of)

having verb aggregation has an

modal verb constraint must be

adjective attribute 3 years old

transitive verb method enter

intransitive verb method (event) depends on

75

Object Modeling in Practice: Class Identification

Foo

Balance

CustomerId

Deposit()Withdraw()GetBalance()

Class Identification: Name of Class, Attributes and Methods

76

Object Modeling in Practice: Encourage Brainstorming

Foo

Balance

CustomerId


Account

Balance

CustomerId


Naming is important!

Money

Balance

CustomerId


77

Object Modeling in PracticeAccount

Balance


Customer

Name

Find New Objects

Iterate on Names, Attributes and Methods

Bank

Name

AccountId

CustomerId

78

Associations

• Class diagrams describe spatial connectivity of objects

• Can include associations to show relationships

• Properties of associations– name: e.g. has, reports to, contains– role of each class– multiplicity

79

Roles

• A role name is the name that uniquely identifies one end of an association.

• A role name is written next to the association line near the class that plays the role.

• When do you use role names?– Necessary for associations between two objects of the same

class– Also useful to distinguish between two associations between

the same pair of classes

• When do you not use role names?– If there is only a single association between a pair of distinct

classes, the names of the classes serve as good role names

80

Example of Role

Problem Statement : A person assumes the role of repairer with respect to another person, who assumes the role of inspector with respect to the first person.

PersonCreates Workorders

inspector

repairpersonCreates Workorders

Person Person

Person

81

Qualification

With qualification: A directory has many files, each with a unique name

Without qualification: A directory has many files. A file belongs only to one directory.

Directory Filefilename

DirectoryFile

filename

1 *

0..11

•The qualifier improves the information about the multiplicity of theassociation between the classes. •It is used for reducing 1-to-many multiplicity to 1-1 multiplicity

82

Example

Problem Statement : A stock exchange lists many companies. However, a stock exchange lists only one company with a given ticker symbol. A company may be listed on many stock exchanges, possibly with different ticker symbols. Find company with ticker symbol AAPL.

StockExchangeCompany

tickerSym

* *lists

83

Use of Qualification reduces multiplicity

StockExchange CompanytickerSym 0..11

StockExchangeCompany

tickerSym

* *

84

Object Modeling in PracticeAccount

BalanceAccountId


Customer

NameCustomerId

Bank

Name

Find New Objects

Iterate on Names, Attributes and Methods

Find Associations between Objects

Has

Label the associations

Determine the multiplicity of the associations

*

85

Object Modeling in Practice: Categorize!

SavingsAccount

Withdraw()

CheckingAccount

Withdraw()

MortgageAccount

Withdraw()

Customer

Name

CustomerId

Account

BalanceAccountId


Bank

Name Has**

86

Object Modeling in Practice: Heuristics

• Explicitly schedule meetings for object identification • Try to differentiate between entity, boundary and

control objects• Find associations and their multiplicity

– Unusual multiplicities usually lead to new objects or categories

• Identify Aggregation • Identify Inheritance: Look for a Taxonomy,

Categorize

• Allow time for brainstorming - Iterate, iterate, iterate

87

Analysis – (2)

Analysis

88

The Analysis Model

analysismodel:Model

dynamicmodel:Model

objectmodel:Model

functionalmodel:Model

use casediagram:View

classdiagram:View

statechartdiagram:View

sequencediagram:View

89

Analysis Activities

• Identifying entity objects• Identifying boundary objects• Identifying control objects• Mapping use cases to objects• Identifying associations among objects• Identifying object attributes• Modeling nontrivial behavior with statecharts• Modeling generalization relationships• Reviewing the analysis model

Reviewmodel

Consolidatemodel

Defineentity

Defineboundary

Definecontrol

Defineinteractions

Defineassociations

Defineattributes

Definenontrivialbehavior

Defineparticipating

Defineuse cases

objects

objects objectsobjects

Analysis activities

(UML activities diagram).

91

Modeling Interactions Between Objects

• Sequence diagrams tie use cases and objects together

• Objects that participate in use case form columns– Vertical dashed line is called the lifeline

• Time progresses from top to bottom• Horizontal arrows represent messages sent

from one object to another• Rectangles represent the activation of an

operation

92

Example Sequence Diagram

FieldOfficer Report

EmergencyButton ReportEmergencyControl ReportEmergency

Form Emergency

Report Manage

EmergencyControl

press()

create()create()

submit()

fillContents()

submitReport()create()

submitReportToDispatcher()

93

Heuristics for drawing sequence diagrams

• Actor who initiates – on the left• Next - the boundary object that the actor uses to

initiate• Next – the first use case control object • Boundary objects are created by control objects• Entity objects are accessed by control objects and

boundary objects• Entity objects should NOT access boundary or

control objects (WHY?)

94


• Actor: Customer• Use case - flow of events

– The customer clicks the login button on the home page.

– The system displays the login page.– The customer enters his/her user ID and password

and clicks the OK button.– The system validates the login information against

the account’s data.– The system returns the customer to the home

page.

95


• Entity objects– Customer?– Account

• Boundary Objects– Home page– Login page– Buttons?

• Control Objects– Display

96

Login Sequence Diagram

• Initiating actor?• Boundary object that actor uses in initiation?• Control object?• Messages?• Use Together to generate

– Follow heuristics

97

Why Use Sequence Diagrams?

• Model the order of interactions of objects– Side effect: May result in rewriting the flow of

control for a use case in more precise terms

• Distribute the behavior of the use case among the objects (design)– Forces us to start thinking about the methods of

an object

• Identify missing behavior– acts as a check

• Forces us to focus and think more critically

98

Is it worth the effort?

• Time consuming• Difficult• May not want to do for simple parts of system

– Although we learn from doing simple parts

• There are other tools that are used to allocate behavior– e.g. CRC cards

99

Collaboration Diagrams

• Sequence diagrams and collaboration diagrams belong to the general class of interaction diagrams

• Capture the same content– Can be converted automatically to the other style

• Collaboration diagram is more free-form– Does not emphasize time ordering

• Convert sequence diagram to collaboration in Together.

100

Statechart Diagrams

• Graph whose nodes are states and whose directed arcs are transitions labeled by event names.

• A statechart diagram relates events and states for one class– An object model with a set of objects has a set of

state diagrams

101

State• An abstraction of the attribute of a class

– State is the aggregation of several attributes of a class

• Basically an equivalence class of all those attribute values and links that do no need to be distinguished as far as the control structure of the system is concerned – Example: State of a bank

• A bank is either solvent or insolvent

• State has duration

102

UML Statechart Diagram Notation

State2State1 Event1(attr) [condition]/action

entry /action

exit/action

• A UML statechart diagram can be mapped into a finite state machine

do/Activity

Event triggerWith parameters

Guardcondition

103

UML statechart for Incident.

numAllocatedResource == 0

all reports

when incident.date > 1yr.

are submitted

Active Inactive Closed Archived

104

MeasureTime SetTime

pressButtonsLAndR

pressButtonsLAndR/beep

after 2 min.

DeadBattery

after 20 yearsafter 20 years

Statechart diagram for 2Bwatch

Reviewmodel

Consolidatemodel

Defineentity

Defineboundary

Definecontrol

Defineinteractions

Defineassociations

Defineattributes

Definenontrivialbehavior

Defineparticipating

Defineuse cases

objects

objects objectsobjects

Analysis activities

(UML activities diagram).

106

Reviewing the Analysis Model

• Analysis model built incrementally and iteratively– omission discovered during analysis may lead to

new use case– E.g. What happens to student applications after

students have been selected for a term? Do we need an archive or purge applications use case?

• Reviews conducted to ensure that the necessary attributes are met

• Text lists a number of questions to ask…

107

Model Correct?

• Is the glossary of entity objects understandable by the user?

• Do abstract classes correspond to user-level concepts?

• Are all descriptions in accordance with users’ definitions?

• Do all use cases and control objects have meaningful verb phrases as names?

• Etc.

108

Model Consistent?

• Are there multiple classes or use cases with the same name?

• Do entities (e.g. use cases, classes, attributes) with similar names denote similar phenomena?

• Are all entities described at the same level of detail?

109

Model Realistic?

• Are there any novel features of the system? Were any studies or prototypes built to ensure their feasibility?

• Can the performance and reliability be met?• Etc.

110

Managing Analysis

• Documenting• Assigning Responsibilities• Communicating• Client Sign-off

111

1. Introduction2. Current system3. Proposed system

3.1 Overview3.2 Functional requirements3.3 Nonfunctional requirements3.4 Constraints (“Pseudo requirements”) 3.5 System models

3.5.1 Scenarios3.5.2 Use case model3.5.3 Object model 3.5.3.1 Data dictionary 3.5.3.2 Class diagrams3.5.4 Dynamic models3.5.5 User interfae

4. Glossary

Requirements Analysis Document Template

112

Documenting Analysis

• RAD documents both requirements elicitation and analysis activities

• Many sections written during requirements elicitation

• Those sections are reviewed and revised• New sections are added

– Object models– Dynamic models– User interface: screen mockups, forms

113

Object Models

• Document the domain objects identified– Attributes

• As complete as possible• No data types needed

– Operations • From sequence diagrams• List may be incomplete• No logic

– Class diagrams showing relationships – Data Dictionary with text descriptions

114

Dynamic Models

• Statechart diagrams for complex behavior of objects

• Sequence diagrams for use cases– Although they contain redundant information (have

textual flow of events with use cases) useful because they are more precise and will help the designers understand the system

115

Assigning Responsibilities

• Analysis involves many individuals– User and client– Analyst, architect, document editor, configuration

manager, reviewer

• Challenging to coordinate and communicate• Assign types of roles:

– Generation of information– Integration– Review

116

User and Client

• User– Domain expert– Generates information about the current system

and about the tasks that the future system should support

– Corresponds to one or more actors• Helps identify their use cases

• Client– Integration of user requests– Defines the scope of the system based on

(sometimes conflicting) user requirements

117

Analyst and Architect

• Analyst– Development domain expert– Models current system– Generates information about the future system

• Architect– Integrates the use case and object models – Ensures consistency and completeness– Develops system philosophy

118

Editor, Reviewer, Configuration Manager

• Editor– Integration of document– Format of document

• Reviewer– Validates document against requirements qualities

• Configuration Manager– Maintains revision history– Coordinates traceability with other documents

119

Communicating

• Challenges– Different backgrounds– Different expectations– Passing information to new teams– Evolving system

• Guidelines– Define clear territories– Define clear objectives and success criteria– Brainstorm

120

Client Sign-off

• Acceptance of the analysis model (RAD) by client

• Also client and developer must agree on:– Priorities– Criteria by which to accept or reject system– Schedule– Budget– Revision process

Report problemor

Design changeand

change request estimate impact

Updaterequirements

Updatedesign

Update code (if applicable)

Designtest

Execute allrelevant tests

Archiverequest

[change approved]

Review proposedchange

Review actualchange

Client Developer

Example of a

revision process

1 requirements - 1. 2 software development activities application domain objects subsystems class......

Documents