Software Requirements

 Requirements:-
 Services that user expects from system

 Gathering the requirements-done by

communication with user

 Types of Requirements:-
1. Functional Requirements
2. Non Functional Requirements
 Cont’d….
 Functional Requirements:-
 Describe the functionality of the system.
i.e. features provided by system to satisfy
customer (List of features)
 Should be complete and consistent

 Non-Functional Requirements:-
 Not directly related to the functionality of the
system.
 How features are provided. (Implementation
of those features)
 Cont’d….

 Not needed for users.

 More important than functional

 Types of Non Functional Requirements

1. Product Requirements
2. Organizational Requirements
3. External Requirements
 Cont’d….

1. Product Requirements:-
 Specify that delivered product must behave in a
particular way.
 Ex: Reliability, Efficiency, Performance etc…

2. Organizational Requirements:-
 Specifies the organizational policies and
procedures
 Ex: Process standard and its implementation
 Cont’d….

3. External Requirements:-
 Req. that arise from external process of
system and development process.
 Ex: Interoperability
 Requirements Engineering

 Requirements engineering (RE) is the process

of defining, documenting, and
maintaining requirements in the
engineering design process.

 It is the description of features and

functionalities of the target system.

 It is the description of what the system should

do.

 It is a common role in systems engineering and

software engineering. ... In the waterfall model,
Characteristics of Requirements
Activities/Tasks involved in
requirement Engineering
 Tool support for Requirements
Engineering
 Use cases
 Observation reports (User observation)
 Questionnaires (Interviews and Surveys)
 Prototyping
 Role Playing
 Use case

 Use case is nothing but the system behavior and how the
system behaves as per the end user.

 It describes the system functionality as per the end user.

 Use case diagram represents various business activities

performed in a system.

 Business analysts or Business users will create the use

cases.

 Purpose:- Perform the task & achieve the main goal.

Use Case Diagram
 Cont’d….
 A use case diagram graphically represents what
happens when an actor interacts with a system.
It captures the functional aspect of the system.

 Components of Use Case diagram

1. Actor:- It may be a person, machine, or group of
person or system. A stick figure is used to
represent an actor.

2. Use case:- The actions that a person is going to

perform that actions can be represented in a use
case. An oval is used to represent a use case.

3. A line is used to represent a relationship

Bank ATM
Bank Management System
 Library Management System

 There are 4 actors in this system.

 Multiple use cases, and they are interacting with

system.

 Actors interact with system with help of use

cases.
 Software Engineering Process

 Requirements engineering (RE) is the process

of defining, documenting, and maintaining
requirements in the engineering design
process.

 It is a common role in systems engineering and

software engineering. In the waterfall model,
requirements engineering is presented as the
first phase of the development process.
 Cont’d….

 It is a four step process, which includes –

1. Feasibility Study
2. Requirement Gathering
3. Software Requirement Specification
4. Software Requirement Validation
 Software Requirement
Specification (SRS)

 SRS stands for “Software Requirement Specification”.

 It is a detail description of software system to be

developed with its functional & non functional
requirement.

 It is a document prepared by business analyst or system

analyst.

 It describes what will be the features of software and

what will be its behaviour.
 Cont’d….

 The SRS consists of all necessary requirements

required for the project development.

 In order to get all the details of software from

customer and to write the SRS document, system
analyst is required.

 SRS document is actually an agreements between

the client and developer.
 Characteristics of SRS
document

1. Complete
2. Feasible
3. Modifiable
4. Testable
5. Correct
6. Verifiable
7. Unambiguous
Structure of SRS
SRS document for Online
Student Feedback System
 Cont’d….
1. Introduction

1.1 Purpose
• This document gives detailed functional and non- functional
requirements for online student feedback system. The
purpose of this document is that the requirements
mentioned in it should be utilized by software developers to
implement the system.

1.2 Scope
• This system allows the students to provide quick feedback
which is provided by collage staff.

• The feedback report is generated which is checked by

HOD's. He can view grade obtained to the lecturers.

1.3 Overview
• This system provides an easy solution to collage staff and
students for maintaining feedback related to collage staff
 Cont’d….
2. General Description

• This online student feedback system replaces the

traditional, manual feedback system by which lots of
paper work will be reduced.

• The teachers are able to provide feedback regarding

facility and students are able to provide feedback
easily.

• This is primary feature of this system. Another

feature is that feedback form can be provided to
student and staff by emailing for filling it.

2.1 User Manual

The system should provide Help option in which how to
operate system should be explained. Also hard copy of
 Cont’d….
3. Functional Requirement

3.1 Description

For identity of staff, system should display staff

photograph along with their names for that
corresponding subject and skills.

Statistical report accordingly subject or skill should

display individual's report whenever required.
 Cont’d….
4. Interface Requirement

Student

Student can give the feedback about the lecturers

on the scale of ten. Student can give feedback
about the lecturers based on interaction of lecturer
in the class rooms with students and facility
provided by collage like infrastructure etc.

Staff

The feedback given by students can be viewed by

the staff and improve their performance in teaching
and other aspects
 Cont’d….
Head of Department

The feedback report can be checked by HOD. He

can view overall grades and view the grades
obtained by the lecturers and give report to
principal and he can give counseling to the collage
staff.

4.2 Hardware Interface

The system should be embedded in all desktops.

 Cont’d….
4.3 Software Interface

(i) Online Student Feedback System

(ii) The feedback database transmitted to database

server.

(iii) Report generator

5. Performance Requirements

• The system should work concurrently on multiple

processors between the collage hours.
• The report should be generated immediately
 Cont’d….

6. Design Constraints

The system should be designed within 6 months.

7. Other non-functional attributes

Security: The student and staff should be provided

password to log on to the system.

Reliability: Reliability should be guaranteed due to

wired connectivity. Availability: The system should
be available during college hours.
 Cont’d….

Maintainability: There should be facility to add and

delete feedback form for different purpose.
Reusability: The same system will be used in each
semester.

8. Operational Scenarios : There should be

student database and teacher database. The
student database should contain name and
feedback information.
The teacher database should contain name, subject,
skills, and other details.

9. Preliminary Schedule :
 Feasibility Study

 To find out the current user needs and budget.

 This feasibility study is focused towards goal of the

organization.

 This study analyzes whether the software product can

be practically materialized in terms of implementation,
contribution of project to organization, cost constraints
and as per values and objectives of the organization.

 It explores technical aspects of the project and

product such as usability, maintainability, productivity
 Requirement Gathering /
Elicitation

 Requirements Elicitation is the process to find out

the requirements for an intended software system
by communicating with client, end users, system
users and others who have a stake in the
software system development.

 There are various ways to discover requirements

1.Interviews
2. Surveys
3. Questionnaires
4. Domain Analysis
5. Brainstorming
 Interviews
 Interviews are important way for gathering
requirements. Organization may take various
kinds of interviews such as:

 Oral interviews.

 Written interviews.

 Structured or closed interviews in which

information to be collected from customer in
decided in advance.

 Non-structured or open interviews in which

details needs to be collected from customer are
 Cont’d….

 Face-to-face interviews which are held among two

people across the table.

 Groups of persons are participating in group

interviews. They support to cover any missing
requirement as number of people participates in
this process -conduct
 Surveys

 Organization may perform surveys of different

stakeholders by questioning them about their
requirements and expectation from the proposed
software system.

 The advantage of this technique is that, collecting

requirements is economically beneficial because
it collects requirements from a large number of
persons at same time
 Questionnaires

 Questionnaires are a document which contains

set of objectives that is based on questions and
their options. This document is given to all
stakeholders to give answers of those questions
which are gathered and compiled.

 The advantage of this technique is that, collecting

requirements is economically beneficial because
it collects requirements from persons at the same
time.
 Cont’d….
Domain Analysis:

 Each software is put into some domain category

 The experienced persons in that domain can be a

great support to study general and specific
requirements.

Brainstorming:

 Brainstorming is an informal debate held between

different stakeholders and all their suggestions
are documented for further requirement analysis.
Requirement Engineering
Process
 Requirement Validation
 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.
 Cont’d….

In the requirements validation process, we perform a

different type of test to check the requirements mentioned
in the SRS these checks include:

1. Completeness checks
2. Consistency checks
3. Validity checks
4. Realism checks
5. Ambiguity checks
6. Verifiability