Module 2

Chapter 1: Understanding Requirements

Chapter 2: Requirements Modeling Scenarios, Information and

Analysis classes

Chapter 3: Requirement Modeling Strategies

 Contents
Chapter 1: Understanding Requirements: Requirements Engineering,
Establishing the groundwork / Initiating the Requirement engineering, Eliciting
Requirements, Developing use cases, Building the requirements model,
Negotiating Requirements, Validating Requirements.

Chapter 2: Requirements Modeling Scenarios, Information and Analysis

classes: Requirement Analysis, Scenario based modeling, UML models that
supplement the Use Case, Data modeling Concepts class Based Modeling.
 Module 1 - Chapter 1

Understanding Requirements
 Requirement Engineering

• The process to gather the software requirements from client, analyze and

document them is known as requirement engineering.

• The broad spectrum of tasks and techniques that lead to an understanding of

requirements is called requirements engineering.

 Requirement Engineering

• The software requirements are description of features and functionalities of

the target system.

• Requirements convey the expectations of users from the software product.

• The requirements can be noticeable or hidden, known or unknown, expected

or unexpected from client’s point of view.

 Requirement Engineering

• From a software process perspective, 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.

Requirement Engineering
 Requirement Engineering

• Requirements engineering builds a bridge to design and construction. But

where does the bridge originate?

• It begins at the feet of the project stakeholders (e.g., managers, customers, end

users), where business need is defined, user scenarios are described, functions

and features are outlined, and project constraints are identified.

 Requirement Engineering

Requirements engineering encompasses seven distinct tasks:

• Inception(Better understanding)

• Elicitation(Clear understanding)

• Elaboration(Refinement & Modelling)

• Negotiation(strategic discussion, settlement and conflicts)

• Specification(Description about SRS)

• Validation(Validates requirements)

• Management(Manage Changing requirement)

 Requirement Engineering
1. Inception
Inception is a task where the requirement engineering asks a set of questions to establish a
software process.

How does a software project start?

• Sometimes it starts with a simple chat.
• A business need is found.
• A new market or service is identified.

What happens next?

• Business stakeholders (managers, marketers, product managers) create a business case for the
idea.
• They try to understand the market and do a rough analysis to see if it's feasible.
• They outline what the project will involve.
Requirement Engineering
1. Inception

Why is this important?

• This initial information might change, but it's enough to start discussions with the software team.

At the project's inception:

• Develop a basic understanding of the problem.

• Identify the people who need a solution.

• Understand the desired solution.

• Assess the effectiveness of communication and collaboration between stakeholders and the
 Requirement Engineering

2. Elicitation

It's the process of gathering detailed requirements for the system or product from customers and
users.

• Three Problems occur during elicitation

• Scope Problems: The system boundaries might be unclear, or users might give too much
technical detail that confuses the main goals.
• Understanding Problems: Users might:

• Not know exactly what they need.

• Not understand what technology can and can't do.

 Requirement Engineering
2. Elicitation
• Have a weak grasp of the problem.

• Find it hard to communicate their needs.

• Leave out important information assuming it’s obvious.

• Have conflicting needs with other users.

• Provide unclear or untestable requirements.

• Volatility Problems: Requirements can change over time. Which will lead to loss and
wastage of resources and time.
 Requirement Engineering
2. Elicitation

• How to handle these problems?

• Approach requirements gathering in a structured and organized way to manage these

issues effectively.
• In essence, starting a software project involves recognizing a need or opportunity,
discussing it among stakeholders, and then gathering detailed requirements from
users, which is a challenging but crucial part of the process.
 Requirement Engineering

3. Elaboration:

• This phase builds upon the initial information gathered from customers, refining it further
to create a detailed requirements model.

• The information obtained from the customer during inception and elicitation is expanded
and refined during elaboration.

• As an end result this model outlines the specific functions, behaviors, and data aspects of
the software.
 Requirement Engineering

4. Negotiation:

• When customers or users request more than what's feasible given limited resources, or
when conflicting requirements arise, negotiation comes into play.

• Stakeholders rank requirements and discuss priority conflicts. Using an iterative

approach, we prioritize, assess cost and risk, and resolve conflicts, modifying
requirements to satisfy everyone.
 Requirement Engineering

5. Specification:

• In the context of computer-based systems, specification refers to documenting system

details in various forms, such as written documents, graphical models, or prototypes.

• It encompasses a range of representations, including usage scenarios, formal mathematical

models, or a combination of different formats, to accurately convey system requirements
and design.
 Requirement Engineering
6. Validation:

• This step evaluates the quality of requirements work products to ensure clarity,
consistency, and adherence to standards.

• It primarily involves technical reviews where a team of software engineers, customers,

and stakeholders examine the specification for errors, conflicts, and missing
information.

• Validation ensures that all software requirements are unambiguous, errors are corrected,
and work products meet established standards.
 Requirement Engineering

7. Requirements Management:
• Requirements for computer-based systems evolve over time, demanding a systematic
approach to identify, control, and track changes.

• It encompasses activities to manage requirements and changes throughout the project

lifecycle, ensuring alignment with project objectives.

• Requirements management helps maintain clarity and consistency in requirements

documentation, facilitating effective project execution.
 Establishing the groundwork / Initiating the Requirement engineering

• Stakeholders and software engineers work together on the same team. In such cases,
requirements engineering is simply a matter of conducting meaningful conversations with
colleagues who are well-known members of the team.

• Identifying Stakeholders: Stakeholder is “anyone who benefits in a direct or indirect

way from the system which is being developed.”

• The usual stakeholders are business operations managers, product managers, marketing
people, internal and external customers, end users, consultants, product engineers
 Establishing the groundwork / Initiating the Requirement engineering

• Understanding Diverse Perspectives: Various stakeholders bring different viewpoints to

explore system requirements, potentially leading to conflicting or inconsistent.

• Promoting Collaboration: In a software project involving multiple stakeholders, diverse

opinions on requirements arise. Effective collaboration among customers and software
engineers is essential for success.
Establishing the groundwork / Initiating the Requirement engineering

• Asking the First Questions

A requirement engineer might ask questions to customers/stake holders

Context-Free Questions:

• Identify key stakeholders and project goals:

• 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?

Establishing the groundwork / Initiating the Requirement engineering

• Asking the First Questions

A Software team might ask questions to customers/stake holders

Understanding the Problem:

• Gain insights into the problem and desired outcomes:

• How would you characterize “good” output from a successful solution?(Does the output
achieve the intended purpose?)
• What problem(s) will this solution address?

• Can you describe the business environment where the solution will be used?
Establishing the groundwork / Initiating the Requirement engineering
• Asking the First Questions

Communication Effectiveness:

• Ensure effective communication and gather comprehensive information:

• Are you the right person to answer these questions? Are your answers “official”?

• Are my questions relevant to your problem?

• Am I asking too many questions?

• Can anyone else provide additional information?

• Should I be asking anything else?

Eliciting Requirements / Requirements Gathering
• Requirements elicitation is the process of gathering and defining the
requirements for a software system.

• Requirements elicitation involves problem-solving, elaboration, negotiation,

and specification.

• Stakeholders collaborate to identify the problem, propose solutions,

negotiate approaches, and outline initial solutions requirements.
Eliciting Requirements

• Collaborative Requirements Gathering

• Quality Function Deployment

• Usage Scenarios

• Elicitation Work Products

 Eliciting Requirements
• Collaborative Requirements Gathering
Approach: Meetings with software engineers and stakeholders to identify the problem,
propose solutions, negotiate approaches, and outline preliminary requirements.

Structure:
• Preparation and participation rules are established.

• A facilitator (can be a customer, a developer, or an outsider) manages the meeting.

• Use of a definition mechanism (e.g., worksheets, wall stickers, charts) to record ideas.

• Formal agenda encourages idea exchange.

Goal: Create an environment helpful to collaborative problem-solving and requirements

specification.
 Eliciting Requirements
• Collaborative Requirements Gathering
• A meeting place, time, and date are selected; a facilitator is chosen; and attendees from the software team and
other stakeholder organizations are invited to participate. The product request is distributed to all attendees
before the meeting date.
• Each attendee is asked to make a list of objects that are part of the environment that surrounds the system,
other objects that are to be produced by the system, and objects that are used by the system to perform its
functions. In addition, each attendee is asked to make another list of services (processes or functions) that
manipulate or interact with the objects. Finally, lists of constraints (e.g., cost, size, business rules) and
performance criteria (e.g., speed, accuracy) are also developed. The attendees are informed that the lists are not
expected to be exhaustive but are expected to reflect each person’s perception of the system.
• The lists of objects - pinned to the walls of the room/electronic bulletin board/chat room
• After individual lists are presented in one topic area, the group creates a combined list by eliminating
redundant entries, adding any new ideas that come up during the discussion, but not deleting anything.
• In many cases, an object or service described on a list will require further explanation. To accomplish this,
stakeholders develop mini-specifications for entries on the lists. Each mini-specification is an elaboration of an
object or service.
• During all discussions, the team may raise an issue that cannot be resolved during the meeting. An issues list is
maintained so that these ideas will be acted on later.
“Safe Home” Project
• The home security function would protect against and/or
recognize a variety of undesirable “situations” such as illegal
entry, fire, flooding, carbon monoxide levels, and others.
• It’ll use wireless sensors to detect each situation.
• It can be programmed by the homeowner, and will automatically
telephone a monitoring agency when a situation is detected.
• Objects described for SafeHome might include the control panel,
smoke detectors, window and door sensors, motion detectors, an
alarm, an event (a sensor has been activated), a display, a PC,
telephone numbers, a telephone call, and so on.
• The list of services might include configuring the system,
setting the alarm, monitoring the sensors, dialing the phone,
programming the control panel, and reading the display (note
that services act on objects).
 “Safe Home” Project
• lists of constraints (e.g., the system must recognize when sensors
are not operating, must be user-friendly, must interface directly to a
standard phone line) and performance criteria (e.g., a sensor event
should be recognized within one second, and an event priority
scheme should be implemented).

• The mini-spec for the SafeHome object Control Panel might be:

The control panel is a wall-mounted unit that is approximately 9x5

inches in size. The control panel has wireless connectivity to sensors
and a PC. User interaction occurs through a keypad containing 12
keys. A 3x3 inch LCD color display provides user feedback. Software
 Eliciting Requirements
• Quality Function Deployment (QFD)
Purpose: Translates customer needs into technical requirements for software, focusing on
maximizing customer satisfaction.

Types of Requirements:

• Normal Requirements: When creating a product or system, there are specific objectives
and goals that are agreed upon during discussions with the customer. If the product or
system includes these requested features and functions as expected, the customer is
satisfied. Examples of normal requirements might be requested types of graphical displays,
specific system functions, and defined levels of performance.
 Eliciting Requirements
• Quality Function Deployment (QFD)
Types of Requirements:
• Expected Requirements: Fundamental but implicit needs (e.g., ease of use,
reliability).Expected requirements are the basic features or qualities that a product or
system must have, even if the customer doesn't specifically mention them.
These requirements are so essential. Examples of expected requirements are: ease of
human/machine interaction, overall operational correctness and reliability, and ease of
software installation.
• Exciting Requirements: Unexpected features that delight users (e.g., multitouch screen,
visual voicemail). These features exceed customer expectations and significantly
 Eliciting Requirements
• Quality Function Deployment (QFD)

• QFD uses customer interviews and observation, surveys, and examination of

historical data (e.g., problem reports) as raw data for the requirements gathering
activity.

• These data are then translated into a table of requirements—called the customer
voice table—that is reviewed with the customer and other stakeholders.

• A variety of diagrams, matrices, and evaluation methods are then used to

extract expected requirements and to attempt to derive exciting requirements
 Eliciting Requirements
• Usage Scenarios

Purpose: Create scenarios to understand how different user classes will interact with the
system, providing a clear vision of system functions and features.

As requirements are gathered, a clear picture of system functions emerges. To understand

user interactions before technical work, developers and users create use cases.

Use case describes how a system can be used to achieve specific goals or tasks.
 Eliciting Requirements
• Elicitation Work Products

The work products created during requirements elicitation vary by system size but

generally include key documentation and specifications.

Typical Outputs:
• A statement of need and feasibility.
• A bounded statement of scope for the system or product.
• A list of customers, users, and other stakeholders who participated in requirements elicitation.
• A description of the system’s technical environment.
• A list of requirements (preferably organized by function) and the domain constraints that apply to each.
• A set of usage scenarios that provide insight into the use of the system or product under different operating
conditions.
• Any prototypes developed to better define requirements.
 Developing Use Cases

• A use case presents a structured narrative detailing how an end user, assuming one of

several possible roles, engages with the system within a defined scenario.

• This narrative can take various forms, such as written text, task outlines, templates, or

diagrams, but always offers a picture of the software or system from the perspective of the

end user.
 Developing Use Cases
Steps to demonstrate Actors and use cases interact within a system, highlighting roles,
goals, tasks, and the basic flow of interactions.

•Use Cases and Actors: Use cases depict interactions between users/devices and a system,

while actors represent the roles in these interactions.

•Defining Actors: Identifying the actors involved in a use case is the initial step, representing

various users/devices within the system's function.

•Actor's Role: Actors symbolize the roles individuals or devices play within the system, each

with specific goals during interaction.

 Developing Use Cases
•Actor vs. End User: An actor embodies a single role in a use case, contrasting with an end

user who may assume multiple roles.

•Primary and Secondary Actors: Primary actors interact directly with the system to fulfill

its functions, while secondary actors support primary actors in achieving their tasks.

•Developing Use Cases: After identifying actors, use cases are formulated, addressing

questions about actors' roles, goals, tasks, and potential exceptions.

•Basic Use Case: It offers a top-level representation of an actor's interaction with the system,

outlining fundamental steps and interactions.

Developing Use Cases

Questions that should be answered by a use case:

• Who is the primary actor, the secondary actor(s)?
• What are the actor’s goals?
• What preconditions should exist before the story begins?
• What main tasks or functions are performed by the actor?
• What exceptions might be considered as the story is described?
• What variations in the actor’s interaction are possible?
• What system information will the actor acquire, produce, or change?
• Will the actor have to inform the system about changes in the external environment?
• What information does the actor desire from the system?
• Does the actor wish to be informed about unexpected changes?
Developing Use Cases
Developing Use Cases
Developing Use Cases
Developing Use Cases
Developing Use Cases
for online Book shop
Developing Use Cases: “Safe Home”
Actors: homeowner (a user), setup manager (likely the same person
as homeowner, but playing a different role), sensors (devices
attached to the system), and the monitoring and response
subsystem (the central station that monitors the SafeHome home
security function).

For the purposes of this example, 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”
Basic use case for system activation follows:
1. The homeowner observes the SafeHome control panel to determine if the
system is ready for input. If the system is not ready, a not ready message
is displayed on the LCD display, and the homeowner must physically close
windows or doors so that the not ready message disappears. [A not ready
message implies that a sensor is open; i.e., that a door or window is open.]
Developing Use Cases: “Safe Home”

2. The homeowner uses the keypad to key in a four-digit password.

The password is compared with the valid password stored in the
system. If the password is incorrect, the control panel will beep once
and reset itself for additional input. If the password is correct, the
control panel awaits further action.
3. The homeowner selects and keys in stay or away to activate the
system.
Stay activates only perimeter sensors (inside motion detecting
sensors are deactivated).
Away activates all sensors.
Developing Use Cases: “Safe Home”
Developing Use Cases: “Safe Home”
Developing Use Cases: “Safe Home”
 Building The Requirements Model

•The analysis model describes the required informational, functional, and

behavioral domains for a computer-based system.

•It changes dynamically as more information is learned about the system and
stakeholders refine their requirements.

•The analysis model is a snapshot of requirements at a given time and is expected to

change.
 Building The Requirements Model

•As the requirements model evolves, certain elements will become stable, providing

a foundation for subsequent design tasks.

•Other elements may remain volatile, indicating that stakeholders have not yet fully

understood the system's requirements.

 Building The Requirements Model

The analysis model and the methods:

a) Elements of the Requirements Model

i. Scenario based elements

ii. Class based elements

iii. Behavioral elements

iv. Flow oriented elements

b) Analysis Patterns
 Building The Requirements Model

a) Elements of the Requirements Model:

• There are many ways to look at the requirements for a computer-based system.

• Different modes of representation force you to consider requirements from

different viewpoints—an approach that has a higher probability of uncovering

omissions(exclusion or error) , inconsistencies, and ambiguity.

 Building The Requirements Model

a) Elements of the Requirements Model:

1. Scenario-based elements(user point of view).

• The system is described from the user’s point of view using a scenario-based
approach.
• Scenario-based elements of the requirements model are often the first part of
the model that is developed.
• Three levels of elaboration are shown, culminating in a scenario-based
representation.
 Building The Requirements Model

a) Elements of the Requirements Model:

1. Scenario-based elements.
a. Basic Use Cases: These are the initial, simple descriptions of user
interactions with the system.
b. Use-Case Diagrams: These diagrams visually represent the
interactions between users (actors) and the system.
c. Template-Based Use Cases: These are more detailed and structured
descriptions of use cases, often following a standardized format.
 Building The Requirements Model
a) Elements of the Requirements Model:
1. Scenario-based elements.
UML activity diagram for
eliciting requirements
 Building The Requirements Model

a) Elements of the Requirements Model:

2. Class-based elements:
These are essential components of analysis modeling.
•Usage scenarios: Describe how actors interact with the system by manipulating
objects.
•Categorization into classes: Group similar objects into classes based on shared
attributes and behaviors.
•Collaboration and relationships: Show how these classes work together and
interact.
 Building The Requirements Model

a) Elements of the Requirements Model:

2. Class-based elements:
 Building The Requirements Model

a) Elements of the Requirements Model:

3. Behavioral elements:

• The behavior of a computer-based system significantly impacts the design and

implementation approach.
• The requirements model must include elements that describe system behavior.
 Building The Requirements Model
a) Elements of the Requirements Model:

3. Behavioral elements:

State diagram:
• A state diagram represents system behavior by showing its states and the events
causing state changes.
• A state is any externally observable mode of behavior.
• The state diagram also indicates actions taken as a result of particular events (e.g.,
process activation).
Building The Requirements Model
a) Elements of the Requirements Model:

4. Flow-oriented elements

Involve the transformation of information within a computer-based system.

•Input:
•Can be received in various forms, such as:
•Control signals from transducers
•Series of numbers typed by a human operator
•Packets of information transmitted over network links
•Large data files retrieved from secondary storage
Building The Requirements Model

a) Elements of the Requirements Model:

4. Flow-oriented elements
•Transformation:
• The system applies functions to transform the input, which may involve:
•Single logical comparisons
•Complex numerical algorithms
•Rule-inference approaches used in expert systems
•Output:
•The system produces output in various forms, depending on the nature of the input
and the transformations applied. Exs: Output may light a single LED or produce a 200-
page report.
 Building The Requirements Model

b) Analysis Patterns:

•Recurring Problems: Requirements engineers often notice that certain problems recur

across various projects within a specific application domain.

•Analysis Patterns: These recurring problems lead to the identification of analysis

patterns, which suggest reusable solutions like a class, function, or

behavior.

•Reusability: Analysis patterns can be reused across multiple applications within the

same domain.
Negotiating Requirements
Negotiating Requirements
Negotiating Requirements
 Negotiating Requirements
Barry Boehm, an expert in software engineering, defines the activities at the
beginning of each software process iteration.

1.Boehm's Negotiation Activities: Identify Key Stakeholders: Recognize the main

stakeholders for the system or subsystem.

2.Determine Win Conditions: Identify the "win conditions" for each stakeholder.

3.Reconcile(settle) Win Conditions: Negotiate to settle these win conditions into a set of

win-win conditions for all parties involved(decision-making process achieve positive

outcomes that satisfy their respective needs and goals).

 Validating Requirements
•Examine Requirements: Each element of the requirements model is examined for
inconsistencies, omissions, and ambiguity.
•Prioritization: Stakeholders prioritize the requirements and group them into packages
for implementation in software increments.

A review of the requirements model addresses the following questions

•Consistency: Is each requirement consistent with the system/product's overall objectives?

•Level of Abstraction: Are requirements specified at the appropriate level of abstraction,

avoiding unnecessary technical details?

 Validating Requirements
A review of the requirements model addresses the following questions

•Necessity: Is the requirement essential or is it an add-on feature that may not be critical?

•Clarity: Is each requirement bounded and unambiguous?

•Attribution: Is a source noted for each requirement?

•Conflict: Do any requirements conflict with others?

•Achievability: Is each requirement achievable in the intended technical environment?

 Validating Requirements
A review of the requirements model addresses the following questions

•Testability: Is each requirement testable once implemented?

•Model Accuracy: Does the model accurately reflect the system's information, function, and

behavior?

•Partitioning: Has the model been partitioned to expose progressively more detailed

information?

•Patterns: Have requirements patterns been used and validated? Are they consistent with

customer requirements?
Summary

• Requirements engineering establishes a solid foundation for design and construction by

conducting seven key functions: inception, elicitation, elaboration, negotiation,

specification, validation, and management.

• Inception, basic requirements and constraints are defined.

• Elicitation gathers detailed requirements through meetings and scenario.

• Elaboration expands them into a detailed model.

Summary

• Negotiation prioritizes and assesses requirements to create a realistic project plan.

Specification documents the requirements clearly, and validation ensures they meet

customer needs.

• Overall, these activities ensure that the right system is built according to stakeholder

needs and constraints.

 Module 2

Chapter 2: Requirements Modeling Scenarios, Information

and Analysis classes
 Contents
Requirements Modeling Scenarios, Information and Analysis classes

a. Requirements Analysis

b. Scenario based modeling

c. UML models that supplement the Use Case

d. Data modeling Concepts

e. Class Based Modeling

 Requirements Modeling
What is it? Requirements modeling combines text and diagrams that clearly
depict software requirements, making them easier to review for accuracy,
completeness, and consistency.

Who does it? A software engineer or analyst builds the model using customer
requirements.

Why is it important? Examining requirements from multiple perspectives helps

 Requirements Modeling
What is the work product? The requirements model might include things like
written descriptions and drawings, and each one gives a different way of looking
at what's needed.

How do I ensure it's done right? Requirements models must be reviewed for
correctness, completeness, and consistency, reflecting all stakeholders' needs and
providing a solid foundation for design.
 a. Requirements Analysis
• Requirements Analysis specifies software's operational characteristics,
interfaces, and constraints.

• It elaborates on basic requirements established during inception, elicitation, and

negotiation in requirements engineering.

• Requirements modeling action produces one or more of the following models:

• Scenario-based models: View requirements from various system actors'
perspectives.
• Data models: Depict the problem's information domain.
 a. Requirements Analysis
• Class-oriented models: Represent object-oriented classes, attributes,
operations, and class collaborations.
• Flow-oriented models: Show functional elements and data transformations
within the system.
• Behavioral models: Illustrate software behavior in response to external
events.

• These models provide essential information for software designers to create

architectural, interface, and component-level designs and help developers and
customers assess software quality.
a. Requirements Analysis

Use case Diagram

a. Requirements Analysis

Data Flow Diagram

a. Requirements Analysis

Class Diagram
 a. Requirements Analysis
i) Overall Objectives and Philosophy:

Throughout requirements modeling, the primary focus is on what, not how.

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.
 a. Requirements Analysis
i) Overall Objectives and Philosophy:

• 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
a. Requirements Analysis

Fig: The requirements model as a bridge between the system description and the design model
 a. Requirements Analysis
ii)Analysis Rules of Thumb
Arlow and Neustadt suggest several key guidelines for creating an analysis model:

• Focus on visible requirements: Keep the abstraction level(core requirements) high

and avoid detailed explanations(system's internal workings ) of system operations.

• Enhance overall understanding: Each element should improve understanding of the

software's requirements, information domain, function, and behavior.
 a. Requirements Analysis
ii)Analysis Rules of Thumb

• Postpone nonfunctional considerations: Infrastructure and nonfunctional

details, like databases and their operations, networking, should be addressed
during design, not during initial analysis.

• Minimize coupling: Represent relationships between classes and functions but

reduce excessive interconnectedness.
 a. Requirements Analysis
ii)Analysis Rules of Thumb

• Ensure stakeholder value: The model should be useful to all stakeholders,

including business stakeholders for validating requirements, designers for

guiding design, and QA(testers) for planning tests.

• Keep it simple: Don’t create additional diagrams when they add no new

information. Don’t use complex notational forms, when a simple list will do.
 a. Requirements Analysis
iii)Domain Analysis:

• Analysis patterns often reappear in many applications within a specific business domain.

• By defining and categorizing these patterns, you can easily recognize and use them to solve
common problems, which speeds up development of analysis model and lowers costs.

• But how are analysis patterns and classes recognized in the first place? Who defines them,
categorizes them, and readies them for use on subsequent projects? The answers to these
questions lie in domain analysis.

• Software domain analysis is the identification, analysis, and specification of common

requirements from a specific application domain, typically for reuse on multiple projects
within that application domain
 a. Requirements Analysis
iii)Domain Analysis:
 a. Requirements Analysis
iii)Domain Analysis:

• The diagram shows that domain analysis uses sources like technical
literature, existing applications, customer surveys, expert advice, and
current/future requirements to produce a domain analysis model.

• This model includes class taxonomies(organizing domain entities), reuse

standards(promoting component reuse), functional models(system
behavior), and domain languages.
 a. Requirements Analysis
iii)Domain Analysis:

• Domain analysis examines the broader area where an application will be

used, rather than focusing on the application itself.

• The goal is to find common elements that can apply to all applications in that
area.

• It serves as a foundational activity in the software process.

 a. Requirements Analysis
iv) Requirements Modeling Approaches:

Requirements modeling approaches are methods used to capture, analyze, and

document the needs and expectations for a system.

• Two main approaches to requirements modeling.

• Structured analysis
• Object-oriented analysis
 a. Requirements Analysis
iv) Requirements Modeling Approaches:

a)Structured analysis:
• It sees data and processes that transform data as separate entities.

• Data is modeled with attributes and relationships, representing information within

the system.

• Processes are depicted with data flows, illustrating actions or operations performed by
the system.

• Utilizes tools like Data Flow Diagrams (DFDs) and Entity-Relationship Diagrams
(ERDs)
 a. Requirements Analysis
iv) Requirements Modeling Approaches:

b) Object-oriented analysis

• It focuses on defining classes and how they collaborate, often using tools like
UML(Unified Modeling Language) and the Unified Process.

• Understanding and specifying how different classes interact and work

together to achieve the desired functionality of the system.
 a. Requirements Analysis
iv) Requirements Modeling Approaches:

Each element of the requirements model presents the problem from a different
point of view.

1. Scenario-based elements, illustrate user-system interactions and the

sequential activities during software usage, enriching the understanding of
system behavior and user experience.
 a. Requirements Analysis
iv) Requirements Modeling Approaches:

2. Class-based elements model in a system describe the objects, actions

applied to them, their connections, and how they work together.

3. Behavioral elements depict how external events change the state of the
system or the classes that reside within it.
 a. Requirements Analysis
iv) Requirements Modeling Approaches:

4. Flow oriented elements show how data is transformed as it moves through

different parts of the system.

Analysis modeling helps derive these elements, though their content can vary
depending on the project.
 a. Requirements Analysis
iv) Requirements Modeling Approaches:

Fig: Elements of Analysis Model

 b. Scenario based modelling
Requirements modeling with UML begins with the creation of scenarios in the
form of use cases, activity diagrams, and swimlane diagrams.

i) Creating a Preliminary Use Case

ii) Refining a Preliminary Use Case

iii)Writing a Formal Use Case

 b. Scenario based modelling
i) Creating a Preliminary Use Case
• A use case captures the interactions that occur between producers and consumers of
information and the system itself. It describes a specific usage scenario from the point
of view of a defined actor.
1. What to write about: Use information from inception and elicitation phases.
2. How much to write: Focus on the scope of the problem and priorities.
3. Detail level: Specify functional requirements and objects involved.
4. Organization: List functions or activities performed by the actor.
 b. Scenario based modelling
i) Creating a Preliminary Use Case
• The SafeHome home surveillance function (subsystem) identifies the following functions (an
abbreviated list) that are performed by the homeowner actor:
• 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.
 b. Scenario based modelling
i) Creating a Preliminary Use Case
• Use case: Access camera surveillance via the Internet—display camera views
(ACS-DCV)
• Actor: homeowner
1. The homeowner logs onto the SafeHome Products website.
2. The homeowner enters his or her user ID.
3. The homeowner enters two passwords (each at least eight characters in length).
4. The system displays all major function buttons.
5. The homeowner selects the “surveillance” from the major function buttons.
6. The homeowner selects “pick a camera.”
7. The system displays the floor plan of the house.
8. The homeowner selects a camera icon from the floor plan.
9. The homeowner selects the “view” button.
10. The system displays a viewing window that is identified by the camera ID.
11. The system displays video output within the viewing window at one frame per
second.
 b. Scenario based modelling
ii) 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.
To fully understand a use case, evaluate alternative interactions by asking:
1.Can the actor take a different action?
2.Can an error occur at this step?
3.Can other behaviors occur at this step?
• These questions help create secondary scenarios for alternative behaviors.
 b. Scenario based modelling
ii) Refining a Preliminary Use Case:
For example, consider steps 6 and 7 in the primary scenario presented earlier:
6. The homeowner selects “pick a camera.”
7. The system displays the floor plan of the house.
Can the actor take some other action at this point? The answer is “yes.”; the actor may choose to view
thumbnail snapshots of all cameras simultaneously. Hence, one secondary scenario might be “View thumbnail
snapshots for all cameras.”
Is it possible that the actor will encounter some error condition at this point? Again the answer to the question
is “yes.” A floor plan with camera icons may have never been configured. Hence, selecting “pick a camera”
results in an error condition: “No floor plan configured for this house.” This error condition becomes a secondary
scenario.
Is it possible that the actor will encounter some other behavior at this point? Again the answer to the question is
“yes.” As steps 6 and 7 occur, the system may encounter an alarm condition. This would result in the system
displaying a special alarm notification (type, location, system action) and providing the actor with a number of
options relevant to the nature of the alarm. Because this 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.
 b. Scenario based modelling
ii) Refining a Preliminary Use Case:

Additional considerations:

• Validation functions: Might cause errors.

• Supporting function failures: Such as timeouts.

• System performance issues: May lead to improper user actions.

 b. Scenario based modelling
iii) Writing a Formal Use Case: When a use case involves critical activities or
complex steps with many exceptions, a formal, detailed approach is needed
beyond informal descriptions.
Each use case is represented by an
oval. Only the
ACS-DCV use case has been discussed
 c. UML Models that supplement the use case

A UML (Unified Modeling Language) model is a standardized visual

representation used in software engineering to describe, design, and document
the structure and behavior of a system.

i) Developing an Activity Diagram

ii) Swimlane Diagrams

 c. UML Models that supplement the use case
i) Developing an Activity Diagram

A UML activity diagram enhances a use case by visually representing the

interaction flow within a specific scenario.

• Rounded Rectangles: These represent specific system functions or activities.

Each rectangle indicates a task that needs to be completed.

• Arrows: Arrows show the flow of control or data from one activity to the next,

illustrating the sequence of actions.

 c. UML Models that supplement the use case
i) Developing an Activity Diagram

• Decision Diamonds: These depict points where a decision must be made,

leading to different branches of activity.

• Horizontal Lines (Bars): Solid horizontal lines indicate the start or end of

parallel activities, showing that multiple actions can occur simultaneously.

 c. UML Models that supplement the use case
i) Developing an Activity Diagram

Activity diagram for Access

camera surveillance via the
Internet— display camera views
function.
 c. UML Models that supplement the use case
ii) Swimlane Diagrams

• A UML swimlane diagram is a variation of the activity diagram. It represents the

flow of activities in a use case while indicating which actor or analysis class is

responsible for each activity.

• Responsibilities are shown as parallel segments dividing the diagram vertically,

resembling swimming lanes. This makes it clear who is responsible for each

action in the process.

 c. UML Models that supplement the use case
ii) Swimlane Diagrams

Swimlane diagram for

Access camera
surveillance via the
Internet—display
camera views function
 d. Data modeling concepts
Software requirements involve creating, extending, or interfacing with a database, or
handling complex data structures, the software team might create a data model.

This model, often depicted as an entity-relationship diagram (ERD), helps define:

• Data objects

• Data attributes

• Relationships

• Additional information
 d. Data modeling concepts
• Data objects: A data object represents composite information that software must
understand. For example, "dimensions" (height, width, depth) is a valid data object,
unlike a single value like "width."

A data object can be:

• External entity: Produces or consumes information Thing: A report or display.

• Occurrence/event: A telephone call or alarm. Role: Salesperson.

• Organizational unit: Accounting department. Place: Warehouse.

• Structure: File.
 d. Data modeling concepts
• Data objects: A data object encapsulates data only—there is no reference within a data object
to operations that act on the data. Therefore, the data object can be represented as a table.
 d. Data modeling concepts
ii) Data Attributes

• Data attributes define the properties of a data object and can:

1.Name an instance of the data object.

2.Describe the instance.

3.Reference another instance in another table.

• One or more attributes serve as an identifier or "key" to find instances of the data
object. Identifier values can be unique but it's not mandatory.
 d. Data modeling concepts
iii) Relationships
Data objects are connected in various ways. For example, the objects "person" and
"car" are related. To determine their relationships, understand the roles within
the software context.
Some possible relationships are:
•A person owns a car.
•A person is insured to drive a car.

These object/relationship pairs define how the data objects are connected.
 e. Class-based modeling
Class-based modeling represents the objects that the system will manipulate,
the operations that will be applied to the objects to effect the manipulation,
relationships 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.
 e. Class-based modeling
i) Identifying Analysis Classes

• Classes are identified 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.

• If a class is essential for making the solution work, it's in the 'solution space’.

• If it just talks about the solution but doesn't make it happen, it's in the
'problem space’.
 e. Class-based modeling
i)Identifying Analysis Classes - Analysis classes can be categorized or understood according to
certain types or patterns.
• 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.
 e. Class-based modeling
i)Identifying Analysis Classes
The SafeHome security function enables the homeowner to configure the security
system when it is installed, monitors all sensors connected to the security system,
and interacts with the homeowner through the Internet, a PC, or a control panel.
During installation, the SafeHome PC is used to program and configure the system.
Each sensor is assigned a number and type, a master password is programmed for
arming and disarming the system, and telephone number(s) are input for dialing
when a sensor event occurs.
When a sensor event is recognized, the software invokes an audible alarm attached to
the system. After a delay time that is specified by the homeowner during system
configuration activities, the software dials a telephone number of a monitoring
service, provides information about the location, reporting the nature of the event that
has been detected.
The telephone number will be redialed every 20 seconds until telephone connection is
obtained.
The homeowner receives security information via a control panel, the PC, or a browser,
collectively called an interface. The interface displays prompting messages and system
status information on the control panel, the PC ,or the browser window. Homeowner
interaction takes the following form . . .
 e. Class-based modeling
i)Identifying Analysis Classes
Extracting the nouns,
we can propose a
number of potential
classes:
 e. Class-based modeling
i)Identifying Analysis Classes
Coad and Yourdon [Coa91] suggest six selection characteristics that should be used
as you consider 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.
 e. Class-based modeling
i) Identifying Analysis Classes
 e. Class-based modeling
i)Identifying Analysis 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
been accepted).
 e. Class-based modeling
ii) Specifying Attributes

• Attributes are the data objects that define a class within the problem context.

They describe a class included in the requirements model, clarifying what the

class means in the problem space.

• To identify meaningful attributes for an analysis class, study each use case

and select relevant "things" that belong to the class.

 e. Class-based modeling
ii) Specifying Attributes
To illustrate, we consider the System class defined for SafeHome. A homeowner can configure
the security function to reflect sensor information, alarm response information,
activation/deactivation information, identification information, and so forth. We can represent
these composite data items in the following manner:
 e. Class-based modeling
iii) Defining Operations
Operations define an object's behavior and fall into
four broad categories:
1. Operations that manipulate data (e.g., adding,
deleting, reformatting, selecting)
2. Operations that perform computations.
3. Operations that inquire about the object's state.
4. Operations that monitor the object for events.
 e. Class-based modeling
iii) Defining Operations
As a first iteration at deriving a set of operations for an analysis class, 
processing narrative (or use case)  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; 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.
In addition to the grammatical parse, you can gain additional insight into
other operations by considering the communication that occurs
between objects. Objects communicate by passing messages to one
Class Diagram

for a Floor Plan

 e. Class-based modeling
iv) 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 requirements.

• A CRC model uses index cards to represent classes, divided into three sections.

The class name is written at the top,

responsibilities on the left, and

 e. Class-based modeling
iv) 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 requirements.

• A CRC model uses index cards to represent classes, divided into three sections.

The class name is written at the top,

responsibilities on the left, and

 e. Class-based modeling
iv) Class-Responsibility-Collaborator (CRC) Modeling

• In reality, the CRC model may make use of actual or virtual index cards. The intent is to
develop an organized representation of classes.

• 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.
 e. Class-based modeling
iv) Class-Responsibility-Collaborator (CRC) Modeling

for the FloorPlan class

Example CRC Model index card for Order Class
 e. Class-based modeling
iv) Class-Responsibility-Collaborator (CRC) Modeling

Classes: The taxonomy of class types presented earlier can be extended by considering the following categories:
• 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.
• 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. Entity objects contain information that is important to users, but they do
not display themselves. Boundary classes are designed with the responsibility of managing the way entity objects
are represented to users. For example, a boundary class called CameraWindow would have the responsibility of
displaying surveillance camera output for the SafeHome system.
• Controller classes manage a “unit of work” from start to finish. That is, controller classes can be designed to
manage (1) the creation or update of entity objects, (2) the instantiation of boundary objects as they obtain
information from entity objects, (3) complex communication between sets of objects, (4) validation of data
communicated between objects or between the user and the application. In general, controller classes are not
considered until the design activity has begun.
 e. Class-based modeling
iv) Class-Responsibility-Collaborator (CRC) Modeling
Responsibilities:
Distribute System Intelligence: Spread functionality across multiple classes to improve
maintainability and minimize unintended consequences.
• “Dumb” classes (those that have few responsibilities) can be modeled to act as servants
to a few “smart” classes (those having many responsibilities).
• System intelligence is more evenly distributed across the classes
To determine whether system intelligence is properly distributed, the responsibilities noted
on each CRC model index card should be evaluated to determine if any class has an
extraordinarily long list of responsibilities. This indicates a concentration of intelligence.
 e. Class-based modeling
iv) Class-Responsibility-Collaborator (CRC) Modeling
Responsibilities:
General Responsibilities: Assign broad tasks to higher-level classes in the hierarchy.
because they are generic  they will apply to all subclasses
•Encapsulation: Keep data and its related behaviors within the same class.
•Localized Information: Handle specific information within a single class to avoid
spreading it across multiple classes.
•Shared Responsibilities: Share behaviors among related classes when needed to maintain
consistency.
 e. Class-based modeling
iv) Class-Responsibility-Collaborator (CRC) Modeling
Collaboration Types:

1.Is-part-of: This relationship indicates that a class is a component or piece of a larger, whole
class.
2. Has-knowledge-of: This type of collaboration occurs when one class needs to obtain
information from another class to fulfill its responsibilities.
3. Depends-upon: This relationship implies a dependency between two classes that isn't
necessarily about direct knowledge or being a part of a whole. Instead, it’s about an indirect
dependency.(foreign key )
 e. Class-based modeling
iv) 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.

Collaboration Types - three different generic relationships between classes

 is a part of
 has knowledge of
 depends upon
 e. Class-based modeling
iv) Class-Responsibility-Collaborator (CRC) Modeling

Collaboration Types:

An employee is a part of a department

An Employee has knowledge of their Manager through the ManagerID field.
The Employee table depends upon the Project table because each employee is
assigned to a project and needs the project details to perform their work.
 e. Class-based modeling
iv) Class-Responsibility-Collaborator (CRC) Modeling
Collaboration Types:
 e. Class-based modeling
iv) Class-Responsibility-Collaborator (CRC) Modeling
Reviewing CRC Models
1.Distribute CRC Cards:
1. Each participant in the review receives a subset of the CRC cards.
2. Ensure that no participant has two cards that are collaborators.
2.Organize Use-Case Scenarios:
1. Group use-case scenarios into categories for systematic review.
3.Read Use Cases:
1. The review leader reads each use case out loud.
2. When a class mentioned in the use case is reached, pass a token to the participant holding
the corresponding CRC card.
 e. Class-based modeling
iv) Class-Responsibility-Collaborator (CRC) Modeling
Reviewing CRC Models

4. Verify Class Responsibilities:

•The token holder describes the responsibilities on their CRC card.
•The group assesses if these responsibilities satisfy the requirements of the use case.
5. Modify Cards if Necessary:
•If the responsibilities and collaborations on the CRC cards do not meet the use-case
requirements, update the cards.
•This might include defining new classes, revising existing responsibilities, or identifying new
collaborations.
 e. Class-based modeling
V. Associations and Dependencies:

Two analysis classes are connected, similar to how two data objects are linked.
In UML, these connections are called associations.

These associations can have specific rules called multiplicity.

Multiplicity constraints show how many instances of one class are connected
to instances of another.
 e. Class-based modeling
V. Associations and Dependencies:

For example:
- "One or more" connections are represented as 1..*.
- "Zero or more" connections are represented as 0..*.

In UML, the asterisk (*) means there's no limit on the number of connections.

Dependency refers to a relationship between two classes where a change in one class may
affect the other class.
 e. Class-based modeling
• V. Associations and Dependencies
 e. Class-based modeling

VI. Analysis Packages:

In analysis modeling, elements are grouped into categories called analysis packages.
These packages are given representative names and help organize the model.

For example, in video game classes like Tree, Landscape, Road, and others may belong to
one category. Another category might focus on detailing their physical features, actions,
and limitations.
 e. Class-based modeling
• VI. Analysis Packages:
Analysis Packages:
For video game
 e. Class-based modeling
VI. Analysis Packages:
These classes are organized into packages.
• The plus symbol (+) preceding an element within a package indicates that the
element has public visibility.
• A minus sign (-) signifies that the element is hidden from all other
packages.
• A pound symbol (#) indicates that the element is accessible only to packages
contained within a specific package
 Module 2

Chapter 3: Requirement Modeling Strategies

Requirement Modeling Strategies
Requirement Modeling Strategies
Two approaches to Requirements Modeling:

• Structured Analysis – data and the processes that transform the data are treated as
separate entities. Data objects are modeled in a way that defines their attributes
and relationships. Processes that manipulate data objects are modeled in a manner
that shows how they transform data as data objects flow through the system.

• Object-oriented Analysis – focuses on the definition of classes and the manner in

which they collaborate with one another to effect customer requirements.
Requirement Modeling Strategies
Flow Oriented Modeling
• The Data Flow Diagram (DFD) takes an input-process-output view of a system. That
is, data objects flow into the software, are transformed by processing elements, and
resultant data objects flow out of the software.

• Data objects are represented by labeled arrows

• Transformations are represented by circles (also called bubbles).

• The DFD is presented in a hierarchical fashion:

• The first data flow model (sometimes called a level 0 DFD or context diagram)
represents the system as a whole.

• Subsequent data flow diagrams refine the context diagram, providing increasing detail
with each subsequent level.
 Flow Oriented Modeling - Creating a Data Flow
Model
• The DFD enables to develop models of information
domain & functional domain.

• With DFD refinement (L0, L1…)  implicit functional

decomposition of the system.

• DFD refinement results in a corresponding refinement of

data as it moves through the processes that embody the
application.
 Flow Oriented Modeling - Creating a Data Flow
Model
Guidelines to aid the derivation of a data flow diagram:
(1)the level 0 data flow diagram should depict the software/system
as a single bubble;
(2) primary input and output should be carefully noted;
(3) Refinement should begin by isolating candidate processes, data
objects, and data stores to be represented at the next level;
(4) all arrows and bubbles should be labeled with meaningful
names;
(5) information flow continuity must be maintained from level to
level and
(6) one bubble at a time should be refined.

There is a natural tendency to overcomplicate the data flow diagram.

This occurs when you attempt to show too much detail too early or
Flow Oriented Modeling - Creating a Data Flow
Model
Level 0 DFD for the security
function

The primary external entities (boxes) produce information for use by the system and
consume information generated by the system. The labeled arrows represent data objects or
data object hierarchies. For example, user commands and data encompasses all
configuration commands, all activation/deactivation commands, all miscellaneous
interactions, and all data that are entered to qualify or expand a command.
Flow Oriented Modeling - Creating a Data Flow
Model
By performing a grammatical parse on the processing narrative for a
bubble at any DFD level, you can generate much useful information
about how to proceed with the refinement to the next level.

• Referring to the grammatical parse, verbs are SafeHome

processes and can be represented as bubbles in a subsequent DFD.
Nouns are either external entities (boxes), data or control
objects (arrows), or data stores (double lines).

• Nouns and verbs can be associated with one another

 e. Class-based modeling
DFD
The SafeHome security function enables the homeowner to configure the security
system when it is installed, monitors all sensors connected to the security system, and
interacts with the homeowner through the Internet, a PC, or a control panel.
During installation, the SafeHome PC is used to program and configure the system.
Each sensor is assigned a number and type, a master password is programmed for
arming and disarming the system, and telephone number(s) are input for dialing when a
sensor event occurs.
When a sensor event is recognized, the software invokes an audible alarm attached to
the system. After a delay time that is specified by the homeowner during system
configuration activities, the software dials a telephone number of a monitoring service,
provides information about the location, reporting the nature of the event that has been
detected.
The telephone number will be redialed every 20 seconds until telephone connection is
obtained.
The homeowner receives security information via a control panel, the PC, or a browser,
collectively called an interface. The interface displays prompting messages and system
status information on the control panel, the PC ,or the browser window. Homeowner
interaction takes the following form . . .
 Flow Oriented Modeling - Creating a Control
Flow Model
• For some types of applications, the data model and DFD suffice for meaningful
software requirements.
• However, a large class of applications are “driven” by events rather than data,
produce control information rather than reports or displays, and process information
with heavy concern for time and performance. Such applications require the use of
control flow modeling in addition to data flow modeling.
• An event or control item is implemented as a Boolean value (e.g., true or false, on
or off, 1 or 0) or a discrete list of conditions (e.g., empty, jammed, full). To select
potential candidate events, the following guidelines are suggested:
• List all sensors that are “read” by the software.
• List all interrupt conditions.
• List all “switches” that are actuated by an operator.
• List all data conditions.
• Recalling the noun/verb parse review all “control items” as possible control
specification inputs/outputs.
• Describe the behavior of a system by identifying its states, identify how each
state is reached, and define the transitions between states.
• Focus on possible omissions—a very common error in specifying control; for
example, ask: “Is there any other way I can get to this state or exit from it?”
Flow Oriented Modeling - The Control Specification
A control specification (CSPEC) represents the behavior of the
system in two different ways. The CSPEC contains a

• State diagram that is a sequential specification of behavior. The

diagram indicates how the system responds to events as it
traverses the states defined at a particular level. By reviewing the
state diagram, you can determine the behavior of the system and,
more important, ascertain whether there are “holes” in the specified
behavior.

• Program activation table (PAT)—a combinatorial specification

of behavior. The PAT represents information contained in the state
diagram in the context of processes, not states. That is, the table
Preliminary State Diagram for the
Level 1 Control Flow Model for
PAT for the level 1
flow model of
SafeHome software
 Flow Oriented Modeling - The Process Specification
• The process specification (PSPEC) is used to describe all flow model
processes that appear at the final level of refinement.

• The content of the process specification can include narrative text, a

program design language (PDL) description of the process algorithm,
mathematical equations, tables, or UML activity diagrams.

• By providing a PSPEC to accompany each bubble in the flow model, you

can create a “mini-spec” that serves as a guide for design of the
software component that will implement the bubble.
 Flow Oriented Modeling - The Process Specification
To illustrate the use of the PSPEC, consider the process password transform represented
in the flow model for SafeHome (Figure 7.2). The PSPEC for this function might take the
form:

• PSPEC: process password (at control panel).

• The process password transform performs password validation at the control panel for
the SafeHome security function. Process password receives a four-digit password from
the interact with user function.

• The password is first compared to the master password stored within the system. If the
master password matches, <valid id message = true> is passed to the message and
status display function.

• If the master password does not match, the four digits are compared to a table of
secondary passwords (these may be assigned to house guests and/or workers who
Requirement Modeling Strategies
 Creating a Behavioral Model
The modeling notation upto now represents static elements of the
requirements model. Behavioral Model  dynamic behavior of the
system/product, as a function of specific events & time. It indicates how
software will respond to external events or stimuli.

To create the model, you should perform the following steps:

1. Evaluate all use cases to fully understand the sequence of interaction

within the system.

2. Identify events that drive the interaction sequence & understand how
these events relate to specific objects.

3. Create a sequence for each use case.

Creating a Behavioral Model - Identifying Events with the Use Case
• A use case represents a sequence of activities that involves actors
and the system.

• In general, an event occurs whenever the system and an actor

exchange information.

• An event is not the information that has been exchanged, but rather the
fact that information has been exchanged.

• A use case is examined for points of information exchange.

Ex: Use case for a portion of the SafeHome security function: The
homeowner uses the keypad to key in a four-digit password. The
password is compared with the valid password stored in the system.
Creating a Behavioral Model - Identifying Events with the Use Case
The underlined portions  indicate events. An actor should be identified for
each event; the information exchanged should be noted, and any
conditions or constraints should be listed.

• Ex for event: “homeowner uses the keypad to key in a four-digit

password.” In the context of the requirements model, the object,
Homeowner, transmits an event to the object ControlPanel. The event
might be called password entered. The information transferred is the four
digits that constitute the password.

• Once all events have been identified, they are allocated to the objects
involved. Objects can be responsible for generating events (e.g.,
Creating a Behavioral Model - State Representations
• In behavioral modeling, two different characterizations of states must be
considered:
(1) the state of each class as the system performs its function and
(2) the state of the system as observed from the outside as the system
performs its function
• The state of a class takes on both passive and active characteristics.
• A passive state is simply the current status of all of an object’s attributes.
Ex- the passive state of the class Player (video game application) would
include the current position and orientation attributes of Player as well as
other features of Player relevant to the game.
• The active state of an object indicates the current status of the object as
it undergoes a continuing transformation or processing. The class Player
might have the following active states: moving, at rest, injured, being
cured; trapped, lost, and so forth.
Creating a Behavioral Model - State Representations
Two different behavioral representations:

• State diagrams for analysis classes – indicate how an individual class

changes state based on external events. It is a UML state diagram
that represents active states for each class and the events (triggers)
that cause changes between these active states.

• Sequence diagrams - show the behavior of the software as a

function of time. It is called a sequence diagram in UML  indicates
how events cause transitions from object to object as a function of
time. Once events have been identified by examining a use case, the
modeler creates a sequence diagram. In essence, the sequence diagram is
Creating a Behavioral Model - State Representations
Although the active state model provides useful insight into the “life history” of an object,
it is possible to specify additional information to provide more depth in understanding the
behavior of an object. In addition to specifying the event that causes the transition to occur,
you can specify a guard and an action.

A guard is a Boolean condition that must be satisfied in order for the transition to occur. Ex
- the guard for the transition from the “reading” state to the “comparing” state in Figure 7.6
can be determined by examining the use case:

In general, the guard for a transition usually depends upon the value of one or more
attributes of an object. In other words, the guard depends on the passive state of the
object.

An action occurs concurrently with the state transition or as a consequence of it and

generally involves one or more operations (responsibilities) of the object. For example, the
Figure 7.7 illustrates a partial sequence diagram for the SafeHome security function.
Each of the arrows represents an event (derived from a use case) and indicates how
the event channels behavior between SafeHome objects. Time is measured vertically
(downward), and the narrow vertical rectangles represent time spent in processing an
activity. States may be shown along a vertical time line.
The first event, system ready, is derived from the external environment and channels
behavior to the Homeowner object. The homeowner enters a password. A request
lookup event is passed to System, which looks up the password in a simple database
and returns a result (found or not found) to ControlPanel (now in the comparing
state).
A valid password results in a password=correct event to System, which activates
Sensors with a request activation event. Ultimately, control is passed back to the
homeowner with the activation successful event.
Once a complete sequence diagram has been developed, all of the events that cause