Module-2

Understanding Requirements:
1. Requirements Engineering
2. Establishing the ground work
3. Eliciting Requirements
4. Developing use cases
5. Building the requirements model
6. Negotiating Requirements
7. Validating Requirements

Text book: Roger S. Pressman: Software Engineering-A Practitioners

approach, 7th Edition, Tata McGraw Hill.
 Requirements Engineering
Requirements Engineering is a major software engineering action that begins during the communication activity
and continues into the modeling activity. It must be adapted to the needs of the process, the project, the
product, and the people doing the work.

Requirements engineering provides the appropriate mechanism for understanding what the customer wants,
analyzing need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously,
validating the specification, and managing the requirements as they are transformed into an operational system.

Requirement Engineering seven distinct tasks:

1. inception,
2. elicitation,
3. elaboration,
4. negotiation,
5. specification,
6. validation, and
7. management.
 Requirements Engineering - 7 distinct tasks
Requirement Engineering seven distinct tasks:
Inception: A project starts when a business need or market opportunity is identified. Stakeholders develop a
business case and project scope, initiating discussions with the software team.
Elicitation: Gathering detailed requirements from customers and users is challenging due to issues like unclear
system boundaries, misunderstanding of needs, and changing requirements.
Elaboration: The initial information is refined into a detailed requirements model, focusing on user scenarios and
defining analysis classes and their attributes, services, relationships, and collaborations.
Negotiation: Conflicts and unrealistic demands are resolved through negotiation, prioritizing requirements and
balancing costs, risks, and stakeholder satisfaction.
Specification: Requirements are documented using various formats (written documents, graphical models,
scenarios, prototypes) to ensure consistency and clarity.
Validation: Requirements are reviewed to ensure they are unambiguous, consistent, complete, and conform to
standards, using technical reviews involving engineers, customers, and other stakeholders.
Requirements Management: This involves tracking and controlling changes to requirements throughout the
project lifecycle, similar to software configuration management techniques.
 Establishing the ground work
The challenges of requirements engineering in real-world settings. Ideally, stakeholders and
software engineers collaborate closely within the same team, facilitating easy communication.
However, in reality, customers or end users often face issues such as being geographically
distant, having only a vague understanding of their requirements, holding conflicting opinions,
lacking technical knowledge, and having limited time for interaction. These constraints are
common and pose significant challenges to effective requirements engineering.

The steps required to establish the groundwork for an understanding of software requirements:

1. Identifying stakeholders
2. Recognizing multiple viewpoints
3. Working towards collaboration
4. Asking the first questions
Establishing the ground work - Identifying stakeholders
Stakeholders can include business operations managers, product managers, marketing
personnel, customers (internal and external), end users, consultants, engineers (product,
software, support, and maintenance), and others. Each stakeholder has unique perspectives,
benefits, and risks associated with the project's success or failure. At the inception of a
project, it's crucial to identify and list all stakeholders who will provide input during the
requirements elicitation process, with the list expanding as more stakeholders are identified
through referrals.
Establishing the ground work - Recognizing
multiple viewpoints
The requirements engineering process involves gathering inputs from various stakeholders,
each with different perspectives and priorities:
Marketing Group: Focuses on features that will attract potential customers and facilitate sales.
Business Managers: Prioritize a feature set that can be developed within budget and within
the required timeline.
End Users: Desire familiar, easy-to-learn, and user-friendly features.
Software Engineers: Concerned with underlying functions that support visible features and
overall system infrastructure.
Support Engineers: Emphasize the maintainability of the software.
These diverse viewpoints contribute to a comprehensive set of requirements. However, this
can lead to inconsistencies and conflicts. The gathered information should be categorized to
help decision-makers select a coherent and consistent set of system requirements.
Establishing the ground work - Recognizing
multiple viewpoints
The requirements engineering process involves gathering inputs from various stakeholders,
each with different perspectives and priorities:
Marketing Group: Focuses on features that will attract potential customers and facilitate sales.
Business Managers: Prioritize a feature set that can be developed within budget and within
the required timeline.
End Users: Desire familiar, easy-to-learn, and user-friendly features.
Software Engineers: Concerned with underlying functions that support visible features and
overall system infrastructure.
Support Engineers: Emphasize the maintainability of the software.
These diverse viewpoints contribute to a comprehensive set of requirements. However, this
can lead to inconsistencies and conflicts. The gathered information should be categorized to
help decision-makers select a coherent and consistent set of system requirements.
Establishing the ground work - Recognizing
multiple viewpoints
The requirements engineering process involves gathering inputs from various stakeholders,
each with different perspectives and priorities:
Marketing Group: Focuses on features that will attract potential customers and facilitate sales.
Business Managers: Prioritize a feature set that can be developed within budget and within
the required timeline.
End Users: Desire familiar, easy-to-learn, and user-friendly features.
Software Engineers: Concerned with underlying functions that support visible features and
overall system infrastructure.
Support Engineers: Emphasize the maintainability of the software.
These diverse viewpoints contribute to a comprehensive set of requirements. However, this
can lead to inconsistencies and conflicts. The gathered information should be categorized to
help decision-makers select a coherent and consistent set of system requirements.
Establishing the ground work - Working
toward Collaboration
When multiple stakeholders are involved, each may have different requirements and priorities.
The challenge is of managing differing opinions among stakeholders in a software project.

Effective collaboration is essential for project success. The role of a requirements engineer is
to identify common requirements and resolve conflicts or inconsistencies among stakeholders.
Collaboration involves stakeholders sharing their views, but ultimately, a strong project
champion (such as a business manager or senior technologist) often makes the final decision
on which requirements to prioritize and implement.
Establishing the ground work - Asking the
first questions
Questions asked at the inception of the project should be “context free”. The first set of
context-free questions focuses on the customer and other stakeholders, the overall project
goals and benefits. For example, you might ask:

• Who is behind the request for this work?

• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution that you need?

These questions help to identify all stakeholders who will have interest in the software to be
built. In addition, the questions identify the measurable benefit of a successful
implementation and possible alternatives to custom software development.
Establishing the ground work - Asking the first
questions contd….
The next set of questions enables you to gain a better understanding of the problem and
allows the customer to voice his or her perceptions about a solution:
• How would you characterize “good” output that would be generated by a successful
solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the business environment in which the solution will be
used?
• Will special performance issues or constraints affect the way the solution is approached?

These questions (and others) will help to “break the ice” and initiate the communication
that is essential to successful elicitation. But a question-and-answer meeting format is not
an approach that has been overwhelmingly successful. In fact, the Q&A session should be
used for the first encounter only and then replaced by a requirements elicitation format
that combines elements of problem solving, negotiation, and specification
Establishing the ground work - Asking the first
questions contd….
The final set of questions focuses on the effectiveness of the communication
activity itself. Gause and Weinberg [Gau89] call these “meta-questions” and propose
the following (abbreviated) list:
• Are you the right person to answer these questions? Are your answers
“official”?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?
Eliciting Requirements
Requirements elicitation (also called requirements gathering) combines elements of problem
solving, elaboration, negotiation, and specification. In order to encourage a collaborative,
team-oriented approach to requirements gathering, stakeholders work together to identify the
problem, propose elements of the solution, negotiate different approaches and specify a
preliminary set of solution requirements.

Approaches-
1. Collaborative Requirements Gathering
2. Quality Function Deployment
3. Usage Scenarios
4. Elicitation Work Products
Eliciting Requirements - Collaborative
Requirements Gathering
Steps followed:
1. Meetings are conducted and attended by both software engineers and other stakeholders.
2. Rules for preparation and participation are established.
3. An agenda is suggested that is formal enough to cover all important points but informal
enough to encourage the free flow of ideas.
4. A “facilitator” (can be a customer, a developer, or an outsider) controls the meeting.
5. A “definition mechanism” (can be work sheets, flip charts, or wall stickers or an electronic
bulletin board, chat room, or virtual forum) is used.
Eliciting Requirements - Collaborative
Requirements Gathering Contd…
The process of identifying problems, proposing solutions, and gathering requirements in a software project
through collaborative meetings. The sequence of events involves:
1. Inception: Initial meetings establish the problem's scope and outline a potential solution. A brief "product
request" document is created, summarizing the basic requirements.
2. Preparation for the Meeting: A meeting is scheduled, a facilitator is chosen, and the product request is
distributed to all participants. Attendees prepare by listing relevant objects, services, constraints, and
performance criteria related to the system.
3. During the Meeting:
a) Object and Service Lists: Participants present and combine their lists of objects (e.g., control panel,
sensors) and services (e.g., setting the alarm, monitoring sensors).
b) Consensus Building: Redundant entries are eliminated, new ideas are added, and a consensus list is
developed without critique.
c) Mini-Specifications: Detailed explanations (mini-specs) of objects and services are created, discussed, and
refined.
4. Post-Meeting: Further elaboration of the mini-specs and lists might reveal new requirements, which are added
to the original lists. Unresolved issues are documented for later resolution.

The goal is to collaboratively create a comprehensive and agreed-upon set of requirements that accurately
reflects the system to be developed.
Eliciting Requirements - Quality Function
Deployment
Quality Function Deployment (QFD) is a quality management technique designed to translate customer needs
into technical requirements for software, with a focus on maximizing customer satisfaction. QFD emphasizes
understanding what is valuable to the customer and incorporating these values throughout the engineering
process.
QFD identifies three types of requirements:
1. Normal Requirements: These are explicitly stated objectives and goals from the customer. Meeting these
requirements satisfies the customer. Examples include specific graphical displays, system functions, and
performance levels.
2. Expected Requirements: These are implicit and fundamental expectations that customers may not explicitly
state but expect to be present. Their absence causes significant dissatisfaction. Examples include ease of use,
operational correctness, reliability, and ease of installation.
3. Exciting Requirements: These are features that exceed customer expectations and provide high satisfaction.
Examples include unexpected capabilities like multitouch screens or visual voicemail in mobile phone
software.
QFD techniques, particularly during requirements elicitation, involve gathering data through customer interviews,
observations, surveys, and historical data analysis. This data is compiled into a customer voice table, reviewed
with stakeholders, and analyzed using various diagrams, matrices, and evaluation methods to identify expected
and exciting requirements.
Eliciting Requirements - Usage Scenarios
As requirements are gathered, an overall vision of system functions and features begins to
materialize.

It is difficult to move into more technical software engineering activities until you understand
how these functions and features will be used by different classes of end users.

To accomplish this, developers and users can create a set of scenarios that identify a thread of
usage for the system to be constructed. The scenarios, often called use cases, provide a
description of how the system will be used.
Eliciting Requirements - Elicitation Work
Products
The work products include:

1. A statement of need and feasibility.

2. A bounded statement of scope for the system or product.
3. A list of customers, users, and other stakeholders who participated in requirements
elicitation.
4. A description of the system’s technical environment.
5. A list of requirements (preferably organized by function) and the domain constraints that
apply to each.
6. A set of usage scenarios that provide insight into the use of the system or product under
different operating conditions.
7. Any prototypes developed to better define requirements.

Each of these work products is reviewed by all people who have participated in requirements
elicitation.
 Developing use cases
A use case captures a "contract" describing a system's behavior in response to stakeholder requests. It
tells a story of how an end user interacts with the system under specific conditions, using various forms
such as narrative text, task outlines, templates, or diagrams.
To create a use case, the first step is defining the "actors“.
Actors are different people or devices that interact with the system. Actors represent roles that entities
play in the system's context, and while they often involve end users, they are not necessarily the same.
An actor can represent a class of external entities playing one role, while a user might take on multiple
roles.
For example, a machine operator might interact with a control computer in different modes—
programming, testing, monitoring, and troubleshooting—leading to the definition of four actors:
programmer, tester, monitor, and troubleshooter. The same person could play all these roles, or they
could be played by different individuals.
As requirements are iteratively refined, primary actors (those who interact frequently with the system
to achieve its main functions) are identified first, followed by secondary actors (those who support the
primary actors) as the system is better understood.
 Developing use cases
Contd…
Number of questions that should be answered by a use case:

1. Who is the primary actor, the secondary actor(s)?

2. What are the actor’s goals?
3. What preconditions should exist before the story begins?
4. What main tasks or functions are performed by the actor?
5. What exceptions might be considered as the story is described?
6. What variations in the actor’s interaction are possible?
7. What system information will the actor acquire, produce, or change?
8. Will the actor have to inform the system about changes in the external environment?
9. What information does the actor desire from the system?
10. Does the actor wish to be informed about unexpected changes?
 Developing use cases
Contd…
Safe Home Example:
define four actors:
1. Homeowner (a user),
2. setup manager (likely the same person as homeowner, but playing a different role),
3. sensors (devices attached to the system), and
4. the monitoring and response subsystem (the central station that monitors the SafeHome
home security function).
We consider only the homeowner actor. The homeowner actor interacts with the home security
function in a number of different ways using either the alarm control panel or a PC:
• Enters a password to allow all other interactions.
• Inquires about the status of a security zone.
• Inquires about the status of a sensor.
• Presses the panic button in an emergency.
• Activates/deactivates the security system.
 Developing use cases
Safe Home Example: Contd…

Following example is
the process a homeowner follows to activate the SafeHome
security system using the control panel:
1.System Readiness: The homeowner checks the control
panel to see if the system is ready for input. If it displays a
"not ready" message (indicating an open sensor, such as a
door is open or window is open), they must close the open
sensor.
2.Password Entry: The homeowner enters a four-digit
password. If incorrect, the control panel beeps and resets. If
correct, the system is ready for further action.
3.System Activation: The homeowner selects "stay"
(activating only perimeter sensors) or "away" (activating all
sensors).
4.Confirmation: Upon activation, a red alarm light indicates
the system is active.
 Building the Requirements Model
Elements of the Requirements
Model
Analysis Patterns
Elements of the Requirements Model
1. Scenario-based elements
2. Class-based elements
3. Behavioral elements
UML use case Class diagram of
4. Flow-oriented elements diagram for sensor
SafeHome home
security function
UML activity diagrams for eliciting requirements
 Building the Requirements Model
Elements of the Requirements
Model
Analysis Patterns
Each usage scenario implies
Elements of the Requirements Model a set of objects that are
manipulated as an actor
1. Scenario-based elements interacts with the system.
2. Class-based elements
These objects are
3. Behavioral elements categorized into classes—a
collection of things that Class diagram of
4. Flow-oriented elements have similar attributes and sensor
common behaviors.
 Building the Requirements Model
Elements of the Requirements • The behavior of a computer-based
system can have a profound effect on
Model the design that is chosen and the
implementation approach that is
Analysis Patterns applied.
Elements of the Requirements • Therefore, the requirements model
must provide modeling elements that
Model depict behavior.
1. Scenario-based elements • The state diagram is one method for
representing the behavior of a system
2. Class-based elements by depicting its states and the events
that cause the system to change state. A simplified UML
3. Behavioral elements A state is any externally observable state diagram
mode of behavior. In addition, the state
4. Flow-oriented elements diagram indicates actions (e.g., process
activation) taken as a consequence of a
particular event.
 Building the Requirements Model
Elements of the Requirements Information is transformed as it flows
Model
through a computer-based system.
Analysis Patterns The system accepts input in a variety
Elements of the Requirements of forms, applies functions to
Model transform it, and produces output in a
1. Scenario-based elements variety of forms.
2. Class-based elements
3. Behavioral elements
4. Flow-oriented elements
 Building the Requirements Model
Elements of the Requirements Model
Analysis Patterns

Anyone who has done requirements engineering on more than a few software
projects begins to notice that certain problems reoccur across all projects within
a specific application domain. These analysis patterns suggest solutions within
the application domain that can be reused when modeling many applications.

Analysis patterns are integrated into the analysis model by giving Pattern
reference name.
 Negotiating Requirements
In most cases, stakeholders are asked to balance functionality, performance, and other
product or system characteristics against cost and time-to-market. The intent of this
negotiation is to develop a project plan that meets stakeholder needs while at the same time
reflecting the real-world constraints (e.g., time, people, budget) that have been placed on the
software team.

a set of negotiation activities at the beginning of each software process iteration:

1. Identification of the system or subsystem’s key stakeholders.
2. Determination of the stakeholders’ “win conditions.”
3. Negotiation of the stakeholders’ win conditions to reconcile them into a set of win-win
conditions for all concerned (including the software team).
 Validating Requirements
As each element of the requirements model is created, it is examined for inconsistency, omissions, and ambiguity. The
requirements represented by the model are prioritized by the stakeholders and grouped within requirements packages that
will be implemented as software increments. A review of the requirements model addresses the following questions:
• Is each requirement consistent with the overall objectives for the system/product?
• Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of
technical detail that is inappropriate at this stage?
• Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of
the system?
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement?
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment that will house the system or product?
• Is each requirement testable, once implemented?
• Does the requirements model properly reflect the information, function, and behavior of the system to be built?
• Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the
system?
• Have requirements patterns been used to simplify the requirements model?
• Have all patterns been properly validated?
• Are all patterns consistent with customer requirements?
Module-2
Requirements Modeling Scenarios, Information and Analysis classes:
1. Requirement Analysis
2. Scenario based modeling
3. UML models that supplement the Use Case
4. Data modeling Concepts
5. Class Based Modeling.

Text book: Roger S. Pressman: Software Engineering-A Practitioners

approach, 7th Edition, Tata McGraw Hill.
 Requirement Analysis
Requirements analysis allows you to elaborate on basic requirements established during the
inception, elicitation, and negotiation tasks that are part of requirements engineering.
The requirements modeling action results in one or more of the following types of models:
1. Scenario-based models of requirements from the point of view of various system “actors”
2. Data models that depict the information domain for the problem
3. Class-oriented models that represent object-oriented classes (attributes and operations)
and the manner in which classes collaborate to achieve system requirements
4. Flow-oriented models that represent the functional elements of the system and how they
transform data as it moves through the system
5. Behavioral models that depict how the software behaves as a consequence of external
“events”
These models provide a software designer with information that can be translated to
architectural, interface, and component-level designs. Finally, the requirements model
provides the developer and the customer with the means to assess quality once software is
built.
Requirement Analysis-
Overall Objectives and Philosophy
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, and
(3)to define a set of requirements that can be
validated once the software is built.

The analysis model bridges the gap between a

system-level description that describes overall
system or business functionality as it is achieved
by applying software, hardware, data, human,
and other system elements and a software
design that describes the software’s application The requirements model as a
architecture, user interface, and component-level bridge
structure. between the system description
and the design mode
 Requirement Analysis-
Analysis Rules of Thumb
Thumb Rules should be followed when creating the analysis model:
1. The model should focus on requirements that are visible within the problem or business domain. The level of
abstraction should be relatively high. “Don’t get bogged down in details”.
2. Each element of the requirements model should add to an overall understanding of software requirements
and provide insight into the information domain, function, and behavior of the system.
3. Delay consideration of infrastructure and other nonfunctional models until design. That is, a database may be
required, but the classes necessary to implement it, the functions required to access it, and the behavior that
will be exhibited as it is used should be considered only after problem domain analysis has been completed.
4. Minimize coupling throughout the system. It is important to represent relationships between classes and
functions. However, if the level of “interconnectedness” is extremely high, effort should be made to reduce it.
5. Be certain that the requirements model provides value to all stakeholders. Each constituency has its own use
for the model. For example, business stakeholders should use the model to validate requirements; designers
should use the model as a basis for design; QA people should use the model to help plan acceptance tests.
6. Keep the model as simple as it can be. Don’t create additional diagrams when they add no new information.
Don’t use complex notational forms, when a simple list will do.
 Requirement Analysis- Domain
Analysis
Domain analysis may be viewed as an umbrella activity for the software process.

The role of the domain analyst is to discover and define analysis patterns, analysis classes, and related
information that may be used by many people working on similar but not necessarily the same applications
 Requirement Analysis-
Requirements Modeling Approaches
1. Requirements modeling, called structured analysis: considers data and the processes that transform the
data.
2. Analysis modeling, called 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
Steps To begin developing a set of use cases, list the functions or
activities performed by a specific actor.
1. Creating a Primary Use You can obtain these from a list of required system functions,
Case through conversations with stakeholders, or by an evaluation
of activity diagrams developed as part of requirements
2. Refining a Preliminary Use modeling.
Case
3. Writing
Example: Thea Formal Use home
SafeHome Case surveillance function - homeowner (actor)
Functions:
• Select camera to view.
• Request thumbnails from all cameras.
• Display camera views in a PC window.
• Control pan and zoom for a specific camera.
• Selectively record camera output.
• Replay camera output.
• Access camera surveillance via the Internet.
 Scenario based Modeling – 1. Creating a Primary Use Case
Use case: Access camera surveillance via the Internet—display camera views
(ACS-DCV)
Actor: homeownerNarration Ordered sequence of user actions
If I’m at a remote location, I can use any PC with appropriate The homeowner logs onto the SafeHome
browser software to log on to the SafeHome Products website. Products website.
I enter my user ID and two levels of passwords and once I’m The homeowner enters his or her user ID.
validated, I have access to all functionality for my installed The homeowner enters two passwords (each at
SafeHome system. least eight characters in length).
The system displays all major function buttons.

To access a specific camera view, I select “surveillance” from the The homeowner selects the “surveillance” from
major function buttons displayed. the major function buttons.
I then select “pick a camera” and the floor plan of the house is The homeowner selects “pick a camera”.
displayed. The system displays the floor plan of the house.
 Scenario based Modeling – 1. Creating a Primary Use Case
Use case: Access camera surveillance via the Internet—display camera views
(ACS-DCV)
Actor: homeownerNarration Ordered sequence of user actions
I then select the camera that I’m interested in. The homeowner selects a camera icon from the
Alternatively, I can look at thumbnail snapshots from all floor plan
cameras simultaneously by selecting “all cameras” as my
viewing choice

Once I choose a camera, I select “view” and a one-frame-per- The homeowner selects the “view” button.
second view appears in a viewing window that is identified by The system displays a viewing window that is
the camera ID. identified by the camera ID.
The system displays video output within the
viewing window at one frame per second.

If I want to switch cameras, I select “pick a camera” and the original viewing window disappears and the floor plan
of the house is displayed again. I then select the camera that I’m interested in. A new viewing window appears.
 Scenario based Modeling
Steps Each step in the primary scenario is evaluated by asking the following
questions:
1. Creating a Primary 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
2. Refining a Preliminary
point? If so, what might it be?
Use Case • Is it possible that the actor will encounter some other behavior at this
3. Writing a Formal Use Case point (e.g., behavior that is invoked by some event outside the actor’s
control)? If so, what might it be?
Primary scenario -Narration Ordered sequence of user actions
I then select “pick a camera” and the floor plan of the house is The homeowner selects “pick a camera”.
displayed. The system displays the floor plan of the house.

Question and Answer Secondary sequence of user actions

Can the actor take some other action at this point? View thumbnail snapshots for all cameras.
Yes
 Scenario based Modeling
Steps
1. Creating a Primary Use Case
2. Refining a Preliminary Use Case
3. Writing a Formal Use Case

Primary scenario -Narration Ordered sequence of user actions

I then select “pick a camera” and the floor plan of the house is The homeowner selects “pick a camera”.
displayed. The system displays the floor plan of the house.

Question and Answer Secondary sequence of user actions

Is it possible that the actor will The system may encounter an alarm condition. This would result in the system
encounter some other behavior at displaying a special alarm notification (type, location, system action) and providing the
this point? actor with a number of options relevant to the nature of the alarm. Because this
Yes secondary scenario can occur at any time for virtually all interactions, it will not
become part of the ACS-DCV use case. Rather, a separate use case—Alarm condition
encountered—would be developed and referenced from other use cases as required.
Scenario based Modeling
Steps when a use case involves a critical activity or describes a complex set of steps
with a significant number of exceptions, a more formal approach may be
1. Creating a Primary Use Case desirable.
2. Refining a Preliminary Use
Case
3. Writing a Formal Use
Exceptions:
Case
1. ID or passwords are incorrect or not recognized— see use case Validate ID and passwords.
2. Surveillance function not configured for this system—system displays appropriate error
message; see use case Configure surveillance function.
3. Homeowner selects “View thumbnail snapshots for all camera”—see use case View thumbnail
snapshots for all cameras.
4. A floor plan is not available or has not been configured—display appropriate error message and
see use case Configure floor plan.
5. An alarm condition is encountered—see use case Alarm condition encountered.
 UML models that supplement the Use Case
Use case: Access camera
surveillance via the Internet—
display camera views (ACS-DCV)
Actor: homeowner

1. Activity diagram
2. Swimlane diagrams

The UML activity diagram supplements the

use case by providing a graphical
representation of the flow of interaction
within a specific scenario. Similar to the
flowchart, an activity diagram uses rounded
rectangles to imply a specific system
function, arrows to represent flow through
the system, decision diamonds to depict a
branching decision (each arrow emanating
from the diamond is labeled), and solid
horizontal lines to indicate that parallel
activities are occurring.
 UML models that supplement the Use Case
Use case: Access camera
surveillance via the Internet—
display camera views (ACS-DCV)
Actor: homeowner

1. Activity diagram
2. Swimlane diagrams

The UML swimlane diagram allows you to

represent the flow of activities described by
the use case and also indicate which actor (if
there are multiple actors involved in a specific
use case) or analysis class has responsibility
for the action described by an activity
rectangle. Responsibilities are represented as
parallel segments that divide the diagram
vertically, like the lanes in a swimming pool.
Data modeling Concepts
The software team may choose to create a data model
as part of overall requirements modeling. A software
engineer or analyst defines all data objects that are
processed within the system, 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 modeling Concepts- Data Objects
A data object can be an external entity (e.g., anything that produces or consumes
information), a thing (e.g., a report or a display), an occurrence (e.g., a telephone call) or
event (e.g., an alarm), a role (e.g., salesperson), an organizational unit (e.g., accounting
department), a place (e.g., a warehouse), or a structure (e.g., a file).
the data object can be represented as a table as shown in Figure 6.7. The headings in the
table reflect attributes of the object. The body of the table represents specific instances of
the data object.
Example:
Data Objects: a car is defined in terms of
make, model, ID number, body type, color,
and owner.
Data modeling Concepts- Data Attributes
Data attributes define the properties of a data object and take on one of three different
characteristics. They can be used to
(1) name an instance of the data object,
(2) Describe the instance, or
(3) make reference to another instance in another table.

Example:
Referring to the data object car, a
reasonable identifier might be the ID
number.
Data modeling Concepts- Relationships
Data objects are connected to one another in different ways. Consider the two data objects,
person and car.

Relationships,
For example,
• A person owns a car.
• A person is insured to drive a car.
Class-based modeling
Class-based modeling represents the objects that the system will manipulate,
the operations (also called methods or services) that will be applied to the
objects to effect the manipulation, relationships (some hierarchical) between
the objects, and the collaborations that occur between the classes that are
defined. The elements of a class-based model include classes and objects,
attributes, operations, Class Responsibility Collaborator (CRC) models,
collaboration diagrams, and packages.
Class-based modeling - Identifying Analysis Classes
Identify classes by examining the usage scenarios developed as part of the requirements model and performing
a “grammatical parse” on the use cases developed for the system to be built. Classes are determined by
underlining each noun or noun phrase and entering it into a simple table. Synonyms should be noted. If the
class (noun) is required to implement a solution, then it is part of the solution space; otherwise, if a class is
necessary only to describe a solution, it is part of the problem space.
Analysis classes manifest themselves in one of the following ways:
• 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.
Class-based modeling - Identifying Analysis Classes
Consider the narration: Extracting the nouns, we can propose a
number of potential classes:
Class-based modeling - Identifying Analysis Classes
Six selection characteristics that should be used in each 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.
Class-based modeling - Identifying Analysis Classes
The selection characteristics to the list of potential SafeHome classes:

It should be noted that

(1) the preceding list is not all-
inclusive, additional classes
would have to be added to complete
the model;
(2) some of the rejected potential
classes will become attributes for those
classes that were accepted (e.g.,
number and type are attributes of
Sensor, and master password and
telephone number may become
attributes of System);
(3) different statements of the problem
might cause different “accept or reject”
decisions to be made (e.g., if each
homeowner had an individual password
or was identified by voice print, the
Homeowner class would satisfy
characteristics 1 and 2 and would have
Class-based modeling - Specifying Attributes
Attributes describe a class that has been selected for inclusion in the requirements model.
For example, if we were to build a system that tracks baseball statistics for professional baseball players, the
attributes of the class Player (attributes such as name, position, batting average, fielding percentage, years
played, and games played might be relevant) would be quite different than the attributes of the same class
when it is used in the context of the professional baseball pension system (attributes would be meaningful, but
others would be replaced (or augmented) by attributes like average salary, credit toward full vesting, pension
plan options chosen, mailing address, and the like.)
Class-based modeling - Defining Operations
Operations define the behavior of an object. Although many different types of operations exist, they can
generally be divided into four broad categories:
(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 of an object, and
(4) operations that monitor an object for the occurrence of a controlling event.
Study a processing narrative (or use case) and select those operations that reasonably belong to
the class. To accomplish this, the grammatical parse is again studied and verbs are isolated. Some
of these verbs will be legitimate operations and can be easily connected to a specific class. For
example, from the SafeHome processing narrative presented earlier in this chapter, we see that
“sensor is assigned a number and type” or “a master password is programmed for
arming and disarming the system.” These phrases indicate a number of things:
• That an 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-based modeling - 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.

Responsibilities are the attributes and operations that are relevant for the class.
Stated simply, a responsibility is “anything the class knows or does”.

Collaborators are those classes that are required to provide a class with the
information needed to complete a responsibility. In general, a collaboration
implies either a request for information or a request for some action.
Class-based modeling - Class-Responsibility-
Collaborator (CRC) Modeling
A simple CRC index card for the FloorPlan
class is illustrated.

The list of responsibilities shown on the

CRC card is preliminary and subject to
additions or modification. The classes Wall
and Camera are noted next to the
responsibility that will require their
collaboration.
Class-based modeling - Class-Responsibility-
Collaborator (CRC) Modeling
Classes:
1. Entity classes, also called model or business classes, are extracted directly from the
statement of the problem (e.g., FloorPlan and Sensor). These classes typically represent
things that are to be stored in a database and persist throughout the duration of the
application.

2. 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.

3. Controller classes manage a “unit of work” from start to finish. That is, controller classes
can be designed to manage (i) the creation or update of entity objects, (ii) the
instantiation of boundary objects as they obtain information from entity objects, (iii)
complex communication between sets of objects, (iv) validation of data communicated
between objects or between the user and the application.
Class-based modeling - Class-Responsibility-
Collaborator (CRC) Modeling
Responsibilities:
1. System intelligence should be distributed across classes to best address the needs of the
problem.
2. Each responsibility should be stated as generally as possible.
3. Information and the behavior related to it should reside within the same class.
4. Information about one thing should be localized with a single class, not distributed across
multiple classes.
5. Responsibilities should be shared among related classes, when appropriate.
Class-based modeling - Class-Responsibility-
Collaborator (CRC) Modeling
Collaboration
Collaborations are identified by determining whether a class can fulfill each responsibility
itself. If it cannot, then it needs to interact with another class. Hence, a collaboration.

As an example, consider the SafeHome security function. As part of the activation procedure,
the ControlPanel object must determine whether any sensors are open. A responsibility
named determine-sensor-status() is defined. If sensors are open, ControlPanel must set a
status attribute to “not ready.” Sensor information can be acquired from each Sensor object.
Therefore, the responsibility determinesensor- status() can be fulfilled only if ControlPanel
works in collaboration with Sensor.
Class-based modeling - Class-Responsibility-
Collaborator (CRC) Modeling
When a complete CRC model has been developed, stakeholders can review the model using
the following approach

1. All participants in the review (of the CRC model) are given a subset of the CRC model
index cards. Cards that collaborate should be separated
2. All use-case scenarios (and corresponding use-case diagrams) should be organized into
categories.
3. The review leader reads the use case deliberately. As the review leader comes to a named
object, she passes a token to the person holding the corresponding class index card.
4. When the token is passed, the holder of the Sensor card is asked to describe the
responsibilities noted on the card. The group determines whether one (or more) of the
responsibilities satisfies the use-case requirement.
5. If the responsibilities and collaborations noted on the index cards cannot accommodate
Class-based modeling - Class-Responsibility-
Collaborator (CRC) Modeling
Associations and Dependencies

In many instances, two analysis classes are related to one another in some fashion, much like
two data objects may be related to one another. In UML these relationships are called
associations

In many instances, 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.
Class-based modeling - Class-Responsibility-
Collaborator (CRC) Modeling
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.
END