SOFTWARE REQUIREMENTS

 Contents:

 Functional and non-functional requirements

 User requirements
 System requirements
 Interface specification
 The Software Requirements Document

Requirement:

 In software engineering, requirements are the conditions or capabilities that a software system must meet
to satisfy user needs and fulfill the purposes for which it is designed.

 These requirements serve as a foundation for designing, developing, and testing software, ensuring that
the final product meets stakeholders' expectations

Requirements engineering:

The process to gather the software requirements from customers, analyze and document them
is known s requirement engineering.

FUNCTIONAL REQUIREMENTS

 Describe functionality or system services, how the system should react to particular
inputs and how the system should behave in particular situations.
 Requirements should be complete and consistent Complete
 Depend on the type of software, expected users and the type of system where the
software is used
 Functional user requirements may be high-level statements of what the system should
do but functional system requirements should describe the system services in detail.

Finally ,Describe what the software should do, focusing on specific tasks, behaviors, or features it must perform.

NON FUNCTIONAL REQUIREMENTS

 Constraints on the services or functions offered by the system

 Include timing constraints, constraints on the development process and standards.
 Not directly related to functionality of system
 How features are provided
  Not needed for user
 More important than functional requirements.

Finally, Describe how the software should perform, focusing on qualities like speed, security, and usability.

They are 3 types on Non Functional requirements

 Product requirements
• Requirements which specify that the delivered product must behave in a
particular way
e.g. execution speed, reliability, etc.

 Organisational requirements

• Requirements which are a consequence of organizational policies and

procedures
e.g. process standards used, implementation requirements, etc.

 External requirements

• Requirements which arise from factors which are external to the system and its
development process
e.g. interoperability requirements, legislative requirements, etc.

DOMAIN REQUIREMENTS:

 Requirements relate to specific application of the system

 Reflect characteristics and constraints of the system.
Difference between Functional and non functional Requirements

Functional Non Functional

1. Help to understand the functions of the system 1.Help to understand the system
performance

2. Mandatory requirements 2. Not mandatory requirements

3. They are easy to define 3. They are hard to define

4. It concentrate on the users requirement 4. It concentration on the expectation of the user

5. These requirements are specified by the user 5. These are specified by software developers,
Architects and technical persons.

6. Describes what product does 6. Describes how the product works.

7. There is functional testing such as API testing, 7.There is non functional testing such as
System, Integration etc. Usability, performance, security etc
USER REQUIREMENTS:

 Should describe functional and non-functional requirements so that they are

understandable by system users who don’t have detailed technical knowledge

 User requirements are defined using natural language, tables and diagrams.

Problems with natural language

 Lack of clarity

 Precision is difficult without making the document difficult to read

 Requirements confusion

 Functional and non-functional requirements tend to be mixed-up

 Several different requirements may be expressed together

For Example: Suppose you are a web developer and user ask you to create a website of his
company. For that he has to give some requirements which he wants from this website.

So user requirements are those which user wants from the system.

SYSTEM REQUIREMENTS

 More detailed specifications of user requirements

 Serve as a basis for designing the system
 May be used as part of the system contract
 System requirements may be expressed using system models

For Example: If we’re talking about a game that you play on your computer or phone, a
system requirement could be something like this:

“ The game needs to be able to run smoothly on computers with at least 4GB of RAM and
a graphics card that support direct 11”
 INTERFACE SPECIFICATION

 Interface specification in software requirements is a detailed description of how

different parts of a software system or external systems will communicate with
each other.

 It defines the data they will exchange, the rules for communication, and how they
will work together.

 In simple terms, it's like a "contract" that explains how one part of the system talks to
another, ensuring they understand each other and work smoothly. For example, it
might specify that one part of the system sends data in a certain format, and the other
part receives it and processes it correctly.

 Most systems must operate with other systems and the operating interfaces must
be specified as part of the requirements

 Three types of interface may have to be defined

 Procedural interfaces
 Data structures that are exchanged
 Data representations

1. Procedural Interfaces

These define the functions or procedures that one module can call in another module.

It specifies the name of the function, the parameters (inputs) it accepts, and the output
it returns.

It is the most common type of interface in programming.

Example:

int add(int a, int b); //

Function that takes two integers and returns their sum

2. Data Structures That Are Exchanged

These are the complex data formats or objects shared between modules.

Instead of passing simple values (like integers or strings), modules may exchange
structs, arrays, lists, or classes.
 The structure must be clearly defined so both modules understand it.

Example:

struct Student {
int id;
char name[50];
float marks;
};

3. Data Representations

This specifies how the data is stored, formatted, or encoded when exchanged.

Important when systems are built on different platforms (e.g., 32-bit vs 64-bit) or
languages (like C++ vs Python).

Example:

Sending data in JSON format:

{ "id": 101, "name": "John", "marks": 85.5 }

These three types of interfaces help ensure that modules communicate correctly and that data is shared
accurately between different parts of a software system

SOFTWARE REQUIREMENTS DOCUMENT

A Software Requirements Document is a formal document that explains what the software
system should do. It includes all the features, functions, and constraints of the software
that needs to be built.
 It is prepared after talking with the client or user to understand their needs. This document helps
everyone involved in the
project — developers, testers, designers, and
clients — to understand the system clearly.

Why is SRD Important?

It acts as a blueprint for the software project.

It helps to avoid misunderstandings between the client and the development team.

It allows for planning, designing, coding, and testing in a more organized way.

 The requirements document is the official statement of what is required of the

systemdevelopers

 Should include both a definition and a specification of requirements

 It is NOT a design document. As far as possible, it should set of WHAT the system
should do rather than HOW it should do it

There are 6 requirements it should satisfy!

 Specify external system behavior

 Specify implementation constraints
 Easy to change
 Serve as reference tool for maintenance
 Record forethought about the life cycle of the system i.e. predict changes
 Characterize responses to unexpected events

Purpose of SRS:

 Communication between the customer, Analyst, System developers, Maintainers.

 Firm Foundation for design phase
 Support system testing activities
 Support project management and control
 Controlling the evaluation of the system.
 IEEE requirements standard

 Introduction
 General description
 Specific requirements
 Appendices
 Index
 This is a generic structure that must be instantiated for specific systems

Conclusion: The SRD is the Foundation of the entire software development process. A well written SRD
ensures that the final software meets the users expectations and works correctly.

Users of a requirements document

USERS VS SYSTEM REQUIREMENTS

USERS SYSTEM

1. Written for customers 1. Written for implementation team

2. In Natural Language 2. In Technical language.

3. May include Diagrams and Tables 3. May include system models

4. Understandable by system users who 4. Understandable by implementation

Don’t have technical knowledge, team who have technical knowledge.
REQUIREMENTS ENGINEERING PROCESSES (REP)

Objectives

The objective of this chapter is to discuss the activities involved in the requirements
engineering process. When you study this chapter, you will:

 Understand the principal requirements of engineering activities and their relationships;

 Have been introduced to several techniques of requirements elicitation and analysis;

 understand the importance of requirements validation and how requirements

reviews are used in this process;

 understand why requirements management is necessary and how it supports

other requirements engineering activities.

Defination:

The process to gather the software requirements from customers analyze and document them is known as
Requirement engineering.

Requirement engineering processes vary widely depending on

• The application domain

• The people involved and
• The organization developing the requirements

However, there are a number of generic activities common to all processes

1. Feasibility studies

2. Requirements elicitation and analysis

3. Software requirement specification

4. Software Requirements validation

5. Software Requirements management

1. FEASIBILITY STUDY

 A feasibility study decides whether or not the proposed system is worthwhile

 A short focused study that checks
• If the system contributes to organizational objectives
• If the system can be engineered using current technology and within budget
• If the system can be integrated with other existing systems

Feasibility study implementation

 Based on information assessment (what is required), information collection and

report writing
 Questions for people in the organization
• What if the system wasn’t implemented?
• What are current process problems?
• How will the proposed system help?
• What will be the integration problems?
• Is new technology needed? What skills?
• What facilities must be supported by the proposed system?
 Feasibility study report

1. To create and analyze the reasons for developing the software that is acceptable to users

2. To check aim and goal of the customer and organization behind implementation of
software.

Types of feasibility study:

1. Technical Feasibility:

Evaluates the current technologies which are needed to achieve customer requirements within the time
and budget.

2. Operational Feasibility:

Required software solve business problems and customer requirements.

3. Economic feasibility:

It decides whether the necessary software can generate financial profits for an organization.

The output is to decide whether or not the project should be undertaken.

2.REQUIREMENTS ELICITATION AND ANALYSIS:

 Requirement elicitation is the process of gathering actual requirements about needs and
expectations of stake holders for a software system.

 To understand customers, business manuals the existing software of same type, standards and
other stakeholders of the project.

ELICITATION CHALENGES:

 Identification of problem scope

 Identification of stake holders

 Understanding of problems

 Clear information about all requirements

Requirements Discovery or Elicitation:

1. This is the process of interacting with stakeholders of the system to discover their requirements.
2. Domain requirements from stakeholders and documentation are alos discovered during this
activity.

Requirements classification and Organization:

1. This activity takes the unstructured collection of requirements group related requirements and
organizes them in to coherent clusters.
2. The most common way of grouping requirements to use a model of the system architecture to
identify sub systems and to associate requirements with each sub system.

Requirements prioritization and Negotiation:

1. Inevitably, when multiple stakeholders are involved requirements will conflict.

2. This activity is concerned with prior zing requirements and finding the resolving requirements
conflict through negotiation.
3. Usually, stake holders have to meet to resolve differences and agree on compromise
requirements.

Requirements Specification:

1.The requirements and documented and input to the next round of spiral formal or informal
requirements documents may be produced.

Techniques of Requirements Elicitation:

1. Interviews: One – on – one conversations with stakeholders to gather information about their
needs and expectations.

2. Surveys : these are questionnaires that are distributed to stake holders to gather information.

3. Focus Groups: Small groups of stake holders who are brought together to discuss their needs.

4. Observation: Observing the stakeholders in their work environment to gather information.

5. Prototyping: Creating a working model of the software system, which can be used to gather
feedback from stakeholders and to validate requirements.

3.Software requirement specification(SRS):

 Requirements received from Clint are written in natural language.

 After collecting system analyst to document the requirements in technical language.
  SRS include data flow diagram dictionary, entity relationship diagram.

SRS Defines:
1. How the intended software will interact with hardware
2. External interface/GUI
3. Speed of operation, Response time of system
4. Portability of software across various platforms.
5. Maintainability
6. Speed of recovery after cresting
7. Security quality, limitations etc

4.Software Requirements validation:

 After SRS developed , the requirements discussed in this document are validated or
tested.

 Requirement validation done through requirement review taken by customers, after

developing prototyping check with customers and test case genarations.

Requirements can be check against the following conditions:

1. If they can practically implement.

2. If they are correct and as per the functionality and specially of software

3. If there are any ambiguities.

4. If they can describe.

5. Any changing or additional requirement.

5.Software Requirement Management (SRM) :

 Requirements management is the process of managing changing requirements

during the requirements engineering process and system development

 Requirements are inevitably incomplete and inconsistent

• New requirements emerge during the process as business needs change and a
better understanding of the system is developed
• Different viewpoints have different requirements and these are often contradictory
Why requirements change

 The priority of requirements from different viewpoints changes during the

development process
 System customers may specify requirements from a business perspective that
conflict with end-user requirements
 The business and technical environment of the system changes during its development

Activities involved in SRM:

1.Tracking & Controlling changes: Handling changing requirements from customers.

2.Version control: Keeping track of different versions of system.

3.Traceability : Trace to software is design, develop or test as per requirements or not.

4.Communication: If changing requirements has any issues contact with clients within time.

5.Monitoring & Reporting: Monitoring development process and report the status.