UNIT-2 Requirement Elicitation,

Analysis, and Specification

UNIT 2 SYLLABUS
Unit II: Requirement Elicitation, Analysis, and Specification
Functional and Non-functional requirements, Requirement Sources
and Elicitation Techniques,
Analysis Modeling for Function-oriented and Object-oriented
software development,
Use case Modeling, System and Software Requirement
Specifications, Requirement Validation, Traceability
SOFTWARE REQUIREMENT
SPECIFICATION (SRS)
Software Requirement Specification (SRS) Format as the name suggests, is a
complete specification and description of requirements of the software that need
to be fulfilled for the successful development of the software system.
These requirements can be functional as well as non-functional depending upon the
type of requirement
The interaction between different customers and contractors is done because it is
necessary to fully understand the needs of customers.
SRS LAYOUT
1.1 INTRODUCTION
•Purpose of this Document – At first, main aim of why this document is necessary
and what’s purpose of document is explained and described.
•Scope of this document – In this, overall working and main objective of document
and what value it will provide to customer is described and explained. It also
includes a description of development cost and time required.
•Overview – In this, description of product is explained. It’s simply summary or
overall review of product.
1.2 GENERAL DESCRIPTION
In this, general functions of product which
includes objective of user, a user characteristic,
features, benefits, about why its importance is
mentioned.

It also describes features of user community.

1.3 FUNCTIONAL
REQUIREMENTS
All functional requirements which may include calculations, data processing, etc. are
placed in a ranked order.
Functional requirements specify the expected behavior of the system-which outputs
should be produced from the given inputs.
They describe the relationship between the input and output of the system.
For each functional requirement, detailed description all the data inputs and their
source, the units of measure, and the range of valid inputs must be specified.
1.4 INTERFACE
REQUIREMENTS
In this, software interfaces which mean how
software program communicates with each other or
users either in form of any language, code, or
message are fully described and explained.
Examples can be shared memory, data streams, etc.
1.5 NON-FUNCTIONAL
REQUIREMENTS

An example may include

In this, non-functional Security, Portability,
attributes are explained Reliability, Reusability,
that are required by Application
software system for compatibility, Data
better performance. integrity, Scalability
capacity, etc.
 1.6 PERFORMANCE
REQUIREMENTS
1. In this, how a software system performs desired functions under specific
condition is explained.
2. It also explains required time, required memory, maximum error rate, etc.
3. All the requirements relating to the performance characteristics of the system
must be clearly specified.
4. There are two types of performance requirements: static and dynamic.
5. Static requirements are those that do not impose constraint on the execution
characteristics of the system.
6. Dynamic requirements specify constraints on the execution behaviour of the
system
 1.7 DESIGN CONSTRAINTS
1. In this, constraints which simply means limitation or restriction are specified and
explained for design team.
2. Examples may include use of a particular algorithm, hardware and software
limitations, etc.
3. There are a number of factors in the client’s environment that may restrict the
choices of a designer leading to design constraints such factors include standards
that must be followed resource limits, operating environment, reliability and
security requirements and policies that may have an impact on the design of the
system.
4. An SRS should identify and specify all such constraints.
1.8 & 1.9
1.8 Preliminary Schedule and Budget
In this, initial version and budget of project plan are explained which
include overall time duration required and overall cost required for
development of project.
1.9 Appendices
In this, additional information like references from where information
is gathered, definitions of some specific terms, acronyms,
abbreviations, etc. are given and explained.
 APPLICATION OF SRS
1. Development team require it for developing product according to the need.
2. Test plans are generated by testing group based on the describe external behaviour.
3. Maintenance and support staff need it to understand what the software product is
supposed to do.
4. Project manager base their plans and estimates of schedule, effort and resources on it.
5. Customer rely on it to know that product they can expect.
6. As a contract between developer and customer.
7. For documentation purpose.
 SRS
CHARACTER
ISTICS
UML
UNIFIED MODELING
LANGUAGE
UML stands for Unified Modelling Language.

It is a generic developmental modelling language used for

analysis, design and implementation of software systems.

The purpose of UML is to provide a simple and common

method to visualise a software system's inherent architectural
properties.
 UML
UML is not a programming language, it is rather a visual language.
1. We use UML diagrams to portray the behaviour and structure of a system.
2. UML helps software engineers, businessmen, and system architects with
modeling, design, and analysis.
3. The Object Management Group (OMG) adopted Unified Modelling Language as
a standard in 1997. It’s been managed by OMG ever since.
4. The International Organization for Standardization (ISO) published UML as an
approved standard in 2005. UML has been revised over the years and is reviewed
periodically.
WHY DO WE NEED UML?
•Complex applications need collaboration and planning from multiple teams and
hence require a clear and concise way to communicate amongst them.
•Businessmen do not understand code.
•So UML becomes essential to communicate with non-programmers about essential
requirements, functionalities, and processes of the system.
•A lot of time is saved down the line when teams can visualize processes, user
interactions, and the static structure of the system.
TYPES OF
UML
 OOPS CONCEPTS USED IN
UML
[Link]: A class defines the blue print i.e. structure and functions of an object.
[Link]: Objects help us to decompose large systems and help us to modularize our system.
Modularity helps to divide our system into understandable components so that we can build our
system piece by piece.
[Link]: Inheritance is a mechanism by which child classes inherit the properties of their
parent classes.
[Link]: Abstraction in UML refers to the process of emphasizing the essential aspects of a
system or object while disregarding irrelevant details. By abstracting away unnecessary
complexities, abstraction facilitates a clearer understanding and communication among
stakeholders.
[Link]: Binding data together and protecting it from the outer world is referred to as
encapsulation.
[Link]: Mechanism by which functions or entities are able to exist in different forms.
STEPS TO CREATE UML
 BENEFITS OF UML
[Link]: UML provides a standardized way of representing system models,
ensuring that developers and stakeholders can communicate using a common visual
language.
[Link]: UML diagrams serve as a powerful communication tool between
stakeholders, including developers, designers, testers, and business users. They help in
conveying complex ideas in a more understandable manner.
[Link]: UML diagrams facilitate the visualization of system components,
relationships, and processes. This visual representation aids in understanding and designing
complex systems.
[Link]: UML diagrams can be used as effective documentation tools. They provide
a structured and organized way to document various aspects of a system, such as
architecture, design, and behavior.
[Link] and Design: UML supports both analysis and design phases of software
development. It helps in modeling the requirements of a system and then transforming them
into a design that can be implemented
USE CASE DIAGRAM _
USE CASE DIAGRAM

It serves as a blueprint for

understanding the functional
A Use Case Diagram is a
requirements of a system
vital tool in system design, it
from a user’s perspective,
provides a visual
aiding in the communication
representation of how users
between stakeholders and
interact with a system.
guiding the development
process.
USE CASE DIAGRAM
NOTATIONS
1.1 ACTORS
Actors are external entities that interact with the system.
These can include users, other systems, or hardware devices.
In the context of a Use Case Diagram, actors initiate use cases and receive the
outcomes.
Proper identification and understanding of actors are crucial for accurately modelling
system behaviour.
1.2 USE CASES
1.2. Use Cases
Use cases are like scenes in the play. They represent specific things your system can
do.
In the online shopping system, examples of use cases could be “Place Order,” “Track
Delivery,” or “Update Product Information”.
Use cases are represented by ovals.
1.3 SYSTEM BOUNDARIES
1.3. System Boundary
The system boundary is a visual representation of the scope or limits of the system you are
modeling. It defines what is inside the system and what is outside. The boundary helps to
establish a clear distinction between the elements that are part of the system and those that
are external to it. The system boundary is typically represented by a rectangular box that
surrounds all the use cases of the system.
Purpose of System Boundary:
•Scope Definition: It clearly outlines the boundaries of the system, indicating which
components are internal to the system and which are external actors or entities interacting
with the system.
•Focus on Relevance: By delineating the system’s scope, the diagram can focus on
illustrating the essential functionalities provided by the system without unnecessary details
about external entities.
RELATIONSHIPS
Association Relationship
The Association Relationship represents a communication or interaction between an
actor and a use case. It is depicted by a line connecting the actor to the use case. This
relationship signifies that the actor is involved in the functionality described by the
use case.
Example: Online Banking System
•Actor: Customer
•Use Case: Transfer Funds
•Association: A line connecting the “Customer” actor to the “Transfer Funds” use
case, indicating the customer’s involvement in the funds transfer process.
RELATIONSHIPS
INCLUDE RELATIONSHIPS
The Include Relationship indicates that a use case includes the functionality of
another use case. It is denoted by a dashed arrow pointing from the including use
case to the included use case. This relationship promotes modular and reusable
design.
Example: Social Media Posting
•Use Cases: Compose Post, Add Image
•Include Relationship: The “Compose Post” use case includes the functionality of
“Add Image.” Therefore, composing a post includes the action of adding an image.
INCLUDE
EXTEND
The Extend Relationship illustrates that a use case can be extended by another use
case under specific conditions. It is represented by a dashed arrow with the keyword
“extend.” This relationship is useful for handling optional or exceptional behavior.
Example: Flight Booking System
•Use Cases: Book Flight, Select Seat
•Extend Relationship: The “Select Seat” use case may extend the “Book Flight” use
case when the user wants to choose a specific seat, but it is an optional step.
EXTEND
GENERALIZATION
The Generalization Relationship establishes an “is-a” connection between two use
cases, indicating that one use case is a specialized version of another. It is
represented by an arrow pointing from the specialized use case to the general use
case.
Example: Vehicle Rental System
•Use Cases: Rent Car, Rent Bike
•Generalization Relationship: Both “Rent Car” and “Rent Bike” are specialized
versions of the general use case “Rent Vehicle.”
GENERALIZATION
Example-ATM System:
Withdraw Cash → <<include>> Authenticate User (mandatory)
Withdraw Cash → <<extend>> Print Receipt (optional)
 DATA FLOW
DIAGRAM (DFD)
DATA FLOW DIAGRAM
DFD is the abbreviation for Data Flow Diagram.
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.
DFD does not have control flow and no loops or decision rules are present.
Specific operations depending on the type of data can be explained by a
flowchart.
It is a graphical tool, useful for communicating with users ,managers and
other personnel.
It is useful for analyzing existing as well as proposed system
DFD

It provides an overview of

•What data is system processes?

•What transformation are performed?
•What data are stored?
•What results are produced ?, etc.
 DFD
SYMBOLS
NOTATIONS
IN DFD
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.
RULES FOR CREATING
DFD
1. Data can flow from
Terminator or External Entity → Process
Process → Terminator or External Entity
Process → Data Store
Data Store → Process
Process → Process
2. Data Cannot Flow From
Terminator or External Entity → Terminator or External Entity
Terminator or External Entity → Data Store
Data Store → Terminator or External Entity
Data Store → Data Store.
DFD CHARACTERISTICS
•DFDs are commonly used during problem analysis.
•DFDs are quite general and are not limited to problem analysis for software requirements specification.
•DFDs are very useful in understanding a system and can be effectively used during analysis.
•It views a system as a function that transforms the inputs into desired outputs.
•The DFD aims to capture the transformations that take place within a system to the input data so that
eventually the output data is produced.
•The processes are shown by named circles and data flows are represented by named arrows entering or
leaving the bubbles.
•A rectangle represents a source or sink and it is a net originator or consumer of data. A source sink is typically
outside the main system of study.
LEVELS OF DFD
DFD uses hierarchy to maintain transparency thus multilevel 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.
•3-level DFD: It represents the data flow within each process and how the data is
transformed and stored
LEVEL 0 DFD
LEVEL 0 DFD
The Level 0 data flow diagram gives a general overview of the process.
They are also called context diagrams.
The level 0 DFDs depict the single process node and its links with external entities.
It is understood by all the stakeholders participating in the activity.
LEVEL 1
DFD
LEVEL 1 DFD
The Level 1 data flow diagrams are the more detailed breakout of parts of the Level
0 DFDs.
In a level 1 DFD, the single process node is broken down into sub-processes with
additional data flows and data stores to connect them.
LEVEL 2
DFD
LEVEL 2 DFD
The Level 2 data Flow diagrams go into deeper sub-processes to better illustrate a
process and its stages.
More symbols, shapes, and text are required to detail the process depicting the
system's functioning.
 TRY THIS
1. Draw a level 0 DFD for Library Management
System

2. Draw a level 0 DFD for Railway Reservation

System
LEVEL 0 DFD
RAILWAY RESERVATION
SYSTEM LEVEL 0 DFD
LEVEL 1 DFD
LEVEL 2 DFD
 ONLINE BANKING
SYSTEM LEVEL 0 DFD
 LEVEL 1
DFD
ONLINE
BANKING
SYSTEM
CLASS DIAGRAM
Class diagrams are a type of UML (Unified Modeling Language)
diagram used in software engineering to visually represent the
structure and relationships of classes in a system.
UML is a standardized modeling language that helps in designing
and documenting software systems.
They are an integral part of the software development process,
helping in both the design and documentation phases.

CLASS DIAGRAM
CLASS DIAGRAM
Class diagrams provide a high-level overview of
a system’s design, helping to communicate and
document the structure of the software.
They are a fundamental tool in object-oriented
design and play a crucial role in the software
development lifecycle.
CLASS DIAGRAM
UML CLASS
NOTATION
Class notation is a graphical representation used to
depict classes and their relationships in
object-oriented modeling.
UML CLASS NOTATION
 UML CLASS NOTATION
[Link] Name:
The name of the class is typically written in the top compartment of the class box and is centred and
bold.

[Link]:
Attributes, also known as properties or fields, represent the data members of the class. They are
listed in the second compartment of the class box and often include the visibility (e.g., public,
private) and the data type of each attribute.
 UML NOTATIONS
[Link]:
•Methods, also known as functions or operations, represent the behavior
or functionality of the class.
•They are listed in the third compartment of the class box and include the
visibility (e.g., public, private), return type, and parameters of each
method.
[Link] Notation:
•Visibility notations indicate the access level of attributes and methods.
Common visibility notations include:
•+ for public (visible to all classes)
•- for private (visible only within the class)
•# for protected (visible to subclasses)
•~ for package or default visibility (visible to classes in the same
package)
RELATIONSHIPS IN CLASS
DIAGRAM
RELATIONSHIPS IN CLASS
DIAGRAM
1. Association
An association represents a bi-directional relationship between two classes. It
indicates that instances of one class are connected to instances of another class.
Example: Teacher ↔ Student
2. Directed Association
A directed association in a UML class diagram represents a relationship between two
classes where the association has a direction, indicating that one class is associated
with another in a specific way.
Example: Customer → Order
RELATIONSHIPS IN CLASS
DIAGRAM
3. Aggregation
Aggregation is a specialized form of association that represents a "whole-part"
relationship. It denotes a stronger relationship where one class (the whole) contains
or is composed of another class (the part)
Example: Library ◇— Books
4. Composition
Composition is a stronger form of aggregation, indicating a more significant
ownership or dependency relationship. In composition, the part class cannot exist
independently of the whole class.
Example: House ◆— Rooms
RELATIONSHIPS IN CLASS
DIAGRAM
5. Generalization(Inheritance)
Inheritance represents an "is-a" relationship between classes, where one class (the subclass
or child) inherits the properties and behaviors of another class (the superclass or parent)
Example-Animal → Dog
6. Realization (Interface Implementation)
Realization indicates that a class implements the features of an interface. It is often used in
cases where a class realizes the operations defined by an interface.
Interface: Shape → Class: Circle
Shape defines: draw()
Circle implements draw()
RELATIONSHIPS IN CLASS
DIAGRAM
7. Dependency Relationship
A dependency exists between two classes when one class relies on another, but the
relationship is not as strong as association or inheritance. It represents a more loosely
coupled connection between classes.
Example: Report → Printer
8. Usage(Dependency) Relationship
A usage dependency relationship in a UML class diagram indicates that one class (the
client) utilizes or depends on another class (the supplier) to perform certain tasks or access
certain functionality.
Example: Student → Calculator
Student uses calculator to solve problems
Doesn’t own or control the calculator
SEQUENCE
DIAGRAM
 A sequence diagram simply depicts the interaction
between the objects in a sequential order i.e. the
order in which these interactions occur.

We can also use the terms event diagrams or event

SEQUENC scenarios to refer to a sequence diagram.
E
DIAGRAM Sequence diagrams describe how and in what
order the objects in a system function.

These diagrams are widely used by businessmen

and software developers to document and
understand requirements for new and existing
systems.
SEQUENCE DIAGRAM
NOTATIONS
1.1. Actors

An actor in a UML diagram represents a type of role where it

interacts with the system and its objects.

It is important to note here that an actor is always outside the

scope of the system we aim to model using the UML diagram.
EXAMPLE
SEQUENCE DIAGRAM
NOTATIONS
1.2. Lifelines
A lifeline is a named element which depicts an individual participant in a sequence
diagram.
So basically each instance in a sequence diagram is represented by a lifeline.
Lifeline elements are located at the top in a sequence diagram.
 SEQUENCE DIAGRAM
NOTATIONS
We display a lifeline in a rectangle called head with its name and type.
The head is located on top of a vertical dashed line.
If we want to model an unnamed instance, we follow the same pattern except
now the portion of lifeline’s name is left blank.
Difference between a lifeline and an actor
A lifeline always portrays an object internal to the system whereas actors are used to depict
objects external to the system.
EXAMPLE
SEQUENCE DIAGRAM
NOTATIONS
1.3. Messages
Communication between objects is depicted using messages. The messages appear in
a sequential order on the lifeline.
•We represent messages using arrows.
•Lifelines and messages form the core of a sequence diagram.
TYPES OF MESSAGES
TYPES OF MESSAGES
1. Synchronous messages
A synchronous message waits for a reply before the interaction can move forward.
The sender waits until the receiver has completed the processing of the message. The
caller continues only when it knows that the receiver has processed the previous
message i.e. it receives a reply message.
•A large number of calls in object oriented programming are synchronous.
•We use a solid arrow head to represent a synchronous message.
EXAMPLE
TYPES OF MESSAGES
2. Asynchronous Messages
An asynchronous message does not wait for a reply from the receiver.
The interaction moves forward irrespective of the receiver processing the previous
message or not.
We use a lined arrow head to represent an asynchronous message.
EXAMPLE
CREATE MESSAGE
1.4. Create message
We use a Create message to instantiate a new object in the sequence diagram.
There are situations when a particular message call requires the creation of an object.
It is represented with a dotted arrow and create word labelled on it to specify that it is
the create Message symbol.
EXAMPLE
DELETE MESSAGE
1.5. Delete Message
We use a Delete Message to delete an object.
When an object is deallocated memory or is destroyed within the system we use the
Delete Message symbol.
It destroys the occurrence of the object in the [Link] is represented by an arrow
terminating with a x.
EXAMPLE
SELF MESSAGE
1.6. Self Message
Certain scenarios might arise where the object needs to send a message to itself.
Such messages are called Self Messages and are represented with a U shaped
arrow.
EXAMPLE
REPLY MESSAGE
1.7. Reply Message
Reply messages are used to show the message being sent from the receiver to the
sender. We represent a return/reply message using an open arrow head with a
dotted line. The interaction moves forward only when a reply message is sent by the
receiver.
REPLY MESSAGE
FOUND MESSAGE
1.8. Found Message
A Found message is used to represent a scenario where an unknown source sends the
message. It is represented using an arrow directed towards a lifeline from an end
point.
EXAMPLE
LOST MESSAGE
1.9. Lost Message
A Lost message is used to represent a scenario where the recipient is not known to
the system. It is represented using an arrow directed towards an end point from a
lifeline.
EXAMPLE
GUARDS
1.10. Guards
To model conditions we use guards in UML.
They are used when we need to restrict the flow of messages on the pretext of a
condition being met.
Guards play an important role in letting software developers know the constraints
attached to a system or a particular process.
EXAMPLE
EXAMPLE
REQUIREMENT
ANALYSIS
REQUIREMENT
ANALYSIS
Requirements analysis is a very critical process that
enables the success of a system or software project
to be assessed.
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 the
requirements stated by the user which one can see directly in the final
product, unlike the non-functional requirements.
Example:
•What are the features that we need to design for this system?
•What are the edge cases we need to consider, if any, in our design?
NON FUNCTIONAL
REQUIREMENTS
These are 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 another. They are also called non-behavioral
requirements. They deal with issues like:
•Portability
•Security
•Maintainability
•Reliability
•Scalability
•Performance
•Reusability
•Flexibility
NON FUNCTIONAL
REQUIREMENTS
Example:
•Each request should be processed with the minimum latency?
•System should be highly valuable.
FUNCTIONAL VS NON
FUNCTIONAL REQUIREMENTS
REQUIREMENT
ELICITATION
REQUIREMENT
ELICITATION
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.
 REQUIREMENT ELICITATION
Requirements elicitation is perhaps the most difficult, most error-prone, and
most communication-intensive software development.
[Link] can be successful only through an effective customer-developer partnership. It is
needed to know what the users require.
[Link] elicitation involves the identification, collection, analysis, and
refinement of the requirements for a software system.
 REQUIREMENT ELICITATION
[Link] is a critical part of the software development life cycle and is typically
performed at the beginning of the project.
[Link] elicitation involves stakeholders from different areas of the
organization, including business owners, end-users, and technical experts.
[Link] 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.
REQUIREMENT
ELICITATION
METHODS
 1. Interviews
REQUIREM
2. Brainstorming Sessions
ENT
3. Facilitated application specification
ELICITATI technique
ON 4. Quality function deployment
METHODS 5. Use case approach
 1. Interviews
Objective of conducting an interview is to understand
the customer’s expectations from the software.
REQUIREM
ENT It is impossible to interview every stakeholder hence
representatives from groups are selected based on their
ELICITATI expertise and credibility. Interviews maybe be
open-ended or structured.
ON [Link] open-ended interviews there is no pre-set agenda.
Context free questions may be asked to understand the
METHODS problem.
[Link] a structured interview, an agenda of fairly open
questions is prepared. Sometimes a proper questionnaire
is designed for the interview.
REQUIREMENT
ELICITATION
METHODS
2. Brainstorming Sessions
•It is a group technique
•It is intended to generate lots of new ideas hence
providing a platform to share views
•A highly trained facilitator is required to handle group
bias and group conflicts.
•Every idea is documented so that everyone can see it.
•Finally, a document is prepared which consists of the list
of requirements and their priority if possible.
 REQUIREMENT ELICITATION
METHODS
3. Facilitated Application Specification Technique
Its objective is to bridge the expectation gap – the difference between what the
developers think they are supposed to build and what customers think they are going
to get. A team-oriented approach is developed for requirements gathering. Each
attendee is asked to make a list of objects that are:
[Link] of the environment that surrounds the system.
[Link] by the system.
[Link] by the system.
REQUIREMENT ELICITATION
METHODS
4. Quality Function Deployment
In this technique customer satisfaction is of prime concern, hence it emphasizes on the
requirements which are valuable to the customer.

3 types of requirements are identified:

•Normal requirements: In this the objective and goals of the proposed software are
discussed with the customer. Example – normal requirements for a result management
system may be entry of marks, calculation of results, etc.
•Expected requirements: These requirements are so obvious that the customer need not
explicitly state them. Example – protection from unauthorized access.
•Exciting requirements: It includes features that are beyond customer’s expectations and
prove to be very satisfying when present. Example – when unauthorized access is detected,
it should backup and shutdown all processes.
 REQUIREMENT ELICITATION
METHODS
5. Use Case Approach
This technique combines text and pictures to provide a better understanding of the
requirements.

The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give
a functional view of the system.

The components of the use case design include three major things – Actor, use
cases, use case diagram.
[Link]:
[Link] cases:
[Link] case diagram:
 STEPS OF REQUIREMENT
ELICITATION
[Link] all the stakeholders, e.g., Users, developers, customers etc.
[Link] out all requirements from customer.
3.A value indicating degree of importance is assigned to each
requirement.
[Link] the end the final list of requirements is categorized as:
It is possible to achieve.
It should be deferred and the reason for it.
It is impossible to achieve and should be dropped off
 ADVANTAGES
[Link] requirements: Helps to clarify and refine customer requirements.
[Link] communication: Improves communication and collaboration
between stakeholders.
[Link] in good quality software: Increases the chances of developing a
software system that meets customer needs.
[Link] misunderstandings: Avoids misunderstandings and helps to manage
expectations.
[Link] the identification of potential risks: Supports the identification of
potential risks and problems early in the development cycle.
[Link] development of accurate plan: Facilitates the development of a
comprehensive and accurate project plan.
[Link] user confidence: Increases user and stakeholder confidence in the
software development process.
[Link] identification of new business opportunities: Supports the
identification of new business opportunities and revenue streams.
 DISADVANTAGES
[Link] consuming: Can be time-consuming and expensive.
[Link] required: Requires specialized skills and expertise.
[Link] by changing requirements: May be impacted by changing business needs and requirements.
[Link] by other factors: Can be impacted by political and organizational factors.
[Link] of commitment from stakeholders: Can result in a lack of buy-in and commitment from stakeholders.
[Link] by conflicting priorities: Can be impacted by conflicting priorities and competing interests.
[Link] inaccurate requirements: May result in incomplete or inaccurate requirements if not properly managed.
[Link] development cost: Can lead to increased development costs and decreased efficiency if requirements are
not well-defined.
SOFTWARE MODELING
FUNCTION
MODELING
In the Functional Model, software converts
information, and to accomplish this, it must
perform at least three common tasks- input,
processing and output.
When functional models of an application are
created, the software engineer emphasizes problem
specific tasks.
The functional model begins with a single reference
level model. In a series of iterations, more and
more functional detail is given, until all system
functionality is fully represented.
FUNCTION MODELLING
A functional model represents the system's behavior that focuses on
what the system does without delving into how it accomplishes those
tasks
Functional models are often used during the early stages of software
development to capture the high-level requirements and behavior of the
system.
They help stakeholders, including developers, designers, and clients, to
understand and agree upon the system's expected functionalities before
diving into the details of implementation.
 FUNCTIONAL MODEL
DESCRIBES-
[Link]: It identifies and specifies the different tasks or operations
that the system can perform. These functionalities are often described in
terms of inputs, outputs, and the processing logic involved.
[Link]: It illustrates how different components or modules within the
system interact with each other to achieve the desired functionalities. This
can include the flow of data or control between components.
[Link]: It defines the interfaces through which users or external systems
can interact with the system. This includes input interfaces for providing
data or commands to the system and output interfaces for receiving results
or feedback.
HOW TO USE FUNCTIONAL
MODELS

There are various techniques These models can be

and notations used to create supplemented with textual
functional models, including descriptions or requirements
flowcharts, data flow documents to provide a
diagrams, use case comprehensive
diagrams, and activity understanding of the
diagrams. system's functionality.
 Information flow modeling is a
technique used in software
INFORMA engineering and systems analysis
to represent the movement of data
TION or information within a system.
FLOW It focuses on understanding how
MODELIN data is generated, processed, stored,
G and transmitted between different
components or subsystems of a
larger system.
INFORMATION
FLOW MODELING
Information flow modeling is particularly useful
in designing and analyzing systems where data
plays a critical role, such as information
systems, communication networks, and
distributed systems.
INFORMATION FLOW
MODELING
A computer-based system can be modeled as an information
transform function as shown in figure.

A rectangle represents an external unit. That is, a system element,

such as a hardware, a person or another system that provides
information for transformation by the software or receives
information provided by the software.
A circle is used to represent a process or transform or a function that
is applied to data and changes it in some way.
An arrow is used to represent one or more data items.
INFORMATION
FLOW
MODELING
 [Link] Data Sources and Sinks: The first
step in information flow modeling is to identify the
sources where data originates and the sinks
STEPS IN where data is consumed or stored. Sources could
include user inputs, sensors, external systems, or
INFORMA databases, while sinks could be output
interfaces, storage devices, or other systems.
TION [Link] Data Flows: Once the sources and
FLOW sinks are identified, data flows between them
need to be defined. Data flows represent the
MODELIN movement of information from one point to
another within the system. This can be depicted
G using arrows or lines in a diagram to indicate the
direction of data transfer.
 3. Modeling Processing Logic: Information flow
modeling also involves modeling the processing
logic that occurs within the system. This includes
STEPS IN specifying how data is transformed or manipulated
as it moves through different components or
INFORMA subsystems. This could involve data validation,
calculations, filtering, aggregation, or other
TION operations.
[Link] Dependencies: Information flow
FLOW modeling helps in identifying dependencies
between different components or subsystems of a
MODELIN system. This includes understanding how
changes in one part of the system can affect the
G flow of information and functionality in other parts
of the system.
 5. Concurrency and Parallelism: In complex
systems, data flows may occur concurrently or in
parallel. Information flow modeling helps in
STEPS IN understanding how multiple data flows interact
and synchronize with each other within the
INFORMA system.

TION [Link] and Analysis: Information flow

models can be used for verification and analysis
FLOW purposes to ensure that the system meets its
functional requirements, performance goals, and
MODELIN other quality attributes. This can involve
simulating the flow of data under different
G scenarios or analyzing the impact of changes to
the system architecture.
OBJECT ORIENTED
MODELING
Object-oriented modeling is a methodology
used in software engineering to design and
analyze systems based on the concept of
objects.
It's a way of representing real-world entities,
along with their attributes and behaviors, in
software systems.
Object-oriented modeling is a fundamental
aspect of object-oriented programming (OOP)
languages like Java, C++, and Python.
OBJECT ORIENTED MODELING
Object-oriented modeling is widely used in software development due to its
ability to model complex systems in a more intuitive and manageable way.
It promotes modularity, reusability, and scalability, making it suitable for
developing large-scale, maintainable software systems.
UML (Unified Modeling Language) is often used to visualize and document
object-oriented models using diagrams such as class diagrams, object
diagrams, sequence diagrams, and use case diagrams.
OBJECT ORIENTED
MODELLING INCLUDES
1. Objects
2. Classes
3. Inheritance
4. Encapsulation
5. Polymorphism
6. Association, Aggregation & Composition
TYPES OF
OBJECT-ORIENTED
MODELS
There are 3 types of models in the object oriented
modeling and design are:
Class Model,
State Model, and
Interaction Model.
 TYPES OF OBJECT-ORIENTED
MODELS
[Link] Model: The class model shows all the classes present in the system. The class
model shows the attributes and the behaviour associated with the objects.
The class diagram is used to show the class model.
The class diagram shows the class name followed by the attributes followed by the
functions or the methods that are associated with the object of the class.
Goal in constructing class model is to capture those concepts from the real world that
are important to an application.
TYPES OF OBJECT-ORIENTED
MODELS
[Link] Model: State model describes those aspects of objects concerned with time
and the sequencing of operations – events that mark changes, states that define the
context for events, and the organization of events and states.
Actions and events in a state diagram become operations on objects in the class
model. State diagram describes the state model.
TYPES OF OBJECT-ORIENTED
MODELS
[Link] Model: Interaction model is used to show the
various interactions between objects, how the objects collaborate to
achieve the behaviour of the system as a whole.
The following diagrams are used to show the interaction model:
1. Use Case Diagram
2. Sequence Diagram
3. Activity Diagram
REQUIREMENT ENGINEERING
PROCESS
REQUIREMENT
ENGINEERING
PROCESS
A systematic and strict approach to the
definition, creation, and verification of
requirements for a software system is known as
requirements engineering.
To guarantee the effective creation of a software
product, the requirements engineering process
entails several tasks that help in understanding,
recording, and managing the demands of
stakeholders.
REQUIREMENT ENGINEERING
PROCESS
 Feasibility Study

REQUIRE Requirements elicitation

MENT
ENGINEER Requirements specification

ING Requirements for verification and

PROCESS validation

Requirements management
1. FEASIBILITY
STUDY
 1. FEASIBILITY STUDY
The feasibility study mainly concentrates on below five mentioned areas below. Among
these Economic Feasibility Study is the most important part of the feasibility analysis and
the Legal Feasibility Study is less considered feasibility analysis.
[Link] Feasibility: In Technical Feasibility current resources both hardware software
along required technology are analyzed/assessed to develop the project.
This technical feasibility study reports whether there are correct required resources and
technologies that will be used for project development.
with this, the feasibility study also analyzes the technical skills and capabilities of the
technical team, whether existing technology can be used or not, whether maintenance and
up-gradation are easy or not for the chosen technology, etc.
1. FEASIBILITY STUDY

Operational Feasibility: In Along with this other

Operational Feasibility degree operational scopes are
of providing service to determining the usability of the
requirements is analyzed along product, Determining
with how easy the product will suggested solution by the
be to operate and maintain software development team is
after deployment. acceptable or not, etc.
1. FEASIBILITY STUDY
3. Economic Feasibility: In the Economic Feasibility study cost and benefit of the
project are analyzed.
This means under this feasibility study a detailed analysis is carried out will be cost
of the project for development which includes all required costs for final
development hardware and software resources required, design and development
costs operational costs, and so on.
After that, it is analyzed whether the project will be beneficial in terms of finance for
the organization or not.
2. REQUIREMENTS
ELICITATION
 2. REQUIREMENTS
ELICITATION
1. It is related to the various ways used to gain knowledge about the project domain
and requirements.
2. The various sources of domain knowledge include customers, business manuals,
the existing software of the same type, standards, and other stakeholders of the
project.
3. The techniques used for requirements elicitation include interviews,
brainstorming, task analysis, Delphi technique, prototyping, etc.
 Several techniques can be used to elicit requirements, including:
•Interviews: These are one-on-one conversations with stakeholders to gather
information about their needs and expectations.
•Surveys: These are questionnaires that are distributed to stakeholders to gather
information about their needs and expectations.

2. •Focus Groups: These are small groups of stakeholders who are brought together
to discuss their needs and expectations for the software system.

REQUIRE •Observation: This technique involves observing the stakeholders in their work
environment to gather information about their needs and expectations.
•Prototyping: This technique involves creating a working model of the software
MENTS system, which can be used to gather feedback from stakeholders and to validate
requirements.

ELICITATI
ON
3. REQUIREMENT
SPECIFICATION
 3. REQUIREMENT
SPECIFICATION
1. This activity is used to produce formal software requirement models.
2. All the requirements including the functional as well as the non-functional
requirements and the constraints are specified by these models in totality.
3. During specification, more knowledge about the problem may be required which
can again trigger the elicitation process.
4. The models used at this stage include ER diagrams, data flow diagrams(DFDs),
function decomposition diagrams(FDDs), data dictionaries, etc.
 3. REQUIREMENT
SPECIFICATION
Several types of requirements are commonly specified in this step, including
[Link] Requirements: These describe what the software system should do. They
specify the functionality that the system must provide, such as input validation, data
storage, and user interface.
[Link]-Functional Requirements: These describe how well the software system should do it.
They specify the quality attributes of the system, such as performance, reliability, usability,
and security.
[Link]: These describe any limitations or restrictions that must be considered when
developing the software system.
[Link] Criteria: These describe the conditions that must be met for the software
system to be considered complete and ready for release.
4. REQUIREMENT
VALIDATION AND
VERIFICATION
 4. REQUIREMENT
VALIDATION AND
VERIFICATION
Verification: It refers to the set of tasks that ensures that the software correctly
implements a specific function.
Validation: It refers to a different set of tasks that ensures that the software that has been
built is traceable to customer requirements. If requirements are not validated, errors in the
requirement definitions would propagate to the successive stages resulting in a lot of
modification and rework. The main steps for this process include:
[Link] requirements should be consistent with all the other requirements i.e. no two
requirements should conflict with each other.
[Link] requirements should be complete in every sense.
[Link] requirements should be practically achievable.
5. REQUIREMENT
MANAGEMENT
5. REQUIREMENT
MANAGEMENT
Requirement management is the process of analyzing, documenting,
tracking, prioritizing, and agreeing on the requirement and controlling
the communication with relevant stakeholders.
This stage takes care of the changing nature of requirements. It should
be ensured that the SRS is as modifiable as possible to incorporate
changes in requirements specified by the end users at later stages too.
Modifying the software as per requirements in a systematic and
controlled manner is an extremely important part of the requirements
engineering process.
 5. REQUIREMENT
MANAGEMENT
Several key activities are involved in requirements management, including:
[Link] and controlling changes: This involves monitoring and controlling changes to
the requirements throughout the development process, including identifying the source of
the change, assessing the impact of the change, and approving or rejecting the change.
[Link] control: This involves keeping track of different versions of the requirements
document and other related artifacts.
[Link]: This involves linking the requirements to other elements of the development
process, such as design, testing, and validation.
[Link]: This involves ensuring that the requirements are communicated
effectively to all stakeholders and that any changes or issues are addressed promptly.
[Link] and reporting: This involves monitoring the progress of the development
process and reporting on the status of the requirements.