Software Engineering

LAB 2
REQUIREMENT ANALYSIS AND ELICITATION
 Introduction
Requirements gathering and analysis is the first step of any software development project.
Until requirements are clear we can not move to next tasks(design , coding , testing, deployment etc)
There are two main types of Requirements (Functional(what) and Non Functional(how))
Somerville defines “requirement” as a specification of what should be implemented.
Requirements specify how the target system should behave. It specifies what to do, but not
how to do.
Requirements engineering refers to the process of understanding what a customer expects from the
system to be developed, and to document them in a standard and easily readable and understandable
format.
This documentation will serve as reference for the subsequent design, implementation and verification
of the system.
 Requirements Engineering
The process of defining, documenting and maintaining the requirements.
It is a process of gathering and defining service provided by the system.
The Process consists of the following main activities:
❖Requirements elicitation (Rough Idea , required or not required)
❖Requirements specification(Specify Requirements)
❖Requirements verification and validation (More Precise)
❖Requirements management(Managing All The Requirements-Final Stage)
 Functional Requirements
Requirements related to functional aspect of software.
◦ Define functions and functionality within and from the software system.
◦ Examples -
◦ Search option given to user to search different products and categories.
◦ User should be able to create an account and then must be able to login to the systems.
◦ Software is developed keeping downward compatibility intact.
 Non-Functional Requirements
Requirements, which are not related to functional aspect of software.
◦ They are implicit or expected characteristics of software, which users make assumption of.
Non-functional requirements include -
◦ Security, Logging, Storage, Configuration
◦ Performance, Cost, Flexibility
◦ Disaster recovery, Accessibility

They are not directly related what functionalities are expected from the system. However, NFRs
could typically define how the system should behave under certain situations. Eg: A system must
be easy to use.
We map the NFR with FR
 Exercise
let’s assume we’re developing a web application that should process customer orders for an
auto car shop.
◦ functional requirements describe what the software / website should do (the functions).
◦ Think about the core operations. To identify FRs
◦ The web application shall accept customer orders
◦ The web application shall be able to cash a sale
◦ The web application shall produce a receipt detailing a customers’ purchase information and include
name of customer, items purchased, cost of each item and total cost
◦ The web application shall be able to produce weekly, monthly and yearly reports about sales
Case Study: A Library Information
System
As the size and capacity of the institute is increasing with the time, it has been proposed to
develop a Library Information System (LIS) for the benefit of students and employees of the
institute. LIS will enable the members to borrow a book (or return it) with ease while sitting at
his desk/chamber. The system also enables a member to extend the date of his borrowing if no
other booking for that particular book has been made. For the library staff, this system aids
them to easily handle day-to-day book transactions. The librarian, who has administrative
privileges and complete control over the system, can enter a new record into the system when a
new book has been purchased, or remove a record in case any book is taken off the shelf. Any
non-member is free to use this system to browse/search books online. However, issuing or
returning books is restricted to valid users (members) of LIS only. The final deliverable would a
web application (using HTML 5), which should run only within the institute LAN. Although this
reduces security risk of the software to a large extent, care should be taken no confidential
information (e.g. passwords) is stored in plain text. Lot of members should be able to use the
system.
Identification of Functional requirements:
# Requirements Priority
R1 New user registration High
R2 User Login High
R3 Search book High
R4 Issue book High
R5 Return book High
R6 Reissue book Low
Identification of non-functional
requirements:
Performance Requirements:
▪This system should remain accessible 24x7
▪At least 50 users should be able to access the system altogether at any given time
Security Requirements:
▪This system should be accessible only within the institute LAN
▪The database of LIS should not store any password in plain text -- a hashed value has to be stored
Design Constraints:
The LIS has to be developed as a web application, which should work with Firefox 5, Internet Explorer 8,
Google Chrome 12, Opera 10.The system should be developed using HTML 5. Once all the functional and
non-functional requirements have been identified, they are documented formally in SRS, which then
serves as a legal agreement.
 Lab Task 1
We are planning to design an interactive flight reservation system where Traveler should be able
to check ticket availability if he fined available pay fare by PayPal and can book ticket. Before
booking a ticket it is must to fallout the personal information and travel details. Once traveler
book a ticket he/she should be able to cancel the ticket with in a limited amount of time and can
get his full refund back. And we can add this advance feature later if the traveler want to hold a
reservation. While on the other hand a railway clerk can approve the cancel requests. Final
deliverable should be able to work on MAC and IOS, system should be available 24x7 especially
on holiday season. Our system shouldn’t store any of the travelers PayPal information.
 Lab Task 2
An Address Book Application required to work as follow. When user signs in into system he
should be able to add new person detail into address book and system should have capability to
store lot of contacts. If he wants to edit and delete a record he should be able to do as well.
Along with the details given above he should be able to perform different types of sorting on the
address book for example sort by name and sort by ZIP code. System should have facility to print
the entries of address book records. System should be able to export (save the contact into
excel file/ pdf formats on the computer desktop) and import (loading file from desktop into
software) external files. If the user wants to encrypt and export the file from the application he
should be able to do so. We really like to add a new feature like syncing the contacts with
iphones/android but that can wait until next release. The final deliverable should be a desktop
application using Java.