Software Requirements Specification-SETS

MKCL
SETS
Software Requirements Specification
Version <1.0>
[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in
square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author
and should be deleted before publishing the document. A paragraph entered following this style will
automatically be set to normal (style=Body Text).]
[To customize automatic fields (which display a gray background when selected), select File>Properties and
replace the Title, Subject and Company fields with the appropriate information for this document. After
closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All
(or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for
Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See
Word help for more information on working with fields.]
[Note: The Software Requirements Specification (SRS) captures the complete software requirements for
the system, or a portion of the system. Following is a typical SRS outline for a project using only
traditional natural-language style requirements – with no use-case modeling. It captures all
requirements in a single document, with applicable sections inserted from the Supplementary
Specifications (which would no longer be needed). For a template of an SRS using use-case modeling,
which consists of a package containing use cases of the use-case model and applicable Supplementary
Specifications and other supporting information, see rup_srs-uc.dot.]
Many different arrangements of an SRS are possible. Refer to [IEEE93] for further elaboration of these
explanations, as well as other options for SRS organization.]
SETS Version: <1.0>
Software Requirements Specification Date: <02/Apr/06>
<document identifier>
Revision History
Date Version Description Author
<dd/mmm/yy> <x.x> <details> <name>
Confidential MKCL, 2006 Page 2

SETS Version: <1.0>
Table of Contents
1. Introduction 0
1.1 Purpose 0
1.2 Scope 0
1.3 Definitions, Acronyms and Abbreviations 0
1.4 References 0
1.5 Overview 0
2. Overall Description 0
3. Specific Requirements 0
3.1 Functionality 0
3.1.1 <Functional Requirement One> Error! Bookmark not defined.
3.2 Usability 0
3.2.1 <Usability Requirement One> 0
3.3 Reliability 0
3.3.1 <Reliability Requirement One> 0
3.4 Performance 0
3.4.1 <Performance Requirement One> 0
3.5 Supportability 0
3.5.1 <Supportability Requirement One> 0
3.6 Design Constraints 0
3.6.1 <Design Constraint One> 0
3.7 Online User Documentation and Help System Requirements 0
3.8 Purchased Components 0
3.9 Interfaces 0
3.9.1 User Interfaces 0
3.9.2 Hardware Interfaces 0
3.9.3 Software Interfaces 0
3.9.4 Communications Interfaces 0
3.10 Licensing Requirements 0
3.11 Legal, Copyright and Other Notices 0
3.12 Applicable Standards 0
4. Supporting Information 0

SETS Version: <1.0>
Software Requirements Specification

1. Introduction
[The introduction of the SRS should provide an overview of the entire SRS. It should include the purpose,
scope, definitions, acronyms, abbreviations, references and overview of the SRS.]
Secure e-Tendering System (SETS) is an exclusive, most vibrant end to end solution for buying / selling of products
and services through tendering process. It supports complete lifecycle procedures of tendering from requisition to
comparative statement generation. Procedures related to tendering like vendor registration, tender publishing, tender
form preparation, opening, scrutiny and tender awarding are supported in a real time interactive environment. SETS
create a real dynamic market place for both buyers and vendors to interact with each other and participate in real time
procurement transaction. SETS service provides a simple, secure and efficient system to manage tendering activities
thus reducing the time, effort and cost involved in the procurement cycle for both Suppliers and the Organization.
1.1 Purpose
[Specify the purpose of this SRS. The SRS should fully describe the external behavior of the application or
subsystem identified. It also describes nonfunctional requirements, design constraints and other factors
necessary to provide a complete and comprehensive description of the requirements for the software.]
1.2 Scope
[A brief description of the software application that the SRS applies to; the feature or other subsystem
grouping; what Use Case model(s) it is associated with, and anything else that is affected or influenced by
this document.]
1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to
interpret properly the SRS. This information may be provided by reference to the project Glossary.]
1.4 References
[This subsection should provide a complete list of all documents referenced elsewhere in the SRS. Each
document should be identified by title, report number (if applicable), date, and publishing organization.
Specify the sources from which the references can be obtained. This information may be provided by
reference to an appendix or to another document.]
1.5 Overview
[This subsection should describe what the rest of the SRS contains and explain how the SRS is organized.]
2. Overall Description
[This section of the SRS should describe the general factors that affect the product and its requirements.
This section does not state specific requirements. Instead, it provides a background for those
requirements, which are defined in detail in section 3, and makes them easier to understand. Include such
items as:
 product perspective,
 product functions,
 user characteristics,
 constraints,

SETS Version: <1.0>
 assumptions and dependencies, and

 requirements subsets.]
3. Specific Requirements
[This section of the SRS should contain all the software requirements to a level of detail sufficient to enable
designers to design a system to satisfy those requirements, and testers to test that the system satisfies
those requirements. When using use-case modeling, these requirements are captured in the use cases
and the applicable supplementary specifications. If use-case modeling is not used, the outline for
supplementary specifications may be inserted directly into this section, as shown below.]
The application will have the functionality distributed in modules. The following modules are in thought as
of this version.
Sr. No Main Modules Intent

1 Registration This will have responsibility for various registration
functions which vendors need to fulfill
2 Tenders This module will be use by vendors/companies to
carry out the important tasks related to tenders
3 Bids This module will help the vendor to execute
functions related to submitted bids against the
tenders
4 Notices This module will help the vendor to browse the
public notices regarding tenders
5 Openings The aim of this module is to help participate the
vendor in the opening activity
6 Meetings The module will help vendors to attend the prebid
or any such meeting online
7 Reports The module will take care of reporting activities
8 Utilities The module will have functions related to changing
of password/ lost password/general search of
information
3.1 Functionality
[This section describes the functional requirements of the system for those requirements which are
expressed in the natural language style. For many applications, this may constitute the bulk of the SRS
Package and thought should be given to the organization of this section. This section is typically organized
by feature, but alternative organization methods, for example organization by user, or organization by
subsystem may also be appropriate. Functional requirements may include: feature sets, capabilities and
security.
Where application development tools (requirements tools, modeling tools, etc) are employed to capture the
functionality, this section document will refer to the availability of that data and indicate the location and
name of the tool which is used to capture the data.2650-7138]
Registration
Vendors before participating in e-Tendering activities need to register themselves online. Registration will
help the system authenticate the correct vendor and also maintain his profile and deliver the necessary
customized information to him periodically. Two types of registration is being envisages as of this version.
Sr. No Main Modules Intent

SETS Version: <1.0>
1 Basic This will enable the vendors with basic facilities of

delivering information of tenders to vendors
through email/sms. This will not let him take part in
core tendering activities
2 Basic+ This registration will enable the vendors to take
part in core tendering activities. For instance
purchasing of tender/filling/submission etc
3 Company Specific Apart from the Basic+, the sourcing company might
want to ask company specific registration which
might contain questions regarding the specific
business information the company is dealing in.
This registration will not be discussed as the
requirements are purely based on sourcing agency
and will be drafted only at the time of customized
implementation
3.1.1 Basic Registration
Basic Registration aims to provide vendors as a starting point to interact with the system. This registration will
help the vendors get information about tenders published in the system by various sourcing companies registered
with the system. The information will be delivered via email/SMS and also can be viewed online through the web
interface. Basic registration is a free registration where the vendor will not be charged for the information. Being
free, there are limitations in terms of services the vendor will have access to. For instance he will not have access
to core e-Tendering service like purchasing/filling/submission of tenders. The idea of basic registration is to hook
the vendor in the system and provide him the information his interest by virtue of which he will be motivated to
upgrade his membership to next level.
3.1.1.1 Use Case
Identifier UC-1
Rank High
Parent System
Scenario Main
This use case captures the flow of vendor applying for the basic services of SETS. The Basic
Brief Description SETS registration is a three step process at the end of which the user is considered
registered SETS vendor
Preconditions Vendor must not be already registered with the system
Sr. No Actor input System response

SETS Version: <1.0>
Vendor clicks on New Register link on the home

1
page
Opens a new window displaying registration wizard
with first page showing general information about
2
the registration procedure and selection box for the
type of registration
Vendor does the following
a. selects communication language as ‘English’
3
b. selects registration as ‘Basic’
c. clicks Next button
System displays the first step of registration which
4
gather the user profile data
Vendor inputs the user profile following information
5
and clicks Next button
System validates the user profile data and if
successful saves the data and navigates the user to
6 the next step of registration which is used to gather
company information and item category
information
Vendor inputs/selects the inputs on Company
7
Information page and clicks Next
successful saves the data and navigates the user to
8
the next step of registration which is use to capture
item category information
Vendor selects the respective item categories he is
9
interested in and clicks Finish
successful saves the data. System sends an email
10
to the vendor stating that he is now registered with
SETS and also an activation link embedded in it.
Vendor checks his email received from the system
11
and clicks on the Activation link
System shows him a page stating his registration
12
status as successful along with a link to login page
3.1.1.2 Business Validations
Sr. No UI Artifact Validations

1 Introduction Screen 1 All fields selection are mandatory
2 User Profile Screen 1 All the fields are mandatory
2 Username should be unique

SETS Version: <1.0>
3 Password length should be >=6 & <=15

characters
4 Confirm password and Password field data
should match
5 Email should have [@,.] as a part of input
6 Mobile no should include the country code
e.g. +91
3 Company Profile 1 All fields are mandatory

2 Company should not contain special
characters except [., (, )]
3 Registration Date should be less than today
4 Atleast one business type should be selected
5 District, City should not contain numeric data
or any special characters
6 Tel, Fax fields should not contain alphabets
or special characters except [+]
7 Pincode should not be > 7 digits and should
not contain alphabets or any special chars
4 Item Category Selection 1 Atleast one item category should be selected
3.1.1.3 Database Relations

The following fields will get affected due to this functionality
Screen Introduction, UserProfile

Table SETS_COMMON.USERS
Name Comments
USERID Need to be generated automatically
USERNAME
PASSWORD
EMAIL
MOBILE
LOCALEID
SECRETANSWER
SECRETQUESTIONID
Screen CompanyDetails
Table SETS_COMMON.COMPANYDETAILS
Name Comments
COMPANYNAME
REGISTRATIONNO
REGISTRATIONDATE
ADDRESS

SETS Version: <1.0>
CITY
PINCODE
TEL1
TEL2
FAX1
FAX2
USERID
STATEMASTERSTATEID
COUNTRYID
COMPANYTYPEID
BUSINESSTYPEID
DISTRICT
Screen Item Category

Table SETS_COMMON. VENDOR_CATEGORY_INTEREST
Name Comments
ITEMCATEGORYID
USERID
3.1.2 Basic+ Registration
Basic+ Registration aims to provide vendors an opportunity to get going with etendering services. This registration
will help the vendors get information about tenders published plus they will have access to core e-Tendering
service like purchasing/filling/submission of tenders. This will be a charged registration unlike basic which is free.
As he will be participating in the core services the information required from the vendor will involve more steps. In
these steps he will write about his factory details, his past experiences he will upload some important documents.
Once the vendor has registered his case will be scrutinized by MKCL authorities against the physical documents
and then the registration will be completed. In this case the vendor will receive two emails one after his
registration and one post his verification. The email after his registration will have an activation link which he must
click in order to start his verification process and the other email post verification will have general details and a
link for pdf containing the data which has been verified. Once the verification process has started vendor cannot
edit his details. In case of unsuccessful verification he will be able to edit his registration details.
3.1.2.1 Use Case
Identifier UC-2
Rank High
Parent UC-1
Scenario Main
Brief Description This use case captures the flow of vendor applying for the Basic+ services of SETS.
Preconditions Vendor must not be already registered with the system

SETS Version: <1.0>
Sr. No Actor input System response

As this use case extends UC-1 the interaction will
1 follow from the after screen of item category
selection
1 Vendor clicks on Next
System displays the next page of entering
2
management details of company
3 Vendor clicks New
System opens a new window for entering new
management details
Vendor enters the required management
4
information and presses save
System saves the data to the database, on
successful save closes the window and adds the
5 recently saved management personnel name to the
select grid on the screen. Which can be used by
vendor to re-edit the saved data
Vendor repeats step-3,4 to save more
6
management details

On completion of entering management details
7
vendor clicks ‘Next’
System navigates the user to the next screen for
entering factory details this screen will only be
8 shown to vendors whose business type is of
‘Manufacturer’ else he will be navigated to other
details screen
9 Vendor clicks ‘New’ on the factory details screen
10
factory details
Vendor enters the mandatory information of factory
11
the company owns and clicks ‘Save’
System validates the info and saves the factory
details to the database, closes the window and
12
adds the recently saved factory name to the select
grid on the screen.
Vendor repeats step-9,11 to save more factory
13
details and on completion clicks ‘Next’
14
other general certification/affiliation details

SETS Version: <1.0>
Vendor clicks ‘New’ on the certification/affiliation

15
details screen
16
certification/affiliation details
Vendor enters the mandatory information of
17 certification/affiliation the company has and clicks
‘Save’
System validates the info and saves the
certification/affiliation details to the database,
18 closes the window and adds the recently saved
certification/affiliation name to the select grid on
the screen.
Vendor repeats step-15,17 to save additional
19 certification/affiliation details and on completion
clicks ‘Next’
uploading important documents details. The
documents will be of mandatory/non-mandatory
20
nature. The list of documents will be automatically
built based on the certificates he entered on the
previous screen
21 Vendor selects the document and clicks ‘Upload’
System uploads the document into configured DMS
22 and shows the appropriate progress while
uploading and confirmation of upload
Vendor repeats step-21 to repeat the uploading of
23
other documents and on done clicks ‘Next’
System navigates the user to next page for online
24
payment
25 Vendor makes the online payment
System verifies the payment the navigates the user
26
to the last page
27 Vendor reads the instruction and clicks ‘Finish’
System sends an email to vendor asking him to
click on a link to activate his account and also
28
stating his account details along with payment
details
29 Vendor receives the email and clicks on the link
30 System activates the vendors account

SETS Version: <1.0>
3.1.2.2 Business Validations
Sr. No UI Artifact Validations

1 Management Screen 1 All fields selection are mandatory
2 User Profile Screen

1 All the fields are mandatory
2 Username should be unique
3 Password length should be >=6 & <=15
characters
4 Confirm password and Password field data
should match
5 Email should have [@,.] as a part of input
6 Mobile no should include the country code
e.g. +91
3 Company Profile
1 All fields are mandatory
2 Company should not contain special
characters except [., (, )]
3 Registration Date should be less than today
4 Atleast one business type should be selected
5 District, City should not contain numeric data
or any special characters
6 Tel, Fax fields should not contain alphabets
or special characters except [+]
4 Item Category Selection 7 Pincode should not be > 7 digits and should
not contain alphabets or any special chars
1 Atleast one item category should be selected
3.1.2.3 Database Relations

The following fields will get affected due to this functionality
Screen Introduction, UserProfile

Table SETS_COMMON.USERS
Name Comments
USERID Need to be generated automatically
USERNAME
PASSWORD
EMAIL
MOBILE

SETS Version: <1.0>
LOCALEID
SECRETANSWER
SECRETQUESTIONID
3.2 Usability
[This section should include all of those requirements that affect usability. Examples:
 Specify the required training time for a normal users and power users to become productive at
particular operations.
 Specify measurable task times for typical tasks, or
 Base usability requirements of the new system on other systems that the users know and like.
 Specify requirements to conform to common usability standards – e.g., IBM’s CUA standards, or the
GUI standards published by Microsoft for Windows 95.]
3.2.1 <Usability Requirement One>

The requirement description.
3.3 Reliability
[Requirements for reliability of the system should be specified here. Suggestions:
 Availability – specify % of time available ( xx.xx%), hours of use, maintenance access, degraded mode
operations etc.
 Mean Time Between Failures (MTBF) – this is usually specified in hours, but it could also be specified in
terms of days, months, or years.
 Mean Time To Repair (MTTR) – how long is the system allowed to be out of operation after it has
failed?.
 Accuracy – specify precision (resolution) and accuracy (by some known standard) that is required in the
systems output.
 Maximum bugs or defect rate – usually expressed in terms of bugs/KLOC (thousands of lines of code),
or bugs per function-point.
 Bugs or defect rate – categorized in terms of minor, significant, and critical bugs: the requirement(s)
must define what is meant by a “critical” bug (e.g., complete loss of data, complete inability to use
certain parts of the functionality of the system).]
3.3.1 <Reliability Requirement One>

[The requirement description.]
3.4 Performance
[The performance characteristics of the system should be outlined in this section. Include specific response
times. Where applicable, reference related Use Cases by name.
 Response time for a transaction(average, maximum)
 Throughput (e.g., transactions per second)
 Capacity (e.g., the number of customers or transactions the system can accommodate)

SETS Version: <1.0>
 Degradation modes (what is the acceptable mode of operation when the system has been degraded in
some manner)
 Resource utilization: memory, disk, communications, etc.]
3.4.1 <Performance Requirement One>

3.5 Supportability
[This section indicates any requirements that will enhance the supportability or maintainability of the
system being built, including coding standards, naming conventions, class libraries, maintenance access,
maintenance utilities.]
3.5.1 <Supportability Requirement One>

3.6 Design Constraints

[This section should indicate any design constraints on the system being built. Design constraints represent
design decisions that have been mandated and must be adhered to. Examples include software languages,
software process requirements, prescribed use of developmental tools, architectural and design constraints,
purchased components, class libraries, etc.]
3.6.1 <Design Constraint One>

3.7 Online User Documentation and Help System Requirements

[Describes the requirements, if any, for on-line user documentation, help systems, help about notices, etc.]
3.8 Purchased Components

[This section describes any purchased components to be used with the system , any applicable licensing or
usage restrictions, and any associated compatibility/interoperability or interface standards.]
3.9 Interfaces
[This section defines the interfaces that must be supported by the application. It should contain adequate
specificity, protocols, ports and logical addresses, etc, so that the software can be developed and verified
against the interface requirements.]
3.9.1 User Interfaces

[Describe the user interfaces that are to be implemented by the software.]
3.9.2 Hardware Interfaces

[This section defines any hardware interfaces that are to be supported by the software, including logical
structure, physical addresses, expected behavior, etc. ]
3.9.3 Software Interfaces

[This section describes software interfaces to other components of the software system. These may be
purchased components, components reused from another application, or components being developed for
subsystems outside of the scope of this SRS, but with which this software application must interact.]

SETS Version: <1.0>
3.9.4 Communications Interfaces

[Describe any communications interfaces to other systems or devices such as local area networks, remote
serial devices, etc.]
3.10 Licensing Requirements

[Defines any licensing enforcement requirements or other usage restriction requirements which are to be
exhibited by the software.]
3.11 Legal, Copyright and Other Notices

[This section describes any necessary legal disclaimers, warranties, copyright notices, patent notice,
wordmark, trademark, or logo compliance issues for the software.]
3.12 Applicable Standards

[This section describes by reference any applicable standards, (and the specific sections of any such
standards which apply to the system being described). For example, this could include legal, quality and
regulatory standards, industry standards for usability, interoperability, internationalization, operating
system compliance, etc.]
4. Supporting Information
[The supporting information makes the SRS easier to use. It includes: a) Table of contents, b) Index, c)
Appendices. These may include use-case storyboards or user-interface prototypes. When appendices are
included, the SRS should explicitly state whether or not the appendices are to be considered part of the
requirements.]

SETS Version: <1.0>

Software Requirements Specification-SETS

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Requirements Specification-SETS

Uploaded by

Copyright:

Available Formats

MKCL

Confidential MKCL, 2006 Page 2

Confidential MKCL, 2006 Page 3

Software Requirements Specification

1.3 Definitions, Acronyms and Abbreviations

Confidential MKCL, 2006 Page 4

 assumptions and dependencies, and

Sr. No Main Modules Intent

Confidential MKCL, 2006 Page 5

1 Basic This will enable the vendors with basic facilities of

3.1.1 Basic Registration

3.1.1.1 Use Case

Confidential MKCL, 2006 Page 6

Vendor clicks on New Register link on the home

3.1.1.2 Business Validations

Sr. No UI Artifact Validations

Confidential MKCL, 2006 Page 7

3 Password length should be >=6 & <=15

3 Company Profile 1 All fields are mandatory

3.1.1.3 Database Relations

Screen Introduction, UserProfile

Confidential MKCL, 2006 Page 8

Screen Item Category

3.1.2 Basic+ Registration

3.1.2.1 Use Case

Confidential MKCL, 2006 Page 9

Sr. No Actor input System response

Confidential MKCL, 2006 Page 10

Vendor clicks ‘New’ on the certification/affiliation

Confidential MKCL, 2006 Page 11

3.1.2.2 Business Validations

Sr. No UI Artifact Validations

2 User Profile Screen

3.1.2.3 Database Relations

Screen Introduction, UserProfile

Confidential MKCL, 2006 Page 12

3.2.1 <Usability Requirement One>

3.3.1 <Reliability Requirement One>

Confidential MKCL, 2006 Page 13

3.4.1 <Performance Requirement One>

3.5.1 <Supportability Requirement One>

3.6 Design Constraints

3.6.1 <Design Constraint One>

3.7 Online User Documentation and Help System Requirements

3.8 Purchased Components

3.9.1 User Interfaces

3.9.2 Hardware Interfaces

3.9.3 Software Interfaces

Confidential MKCL, 2006 Page 14

3.9.4 Communications Interfaces

3.10 Licensing Requirements

3.11 Legal, Copyright and Other Notices

3.12 Applicable Standards

Confidential MKCL, 2006 Page 15

Confidential MKCL, 2006 Page 16

You might also like