HMR INSTITUTE OF TECHNOLOGY AND

MANAGEMENT

SOFTWARE ENGINEERING LAB

PAPER CODE: ETCS-353

Submitted to:
Ms. Isha
Assistant Professor
Department of Computer Science

Submitted by:
Vaibhav Bhnadari
CSE-5A
04913302714

Software Engineering Lab Manual

INDEX
S.No
.

Name of Experiment

Date

Marks

Sign

Software Engineering Lab Manual

EXCERCISE NO. 1
AIM: To prepare PROBLEM STATEMENT for any project.
REQUIREMENTS:
Hardware Interfaces
1. Pentium(R) 4 CPU 2.26 GHz, 128 MB RAM
2. Screen resolution of at least 800 x 600 required for proper and complete
viewing
of screens. Higher resolution would not be a problem.
3. CD ROM Driver

Software Interfaces

Any window-based operating system (Windows 95/98/2000/XP/NT)

WordPad or Microsoft Word

THEORY:
The problem statement is the initial starting point for a project. It is basically a one to
three-page statement that everyone on the project agrees with that describes what will
be done at a high level. The problem statement is intended for a broad audience and
should be written in non-technical terms. It helps the non-technical and technical
personnel communicate by providing a description of a problem. It doesn't describe
the solution to the problem.
The input to requirement engineering is the problem statement prepared by customer.
It may give an overview of the existing system along with broad expectations from
the new system.
The first phase of requirements engineering begins with requirements elicitation i.e.
gathering of information about requirements. Here, requirements are identified with
the help of customer and existing system processes. So from here begins the
preparation of problem statement.
So, basically a problem statement describes what needs to be done without describing
how.
Conclusion: The problem statement was written successfully by following the steps
described above.

Software Engineering Lab Manual

PROBLEM STATEMENT
TOPIC: Ecommerce
E-commerce provides an easy way to sell products to a large customer base. However, there is a lot
of competition among multiple e-commerce sites. When users land on an e-commerce site, they
expect to find what they are looking for quickly and easily. Also, users are not sure about the brands
or the actual products they want to purchase.
They have a very broad idea about what they want to buy. Many customers nowadays search for
their products on Google rather than visiting specific e-commerce sites. They believe that Google
will take them to the e-commerce sites that have their product.
Ecommerce allows consumers to electronically exchange goods and services with no barriers of
time or distance. Electronic commerce has expanded rapidly over the past five years and is
predicted to continue at this rate, or even accelerate.
In the near future the boundaries between "conventional" and "electronic" commerce will become
increasingly blurred as more and more businesses move sections of their operations onto the
Internet.
The main objectives provided by this system are as follows:

Reach out to a larger audience.

Your virtual shop remains open and operational 24x7.

In most cases; you need not maintain the whole stock of products.

You build your brand more quickly.

Shop from home.

Software Engineering Lab Manual

EXCERCISE NO. 2
Aim: Understanding an SRS.
Requirements:
Hardware Requirements:

PC with 300 megahertz or higher processor clock speed recommended; 233

MHz minimum required.
128 megabytes (MB) of RAM or higher recommended (64 MB minimum
supported)
1.5 gigabytes (GB) of available hard disk space
CD ROM or DVD Drive
Keyboard and Mouse (compatible pointing device).

Software Requirements:
Rational Rose, Windows XP
Theory:
An SRS is basically an organization's understanding (in writing) of a customer or
potential client's system requirements and dependencies at a particular point in time
(usually) prior to any actual design or development work. It's a two-way insurance
policy that assures that both the client and the organization understand the other's
requirements from that perspective at a given point in time.
The SRS document itself states in precise and explicit language those functions and
capabilities a software system (i.e., a software application, an ecommerce Web site,
and so on) must provide, as well as states any required constraints by which the
system must abide. The SRS also functions as a blueprint for completing a project
with as little cost growth as possible. The SRS is often referred to as the "parent"
document because all subsequent project management documents, such as design
specifications, statements of work, software architecture specifications, testing and
validation plans, and documentation plans, are related to it.
It's important to note that an SRS contains functional and non-functional
requirements only; it doesn't offer design suggestions, possible solutions to
technology or business
issues, or any other information other than what the development team understands
the customer's system requirements to be
5

Software Engineering Lab Manual

A well-designed, well-written SRS accomplishes four major goals:

It provides feedback to the customer. An SRS is the customer's assurance that
the development organization understands the issues or problems to be solved
and the software behaviour necessary to address those problems. Therefore, the
SRS should be written in natural language (versus a formal language,
explained later in this article), in an unambiguous manner that may also
include charts, tables, data flow diagrams, decision tables, and so on.
It decomposes the problem into component parts. The simple act of writing
down software requirements in a well-designed format organizes information,
places borders around the problem, solidifies ideas, and helps break down the
problem into its component parts in an orderly fashion.
It serves as an input to the design specification. As mentioned previously, the
SRS serves as the parent document to subsequent documents, such as the
software design specification and statement of work. Therefore, the SRS must
contain sufficient detail in the functional system requirements so that a design
solution can be devised.
It serves as a product validation check. The SRS also serves as the parent
document for testing and validation strategies that will be applied to the
requirements for verification.

SRSs are typically developed during the first stages of "Requirements Development,"
which is the initial product development phase in which information is gathered
about what requirements are needed--and not. This information-gathering stage can
include onsite visits, questionnaires, surveys, interviews, and perhaps a return-oninvestment (ROI) analysis or needs analysis of the customer or client's current
business environment. The actual specification, then, is written after the requirements
have been gathered and analysed.
SRS should address the following
The basic issues that the SRS shall address are the following:
a) Functionality. What is the software supposed to do?
b) External interfaces. How does the software interact with people, the systems
hardware, other hardware, and other software?
c) Performance. What is the speed, availability, response time, recovery time of
various software functions, etc.?
d) Attributes. What are the portability, correctness, maintainability, security, etc.
Considerations?

Software Engineering Lab Manual

e) Design constraints imposed on an implementation. Are there any required

standards in effect, implementation language, policies for database integrity,
resource limits, operating environment(s) etc.

Characteristics of a good SRS

An SRS should be
a) Correct
b) Unambiguous
c) Complete
d) Consistent
e) Ranked for importance and/or stability
f) Verifiable
g) Modifiable
h) Traceable
Correct - This is like motherhood and apple pie. Of course you want the
specification to be correct. No one writes a specification that they know is incorrect.
We like to say - "Correct and Ever Correcting." The discipline is keeping the
specification up to date when you find things that are not correct.
Unambiguous - An SRS is unambiguous if, and only if, every requirement stated
therein has only one interpretation. Again, easier said than done. Spending time on
this area prior to releasing the SRS can be a waste of time. But as you find
ambiguities - fix them.
Complete - A simple judge of this is that is should be all that is needed by the
software designers to create the software.
Consistent - The SRS should be consistent within itself and consistent to its
reference documents. If you call an input "Start and Stop" in one place, don't call it
"Start/Stop" in another.
Ranked for Importance - Very often a new system has requirements that are really
marketing wish lists. Some may not be achievable. It is useful provide this
information in the SRS.
Verifiable - Don't put in requirements like - "It should provide the user a fast
response." Another of my favourites is - "The system should never crash." Instead,
provide a quantitative requirement like: "Every key stroke should provide a user
response within 100 milliseconds."
Modifiable - Having the same requirement in more than one place may not be wrong
- but tends to make the document not maintainable.
7

Software Engineering Lab Manual

Traceable - Often, this is not important in a non-politicized environment. However,

in most organizations, it is sometimes useful to connect the requirements in the SRS
to a higher level document. Why do we need this requirement?

A sample of basic SRS Outline

1. Introduction
1.1 Purpose
1.2 Document conventions
1.3 Intended audience
1.4 Additional information
1.5 Contact information/SRS team members
1.6 References
2. Overall Description
2.1 Product perspective
2.2 Product functions
2.3 User classes and characteristics
2.4 Operating environment
2.5 User environment
2.6 Design/implementation constraints
2.7 Assumptions and dependencies
3. External Interface Requirements
3.1 User interfaces
3.2 Hardware interfaces
3.3 Software interfaces
3.4 Communication protocols and interfaces
4. System Features
4.1 System feature
4.1.1 Description and priority
4.1.2 Action/result
4.1.3 Functional requirements
4.2 System feature B
5. Other Non-functional Requirements
5.1 Performance requirements
5.2 Safety requirements
5.3 Security requirements
5.4 Software quality attributes
5.5 Project documentation
5.6 User documentation
6. Other Requirements
8

Software Engineering Lab Manual

Appendix A: Terminology/Glossary/Definitions list

Appendix B: To be determined
Conclusion: The SRS was made successfully by following the steps described above.

SAMPLE SRS

Software Engineering Lab Manual

Table of Contents
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Document Convention
1.4 Intended Audience
1.5 Technologies
1.6 Features of ASP.NET
1.7 Abbreviations
1.8 References
2. The Overall Description
2.1 Product Perspective
2.2 Product Functions
2.3 User Characteristics
2.4 Operating environment
2.5 Constraints
3. External interface Requirements
3.1 User Interfaces
3.2 Hardware Interfaces
3.3 Software Interfaces
3.4 Communications Interfaces
4. System Features
5. Other Non-Functional Requirements
5.1 Performance Requirements
5.2 Safety Requirements
5.3 Security Requirements
5.4 Software Quality Attributes
5.4.1 Security
5.4.2 Reliability
5.4.3 Maintainability
5.4.4 Portability
5.4.5 Usability
5.4.6 Scalability
6. Other Requirements .............................................................................
10

Software Engineering Lab Manual

Appendix A: Glossary

1 Introduction
The introduction of the Software Requirements Specification (SRS) provides an overview of the
entire SRS with purpose, scope, abbreviations, references and overview of the SRS. The aim of this
document is to gather and analyze and give an in-depth insight of the complete
e-commerce webite by defining the problem statement in detail. Nevertheless, it also define the highlevel product features.

1.1 Purpose
The purpose of the document is to collect and analyse all assorted ideas that have come up to define
the website, its requirements with respect to consumers. Also, we shall predict and sort out how we
hope this website will be used.In short, the purpose of this SRS document is to provide a detailed
overview of our software product, its parameters and goals. This document describes the website's
target audience and itsuser interface, hardware and software requirements. It defines how our client,
team and audiencesee the product and its functionality.

1.2 Scope
Primarily, the scope pertains to the e-commerce website features for making online shopping better.
It focuses on the company, the customer and applications, which allow for online sales and
distribution.
This SRS is also aimed at specifying requirements of software to be developed but it can also be
applied to assist in the selection of in-house and commercial software products. The standard can be
used to create software requirements specifications directly or can be used as a model for defining a
organization or project specific standard. It does not identify any specific method, nomenclature or
tool for preparing an SRS.

1.3 Abbreviations:
HTML - Hyper Text Markup Language.
HTTP - Hyper Text Transfer Protocol.
1.4 Abbreviations:
2. Overall Description
This document contains the problem statement that the current system is facing which ishampering
the growth opportunities of the company. It further contains a list of the stakeholdersand users of
the proposed solution. It also illustrates the needs and wants of the stakeholders thatwere identified
in the brainstorming exercise as part of the requirements workshop. It further listsand briefly
11

Software Engineering Lab Manual

describes the major features and a brief description of each of the proposed system.The following
SRS contains the detail product perspective from different stakeholders. It provides the detail
product functions of E-Store with user characteristics permitted constraints,assumptions and
dependencies and requirements subsets.

2.1 Product perspective

BECS is an online bookstore website which supports a number of functions for both the consumer
and store's management. The website must be available to anyone using the Computer Science
Departments provided computer resources in the MSU Engineering Building and as such must
work correctly in both Internet Explorer and Mozilla Firefox. As stated by the customer, there are
no hardware or software requirements beyond these including, but not limited to, memory or
specific software packages that need to be utilized nor software packages that need not be
utilized

2.2 Product Functions

BECS will provide a number of functions; each is listed below.

Maintain data associated with the inventory (a collection of books)
A book has a title, author and price The inventory also keep track of the stock/quantity of
each book
Maintain records for many customers
A customer can be either a member or non-member.
A customer has a username (unique across all users), password (no restrictions), email
address (no restrictions), and postal address (unverified.)
Anyone may sign up for a customer account.
Allow any customer to become a member.
Show a listing of available books
Books are to be displayed in ascending alphabetical order by title.
Each book will list the following from left to right
Title
Author
Price
Allow customers and managers to log in and out of the system.
Users (both customers and the manager) will be logged out if inactive for 30 minutes.
Shopping cart .
Anyone is able to add one or more books to the shopping cart.
The shopping cart does not need to allow multiple copies of any book.
Checkout
Checkout is only available to logged-in customers. A user that is not logged in as a customer
is given a chance to log in.
Member customers may enter a promotion code.
Only one promotion code may be used per purchase
The promotion is a fixed percentage discount that is to be applied to an entire order.
The discount is specified by the manager at the time of the promotions creation or most
recent update/edit.
12

Software Engineering Lab Manual

Collect a 16-digit credit card number from the customer

Log/record the transaction
Allow manager to specify a stop-order for a book
Each book has its own stop-order status either on or off. Details of its use are involved in
the following feature.
Notify manager when books need to be reordered
When the quantity a book falls below a threshold, the manager is notified that the book
needs to be reordered.
One exception is if the manager has already specified a stop-order for this book.
Every book must either have stop-order enabled or disabled
Allow manager to update stock quantities
Allow manager to change any book's price
Allow manager to view transaction logs
Allow manager to create promotions
A promotion is a percentage discount that can be applied to an entire order
Promotions may only be used by member customers .
A promotion has an expiration date specified by the manager When a promotion is created,
it is emailed to all member customers via the email address on record

2.3 User Classes and Characteristics

The typical BECS user is simply anyone that has access to the Internet and a web browser in the
computer science department at Michigan State University. It is assumed that the user is familiar
enough with a computer to operate the browser, keyboard and mouse and is capable of browsing to,
from and within simple websites

2.4 Operating Environment

The server should have Java installed on the machine, along with Javas
cryptographic packages. The election server runs on a http server, that is jsp
enabled. The browsers through which the voters access the server should have
minimal support for cookies and encrypted transactions.
2.5 Constraints
As stated by the customer, security is not a concern for this system. The database may store
passwords in plain text and there doesn't need to be a password recovery feature nor lockout after
numerous invalid login attempts. As such, the system may not work correctly in cases when security
is a concern. These cases include those listed above in addition to lack of an encrypted connection
when sending credit card information and forcing users to use strong passwords. A strong
password is a password that meets a number of conditions that are set in place so that user's
passwords cannot be easily guessed by an attacker. Generally, these rules include ensuring that the
password contains a sufficient number of characters and contains not only lowercase letters but also
capitals, numbers, and in some cases, symbols. The system may not behave correctly when used
with Internet browsers other than Firefox and Internet Explorer.

13

Software Engineering Lab Manual

3.Specific Requirements
3. 1 Interface Requirements
There are many types of interfaces as such supported by the E-Store software system
namely User Interface, Software Interface and Hardware Interface .The protocol used
shall be HTTP .The Port number used will be 80.There shall be logical address of the
system in IPv4 format.
3.1.1 User Interfaces
The user interface for the software shall be compatible to any browser such as
Internet Explorer, Mozilla or Netscape Navigator by which user can access to the
system .The user interface shall be implemented using any tool or software package
like JavaApplet, MS Front Page, EJB etc.
3.1.2 Hardware Interface:
Since the application must run over the internet, all the hardware shall require to
connect internet will be hardware interface for the system. As for e.g. Modem, WAN
LAN ,Ethernet Cross-Cable.

3.1.3 Software Requirements

Operating System
Interface
Client side Scripting

: Windows XP/2003/7 or Linux User

: HTML, CSS
: JavaScript
14

Software Engineering Lab Manual

Programming Language
Web Applications
IDE/Workbench
Database

: C#
: ASP.NET
: Visual Studio 2008/2010
: Microsoft SQL Server 2005/2008

3.1.4 COMMUNICATION INTERFACES

- It uses HTTP/HTTPS protocol on client side.
- Firewall security is required for securing the server.
- TCP/IP protocol is the basic need for client side.
- For the purpose of giving the EA an option of sending the voters their
passwords through mail, the system should use the SMTP protocol.
- The system should also use standard protocols for secure transactions between
the Voter and the system through the internet.
3.2 FUNCTIONALITY
This section contains the requirements for the e-store. These requirements
are organized bythe features discussed in the vision document.
3.2.1 PROVIDE COMPREHENSIVE PRODUCT DETAILS
The system shall display detailed information of the selected products. -The system
shall provide browsing options to see product details.
3.2.2 DETAILED PRODUCT CATEGORISATION
The system shall display detailed product categorization to the user.
3.2.3 PROVIDE SEARCH FACILITY
The system shall enable user to enter the search text on the screen.
The system shall enable user to select multiple options on the screen to search
The system shall display all the matching products based on the search.
The system shall display only 10 matching result on the current screen
The system shall enable user to navigate between the search results.
The system shall notify the user when no matching product is found on the
search.
3.2.4 MAINTAIN CUSTOMER PROFILE
The system shall allow user to create profile and set his credential.
The system shall authenticate user credentials to view the profile.
The system shall allow user to update the profile information.
15

Software Engineering Lab Manual

3.2.5 PROVIDE CUSTOMER SUPPORT

The system shall provide online help, FAQs customer support, and sitemap
options for customer support.
The system shall allow user to select the support type he wants.
The system shall allow user to enter the customer and product information for
the support.
The system shall display the customer support contact numbers on the screen.
The system shall allow user to enter the contact number for support personnel
to call.
The system shall display the online help upon request.
The system shall display the FAQs upon request.
3.2.6 EMAIL CONFIRMATION
The system shall maintain customer email information as a required part of
customer profile.
The system shall send an order confirmation to the user through email.
3.2.7 DETAILED INVOICE FOR CUSTOMER
The system shall display detailed invoice for current order once it is confirmed.
The system shall optionally allow user to print the invoice.
3.2.8 PROVIDE SHIPPING METHODS
The system shall display different shipping options provided by shipping
department
The system shall enable user to select the shipping method during payment
process
The system shall display the shipping charges.
The system shall display tentative duration for shipping.
3.2.9 ONLINE TRACKING SYSTEM
The system shall allow user to enter the order information for tracking.
The system shall display the current tracking information about the order.
3.2.10 ALLOW MULTIPLE PAYMENT OPTIONS
The system shall display available payment methods for payment.
The system shall allow user to select the payment method for order
3.2.11ALLOW ONLINE CHANGE OR CANCELLATION OF ORDER
16

Software Engineering Lab Manual

The system shall display the orders that are eligible to change.
The system shall allow user to select the order to be changed.
The system shall allow user to cancel the order.
The system shall allow user to change shipping, payment method.
The system shall notify the user about any changes made to the order.

3.2.12 ALLOW ONLINE PRODUCT REVIEWS AND RATINGS

The system shall display the reviews and ratings of each product, when it is
selected
The system shall enable the user to enter their reviews and ratings.
3.3 Usability
3.3.1 Graphical User Interface
The system shall provide a uniform look and feel between all the web pages.The
system shall provide a digital image for each product in the product catalog.The
system shall provide use of icons and toolbars.
3.3.2 Accessibility
The system shall provide handicap access.
The system shall provide multi language support
3.4 Performance
The product shall be based on web and has to be run from a web server.The product
shall take initial load time depending on internet connection strength which
alsodepends on the media from which the product is run.The performance shall
depend upon hardware components of the client/customer.
3.5 Security
3.5.1 Data Transfer
The system shall use secure sockets in all transactions that include any confidential
customer information.The system shall automatically log out all customers after a
period of inactivity.The system shall confirm all transactions with the customers web
browser.The system shall not leave any cookies on the customers computer
containing the users password.The system shall not leave any cookies on the
customers computer containing any of the usersconfidential information.
3.5.2 Data Storage
The customers web browser shall never display a customers password. It shall
always be echoed with special characters representing typed characters. The
customers web browser shall never display a customers credit card number after
retrieving from the database. It shall always be shown with just the last 4 digits of the
17

Software Engineering Lab Manual

credit card number. The systems back-end servers shall never display a customers
password. The customers password may be reset but never shown. The systems
back-end servers shall only be accessible to authenticated administrators. The
systems back-end databases shall be encrypted
3.6 Design constraints
3.6.1 Standard Development Tools
The system shall be built using a standard web page development tool that conforms
to either IBMs CUA standards or Microsofts GUI standards.
3.6.2Web Based Product
There are no memory requirements The computers must be equipped with web
browsers such as Internet explorer. The product must be stored in such a way that
allows the client easy access to it. Response time for loading the product should take
no longer than five minutes.

18

Software Engineering Lab Manual

Appendix: A - Glossary

19