Software Requirements

Specification
for

<Project>
Version 1.0 approved

Prepared by <author>

<organization>

<date created>

Copyright © 2013 by Karl Wiegers and Seilevel. Permission is granted to use and modify this document.
Software Requirements Specification for <Project> Page ii

Table of Contents
Table of Contents .......................................................................................................................... ii
Revision History ............................................................................................................................ ii
1. Introduction ..............................................................................................................................1
1.1 Purpose ........................................................................................................................................ 1
1.2 Document Conventions ............................................................................................................... 1
1.3 Project Scope ............................................................................................................................... 1
1.4 References ................................................................................................................................... 1
2. Overall Description ..................................................................................................................1
2.1 Product Perspective ..................................................................................................................... 1
2.2 User Classes and Characteristics ................................................................................................. 2
2.3 Operating Environment ............................................................................................................... 2
2.4 Design and Implementation Constraints...................................................................................... 2
2.5 Assumptions and Dependencies .................................................................................................. 2
3. System Features .......................................................................................................................2
3.1 System Feature 1 ......................................................................................................................... 2
3.2 System Feature 2 (and so on) ...................................................................................................... 3
4. Data Requirements ..................................................................................................................3
4.1 Logical Data Model ..................................................................................................................... 3
4.2 Data Dictionary ........................................................................................................................... 3
4.3 Reports......................................................................................................................................... 3
4.4 Data Acquisition, Integrity, Retention, and Disposal .................................................................. 3
5. External Interface Requirements ...........................................................................................4
5.1 User Interfaces ............................................................................Error! Bookmark not defined.
5.2 Software Interfaces .....................................................................Error! Bookmark not defined.
5.3 Hardware Interfaces....................................................................Error! Bookmark not defined.
5.4 Communications Interfaces ......................................................................................................... 4
6. Quality Attributes ....................................................................................................................4
6.1 Usability .....................................................................................Error! Bookmark not defined.
6.2 Performance ................................................................................................................................. 5
6.3 Security ........................................................................................................................................ 5
6.4 Safety ........................................................................................................................................... 5
6.5 [Others as relevant].....................................................................Error! Bookmark not defined.
7. Internationalization and Localization Requirements ...........................................................6
8. Other Requirements .................................................................. Error! Bookmark not defined.
Appendix A: Glossary....................................................................................................................6
Appendix B: Analysis Models .......................................................................................................6

Revision History
Name Date Reason For Changes Version
Result management
system V1.0

Copyright © 2013 by Karl Wiegers and Seilevel. Permission is granted to use and modify this document.
Software Requirements Specification for <Project> Page 1

1. Introduction
<The introduction presents an overview to help the reader understand how the SRS is organized
and how to use it.>

1.1 Purpose
<Identify the product whose software requirements are specified in this document, including the
revision or release number. Describe the different types of reader that the document is intended
for, such as developers, project managers, marketing staff, users, testers, and documentation
writers.>

1.2 Document Conventions

<Describe any standards or typographical conventions used, including the meaning of specific text
styles, highlighting, or notations. If you are manually labeling unique requirement identifiers, you
might specify the format here for anyone who needs to add one later.>

1.3 Project Scope

<Provide a short description of the software being specified and its purpose. Relate the software to
user or corporate goals and to business objectives and strategies. If a separate vision and scope
or similar document is available, refer to it rather than duplicating its contents here. An SRS that
specifies an incremental release of an evolving product should contain its own scope statement as
a subset of the long-term strategic product vision. You might provide a high-level summary of the
major features the release contains or the significant functions that it performs.>

1.4 References
<List any documents or other resources to which this SRS refers. Include hyperlinks to them if they
are in a persistent location. These might include user interface style guides, contracts, standards,
system requirements specifications, interface specifications, or the SRS for a related product.
Provide enough information so that the reader can access each reference, including its title,
author, version number, date, and source, storage location, or URL.>

2. Overall Description
<This section presents a high-level overview of the product and the environment in which it will be
used, the anticipated users, and known constraints, assumptions, and dependencies.>

2.1 Product Perspective

<Describe the product's context and origin. Is it the next member of a growing product line, the next
version of a mature system, a replacement for an existing application, or an entirely new product?
If this SRS defines a component of a larger system, state how this software relates to the overall

Copyright © 2013 by Karl Wiegers and Seilevel. Permission is granted to use and modify this document.
Software Requirements Specification for <Project> Page 2

system and identify major interfaces between the two. Consider including visual models such as a
context diagram or ecosystem map to show the product's relationship to other systems.>

2.2 User Classes and Characteristics

<Identify the various user classes that you anticipate will use this product and describe their
pertinent characteristics. Some requirements might pertain only to certain user classes. Identify the
favored user classes. User classes represent a subset of the stakeholders described in the vision
and scope document. User class descriptions are a reusable resource. If available, you can
incorporate user class descriptions by simply pointing to them in a master user class catalog
instead of duplicating information here.>

2.3 Operating Environment

<Describe the environment in which the software will operate, including the hardware platform;
operating systems and versions; geographical locations of users, servers, and databases; and
organizations that host the related databases, servers, and websites. List any other software
components or applications with which the system must peacefully coexist. If extensive technical
infrastructure work needs to be performed in conjunction with developing the new system, consider
creating a separate infrastructure requirements specification to detail that work.>

2.4 Design and Implementation Constraints

<Describe any factors that will limit the options available to the developers. These might include:
corporate or regulatory policies; hardware limitations (timing or memory requirements); interfaces
to other applications; specific technologies, tools, and databases to be used; programming
language requirements or restrictions.>

2.5 Assumptions and Dependencies

<List any assumed factors (as opposed to known facts) that could affect the requirements stated in
the SRS. These could include third-party or commercial components that you plan to use, reuse
expectations, issues around the development or operating environment, or constraints. The project
could be affected if these assumptions are incorrect, are not shared, or change. Also identify any
dependencies the project has on external factors outside its control.>

3. System Features
<This template illustrates organizing the functional requirements for the product by system
features, the major services provided by the product. You may prefer to organize this section by
use case, mode of operation, user class, object class, functional hierarchy, stimulus, response, or
combinations of these, whatever makes the most logical sense for your product.>

3.1 System Feature 1

<Don’t really say “System Feature 1.” State the feature name in just a few words.>

3.1.1 Description

Copyright © 2013 by Karl Wiegers and Seilevel. Permission is granted to use and modify this document.
Software Requirements Specification for <Project> Page 3

<Provide a short description of the feature and indicate whether it is of High, Medium, or
Low priority.>

3.1.2 Stimulus/Response Sequences

<List the sequences of user actions and system responses that stimulate the behavior
defined for this feature. These will correspond to the dialog elements associated with use
cases.>

3.1.3 Functional Requirements

<Itemize the specific functional requirements associated with this feature. These are the
software capabilities that must be implemented for the user to carry out the feature's
services or to perform a use case. Describe how the product should respond to anticipated
error conditions. Use “TBD” as a placeholder to indicate when necessary information is not
yet available.>

3.2 System Feature 2 (and so on)

4. Data Requirements
<This section describes various aspects of the data that the system will consume as inputs,
process in some fashion, or create as outputs.>

4.1 Logical Data Model

<A data model is a visual representation of the data objects and collections the system will process
and the relationships between them. Include a data model for the business operations being
addressed by the system, or a logical representation for the data that the system itself will
manipulate. Data models are most commonly created as an entity-relationship diagram.>

4.2 Data Dictionary

<The data dictionary defines the composition of data structures and the meaning, data type, length,
format, and allowed values for the data elements that make up those structures. In many cases,
you're better off storing the data dictionary as a separate artifact, rather than embedding it in the
middle of an SRS. That also increases its reusability potential in other projects.>

4.3 Reports
<If your application will generate any reports, identify them here and describe their characteristics.
If a report must conform to a specific predefined layout you can specify that here as a constraint,
perhaps with an example. Otherwise, focus on the logical descriptions of the report content, sort
sequence, totaling levels, and so forth, deferring the detailed report layout to the design stage.>

4.4 Data Acquisition, Integrity, Retention, and Disposal

<If relevant, describe how data is acquired and maintained. State any requirements regarding the
need to protect the integrity of the system's data. Identify any specific techniques that are

Copyright © 2013 by Karl Wiegers and Seilevel. Permission is granted to use and modify this document.
Software Requirements Specification for <Project> Page 4

necessary, such as backups, checkpointing, mirroring, or data accuracy verification. State policies
the system must enforce for either retaining or disposing of data, including temporary data,
metadata, residual data (such as deleted records), cached data, local copies, archives, and interim
backups.>

5. External Interface Requirements

The minimum system requirements and required hardware specifications are stated in this section.

5.1 Software Specifications

5.1.1 Operating system: Windows XP

5.1.2 Front-End: HTML, PHP

5.1.3 Database: MySQL

5.1.4 Model design: Rational Rose

5.2 Hardware specifications

5.2.1 Processor: Intel Pentium 4

5.2.2 RAM: 2 GB

5.2.3 Hard disk: 500 GB

6. Technology description
6.1.1 HTML

Hypertext Markup Language (HTML) is the standard markup language for creating web pages and
web applications. With Cascading Style Sheets (CSS) and JavaScript, it forms a triad of cornerstone
technologies for the World Wide Web. Web browsers receive HTML documents from a web server
or from local storage and render them into multimedia web pages. HTML describes the structure of
a web page semantically and originally included cues for the appearance of the document.
6.1.1.1 HTML Forms
HTML Forms are required when you want to collect some data from the site visitor. For example,
during user registration you would like to collect information such as name, email address, credit
card, etc. A form will take input from the site visitor as CGI, ASP Script, or PHP script etc. The
back-end application will perform required processing on the passed data based on defined business
logic inside the application.

Copyright © 2013 by Karl Wiegers and Seilevel. Permission is granted to use and modify this document.
Software Requirements Specification for <Project> Page 5

6.1.2 Java Script

JavaScript often abbreviated as JS, is a high level, interpreted programming language. It is a

language which is also characterized as dynamic, weakly typed, prototype-based and
multiparadigm. Alongside HTML and CSS, JavaScript is one of the three core technologies of
World Wide Web content engineering. It is used to make dynamic web pages interactive and
provide online programs, including video games. The majority of website seem to ploy it, and all
modern web browsers support it without the need for plug-ins by means of a built-in JavaScript
engine. Each of the many JavaScript engines represent a different implementation of JavaScript, all
based on the ECMA Script specification, with some engines not supporting the spec fully, and with
many engines supporting additional features beyond ECMA.

6.1.3 Cascading Style Sheet

Cascading Style Sheets (CSS) is a style sheet language used for describing the presentation of a
document written in a markup language. Although most often used to set the visual style of web
pages and user interfaces written in HTML and XHTML, the language can be applied to any XML
document, including plain XML, SVG and XUL, and is applicable to rendering in speech, or on
other media. Along with HTML and JavaScript, CSS is a cornerstone technology used by most
websites to create visually engaging webpages, user interfaces for web applications, and user
interfaces for many mobile applications.

6.1.4 Hypertext Pre-Processor

PHP started out as a small open-source project that evolved as more and more people found out how
useful it was. Rasmus Lerdorf unleashed the first version of PHP way back in 1994. PHP is a
recursive acronym for &quot;PHP:HypertextPreprocessor&quot;. PHP is a server-side scripting
language that is embedded in HTML. It is used to manage dynamic content, databases, session
tracking, even build entire ecommerce sites. It is integrated with a number of popular databases,
including MySQL, PostgreSQL, Oracle, Sybase, Informix, and Microsoft SQL Server. PHP
performs system functions, i.e., from files on a system it can create, open, read, write, and close
them. PHP can handle forms, i.e. gather data from files, save data to a file, through email you can
send data, return data to the user. You add, delete, modify elements within your database through
PHP.

6.1.5 Database description

MySQL is an open-source relational database management system (RDBMS) based on Structured

Query Language (SQL). MySQL is a popular choice of database for use in web applications, and is
a central component of the widely used LAMP opensource web application software stack (and
other &quot;AMP&quot; stacks). LAMP is an acronym for &quot;Linux, Apache, MySQL,
Perl/PHP/Python&quot;. Freesoftware open-source projects that require a full featured database
management system often use MySQL.Applications that use the MySQL database include: TYPO3,
MODx, Joomla,WordPress, phpBB, MyBB, Drupal and other software. MySQL is also used in
many high-profile, large-scale websites, including Google (though not for searches),Facebook,
Twitter, Flickr and YouTube.

Copyright © 2013 by Karl Wiegers and Seilevel. Permission is granted to use and modify this document.
Software Requirements Specification for <Project> Page 6

7. Internationalization and Localization Requirements

The 1.0 release of the result management system had the constraint of the need of internet for use of
the system. Release 1.5 came with an update to the system, enabling users to readily and
subsequently always access the ERP system, regardless of where they are present i.e., without the
restriction of internet access. The backward areas had an issue in staying in constant touch with the
ERP and prioritized paper work over ERP system due to this constraint. The new release upon being
extranet friendly has added to the user feasibility and not only made instant access to the system
easy but simplified the 24/7 connectivity/internet availability issue.

Appendix A: Glossary
<Define any specialized terms that a reader needs to know to understand the SRS, including
acronyms and abbreviations. Spell out each acronym and provide its definition. Consider building a
reusable enterprise-level glossary that spans multiple projects and incorporating by reference any
terms that pertain to this project.>

Appendix B: Analysis Models

<This optional section includes or points to pertinent analysis models such as data flow diagrams,
feature trees, state-transition diagrams, or entity-relationship diagrams. You might prefer to insert
certain models into the relevant sections of the specification instead of collecting them at the end.>

Copyright © 2013 by Karl Wiegers and Seilevel. Permission is granted to use and modify this document.