Requirements Engineering

The Requirements Specification
TOPIC THREE
Software Engineering 1

Requirements Specifications

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

Software Engineering

2

Use-Case Analysis

It is a technique where the analysis model is derived from the requirements model. It identifies the initial classes, called analysis classes of the system. It is also identifies the responsibilities of the analysis classes by elaborating on the collaboration done by the classes.

Software Engineering

3

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 of the analysis classes.

● ●

Software Engineering

4

Input Documents
● ● ● ●

Use-Case Model Supplementary Specifications Glossary Software Architecture Document (if any)

Software Engineering

5

Resulting Work Product

The Analysis Model

Object Model

Class Diagrams

It is created using the Class Diagram. It is the most important diagram because it serves as a major input at the design engineering activity. It represents the static aspect of the system through the analysis classes

Sequence Diagrams

Behavioral Model

It is created using the Sequence and Collaboration Diagrams. It represents the dynamic aspect of the system. It shows interactions and collaborations
Software Engineering

Collaboration Diagrams

6

Steps in Use-Case Analysis
1.Review and verify use-case specifications. 2.For each use-case, find the analysis classes using the three perspective or UML stereotypes. 3.Model the behavior of the analysis classes as collaborating classes using the Sequence and Collaboration Diagrams. 4.For each resulting analysis classes, identify responsibilities.

Software Engineering

7

Steps in Use-Case Analysis
5.For each resulting analysis classes, identify attributes. 6.Identify associations among analysis classes. 7.Unify the analysis classes in a class diagram. 8.Validate the Analysis Model.

Software Engineering

8

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 events should be update, ie, one needs to go back and do the requirements analysis. As an example, which one is clear?
– –

The selection committee gets application forms. The selection committee retrieves the application forms of the applicants who are scheduled for the mock try-outs from the filing cabinet drawer with the title “Mock Try-out Applicants.”

Software Engineering

9

STEP 2: For each use case, find analysis classes.

A set of candidate analysis classes (model elements) is identified. These analysis classes are capable of performing the behavior described by the use cases. Analysis classes should be named and described briefly in a few sentences.

Software Engineering

10

Class

It is a description of a set of objects that share the same attributes, operations and behavior. It is an abstraction that focuses on the characteristics that are important and ignoring those that are not. It is represented as a rectangular box with three compartments- name, attributes and operations.
Software Engineering 11

Analysis Classes

It represents an early conceptual model for things in the system which have responsibilities and behavior. It is used to capture the first draft of 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 in hardware and how much with software. It rarely survives into the design phase unchanged. It allows one to play with the distribution of responsibilities, re-allocating, as necessary.

● ● ●

● ●

Software Engineering

12

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. They offer a more robust model because they isolate those things most likely to change in a system, ie, interface/environment, control flow, and key system entities.

Software Engineering

13

Boundary Classes

It intermediates between the interface and something outside the system. Types:
– – –

User-interface System-interface Device-interface

<<boundary>> Class Name

1 boundary class per actor/use-case pair.

Software Engineering

14

Boundary Classes

It is used to model interaction between the system's surroundings and its inner workings. It clarifies system boundaries and aid design by providing a good point of departure for identifying related services. It insulates external forces from internal mechanisms and vice versa.

Software Engineering

15

Boundary Classes

Software Engineering

16

Control Classes

It provides coordinating behavior of the system. It decouples boundary and entity classes from one another. 1 control class per usecase

<<control>> Class Name

Software Engineering

17

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 the entity classes changes. Uses or sets the contents of several entity classes, and therefore needs to coordinate the behavior of these entity classes Is not performed in the same way every time it is activated

Software Engineering

18

Control Classes

Software Engineering

19

Entity Classes

It represents the key concepts of the system being developed. It shows the logical data structure. It helps in understanding what the system is supposed to offer. <<entity>> Class Name

Software Engineering

20

Entity Classes
● ●

It represent stores of information in the system. It is used to hold and update information about some phenomenon, such as an event, a person or some real-life object. It's main responsibilities are to store and manage information in the system.

Software Engineering

21

Entity Classes

It can be found by:
– – –

Using use-case flow of events as input. Getting key abstractions from use-cases. Filtering nouns

Software Engineering

22

STEP 3: Model the behavior of the analysis classes.

The behavior of the analysis classes are seen through their collaboration with one another. It uses the Event or Interaction Diagrams:
– –

Sequence Diagrams Collaboration Diagrams

It helps in defining the responsibilities of the analysis classes. When modeling the behavior of the system, object-level is used rather than the class-level to allow for scenarios and events that use more than one instance of a class.

Software Engineering

23

Object Modeling

Two basic elements of the objects are modeled.
– –

Objects Messages.

Software Engineering

24

Objects

They are instances of a class. They maybe named objects or anonymous objects.

Named Objects

Anonymous Objects

Software Engineering

25

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
Software Engineering

26

Event/Interaction Diagrams

They model the dynamic nature of objects within a set of classes. 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?

Software Engineering

27

Sequence Diagram

The purpose is to model interactions between objects which maps sequential interactions to object interactions. It shows explicit sequence of messages passed from one object to another. It is better used for real-time specifications and for complex scenarios. It shows the sequential interactions among objects.

Software Engineering

28

Basic Sequence Diagram Notation
Client Object Supplier Object Bill:Client Object Lifeline
1*[condition]: Action This is a sample script. 1.1[condition]: Action Responsibility :Supplier

Reflexive Message

Message
2 : return done

Return Message
Software Engineering

Hierarchical Message Numbering
29

Enhanced Sequence Diagram Notation

The explicit addition of return is not followed by all designers. Object creation and termination Customized Messages

● ●

Software Engineering

30

Object Creation

Placing object at top of diagram implies that the object exists before the scenario starts. If object is created during the execution of the scenario, place it relative to the point when it was created.

Software Engineering

31

Object Activation and Termination

To show an object is active: widen the object lifeline to a narrow 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.

Software Engineering

32

Customized Messages
● ●

Customized messages (for common programming events) Synchronous Messages:

Operation proceeds only when client sends a message to the supplier and the supplier responds to the message. The client waits until a response is received.

Software Engineering

33

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 given period of time

Software Engineering

34

Customized Messages

Asynchronous Events:

Client continues execution after having sent a message to the supplier Client does not wait or rely on supplier's response. Sent only if certain conditions are met Place condition in square brackets Eg. [product available = yes ]


Conditioned Message:
– – –

Software Engineering

35

Enhanced Sequence Diagram
Bill:Client
1*[condition]: Action

Creation

Activation Synchronous Timeout

:Supplier

2 : return done

Asynchronous

Deactivation Return
Software Engineering

X
Termination
36

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.
Software Engineering 37

First Step

Place the participating analysis objects at the top of the diagram. Place control objects between boundary and entity objects. Control objects serves as intermediary between boundary and entity classes. Place actors either at the beginning or ending of the line.

● ●

Software Engineering

38

Second Step

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

Software Engineering

39

Third Step

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

Software Engineering

40

Fourth Step

Draw the return messages.

Software Engineering

41

Fifth Step

Number the messages according to its chronological order of the invocation.

Software Engineering

42

Sixth Step

Elaborate on the messages by specifying any of the following: repetition, conditions, list of parameters, and return type.

Software Engineering

43

Seventh Step

Optionally enhance the sequence diagrams using the enhanced notation.

Software Engineering

44

Collaboration Diagram

The purpose is to model a pattern of interaction among objects. It models the objects participating in the interaction by their links 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.

Software Engineering

45

Collaboration Diagram
Client Object Link
:Client 1: PerformResponsibility :Supplier 2: PerformResponsibility

Return

Supplier Object

Synchronous Message

Software Engineering

46

Building a Collaboration Diagram
● ● ●

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.

Software Engineering

47

First Step

Draw the participating actors and objects.

Software Engineering

48

Second Step

If objects exchange messages as shown in their sequence diagram, draw a line connecting them which signifies an association.

Software Engineering

49

Third Step

Write the messages on the associated lines.

Software Engineering

50

STEP 4: For each analysis class, identify responsibilities.

This steps identifies the responsibilities that each analysis class performs or provides.

Software Engineering

51

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 or Interaction Diagrams. For each message, examine the class of the object to which the message is sent; receiving objects own the message, therefore, the responsibility. If the responsibility does not exists, create one that provides the behavior. Check also non-functional requirements for other responsibilities.
Software Engineering 52

Responsibility Identification Guidelines
● ● ●

Check that classes have consistent responsibility. Check the classes for similar responsibilities. Better distribution of responsibilities may be evident while working on another interaction diagram. There is no problem if a class has only one responsibility,per se, but it should raise question on why it is needed.

Software Engineering

53

Responsibilities

Software Engineering

54

STEP 4: For each analysis class, identify attributes.

The purpose of this step is to identify the information that the analysis class is responsible for maintaining. This steps identifies the attributes of each analysis class.

Software Engineering

55

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}
Software Engineering 56

Attribute Identification Guidelines

Sources of possible attributes are system domain knowledge, 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 or perform simple transformations on the information; the information has no real behavior other than providing its value.

If the information has complex behavior, or is shared by two or more objects the information should be modeled as a separate class.
Software Engineering 57

Attribute Identification Guidelines
● ●

Attributes are domain dependent. Attributes should support at least one use case.

Software Engineering

58

Attributes

Software Engineering

59

STEP 6: Identify associations.

The purpose of this step is to identify other classes on which the analysis class depend. It defines the structural relationship of objects within the set of analysis classes.

Software Engineering

60

Association

It represents the structural relationships between objects of different classes. It connects instances of two or more classes together for some duration. It may be:
– – –

unary association binary association (common) ternary association

Software Engineering

61

Association Names

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

a verb phrase a role name

Association names can be placed on, or adjacent to the association path. Avoid names likes has or contains because they add no information about what relationships are between objects of classes.

Software Engineering

62

Types of Associations

Software Engineering

63

Aggregation

It is a special form of association that models a whole-part relationship 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.

Software Engineering

64

Roles

It specifies the face that a class presents on each side of the association. It should be unique. It should be a noun indicating the relationship.

● ●

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

Software Engineering

65

Aggregation and Roles

Software Engineering

66

Multiplicity

It is the number of objects of the class can be associated with 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 be linked to one instance?

Software Engineering

67

Multiplicity

There can be multiple associations between the same class, but they should represent distinct relationships, DIFFERENT ROLES; they should not be just of invoking different operations.

<<entity>> Schedule

add student to remove student from

<<entity>> CourseOffering

Software Engineering

68

Multiplicity
● ● ●

Unspecified Exactly one Zero or many One or more Zero or one Specified range Multiple, disjoint ranges
0..1 2..4 2, 4..6
Software Engineering 69

1 0..*

● ● ● ●

* 1..*

Multiplicity Illustrated

Software Engineering

70

Association Identification 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 unary association. An object can send a message to itself. Unary relationship is needed when two different objects of the 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 how the association is used, or what relationships the association represents.

Software Engineering

71

STEP 7: Unify the analysis classes in a class diagram.

The purpose of this step is to ensure that each analysis class represents a single well-defined concepts with nonoverlapping responsibilities. It filters the analysis classes to ensure minimum number of new concepts have been created.

Software Engineering

72

Generalization

This concept supports reuse since hierarchies can usually be extended without significant effects on existing structures. It is usually the “is a kind of” relationships that are identified and modeled into the class diagram.

Software Engineering

73

Generalization Guidelines

As a rule, only model a class as a superclass of another if one is confident that all attributes, operations and association of the superclass is known. One should not anticipate subclasses not justified in the currently known requirements.

Software Engineering

74

Unification Guidelines

The name of the analysis class should accurately capture the role played by the class in the system. It should be unique. Merge classes that have similar behavior. Merge entity classes that have similar attributes, even if their defined behavior is different; aggregate the behaviors of the merged classes. When one updates a class, you should update any supplemental 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 consistent with the collaboration they support Software Engineering
75

Club Membership Maintenance Object Model

Software Engineering

76

Analysis Model Validation 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?

Software Engineering

77

Analysis Model Validation Checklist

Behavioral Model

Have all the main and/or sub-flows been handled, including exceptional cases? Have all the required objects been found? Has all behavior been unambiguously distributed to the participating objects? Has the behavior been distributed to the right objects? Where there are several interaction diagrams, are their relationships clear and consistent?

– –

– –

Software Engineering

78

Summary
Requirements Model ●Use-Case Model ● Use-case Diagram ● Use-case Specification ●Supplementary Specification ●Glossary Analysis Model ●Object Model ● Class Diagram of Analysis Classes ●Behavioral Model ● Sequence Diagrams ● Collaboration Diagrams
Software Engineering 79

Sign up to vote on this title
UsefulNot useful