BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Module-02

Chapter: -1 - Understanding Requirements

Requirements Engineering

The Challenge of Building Software:

o Software development is engaging and creative but can lead to prematureaction

without proper understanding of requirements.
o Some developers argue that understanding evolves during the build, stakeholders
understand better with early iterations, and rapid changes make detailed
requirements unnecessary.
o These arguments have elements of truth but can lead to project failure ifnot
managed properly.

Requirements Engineering:

o A crucial software engineering action starting during the communication

activity and continuing into the modelling activity.
o It builds a bridge to design and construction, originating from stakeholders'needs
or a broader system definition.

Tasks of Requirements Engineering:

o Inception: Establishes a basic understanding of the problem,

stakeholders, desired solution, and preliminary communication and
collaboration.
o Elicitation: Involves gathering requirements from customers/users, often
encountering problems of scope, understanding, and volatility.
o Elaboration: Refines and expands the information obtained during inceptionand
elicitation, developing a detailed requirements model.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Negotiation: Reconciles conflicts between different stakeholders’ requirements

through prioritization, cost and risk assessment, and iterativediscussions.
o Specification: Documents requirements in various forms, such as written
documents, graphical models, usage scenarios, prototypes, orcombinations
thereof.
o Validation: Assesses the quality of requirements to ensure they are
unambiguous, consistent, complete, and conform to standards.
o Requirements Management: Tracks and controls changes to
requirements throughout the project's life, similar to software
configuration management.

Inception Stage:

o Projects usually begin from a business need or market opportunity.

o Stakeholders define the business case, market scope, feasibility, and project
scope, initiating discussions with the software engineering team.

Elicitation Stage:

o Challenges include ill-defined system boundaries, misunderstandings aboutneeds,

and evolving requirements.
o An organized approach to requirements gathering is essential.

Elaboration Stage:

o Focuses on developing a refined model that identifies software

functions, behaviours, and information.
o User scenarios are used to extract and define analysis classes and their
attributes, services, relationships, and collaborations.

Negotiation Stage:
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Resolves conflicts between different stakeholders' requirements through

iterative prioritization and compromise to achieve mutual satisfaction.

Specification Stage:

o Requirements can be documented in various forms, with flexibility dependingon the

project size and complexity.
o Consistent presentation of requirements is beneficial for clarity.

Validation Stage:

o Technical reviews are conducted to ensure requirements are clear, complete, and
correct, involving a review team of engineers, customers, users, and stakeholders.

Requirements Management Stage:

o Ongoing activity to manage changes to requirements throughout the

project's lifecycle, involving identification, control, and tracking of
changes.

Establishing the ground work

Ideal vs. Real-world Settings:

 In an ideal scenario, stakeholders and software engineers work closely as asingle

team.
 Reality often involves geographical separation, vague requirements,
conflicting opinions, limited technical knowledge, and time constraints.

Establishing Groundwork for Requirements:

 It’s crucial to lay a strong foundation for understanding software

requirements to ensure project success.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Identifying Stakeholders:

 Defined as anyone who benefits directly or indirectly from the systembeing

developed.
 Common stakeholders include business managers, product managers,
marketing, internal/external customers, end users, consultants, product
engineers, software engineers, and support/maintenance engineers.
 Begin with an initial list of stakeholders and expand it by asking each
stakeholder for additional contacts.

Recognizing Multiple Viewpoints:

 Different stakeholders have different views and priorities for the system.
 Marketing focuses on marketable features, business managers on budget and
timelines, end users on usability, software engineers on technical
infrastructure, and support engineers on maintainability.
 Collect and categorize stakeholder information to address inconsistenciesand
conflicts in requirements.

Working toward Collaboration:

 Collaboration involves stakeholders providing their viewpoints and

working together to resolve conflicts.
 A requirements engineer identifies commonalities and conflicts,
facilitating decision-making.
 A strong project champion often makes final decisions on requirements.

Asking the First Questions:

 Initial questions should be context-free, focusing on identifying

stakeholders, project goals, and benefits:
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Who is behind the request?

o Who will use the solution?
o What is the economic benefit of the solution?
o Are there alternative sources for the solution?
 Follow-up questions aim to understand the problem and solution context:
o What constitutes good output?
o What problems will the solution address?
o Describe the business environment for the solution.
o Any special performance issues or constraints?
 Meta-questions assess the effectiveness of communication:
o Are you the right person to answer these questions?
o Are your answers official?
o Are my questions relevant?
o Am I asking too many questions?
o Can anyone else provide more information?
o Should I ask anything else?

Moving Beyond Initial Q&A:

 Initial Q&A sessions are useful for the first encounter but should evolve into a
more dynamic format involving problem-solving, negotiation, andspecification
for effective requirements elicitation.

Eliciting Requirements

1. Initial Meeting Preparation:

o Attendees: Include both software engineers and stakeholders.
o Rules and Agenda: Establish guidelines for preparation and participation,
ensuring the agenda is formal enough to cover key points but informal enough to
encourage idea exchange.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Facilitator: Assign a facilitator to control the meeting.

o Definition Mechanism: Use tools such as worksheets, flip charts, wall
stickers, or electronic platforms (bulletin boards, chat rooms) to organizeand
display ideas.
2. Inception Phase:
o Conduct initial Q&A sessions to establish the scope of the problem and
overall perception of a solution.
o Develop a preliminary "product request" document summarizing the
project's aims and initial requirements.
o Distribute the product request to all attendees before the meeting.
3. Requirements Gathering Meeting:
o Before the Meeting:
 Attendees review the product request and prepare lists of
objects, services, constraints, and performance criteria.
o During the Meeting:
 Present individual lists for each topic area.
 Combine lists to eliminate redundancies and add new ideas.
 Engage in discussion to refine and achieve a consensus on the lists
of objects, services, constraints, and performance criteria.
o Post-Meeting:
 Develop mini-specifications for objects or services that need
further elaboration.
 Review and refine mini-specifications with all stakeholders, addingnew
requirements as necessary.
 Maintain an issues list for unresolved topics.

Quality Function Deployment (QFD):

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

QFD translates customer needs into technical requirements, focusing on maximizing

customer satisfaction. It distinguishes three types of requirements:

1. Normal Requirements:
o Objectives and goals explicitly stated by the customer (e.g., specific
system functions, performance levels).
2. Expected Requirements:
o Fundamental requirements implicit to the product (e.g., ease ofuse,
reliability, installation ease). Absence leads to dissatisfaction.
3. Exciting Requirements:
o Unexpected features that delight customers (e.g., innovative
capabilities like multitouch screens in smartphones).

Usage Scenarios:

Creating scenarios (or use cases) helps to understand how different user classes will use the
system. These scenarios describe the system's functions and features inpractical use,
aiding in the transition to technical software engineering activities.

Elicitation Work Products:

The outputs of requirements elicitation vary by project size but typically include:

1. Statement of Need and Feasibility: Clarifies the necessity and practicality ofthe
project.
2. Bounded Statement of Scope: Defines the system or product's boundaries.
3. List of Participants: Documents the customers, users, and stakeholders involved.
4. Technical Environment Description: Details the system’s operational context.
5. Requirements List: Organized by function, with domain constraints foreach
requirement.
6. Usage Scenarios: Provide insights into system use under different conditions.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

7. Prototypes: Developed as needed to better define requirements.

Each work product is reviewed by all participants to ensure accuracy and completeness.

Developing use cases

Writing Effective Use

Cases

Alistair Cockburn defines a use case as a description of the system's behavior as it responds
to requests from its stakeholders, capturing a contract between the stakeholders and the
system. A use case typically tells a story about how an end userinteracts with the system
under specific circumstances.

1. Actors:
o Definition: Actors are entities that interact with the system,
playing specific roles. These can be people or devices.
o Primary Actors: Directly interact with the system to achieve a goal.
o Secondary Actors: Support the system so that primary actors can
perform their roles.
o Example: For a home security system, actors might includethe
homeowner, setup manager, sensors, and monitoring subsystem.
2. Identifying Actors:
o Not all actors are identified in the first iteration; primary actors are
identified early, and secondary actors are added as understanding ofthe
system evolves.
3. Developing Use Cases:
o Questions to Answer:
 Who are the primary and secondary actors?
 What are the actors’ goals?
 What preconditions should exist?
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

 What tasks or functions do the actors perform?

 What exceptions might occur?
 What variations in interactions are possible?
 What information does the actor acquire, produce, or change?
 How does the actor inform the system about changes?
 What information does the actor desire from the system?
Does the actor need to be informed about unexpected changes?
4. Example Use Case: SafeHome

System Actors:

Homeowner
Setup Manager
Sensors
Monitoring Subsystem

Homeowner Interactions:

Entering a password
Inquiring about the status of security zones and sensors
Pressing the panic button

Homeowner checks"stay"
Homeowner selects if theorsystem
"away"istoready viathe
activate thesystem.
control panel.
The

Homeowner
system enters
confirms a four-digit
activation with a password.
visual indicator.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Detailed Use Case: Initiate Monitoring

o Primary Actor: Homeowner

o Goal in Context: To set the system to monitor sensors.
o Preconditions: System programmed with a password and
sensor recognition.
o Trigger: Homeowner decides to activate the system.
o Scenario:
1. Homeowner observes the control panel.
2. Homeowner enters the password.
3. Homeowner selects "stay" or "away".
4. Homeowner sees the alarm light indicating the system is armed.
o Exceptions:
0. System not ready: Homeowner checks and closes all sensors.
1. Incorrect password: Homeowner re-enters the correct password.
2. Password not recognized: Contact support to reprogram.
3. "Stay" selected: Perimeter sensors activated.
4. "Away" selected: All sensors activated.
o Priority: Essential
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o When Available: First increment

o Frequency of Use: Regular
o Channels to Actor: Via control panel
o Secondary Actors: Support technician, sensors
o Channels to Secondary Actors: Phone line, radio frequency interfaces

Open Issues:

Additional text messages on the control panel

Time limit for entering the password
Deactivation options before activation

Use cases should be reviewed meticulously to ensure clarity and completeness.

Ambiguities in the use case can indicate potential problems that need addressing.

Building the requirements

model The Intent of theAnalysis

Model
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

The analysis model is designed to provide a comprehensive description of the informational,

functional, and behavioral domains required for a computer-based system. It evolves as
more is learned about the system and as stakeholders refine theirunderstanding of their
needs, serving as a dynamic snapshot of requirements at any given time. Elements of the
model may stabilize over time, forming a solid foundation for subsequent design tasks,
while others may remain volatile, reflecting areas where stakeholder understanding is still
evolving.

Elements of the Requirements Model

There are various ways to represent requirements for a computer-based system, and different
modes of representation can provide different perspectives, helping to uncoveromissions,
inconsistencies, and ambiguities. Here are some common elements in most requirements
models:

Scenario-Based Elements

Scenario-based elements describe the system from the user's point of view, often
starting with basic use cases and evolving into more elaborate template-based usecases.
These scenarios serve as input for creating other modeling elements.

Class-Based Elements

Each usage scenario implies a set of objects manipulated by the actor interacting withthe
system. These objects are categorized into classes, collections of things with similar
attributes and behaviors. Class diagrams, such as a UML class diagram, depictthese classes
and their relationships, showing attributes and operations that can modify these attributes.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Behavioral Elements
The behavior of a system is critical to its design and implementation. Behavioral modeling
elements, such as state diagrams, depict the system's states and the events that cause state
changes. These diagrams also indicate actions taken as a consequence of specific events.
Behavioural modelling extends to individual classes, detailing their specific behaviours.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Flow-Oriented Elements

Flow-oriented elements model the transformation of information as it moves through the

system. This involves depicting the input, the transformations applied to it, and theoutput
produced. Flow models can be created for any computer-based system, regardless of size or
complexity.

Analysis Patterns

Analysis patterns are reusable solutions for common problems within a specificapplication
domain. These patterns provide two main benefits:

1. Speeding up Development: They help develop abstract analysis models that

capture the main requirements of a problem by providing reusable models with
examples and descriptions of their advantages and limitations.
2. Facilitating Transformation: They aid in transforming the analysis modelinto a
design model by suggesting design patterns and reliable solutions for common
problems.

Analysis patterns are referenced by name within the analysis model and stored in a
repository, making them accessible for reuse by requirements engineers. Information
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

about an analysis pattern is presented in a standard template, further discussed in detailin

subsequent chapters.

Example: SafeHome System

Actors and Interactions

For the SafeHome system, consider the homeowner actor. The interactions include:

 Entering a password
 Inquiring about the status of security zones and sensors
 Pressing the panic button
 Activating/deactivating the system

Basic Use Case: System Activation

1. Homeowner observes the control panel to ensure the system is ready.

2. Homeowner enters a four-digit password.
3. Homeowner selects "stay" or "away" to activate the system.
4. Homeowner observes a red alarm light indicating system activation.

Detailed Use Case: Initiate Monitoring

 Primary Actor: Homeowner

 Goal in Context: Set the system to monitor sensors.
 Preconditions: System programmed with a password and sensor recognition.
 Trigger: Homeowner decides to activate the system.
 Scenario:
1. Homeowner observes the control panel.
2. Homeowner enters the password.
3. Homeowner selects "stay" or "away".
4. Homeowner sees the alarm light indicating the system is armed.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

 Exceptions:
1. System not ready: Homeowner checks and closes all sensors.
2. Incorrect password: Homeowner re-enters the correct password.
3. Password not recognized: Contact support to reprogram.
4. "Stay" selected: Perimeter sensors activated.
5. "Away" selected: All sensors activated.
 Priority: Essential
 When Available: First increment
 Frequency of Use: Regular
 Channels to Actor: Via control panel
 Secondary Actors: Support technician, sensors
 Channels to Secondary Actors: Phone line, radio frequency interfaces
 Open Issues:
o Alternate activation methods (e.g., abbreviated password)
o Additional text messages on the control panel
o Time limit for entering the password
o Deactivation options before activation

Use cases and other elements should be reviewed thoroughly to ensure clarity and completeness, as
ambiguities can indicate potential problems that need addressing.

Negotiating Requirements

Negotiation in Requirements Engineering

In an ideal scenario, the tasks of inception, elicitation, and elaboration determine customer
requirements in sufficient detail to proceed seamlessly to subsequent software engineering
activities. However, this ideal is rarely achieved. In reality, negotiation with stakeholders
often becomes necessary to balance functionality, performance, and other product or system
characteristics against constraints like costand time-to-market.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Negotiation Goals and Approach

The primary goal of negotiation is to develop a project plan that meets stakeholder needs while
accommodating real-world constraints (e.g., time, budget, and personnel). The best
negotiations aim for a "win-win" outcome, where:

 Stakeholders win by getting a system or product that satisfies the

majority of their needs.
 The software team wins by working within realistic and achievable budgetsand
deadlines.

Negotiation Activities

Barry Boehm defines a set of negotiation activities to be conducted at the beginning ofeach
software process iteration. These activities are designed to ensure effective stakeholder
communication and to reconcile differing priorities and constraints. The activities include:

1. Identification of Key Stakeholders:

o Identify individuals or groups who have a vested interest in the
system or subsystem being developed.
o Stakeholders typically include end-users, customers, project
sponsors, developers, and possibly regulatory bodies.
2. Determination of Stakeholders' "Win Conditions":
o Understand the specific needs, desires, and success criteria foreach
stakeholder.
o Win conditions may include specific functional requirements,
performance targets, budget limits, or deadlines.
3. Negotiation of Win Conditions:
o Reconcile the various win conditions to develop a set of
mutually acceptable goals.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Aim to create a scenario where all stakeholders feel their primary needsare
addressed.
o Ensure the negotiated plan is feasible within the given constraints.

Achieving a Win-Win Result

Successful completion of these initial negotiation steps results in a win-win outcome,which

serves as the key criterion for moving forward with subsequent software engineering
activities. Achieving a win-win result involves:

 Clear Communication: Ensure all stakeholders understand each other's

priorities and constraints.
 Compromise and Flexibility: Be prepared to adjust expectations and find
middle ground.
 Focus on Shared Goals: Emphasize the common objectives and benefits toall
parties.

Practical Example: SafeHome System

For instance, in the development of the SafeHome system:

1. Identification of Stakeholders:
o Homeowners (end-users)
o Setup managers (users with administrative roles)
o Monitoring and response subsystem operators
o Development team
o Budget managers
2. Determination of Win Conditions:
o Homeowners: Reliable security system with easy-to-use interface.
o Setup managers: Flexible configuration options.
o Monitoring subsystem: Seamless integration with existing systems.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Development team: Clear requirements and achievable deadlines.

o Budget managers: Cost-effective solution within budget.
3. Negotiation of Win Conditions:
o Homeowners may need to compromise on advanced features for a
simpler interface.
o Setup managers may agree to phased implementation of
configuration options.
o The development team may negotiate for extended deadlines for
critical features.
o Budget managers may adjust the budget for essential features, withcost-
saving measures for others.

By addressing these negotiation activities, the project can move forward with a shared
understanding and commitment to the project's success.

Validating Requirements

Reviewing requirements is a critical step to ensure the requirements model accuratelyreflects

stakeholder needs and provides a solid foundation for design. Here are the keyquestions to
consider during a requirements review:

1. Consistency with Objectives:

o Is each requirement consistent with the overall objectives for the
system or product?
2. Proper Level of Abstraction:
o Have all requirements been specified at the proper level of abstraction?
o Do some requirements provide a level of technical detailthat
is inappropriate at this stage?
3. Necessity:
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Is the requirement really necessary, or does it represent an add-on

feature that may not be essential to the system's objective?
4. Bounded and Unambiguous:
o Is each requirement bounded and unambiguous?
5. Attribution:
o Does each requirement have attribution?
o Is a source (generally a specific individual) noted for each requirement?
6. Conflict Checking:
o Do any requirements conflict with other requirements?
7. Achievability:
o Is each requirement achievable in the technical environment that willhouse
the system or product?
8. Testability:
o Is each requirement testable once implemented?
9. Reflection of Information, Function, and Behavior:
o Does the requirements model properly reflect the information, function,and
behavior of the system to be built?
10. Partitioning:
o Has the requirements model been “partitioned” in a way that
exposes progressively more detailed information about the
system?
11. Use of Requirements Patterns:
o Have requirements patterns been used to simplify the requirements model?
o Have all patterns been properly validated?
o Are all patterns consistent with customer requirements?

Additional Considerations

 Prioritization and Grouping:

o Have the requirements been prioritized by stakeholders?
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Are the requirements grouped within requirements packages that willbe

implemented as software increments?

By asking these questions, stakeholders and development teams can ensure that the requirements
model is comprehensive, clear, and aligned with the project's goals. This process helps in identifying
potential issues early, thereby reducing the risk of costly changes later in the development process.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Chapter:-2

Requirements Modeling Scenarios, Information and Analysis classes

Requirements Analysis

1. Purpose and Outcome:

o Specifies software’s operational characteristics.
o Indicates software’s interface with other system elements.
o Establishes constraints that software must meet.
2. Tasks Involved:
o Elaborates on basic requirements from inception, elicitation,and
negotiation phases of requirements engineering.

Requirements Modeling Types

1. Scenario-Based Models:
o Focus on requirements from the perspective of various system actors.
2. Data Models:
o Depict the information domain for the problem.
3. Class-Oriented Models:
o Represent object-oriented classes (attributes and operations) andtheir
collaboration to achieve system requirements.
4. Flow-Oriented Models:
o Represent the functional elements of the system and data transformation.
5. Behavioral Models:
o Depict software behavior in response to external events.
BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Focus on 'What', Not 'How':

Identify what user interactions occur.
Determine what objects the system manipulates.
Define what functions the system must perform.
Describe what behaviors the system exhibits.
Specify what interfaces are defined.
Establish what constraints apply.
Iterative Approach:
Complete specification of requirements may not be possible initially.
Customers may be unsure of precise requirements for certain system
aspects.
Developers may be uncertain if specific approaches will meet function &
performance needs.
Model what is known and use it as the basis for designing the
software incrementally.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

3. Primary Objectives of the Requirements Model:

o Describe Customer Requirements:

 Clearly articulate what the customer needs from the system.

o Establish Basis for Software Design:

 Provide essential information that guides the creation of the

software design.
o Define Validatable Requirements:
 Outline requirements that can be validated once the software is built.
4. Bridging Analysis and Design:
o The analysis model connects the overall system or business functionality
(achieved through software, hardware, data, human, andother elements) to
a detailed software design.
o The design includes the software’s application architecture, user
interface, and component-level structure.

By adhering to these principles, requirements modeling ensures a thorough understanding of

the system requirements, facilitating effective and efficient software design and
development.

Analysis Rules of Thumb (Arlow and Neustadt)

1. Focus on Visible Requirements:

o Keep the level of abstraction high, avoid unnecessary details.
2. Add to an overall Understanding:
o Each model element should enhance understanding of the requirements.
3. Delay Nonfunctional Considerations:
o Focus on problem domain analysis before addressing infrastructure needs.
4. Minimize Coupling:
o Represent relationships but strive to reduce high
levels of interconnectedness.
5. Provide Stakeholder Value:
o Ensure the model is useful to all stakeholders involved.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

6. Simplicity:
o Keep models simple and avoid unnecessary complexity.
Domain Analysis

1. Purpose and Importance:

o Recognition of Recurrent Patterns:
 Identify and categorize analysis patterns that often reoccur
across applications within a specific business domain.
o Expedited Model Creation:
 Recognizing and applying these patterns expedites the
creation of the analysis model.
o Improved Time-to-Market and Reduced Costs:
 Increases the likelihood of using design patterns and executable
software components, leading to faster development and lower costs.
2. Domain Analysis Definition (Firesmith):
o Software Domain Analysis:
 Identification, analysis, and specification of common
requirements within a specific application domain for reuse
across multiple projects.
o Object-Oriented Domain Analysis:
 Focuses on identifying, analyzing, and specifying common, reusable
capabilities in terms of common objects, classes, subassemblies, and
frameworks.
3. Application Domains:
o Examples include avionics, banking, multimedia video games, and software for
medical devices.
o The goal is to find or create broadly applicable analysis classes and patterns for
reuse.
4. Ongoing Activity:
o Domain analysis is a continuous software engineering activity, not tied to a
specific project.

o Role of Domain Analyst:

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

 Similar to a master toolsmith who designs and builds reusable tools.

 Discover and define reusable analysis patterns and classesfor
multiple applications.
5. Inputs and Outputs of Domain Analysis:
Sources of Domain Knowledge:
Surveyed to identify objects that can be reused across the domain.
Outputs:
Analysis patterns, analysis classes, and related reusable information.

By conducting domain analysis, software engineers can leverage common patterns

and classes across multiple projects, enhancing efficiency and fostering consistency
in software development.

Structured Analysis:
o Data Object Modeling:
Data and Process Separation:
 Defines attributes and relationships of data objects.
Treats data and the processes that transform it as separate entities.
o Process Modeling:
 Shows how processes manipulate data as it flows through the system.

2. Object-Oriented Analysis (OOA):

o Class Definition and Collaboration:

 Focuses on defining classes and how they collaborate to meet

customer requirements.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Use of UML and Unified Process:

 Predominantly uses object-oriented approaches such as

Unified Modeling Language (UML) and the Unified
Process.

3. Combining Approaches:

o The book proposes a model that combines features of both structuredand

object-oriented analysis.

o Choosing an Approach:

 Software teams may choose one approach and exclude

representations from the other.

 The choice depends on which combination provides stakeholderswith

the best model and the most effective bridge to software design.

4. Elements of the Requirements Model:

o Scenario-Based Elements:

 Depict user interactions with the system and the sequence of activities.

o Class-Based Elements:
 Model objects the system will manipulate, the operations onthese
objects, relationships (including hierarchical), and
collaborations between classes.

o Behavioral Elements:

 Show how external events change the system or class states.

o Flow-Oriented Elements:

 Represent the system as an information transform, showingdata

transformation as it flows through system functions.

5. Derivation and Specific Content:

o Analysis modeling leads to the derivation of these modeling elements.

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Project-Specific Content:

 The specific content and diagrams used to construct these elementsmay

vary from project to project.

o Simplicity Principle:

 Only those modeling elements that add value to the model shouldbe
used to keep the modeling process simple.

By understanding and effectively combining these approaches, software teams cancreate

comprehensive and useful models that accurately represent system requirements and
provide a solid foundation for design.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Importance of User Satisfaction in Requirements Modeling

User Satisfaction:
User satisfaction is the primary measure of a computer-based
system or product's success.
Understanding end user interactions helps in characterizing
requirements and building effective models.

Begins with creating use cases, activity diagrams, and swimlane diagrams.
Use cases capture interactions between users (actors) and the system.

Creating a Preliminary Use Case

• Definition by Alistair Cockburn:

o A use case is a "contract for behavior," detailing how an actor uses a
system to achieve a goal. Captures interactions between information
producers/consumers andthe system.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Writing Use Cases

1. What to Write About:

o Derived from inception and elicitation tasks.
o Identify stakeholders, define problem scope, set operational goals,and
outline functional requirements.
2. Developing Use Cases:
o List functions or activities performed by an actor.
o Use lists of required system functions, stakeholder conversations,and
activity diagrams.
3. Example: SafeHome Surveillance System:
o Functions like selecting cameras, viewing thumbnails, controlling
cameras, recording, and accessing via the Internet.
4. Informal Narrative Use Case:
o Written in straightforward language from the actor's point of view.
o Example narrative for accessing camera surveillance via the
Internet, detailing steps and interactions.
5. Sequential Use Case:
o Represents user actions as a sequence of declarative sentences.
o Example sequence for the ACS-DCV function with step-by-step actions.

The requirements gathering team develops use cases for each of the functions noted. In general, use cases
are written first in an informal narrative fashion. If more formality is required, the same use case is
rewritten using a structured format. To illustrate, consider the function access camera surveillance via the
Internet— display camera views (ACS-DCV). The stakeholder who takes on the role of the homeowner
actor might write the following narrative:

Use case: Access camera surveillance via the Internet—display camera views (ACS-DCV)
Actor: homeowner
If I’m at a remote location, I can use any PC with appropriate browser software to log on to the
SafeHome Products website. I enter my user ID and two levels of passwords and once I’m validated, I have
access to all functionality for my installed SafeHome system. To access a specific camera view, I select
“surveillance” from the major function buttons displayed. I then select “pick a camera” and the floor plan
of the house is displayed. I then select the camera that I’m interested in. Alternatively, I can look at
thumbnail snapshots from all cameras simultaneously by selecting “all cameras” as my viewing choice.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Once I choose a camera, I select “view” and a one-frame-per-second view appears in a viewing window
that is identified by the camera ID. If I want to switch cameras, I select “pick a camera” and
the original viewing window disappears and the floor plan of the house is displayed again.
I then select the camera that I’m interested in. A new viewing window appears.

A variation of a narrative use case presents the interaction as an ordered sequence of user actions. Each
action is represented as a declarative sentence. Revisiting the ACS-DCV function, you would write:

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.

Use cases of this type are sometimes referred to as primary scenarios.

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Refining a Preliminary Use Case

 Secondary Scenarios:
o Evaluate each primary scenario step for alternative actions, error conditions, and other
behaviors.
o Create secondary scenarios for alternative interactions and error conditions.
 Example of Refinement:
o Identify secondary scenarios like viewing all camera thumbnails or handling error
conditions

Writing a Formal Use Case

Formal Use Case Structure:

Goal in Context: Defines the overall scope.
Precondition: What is true before the use case starts.
Trigger: Event or condition that starts the use case.
Scenario: Specific actions by the actor and system responses.

Use-case diagrams in UML can help visualize complex scenarios.

Example: Preliminary use-case diagram for SafeHome, showing
various use cases.
BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Limitations and Benefits of Use Cases

 Limitations:
o Quality depends on the author's clarity.
o Focuses on functional and behavioral requirements, not suitablefor
nonfunctional requirements.
o May not be sufficient for detailed and precise requirements,
especially in safety-critical systems.
 Benefits:
o Scenario-based modeling is appropriate for most situations
encountered in software engineering.
o Properly developed use cases provide substantial benefits as a
modeling tool.

UML models that supplement the Use Case

Enhancing Requirements Modeling with UML Graphical Models Developing

an Activity Diagram

 Purpose: Provides a graphical representation of interaction flow within a

scenario, supplementing text-based models like use cases.
 Components:
o Rounded Rectangles: Represent specific system functions.
o Arrows: Indicate the flow through the system.
o Decision Diamonds: Depict branching decisions with labeled arrows.
o Solid Horizontal Lines: Indicate parallel activities.
 Example: An activity diagram for the ACS-DCV use case (Figure 6.5) shows
details like the limited number of attempts a user has to enter their user ID and
password.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Purpose: The UML swimlane diagram is a variation of the activity diagram designed

to represent the flow of activities within a use case while highlighting the responsibilities of
different actors or analysis classes. This is achieved by dividing thediagram into parallel
segments, resembling the lanes in a swimming pool.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Structure:

 Parallel Segments (Lanes): Each lane represents a different actor or

analysis class responsible for certain actions within the use case.
 Activity Rectangles: Placed within the lanes, these rectangles depict
specific actions or system functions.
 Arrows: Indicate the flow of activities and the sequence of operations.
 Decision Diamonds: Used to show branching decisions, with arrows
leading to different paths based on conditions.

Example:

 Analysis Classes: Consider three analysis classes—Homeowner, Camera,and

Interface. Each has distinct responsibilities depicted within their respective
swimlanes.
 Interface Class: Responsible for user prompts like "prompt for reentry"and
"prompt for another view." These activities fall within the Interface swimlane.
 Homeowner Actions: Arrows from the Interface swimlane lead back to the
Homeowner swimlane, indicating the homeowner's actions following the
prompts.

Context: Swimlane diagrams, like activity diagrams and use cases, are procedurallyoriented.
They focus on how various actors invoke specific functions or follow procedural steps to
meet system requirements.

Procedural View vs. Information Space

Procedural View:

 Use Cases: Describe interactions between actors and the system.

 Activity Diagrams: Show the flow of activities within a use case.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

 Swimlane Diagrams: Illustrate responsibilities of different actors or classesalong

with the flow of activities.

Information Space:

Data Requirements: Beyond the procedural view, it's essential to represent

and understand the data requirements of the system.
Upcoming Sections: Will explore how to model the information space to
ensure comprehensive coverage of all system requirements.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Data Modeling for Requirements

Purpose: In software requirements modeling, creating a data model is crucial, especially

when there is a need to interact with a database or handle complex data structures. Data
modeling helps in defining and understanding data objects, their attributes, and their
relationships.

Entity-Relationship Diagram

(ERD) Entity-Relationship

Diagram (ERD):

 Purpose: Represents all data objects that are processed within an applicationand
illustrates the relationships between these objects.
 Components: Data objects, attributes, and relationships.

Data Objects

Definition: A data object is a composite piece of information that is processed withinthe

system. It consists of multiple attributes.

Types of Data Objects:

1. External Entity: Produces or consumes information.

2. Thing: Example, a report or a display.
3. Occurrence/Event: Example, a telephone call or an alarm.
4. Role: Example, salesperson.
5. Organizational Unit: Example, accounting department.
6. Place: Example, a warehouse.
7. Structure: Example, a file.

Example: A car can be a data object defined by attributes such as make, model, IDnumber,
body type, color, and owner.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Table Representation: Data objects can be represented in a tabular form where:

 Headings: Represent attributes of the data object.

 Body: Represents specific instances of the data object.

Data Attributes

Definition: Properties that define a data object. Attributes can:

1. Name an instance of the data object.

2. Describe the instance.
3. Reference another instance in another table.

Identifier: One or more attributes that serve as keys to uniquely identify an instanceof the
data object. For example, the ID number for a car.

Example: For a department of motor vehicles, attributes for the data object car might
include make, model, ID number, body type, color, and owner. For a manufacturing control
software, additional attributes like interior code, drive train type, trim packagedesignator,
and transmission type might be needed.

Relationships

Definition: Connections between data objects that define how they interact or relateto one
another.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Example Relationships Between Person and Car:

 Owns: A person owns a car.

 Insured to Drive: A person is insured to drive a car.

Simple Connection: Shows basic relationship (e.g., person and car

are connected).
Object/Relationship Pairs: Defines specific relationships (e.g., owns,
insured to drive).
Directionality: Arrows indicate the direction of the relationship, which
helps in reducing ambiguity.

Class-Based Modeling

1. Definition and Purpose:

o Class-based modeling represents the objects the system

manipulates, operations on those objects, relationships between

objects, and collaborations among classes.

BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o It includes elements such as classes, objects, attributes, operations, CRC

(Class-Responsibility-Collaborator) models, collaboration diagrams, and
packages.

2. Identifying Analysis Classes:

o Start with usage scenarios from the requirements model.

o Perform a grammatical parse on use cases to identify nouns or noun

phrases as potential classes.

o Synonyms should be noted, and classes needed for the solution are part of
the solution space; those needed only for description are in theproblem
space.

3. Categories of Analysis Classes:

o External entities: Other systems, devices, people.

o Things: Reports, displays, letters, signals.

o Occurrences/Events: Property transfers, completion of robot movements.

o Roles: Manager, engineer, salesperson.

o Organizational units: Division, group, team.

o Places: Manufacturing floor, loading dock.

o Structures: Sensors, vehicles, computers.

4. Examples and Non-Examples of Classes:

o Classes should not have imperative procedural names.

o Example: An image is a class; image inversion is an operation on the

image class, not a separate class.
BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

5. Applying Selection Characteristics (Coad and Yourdon's guidelines):

o Retained information: Must retain information for system functionality.

o Needed services: Must have identifiable operations that can changeits

attributes.

o Multiple attributes: Should have multiple significant attributes.

o Common attributes: Attributes apply to all instances.

o Common operations: Operations apply to all instances.

o Essential requirements: Produce or consume essential information forthe

system.

6. Example of Analysis for SafeHome Security Function:

o Grammatical parsing of a narrative identifies potential classes.

o Example classes: Homeowner, sensor, control panel, installation, system,

number, type, master password, telephone number, sensor event, audible
alarm, monitoring service.

7. Selection and Evaluation of Classes:

o Apply selection characteristics to potential classes.

o Example evaluation:

 Accepted: Sensor, control panel, system, sensor event,

audible alarm.

 Rejected: Homeowner, installation, number, type, master

password, telephone number, monitoring service.

8. Notes:
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o The list of classes is not exhaustive; additional classes may be needed.

o Rejected classes may become attributes of accepted classes.

o Different problem statements may lead to different decisions

regarding class acceptance or rejection.

Specifying Attributes in Class-Based Modeling

1. Purpose of Attributes:
o Attributes define a class and clarify its meaning in the problem space.
o The relevance of attributes depends on the context in which theclass
is used.
2. Context-Specific Attributes:
o Attributes for the same class can vary significantly based on the
context of the system.
o Example:
 For a baseball statistics system: name, position, batting
average, fielding percentage, years played, games played.
 For a baseball pension system: average salary, credit towardfull
vesting, pension plan options chosen, mailing address.
3. Developing Attributes:
o Study each use case to identify relevant attributes that belong to the class.
o Answer the question: "What data items (composite and/or elementary) fully
define this class in the context of the problem at hand?"
4. Example: SafeHome System Class Attributes:
o Identification Information:
 System ID
 Verification phone number
 System status
o Alarm Response Information:
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

 Delay time
 Telephone number
o Activation/Deactivation Information:
 Master password
 Number of allowable tries
 Temporary password
5. Composite Data Items:
o Each composite data item can be further broken down into elementarydata
items if needed.
o For practical purposes, composite data items provide a reasonablelist of
attributes.
6. Class vs. Attribute:
o Avoid defining an item as an attribute if multiple instances of the itemare
associated with the class.
o Example: Sensors are not attributes of the System class but are definedas a
separate Sensor class associated with the System class.

Defining Operations in Class-Based Modeling

1. Purpose of Operations:
o Operations define the behavior of an object.
o They manipulate data, perform computations, inquire about object
states, or monitor for events.
2. Categories of Operations:
o Data manipulation: Adding, deleting, reformatting, selecting data.
o Computation: Performing calculations or processing data.
o State inquiry: Checking or retrieving the state of an object.
o Event monitoring: Watching for specific events to occur.
3. Relationship with Attributes and Associations:
BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Operations work with the class's attributes and associations.

o They require knowledge of these elements to function correctly.
4. Deriving Operations from Use Cases:
o Study processing narratives or use cases to identify relevant operations.
o Use grammatical parsing to isolate verbs, which often indicate operations.
5. Example: SafeHome System Operations:
o From the narrative:
 "Sensor is assigned a number and type" suggests an assign()
operation for the Sensor class.
 "A master password is programmed for arming and disarmingthe
system" suggests a program () operation for the System class.
 arm() and disarm() operations for the System class.
6. Refining Operations:
o Initial operations might be high-level and can be broken down intomore
specific suboperations.
o Example: program() might include suboperations like specifying
phone numbers, configuring system characteristics, and entering
passwords.
7. Communication Between Objects:
o Objects interact by passing messages to each other.
o Understanding this communication helps identify additional operations.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

By following these guidelines, operations for each class can be effectively identified
and defined, ensuring that the behavior of each object in the system is thoroughly
understood and documented.

CRC modeling is a technique used to identify and organize classes relevant to system
or product requirements. This model is typically represented using index cards, each
card detailing a class, its responsibilities, and its collaborators.

Each CRC card is divided into three sections:

Class Name: The name of the class.

Responsibilities: Attributes and operations that define what the class
knows or does.
BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

3. Collaborators: Other classes that provide necessary information or actions forthe

class to fulfill its responsibilities.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Identifying Classes

Classes can be categorized into:

1. Entity Classes: Represent entities derived from the problem statement,e.g.,

FloorPlan, Sensor.
2. Boundary Classes: Interface elements the user interacts with,e.g.,
CameraWindow.
BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

3. Controller Classes: Manage operations from start to finish, e.g., creation or

update of entity objects, complex communication, validationof data.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Identifying Responsibilities

Responsibilities are anything a class knows or does, including both attributes andoperations.
The following guidelines help in allocating responsibilities:

1. Distribute System Intelligence: Ensure intelligence is evenly distributedacross

classes to improve cohesiveness and maintainability.
2. General Responsibilities: State responsibilities generally to allow for high-level
abstraction and reuse.
3. Encapsulation: Keep information and behavior related to it within the same class.
4. Localize Information: Information about one thing should reside within asingle
class.
5. Share Responsibilities When Appropriate: Related classes shouldshare
responsibilities when they need to exhibit the same behavior.

Identifying Collaborations

Collaborations represent requests from one class (client) to another (server) to fulfill a
responsibility. These collaborations are necessary when a class cannot fulfill a responsibility
on its own.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Three types of relationships help identify collaborators:

1. Is-Part-Of: Aggregate relationships where one class is part of another,e.g.,

PlayerBody is part of Player.
2. Has-Knowledge-Of: One class acquires information from another,
e.g., ControlPanel determining sensor status from Sensor.
3. Depends-Upon: Classes dependent on each other without direct
knowledge, facilitated by a third class.

The CRC model is reviewed through a collaborative process:

Distribute CRC Cards: Participants receive a subset of CRC cards, ensuring

no one has collaborating cards.

3. Read Use Case: The review leader reads the use case, passing a token tothe
holder of the corresponding class card.
4. Describe Responsibilities: The cardholder describes the responsibilities,
verifying if they satisfy the use-case requirement.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

5. Modify Cards: If necessary, define new classes or modify responsibilitiesand

collaborations on existing cards.

This process ensures the model accurately represents the requirements and guides furtherdevelopment.

Associations and Dependencies

In UML (Unified Modeling Language), associations and dependencies representrelationships

between classes.

Associations

Definition: Associations are relationships between two or more classes. These

relationships often signify how objects of one class interact or are connected toobjects
of another class.

Example: In the context of a floor plan system, a FloorPlan class may be associated with
Camera and Wall classes. Similarly, a Wall class might be associated with WallSegment,
Window, and Door classes.

Multiplicity: Associations can have multiplicity, which defines how many instancesof one
class are associated with instances of another class.

Multiplicity Notation:

 1..* indicates one or more instances.

 0..* indicates zero or more instances.

Example of Multiplicity:

 A Wall object can be constructed from one or more WallSegment objects (1..*).
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

 A Wall object may contain zero or more Window objects (0..*) and zero ormore
Door objects (0..*).

The relationships and multiplicities can be illustrated in UML diagrams, as shown below:

Definition: Dependencies represent a client-server relationship where one class (theclient)

depends on another class (the server) for some functionality or service. A dependency
Dependencies
indicates that a change in the server class may affect the client class.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Stereotypes: Dependencies are often defined using stereotypes, which are special modeling
elements with custom-defined semantics. In UML, stereotypes are enclosedin double angle
brackets (e.g., <<stereotype>>).

Example: In the SafeHome surveillance system, a Camera object (server class) provides
video images to a Display Window object (client class). This relationship is more complex
than a simple association and can be represented as a dependency.

Example of Dependency:

 The Display Window depends on the Camera for video images.

Additionally, access to specific camera views may be controlled by a
special password.

This can be represented as shown in Figure 6.14: DisplayWindow <<access>> Camera

In this diagram, <<access>> implies that the use of the camera output by the
DisplayWindow is controlled by a special password.

Associations: Represent general relationships between classes and may include

multiplicities to indicate how many instances of one class relate to instances of another.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Dependencies: Indicate that one class relies on another, often represented with
stereotypes to provide additional semantics. These relationships are crucial for
understanding the interactions and dependencies within a system.

Analysis Packages

Analysis packages are used in analysis modeling to group related elements, such as use
cases and analysis classes, into categorized units. This organization helps manage complexity
by structuring the model into coherent sections.

Example: Video Game Analysis Packages

Consider a video game analysis model, which consists of numerous classes. These classes
can be categorized into different analysis packages based on their roles and functionalities
within the game.

Categories of Classes:

1. Game Environment:
o Classes that describe the visual scenes and environment elements theuser
sees during gameplay.
o Examples: Tree, Landscape, Road, Wall, Bridge, Building, VisualEffect.
2. Game Characters:
o Classes that define the physical features, actions, and
constraints of characters within the game.
o Examples: Player, Protagonist, Antagonist, SupportingRoles.
3. Game Rules:
o Classes that define the rules of the game, including how players
navigate the environment and interact with objects and characters.
o Examples: RulesOfMovement, ConstraintsOnAction.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Illustration:

Figure 6.15: Analysis Packages for a Video Game

Visibility Symbols

In UML, symbols are used to indicate the visibility of elements within and across
packages:

Public (+): The element is accessible from other packages.

Private (-): The element is hidden from other packages.
Protected (#): The element is accessible only to packages contained
within a given package.

In Figure 6.15, the plus sign (+) before the class names indicates that these classes
have public visibility, meaning they can be accessed from other packages. Other
symbols (minus sign - for private and hash # for protected) are not shown in this
figure but are used similarly to control the visibility of elements.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Chapter: - 3 - Requirement Modeling Strategies

Flow-Oriented Modeling

Flow-oriented modeling is a strategy for representing how data flows through a system and how
data is transformed as it moves from input to output. It emphasizes the movement of information
and the processes that manipulate it.

Flow-oriented modeling focuses on the transformation and movement of data within a system. It
typically involves tools like Data Flow Diagrams (DFDs) to represent processes, data stores,external
entities, and the flow of data between these components.

This modeling approach helps in understanding how information is processed and supports
requirement analysis by visualizing the system's functional aspects.

Some Key Points of Flow-Oriented Modeling

Data Flow Diagrams (DFDs):

o The primary tool for flow-oriented modeling.

o Represents the flow of data between processes, data stores, and external entities.
o Focuses on what the system does (i.e., the processes) rather than how it is
implemented.

Processes:

o Describes actions or functions that transform data.

o Each process receives input data, processes it, and produces output data.

Data Stores:

o Represents where data is stored temporarily or permanently within the system.

o Data can be read from or written to these stores by processes.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Data Flows:

o Shows the movement of data between processes, data stores, and external entities.
o Represents the "what" (data) that moves, not the control flow.

External Entities:

o Entities outside the system boundary that interact with the system (e.g., users, external
systems).
o They send data to or receive data from the system.

Hierarchical Decomposition:

o DFDs can be decomposed into multiple levels of detail.

o A high-level DFD provides a broad overview, while detailed DFDs represent specific
processes.

Focus on Information Flow:

o Emphasizes the flow of information and how it is processed.

o Helps in identifying key functions and data processing requirements.

System Boundaries:

o Defines the boundaries of the system being modeled, separating it from the external
environment.

Process Specifications (PSpecs):

o Each process in a DFD may have a corresponding process specification that details how
the process transforms the input into the output.
Helps in Requirement Analysis:
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT.

o Useful in identifying data requirements, data transformations, and functional

requirements early in the system design process.
o Provides a clear, visual representation of how data interacts with system functions.

Behavioral Modeling

Behavioral modeling is a technique used to describe how a system behaves in response to

external stimuli. It focuses on how the system’s components interact over time, capturing the
dynamic aspects of the system, such as how objects change state, respond to events, and
communicate with each other.

Behavioral modeling is typically employed during requirement analysis and system design to depict
the system's response to events.

Behavioral modeling highlights the dynamic nature of a system by modeling its responses tointernal
and external events.

Tools like State Diagrams, Sequence Diagrams, and Activity Diagrams are commonly used to
represent how the system or its components behave in different scenarios over time.

This modeling approach helps capture the dynamic requirements of a system, complementing static
models like class or component diagrams.

Key Points of Behavioral Modeling

State Diagrams (State Machines):

o Represents the states an object can be in and how it transitions from one state to anotherbased
on events.
o Shows the life cycle of an object or a component by defining states, events, transitions,and
actions.
o Useful for systems with significant event-driven behaviors (e.g., controllers, devices).
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT.

Events and States:

o Events: External stimuli or occurrences that trigger state transitions (e.g., user input,sensor
data).
o States: Conditions or situations in which an object can exist.
o Transitions: The movement from one state to another when an event occurs.

Sequence Diagrams:

o Represents the interaction between objects over time.

o Illustrates the sequence of messages exchanged between objects to achieve a particular
functionality.
o Helps model use cases and interactions between system components.

Activity Diagrams:

o Focuses on the flow of activities within a system, showing the sequence and conditionsunder
which activities occur.
o Useful for modeling workflows or complex algorithms.
o Captures the flow of control and data between actions or activities.

Use Case Diagrams:

o Describes how external actors (users or other systems) interact with the system.
o Focuses on user interactions and helps capture functional requirements.
o Represents various use cases the system must handle and the actors involved in each usecase.

Collaboration Diagrams (Communication Diagrams):

o Similar to sequence diagrams but focuses more on the relationships between objectsrather
than the time sequence of messages.
o Shows how objects work together to perform a function.
 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT.

Interaction Diagrams:

o Models the dynamic behavior between objects and their interactions to achieve a
specific outcome.
o Focuses on how objects collaborate through message passing and communication.

Behavioral Modeling in UML:

o Unified Modeling Language (UML) is a common language for representing behavioral

models.
o UML provides diagrams such as state diagrams, sequence diagrams, and activity
diagrams for this purpose.

Dynamic Nature of the System:

o Behavioral modeling captures the system's dynamic response to inputs, user actions, and
internal conditions.
o It reveals how the system behaves over time and under various conditions.

Complements Static Models:

o Behavioral modeling works alongside static modeling (e.g., class diagrams) to provide a
complete view of the system.
o While static models describe structure, behavioral models describe behavior and
interactions.

Applications:

 Useful in real-time systems, event-driven systems, and systems with complex

workflows.
 Helps in identifying dynamic requirements such as timing constraints, event handling, and
state transitions.