UNIT-2

Chapter-1: Software Requirements

Functional and Non-Functional Requirements:
Software Requirements:
According to IEEE standard 729, a requirement is defined as follows:
 A condition or capability needed by a user to solve a problem or achieve an objective
 A condition or capability that must be met or possessed by a system or system
component to satisfy a contract, standard, specification or other formally imposed
documents
Requirements should be clear, correct and well defined.
Types of Requirements:
There are two types of Requirements.
 Functional requirements
 Non-functional requirements
Functional Requirements:
Functional requirements are statements or goals used to define system behavior.
Functional requirements define what a software system must do or not do. They are
typically expressed as responses to inputs or conditions.
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,
unlike the non-functional requirements.
For example, in a hospital management system, a doctor should be able to retrieve
the information of his patients.
There are many ways of expressing functional requirements e.g., natural language,
a structured or formatted language with no rigorous syntax and formal specification
language with proper syntax. Functional Requirements in Software Engineering are also
called Functional Specification.
Nonfunctional requirements:
Nonfunctional requirements relate to software usability. Nonfunctional software
requirements define how the system must operate or perform. A system can meet its
functional requirements and fail to meet its nonfunctional requirements.
Requirements are expected characteristics of target software.(security, storage,
configuration, performance, cost, flexibility, recovery, accessability)
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.
 Portability: Describe the ease with which the software can be transferred from one
platform to another. For example, it should be easy to port the software to a
different operating system without the need to redesign the entire software.
 Security: the concept of implementing mechanisms in the construction of security to
help it remain functional (or resistant) to attacks. (Provide security from attacks)
 Maintainability: The ease with which a software system or component can be
modified to correct faults, improve performance or other attributes, or adapt to a
changed environment."
 Reliability: Describe the acceptable failure rate of the software. For example, the
software should be able to operate even if a hazard(failure) occurs.
  Scalability: scalability is the ability to grow or shrink a piece of software to meet
changing demands on a business.
 Performance: (speed, accuracy) performance measures how effective is a software
system with respect to time constraints and allocation of resources.
 Reusability: The ease with which the product or portions of the product can be reused
in the development of other systems
 Flexibility: Flexibility in software engineering is the ability of the system to respond
to uncertainty in a way that allows it to function normally.
Difference between Functional and Nonfunctional Requirements:
Functional Requirements Non Functional Requirements

A functional requirement
A non-functional requirement defines the
defines a system or its
quality attribute of a software system.
component.

It places constraints on “How should the

It specifies “What should the
software system fulfill the functional
software system do?”
requirements?” like quality and performance

Non-functional requirement is specified by

Functional requirement is
technical peoples e.g. Architect, Technical
specified by User.
leaders and software developers.

It is mandatory. It is not mandatory.

It is captured in use case. It is captured as a quality attribute.

Defined at a component level. Applied to a system as a whole.

Helps you verify the Helps you to verify the performance of the
functionality of the software. software.

Functional Testing like System, Non-Functional Testing like Performance,

Integration, End to End, API Stress, Usability, Security testing, etc are
testing, etc are done. done.

Usually easy to define. Usually more difficult to define.

What Is a Software Requirements Specification (SRS) Document?

 A software requirements specification (SRS) is a document that describes what the
software will do and how it will be expected to perform. Behavior of system,
Functional and Non- Functional rerquirements of system
 SRS is a formal report, that enables the customer to review whether it(SRS) is
according to their requirement.
  It is usually signed off at the end of requirements engineering phase
Users of SRS Document:
 Client
 Development team
 Maintenance team
 Technical team
Need/use of SRS Document:
1. It structure and formalizes all project requirements.
2. It help the development team build a product that exactly customer and target
audience needs
3. It provides all team members with the necessary information while working on the
project
4. It minimizes the possible misunderstanding between the members of the development
team and the customer.
5. It clearly defines the scope of work, and that allows developers to plan particular
iterations and release dates.
6. It allows estimating the required development budget
Structure of SRS Document:
Creating a clear and effective SRS document can be difficult and time-consuming.
But it is critical to the efficient development of a high quality product that meets the needs of
business users.
Here are five steps you can follow to write an effective SRS document.
1. Introduction
1.1 Purpose
1.2 Intended Audience
1.3 Scope
1.4 Definitions
1.5 References
2. Overall Description
2.1 User interface
2.2 system interface
2.3 Software and hardware requirements.
2.4 Constraints.
2.5 User characteristics
3. System Features and Requirements
3.1 Functional Requirements
3.2 External Interface Requirements
3.3 Database requirements
1.4 Non-functional Requirements
1.5 Use-case/sequence diagram
4 . Detail Your Specific Requirements
In order for your development team to meet the requirements properly, we must include as
much detail as possible. This can feel overwhelming but becomes easier as you break down
your requirements into categories. Some common categories are functional requirements,
interface requirements, system features, and various types of non-functional requirements:
5. Deliver for Approval
Characteristics of good SRS Document:

1. Correctness:
Provide accurate functional and non-functional requirements as discussed with client
2. Completeness:
Should complete all essential features like functionality, performance, features ,
design, constraints and external interfaces.
3. Consistency:
Same abbreviation, tabular format, diagram format, naming format follow.
4. Unambiguousness:
should not be confusion regarding understanding of the requirements. Everything
mention uniquely and clearly
5. Ranking for importance and stability:
There should a criterion to classify the requirements as less or more important or more
specifically as desirable or essential. An identifier mark can be used with every
requirement to indicate its rank or stability.
6. Modifiability:
SRS should be made as modifiable as possible and should be capable of easily
accepting changes to the system to some extent. Modifications should be properly
indexed and cross-referenced.
7. Verifiability:
The requirements are verified with the help of reviewers and stake holders
8. Traceability:
Every requirement having unique number that is easy to use in future development
9. Design Independence:
There should be an option to choose from multiple design alternatives for the final
system. More specifically, the SRS should not include any implementation details.
10. Testability:
A SRS should be written in such a way that it is easy to generate test cases and test
plans from the document.
11. Understandable by the customer:
The language should be kept easy and clear.
12. Right level of abstraction:
If the SRS is written for the requirements phase, the details should be explained
 explicitly. Whereas, for a feasibility study, fewer details can be used. Hence, the level
of abstraction varies according to the purpose of the SRS.
Chapter-2
Requirement engineering process:
Requirements engineering (RE) refers to the process of defining, documenting, and
maintaining requirements in the engineering design process.
The process to gather the software requirements from customer, analyse and
document them is known as requirement engineering
Requirement Engineering Process
It is a four-step process, which includes -
Feasibility Study
1. Requirement Elicitation and Analysis
2. Software Requirement Specification
3. Software Requirement Validation
4. Software Requirement Management

Feasibility Study:
The objective behind the feasibility study is to create the reasons for developing the software
that is acceptable to users.
To check aim and goal of the customer and organization behind implementation of software.
Types of Feasibility:
1. Technical Feasibility - Technical feasibility evaluates the current technologies, which
are needed to achieve customer requirements within the time and budget.
2. Operational Feasibility - Operational feasibility assesses required software solve
business problems and customer requirements.
3. Economic Feasibility - Economic feasibility decides whether the necessary software can
generate financial profits for an organization.
1. Requirement Elicitation and Analysis:
Requirements elicitation is the process of gathering actual requirements about the
needs and expectations of stakeholders/customer for a software system
Analysis of requirements starts with requirement elicitation. The requirements are analysed to
identify inconsistencies, defects, omission, etc. We describe requirements in terms of
relationships and also resolve conflicts if any.
Techniques of Requirement Elicitation:
Interview: one-to-one conversation with stakeholders to gather information about their needs
and expectations
Survey: These are questionnaire that are distributed to stakeholders to gather information.
Focus groups: small groups of stakeholders who are brought together to discuss their needs
Observation: Observing the stakeholders in their work environment to gather information
Prototyping: Creating a work model of the software system, which can be used to gather
feedback from customers an to validate requirements
Problems of Elicitation and Analysis
o Getting all, and only, the right people involved.
o Stakeholders often don't know what they want
o Stakeholders express requirements in their terms.
o Stakeholders may have conflicting requirements.
o Requirement change during the analysis process.
o Organizational and political factors may influence system requirements.
2. Software Requirement Specification:
Software requirement specification is a kind of document which is created by a
software analyst after the requirements collected from the various sources - the requirement
received by the customer written in ordinary language. It is the job of the analyst to write the
requirement in technical language so that they can be understood and beneficial by the
development team.
SRS include ER diagrams, data flow diagrams (DFDs), function decomposition diagrams
(FDDs), data dictionaries, etc.
o Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the
requirements. DFD shows the flow of data through a system. The system may be a
company, an organization, a set of procedures, a computer hardware system, a
software system, or any combination of the preceding. The DFD is also known as a
data flow graph or bubble chart.
o Data Dictionaries: Data Dictionaries are simply repositories to store information
about all data items defined in DFDs. At the requirements stage, the data dictionary
should at least define customer data items, to ensure that the customer and developers
use the same definition and terminologies.
o Entity-Relationship Diagrams: Another tool for requirement specification is the
entity-relationship diagram, often called an "E-R diagram." It is a detailed logical
representation of the data for the organization and uses three main constructs i.e. data
entities, relationships, and their associated attributes.
3. Software Requirement Validation:
After Software requirement specifications (SRS) developed, the requirements
discussed in this document are validated or tested.
Requirements reviews taken by the customer, After developing prototyping check
with customer and test case generation.
Requirements can be the check against the following conditions -
o If they can practically implement
o If they are correct and as per the functionality and specially of software
o If there are any ambiguities
o If they are full
o If they can describe
Requirements Validation Techniques
o Requirements reviews/inspections: systematic manual analysis of the requirements.
o Prototyping: Using an executable model of the system to check requirements.
o Test-case generation: Developing tests for requirements to check testability.
o Automated consistency analysis: checking for the consistency of structured
requirements descriptions.
4. Software Requirement Management:
Requirement management is the process of managing changing requirements during the
requirements engineering process and system development.
Activities in Requirement Management:
Tracking and controlling changes: Handling changing requirements from the customer.
Version control: Keeping track of different version of system
Traceability: Trace to software is design, develop or test as per requirements or not
Communication: If changing requirements has any issues contact with clients within time
Monitoring and reporting: Monitoring development process and report the status

System Model in Software Engineering:

Software engineering solutions are initiated from conceptualization to software
implementation using system models. System models improve the quality of software
development.
“A system model is a visual representation of the interaction between
elements of a system or software”
A system model typically contains elements such as inputs, processes, outputs, and entities.
Types of System Models
 Context models
 Behavioral Models
 Data models
 Object models
 Structural model

Behavioral Model in Software Engineering

The behavioral model is a key concept in software engineering. It is a representation of the
expected behavior of a given system, including how it interacts with other systems. By using
behavioral models, developers can analyze the behavior of a system, predict how it will
behave under different conditions, debug software, and optimize performance.
Behavioral modeling in software engineering refers to the process of creating models that
predict and describe the behavior of software systems. The primary goal of behavioral
modeling is to provide developers with a clear understanding of how a software system will
function under different conditions.
Types of Behavioral Models
State Machine Model
The state machine model is a behavioral model that describes the behavior of a system by
specifying a finite set of states that it may be in at any given time and the transitions between
those states.
Activity Model
The activity model is a behavioral model that describes the dynamic behavior of a system by
showing how its elements interact with each other over a period of time. It is used to model
complex business processes and workflows.
Use Case Model
The use case model is a behavioral model that describes the interactions between a system
and its users or other systems. It consists of a set of use cases, each of which describes a
specific interaction between the system and its environment.
State Machine Model
It’s a behavioral diagram and it represents the behavior using finite state transitions. State
diagrams are also referred to as State machines and State-chart Diagrams.
A state chart diagram in software engineering is a visual representation of the state and
behavior of an object or system. It is used to model complex systems and processes in order
to analyze, modify, or improve their functionality. This document will explore the
components of a state chart diagram and provide examples of its use in software engineering.
.
Basic components of a statechart diagram –
1. Initial state – We use a black filled circle represent the initial state of a System or a
class.

Figure – initial state notation

2. Transition – We use a solid arrow to represent the transition or change of control from
one state to another. The arrow is labelled with the event which causes the change in
state.

Figure – transition
3. State – We use a rounded rectangle to represent a state. A state represents the conditions
or circumstances of an object of a class at an instant of time.

Figure – a diagram using join notation

4. Self transition – We use a solid arrow pointing back to the state itself to represent a self
transition. There might be scenarios when the state of the object does not change upon
the occurrence of an event. We use self transitions to represent such cases.

Figure – self transition notation

5. Final state – We use a filled circle within a circle notation to represent the final state in
a state machine diagram.

Figure – final state notation

Steps to draw a state diagram –
1. Identify the initial state and the final terminating states.
2. Identify the possible states in which the object can exist (boundary values corresponding
to different attributes guide us in identifying different states).
3. Label the events which trigger these transitions.

Examples of State Chart Diagrams (Make a Phone Call)

A state chart diagram of a phone call can provide insights into its functionality. Some of the
examples of state chart diagrams are:
 Idle state
 Ringing state
 Active state
  Hold state
 Conference call state
An example state chart diagram of a phone call.
The state chart diagram of a phone call can help in understanding the call's behavior.
In the Idle state, the phone is waiting for a call. When someone calls, the phone goes
into the Ringing state. If the call is accepted, it goes into the Active state. If the person
receiving the call puts it on hold, the hold state is entered. Finally, the call can be
made into a conference call state where multiple people can join the call.
State chart Diagram for Telephone Call Receiving

Ringing When phone pick up Received

When Call comes

Another Call coming While talking

Start Idle
Start
Waiting First Call ends Connected

Call ends

Stop

Activity diagram
Activity diagram is basically a flowchart to represent the flow from one activity to another
activity. The activity can be described as an operation of the system.
An activity diagram visually presents a series of actions or flow of control in a system
similar to a flowchart or a data flow diagram. Activity diagrams are often used in business
process modeling. They can also describe the steps in a use case diagram. Activities modeled
can be sequential and concurrent. In both cases an activity diagram will have a beginning (an
initial state) and an end (a final state).
Basic Activity Diagram Notations and Symbols
Initial State or Start Point
A small filled circle followed by an arrow represents the initial action state or the start point
for any activity diagram. For activity diagram using swimlanes, make sure the start point is
placed in the top left corner of the first column.

Activity or Action State

An action state represents the non-interruptible action of objects. You can draw an action
state in SmartDraw using a rectangle with rounded corners.

Action Flow
Action flows, also called edges and paths, illustrate the transitions from one action state to
another. They are usually drawn with an arrowed line.
Decisions and Branching
A diamond represents a decision with alternate paths. When an activity requires a decision
prior to moving on to the next activity, add a diamond between the two activities. The
outgoing alternates should be labeled with a condition or guard expression. You can also
label one of the paths "else."

Guards
In UML, guards are a statement written next to a decision diamond that must be true before
moving next to the next activity. These are not essential, but are useful when a specific
answer, such as "Yes, three labels are printed," is needed before moving forward.

Final State or End Point

An arrow pointing to a filled circle nested inside another circle represents the final action
state.
Back to top
 ACTIVITY DIAGRAM FOR MONEY TRANSFER

Start

Enter uid and

pwd

valid check
Prompt for
Invalid Re-Entry

Enter user
Acct.No.

End
check1
Main Menu
valid

Invalid

Re-Enter
Acct.No.
Select Money
Transfer

Enter Dest.
Acct.No

Invalid
checking
Enter Amt.to
valid Transfer

Activity

Diagram for Library Management System

 ACTIVITY DIAGRAM FOR BALANCE ENQUIRY

Start

Enter uid and

pwd

valid check
Prompt for
Invalid Re-Entry

Enter Acct.No.

End
check1
Main Menu
valid

Invalid

Re-Enter
Acct.No.
Select Balance
Enquiry

Use-case diagrams
Use-case diagrams describe the high-level functions and scope of a system. These
diagrams also identify the interactions between the system and its actors. The use cases
and actors in use-case diagrams describe what the system does and how the actors use it, but
not how the system operates internally.

Notations of use case daigram

`
UML use case diagrams are ideal for:
  Representing the goals of system-user interactions
 Defining and organizing functional requirements in a system
 Specifying the context and requirements of a system
 Modeling the basic flow of events in a use case

Data Model:
Data Flow Diagram
In software engineering, a data flow diagram (DFD) is a visual representation of the flow of
data within a system. It allows developers to understand the system at a high level and plan
changes or improvements.
What is a Data Flow Diagram?
.
DFD is graphical representation which provides information flow and transformation
between input, processed and output
DFD shows the movement of data through different transformation on process in the system
It is also known as bubble chart / data flow graph
Components/Notations of Data Flow Diagrams
Process
A function that transforms data from input to output.
Data Store
A repository of data that persists over time.
External Entity
Represents a source or destination of data outside the scope of the system.
Data Flow
The movement of data from one component to another.