2.1 project management srs

ENVISION ENTERPRISE SOLUTIONS PVT LTD Doc Reference No:
SOFTWARE REQUIREMENT SPECIFICATIONS TMP/SRS/V.1.0/00
Software Requirement Specifications
Version 1.0
Project Name
Prepared By
[Pick the date]
[Type the abstract of the document here. The abstract is typically a short summary of the contents of
the document. Type the abstract of the document here. The abstract is typically a short summary of
the contents of the document.]

SOFTWARE REQUIREMENT SPECIFICATIONS PM/SRS/00
5/6/2013 Version 1.0 2
Document Amendment Record
*A-Added, M-Modified, D-Deleted
Version
No.
Date A/M/D* Section
No.
Description of Change
1.0 15/1/2013 A
Review Log
Version No. Reviewed By Review Date Comments
Approved By
Version No. Approved By Approved Date Comments
Copyright
No part of this volume may be reproduced or transmitted in any form or by any means electronic or
mechanical including photocopying and recording or by any information storage or retrieval system
except as may be expressly permitted by Envision.

5/6/2013 Version 1.0 3
1 Introduction........................................................................................................................ 5
1.1 Purpose of SRS............................................................................................................. 5
1.2 Scope of the Project...................................................................................................... 6
1.3 Definitions and Acronyms........................................................................................... 6
1.4 References.................................................................................................................... 6
2 OVERALL DESCRIPTION.................................................................................................. 7
2.1 Product Perspective ..................................................................................................... 7
2.1.1 System Interfaces.................................................................................................. 8
2.1.2 User Interfaces...................................................................................................... 8
2.1.3 Hardware Interfaces ............................................................................................. 8
2.1.4 Software Interfaces ............................................................................................... 8
2.1.5 Communications Interfaces .................................................................................. 8
2.1.6 Memory Constraints............................................................................................. 9
2.1.7 Operations............................................................................................................ 9
2.1.8 Site Adaptation Requirements .............................................................................. 9
2.1.9 Product Functions................................................................................................. 9
2.1.10 User Characteristics.............................................................................................10
2.1.11 Constraints ..........................................................................................................10
2.1.12 Assumptions and Dependencies..........................................................................11
2.1.13 Apportioning of Requirements ............................................................................11
3. SPECIFIC REQUIREMENTS.......................................................................................11
3.1 External Interface Requirements..............................................................................14
3.1.1 User Interfaces.....................................................................................................14
3.1.2 Hardware Interfaces ............................................................................................14
3.1.3 Software Interfaces ..............................................................................................14
3.1.4 Communications Interfaces .................................................................................14
3.2 Software Product Features..........................................................................................14
3.2.1 Feature.................................................................................................................14
3.2.2 Purpose ...............................................................................................................15
3.2.3 Stimulus/Response Sequence...............................................................................15
3.2.4 Associated Functional Requirements ...................................................................15

5/6/2013 Version 1.0 4
3.2.5 Functional Requirements.....................................................................................15
3.3 Performance Requirements.........................................................................................15
3.4 Design Constraints .....................................................................................................15
3.5 Software System Attributes.........................................................................................15
3.5.1 Reliability ............................................................................................................15
3.5.2 Availability..........................................................................................................15
3.5.3 Security................................................................................................................16
3.5.4 Maintainability ....................................................................................................16
3.5.5 Portability............................................................................................................16
3.6 Logical Database Requirements ..................................................................................16
3.7 Other Requirements....................................................................................................17
4. INDEX...............................................................................................................................17
5. APPENDICES....................................................................................................................17
5.1 Screens, Forms and Reports Given by the User...........................................................17
5.2 Traceability Table .......................................................................................................17
5.3 SDD <provide reference to system design document> .........................................17

5/6/2013 Version 1.0 5
1 Introduction
1.1 Purpose of SRS
This Software Requirements Specifications (SRS) specifies the general factors like the
external interfaces, evolution or growth path of the system, functional requirements, user
characteristics and the assumptions, dependencies and risks associated with the
iPortman Administration module
In addition certain common considerations like external interface specifications, user interface, hardware
interface, software interface, performance requirements, attributes such as availability and security are
specified in the SRS. Environment required for development, integration and testing are also identified.
The intended audience for the SRS is the Project Leader (PL), the Team members and the customer.
The applications of the software system are as follows:
System Administration
• Multi Company
• Company Definitions, Calendar, Financial Periods
• Multi Ports
• Users Management – Access, Groups, Credentials
• Access Controls – Applications – Add / Modify / Read only
• Documents Access Control
• MIS Reports access
• Approval Process and Limits
• Transaction Approval Work flow
• Alert Management – SMS/ e-Mail notifications
• Back up policy based on time as well as volume
• Document management System Configurations
• Firewall configuration
• Application Transaction Numbering System Series

5/6/2013 Version 1.0 6
The benefits of the software system are as follows:
• Improves operations control
• Improves the vessel turnaround time
• Increases personnel productivity and manpower utilization
• Improves effective communication, coordination and controls in systems and
processes
• Improves real time data availability.
• Streamlines operational processes
• End to end web based Integrated port management Solution
• Built in BIRT reporting and configurable workflow manager
• Streamlines operational processes
• Role based configurable Start Center, Dashboard with KPI’s, Favorites, eMail
notification – Inbox
• More user friendly screens.
The objectives and goals of the software system are as follows:
1.2 Scope of the Project
This sub-section states the scope of work (in terms of stages in the software development life cycle) and the
role-played by Envision
1.3 Definitions and Acronyms
This sub-section defines all terms, acronyms and abbreviations used in the project and explain all
conventions of nomenclature, special symbols used, etc.
1.4 References
This sub-section provides a complete list of all documents referred to in the SRS, or those on which the SRS
is based.

5/6/2013 Version 1.0 7
2 OVERALL DESCRIPTION
In this section, describe the general factors that affect the product and its requirements. This section
should contain background information, not state specific requirements.
No text is necessary between the heading above and the heading below unless otherwise desired.
* Product perspective section is applicable for software products only
2.1 Product Perspective
Administration:
Default Configuration
o Country
o State
o City
o Currency
System Initialization
o Group Company Details
o Company Details
o Port Details
o Branch
o Department
o Shift Master
o Document Series
o Document Master
o SMTP Configuration
o Mail Configuration
o Document Meta-Data
User Management
o User Master
o Role Configuration
o KPI Configuration
Work Flow
o Workflow Status
o Workflow Report
o Approval Configuration
Document Configuration
o Document Print Layout

5/6/2013 Version 1.0 8
This section should place the product in perspective with other related products. If the product is
independent and self-contained, state that here. Otherwise, identify interfaces between the product and
related systems.
2.1.1 System Interfaces
List each system interface and identify the related functionality of the product.
2.1.2 User Interfaces
Specify the logical characteristics of each interface between the software product and its users (e.g.,
required screen formats, report layouts, menu structures, or function keys).
Specify all the aspects of optimizing the interface with the person who must use the system (e.g., required
functionality to provide long or short error messages). This could be a list of do’s and don’ts describing
how the system will appear to the user.
2.1.3 Hardware Interfaces
Specify the logical characteristics of each interface between the software product and the hardware
components of the system. This includes configuration characteristics (e.g., number of ports, instruction
sets), what devices are to be supported, and protocols.
2.1.4 Software Interfaces
Specify the use of other required software products (e.g., a DBMS or operating system), and interfaces
with other application systems. For each required software product, provide the following:
Name
Mnemonic
Specification Number
Version Number
Source
For each interface, discuss the purpose of the interfacing software, and define the interface in terms of
message format and content. For well-documented interfaces, simply provide a reference to the
documentation.
2.1.5 Communications Interfaces
Specify any interfaces to communications such as local area networks, etc.

5/6/2013 Version 1.0 9
2.1.6 Memory Constraints
Specify any applicable characteristics and limits on RAM, disk space, etc.
2.1.7 Operations
Specify any normal and special operations required by the user, including:
periods of interactive operations and periods of unattended operations
data processing support functions
backup and recovery operations
2.1.8 Site Adaptation Requirements
Define requirements for any data or initialization sequences that are specific to a given site,
mission, or operational mode. Specify features that should be modified to adapt the software to a
particular installation
* this product functions is applicable only for software products.
2.1.9 Product Functions
Multi port : This function is used to enable the operations of multiple ports that are commencing
import export operations with their port code, city, county and the currency of the country, those were
using this application
Multi Group, companies, Branches in one application: This feature will facilitate the application
to be used by different group of companies. Each group may have multiple companies and each
company may have different branches
Multiple Series of document: This will enable to create the multiple series of documents with
unique serial numbers for the each document or form . These can be changed in any particular period
which can be noted for the further reference and those can also be easily differentiated. Assigning the
prefixes and suffixes
User configuration: Any number of user can be created, activate/inactivate and update. it enables to
assigned user Id and Passwords to Access the Application, which can be configured periodically and
the user will also given the option to change the password upon his will or can be compelled to
change periodically to maintain the optimum security
Role configuration: For each user created the customized role can be assigned through which we can
create the multiple user levels and restrict the user access to the application depending on the
necessity. this facilitate to give view, edit, update, delete, Export to Excel permission for each user
and each form
KPI/KPI configuration: This will display the data with charts and graphs about the happening in the
port. Example KPI Are: Stock Cargo Status, cargo handling (for particular period) berth

5/6/2013 Version 1.0 10
Occupancy Percentage, Total Vessel count, cargo operation status etc. And this can be configured
for visibility to each user
Work flow configuration: With this feature we can assignee the approving Authority for each form
that is drafted during the port operations. In this we can also create the different levels (hierarchy) of
approvals and a user can be assigned to each level (hierarchy). The status of approvals for each form
can be viewed and the consolidated report also be generated
Work flow status & report: This function will facilitate to view the status if the form. This
will display the details like what application it is, who are the originator, date of origination,
action performed on that particular document and date of action, stage of flow and the status,
version. Can also generate the report to each work flow this with the details of Application,
document number, originated by and date, document status and stage.
Mail configuration: This facilitate to send the mails with the pre defined reports that were
automatically generated and forwarded in defined intervals. We can define to whom the report have
to be send and from whom
Provide a summary of the major functions that the software will perform.
/* this user characteristics section is applicable only for software products.
2.1.10 User Characteristics
Describe the general characteristics of the intended users, including
educational level
experience
technical expertise
2.1.11 Constraints
Describe any other items that will constrain the design options, including
regulatory policies
hardware limitations
interfaces to other applications
parallel operation
audit functions
control functions
higher-order language requirements
signal handshake protocols

5/6/2013 Version 1.0 11
reliability requirements
criticality of the application
safety and security considerations
2.1.12 Assumptions and Dependencies
List factors that affect the requirements. These factors are not design constraints, but areas where future
changes might drive change in the requirements..
2.1.13 Apportioning of Requirements
Identify any requirements that may be delayed until future versions of the system.
3. SPECIFIC REQUIREMENTS
Default Configuration: This the menu used to configure details of the different
countries, states their cities and their currencies were the ports located and the possibility
of vessels visiting to/from those ports. This has the sub menus as
Country: In this we need to enter the country code and country Name
State: Here the data state code, state name and which country it belongs to need to
be entered
City: in this form city code, city name and which state it belongs to need to me
entered
Currency: we enter the different currencies which were circulating in the trade
with the details like currency type code, currency type description, base
currency and which country it belongs to
System Initialization: This menu is to configure the details of the particular company or
a group company which handles the port or group of ports operations using iPortman.
This will capture the details using the below forms
Group Company Details: This will capture the detail of the group which is having
different companies under it. The details include the Group Code, Name,
complete address and contact details along with the time and date format it
follows and the current used to trade with.
Company Details: This form will capture the details of the different companies
with company code, Name and the group under which it is operating. This also
captures the complete address and the contact details along with the time and date
format that the particular company follows and the current used to trade with

5/6/2013 Version 1.0 12
Port Details : This will capture the details of the port with Port Code, Name and
the company under which it is operating. This also captures the complete address
and the contact details along Latitude, Longitude and with the time and date
format that the particular company follows and the current used to trade with
Branch : This form need to be filled if the company is having any branches with
the details Branch Code and Name
Department : this will configure the details of the entire departments in the
particular company with detail of Department code, name, Company & group it
belongs to
Shift Master : this will capture the Detail of the shifts that the port is operating
with the shift code, Name with the Start and end timings of the shift
Document Series: This form will define the series of the documents and forms so
that a unique identification number will be assigned to each form that is posted.
By fill the detail we can define the range of the series (1-9999999) along with the
details like Document Series Code ,Series Prefix ,Series Suffix, Financial
Period(define the name particular period the series will used), Default
Series(check box to define whether it’s a default or not), lock(if the particular
series is not locked the it has to be default, if u want to. At any particular time
only one series will be default and unlocked the remaining will be in locked state)
Document Master : This will define the different document and the form that
were maintained and filled during the port operations. This captures only
Document Name and the Document Code (it doesn’t have the functional
significance in the front as the documents and forms which were used in the
operation were all ready defined in the back end with the field and significances,
this just for the reference purpose)
SMTP Configuration : This will configure hosting details which enables the mail
forwarding
Mail Configuration : This used to configure the E-mail settings to send the report,
here user will define the host server details and mail Id from which mail has to be
sent and the mail Id from to which mail had to be received
Document Meta-Data :
User Management : This is used to configure users of the iPortman, here new users will
be added, roles and credentials will be assigned/updated
User Master: here the new user will be created by taking the details like User
Code, name and the company and the branch he belongs to

5/6/2013 Version 1.0 13
Role Configuration: Using this we can assigned or update the roles for the each
user. Using this define the permission for each role and each user as No Access,
Limited Access, Full Access and also can define the permission like View, Add,
Update, Cancel, Export to Excel
KPI Configuration: This is used to define the dash board permissions
Work Flow : this is the module used to define the flow of the forms and to view the status
of each form whether it is approved by the particular approval authority or it is pending for
approval and at what stage it is pending, for doing this the below three tabs were used
Workflow Status: This tab is used view the status if the form. this will show
details like what application it is, originator, date of origination, action performed
on that particular document and date of action, stage of flow and the status,
version.
Workflow Report: this will display the report of the each work flow this will
display the detail as, Application, document number, originated by and date,
document status and stage.
Approval Configuration: using this we can assign the approval authority (user) for
each document that will be submitted during the flow/operation
Document Configuration: This is used to configure and assign the print layout of the
documents that were needed to be printed
Document Print Layout : this is used to assign the document to the print layout
This section should describe all software requirements at a sufficient level of detail for designers to design
a system satisfying the requirements and testers to verity that the system satisfies requirements.
Every stated requirement should be externally perceivable by users, operators or other external systems.
At a minimum, these requirements should describe every input into the software, every output from the
software, and every function performed by the software in response to an input or in support of an
output.
All requirements should be uniquely identifiable (e.g., by number).
The remainder of this sample document is organized according to A.5 Template of SRS Section 3
Organized by Feature shown in the Annex of Std 830-1993. For alternative organizational schemes by
system mode, user class, object, stimulus, functional hierarchy, and combinations, see

5/6/2013 Version 1.0 14
3.1 External Interface Requirements
Provide a detailed description of all inputs into and outputs from the software. This section should
complement the interface descriptions under section 2.1 and should not repeat information there. Include
both content and format as follows:
name of item
description of purpose
source of input or destination of output
valid range, accuracy, and/or tolerance
units of measure
timing
relationships to other inputs/outputs
screen formats/organization
window formats/organization
data formats
command formats
end messages
These requirements may be organized in the following subsections.
3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.1.4 Communications Interfaces
3.2Software Product Features
3.2.1 Feature
Repeat subsections at this level and below for each feature.

5/6/2013 Version 1.0 15
3.2.2 Purpose
3.2.3 Stimulus/Response Sequence
3.2.4 Associated Functional Requirements
3.2.5 Functional Requirements
Repeat subsections at this level and below for each associated functional requirement.
Each functional requirement may be described in natural language, pseudocode, or in four subsections as
follows. Functional requirements include:
validity checks on inputs
exact sequencing of operations
responses to abnormal situations, including error handling and recovery
effects of parameters
relationships of inputs to outputs, including input/output sequences and formulas for input to output
conversion
3.3Performance Requirements
Specify static and dynamic numerical requirements placed on the software or on human interaction with
the software.
Static numerical requirements may include the number of terminals to be supported, the number of
simultaneous users to be supported, and the amount and type of information to be handled.
Dynamic numerical requirements may include the number of transactions and tasks and the amount of
data to be processed within certain time period for both normal and peak workload conditions.
All of these requirements should be stated in measurable form.
3.4Design Constraints
Specify requirements imposed by standards, hardware limitations, etc.
3.5Software System Attributes
The following items provide a partial list of system attributes that can serve as requirements that should
be objectively verified.
3.5.1 Reliability
3.5.2 Availability
In almost every aspect of an organization’s business environment relies on the
uninterrupted availability of platforms, applications and data. Based on Web Services

5/6/2013 Version 1.0 16
technologies, iPortman products increase higher availability, fault tolerance and disaster recovery
by supporting both vertical and horizontal clustering and load balancing.
Using vertical clustering capabilities such as server groups, clones, or multiple
application servers, the POF will be able to ensure that its application environment is insulated
from single JVM performance issues or memory constraints that may cause poor performance or
outages in a single JVM or application server environment.
It not only balances user connectivity, but also provides improved performance, the
ability to add additional servers as necessary, and the ability to perform maintenance on any of
the servers without any impact on configuration.
Specify the factors needed to guarantee a defined level of availability.
3.5.3 Security
Specify the factors that will protect the software from accidental or malicious access, misuse, or
modification. These factors may include:
cryptography
activity logging
restrictions on intermodule communications
data integrity checks
3.5.4 Maintainability
Specify attributes of the software that relate to ease of maintenance. These requirements may relate to
modularity, complexity, or interface design. Requirements should not be placed here simply because they
are thought to be good design practices.
3.5.5 Portability
Specify attributes of the software that relate to the ease of porting the software to other host machines
and/or operating systems.
* Remove this section if no logical database requirements are applicable in your project
3.6Logical Database Requirements
Specify the requirements for any information that is to be placed into a database, including
types of information used by various functions
frequency of use
accessing capabilities
data entities and their relationships

5/6/2013 Version 1.0 17
integrity constraints
data retention requirements
3.7Other Requirements
4. INDEX
The index is optional according to the IEEE standard. If the document is made available in
electronic form, readers can search for terms electronically
5. APPENDICES
Include supporting detail that would be too distracting to include in the main body of the
document.
5.1 Screens, Forms
and Reports
Given by the
User
This sub-section contains all the screens, forms and reports
specified by the user as part of the requirements of the system.
(Annexure - I of the SRS). Also provide reference to URD.
5.2 Traceability
Table
<provide reference to the traceability matrix>
5.3 SDD <provide reference to system design document>

2.1 project management srs

More Related Content

What's hot

Viewers also liked

Similar to 2.1 project management srs

2.1 project management srs