Software Engineering

BY
Prof. Shraddha Rokade
Software Requirements
Functional and non-functional requirements
Requirements are generally split into two types: Functional and Non-functional requirements.

Functional Requirements: These are the requirements that the end user specifically demands
as basic facilities that the system should offer. All these functionalities need to be necessarily
incorporated into the system as a part of the contract. These are represented or stated in the
form of input to be given to the system, the operation performed and the output expected.
They are basically the requirements stated by the user which one can see directly in the final
product.Example: Authentication of user whenever he/she logs into the system.

Non-functional requirements: These are basically the quality constraints that the system
must satisfy according to the project contract. The priority or extent to which these factors are
implemented varies from one project to other. They are also called non-behavioral
requirements.They basically deal with issues like:
Portability,Security,Maintainability,Reliability,Scalability,Performance,Reusability,Flexibility
.Example:The site should load in 3 seconds when the number of simultaneous users are >
10000
User requirements: These requirements describe what the end-user wants from the
software system. User requirements are usually expressed in natural language and are
typically gathered through interviews, surveys, or user feedback.

System requirements: These requirements specify the technical characteristics of the

software system, such as its architecture, hardware requirements, software components,
and interfaces. System requirements are typically expressed in technical terms and are
often used as a basis for system design.

Interface requirements: These requirements specify the interactions between the

software system and external systems or components, such as databases, web services,
or other software applications.
The software requirements document
Software Requirement Specification (SRS)
(SRS) Format as name suggests, is complete specification and description of
requirements of software that needs to be fulfilled for successful development of
software system. These requirements can be functional as well as non-functional
depending upon type of requirement. The interaction between different customers
and contractor is done because its necessary to fully understand needs of customers.
1. Introduction
(i) Purpose of this document (ii) Scope of this document (iii) Overview

2. General description 3. Functional Requirements 4. Interface Requirements 5.

Performance Requirements 6. Design Constraints 7. Non-Functional Attributes 8.
Preliminary Schedule and Budget 9. Appendices
Requirements engineering process:

➔ Feasibility Study in Software Engineering is a study to evaluate

feasibility of proposed project or system. Feasibility study is one of stage
among important four stages of Software Project Management Process.
As name suggests feasibility study is the feasibility analysis or it is a
measure of the software product in terms of how much beneficial product
development will be for the organization in a practical point of view.
Feasibility study is carried out based on many purposes to analyze
whether software product will be right in terms of development,
implantation, contribution of project to the organization etc.
➔ Requirements elicitation is the process of gathering and defining the
requirements for a software system. The goal of requirements elicitation
is to ensure that the software development process is based on a clear and
comprehensive understanding of the customer’s needs and requirements.
Requirements elicitation involves the identification, collection, analysis,
and refinement of the requirements for a software system. It is a critical
part of the software development life cycle and is typically performed at
the beginning of the project. Requirements elicitation involves
stakeholders from different areas of the organization, including business
owners, end-users, and technical experts. The output of the requirements
elicitation process is a set of clear, concise, and well-defined
requirements that serve as the basis for the design and development of the
software system.
 Requirements elicitation Activities:

● Knowledge of the overall area where the systems is applied.

● The details of the precise customer problem where the system is going to be applied must be
understood.
● Interaction of system with external requirements.
● Detailed investigation of user needs.
● Define the constraints for system development

There are a number of requirements elicitation methods.

1. Interviews
2. Brainstorming Sessions
3. Facilitated Application Specification Technique (FAST)
4. Quality Function Deployment (QFD)
5. Use Case Approach
➔ Requirements validation is the process of checking that requirements defined for
development, define the system that the customer really wants. To check issues related to requirements,
we perform requirements validation. We usually use requirements validation to check error at the initial
phase of development as the error may increase excessive rework when detected later in the
development process. In the requirements validation process, we perform a different type of test to
check the requirements mentioned in the Software Requirements Specification (SRS), these checks
include:
● Completeness checks
● Consistency checks
● Validity checks
● Realism checks
● Ambiguity checks
● Verifiability

The output of requirements validation is the list of problems and agreed on actions of detected problems. The
lists of problems indicate the problem detected during the process of requirement validation. The list of
agreed action states the corrective action that should be taken to fix the detected problem.
➔ Requirements management is a set of activities that help the
project team to identify, control, and track requirements and
changes to requirements at any time as the project proceeds.
Like SCM, requirements management begins with
identification. Each requirement is assigned a unique identifier
that might take the form where requirement type takes on values
such as F = functional requirement, D = data requirement, B =
behavioral requirement, I = interface requirement, and P =
output requirement. Hence, a requirement identified as F09
indicates a functional requirement assigned requirement number
9.
Software Analysis:
Difference between Structured & Object Oriented analysis

Structured Analysis:

1. Focus on processes: Structured Analysis focuses on the processes involved in a software

system, modeling them as a series of connected steps.
2. Top-down approach: Structured Analysis follows a top-down approach, breaking down
complex systems into smaller, simpler parts that can be more easily understood.
3. Data-centered: Structured Analysis focuses on the data that a software system
manipulates, modeling it as data flows between processes.
4. Emphasis on functional decomposition: Structured Analysis emphasizes the functional
decomposition of a software system into smaller, independent functions.
Object-Oriented Analysis (OOA):

1. Focus on objects: OOA focuses on the objects involved in a software system,

modeling them as instances of classes that encapsulate both data and behavior.
2. Bottom-up approach: OOA follows a bottom-up approach, building complex
systems from smaller, simpler objects that can be more easily understood.
3. Object-centered: OOA focuses on the objects that make up a software system,
modeling their relationships and interactions.
4. Emphasis on object-oriented design patterns: OOA emphasizes the reuse of
objects and object-oriented design patterns, reducing the amount of code that
needs to be written and improving the quality and consistency of the software.
Difference between Structured & Object Oriented analysis

● Structured Analysis ● Object-Oriented Analysis

❏ The main focus is on the process ❏ The main focus is on data
and procedures of the system. structure and real-world
❏ It uses System Development Life objects that are important.
Cycle (SDLC) methodology for
❏ It uses Incremental or
different purposes like planning,
analyzing, designing,
Iterative methodology to
implementing, and supporting an refine and extend our design.
information system. ❏ It is suitable for large projects
❏ It is suitable for well-defined with changing user
projects with stable user requirements.
requirements.
Difference between Structured & Object Oriented analysis

● Structured Analysis ● Object-Oriented Analysis

❏ Risk while using this ❏ Risk while using this

analysis technique is analysis technique is low
❏ This technique is new and
high
is mostly preferred.
❏ This technique is old
and is not preferred
usually.
Use Case
● The Use-case model is defined as a model which is used to show how
users interact with the system in order to solve a problem.
● Various model elements are contained in use-case model, such as actors,
use cases, and the association between them.

Components of Basic Model

There are various components of the basic model:

1. Actor
2. Use Case
3. Associations
Actor
Usually, actors are people involved with the system defined on the basis of their roles. An actor can be
anything such as human or another external system.

Use Case
The use case defines how actors use a system to accomplish a specific objective. The use cases are
generally introduced by the user to meet the objectives of the activities and variants involved in the
achievement of the goal.

Associations
Associations are another component of the basic model. It is used to define the associations among
actors and use cases they contribute in. This association is called communicates-association.
There are various components of the advanced model:

1. Subject
2. Use-Case Package
3. Generalizations
4. Dependencies

Subject
The subject component is used to represent the boundary of the system of interest.

Use-Case Package
we use directories or folders to organize the information on our hard-disk.
Generalizations

Generalizations mean the association between the actors in order to help re-use
of common properties.

Dependencies

In UML, various types of dependencies are defined between use cases. In

particular, <<include>> and <<extend>>.
We use <<include>> dependency to comprise shared behavior from an included
use case into a base use case to use common behavior.
We use <<extend>> dependency to include optional behavior from an extended
use-case into an extended use case.
Student Management System
Class diagram
● The main purpose of class diagrams
is to build a static view of an application.

● Components of a Class Diagram

Relationships
Generalization

Association

Multiplicity
Aggregation

Composition

Abstract Classes
A class diagram describing the sales order system is
Interaction diagrams
The interaction diagram portrays the interactions between distinct
entities present in the model.

Notation of an Interaction Diagram

Activity diagram
We use Activity Diagrams to illustrate the flow of control in a system and refer to the
steps involved in the execution of a use case.

Activity Diagram Notations –

Initial State – The starting state before an activity takes place is depicted using the
initial state.

Action or Activity State - An activity represents execution of an action on objects or

by objects.

Action Flow or Control flows – They are used to show the transition from one activity
state to another.
Decision node and Branching - When we need to make a decision before
deciding the flow of control, we use the decision node.

Guards – A Guard refers to a statement written next to a decision node on an

arrow sometimes within square brackets.
Fork – Fork nodes are used to support concurrent activities.

Join – Join nodes are used to support concurrent activities converging into one.

Merge or Merge Event – Scenarios arise

when activities which are not being executed concurrently
have to be merged.
Swimlanes – We use swimlanes for grouping related activities in one column.

Time Event - We can have a scenario where an event takes some time to
complete.

Final State or End State – The state which the system reaches when a
particular process or activity ends is known as a Final State or End State.
State Chart diagram
A state diagram is used to represent the condition of the system or part of the
system at finite instances of time.
Initial state – We use a black filled circle represent the initial state of a System
or a class.
Transition – We use a solid arrow to represent the transition or change of
control from one state to another.
State – We use a rounded rectangle to represent a state.

Fork – We use a rounded solid rectangular bar to represent a Fork notation with
incoming arrow from the parent state and outgoing arrows towards the newly
created states.
Join – We use a rounded solid rectangular bar to represent a Join notation with
incoming arrows from the joining states and outgoing arrow towards the
common goal state.

Self transition – We use a solid arrow pointing back to the state itself to
represent a self transition.
Composite state – We use a rounded rectangle to represent a composite state
also.We represent a state with internal activities using a composite state.

Final state – We use a filled circle within a circle notation to represent the final
state in a state machine diagram.
Component Diagram - A component diagram is used to break down a large
object-oriented system into the smaller components, so as to make them more
manageable.

Notation of a Component Diagram

a) A component

b) A node
Deployment Diagram -The deployment diagram visualizes the physical
hardware on which the software will be deployed.

The deployment diagram consist of the following notations:

1. A component
2. An artifact
3. An interface
4. A node
Data Flow Diagrams -The flow of data of a system or a process is represented
by DFD. It also gives insight into the inputs and outputs of each entity and the
process itself.
Components of DFD
Process
Data Flow
Warehouse
Terminator
Symbols Used in DFD
● Square Box: A square box defines source or destination of the system. It
is also called entity. It is represented by rectangle.
● Arrow or Line: An arrow identifies the data flow i.e. it gives information
to the data that is in motion.
● Circle or bubble chart: It represents as a process that gives us
information. It is also called processing box.
● Open Rectangle: An open rectangle is a data store. In this data is store
either temporary or permanently.
Levels of DFD
DFD uses hierarchy to maintain transparency thus multi level DFD’s can be
created. Levels of DFD are as follows:
● 0-level DFD: It represents the entire system as a single bubble and provides
an overall picture of the system.
● 1-level DFD: It represents the main functions of the system and how they
interact with each other.
● 2-level DFD: It represents the processes within each function of the system
and how they interact with each other.