Scribd
Upload
250 views6 pages

Chapter 6 - Requirements Modeling Scenarios and Information

The document discusses requirements modeling which involves creating models using scenarios, data, and classes to represent software requirements. It covers scenario-based modeling using use cases, activity diagrams, and swimlane diagrams. Data modeling shows how data is transformed. Class-based modeling defines objects, attributes, and relationships. Effective requirements modeling follows best practices like ensuring models are simple, focused, and provide value to stakeholders.

Uploaded by

San Lizas Airen
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
250 views6 pages

Chapter 6 - Requirements Modeling Scenarios and Information

The document discusses requirements modeling which involves creating models using scenarios, data, and classes to represent software requirements. It covers scenario-based modeling using use cases, activity diagrams, and swimlane diagrams. Data modeling shows how data is transformed. Class-based modeling defines objects, attributes, and relationships. Effective requirements modeling follows best practices like ensuring models are simple, focused, and provide value to stakeholders.

Uploaded by

San Lizas Airen
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

Chapter 6 – Requirements Modeling: Scenarios and Information

The requirements model is the first technical representation of a system.


Requirements modeling process uses a combination of text and diagrams to
represent software requirements (data, function, and behavior) in an
understandable way. Software engineers build requirements models using
requirements elicited from customers. Building analysis models helps to make it
easier to uncover requirement inconsistencies and omissions. This chapter
covers three perspectives of requirements modeling: scenario-based, data
(information), and class-based. Requirements modeling work products must be
reviewed for completeness, correctness, and consistency.

Requirements Models

• Scenario-based (system from the user’s point of view)


• Data (shows how data are transformed inside the system)
• Class-oriented (defines objects, attributes, and relationships)
• Flow-oriented (shows how data are transformed inside the system)
• Behavioral (show the impact of events on the system states)

Requirements Model Objectives

• Describe what the customer requires.


• Establish a basis for the creation of a software design.
• Devise a set of requirements that can be validated once the software is built.

Analysis Model Rules of Thumb

• The model should focus on requirements that are visible within the problem or
business domain and be written as a relatively high level of abstraction.
• Each element of the analysis model should add to the understanding of the
requirements and provide insight into the information domain, function, and
behavior of the system.
• Delay consideration of infrastructure and other non-functional models until
design.
• Minimize coupling throughout the system.
• Be certain the analysis model provides value to all stakeholders.
• Keep the model as simple as possible.
Domain Analysis

• Umbrella activity involving the Identification, analysis, and specification of


common requirements from a specific application domain, typically for reuse
in multiple projects
• Object-oriented domain analysis involves the identification, analysis, and
specification of reusable capabilities within a specific application domain in
terms of common objects, classes, subassemblies, and frameworks

Requirements Modeling Approaches

• Structured analysis considers data and processes that transform data as


separate entities
o Data objects are modeled to define their attributes and relationships
o Process are modeled to show how they transform data as it flows
thought the system
• Object-oriented analysis focuses on the definition of classes and the
manner in which they collaborate to effect the customer requirements

Scenario-Based Modeling

• Makes use of use cases to capture the ways in which end-users will interact
with the system
• UML requirements modeling begins with the creation of scenarios in the from
of use cases, activity diagrams, and swim lane diagrams

Developing Use Cases

• Use cases capture the interactions between actors (i.e. entities that consume
or produce information)
• Begin by listing the activities performed by a single actor to accomplish a
single function
• Continue this process for each actor and each system function
• Use-cases are written first in narrative form and then mapped to a template if
more formality is required
• Each primary scenarios should be reviewed and refined to see if alternative
interactions are possible
o Can the actor take some other action at this point?
o Is it possible that the actor will encounter an error condition at some
point? If so, what?
o Is it possible that the actor will encounter some other behavior at some
point? If so, what?
Exceptions

• Describe situations (failures or user choices) that cause the system to exhibit
unusual behavior
• Brainstorming should be used to derive a reasonably complete set of
exceptions for each use case
o Are there cases where a validation function occurs for the use case?
o Are there cases where a supporting function (actor) fails to respond
appropriately?
o Can poor system performance result in unexpected or improper use
actions?
• Handling exceptions may require the creation of additional use cases

UML Activity Diagrams

• Supplements use-case by providing graphical representation of the


interaction flow within a specific scenario
• Similar to flow chart
o Rounded rectangles used to represent functions
o Diamonds used to represent decision points
o Labeled arrows represent system flow
o Solid horizontal lines indicate parallel activities

UML Swimlane Diagrams

• Variation of activity diagrams used show flow of activities in use case as well
as indicating which actor has responsibility for activity rectangle actions
• Responsibilities are represented by parallel line segments that divide the
diagram vertically headed by the responsible actor

Data Objects

• Data object - any person, organization, device, or software product that


produces or consumes information
• Attributes - name a data object instance, describe its characteristics, or make
reference to another data object
• Relationships - indicate the manner in which data objects are connected to
one another
Class-based Modeling

• Represents objects system manipulates, operations applied to objects, and


collaborations occurring between classes
• Elements of class model include: classes, objects, attributes, operations,
CRC models, collaboration diagrams, and packages

Identifying Analysis Classes

• Examine the problem statement and try to find nouns that fit the following
categories and produce or consume information (i.e. grammatical parse)
o External entities (systems, devices, people)
o Things (e.g. reports, displays, letters, signals)
o Events occurring during system operation
o Roles (e.g. manager, engineer, salesperson)
o Organizational units (e.g. division, group, team)
o Places
o Structures (e.g. sensors, vehicles, computers)

Class Selection Criteria

• Consider whether each potential class satisfies one of these criteria as well
o Contains information that should be retained
o Provides needed services
o Contains multiple attributes
o Has common set of attributes that apply to all class instances
o Has common set of operations that apply to all object instances
o Represents external entity that produces or consumes information

Specifying Class Attributes

• Examine the processing narrative or use-case and select the things that
reasonably can belong to each class
• Ask what data items (either composite or elementary) fully define this class in
the context of the problem at hand?

Defining Operations

• Look at the verbs in the processing narrative and identify operations


reasonably belonging to each class that (i.e. grammatical parse)
o manipulate data
o perform computation
o inquire about the state of an object
o monitor object for occurrence of controlling event
• Divide operations into sub-operations as needed
• Also consider communications that need to occur between objects and define
operations as needed

Class-Responsibility-Collaborator (CRC) Modeling

• Develop a set of index cards that represent the system classes


• One class per card
• Cards are divide into three sections (class name, class responsibilities, class
collaborators)
• Once a complete CRC card set is developed it is reviewed examining the
usage scenarios

Classes

• Entity classes extracted directly from problem statement (things stored in a


database and persist throughout application)
• Boundary classes used to create the interface that user sees and interacts
with as software is used
• Controller classes manage unit of work from start to finish
o Create or update entity objects
o Instantiate boundary objects
o Complex communication between sets of objects
o Validation of data communicated between actors

Allocating Responsibilities to Classes

• Distribute system intelligence evenly


• State each responsibility as generally as possible
• Information and its related behaviors should reside within the same class
• Localize all information about one thing in a single class
• Share responsibilities among related classes when appropriate

Collaborations

• Any time a class cannot fulfill a responsibility on its own it needs to interact
with another class
• A server object interacts with a client object to fulfill some responsibility
Reviewing CRC Models

• Each review participant is given a subset of the CRC cards (collaborating


cards must be separated)
• All use-case scenarios and use-case diagrams should be organized into
categories
• Review leader chooses a use-case scenario and begins reading it out loud
• Each time a named object is read a token is passed to the reviewer holding
the object's card
• When the reviewer receives the token, he or she is asked to describe the
responsibilities listed on the card
• The group determines whether one of the responsibilities on the card satisfy
the use-case requirement or not
• If the responsibilities and collaborations on the index card cannot
accommodate the use-case requirements then modifications need to be
made to the card set

Associations and Dependencies

• Association - present any time two classes are related to one another in some
fashion
o association multiplicity or cardinality can be indicated in a UML class
diagram (e.g. 0..1, 1..1, 0.., 1..)
• Dependency – client/server relationship between two classes
o dependency relationships are indicated in class diagrams using
stereotype names surrounded by angle brackets (e.g. <<stereotype>>)

Analysis Packages

• Categorization is an important part of analysis modeling


• Analysis packages are made up of classes having the same categorization
• In class diagrams visibility of class elements can be indicated using a +
(public), - (private), # (package)

You might also like