Software Requirements Specification Document

After requirements elicitation, we prepare the IRD. This document gives an overview of the
system. Now a detailed document is prepared on the basis of the IRD and is called software
requirements specification (SRS) document. This document is used as a legal document which
acts as a contract between customers and developers.
We use IEEE recommended practice for software requirements specifications-IEEE standard
830-1998 for preparing the SRS document.
Nature of the SRS Document
The following issues shall be addressed by the SRS writer:
1. Functionality: What functions the software is supposed to perform?
2. Externalinterfaces: With what all external entities does the system interact? This may
include the number of users, response time, recovery time, processing time, etc.
3. Performance: How does the software address performance issues? This may include
people, hardware, external databases, etc.
4. Qualityattributes: What are the considerations for non-functional requirements? These
may include availability, correctness, maintainability, portability, reliability, security,
testability, etc. These non-functional requirements should also be properly placed in the
SRS document.
5. Design constraints imposed on implementation: All constraints should be highlighted
which have an impact on implementation. This may include limitations of the operating
environment, programming language, database, resources, policies for database integrity,
etc.
The SRS writer(s) should not include design and implementation details. It should be written in a
simple, clear and unambiguous language which may be understandable to all developers and
customers.
Organization of the SRS Document
SRS document is used to specify requirements of the software which is to be developed. It helps
the customers to know what they want from the proposed software system. It also helps the
developer to understand exactly what the customer wants.
There are four sections of the SRS document and are given in Table (IEEE, 1998).
The first two sections are the same for all projects, but Section 3 provides special tailoring as
mentioned "specific requirements" for different projects.
1. Introduction
1.1 Purpose
1.2 Scope
 1.3 Definitions, acronyms and abbreviations
1.4 References
1.5 Overview .
2. Overall description
2.1 Product perspective
2.1.1 System
2.1.2 User interfaces
interfaces
2.1.3 Hardware
2.1.4 Software
interfaces
2.1.5 Communications
interfaces interfaces
2.1.6 Memory
2.1.7 Operations
constraints
2.1.8 Site adaptation requirements
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and dependencies
2.6 Apportioning of requirements
3. Specific requirements
3.1 External interfaces
3.2 Functions
' 3.3 Performance requirements
3.4 Logical database requirements
3.5 Design constraints
3.5.l Standards
3.6 Softwarecompliance
system attributes
3.6.l Reliability
3.6.2 Availability
3.6.3 Security
3.6.4 Maintainability
3.6.5 Portability
3.7 Organizing the specific requirements
3.7.l System mode
3.7.2 User class
3.7.3 Objects
3.7.4 Feature
3.7.5 Stimulus
3.7.6 Response
3.7.7 Functional
,3.8 Additional comments
hierarchy
4. Supporting information
Example: LMS. The complete SRS is given below.
1. Introduction
This section gives the overview of the complete SRS document.
1.1 Purpose
We should describe the purpose of the SRS document and also list the intended audience for the
document. The purpose of the LMS is given as:
1.1 Purpose
The library management system (LMS) maintains the information about various books
available in the library. The LMS also maintains records of all the students, faculty and
employees in the university. 1'hese records are maintained in order to provide membership
to them.

1.2 Scope
The task of this subsection is to:
(i) Assign a name to the software under development.
(ii) List the functions which will be provided and also those functions which the software
will not do.
(iii) Explain the applications of the software along with possible benefits and objectives.
(iv) Maintain consistency amongst statements.
The scope of the LMS is given as:
1.2 Scope
The name of the software is library management system (LMS). The system will be
referred to as LMS in rest of the SRS. The proposed LMS must be able to perform the
following functions:
Dos
1. Issue of login ID and password to system operators.
2. Maintain details of books available in the library.
3. Maintain details of the students in the university to provide student membership.
4. Maintain details of the faculty and employees in the university to provide faculty and
employees membership.
5. Issue a book.
6. Bring a book back, and calculates fine if the book is being returned after the
specified due date.
7. Reserve a book.
8. Provide search facility to check the availability of a book in the library.
9. Generate the following reports:
 (a) List of books issued by a member.
(b) Details of books issued and returned on daily basis.
(c) Receipt of fine.
(d) Total available books in the library.
(e) List of library members along with issued books.
(f) List of available books in the library:
 Author-wise
 Book title-wise
 Publisher-wise
 Subject-wise
Don'ts
1. Periodicals section is not covered.
2. Book bank (if any) is not covered.
3. Records of digital books are not available.
4. Purchase of books facility is not available.
Benefits
The LMS provides the following benefits:
1. Easy searching of books.
2. Efficient issue and return of books.
3. Accurate and automated fine calculation.
4. Printing of reports.

1.3 Definitions, Acronyms and Abbreviations

Define all terms, acronyms and abbreviations. This may help to make the SRS document more
readable, understandable and clear to all the stakeholders. The definitions and acronyms used in
the LMS are given as:
1.3 Definitions, Acronyms and Abbreviations
SRS: Software requirement specification
LMS: Library management system
Systemoperator: System administrator, library staff, data entry operator
RAM: Random access memory
Accessionnumber: It is a unique sequence number allocated to each book in the catalog.
Student: Any candidate admitted in a programme offered by a school.
System administrator/Administrator: User having all the privileges to operate the LMS.
Data entry operator (DEO): User having privileges to maintain book, student and
faculty/ employee details.
Library staff: User having privilege to issue, return, reserve and query books.
Faculty: Teaching staff of the University-Professor, Associate Professor, Assistant
Professor School: Academic unit that offers various programmes

1.4 References
This subsection provide a list of all documents including books and research papers referenced
anywhere in the SRS document. The referenced material used in LMS is given as:
1.4 References
(a) Software Engineering by K.K. Aggarwal & Yogesh Singh, New Age Publishing
House, 3rd Edition, 2008.
(b) IEEE Recommended Practice for Software Requirements Specifications- IEEE Std
830-19~8.
(c) IEEE Standard for Software Test Documentation-IEEE Std. 829-1998.

1.5 Overview
This subsection of the SRS gives the overview of the software system. Explain what the rest of
the SRS contains and also gives details about the organization of the SRS document.
2. Overall Description
This section discusses the general factors which affect the requirements, and the final product
specific requirements are not discussed. This section may help to write specific requirements of
section 3 of the SRS document. The overview of the LMS is given as:
2. Overall Description
The LMS maintains records of books in the library and membership details of students,
faculty and employees in the university. It is assumed that approved books have already
been purchased by the acquisition section. It is also assumed that the student has already
been admitted in the university for a specific programme. The system administrator will
receive lists of the admitted students (school-wise and programme-wise) from the
academic section. The establishment section will provide the list of the faculty and
employees appointed in the university.
The LMS issues books to students, faculty and employees and brings the same back from
them. The LMS generates fine if the book is returned by a student after the due date. It also
allows students, faculty and employee to reserve a book. The student/faculty/employee can
access LMS on the university's library LAN in order to search the availability of the book
from the library.
The administrator/DEO will have to maintain the following information:
 Book details
 Student membership details
 Faculty and employee membership details
The administrator/library staff will perform the following functions:
 Issue a book
 Return a book
 Reserve a book
 Query a book
 Generate reports
 List of books issued to a member
 Details of books issued and returned on daily basis
 Receipt of fine
 Total available books in the library
 List of library members along with issued books
The administrator/student/faculty/employee requires the following'. information from the
system:
 List of available books in the library:
 Author-wise
 Book title-wise
 Publisher-wise
 Subject-wise

2.1 Product Perspective

This subsection puts the product into perspective with other related products. We should specify
the environment which may be web-enabled, stand-alone system, or usage of local area network.
A block diagram showing the major components of the large system, interconnections and
external interfaces can be helpful. The product perspective of LMS is given as:
2.1 Product Perspective
The LMS shall be developed using client/server architecture and will be compatible with
Microsoft Windows Operating System. The front-end of the system will be developed
using Visual Basic 6.0 and the back-end will be developed using MS SQL Server 2005.
2.1.1 System Interfaces
. System interfaces are addressed which are required by the product during its usage.
2.1.2 User Interfaces
This subsection should specify:
(i) Logical characteristics of each interface between the product and its users.
(j) How the system can be best used by the user. A list of dos and don'ts for the user may
also be specified.
The user interfaces of the LMS are given as:
2.1.2 User Interfaces
The LMS will have the following user-friendly and menu-driven interfaces:
(a) Login: to allow the entry of only authorized users through valid login ID and
password.
(b) Book details: to maintain book details.
(c) Student membership details: to maintain student membership details.
(d) Faculty/employee membership details: to maintain faculty/employee
membership details.
(e) Issue book: to allow library staff to issue a book from the library.
(f) Return book: to allow library staff to bring a book back to the library.
(g) Reserve book: to allow library staff to reserve a book.
(g) Query book: to check availability of a book in the library.
The software should generate the following information:
(a) Details of books issued and returned on daily basis.
(b) Details of books available in the library.
(c) Details of books issued to a student.
(d) List of library members with issued books.
(e) Receipt of fine

2.1.3 Hardware Interfaces

Logical characteristics of each interface between the software product and the hardware
component is to be specified. For example, issues such as screen resolution, support for printer,
single user/multi-user system, etc. should be addressed. These issues for the LMS are shown as
follows:
2.1.3 . Hardware Interfaces
(a) Screen resolution of at least 640 x 480 or above.
(b) Support for printer (dot matrix, deskjet, laserjet).
(c) Computer systems will be in the networked environment as it is a multi-user
system.

2.1.4 Software Interfaces

This subsection should specify the interface of the software product with other software
applications. For example, operating system, front end tools, back end tools, the specification
and version number of the software, etc. should also be specified. The software interfaces for the
LMS are given as:
2.1.4 Software Interfaces
(a) MS-Windows Operating System (NT/XP/Vista)
(b) Microsoft Visual Basic 6.0 for designing front-end
(c) MS SQL Server 2005 for back-end

2.1.5 Communication Interfaces

This subsection specifies the various interfaces to communication such as local network,
protocol, etc. For example, whether the software product will use LAN, web-enabled services or
stand-alone system. In the LMS, communication is via local area network (LAN).
2.1.6 Memory Constraints
Any constrains related to primary and secondary memories are specified. For example, for the
LMS, we may specify ''At least 512 MB RAM and 500 MB space of hard disk will be required to
run the software".
2.1.7 Operations
Various operations in the user's organization are specified. This may include data processing
support functions, backup and recovery operations.
2.1.8 Site Adaptation Requirements
Any specific requirements related to the hardware and software interfaces at site are to be
specified in this subsection. In the LMS, the terminal at the client site will have to support the
hardware and software interfaces specified in sections 2.1.3 and 2.1.4, respectively.
2.2 Product Functions
This section should list the summary of all functions that the software shall perform. Functions
should be listed in a simple and clear language and must be understandable to the customer. The
product functions for the LMS are given as:

2.2 Product Functions

The LMS will allow access only to the authorized users with specific roles (system
administrator, library staff, DEO and student). Depending upon the user's role, he/she will
be able to access only specific modules of the system.
A summary of major functions that the LMS shall perform includes:
 A login facility for enabling only authorized access to the system.
 The system administrator/DEO will be able to add, modify, delete or view book,
student, faculty/employee and login information.
 The system administrator/library staff will be able to issue, bring back, and reserve
book.
 The system administrator/library staff will be able to query a book in order to check
the availability of the book in the library.
 The system administrator/students/faculty/employee will be able to search a book
from the library catalogue (author-wise, title-wise and publisher-wise).
 The system administrator/library staff will be able to generate various reports from
the LMS.
2.3 User Characteristics
Characteristics of users in terms of their qualification, skills sets and experience should be
specified in this subsection. The user characteristics for the LMS are given as:
2.3 User Characteristics
Qualification: At least matriculation and comfortable with English.
Experience: Should be well versed/informed about the processes of the university library.
Technical experience: Elementary knowledge of computers.

2.4 Constraints
We may list constraints that may limit the developer's implementation options. These constraints
may include:
(i) Regulatory policies
(ii) Hardware limitations
(iii) Interface to other applications
(iv) Parallel operations
(v) Audit functions
(vi) Control functions
(vii) Higher-order language requirements
(viii) Protocols
(ix) Reliability requirements
(x) Safety, security and criticality of the application
The constraints for the LMS are given as:
2.4 Constraints
 The software does not maintain records of periodicals.
 There will be only one administrator.
 The delete operation is available to the administrator and DEO. To reduce the
complexity of the system, there is no check on delete operation. Hence, the
administrator/DEO should be very careful before deletion of any record and he/she
will be responsible for data consistency.
 The user will not be allowed to update the primary key.
2.5 Assumptions and Dependencies
This subsection includes assumptions and dependencies for the implementation of the software
product. These assumptions may be very important and may become input for the design and'
implementation of the software system.

2.5 Assumptions and Dependencies

 The acquisition section of the library will provide the list of the books purchased by
the library.
 The academic section will provide the list of the admitted students (school-wise
and programme-wise).
  The establishment section will provide the list of the faculty members in various
schools of the university. It will also provide the list of employees working in
various branches such as examination, academics, establishment and schools of the
university.
 The login ID and password must be created by the system administrator and
communicated to the concerned user confidentially to avoid unauthorized access to
the system.

2.6 Apportioning of Requirements

This subsection list those requirements that can be delayed and may be incorporated in the future
version of the software system. For the LMS, there is no such requirement.
3. Specific Requirements
All requirements stated in section 2 must be written in detail and at a level sufficient for the
designers to understand and design the system. The testers should test that the requirements are
met by the system. All requirements should conform to the guidelines of good requirements as
discussed in Section 3.6. Some of the characteristics of good requirements are correctness,
completeness, unambiguity, consistence, verifiability, modifiability, traceability, etc.
In addition to the basic format given by IEEE 830-1998, we may also construct Section 3
according to any one of the following additional templates given in Section 3.7 of the SRS.
System Mode
Depending on the mode of operation, we may choose either of the two outlines given in Tables
A and B.
Table A - Template of SRS section 3 organized by mode
3. Specific requirements
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communications interfaces
3.2 Functional requirements
3.2.1 Mode 1
[Link] Functional requirement 1.1
3.2.1.n Functional requirement l.n
3.2.2 Mode2
…
[Link]
 3.2.m.1 Functional requirement m.1
3.2 .. m.n Functional requirement m.n
3.3 .Performance requirements
3.4 Design constraints
3.5 Software system attributes
3.6 Other requirements

Table B - Another template of SRS section 3 organized by mode

3. Specific requirements
3.1 Functional requirements
3.1.1 Mode
[Link] External interfaces
[Link].1 User interfaces
[Link].2 Hardware interfaces
[Link].3 Software interfaces
[Link].4 Communications interfaces
[Link] Functional requirements
.. [Link].1 Functional requirement 1
[Link].n Functional requirement n
[Link] Performance
3.1.2 Mode
2
3.1. Mode
mm mconstraints
3.2 Design
mm
3.3 Software system attributes
3.4 Other requirements

3.1 External Interfaces .

External interfaces provide mechanisms to enter data into the system. Sometimes, we may also
specify the outputs from the software system. We may use different types of forms for the entry
of the data. A few forms of the LMS are given that are used to enter data into the LMS. Formats
for various fields are also defined.
The specific requirements for issuing book in the LMS following the basic format of SRS given
in IEEE Std 830-1998 are given as follows:
3. Specific Requirements
This section contains the software requirements in detail along with the various forms to be
developed.
Issue Book
This form will be accessible only to the system administrator and library staff. It will allow
him/her to issue existing book(s) to the student(s).

Various fields available on this form will be:

 Membership ID: Numeric and will have value from 100 to 19999. The system shall
not allow the user to enter non-numeric characters and out of range values.
 Accession number: Numeric and will have value from 10 to 199999. The system
shall not allow the user to enter non-numeric characters and out of range values.
 Title: Alphanumeric of length 3 to 100 characters. Special characters (except
brackets) are not allowed. Numeric data will be allowed. The system shall not allow
the user to enter special characters and out of range values.
 Issue status (the following member information will be displayed):
o Accession number: Numeric and will have value from 10 to 199999. The
system shall not allow the user to enter non-numeric characters and out of
range values.
o Title: Alphanumeric of length 3 to 100 characters. Special characters (except
brackets) are not allowed. Numeric data will be allowed. The system shall not
' allow the user to enter special characters and out of range values.
o Expected: Date of return. It will be of mm/dd/yyyy format and will have 10
alphanumeric characters. The system shall not allow the user to enter any
other format.
 Reservation status (the following fields will be displayed):
o Accession number: Numeric and will have value from 10 to 199999. The
 system shall not allow the user to enter non-numeric characters and out of
range values.
o Title: Alphanumeric of length 3 to 100 characters. Special characters (except
brackets) are not allowed. Numeric data will be allowed. The system shall not
allow the user to enter special characters and out of range values.
o Reservation date: It will be of mm/dd/yyyy format. It will have 10
alphanumeric characters. The system shall not allow the user to enter any
other format.
o Expected: Date of return. It will be of mm/dd/yyyy format and will have 10
alphanumeric characters. The system shall not allow the user to enter any
other format.

Functions
Functional requirements define the fundamental actions that must take place in the software
when inputs are accepted, and processed, and outputs are accordingly generated. Generally, the
most popular way to implement this process is to write use case description. The use case
description addresses all actions when an actor interacts with the system for a specified purpose.
We may also include validity checks on inputs, sequencing information about operations, and
error handling/response to abnormal situations. A few use case descriptions of LMS are given
below in the specified template. The validity checks and error handling information is also
provided.
MAINTAIN BOOK DETAILS
A. Use Case Description
Introduction
This use case documents the steps that the administrator/DEO must follow in order to
maintain book details and add, update, delete and view book information.
Actors
Administrator
Data entry operator
Precondition
The administrator/DEO must be logged onto the system before this use case begins.
Postcondition
If the use case is successful, then the book information is added, updated, deleted or
viewed. Otherwise, the system state is unchanged.
Flow of Events
Basic Flow
This use case starts when the administrator/DEO wishes to add/update/delete/view book
information.
1. The system requests that the administrator/DEO specify the function he/she would like
 to perform (either add a book, update a book, delete a book or view a book).
2. Once the administrator/DEO provides the requested information, one of the subflows
is executed.
 If the administrator/DEO selects "Add a Book", the Add a Book subflow is
executed.
 If the administrator/DEO selects "Update a Book", the Update a Book subflow is
executed.
 If the administrator/DEO selects "Delete a Book", the Delete a Book subflow is
executed.
 If the administrator/DEO selects "View a Book", the View a Book subflow is
executed.
Basic Flow 1: Add a Book
The system requests that the administrator/DEO enter the book information. This includes:
 Accession number (book barcode ID)
 Subject descriptor
 ISBN
 Title
 Language
 Author-
 Publisher
Once the administrator/DEO provides the requested information, the book is added to the
system.
Basic Flow 2:
Update a Book
1. The system requests that the administrator/DEO enter the accession number.
2. The administrator/DEO enters the accession number.
3. The system retrieves and displays the book information.
4. The administrator/DEO makes the desired changes to the book information. This
includes any of the information specified in the Add a Book subflow.
5. Once the administrator/DEO updates the necessary information, the system updates
the book information with the updated information.
Basic Flow 3: Delete a Book
1. The system requests that the administrator/DEO specify the accession number.
2. The administrator/DEO enters the accession number. The system retrieves and
displays the required information.
3. The system prompts the administrator/DEO to confirm the deletion of the book record.
4. The administrator/DEO verifies the deletion.
5. The system deletes the record.
Basic Flow 4: View a Book
1. The system requests that the administrator/DEO specify the accession number.
2. The system retrieves and displays the book information.
Alternative Flows
Alternative Flow 1: Invalid Entry
If in the Add a Book or Update a Book flow, the actor enters invalid accession
number/ISBN/ title/author/publisher/language/subject descriptor or leaves the accession
number/ISBN/title/ author/publisher/language/subject descriptor empty, the system
displays an appropriate error message. The actor returns to the basic flow and may reenter
the invalid entry.
Alternative Flow 2: Book Already Exists
If in the Add a Book flow, a book with a specified accession number already exists, the
system displays an error message. The administrator returns to the basic flow and may
reenter the book.
Alternative Flow 3: Book Not Found
If in the Update a Book or Delete a Book or View a Book flow, the book information with
the specified accession number does not exist, the system displays an error message. The
administrator returns to the basic flow and may reenter the accession number.
Alternative Flow 4: Update Cancelled
If in the Update a Book flow, the administrator/DEO decides not to update the book, the
update is cancelled and the Basic Flow is restarted at the beginning.
Alternative Flow 5: Delete Cancelled
If in the Delete a Book flow, the administrator/DEO decides not to delete the book, the
delete is cancelled and the Basic Flow is restarted at the beginning.
Alternative Flow 6: Deletion Not Allowed
If in the Delete a Book flow, issue/return/reserve details of the book selected exist, then the
system displays an error message. The administrator returns to the basic flow and may
reenter the student membership number.
Alternative Flow 7: User Exits
This allows the user to exit at any time during the use case. The use case ends.
Special Requirements
None
Associated Use Cases
Login
B. Validity Checks
(i) Only the administrator/DEO will be authorized to access_ the Book Details
module.
(ii) Every book will have a unique accession number.
(iii) Accession number cannot be blank.
(iv) Accession number can only have value from 10 to 199999 digits.
(v) Subject descriptor cannot be blank.
(vi) ISBN number cannot be blank.
(vii) Length of ISBN number for any user can only be equal to 11 digits.
(viii) ISBN number will not accept alphabets, special characters and blank spaces.
(ix) Title cannot be blank.
(x) Length of title can be of 3 to 100 characters.
(xi) Title will only accept alphabetic characters, brackets, numeric digits and blank
spaces.
(xii) Language cannot be blank.
(xiii) Author (first name and last name) cannot be blank.
(a) Length of first name and last name can be of 3 to 100 characters.
(b) First name and last name will not accept special characters and numeric digits.
(xiv) Publisher cannot be blank.
(xv) Length of first name and last name can be of 3 to 300 characters.
(xvi) Publisher will not accept special characters and numeric digits.
C. Sequencing Information
None
D. Error Handling/Response to Abnormal Situations
If any of the validation flows does not hold true, an appropriate error message will be
prompted to the user for doing the needful.

3.3 Performance Requirements

Static and dynamic numerical requirements are addressed. Static numerical requirements may
include:
 (i) The number of terminals to be supported.
(ii) The number of simultaneous users to be supported.
(iii) Amount and type of information to be handled.
Dynamic requirements may include the amount of data to be processed within certain time
periods for both normal and peak load conditions, response time for transactions etc. We may
specify "75% of transactions shall be processed in less than 2 seconds". Hence, response time for
all operations shall be specified. Broadly, it covers those requirements that affect the
performance of the software system. For the LMS, we may specify performance requirements as:
3.3 Performance Requirements
(a) Should support at least 8 terminals.
(b) Should support at least 7 users simultaneously.
(c) Should run on 500 MHz, 512 MB RAM machine.
(d) Responses should be within 2 seconds.

3.4 Logical Database Requirements

We may specify logical requirements for any information that is to be placed into a database. We
may include:
(i) Frequency of use
(ii) Accessing capabilities
(iii) Data entities and their relationships
(iv) Integrity constraints
(v) Data retention policy
The logical database requirements for the LMS are given in Appendix.
3.5 Design Constraints
If there are any specific design constraints due to some standards, hardware and networking
limitations, then those constraints should be specified to help the designers. This may include
any deviation from standard (if any) report format, data naming, accounting procedures, audit
tracing, etc.
3.6 Software System Attributes
Non-functional requirements such as reliability, availability, security, maintainability, usability,
etc. are specified in this subsection. Definitions of some quality attributes are given in Table.
Table - Software quality attributes
[Link] Attribute Description
1 Reliability The extent to which a software product performs its
intended functions without failure.
2 Correctness The extent to which the software meets its specifications.
3 Consistency and The extent to which the software is consistent and gives
 precision results with precision.
4 Robustness The extent to which the software tolerates the unexpected
problems.
5 Simplicity The extent to which the software is simple in its operations.
6 Traceability The extent to which an error is traceable in order to fix it.
7 Usability The extent of effort required to learn, operate and
understand the functions of the software
8 Accuracy Meeting specifications with precision.
9 Clarity and accuracy of The extent to which documents are clearly and accurately
documentation written.
10 Conformity of The extent to which the software is in conformity of
operationalenvironment operational environment.
11 Completeness The extent to which the software has specified functions.
12 Efficiency The amount of computing resources and code required by
the software to perform a function.
13 Testability The effort required to test the software to ensure that it
performs its intended functions.
14 Maintainability The effort required to locate and fix an error during
maintenance phase.
15 Modularity It is the extent of ease to implement, test, debug and
maintain the software.
16 Readability The extent to which the software is readable in order to
understand.
17 Adaptability The extent to which the software is adaptable to new
platforms and technologies.
18 Modifiability The effort required to modify the software during
maintenance phase.
19 Expandability The extent to which the software is expandable without
undesirable side effects.
20 Portability The effort required to transfer a program from one platform
to another platform.

The quality considerations in the LMS are given as follows:

3.6 Software System Attributes
Usability
The application will be user-friendly and easy to operate, and the functions will be easily
understandable.
Reliability
The applications will be available to the students throughout the registration period and
have a high degree of fault tolerance.
Security
The application will be password protected. Users will have to enter correct login ID and
password to access the application.
Maintainability
The application will be designed in a maintainable manner. It will be easy to incorporate
new requirements in the individual modules.
Portability
The application will be easily portable on any windows-based system that has SQL Server
installed.

IEEE Std 830-1998 has given various ways to organize section 3 and depending on the project,
customer's expectations and developers expertise, we may choose one way for the organization
of the SRS document.
3.7 Organizing the Specific Requirements
The details are given in the beginning of section 3.
3.8 Additional Comments
We may choose any one organization and the selection is dependent on the developer's expertise,
previous experience, customer's expectations, available technologies, etc. Sometimes, more than
one organization may also be used for organizing section 3 of the SRS document.
4. Supporting Information
Supporting information makes the SRS easier to use. It may include table of contents, index,
appendixes, etc.