meljun cortes jedi slides-3.3 requirements specifications

7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications

1/79

Software Engineering 1

The

RequirementsSpecification

TOPIC THREE

Requirements Engineering


2/79


Requirements Specifications

It is in this task that the most important work product isdeveloped because it serve as a basis for design andconstruction of the software.


3/79


Use-Case Analysis

It is a technique where the analysis model is derived fromthe requirements model.

It identifies the initial classes, called analysis classes of the

system. It is also identifies the responsibilities of the analysisclasses

by elaborating on the collaboration done by the classes.


4/79


Purpose of the Use-Case

Analysis To identify the analysis classes that will do the use case's

flow of events.

To define the behavior of the analysis classes.

To identify the responsibilities, attributes and associations ofthe analysis classes.


5/79


Input Documents

Use-Case Model

Supplementary Specifications

Glossary

Software Architecture Document (if any)


6/79


Resulting Work Product The Analysis Model

Object Model

It is created using the ClassDiagram.

It is the most important diagrambecause it serves as a majorinput at the design engineeringactivity.

It represents the static aspect ofthe system through the analysisclasses

Behavioral Model

It is created using the Sequenceand Collaboration Diagrams.

It represents the dynamicaspect of the system.

It shows interactions andcollaborations

Class Diagrams

Sequence Diagrams

Collaboration Diagrams


7/79


Steps in Use-Case Analysis

1.Review and verify use-case specifications.

2.For each use-case, find the analysis classes usingthe three perspective or UML stereotypes.

3.Model the behavior of the analysis classes ascollaborating classes using the Sequence andCollaboration Diagrams.

4.For each resulting analysis classes, identify

responsibilities.


8/79


Steps in Use-Case Analysis

5.For each resulting analysis classes, identifyattributes.

6.Identify associations among analysis classes.

7.Unify the analysis classes in a class diagram.8.Validate the Analysis Model.


9/79


STEP 1: Validate the Use

Case Model If the Use Case Model has not been validated yet, check the

model for conformance with the stated requirements.

One may find that some requirements are incorrect or not

well-understood. In such a case, the original flow of eventsshould be update, ie, one needs to go back and do therequirements analysis.

As an example, which one is clear?

The selection committee gets application forms.

The selection committee retrieves the application forms of theapplicants who are scheduled for the mock try-outs from the filingcabinet drawer with the title Mock Try-out Applicants.


10/79


STEP 2: For each use case,

find analysis classes. A set of candidate analysis classes (model elements) isidentified. These analysis classes are capable ofperforming the behavior described by the use cases.

Analysis classes should be named and described briefly in afew sentences.


11/79


Class

It is a description of a set ofobjects that share the sameattributes, operations andbehavior.

It is an abstraction thatfocuses on thecharacteristics that areimportant and ignoringthose that are not.

It is represented as arectangular box with threecompartments- name,attributes and operations.


12/79


Analysis Classes

It represents an early conceptual model forthings in thesystem which have responsibilities and behavior.

It is used to capture the first draftof the object model.

It handles primarily functional requirements. It models the objects we want the system to support without

making a decision on how much of them to support inhardware and how much with software.

It rarely survives into the design phase unchanged. It allows one toplaywith the distribution of responsibilities,

re-allocating, as necessary.


13/79


Three Perspectives

The boundary between the system and its actors.

The information the system uses.

The control logic of the system.

The three perspectives are given stereotypes in UML. Theyoffer a more robust model because they isolate those thingsmost likely to change in a system, ie, interface/environment,control flow, and key system entities.


14/79


Boundary Classes It intermediates between

the interface and somethingoutside the system.

Types:

User-interface

System-interface

Device-interface

1 boundary class per

actor/use-case pair.

Class Name


15/79


Boundary Classes

It is used to model interaction between the system'ssurroundings and its inner workings.

It clarifies system boundaries and aid design by providing agood point of departure for identifying related services.

It insulates external forces from internal mechanisms andvice versa.


16/79


Boundary Classes


17/79


Control Classes

It provides coordinatingbehavior of the system.

It decouples boundary andentity classes from oneanother.

1 control class per use-case

Class Name


18/79


Control Classes

It provides behavior that:

Is surroundings-independent.

Defines control logic and transactions within a use case.

Changes little if the internal structure or behavior of theentity classes changes.

Uses or sets the contents of several entity classes, andtherefore needs to coordinate the behavior of these entity

classes Is not performed in the same way every time it is

activated


19/79


Control Classes


20/79


Entity Classes

It represents the keyconcepts of the systembeing developed.

It shows the logical datastructure.

It helps in understandingwhat the system issupposed to offer.

Class Name


21/79


Entity Classes

It represent stores of information in the system.

It is used to hold and update information about somephenomenon, such as an event, a person or some real-lifeobject.

It's main responsibilities are to store and manageinformation in the system.


22/79


Entity Classes

It can be found by:

Using use-case flow of events as input.

Getting key abstractions from use-cases.

Filtering nouns


23/79


STEP 3: Model the behavior

of the analysis classes. The behavior of the analysis classes are seen through theircollaboration with one another.

It uses the Event or Interaction Diagrams:

Sequence Diagrams Collaboration Diagrams

It helps in defining the responsibilities of the analysisclasses.

When modeling the behavior of the system, object-level isused rather than the class-level to allow for scenarios andevents that use more than one instance of a class.


24/79


Object Modeling

Two basic elements of the objects are modeled.

Objects

Messages.


25/79


Objects

They are instances of aclass.

They maybe named objectsor anonymous objects.

Named

ObjectsAnonymousObjects


26/79


Messages

They are a form of communication between objects.

It has the following format:

* [condition] : action( list of parameters ) :returnValueType

Examples:

submitApplication() [athleteIsHere = yes] playBasketball(athlete):void

* [for each athlete] isAthleteHere(athlete):Boolean


27/79


Event/Interaction Diagrams

They model the dynamic nature of objects within a set ofclasses.

They model the behavior of the system.

How will the system respond to certain user actions?

How are objects created? changed?

How is data transformed?


28/79


Sequence Diagram

The purpose is to model interactions between objects whichmaps sequential interactions to object interactions.

It shows explicit sequence of messages passed from oneobject to another.

It is better used for real-time specifications and for complexscenarios.

It shows the sequential interactions among objects.


29/79


Basic Sequence Diagram

Notation

1*[condition]: Action

Client Object Supplier Object

Message

Bill:Client :Supplier

This is a sample

script.

Reflexive MessageObject Lifeline

1.1[condition]: Action

Responsibility

HierarchicalMessage

NumberingReturn Message

2 : return done


30/79


Enhanced Sequence Diagram

Notation The explicit addition ofreturn is not followed by alldesigners.

Object creation and termination

Customized Messages


31/79


Object Creation

Placing object at top of diagram implies that the object existsbefore the scenario starts.

If object is created during the execution of the scenario,place it relative to the point when it was created.


32/79


Object Activation and

Termination To show an object is active: widen the object lifeline to anarrow rectangle.

Top of rectangle indicates when an object becomes active;the bottom of the rectangle indicates when an object has

become inactive. To show that an object has been terminated, place an X at

the point where the termination occurs.


33/79


Customized Messages

Customized messages (for common programming events)

Synchronous Messages:

Operation proceeds only when client sends a message to thesupplier and the supplier responds to the message.

The client waits until a response is received.


34/79


Customized Messages

Return:

Response to a synchronized message:

Data, or

Return of Control

Timeout Events:

Client abandons message if supplier does not respond with a givenperiod of time


35/79


Customized Messages

Asynchronous Events:

Client continues execution after having sent a message to thesupplier

Client does not wait or rely on supplier's response.

Conditioned Message:

Sent only if certain conditions are met

Place condition in square brackets

Eg. [product available = yes ]


36/79


Enhanced Sequence

Diagram

1*[condition]: Action

Timeout

Bill:Client

:Supplier

Return

2 : return done

Activation

Deactivation

Creation

X

Termination

Synchronous

Asynchronous


37/79


Building A Sequence

Diagram Step 1: Line up the participating actors and objects. Step 2: Draw the actor's and object's lifeline.

Step 3: Draw the messages from one object to another.

Step 4: Draw the return messages. Step 5: Number the messages according to the

chronological order of invocation.

Step 6: Elaborate the messages.

Step 7: Optionally enhance the Sequence Diagrams.

Sample Scenario: Club Staff adds an athlete record.


38/79


First Step

Place the participating analysis objects at the top of thediagram.

Place control objects between boundary and entity objects.

Control objects serves as intermediary between boundaryand entity classes.

Place actors either at the beginning or ending of the line.


39/79

Software Engineering39

Second Step

Draw a vertical dashed line below each object to representthe object's lifeline.


40/79

Software Engineering40

Third Step

Draw the message from one object to another. As a rule, nomessages are sent between the boundary object and entityobject. They communicate indirectly with the control object.


41/79


Fourth Step

Draw the return messages.


42/79


Fifth Step

Number the messages according to its chronological orderof the invocation.


43/79


Sixth Step

Elaborate on the messages by specifying any of thefollowing: repetition, conditions, list of parameters, andreturn type.


44/79


Seventh Step

Optionally enhance the sequence diagrams using theenhanced notation.


45/79


Collaboration Diagram

The purpose is to model a pattern of interaction amongobjects.

It models the objects participating in the interaction by theirlinks to each other and the messages that they send to each

other. It validates the class diagram by showing the need for each

association.

It models the recipient's message effectively which defines

an interface to that object.


46/79


Collaboration Diagram

1: PerformResponsibility

Client Object

Supplier Object

Synchronous Message

Link

:Client

:Supplier

Return

2: PerformResponsibility

Building a Collaboration


47/79


Building a CollaborationDiagram

Step 1: Draw the participating actors and objects.

Step 2: Draw a link among actors and objects.

Step 3: Write the messages on the links.

Sample Scenario: Athlete submits application form.


48/79


First Step

Draw the participatingactors and objects.


49/79


Second Step

If objects exchange messages as shown in theirsequence diagram, draw a line connecting them whichsignifies an association.


50/79


Third Step

Write the messages on the associated lines.

STEP 4: For each analysis


51/79


class, identify

responsibilities. This steps identifies the responsibilities that each analysis

class performs or provides.


52/79


Responsibilities

It is a statement of something that an object can provide.

It can be:

An action that the object can perform.

A knowledge that the object maintains and provides to other objects.

It can be derived from messages obtained from the Events orInteraction Diagrams.

For each message, examine the class of the object to which themessage is sent; receiving objects own the message, therefore,the responsibility.

If the responsibility does not exists, create one that provides thebehavior.

Check also non-functional requirements for other responsibilities.

Responsibility Identification


53/79


Responsibility IdentificationGuidelines

Check that classes have consistent responsibility.

Check the classes for similar responsibilities.

Better distribution of responsibilities may be evident whileworking on another interaction diagram.

There is no problem if a class has only one responsibility,perse, but it should raise question on why it is needed.


54/79


Responsibilities

STEP 4: For each analysis


55/79


STEP 4: For each analysisclass, identify attributes.

The purpose of this step is to identify the information that theanalysis class is responsible for maintaining.

This steps identifies the attributes of each analysis class.

A ib


56/79


Attribute

It is an information that an object owns or knows about itself.

It is used to store information.

Attribute has the following format:

attribute : data_type = default_value {constraints}

Sample:

InvoiceNumber : numeric

Temperature : numeric { 4 decimal precision }

SequenceNumber : integer = 0 {assigned sequentially by the system}

Attribute Identification


57/79


Attribute IdentificationGuidelines

Sources of possible attributes are system domainknowledge, requirements and glossary.

Attributes are used instead of classes when:

Only the value of the information, not it's location, is important.

The information is uniquely owned by the object to which it belongs;no other objects refer to the information.

The information is accessed by operations which only get, set orperform simple transformations on the information; the informationhas no real behavior other than providing its value.

If the information has complex behavior, or is shared by twoor more objects the information should be modeled as aseparate class.

Attribute Identification


58/79


Attribute IdentificationGuidelines

Attributes are domain dependent.

Attributes should support at least one use case.

Att ib t


59/79


Attributes

STEP 6: Identify


60/79


STEP 6: Identifyassociations.

The purpose of this step is to identify other classes on whichthe analysis class depend.

It defines the structural relationship of objects within the setof analysis classes.

A i ti


61/79


Association

It represents the structural relationships between objects ofdifferent classes.

It connects instances of two or more classes together forsome duration.

It may be:

unary association

binary association (common)

ternary association

Association Names


62/79


Association Names

Association names should reflect the purpose of therelationship. It can be:

a verb phrase

a role name

Association names can be placed on, or adjacent to theassociation path.

Avoid names likes has orcontains because they add noinformation about what relationships are between objects of

classes.

Types of Associations


63/79


Types of Associations

Aggregation


64/79


Aggregation

It is a special form of association that models a whole-partrelationship between an aggregate and its part.

Some situations where an aggregation is appropriate:

An object is physically composed of other objects.

An object is a logical collection of other objects.

An object physically contains other objects.

Roles


65/79


Roles

It specifies the face that a class presents on each side of theassociation.

It should be unique.

It should be a noun indicating the relationship.

The use of association names and role names are mutuallyexclusive; one would not normally use both. For eachassociation, decide which conveys more information.

Aggregation and Roles


66/79


Aggregation and Roles

Multiplicity


67/79


Multiplicity

It is the number of objects of the class can be associatedwith one object of the other class.

It is indicated by a text expression on the association line.

It answers the following questions:

Is the association optional or mandatory?

What is the minimum and maximum number of instances that can belinked to one instance?

Multiplicity


68/79


Multiplicity

There can be multiple associations between the same class,but they should represent distinct relationships, DIFFERENTROLES; they should not be just of invoking differentoperations.

Schedule

CourseOffering

add student to

remove student from

Multiplicity


69/79


Multiplicity

Unspecified

Exactly one

Zero or many

One or more

Zero or one

Specified range

Multiple, disjoint ranges

2..4

0..1

1..*

0..*

*

2, 4..6

1

Multiplicity Illustrated


70/79


Multiplicity Illustrated

Association Identification


71/79


Guidelines Use the links of the collaboration diagrams. The indicate

that classes need to communicate.

Reflexive links do not need to be instances of a unaryassociation. An object can send a message to itself.

Unary relationship is needed when two different objects ofthe same class need to communicate with one another.

Focus only on association needed to realize the use case.DO NOT ADD!

Write a brief description of the association to indicate howthe association is used, or what relationships the associationrepresents.

STEP 7: Unify the analysis


72/79


classes in a class diagram. The purpose of this step is to ensure that each analysis

class represents a single well-defined concepts with non-overlapping responsibilities.

It filters the analysis classes to ensure minimum number of

new concepts have been created.

Generalization


73/79


Generalization

This concept supports reuse since hierarchies can usuallybe extended without significant effects on existingstructures.

It is usually the is a kind of relationships that are identified

and modeled into the class diagram.

Generalization Guidelines


74/79


Generalization Guidelines

As a rule, only model a class as a superclass of another ifone is confident that all attributes, operations andassociation of the superclass is known.

One should not anticipate subclasses not justified in the

currently known requirements.

Unification Guidelines


75/79


Unification Guidelines

The name of the analysis class should accurately capturethe role played by the class in the system. It should beunique.

Merge classes that have similar behavior.

Merge entity classes that have similar attributes, even if theirdefined behavior is different; aggregate the behaviors of themerged classes.

When one updates a class, you should update anysupplemental documentation necessary.

Evaluate the result. Be sure to:

Verify that the analysis classes meet the functional requirements

Verify that the analysis classes and their relationships are consistentwith the collaboration they support

Club MembershipM i t Obj t M d l


76/79


Maintenance Object Model

Analysis Model ValidationCh kli t


77/79


Checklist Object Model

Are the classes reasonable?

Does the name of each class clearly reflect the role it plays?

Does the class represent a single well-defined abstraction?

Are all attributes and responsibilities functionally coupled?

Does the class offer the required behavior?

Are all specific requirements on the class addressed?

Analysis Model ValidationCh kli t


78/79


Checklist Behavioral Model

Have all the main and/or sub-flows been handled, includingexceptional cases?

Have all the required objects been found?

Has all behavior been unambiguously distributed to the participatingobjects?

Has the behavior been distributed to the right objects?

Where there are several interaction diagrams, are their relationshipsclear and consistent?

Summary


79/79


Su a y

Requirements ModelUse-Case Model

Use-case Diagram Use-case Specification

Supplementary SpecificationGlossary

Analysis ModelObject Model

Class Diagram of AnalysisClasses

Behavioral Model Sequence Diagrams Collaboration Diagrams