UNIT 4: Requirement Analysis and Specification
Understanding the Requirement,
Requirement Modeling,
Requirement Specification (SRS),
Requirement Analysis and
Requirement Elicitation,
Requirement Engineering.
Q) Requirements (GTU IMP)
Requirements analysis is a very critical process that enables the success of a system.
Requirements are generally split into two types:
1.Functional
2.Non-functional requirements.
Functional Requirements:
These are the requirements that the end user specifically demands as basic facilities that the
system should offer.
They are basically the requirements stated by the user which one can see directly in the final
product.
Non-functional requirements:
The priority or extent to which these factors are implemented varies from one project to other.
They are also called non-behavioral requirements.
They basically deal with issues like:
● Portability
● Security
● Maintainability
● Reliability
● Scalability
● Performance
● Following are the differences between Functional and Non Functional Requirements
Functional Requirements Non Functional Requirements
A non-functional requirement defines
A functional requirement defines a
the quality attribute of a software
system or its component.
system.
Non-functional requirement is
Functional requirement is specified specified by technical peoples e.g.
by User. Architect, Technical 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 functionality of Helps you to verify the performance
the software. of the software.
Functional Testing like System, Non-Functional Testing like
Integration, End to End, API testing, Performance, Stress, Usability,
etc are done. Security testing, etc are done.
Usually easy to define. Usually more difficult to define.
Example
Example
1) Emails should be sent with a
1) Authentication of user whenever
latency of no greater than 12 hours
he/she logs into the system.
from such an activity.
2) System shutdown in case of a
2) The processing of each request
cyber attack.
should be done within 10 seconds
3) A Verification email is sent to user
3) The site should load in 3 seconds
whenever he/she registers for the first
when the number of simultaneous
time on some software system.
users are > 10000
Q) Requirement engineering Task (GTU IMP)
Requirement engineering consists of seven different tasks as follow:
1. Inception
● Inception is a task where the requirement engineering asks a set of questions to establish
a software process.
● In this task, it understands the problem and evaluates with the proper solution.
● It collaborates with the relationship between the customer and the developer.
● The developer and customer decide the overall scope and the nature of the question.
2. Elicitation
Elicitation means to find the requirements from anybody.
The requirements are difficult because the following problems occur in elicitation.
Problem of scope: The customer gives unnecessary technical detail rather than clarity of the
overall system objective.
Problem of understanding: Poor understanding between the customer and the developer
regarding various aspects of the project like capability, limitation of the computing environment.
Problem of volatility: In this problem, the requirements change from time to time and it is
difficult while developing the project.
3. Elaboration
● In this task, the information taken from the user during inception and elaboration and are
expanded and refined in elaboration.
● Its main task is developing a pure model of software using functions, features and
constraints of a software.
4. Negotiation
● In a negotiation task, a software engineer decides how the project will be achieved with
limited business resources.
● To create rough guesses of development and assess the impact of the requirement on the
project cost and delivery time.
5. Specification
● In this task, the requirement engineer constructs a final work product.
● The work product is in the form of software requirement specification.
● In this task, formalize the requirements of the proposed software such as informative,
functional and behavioral.
● The requirements are formalized in both graphical and textual formats.
6. Validation
● The work product is built as an output of the requirement engineering and that is
accessed for the quality through a validation step.
● The formal technical reviews from the software engineer, customer and other
stakeholders helps for the primary requirements validation mechanism.
7. Requirement management
● It is a set of activities that help the project team to identify, control and track the
requirements and changes can be made to the requirements at any time of the ongoing
project.
● These tasks start with the identification and assign a unique identifier to each of the
requirements.
● After finalizing the requirement, a traceability table is developed.
● The examples of traceability tables are the features, sources, dependencies, subsystems
and interface of the requirement.
Q) Eliciting Requirements
Eliciting requirement helps the user for collecting the requirement
Eliciting requirement steps are as follows:
1. Collaborative requirements gathering
● Gathering the requirements by conducting the meetings between developer and
customer.
● Fix the rules for preparation and participation.
● The main motive is to identify the problem, give the solutions for the elements,
negotiate the different approaches and specify the primary set of solution requirements
in an environment which is valuable for achieving goal.
2. Quality Function Deployment (QFD)
● In this technique, translate the customer need into the technical requirement for the
software.
● QFD system designs a software according to the demands of the customer.
QFD consist of three types of requirement:
Normal requirements
● The objective and goal are stated for the system through the meetings with the customer.
● For the customer satisfaction these requirements should be there.
Expected requirement
● These requirements are implicit.
● These are the basic requirement that not be clearly told by the customer, but also the
customer expect that requirement.
Exciting requirements
● These features are beyond the expectation of the customer.
● The developer adds some additional features or unexpected feature into the software to
make the customer more satisfied.
For example, the mobile phone with standard features, but the developer adds few
additional functionalities like voice searching, multi-touch screen etc. then the customer
more exited about that feature.
3. Usage scenarios
● Till the software team does not understand how the features and function are used by the
end users it is difficult to move technical activities.
● To achieve above problem the software team produces a set of structure that identify the
usage for the software.
● This structure is called as 'Use Cases'.
4. Elicitation work product
● The work product created as a result of requirement elicitation that is depending on the
size of the system or product to be built.
● The work product consists of a statement need, feasibility, statement scope for the
system.
● It also consists of a list of users participate in the requirement elicitation.
Q)Elements of the analysis model
1. Scenario based element
● This type of element represents the system user point of view.
● Scenario based elements are use case diagram, user stories.
2. Class based elements
● The object of this type of element manipulated by the system.
● It defines the object,attributes and relationship.
● The collaboration is occurring between the classes.
● Class based elements are the class diagram, collaboration diagram.
3. Behavioral elements
● Behavioral elements represent state of the system and how it is changed by the external
events.
● The behavioral elements are sequenced diagram, state diagram.
4. Flow oriented elements
● An information flows through a computer-based system it gets transformed.
● It shows how the data objects are transformed while they flow between the various
system functions.
● The flow elements are data flow diagram, control flow diagram.
Q)Software Requirement Specification (SRS)
● The requirements are specified in specific format known as SRS.
● This document is created before starting the development work.
● The software requirement specification is an official document.
● It shows the detail about the performance of expected system.
● SRS indicates to a developer and a customer what is implemented in the software.
Example of SRS ON flight management:
1. INTRODUCTION
1.1 PURPOSE
The purpose of this document is to build an online system to manage flights and passengers to
ease the flight management. <<Include the purpose as applicable to your project >>
1.2 DOCUMENT CONVENTIONS
This document uses the following conventions. <<Include the conventions as per your
application >>
DB Database
DDB Distributed Database
ER Entity Relationship
1.3 INTENDED AUDIENCE AND READING SUGGESTIONS
This project is a prototype for the flight management system and it is restricted within the college
premises. This has been implemented under the guidance of college professors. This project is
useful for the flight management team and as well as to the passengers.
1.4 PROJECT SCOPE
The purpose of the online flight management system is to ease flight management and to create a
convenient and easy-to-use application for passengers, trying to buy airline tickets. The system is
based on a relational database with its flight management and reservation functions. We will
have a database server supporting hundreds of major cities around the world as well as thousands
of flights by various airline companies. Above all, we hope to provide a comfortable user
experience along with the best pricing available.
1.5 REFERENCES
● https://krazytech.com/projects
● Fundamentals of database systems by ramez elmarsi and shamkant b.navathe
2. OVERALL DESCRIPTION
2.1 PRODUCT PERSPECTIVE
A distributed airline database system stores the following information.
● Flight details:
It includes the originating flight terminal and destination terminal, along with the
stops in between, the number of seats booked/available seats between two
destinations etc.
● Customer description:
It includes customer code, name, address and phone number. This information
may be used for keeping the records of the customer for any emergency or for any
other kind of information.
● Reservation description:
It includes customer details, code number, flight number, date of booking, date of
travel.
2.2 PRODUCT FEATURES
The major features of airline database system as shown in below entity–relationship model (ER
model)
The diagram shows the layout of airline database system – entity–relationship model
2.3 USER CLASS and CHARACTERISTICS
Users of the system should be able to retrieve flight information between two given cities with
the given date/time of travel from the database. A route from city A to city B is a sequence of
connecting flights from A to B such that: a) there are at most two connecting stops, excluding the
starting city and destination city of the trip, b) the connecting time is between one to two hours.
The system will support two types of user privileges, Customer, and Employee. Customers will
have access to customer functions, and the employees will have access to both customer and
flight management functions. The customer should be able to do the following functions:
● Make a new reservation
• One-way
• Round-Trip
• Multi-city
• Flexible Date/time
• Confirmation
● Cancel an existing reservation
● View his itinerary
The Employee should have following management functionalities:
● CUSTOMER FUNCTIONS.
• Get all customers who have seats reserved on a given flight.
• Get all flights for a given airport.
• View flight schedule.
• Get all flights whose arrival and departure times are on time/delayed.
• Calculate total sales for a given flight.
● ADMINISTRATIVE
• Add/Delete a flight
• Add a new airport
• Update fare for flights.
• Add a new flight leg instance.
• Update departure/arrival times for flight leg instances.
Each flight has a limited number of available seats. There are a number of flights which depart
from or arrive at different cities on different dates and time.
2.4 OPERATING ENVIRONMENT
Operating environment for the airline management system is as listed below. <<Include the
details as per your application >>
● distributed database
● client/server system
● Operating system: Windows.
● database: sql+ database
● platform: vb.net/Java/PHP
●
2.5 DESIGN and IMPLEMENTATION CONSTRAINTS
1. The global schema, fragmentation schema, and allocation schema.
2. SQL commands for above queries/applications
3. How the response for application 1 and 2 will be generated. Assuming these are
global queries. Explain how various fragments will be combined to do so.
4. Implement the database at least using a centralized database management system.
5.
2.6 ASSUMPTION DEPENDENCIES
Let us assume that this is a distributed airline management system and it is used in the following
application:
● A request for booking/cancellation of a flight from any source to any destination,
giving connected flights in case no direct flight between the specified Source-
Destination pair exist.
● Calculation of high fliers (most frequent fliers) and calculating appropriate reward
points for these fliers.
Assuming both the transactions are single transactions, we have designed a distributed database
that is geographically dispersed at four cities Delhi, Mumbai, Chennai, and Kolkatta as shown in
fig. Below.
3. SYSTEM FEATURES
● DESCRIPTION and PRIORITY
The airline reservation system maintains information on flights, classes of seats, personal
preferences, prices, and bookings. Of course, this project has a high priority because it is very
difficult to travel across countries without prior reservations.
● STIMULUS/RESPONSE SEQUENCES
● Search for Airline Flights for two Travel cities
● Displays a detailed list of available flights and make a “Reservation”
or Book a ticket on a particular flight.
● Cancel an existing Reservation.
● FUNCTIONAL REQUIREMENTS
Other system features include:
DISTRIBUTED DATABASE:
Distributed database implies that a single application should be able to operate transparently on
data that is spread across a variety of different databases and connected by a communication
network as shown in below figure.
Distributed database
located in four different cities
CLIENT/SERVER SYSTEM
The term client/server refers primarily to an architecture or logical division of responsibilities,
the client is the application (also known as the front-end), and the server is the DBMS (also
known as the back-end).
A client/server system is a distributed system in which,
● Some sites are client sites and others are server sites.
● All the data resides at the server sites.
● All applications execute at the client sites.
●
4. EXTERNAL INTERFACE REQUIREMENTS
4.1 USER INTERFACES
● Front-end software: Vb.net version
● Back-end software: SQL+
4.2 HARDWARE INTERFACES
● Windows.
● A browser which supports CGI, HTML & Javascript.
4.3 SOFTWARE INTERFACES
Following are the software used for the flight management online application. <<Include the
software details as per your project >>
Software used Description
Operating system We have chosen Windows operating system for its best
support and user-friendliness.
Database To save the flight records, passengers records we have
chosen SQL+ database.
VB.Net To implement the project we have chosen Vb.Net language
for its more interactive support.
4.4 COMMUNICATION INTERFACES
This project supports all types of web browsers. We are using simple electronic forms for the
reservation forms, ticket booking etc.
5. NONFUNCTIONAL REQUIREMENTS
5.1 PERFORMANCE REQUIREMENTS
The steps involved to perform the implementation of airline database are as listed below.
A) E-R DIAGRAM
The E-R Diagram constitutes a technique for representing the logical structure of a database in a
pictorial manner. This analysis is then used to organize data as a relation, normalizing relation
and finally obtaining a relation database.
● ENTITIES: Which specify distinct real-world items in an application.
● PROPERTIES/ATTRIBUTES: Which specify properties of an entity and
relationships.
● RELATIONSHIPS: Which connect entities and represent meaningful
dependencies between them.
the
diagram shows the ER diagram of airline database
5.2 SAFETY REQUIREMENTS
If there is extensive damage to a wide portion of the database due to catastrophic failure, such as
a disk crash, the recovery method restores a past copy of the database that was backed up to
archival storage (typically tape) and reconstructs a more current state by reapplying or redoing
the operations of committed transactions from the backed up log, up to the time of failure.
5.3 SECURITY REQUIREMENTS
Security systems need database storage just like many other applications. However, the special
requirements of the security market mean that vendors must choose their database partner
carefully.
5.4 SOFTWARE QUALITY ATTRIBUTES
● AVAILABILITY: The flight should be available on the specified date and
specified time as many customers are doing advance reservations.
● CORRECTNESS: The flight should reach start from correct start terminal and
should reach the correct destination.
● MAINTAINABILITY: The administrators and flight in chargers should maintain
correct schedules of flights.
● USABILITY: The flight schedules should satisfy a maximum number of
customers needs.
Following are the characteristics of a good SRS document:
1. Correctness:
User review is used to ensure the correctness of requirements stated in the SRS. SRS
is said to be correct if it covers all the requirements that are actually expected from
the system.
2. Completeness:
Completeness of SRS indicates every sense of completion including the numbering of
all the pages, resolving the to be determined parts to as much extent as possible as
well as covering all the functional and non-functional requirements properly.
3. Consistency:
Requirements in SRS are said to be consistent if there are no conflicts between any
set of requirements. Examples of conflict include differences in terminologies used at
separate places, logical conflicts like time period of report generation, etc.
4. Unambiguousness:
A SRS is said to be unambiguous if all the requirements stated have only 1
interpretation. Some of the ways to prevent unambiguousness include the use of
modelling techniques like ER diagrams, proper reviews and buddy checks, etc.
5. 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.
6. Verifiability:
A SRS is verifiable if there exists a specific technique to quantifiably measure the
extent to which every requirement is met by the system. For example, a requirement
starting that the system must be user-friendly is not verifiable and listing such
requirements should be avoided.
7. Traceability:
One should be able to trace a requirement to design component and then to code
segment in the program. Similarly, one should be able to trace a requirement to the
corresponding test cases.
What is the Use Case Diagram?
Use Case Diagram captures the system’s functionality and requirements by
using actors and use cases. Use Cases model the services, tasks, function
that a system needs to perform. Use cases represent high-level functionalities
and how a user will handle the system. Use-cases are the core concepts of
Unified Modelling language modeling.
Use-case diagram notations
Following are the common notations used in a use case diagram:
Use-case:
Use cases are used to represent high-level functionalities and how the user
will handle the system. A use case represents a distinct functionality of a
system, a component, a package, or a class. It is denoted by an oval shape
with the name of a use case written inside the oval shape. The notation of a
use case in UML is given below:
Actor:
It is used inside use case diagrams. The actor is an entity that interacts
with the system. A user is the best example of an actor. An actor is an
entity that initiates the use case from outside the scope of a use case. It
can be any element that can trigger an interaction with the use case.
One actor can be associated with multiple use cases in the system. The
actor notation in UML is given below.
Tips for drawing a use-case diagram
1. A use case diagram should be as simple as possible.
2. A use case diagram should be complete.
3. A use case diagram should represent all interactions with the use
case.
4. If there are too many use cases or actors, then only the essential
use cases should be represented.
5. A use case diagram should describe at least a single module of a
system.
6. If the use case diagram is large, then it should be generalized.
SEQUENCE DIAGRAM
