Requirements modeling

REQUIREMENTS ANALYSIS
Requirements analysis results in the specification of software’s
operational characteristics, indicates software’s interface with other
system elements, and establishes constraints that software must meet.
Types of models:
• Scenario-based models
• Data models
• Class-oriented models
• Flow-oriented models
• Behavioral models

• Scenario-based models of requirements from the point of view
of various system actors”
• Data models that depict the information domain for the problem
• Class-oriented models that represent object-oriented classes
(attributes and operations) and the manner in which classes
collaborate to achieve system requirements
• Flow-oriented models that represent the functional elements of
the system and how they transform data as it moves through the
system
• Behavioral models that depict how the software behaves as a
consequence of external “events”

The requirements model must achieve three primary objectives:
(1) to describe what the customer requires,
(2) to establish a basis for the creation of a software design,
(3) to define a set of requirements that can be validated once the
software is built.
Requirements Modeling Approaches
structured analysis, considers data and the processes that transform
the data as separate entities
object-oriented analysis, focuses on the definition of classes and the
manner in which they collaborate with one another to effect
customer requirements

Elements of the analysis
model

SCENARIO-BASED MODELING
• Creating a Preliminary Use Case
(1) what to write about,
(2) how much to write about it,
(3) how detailed to make your description, and
(4) how to organize the description?
• Refining a Preliminary Use Case
A description of alternative interactions is essential for a complete
understanding of the function that is being described by a use
case.
• Can the actor take some other action at this point?
• Is it possible that the actor will encounter some error condition at
this point? If so, what might it be?
• Writing a Formal Use Case

Preliminary use-case diagram for the SafeHome system

UML Diagrams
Structural Diagrams
Class diagram
Object diagram
Component diagram
Deployment diagram
Behavioral Diagrams
Use case diagram
Sequence diagram
Collaboration diagram
Statechart diagram
Activity diagram

Activity diagram for Access camera surveillance via the Internet—
display camera views function. Graphical representation of the flow of
interaction within a specific scenario

Swimlane diagram for Access camera surveillance via the Internet—display
camera
views function. Responsibilities are represented as parallel segments that
divide the diagram vertically, like the lanes in a swimming pool. Three
analysis classes— Homeowner, Camera, and Interface —have direct or
indirect responsibilities

CLASS BASED MODELING
Based on Objects and operations
The elements of a class-based model include classes and objects,
attributes, operations, class responsibility collaborator (CRC)
models, collaboration diagrams, and packages.

Identifying Analysis Classes
External entities (e.g., other systems, devices, people) that
produce or consume information to be used by a computer-based
system.
Things (e.g., reports, displays, letters, signals) that are part of
the information domain for the problem.
Occurrences or events (e.g., a property transfer or the
completion of a series of robot movements) that occur within the
context of system operation.

Roles (e.g., manager, engineer, salesperson) played by people
who interact with the system.
Organizational units (e.g., division, group, team) that are relevant
to an application.
Places (e.g., manufacturing floor or loading dock) that establish
the context of the problem and the overall function of the system.
Structures (e.g., sensors, four-wheeled vehicles, or computers)
that define a class of objects or related classes of objects.

Six characteristics of potential class for inclusion in the analysis
model
1.Retained information. The potential class will be useful during
analysis only if information about it must be remembered so that the
system can function.
2. Needed services. The potential class must have a set of
identifiable operations that can change the value of its attributes in
some way.
3. Multiple attributes. During requirement analysis, the focus should
be on “major” information; a class with a single attribute may, in fact,
be useful during design, but is probably better represented as an
attribute of another class during the analysis activity.

4. Common attributes. A set of attributes can be defined for the
potential class and these attributes apply to all instances of the
class.
5. Common operations. A set of operations can be defined for
the potential class and these operations apply to all instances of
the class.
6. Essential requirements. External entities that appear in the
problem space and produce or consume information essential to
the operation of any solution for the system will almost always
be defined as classes in the requirements model

Specifying Attributes
Attributes describe a class that has been selected for inclusion in the
requirements
model.
Class- Player
Attributes - as name, position, batting average, fielding percentage,
years played, and games played
Defining Operations
Operations define the behavior of an object
(1)Operations that manipulate data in some way (e.g., adding,
deleting, reformatting, selecting),
(2) operations that perform a computation,
(3) operations that inquire about the state
(4) operations that monitor an object for the occurrence of a
controlling
event.

• assign() operation is relevant for the Sensor class.
• That a program() operation will be applied to the System class.
• That arm() and disarm() are operations that apply to System class
Class-Responsibility-Collaborator (CRC) Modeling
Class-responsibility-collaborator (CRC) modeling provides a simple
means for identifying and organizing the classes that are relevant to
system or product requirements.

class types
Entity classes, also called model or business classes, are extracted
directly from the statement of the problem (e.g., FloorPlan and
Sensor)
Boundary classes are used to create the interface (e.g., interactive
screen or printed reports) that the user sees and interacts with as
the software is used
Controller classes manage a “unit of work” from start to finish

Responsibilities
Five guidelines for allocating responsibilities to classes
System intelligence should be distributed across classes to best
address the needs of the problem
Each responsibility should be stated as generally as possible
Information and the behavior related to it should reside within the
same class.
Information about one thing should be localized with a single class,
not distributed across multiple classes.
Responsibilities should be shared among related classes, when
appropriate

Collaborations
Classes fulfill their responsibilities in one of two ways:
(1) A class can use its own operations to manipulate its
own attributes, thereby fulfilling a particular responsibility,
or
(2) a class can collaborate with other classes.
Generic relationships between classes :
(1) the is-part-of relationship,
(2) the has-knowledge-of relationship, and
(3) the depends-upon relationship

All classes that are part of an aggregate class are
connected to the aggregate class via an is-part-of
relationship.
Consider the classes defined for the video game,
The class PlayerBody is-part-of Player, as are PlayerArms,
PlayerLegs, and PlayerHead.

class must acquire information from another class,
the has-knowledge of relationship is established
The depends-upon relationship implies that two
classes have a dependency that is not achieved by has-
knowledge-of or is-part-of.
For example, PlayerHead must always be connected to
PlayerBody

Associations and Dependencies
Two data objects may be related to one another .
In UML these relationships are called associations.
“one or more” is represented using 1. .*
“0 or more” is represented using 0 . .*.

A client-server relationship exists between two analysis
classes. In such cases, a client class depends on the server
class in some way and a dependency relationship is
established.
A stereotype is an “extensibility mechanism” within UML that
allows you to define a special modeling element whose semantics
are custom defined. In UML stereotypes are represented in double
angle brackets (e.g., <<stereotype>>).

Analysis Packages
An important part of analysis modeling is categorization.
That is, various elements of the analysis model (e.g., use cases,
analysis classes) are categorized in a manner that packages them
as a grouping—called an analysis package—that is given a
representative name.
The plus sign preceding the analysis class name

DATA MODELING CONCEPTS
The relationships between the data objects, and other
information that is pertinent to the relationships.
The entity-relationship diagram (ERD) addresses these
issues and represents all data objects that are entered,
stored, transformed, and produced within an application.

 Data Objects: representation of composite
information that must be understand by software.
 Data Attributes: properties of data objects
(1)name an instance of the data object,
(2) describe the instance, or
(3) make reference to another instance in another table.
 Relationships:
A connection is established between person and car
because the two objects are related.

• A person owns a car.
• A person is insured to drive a car.

Requirements modeling

More Related Content

What's hot

Similar to Requirements modeling

Recently uploaded

In this document

Requirements modeling