Software Engineering

BCSE301L

MODULE 3

Software Requirements & System Modelling

Dr. Naveenkumar Jayakumar

Dept. of Computational Intelligence

PRP-217-4
 Chapter 1: Software Requirements

What are Software Requirements?

Software requirements are the descriptions of the services that a software system should provide and
the constraints under which it must operate. They essentially define what the software should do to
meet the needs of its users and stakeholders.

➢ Descriptions of services a system should provide.

➢ Constraints on system operation.
➢ Reflect customer needs (e.g., controlling a device, placing an order).

What the Software Should Do

This encompasses the functionalities and features expected from the system. Examples include:

• Processing user inputs

• Storing and retrieving data
• Generating reports
• Controlling external devices

Constraints on Operation

These are limitations or restrictions on how the software should function. Examples include:

• Performance requirements (e.g., response time, throughput)

• Security requirements (e.g., data encryption, access control)
• Usability requirements (e.g., ease of use, accessibility)
• Compatibility requirements (e.g., operating system compatibility)

Types of Software Requirements

Requirement Type Description

Business Requirements The high-level goals and objectives that a software system must
achieve to support the organization's strategic business needs. They
focus on the 'why' behind the software and its impact on the
business.

Functional Requirements Describe the specific functions that the software must perform.
Non-Functional Describe the quality attributes of the software, such as performance,
Requirements usability, and security.

User Requirements Describe the needs and expectations of the end-users of the
software.

System Requirements Describe the overall requirements of the entire system, including the
software and hardware components.
 Chapter 2: Software Requirements Engineering

Overview

Requirements Engineering is a process of:

• Finding
• Analyzing
• Documenting
• Checking requirements.

Requirements Engineering Activities

Activity Purpose Techniques/Deliverables

Feasibility Study To assess the technical, economic, Market analysis, technology

and operational feasibility of the assessment, risk analysis,
proposed system. cost-benefit analysis.

Requirements To gather information about the Interviews, surveys, observation,

Elicitation needs and expectations of focus groups, workshops, prototyping.
stakeholders (users, customers,
domain experts).

Requirements To analyze the elicited information, Use case analysis, data flow
Analysis identify conflicts, and prioritize diagrams, requirement
requirements. decomposition, risk analysis.

Requirements To document the requirements in a Software Requirements Specification

Specification clear, concise, and unambiguous (SRS) document covering functional,
manner. non-functional, user, and system
requirements.

Requirements To ensure that the requirements are Reviews and inspections, prototyping,
Validation correct, complete, consistent, and testing.
feasible.

Requirements To track changes to requirements, Change control, version control,

Management manage conflicts, and ensure that traceability.
the system remains aligned with the
evolving needs of stakeholders.

Requirement Elicitation & Analysis Process

 Step Description

Requirements Discovery and Interact with stakeholders to gather information through interviews,
Understanding workshops, surveys, etc. Identify domain requirements and
constraints.

Requirements Classification Group related requirements and organize them into a coherent
and Organization structure. Use techniques like viewpoints or associate
requirements with system subsystems.

Requirements Prioritization Identify and resolve conflicts among stakeholder requirements.

and Negotiation Prioritize requirements based on importance, urgency, and
feasibility. Facilitate stakeholder meetings to reach consensus.

Requirements Document requirements clearly, concisely, and unambiguously.

Documentation Use simple language and diagrams to enhance understanding.
Utilize shared tools like wikis or cloud-based documents for easy
access and collaboration.

Elicitation Techniques & Tools

Interview
Purpose: To understand stakeholder needs and how they might use a new system.

Approaches Challenges & Tips

• Closed Interviews: Predefined set of Challenges: Stakeholder uncertainty,

questions. communication gap (jargon, implicit
knowledge), political factors.

• Open Interviews: Exploratory, with no fixed Effective Techniques: Open-mindedness,

agenda. active listening, use of prompts.

• Observation/Ethnography: Observing Limitations: May not capture all

stakeholders in their work environment. requirements or reveal organizational
constraints.

Ethnography
An observational technique that involves immersing oneself in the work environment of stakeholders to
understand actual work practices, social interactions, and organizational context.

Benefits Limitations

• Uncovers hidden requirements and • May not effectively capture broader

workarounds. organizational or domain requirements.
 • Identifies requirements related to • May not be best for groundbreaking,
cooperation and awareness. innovative system designs.

• Informs prototype development, leading to • Time-consuming and resource-intensive to

more user-centered designs. conduct.

• Reduces the number of prototype

refinement cycles.

Requirement Specifications – What It Captures

Category Question

Functionality What is the software supposed to do?

External Interfaces How does the software interact with people, the system's hardware,
other hardware, and other software?

Performance What is the speed, availability, response time, recovery time of various
software functions?

Attributes What are the portability, correctness, maintainability, security, and

other considerations?

Design Constraints Are there any required standards in effect, implementation language,
policies for database integrity, resource limits, operating
environment(s)?

SRS Characteristics – How It Should Be

Characteristic Description

Valid (Correct) Expresses only the real needs of the stakeholders. Doesn't contain
anything that isn't required.

Unambiguous Every statement can be read in exactly one way.

Complete Specifies all the things the system must do and all the things it must not
do! Includes responses to all classes of input and no TBDs.

Understandable Understandable by non-computer specialists.

(Clear)

Consistent Doesn't contradict itself. Uses all terms consistently.

Ranked Must indicate the importance and/or stability of each requirement.

 Verifiable A process exists to test satisfaction of each requirement. Every
requirement is specified behaviorally.

Modifiable Can be changed without difficulty. Good structure and cross-referencing.

Traceable Origin of each requirement must be clear. Facilitates referencing of

requirements in future documentation.

Requirement Management in Agile – Stories & Scenarios

Stories Scenarios

Stories: High-level narratives describing Scenarios: More detailed descriptions of

how the system might be used. specific user interactions.

• Effective for setting the big picture and • Structured with inputs, outputs, normal
facilitating broad discussions. flow, error handling, and system state.

• Can gather input from a wider audience • Can be used to derive specific system
(e.g., through wikis). requirements.

Example:
• Story: A teacher uses the iLearn system to support student projects on the fishing industry.

• Scenario: A student uploads photos to the KidsTakePics system. The teacher moderates the
photos before they are shared.

Benefits of Using Stories and Scenarios:

• Improved Communication: Facilitates discussions and helps stakeholders understand the system in
a more concrete way.
• Real-World Focus: Helps ensure that the system meets the actual needs of users in real-world
situations.
• Early Identification of Issues: Allows for early identification and resolution of potential problems.
 Chapter 3: System Modelling

What is System Modelling?

➢ System modeling refers to the process of developing simplified, abstract representations of a

system's components, their interactions, and behaviors.
➢ These models serve as tools for visualizing, specifying, and validating system requirements and
design.

Purpose of System Modelling:

Purpose Description

Understanding and System models help stakeholders comprehend the structure and behavior
Analysis of the system, breaking down complexity into manageable parts.

Communication They provide a common language that facilitates discussions among

developers, clients, and other stakeholders, ensuring everyone has a
shared understanding.

Specification Models capture essential requirements and functionalities, guiding the

development process.

Validation They enable testing of the system's design against requirements to ensure
it meets stakeholder expectations.

Types of System Models

Model Type Description Techniques

Context Models Illustrate the system's environment and its UML & DFD
interactions with external entities to define system
boundaries.

Interaction Models Focus on how components within the system UML

communicate and interact with each other.

Structural Models Represent the organization of the system's UML & ERD
components and their relationships, often using
class or ER diagrams.

Behavioral Models Capture how the system behaves in response to UML

various inputs or events, using state machine or
sequence diagrams.
 Data Models Represents the structure and organization of data ERD & UML
within the system.

Modelling Techniques

• Data Flow Diagrams (DFD) – Used for Context and Data models.

• Entity-Relationship Model (ERD) – Used for Structural and Data models.

• State Diagram Models – Used for Behavioral models.

• Unified Modelling Language (UML) – Used across all model types.

 Chapter 4: Data Flow Diagram (DFD)

What is a DFD?

➢ A Data Flow Diagram (DFD) is a graphical representation that illustrates the flow of data within a
system.
➢ It serves as a powerful tool for visualizing and understanding how information is processed, stored,
and communicated.

Purpose and Benefits

• Visualization: Provides a clear and concise visual representation of how data flows through a
system.

• Identification of Bottlenecks: Helps identify potential inefficiencies or bottlenecks in data

processing.

• Documentation: Serves as documentation tools that communicate system designs to various

stakeholders.

• System Analysis: Can be used to analyze existing systems or model new ones.

DFD Components

Component Symbol Description

Processes Rounded Transform input data into output data. Each process
rectangles is labeled with a verb phrase describing its function.

Data Flows Arrows Indicate the movement of data between processes,

data stores, and external entities. Labeled with
descriptions of the data being transferred.

Data Stores Open-ended Represent locations where data is stored for later
(Warehouses) rectangles use. Data can flow into and out of these stores.

External Entities Squares or Sources or destinations of data outside the system

(Terminators) rectangles being modeled. They interact with the system by
providing inputs or receiving outputs.

Rules for Creating a DFD

• Identify the key processes and external entities involved.

• Determine the input and output data for each process.
 • Use standardized symbols to represent components clearly.
• Label all arrows with the type of data being transferred.
• Keep the diagram simple to enhance understanding and avoid complexity.

Levels of DFDs

Level Description

Context Diagram (Level 0) The highest-level DFD, showing the system as a single process with
external entities.

Level 1 DFD Decomposes the context diagram into major processes and data
flows.

Level 2 DFD Further decomposes Level 1 processes into more detailed processes
and data flows.

Level 3 DFD Decomposes Level 2 processes into even more detailed processes
and data flows.

DFD Advantages & Disadvantages

Advantages Disadvantages

• Provides a clear overview of data flow • Can become complex if too many
within a system. elements are included.

• Helps in identifying potential issues in data • May require significant time to create and
handling. maintain.

• Facilitates communication among • Might not capture dynamic aspects of

stakeholders regarding system design. system behavior effectively.

• Clarifies system boundaries and scope.

• Facilitates communication via a common

framework.

DFD Example – Lemonade System

The Lemonade System involves the following processes:

➢ Customer Orders: A customer places an order for lemonade.

➢ Make Lemonade: The lemonade stand owner makes the lemonade according to the customer's
request.
➢ Payment: The customer pays for the lemonade.
 ➢ Serve Lemonade: The lemonade stand owner serves the lemonade to the customer.

Level 1 DFD Processes:

• Customer Order

• Serve Product

• Collect Payment

• Produce Product

• Store Product

• Order Raw Materials

• Pay for Raw Materials

• Pay for Labor

 Chapter 5: Entity-Relationship (ER) Model

What is an ER Model?

➢ Represents the logical design of a database by abstracting real-world objects as entities and their
associations as relationships.
➢ Example: Entities 'Student' and 'School' with the relationship 'Studies in'.

Core Concepts

Concept Description

Entity Set A collection of similar entities (e.g., 'Student' entity set). Individual
instances are entities (e.g., 'Ram').

Relationship Set A collection of similar relationships between entities.

Attributes Characteristics describing an entity (e.g., Student attributes: name, age,

address, roll number, grade).

Super Key One or more attributes that uniquely identify an entity (e.g., grade + roll
number in a school).

Candidate Key A minimal subset of a super key (super key without extraneous attributes).

Primary Key A chosen candidate key for database implementation.

Prime Attribute Any attribute part of a super key.

Weak Entity An entity dependent on another entity for its identification (doesn't have its
own super key). Example: 'Family' (weak entity) dependent on 'Employee'
(owning entity).

Entity Generalization/Specialization

Represents hierarchical relationships between entity sets. A generalized entity (e.g., 'Person') can have
specialized subtypes (e.g., 'Customer,' 'Employee'). Uses 'ISA' hierarchy.

Mapping Cardinalities

Cardinality Description

One-to-One (1:1) One entity in E1 relates to at most one entity in E2, and vice versa.
 One-to-Many (1:N) One entity in E1 relates to zero or more entities in E2. One entity in E2
relates to at most one entity in E1.

Many-to-One (N:1) Many entities in E1 relate to one entity in E2. One entity in E2 relates to
at most one entity in E1.

Many-to-Many (M:N) Many entities in E1 relate to many entities in E2.

ER Diagram

From a given problem statement, we identify the possible entity sets, their attributes, and relationships
among different entity sets. Once we have this information, we represent them pictorially as an
Entity-Relationship (ER) diagram.
 Chapter 6: Unified Modelling Language (UML)

What is UML?

UML is a standardized modeling language used in software engineering for visualizing, specifying,
constructing, and documenting the artifacts of software systems.

Purpose Description

Visualization Provides a way to represent software systems graphically, making complex

designs easier to understand. Instead of just lines of code, developers can
use diagrams to see the structure and behavior of their software.

Specification Can be used to specify the components of a software system in a precise and
unambiguous way. Helps ensure that everyone on the development team has
a shared understanding of the system's design.

Construction While UML itself isn't code, it can be used to generate code in various
programming languages, speeding up the development process and reducing
errors.

Documentation UML diagrams serve as excellent documentation for software systems,

providing a clear and concise overview of the system's design, helpful for
maintenance and future development.

UML Perspectives & Diagram Types

Perspective Diagram Types

Structural Model (Static View) Class Diagram, Component Diagram, Deployment Diagram,
Object Diagram

Behavioral Model (Dynamic View) Sequence Diagram, Collaboration Diagram, State Chart
Diagram, Activity Diagram

User Interaction View Use Case Diagram

 Chapter 7: UML – Use Case Diagram

Overview

➢ Provide a shared understanding of system functionality among end-users, developers, and domain
experts.
➢ Capture system functionality (use cases) and users (actors) from a problem statement.
➢ Behavioral UML diagram showing a graphical overview of system functionality.
➢ Consist of use cases (actions), actors (users/external systems), and their relationships.

Key Elements

Element Description

Actor External entity (human, device, or system) interacting with the system for a
purpose. • Primary Actor: Principal user achieving goals through system
services (e.g., customer withdrawing cash). • Supporting Actor: Provides
services to the system (e.g., bank representative restocking ATM).

Use Case A specific functionality provided by the system (e.g., withdraw cash, check
balance). Includes both successful and unsuccessful interaction scenarios.

Subject The system under consideration (e.g., ATM). Use cases apply to the subject.

Association Connection between actors and use cases, showing interaction (message
passing). Actors must be associated with at least one use case, and vice
versa.

Use Case Relationships

Relationship Description Example

Include Represents shared behavior among use "Login" included by "Send

cases (like a function call). Dashed arrow Email," "Reply," and "Forward."
with «include» stereotype from including to
included use case.

Extend Represents variations or optional behaviors "Add Shipping Instructions"

of a use case. Dashed arrow with «extend» extends "Place Order."
stereotype from extending to extended use
case.
 Generalization Represents inheritance between use cases "Draw Rectangle" generalizes
(specialization). Solid arrow from specialized "Draw Polygon."
to generalized use case.

Guidelines

Actors Use Cases & Drawing

Identifying Actors: Identifying Use Cases:

• Who benefits most from the system? • Determine actor goals (functionality they
(Primary actors) want).

• Who keeps the system working? • Use case names start with a verb (e.g.,
'Check Balance').

• What other software/hardware interacts Drawing Guidelines:

with the system?

• Any interface with other systems? • Define the system boundary.

• Actors should have well-defined purposes.

• Use 'include' relationships for shared

behavior.
 Chapter 8: UML – Activity Diagram

Overview

➢ Activity diagrams are behavioral diagrams that visually represent the flow of control in a system.
➢ They are like flowcharts but can represent concurrent activities.
➢ They can't depict message passing among objects and thus can't be directly translated into code.
➢ Activity diagrams are suitable for confirming logic with business users, especially when the
business logic is complex.

Components

Component Symbol Description

Activity Rounded rectangle Represents an action or task being performed.

Initial Node Filled circle The starting point of the activity flow.

Final Node Filled circle with border The ending point of the activity flow.

Flow Directed arrow Shows the transfer of control. May include guard
conditions.

Decision Diamond shape (1 in, Branches flow based on conditions.

multiple out)

Merge Diamond shape (multiple Processing continues when at least one control
in, 1 out) reaches the node.

Fork Black bar (1 in, multiple Indicates the start of parallel activities.
out)

Join Black bar (multiple in, 1 Synchronizes concurrent activities; all incoming
out) controls must be completed.

Note Rectangle with folded Attaches textual information (comments,

corner constraints) to components.

Partition Divided sections Logically groups components into areas

(Swimlane) corresponding to organizational units or actors.

Guidelines for Drawing Activity Diagrams

• Identify tiny pieces of work being performed by the system.
• Identify the next logical activity that should be performed.
• Think about all those conditions that should be made, and all those constraints that should be
satisfied, before one can move to the next activity.
• Put non-trivial guard conditions on the edges to avoid confusion.
 Chapter 9: UML – State Chart Diagram

Overview

➢ A statechart diagram is a visual representation of a system, showing its states and the events that
cause transitions between them.
➢ It models the behavior of a system with well-defined states.
➢ Statechart diagrams are typically used to model complex systems.

Components

Component Notation Description

Initial State Filled black circle The state an object is in when created.

Final State Unfilled circle with inner A state from which the object does not move to
black-filled circle another state.

Intermediate State Rounded rectangle Any state that is not initial or final. Contains
Name, Internal transitions (Entry/Exit/Do/Include
actions).

Transition Solid arrow Movement from one state to another in

response to an external stimulus or internal
event. Labeled as: event [guard-condition] /
[action-expression].

Event Label on transition What causes the transition (written in past

(mandatory) tense).

Guard Condition Precondition in brackets Precondition(s) that must be true for the
(optional) transition to happen.

Action Expression Action after / (optional) Action(s) performed as a result of the transition.

Guidelines

• Identify the distinct states the system passes through.

• Identify the events (and preconditions) that cause state transitions.
• Identify what activities are performed while the system remains in a given state.

Example – Order Processing State Chart

• On the event of an order being received, we transition from our initial state to Unprocessed
Order state.

• The unprocessed order is then checked.

• If the order is rejected, we transition to the Rejected Order state.

• If the order is accepted and we have the items available, we transition to the Fulfilled Order
state.

• However, if the items are not available, we transition to the Pending Order state.

• After the order is fulfilled, we transition to the final state.

 Chapter 10: UML – Sequence & Class Diagrams

Sequence Diagram

A Sequence Diagram shows object interactions and message passing over time.

Element Notation Description

Object Box at the top with object An instance of a class.

name:class name
(underlined)

Lifeline Vertical dashed line Represents an object's existence over time.

Activation Box Narrow rectangle on lifeline Shows when the object is active.

Synchronous Filled arrowhead Sender waits for receiver to finish.

Message

Asynchronous Open arrowhead Sender doesn't wait for receiver.

Message

Return Message Dashed arrow with open Value returned from a message call.
arrowhead

Self-Message Arrow looping back to Object sending a message to itself.

same lifeline

Guard Condition [condition] on arrow Condition that must be true for message to be
sent.

Class Diagram

A Class Diagram is a graphical representation of a system's static structure, showing classes, their
attributes, operations, and relationships.

Class Structure:
• Class Name: Unique identifier for the class.

• Attributes: Properties of the class (data members).

• Operations: Actions the class can perform (member functions).

Relationship Notation Description

 Association Solid line between Instance-level connection allowing message
classes exchange. Can have name, role names, and
multiplicity.

Aggregation Hollow diamond on 'Part-whole' relationship where the whole contains

the whole side the parts. Weaker ownership — parts can exist
independently.

Composition Filled diamond on the Strong 'part-whole' relationship where the whole
whole side owns the parts. Part lifecycle depends on the
whole.

Generalization Hollow triangle arrow 'ISA' relationship. Derived classes inherit properties
(Inheritance) (child → parent) from parent classes.

Multiplicity Numbers on Specifies the number of instances (e.g., 1, 0..1, *,

association ends 1..*, n).

Examples:

Aggregation (Weak) Composition (Strong)

Aggregation Example: Composition Example:

• A Branch has one or more Departments. • A Shopping Mall contains Branches.

• A Department can exist independently of a • A Branch cannot exist without the

Branch. Shopping Mall.

• If a branch is closed, departments may still • If the shopping mall is demolished, all its
exist or be moved elsewhere. branches automatically cease to exist.
 Chapter 11: UML – Component & Deployment Diagrams

Component Diagram

➢ Models the physical parts of a system like files, executables, and libraries.
➢ Provides a visual representation of the components and their relationships, helping to form an
executable system.
➢ Each component is a single, replaceable unit with hidden implementation details, communicating
through interfaces.

Element Notation Description

Components Rectangles with <> Can be basic building blocks or larger

stereotype or component icon subsystems.

Interfaces Lollipop (provided) and Define how components interact with each
socket (required) notation other. Components provide and require
interfaces.

Connectors Assembly connectors Illustrate the relationships between

components. Link provided interfaces to
required interfaces.

Deployment Diagram

➢ Visualizes the physical hardware and software deployment in a system.

➢ Shows how software components are deployed on hardware.
➢ Depicts the relationships between software and hardware components.

Element Notation Description

Device Nodes 3D box (cube shape) Hardware devices (e.g., servers, PCs, mobile
phones) or software execution environments
(e.g., operating systems, JVMs). Most important
part of the diagram.

Execution Nested within device Computer systems residing within a device

Environment Nodes nodes node, like operating systems or JVMs.
(EEN)
 Artifacts Rectangle with Represent concrete software elements like
dog-eared corner executable files, libraries, configuration files,
databases.

Communication Paths Solid lines between Show communication links between nodes. Can
nodes be labeled with communication protocols (e.g.,
HTTP, TCP/IP).

Dependency Dashed arrow Indicates that one element depends on another.

Deployment Dashed arrow labeled Shows how artifacts are deployed to nodes.
'deploy'

Deployment Diagram Guidelines

• Identify the nodes (hardware and software).

• Outline the software artifacts.
• Establish relationships between nodes.
• Configure artifacts on nodes.
• Detail the environment (e.g., OS, cloud platform).
• Annotate the diagram with notes and constraints.
 Chapter 12: UML Summary

Quick Reference – All UML Diagrams

Diagram Category Purpose & Use

Class Diagram Structural Visualizes a system's classes, their properties, and the
relationships between them. Foundation for component and
deployment diagrams.

Component Structural Verifies that required functionalities are implemented by

Diagram components. Breaks down complex systems into smaller
components and visualizes their relationships.

Deployment Structural Describes hardware components used in system

Diagram implementations, execution environments, and artifacts
deployed on hardware. Visualizes hardware topology.

Object Diagram Structural Shows the relationship between objects using real-world
examples. Illustrates how a system will look at any given
time.

Use Case Diagram Behavioral Used during analysis to identify system functionality by
describing interactions of people or external devices with the
system. Provides a high-level overview for non-technical
audiences.

Sequence Diagram Behavioral Describes how operations are carried out. Depicts the
chronologically structured event flow through a use case and
presents communication relationships between objects.

Communication Behavioral Visualizes the relationship between objects collaborating to

Diagram perform a task. Models the logic of complex operations. Can
represent the same info as sequence diagram.

State Diagram Behavioral Models the dynamic nature of a system by describing all
possible states of an object as events occur, from creation to
termination.

Activity Diagram Behavioral Graphically represents business or operational workflows to

show the activity of any part or component in the system.