MODULE 2

5.1 Requirements Engineering

 Requirements Engineering: A structured process in software engineering that

involves gathering, analysing, and specifying requirements. It starts during the
communication phase and continues into the modelling phase.

Requirements Engineering Tasks

Requirements engineering encompasses seven distinct tasks:

1. Inception: The initial phase where the scope of the project and its stakeholders are
identified.

2. Elicitation: Gathering requirements from stakeholders.

3. Elaboration: Expanding on the gathered requirements to create a clear and detailed

description of the system.

4. Negotiation: Balancing conflicting requirements and finding feasible solutions.

5. Specification: Documenting the requirements in a precise and unambiguous manner.

6. Validation: Ensuring that the requirements accurately represent the stakeholders'

needs.

7. Management: Handling changes to the requirements throughout the development

process.

Inception

 Initial Steps: Stakeholders (e.g., business managers, marketing teams) create a

business case for the idea. They define the project's scope, perform a rough
feasibility analysis, and outline what the project should achieve.

 Understanding the Problem: During inception, the software engineering team

develops a basic understanding of:

o The problem the project aims to solve.

 o The stakeholders involved.

o The desired solution.

o The level of communication and collaboration between stakeholders and the

software team.

Elicitation

 Goal: Elicitation involves asking stakeholders (customers, users, etc.) about their
objectives, how the product will be used, and how it fits into their business.

 Challenges: Elicitation is not as simple as asking straightforward questions. Christel

and Kang identified key problems:

1. Problems of scope:

 The system’s boundaries might be unclear.

 Customers might provide unnecessary technical details that

complicate understanding of the overall objectives.

2. Problems of understanding:

 Customers may not fully know what they need.

 They might not understand their computing environment well.

 They may have trouble articulating their requirements.

 Some requirements might conflict or be ambiguous.

3. Problems of volatility:

 Requirements can change over time, making it difficult to finalize

them.

Elaboration

 Purpose: Information gathered during inception and elicitation is expanded and

refined.
  User Scenarios: The task involves creating and refining user scenarios that describe
how end users and other actors will interact with the system. These scenarios help
identify:

o Analysis classes (business entities visible to the user).

o Attributes and services (operations) of each class.

o Relationships and collaborations between classes.

 It's important to stop elaboration before it turns into design work.

Negotiation

 Purpose: Customers and users often request more features than can be
implemented due to limited resources. Also, conflicting requirements from different
stakeholders are common.

 Process: To resolve conflicts, stakeholders are asked to:

o Rank their requirements.

o Discuss and prioritize conflicting needs.

o Use an iterative approach to balance cost, risk, and internal conflicts, refining
or eliminating some requirements so that all parties reach a mutually
acceptable agreement.

Specification

 Definition: A specification can take various forms, depending on the system's

complexity and needs:

o Written documents, graphical models, mathematical models, or usage

scenarios.

o Some suggest using a standard template for consistency and clarity, but
flexibility is sometimes required.

 Formats:
 o For large systems, a detailed document with natural language and diagrams
may be needed.

o For smaller systems in well-understood environments, usage scenarios might

suffice.

Validation

 Purpose: To assess the quality of the requirements produced during earlier stages of
requirements engineering.

 Key Focus Areas:

o Ensuring that all software requirements are clearly stated and unambiguous.

o Detecting and correcting any inconsistencies, omissions, or errors.

o Verifying that the requirements conform to established standards for the

project, product, and process.

 Validation Mechanism: The primary method used for validation is the technical
review, which involves a team of software engineers, customers, users, and
stakeholders.

Requirements Management

 Purpose: To handle the inevitable changes to system requirements as the project

evolves.

 Key Activities:

o Identify, control, and track requirements throughout the project lifecycle.

o Ensure that all changes are monitored, preventing scope creep and ensuring
that changes are documented and approved.

 Relation to SCM: Many of these activities are similar to those used in software
configuration management (SCM), which involves tracking and controlling changes
in software during development.
5.2 Establishing the Groundwork

5.2.1 Identifying Stakeholders

1. Definition: A stakeholder is anyone who benefits directly or indirectly from the

system.

2. Examples: Business managers, product managers, marketing, internal/external

customers, end users, consultants, product engineers, software engineers,
support/maintenance engineers.

3. Diverse Perspectives: Each stakeholder has a unique view, benefits differently if

successful, and faces different risks if the project fails.

4. Initial List Creation: Begin with a list of stakeholders who can contribute to
requirements.

5. List Expansion: As stakeholders are contacted, ask them to suggest others who may
also provide valuable input.

5.2.2 Recognizing Multiple Viewpoints

1. Different Needs: Marketing focuses on marketable features, business managers

prioritize budget and timing, end users want ease of use, engineers focus on
infrastructure, and support wants maintainability.

2. Collecting Viewpoints: Each stakeholder contributes to requirements, often leading

to conflicting needs.

3. Categorizing Information: Organize conflicting requirements for decision-makers to

select an internally consistent set of requirements.

5.2.3 Working toward Collaboration

1. Multiple Opinions: Multiple stakeholders often have differing opinions on

requirements.

2. Role of Requirements Engineer: Identify common requirements and areas of

conflict.
 3. Resolving Conflicts: Collaboration does not imply consensus; a project champion
often makes final decisions based on stakeholder input.

5.2.4 Asking the First Questions

1. Initial Context-Free Questions:

o These questions focus on identifying stakeholders, project goals, and benefits

without delving into technical specifics.

o Examples include:

 "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?"

o Purpose: These questions help determine all stakeholders involved,

understand the benefits of the project, and identify any existing alternatives
to a custom solution.

2. Understanding the Problem:

o A second set of questions aims to clarify the problem and allows stakeholders
to express their expectations and perceptions of a solution.

o Examples include:

 "How would you characterize ‘good’ output from a successful

solution?"

 "What problem(s) will this solution address?"

 "Can you describe the business environment in which the solution will
be used?"

 "Will any performance issues or constraints affect the approach to the

solution?"
 o Purpose: These questions help in defining the project's success criteria,
identifying specific issues to be addressed, understanding the environment,
and determining any limitations that might impact development.

5.3 Requirements Elicitation

 Definition: Requirements elicitation (or gathering) combines problem-solving,

elaboration, negotiation, and specification.

5.3.1 Collaborative Requirements Gathering

Basic Guidelines:

1. Meetings Involvement:

o Conduct meetings with both software engineers and stakeholders.

2. Preparation and Participation:

o Establish rules for preparation and participation.

3. Agenda:

o Suggest a formal agenda that covers important points while allowing for
informal discussions.

4. Facilitator:

o Designate a facilitator (customer, developer, or outsider) to control the

meeting.

5. Definition Mechanism:

o Use tools like worksheets, flip charts, electronic bulletin boards, chat rooms,
or virtual forums to capture information.

Sequence of Events in Requirements Gathering

1. Inception:

o Initial meetings establish the scope of the problem and perceptions of the
solution.
 o Developers and customers create a one- or two-page “product request.”

2. Meeting Preparation:

o Schedule the meeting (date, time, place) and choose a facilitator.

o Distribute the product request to attendees prior to the meeting.

3. Attendee Preparation:

o Each attendee lists:

 Objects in the system's environment.

 Objects produced by the system.

 Objects used to perform functions.

 Services (processes or functions) that interact with objects.

 Constraints (e.g., cost, size) and performance criteria (e.g., speed,

accuracy).

Objects and Services for SafeHome

1. Objects:

o Control panel

o Smoke detectors

o Window and door sensors

o Motion detectors

o Alarm

o Events (e.g., sensor activation)

o Display

o PC

o Telephone numbers

o Telephone calls
 2. Services:

o Configuring the system

o Setting the alarm

o Monitoring the sensors

o Dialing the phone

o Programming the control panel

o Reading the display

Constraints and Performance Criteria

 Constraints:

o System must recognize non-operating sensors.

o System must be user-friendly.

o Must interface directly with a standard phone line.

 Performance Criteria:

o Sensor events should be recognized within one second.

o An event priority scheme should be implemented.

5.3.2 Quality Function Deployment (QFD)

Quality Function Deployment (QFD) is a quality management technique designed to

translate customer needs into technical requirements for software.

Types of Requirements Identified by QFD

1. Normal Requirements:

o Definition: These are objectives and goals explicitly stated by the customer
during meetings.

o Satisfaction Level: If these requirements are met, the customer is satisfied.

 o Examples: Requested types of graphical displays, specific system functions,
defined performance levels.

2. Expected Requirements:

o Definition: These are implicit needs that the customer may not explicitly
mention because they are fundamental to the product.

o Satisfaction Level: The absence of these requirements leads to significant

dissatisfaction.

o Examples: Ease of human/machine interaction, operational correctness and

reliability, ease of software installation.

3. Exciting Requirements:

o Definition: Features that exceed customer expectations and create high

satisfaction when present.

o Satisfaction Level: Their presence delights users, although they may not have
been anticipated.

o Examples: Innovative features such as multitouch screens or visual voicemail

in mobile software.

5.3.3 Usage Scenarios

Use cases provide detailed descriptions of how the system will be used, outlining
interactions between users and the system.

5.3.4 Elicitation Work Products

1. Statement of Need and Feasibility:

o A document that outlines the need for the system and assesses its feasibility,
including economic, technical, and operational considerations.

2. Bounded Statement of Scope:

o A clear definition of the boundaries of the system or product, specifying what

is included and what is excluded.
 3. List of Stakeholders:

o A comprehensive list of customers, users, and other stakeholders who

participated in the requirements elicitation process.

4. Technical Environment Description:

o An overview of the technical environment in which the system will operate,

including hardware, software, network requirements, and other relevant
factors.

5. Requirements List:

o A detailed list of requirements, preferably organized by function, along with

the domain constraints applicable to each requirement.

6. Usage Scenarios:

o A set of scenarios that illustrate how the system or product will be used
under different operating conditions, providing insights into user interactions
and workflows.

7. Prototypes:

o Any prototypes that were developed to better define requirements and

facilitate understanding of the system’s functionality.

5.4 Developing Use Case

 Use Case Definition: A use case captures a contract that describes the behaviour of a
system in response to requests from one of its stakeholders (e.g., users, devices). It
tells a stylized story about how a user interacts with the system under specific
conditions.

 Forms of Use Cases: The story of the use case can take various forms—narrative text,
task outlines, templates, or diagrams.
Actors in Use Cases

 Actors Definition: Actors are external entities (people or devices) that interact with
the system and are not part of it.

 Roles vs. Actors: A user can take on multiple roles in the system, but an actor
represents just one role.

Identifying Actors

 Primary Actors: These actors interact directly with the system and gain the main
benefits from it. They perform the main tasks.

 Secondary Actors: These support the primary actors in achieving the system’s goals
but do not engage directly or frequently.

Questions for Developing Use Cases

When developing a use case, several questions need to be considered:

 Actors: Who are the primary and secondary actors? What are their goals?

 Preconditions: What needs to be true before the use case begins?

 Tasks: What main functions are performed by the actor?

 Exceptions: What exceptions or variations might occur during the interaction?

 Information Handling: What system information will be affected, and how will the
actor interact with the system in terms of acquiring, producing, or changing data?

 External Changes: Will the actor inform the system about external environmental
changes?

 Unexpected Changes: Does the actor wish to be notified about unexpected changes?

SafeHome Use Case: Initiate Monitoring

In developing the SafeHome security system, we define four actors involved in the
interactions: the homeowner (user), setup manager (often the homeowner in a different
role), sensors (devices attached to the system), and the monitoring and response subsystem
(the central monitoring station).
Detailed Use Case Template

For a more comprehensive understanding, we can further elaborate the use case using the
template suggested by Cockburn.

Use Case: Initiate Monitoring

 Primary Actor: Homeowner

 Goal in Context: To set the system to monitor sensors when leaving the house or
remaining inside.

 Preconditions:

o The system is programmed for a password.

o Various sensors are recognized by the system.

 Trigger: The homeowner decides to "set" the system, turning on the alarm functions.

Scenario Steps:

1. Homeowner: Observes the control panel.

2. Homeowner: Enters the password.

3. Homeowner: Selects "stay" or "away".

4. Homeowner: Observes the red alarm light indicating that Safe Home has been
armed.
Exceptions:

1. Control Panel Not Ready:

o The homeowner checks all sensors to determine which are open and closes
them.

2. Incorrect Password:

o The control panel beeps once; the homeowner renters the correct password.

3. Password Not Recognized:

o The homeowner must contact the monitoring and response subsystem to

reprogram the password.

4. Stay Selected:

o The control panel beeps twice and lights the stay indicator; perimeter sensors
are activated.

5. Away Selected:

o The control panel beeps three times and lights the away indicator; all sensors
are activated.

Additional Information:

 Priority: Essential; must be implemented.

 When Available: First increment.

 Frequency of Use: Many times, per day.

 Channel to Actor: Via control panel interface.

 Secondary Actors: Support technician, sensors.

 Channels to Secondary Actors:

o Support technician: Phone line.

o Sensors: Hardwired and radio frequency interfaces.

5.6 Negotiating Requirements

The Importance of Negotiation

Negotiation is crucial for developing a project plan that addresses stakeholder needs while
accounting for real-world constraints such as time, personnel, and budget. Effective
negotiations aim for a “win-win” outcome, where:

 Stakeholders achieve a system or product that meets most of their needs.

 Software teams work within realistic and achievable budgets and deadlines.

Achieving this balance requires careful negotiation, understanding that stakeholder needs
may conflict and that compromises are often necessary.

Key Negotiation Activities

1. Identification of Key Stakeholders:

o Recognize who the primary stakeholders are for the system or subsystem.
Understanding who will be affected by or have input into the system is critical
for effective negotiation.

2. Determination of Stakeholders’ "Win Conditions":

o Engage stakeholders to clarify what success looks like for them.

Understanding their objectives helps in identifying the features and
functionalities that matter most.

3. Negotiation of Win Conditions:

 o Work collaboratively with stakeholders to reconcile their win conditions into a
unified set of achievable goals. This step is essential for aligning expectations
and ensuring that all parties feel heard and considered.

5.7 Validating Requirements

As the requirements model is developed, it undergoes a thorough examination to ensure

consistency, completeness, and clarity.

Key Review Questions

1. Consistency with Overall Objectives:

o Is each requirement aligned with the system's or product's overarching goals?

Ensuring that all requirements contribute to the intended purpose is crucial
for maintaining focus.

2. Proper Level of Abstraction:

o Are the requirements specified at an appropriate level? Some requirements

may contain excessive technical detail that is not suitable at this stage of
development.

3. Necessity of Requirements:

o Does each requirement fulfil a fundamental need, or does it represent an

optional feature? Distinguishing between essential and non-essential
requirements helps prioritize development efforts.

4. Clarity and Unambiguity:

o Are all requirements clear and free from ambiguity? Each requirement should
be bounded and easily understood to avoid misinterpretation.

5. Attribution of Requirements:

o Is there a noted source for each requirement? Attributing requirements to

specific stakeholders helps in accountability and traceability.

6. Conflict Among Requirements:

 o Do any requirements contradict one another? Identifying conflicts early
allows for resolution before they complicate the design process.

7. Achievability in Technical Environment:

o Can each requirement be realistically achieved within the intended technical

environment? Assessing feasibility is vital for practical implementation.

8. Testability:

o Is each requirement testable once implemented? Requirements should be

defined in a manner that allows for validation through testing.

9. Reflection of Information, Function, and Behavior:

o Does the requirements model accurately capture the information, functions,

and behaviors expected of the system? The model should provide a
comprehensive view of the system's capabilities.

10. Utilization of Requirements Patterns:

o Have analysis patterns been employed to streamline the requirements

model? Patterns can simplify representation and ensure consistency across
similar requirements.

6.1 Requirements Analysis

 What it is: Requirements analysis is the process of understanding what a software

system needs to do. It helps define how the software should work, what it should
connect to, and what limitations it must follow.
6.1.1 Objectives of the Requirements Model

1. Describe Customer Needs: Clearly outline what the customer requires from the
software.

2. Guide Software Design: Provide a foundation for creating a design for the software.

3. Define Verifiable Requirements: Establish a clear set of requirements that can be

checked for correctness after the software is built.

6.1.2 Analysis Rules of Thumb

1. Focus on Visible Requirements:

o Keep your attention on the requirements that are clear and relevant to the
problem or business area. Avoid getting caught up in too many details about
how the system will function.

2. Enhance Understanding:

o Each part of your requirements model should help clarify what the software
needs to do. It should give insights into the information the system will
handle, the functions it must perform, and how it will behave.

3. Postpone Nonfunctional Considerations:

o Don't worry about infrastructure needs (like databases) or other

nonfunctional aspects until after you’ve analyzed the problem. Focus first on
 understanding what the system needs to achieve before diving into how
those needs will be technically met.

4. Minimize Coupling:

o Try to keep the connections between different parts of the system (like
classes and functions) as low as possible. If everything is too interconnected,
it can complicate things.

5. Provide Value for All Stakeholders:

o Ensure that your requirements model is useful for everyone involved.

Different people (like business stakeholders, designers, and quality assurance
teams) will use the model in various ways. For instance:

 Business stakeholders can use it to check if their needs are being met.

 Designers can use it to plan the system’s structure.

 QA teams can plan how to test the software based on the

requirements.

6. Keep It Simple:

o Make your model as straightforward as possible. Avoid adding unnecessary

diagrams that don’t contribute new information. Use simple lists instead of
complex symbols when they convey the information more clearly.

6.1.3 Domain Analysis

Analysis Patterns and Their Importance

 What are Analysis Patterns? Analysis patterns are commonly used solutions or
models that often come up in specific types of businesses or applications (like
banking or healthcare).

 Benefits of Using Them: If these patterns are organized and categorized well, they
can be easily recognized and reused across projects. This speeds up the process of
creating the analysis model (a detailed understanding of what the software needs to
do) since you don’t have to start from scratch each time.
  Why This Matters: Using these reusable patterns also makes it easier to implement
design patterns and other software components later on, which leads to faster
development and lower costs.

Domain Analysis

 What is Domain Analysis? It’s a process that identifies and defines common
requirements for specific fields, such as aviation, video games, or healthcare, so
these requirements can be reused across multiple projects within the same field.

 Goal of Domain Analysis: The main goal is to find or create reusable analysis classes
(blueprints for objects) and analysis patterns that work across various projects in the
same industry. This makes development faster and more efficient.

How Domain Analysis Works

 Sources of Information: To perform domain analysis, experts in the field study

various sources of information (such as documents, existing software, and interviews
with experts) to identify objects or patterns that are frequently used across different
projects.

 Role of a Domain Analyst: The domain analyst works similarly to a specialized

toolmaker who creates tools that many people in the factory can use for similar
tasks. The analyst finds and organizes these reusable analysis patterns and classes, so
they can benefit multiple projects in the same field.
6.2 Scenario Based Modelling

6.2.1 Creating a Preliminary Use Case

What is a Use Case?

A use case is like a contract or agreement for how the system should behave when used by
an actor to achieve a specific goal. In simpler terms, it’s a detailed story about what happens
when someone uses the system for a particular purpose.

Example: SafeHome Surveillance System

In this example, the SafeHome surveillance system includes these functions for a
homeowner actor:

 Viewing different cameras.

 Requesting thumbnails (small preview images) from all cameras.

 Displaying camera views on a PC.

 Controlling pan (side-to-side) and zoom for specific cameras.

 Recording or replaying camera output.

 Accessing camera views through the internet.

Example of a Narrative Use Case

Here’s a sample of a narrative for the function: Access Camera Surveillance via the Internet.

1. Narrative Version:

o A homeowner uses a PC to log in to the SafeHome Products website.

o After logging in, they select the "Surveillance" option to view cameras.

o They pick a specific camera or view all camera thumbnails and choose one.

o The system displays the live camera feed in a viewing window.

2. Detailed Sequential Version:

o Use Case Title: Access camera surveillance via the Internet – display camera
views

o Actor: Homeowner

o Steps:

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.

What is a Use Case Exception?

An exception describes a situation that may cause the system to respond differently due to
an alternative chosen by the actor or a failure condition.

6.2.3 Writing a Formal Use Case

In this section, we’re looking at formal use cases—a structured, detailed way to define how
a user interacts with a system. While informal use cases (basic descriptions in plain
language) might be enough for simple tasks, formal use cases are helpful when a scenario is
complex or involves critical activities with multiple exceptions or error possibilities.

Structure of a Formal Use Case

A formal use case includes several parts:

1. Goal in Context: Defines the purpose and scope of the use case, giving an overview
of what it aims to achieve.

2. Precondition: Specifies conditions that must be true before the use case starts, such
as the user being logged in.

3. Trigger: Identifies the event that starts the use case, like a user action or system
event.

4. Scenario: Details the specific sequence of actions performed by the actor (user) and
the system's responses.

5. Exceptions: Lists possible alternative paths, errors, or situations that could occur and
how the system should handle them.
Diagrammatic Representation

For complex use cases, a graphical use-case diagram can help clarify interactions. In the
Unified Modeling Language (UML), use-case diagrams represent each use case as an oval,
with lines connecting it to the actors involved. This makes it easier to visualize the flow of
actions.

Advantages and Limitations of Use Cases

 Advantages: Formal use cases provide a clear, structured format for understanding
complex scenarios. They’re effective for modeling functional and behavioral
requirements and are useful in most software engineering contexts.

 Limitations: Use cases don’t typically address nonfunctional requirements (like

system performance or security standards).

6.3 UML Model

6.3.1 Developing an Activity Diagram

In requirements modeling, text-based descriptions like use cases can sometimes be limiting
because they don't always provide a quick and easy way to understand complex interactions.
For these cases, UML (Unified Modeling Language) graphical models can visually represent
processes, making them clearer and easier to follow.

Activity Diagrams
An activity diagram is one such UML model. It visually represents the steps within a
scenario, supplementing the information in a use case by showing how interactions flow
from one action to the next. It’s somewhat similar to a flowchart but includes extra UML
features. Here’s what the symbols in an activity diagram represent:

 Rounded rectangles: Indicate specific actions or system functions.

 Arrows: Show the direction of flow from one activity to the next.

 Decision diamonds: Represent points where a decision must be made, leading to

branching paths. Each path from the diamond is labeled to show the conditions for
each decision.

 Horizontal lines (bars): Denote parallel activities—actions that occur simultaneously

in different parts of the system.

For instance, in the ACS-DCV (Access Camera Surveillance - Display Camera View) use case,
the activity diagram can add further detail, like indicating that a user has only a limited
number of attempts to enter the correct user ID and password. This restriction is shown by a
decision diamond labeled “Prompt for reentry,” indicating that the user can try a few times
before being locked out or redirected.
6.3.2 Swimlane Diagrams

A swimlane diagram is a variation of the activity diagram in UML that not only shows the
flow of activities but also visually assigns responsibilities across different actors or system
components (referred to as analysis classes). Each actor or component with responsibilities
in the process gets its own "swimlane," which is a vertical column similar to lanes in a
swimming pool. This helps clarify who performs each activity in a sequence, particularly
when multiple actors or classes are involved in a single use case.

Key Elements of a Swimlane Diagram

1. Swimlanes: Each lane represents an actor or analysis class involved in the activity.
For example, in the SafeHome system use case, the swimlanes could include:

o Homeowner: The person using the system.

 o Camera: Represents the camera's functions like viewing or recording.

o Interface: Manages prompts and displays on the user interface.

2. Activity Rectangles: These rectangles within each swimlane show actions taken by
that particular actor or class. If an action moves from one actor/class to another, the
flow moves across swimlanes.

3. Flow Arrows: Arrows indicate the direction of activity flow between actions, showing
how control passes between actors or classes. For instance, in SafeHome’s diagram:

o The Interface prompts for reentry if the homeowner’s login is incorrect.

o After reentry, the control returns to the Homeowner swimlane where they
perform another action.

4. Decision Points: Just like in activity diagrams, diamonds represent decisions (e.g.,
successful login or choosing to reenter information) and direct the flow to different
outcomes.

Why Use Swimlane Diagrams?

Swimlane diagrams clarify which parts of a system are responsible for each action, making it
easier to understand interdependencies between actors and components. They also help
ensure responsibilities are clear, which is especially useful for complex systems with multiple
actors or interfaces.
6.4 Data Modelling Concept

When developing software that requires handling complex data or interfacing with a
database, creating a data model is essential. A data model organizes the information
required by the software, detailing the structure, relationships, and attributes of data
objects within the system. This approach is particularly useful for complex applications
involving significant data processing or storage requirements.

Key Concepts in Data Modeling

1. Data Objects: These are the core elements representing composite information that
the software needs to process. Each data object typically includes several attributes
that characterize it. For instance:

o Composite Structure: Instead of simple values, data objects encapsulate a set

of related attributes. For example, a "car" could be a data object with
attributes like make, model, ID number, body type, color, and owner.

o Types of Data Objects: A data object can represent different types of

elements in a system, such as:

 External Entities (e.g., a system user),

 Things (e.g., reports or user interfaces),

 Occurrences/Events (e.g., login sessions),

 Roles (e.g., administrator),

 Organizational Units (e.g., finance department), or

 Structures (e.g., a database file).

2. Data Attributes: Each data object is characterized by a set of attributes that define its
properties. Attributes serve three main purposes:

o Instance Identification: One or more attributes uniquely identify each

instance of a data object, known as an identifier or key. For instance, the ID
number might serve as a unique identifier for the "car" object.

o Description: Attributes describe specific properties of the instance. For "car,"

this could include model, color, and body type.

o Reference Links: Attributes may also link to instances of other data objects,
forming relationships across the database.
 3. relationships define the ways in which data objects interact or relate to each other
within a system. Understanding these connections is essential for building a cohesive
model that accurately represents the data’s real-world structure and behavior.

Key Aspects of Relationships

1. Object-Relationship Pairs: Each relationship connects two or more data objects, with
a specific context or purpose. For example, if we consider the data objects person
and car:

o A person owns a car: This relationship signifies that the person is the owner
of the car.

o A person is insured to drive a car: This relationship indicates that the person
has an insurance association with the car, allowing them to drive it.

Each relationship type adds a specific, contextual meaning to the connection, helping clarify
the roles and constraints on each data object within the application.

2. Directionality: Relationships often include a direction, indicated by arrows in

diagrams, to show the flow or ownership of the connection. This directionality is
essential for:

o Clarifying Ownership: For example, the arrow from person to car in the
"owns" relationship specifies that person has a stake or claim in the car.
 o Reducing Ambiguity: Clearly indicating relationship direction helps avoid
misinterpretations, as it defines which object initiates or holds the
connection.

3. Graphical Representation: Relationships are often depicted in entity-relationship

diagrams (ERDs), which use symbols and arrows to show the connections and flows
among objects:

6.5 Class Based Model

Class-based modelling is an essential aspect of software design that emphasizes the

organization and manipulation of data through objects and their interactions.

Class-Based Modelling Overview

In class-based modelling, the following elements are integral:

 Classes and Objects: Classes define the blueprint for objects, which are instances of
classes.

 Attributes: These are properties or characteristics of the classes.

 Operations: Also referred to as methods or services, these are functions that

manipulate the attributes of objects.

 Class Responsibility Collaborator (CRC) Models: These models help identify the
responsibilities of classes and their collaborations with other classes.

 Collaboration Diagrams: These visualize the interactions between classes and

objects.

 Packages: Grouping of related classes to manage complexity.

6.5.1 Identifying Analysis Classes

Identifying analysis classes in a software application can be challenging, but certain

guidelines can simplify the process:

Using Usage Scenarios

1. Examine Usage Scenarios: Start with the usage scenarios from the requirements
model. This helps contextualize the system's operation.

2. Grammatical Parsing: Perform a “grammatical parse” of use cases by underlining

nouns and noun phrases. Each identified noun can indicate a potential class.

3. Create a Table: List the identified nouns in a table, noting synonyms. This
organization helps clarify which classes are essential for the solution.

Manifestations of Analysis Classes

Analysis classes can take various forms:

 External Entities: Systems, devices, or people that interact with the software (e.g.,
users, sensors).

 Things: Items in the information domain (e.g., reports, signals).

 Occurrences or Events: Specific actions within the system (e.g., transactions, alarms).

 Roles: User roles that interact with the system (e.g., administrator, customer).

 Organizational Units: Relevant groups within the context of the application (e.g.,
departments).

 Places: Locations that provide context for system operations (e.g., warehouses).

 Structures: Classes that define a category of objects (e.g., vehicles, components).

Key Steps in Identifying Potential Classes

1. Extracting Nouns and Verbs: The narrative describes various entities and actions
involved in the security function. Nouns represent potential classes, while verbs
indicate actions or operations.
 2. Classifying Potential Classes: Each identified noun can be classified based on its role
in the system.

Considerations for Final Decisions

 Further Evaluation: Each entry in the list is initially considered a potential class.
Further analysis is necessary to determine if it should be finalized as a class in the
system design.

Selection Characteristics

1. Retained Information: The class must retain information that is necessary for the
system's operation.

2. Needed Services: The class should have identifiable operations that can modify its
attributes.

3. Multiple Attributes: The class should have more than one significant attribute to
justify its existence as a separate class.

4. Common Attributes: The class should have a set of attributes that are applicable to
all instances of the class.

5. Common Operations: The class should have operations that apply to all instances of
the class.
 6. Essential Requirements: Classes that represent external entities producing or
consuming information vital to the system should be included.

6.5.2 Specifying attributes

Attributes help clarify what each class represents and ensure that all relevant data is
captured effectively.

Importance of Attributes

Attributes are essential because they:

 Define the properties of a class.

 Differentiate between various instances of that class.

 Provide the necessary data that operations and interactions will manipulate.

Identifying Attributes

To develop a meaningful set of attributes for a class, you can follow these steps:

1. Study Use Cases: Examine the use cases related to the class to identify which data
items belong to it.

2. Identify Composite and Elementary Data Items: Determine the composite data
items that encapsulate multiple attributes, as well as any elementary attributes that
fully define the class.
 3. Ask Key Questions: For each class, consider questions like:

o What data items define this class in the context of the system?

o Are there any nested relationships (e.g., classes containing other classes) that
affect attribute definitions?

Example: Attributes of the System Class in SafeHome

For the System class in the SafeHome security function, the attributes can be organized into
categories based on their relevance:

 Identification Information

o system ID

o verification phone number

o system status

 Alarm Response Information

o delay time

o telephone number

 Activation/Deactivation Information

o master password

o number of allowable tries

o temporary password

Avoiding Redundant Attributes

When defining attributes, it's important to avoid redundancy:

 Do not define items as attributes if they will be represented as separate objects

within the class structure (e.g., multiple Sensor instances).

6.5.3 Defining operations

Operations define how an object behaves and interacts with other objects within the
system, outlining the functionalities that the class can perform.

Categories of Operations

Operations can generally be classified into four broad categories:

1. Data Manipulation Operations: These operations involve changing the state of an

object or its attributes. Common examples include:

o Add: Adding new data to an object.

o Delete: Removing data from an object.

o Reformat: Changing the format of the data.

o Select: Retrieving specific data based on certain criteria.

2. Computational Operations: These operations perform calculations or computations

using the object's data. For example, a calculateArea () operation might compute the
area of a geometric shape represented by an object.

3. Inquiry Operations: These operations check or return the current state of an object
without modifying it. Examples include:

o getStatus (): Retrieving the current status of the object.

o isActive (): Checking if the object is currently active.

4. Monitoring Operations: These operations keep track of certain conditions or events

related to an object. They might trigger other operations when a specified event
occurs. For example, an operation could monitor a sensor for triggering an alarm
when a specific condition is met.

Deriving Operations from Use Cases

To derive operations for an analysis class, you can:

1. Study the Processing Narrative or Use Case: Just like with attributes, you can look for
verbs that indicate operations. For instance, from the Safe Home processing
 narrative, the verbs “assigned,” “programmed,” “armed,” and “disarmed” hint at
various operations related to the Sensor and System classes.

2. Identify Operations Linked to Specific Classes:

o From “sensor is assigned a number and type,” you can infer that the assign ()
operation belongs to the Sensor class.

o From “a master password is programmed for arming and disarming the

system,” you can conclude that program () is an operation for the System
class.

Detailed Breakdown of Operations

For operations that require more detail, you can further decompose them into
suboperations. For example, the program () operation for the System class might encompass
several specific actions, such as:

 specifyPhoneNumbers (): Setting up emergency contact numbers.

 configureCharacteristics (): Establishing various system settings.

 enterPassword (): Inputting master or temporary passwords.

Communication Between Objects

Understanding how objects communicate is also vital for defining operations. Objects
interact by passing messages to one another, which can influence how operations are
defined.

1. Message Passing: This is a way for objects to communicate their state or request
actions from other objects.

2. Designing Operations: While defining operations, consider how messages will be

sent and received among objects. This communication can provide insight into what
operations are necessary and how they should be structured.
6.5.4 Class-Responsibility-Collaborator (CRC) Modelling

Class-Responsibility-Collaborator (CRC) modeling provides a structured way to define the

roles of classes, their responsibilities, and how they interact with other classes.

Structure of a CRC Card

A CRC card is divided into three sections:

 Class Name: At the top of the card, write the name of the class.

 Responsibilities: In the body of the card, list the responsibilities of the class on the
left side. Responsibilities include attributes and operations relevant to the class,
essentially anything the class knows or does.

 Collaborators: On the right side, note the collaborators—other classes that provide
the information or functionality needed to fulfill the responsibilities of the class.
Class Categories

In CRC modeling, classes can be categorized into three types:

1. Entity Classes:

o Also known as model or business classes.

o Directly extracted from the problem statement (e.g., FloorPlan, Sensor).

2. Boundary Classes:

o These classes create the user interface (e.g., interactive screens, printed
reports).

o They manage how entity objects are presented to users.

 3. Controller Classes:

o Manage a "unit of work" from start to finish.

o Responsible for tasks such as:

 Creating or updating entity objects.

 Instantiating boundary objects that interact with entity objects.

 Coordinating complex communications between sets of objects.

 Validating data exchanged between objects or between the user and

the application.

o Typically, controller classes are designed during the later stages of the design
activity.

Allocating Responsibilities to Classes

When designing classes in an object-oriented system, it's crucial to allocate responsibilities

(attributes and operations) thoughtfully. Wirfs-Brock and her colleagues provide five key
guidelines to help in this process:

1. Distribute System Intelligence:

o System intelligence refers to what the system knows and what it can do.

o Distributing intelligence across classes leads to a more cohesive design.

2. State Responsibilities Generally:

o Responsibilities should be articulated as generally as possible.

o General responsibilities should reside higher in the class hierarchy, as they

apply to multiple subclasses.

3. Encapsulate Data and Behavior:

o Related information and behavior should reside within the same class to
achieve encapsulation.
 o Encapsulation helps ensure that data and the processes manipulating it are
packaged as a cohesive unit

4. Localize Information:

o Information about a specific type should be localized within a single class

rather than distributed across multiple classes.

o Sharing information across classes can lead to confusion and increased

difficulty in managing software behavior.

5. Share Responsibilities When Appropriate:

o Related classes that exhibit the same behavior should share certain
responsibilities.

Collaborations in Class Design

1. Definition of Collaborations:

o Collaborations occur when a class (the client) needs to fulfil a responsibility

but cannot do so alone. It therefore sends a message to another class (the
server).

o Each collaboration represents a contract between the client and the server,
where the client relies on the server to complete a task.

2. Example of Collaboration:

o In the context of a security system like SafeHome, the ControlPanel class

might need to determine if any sensors are open.

o The responsibility determine-sensor-status() requires information from

Sensor objects, necessitating collaboration between ControlPanel and Sensor.

Types of Relationships Between Classes

Three generic relationships help identify collaborations:

1. Is-Part-Of Relationship:

o This relationship occurs when a class is a component of an aggregate class.

 o For instance, in a video game, PlayerBody is part of Player, along with
PlayerArms, PlayerLegs, and PlayerHead. This relationship is represented as
aggregation in UML.

2. Has-Knowledge-Of Relationship:

o This relationship is established when one class needs information from

another class.

o The determine-sensor-status() responsibility in the SafeHome system

exemplifies this relationship, as ControlPanel requires knowledge about
Sensor states.

3. Depends-Upon Relationship:

o This implies a dependency between classes that is not covered by the other
two relationships.

o For example, PlayerHead might depend on PlayerBody to know its center

position, without needing direct knowledge of PlayerBody.

Collaborator Identification in CRC Modeling

 Collaborator classes are recorded on the CRC (Class-Responsibility-Collaborator)

model index card next to the relevant responsibility, creating a clear connection
between responsibilities and the classes that fulfill them.
6.5.5 associations and dependencies

Associationss

1. Associations represent a relationship between two classes that need to interact or

share information.

2. They can have multiplicity constraints to define the number of objects involved in
the relationship:

o "1.." (one or more) or "0.." (zero or more) are common notations.

3. Example: In a building system, a Wall class may associate with WallSegment,

Window, and Door classes:

o Wall uses "1..*" for WallSegment (one or more segments form a wall).

o Wall uses "0..*" for Window and Door (walls may contain zero or more of
each).

Dependencies

1. Dependencies indicate that one class relies on another for specific functionality.

2. This relationship often represents a client-server interaction.

3. Stereotypes add custom semantics to dependencies, defined by keywords in double

angle brackets (e.g., <<access>>).

4. Example: In a surveillance system, DisplayWindow depends on Camera to access

video feed:

o The <<access>> stereotype here signifies that access to the camera feed is
controlled (e.g., by password).
7.1 Requirements Modeling

Requirements modeling is a crucial aspect of software development, providing insights into

the functionality and structure of a system. Two primary approaches to requirements
modeling are structured analysis and object-oriented analysis.

1. Structured Analysis

 Data and Processes: In structured analysis, data and processes are treated as
separate entities. This approach emphasizes how data objects are created,
manipulated, and transformed throughout the system.

 Data Modeling: Data objects are modeled to define their attributes (properties or
characteristics) and relationships with other data objects.

 Process Modeling: Processes that manipulate data objects are represented in a way
that illustrates how they transform data as it flows through the system. This might
involve data flow diagrams (DFDs).
  Key Elements:

o Data Flow Models: Illustrate how data moves through the system and how
various processes affect that data.

o Control Flow Models: Show the sequence of operations that are performed
on data objects.

2. Object-Oriented Analysis

 Classes and Collaboration: Object-oriented analysis focuses on defining classes

(blueprints for objects) and how these classes interact and collaborate to meet
customer requirements.

 Class Modeling: Each class is defined with its attributes and behaviors (methods).
This model provides a clear view of the components of the system and how they
relate to each other.

 Key Elements:

o Behavioral Models: Represent how objects behave and interact over time,
often using state diagrams and sequence diagrams to illustrate object
interactions.

o Interaction Models: Show how different objects communicate with each

other, emphasizing collaboration to achieve functionality.

Combining Approaches

While structured analysis and object-oriented analysis are distinct, the most effective
requirements modeling often involves a combination of both approaches.

7.2 Data Flow-Oriented Modelling

Despite being considered somewhat outdated by some software engineers, data flow-
oriented modelling remains a widely utilized technique in requirements analysis. The data
flow diagram (DFD) is particularly effective for visualizing the flow of information and
processes within a system.
7.2.1. Creating a Data Flow Model

Guidelines for Developing a DFD:

1. Level 0 DFD: Start with a high-level overview, representing the system as a single
bubble.

2. Identify Inputs/Outputs: Clearly denote primary inputs and outputs associated with
the system.

3. Refine Processes and Data: Begin isolating candidate processes, data objects, and
data stores for further detail in subsequent levels.

4. Meaningful Labels: Ensure all arrows (representing data flow) and bubbles
(representing processes) are labelled descriptively.

5. Maintain Flow Continuity: Keep the information flow consistent across different
levels of detail.

6. Single Bubble Refinement: Focus on refining one bubble at a time to avoid

overcomplication.

2. Example: Safe Home Security Function

To illustrate the DFD's application, consider the Safe Home security system. The Level 0 DFD
represents the entire security function with primary external entities interacting with the
system.
Level 1 DFD:

 The Level 0 DFD is refined into a Level 1 DFD, where the main processes are
identified through a “grammatical parse” of the use case narrative:

o Verbs in the narrative represent processes and become bubbles in the DFD.

o Nouns identify external entities, data/control objects, and data stores.

Level 2 DFD:

 Further refinement of processes like "monitor sensors" leads to a Level 2 DFD,

maintaining continuity in the information flow and providing more detail about how
the sensors are monitored.

3. Hierarchical Nature of DFDs

DFDs are structured hierarchically:

 Level 0 DFD (Context Diagram): Provides a comprehensive overview of the system.

 Subsequent Levels: Each level dives deeper into the details, with each process
bubble being refined.
7.2.2 Creating a Control Flow Model

Identifying Events and Control Items

Control flow modeling is concerned with how events trigger actions within the system. To
identify potential candidate events for control flow modeling, consider the following
guidelines:

 List Sensors: Identify all sensors that the software reads.

 Interrupt Conditions: Document all interrupt conditions that may affect system
behavior.

 Operator Actuated Switches: Identify switches actuated by user interaction.

 Data Conditions: Recognize data conditions that might influence system operations.

 Control Items from Parsing: Utilize the noun/verb parse from the processing
narrative to identify control items that could serve as inputs or outputs in the control
specification.

 State Behavior: Define the states of the system, how each state is reached, and the
transitions between them.

 Identify Omissions: Carefully review to ensure all potential pathways into or out of
states are considered.
7.2.3 The Control Specification

A control specification (CSPEC) describes system behavior at the reference level in two
primary ways: through a state diagram and a process activation table (PAT).

State Diagram

The state diagram provides a sequential specification of behavior, illustrating how the system
responds to various events. For example, in the SafeHome system:

 The Idle state can transition to other states based on events such as reset, activation,
or power off.

 The Monitoring System Status state changes the displayed messages and invokes
specific processes like monitorAndControlSystem.

 Transitions out of the Monitoring System Status state may occur when the system is
deactivated (returning to Idle) or when a sensor is triggered (moving to the Acting On
Alarm state).

Process Activation Table (PAT)

The PAT provides a complementary representation to the state diagram, focusing on which
processes will be invoked when specific events occur. This table acts as a guide for designers,
outlining the relationships between events and the processes (bubbles) in the flow model.

For instance, a PAT for the SafeHome software level 1 flow model specifies which processes
should be activated in response to specific events, serving as a framework for implementing
control logic.
7.2.4 The Process Specification

The process specification (PSPEC) is a critical component in requirements modeling,

detailing all flow model processes that have undergone the final level of refinement.

Content of the Process Specification

The PSPEC can include various forms of information, such as:

 Narrative Text: A detailed description of the process, explaining its functionality and
purpose.

 Program Design Language (PDL): A structured way to outline the algorithm and logic
of the process, often resembling pseudocode.

 Mathematical Equations: Relevant calculations or formulas necessary for the

process.

 Tables: Any data that might assist in the understanding of the process.

 UML Activity Diagrams: Visual representations that depict the flow of control or data
through the process.
By associating a PSPEC with each bubble in the flow model, you create a "mini-spec" that
can guide the development of the corresponding software component.

Example: Process Password Transform

To illustrate how a PSPEC works, consider the process password transform for the SafeHome
security function. The PSPEC for this process might be structured as follows:

PSPEC: Process Password (at control panel)

 Purpose: The process password transform validates user input at the control panel.

 Input: Receives a four-digit password from the interact with user function.

 Procedure:

1. The input password is compared to the master password stored in the

system.

 If it matches, a <valid id message = true> is sent to the message and

status display function.

 If it does not match, the process checks a table of secondary

passwords (for guests or workers needing entry).

 If a match is found within this table, <valid id message = true> is sent

to the display function.

 If there is still no match, <valid id message = false> is sent to the

display function.

 Optional Details: If more algorithmic detail is needed, a PDL representation may be

included. However, many practitioners suggest postponing the creation of the PDL
until the component design phase begins to avoid premature optimization or design
decisions.

7.3 Dynamic Behavior of the System

The transition from modeling static elements to dynamic behavior is crucial for
understanding how a software system interacts with external events. A behavioral model
effectively represents how the system responds to specific stimuli over time.

Steps to Create the Behavioral Model

1. Evaluate Use Cases: Begin by thoroughly examining all use cases to understand the
sequence of interactions between actors and the system. Each use case should detail
how the system is expected to behave under various scenarios.

2. Identify Events: Determine the events that drive these interactions and understand
their relationships to specific objects in the system. An event is recognized not by the
information exchanged, but by the occurrence of that exchange.

3. Create Sequences: For each use case, develop a sequence that outlines the order of
events and interactions.

4. Build State Diagrams: Create state diagrams that illustrate how the system
transitions between various states in response to events.

5. Review the Behavioral Model: Verify the accuracy and consistency of the behavioral
model to ensure it aligns with the requirements and expectations outlined in the use
cases.

7.3.1 Identifying Events with the Use Case

The use case serves as a key tool for identifying events that indicate information exchange
between the system and its actors. Each event marks a moment of interaction, which can
trigger further actions within the system.

Example: SafeHome Use Case

Consider a simplified use case scenario for the SafeHome security function:

 The homeowner uses the keypad to enter a four-digit password.

 The system compares this password against the valid password stored.

 If the password is incorrect, the control panel emits a beep and resets for another
input.
  If the password is correct, the control panel awaits further action.

The underlined phrases in this scenario represent events. For instance, when the
homeowner uses the keypad, we can identify the following:

 Actor: Homeowner

 Event: Password Entered

 Information Exchanged: The four-digit password (though the actual digits are not
crucial for the behavioral model)

Impact of Events

Some events directly affect the flow of control within the use case, while others do not. For
example:

 Password Entered: This event does not change the flow of control but indicates that
the homeowner has initiated an action.

 Password Compared: This event impacts the control flow as it determines whether
the entered password matches the stored one.

Once events are identified, they must be allocated to the relevant objects. For example:

 Generating Events: The Homeowner object generates the Password Entered event
when the password is entered.

 Recognizing Events: The ControlPanel object recognizes the outcome of the

Password Compared event, determining whether to beep or await further action.

7.3.2 State Representations

In behavioral modeling, understanding how systems and their components change states is
essential. Two characterizations of states are important to consider:

1. State of Each Class: This refers to the status of attributes within individual classes as
the system performs its functions.

2. State of the System: This is the external observation of the system's overall state as it
operates.
Passive and Active States

 Passive State: This represents the current values of an object's attributes at any given
moment. For instance, in a video game, the passive state of the Player class might
include attributes like position, orientation, and remaining magic wishes.

 Active State: This indicates the ongoing status of an object as it undergoes

transformations or processes. For the Player class, active states could include
moving, at rest, injured, being cured, or trapped. Transitions between these active
states are triggered by specific events.

Behavioral Representations

Two primary forms of behavioral representation are discussed:

1. State Diagrams for Analysis Classes: These UML diagrams represent the active states
of individual classes and the events (triggers) that lead to changes in those states.
Each arrow in the diagram signifies a transition between active states, with the labels
on the arrows indicating the triggering events.

For example, a state diagram for the ControlPanel object in the SafeHome security function
would show transitions such as:
 o Reading State to Comparing State triggered by the event of entering a
password.

Additionally, further detail can be provided by specifying:

o Guard: A Boolean condition that must be met for the transition to occur (e.g.,
checking if the entered password consists of 4 digits).

o Action: Operations that occur concurrently with the transition (e.g., executing
validatePassword() to compare the input password with the stored one).

2. Sequence Diagrams: This type of diagram illustrates how events lead to interactions
between different objects over time. It captures the flow of control as events are
passed from one object to another.

In a sequence diagram for the SafeHome security function:

o Time is represented vertically, with the flow of events moving downward.

o Each arrow signifies an event that channels behavior between objects.

o For instance, an initial event like system ready may trigger the Homeowner
object to enter a password, leading to further events like request lookup for
password verification.

Example of a Sequence Diagram

Consider the following sequence in the SafeHome function:

 Event 1: system ready → triggers the Homeowner.

 Event 2: password entered → Homeowner passes this to the System for validation.

 Event 3: request lookup → the System checks the password in the database and
returns a found or not found response to the ControlPanel.

 Event 4: If valid, a password=correct event is sent to the System, leading to an

activation of Sensors.

 Event 5: Finally, the ControlPanel communicates back to the Homeowner with

activation successful.
Once the complete sequence diagram is constructed, it becomes easier to compile all events
that facilitate transitions between system objects into sets of input and output events. This
information is vital for effective system design and implementation.