1

Software Requirements Specification

Prototype
" Product Name "









Produced by: Sycus Networks
Version I.0
2
TABLE OF CONTENTS
I. INTRODUCTION.... 3
1.1 Purpose of this Document
1.2 Scope of this Document
1.3 Overview
1.4 Scope of the Procurement and Pre-Processing Project
II. GENERAL DESCRIPTION.. 5
2.1 Project Functions
2.2 User Characteristics
2.3 Operating Environment
2.4 User Problem Statement
2.5 User Objectives
2.6 General Constrains
III. SYSTEM REQUIREMENTS..... 8
3.1 Functional Requirements
3.2 System Requirements
IV. VALIDATION CRITERIA... 12
4.0 Validating the Software Requirement Specification
4.1 Prototyping
4.2 Testing
V. OPERATIONAL SCENARIOS.. 14
VI. PRELIMINARY SCHEDULE.. 15
VII. CONCLUSION.. 16
VIII. APPENDIECES.. 17
3

I. INTRODUCTION

1.1 Purpose of this Document
This document is provided in order to ensure that the software that the
development team produces will be consistent with the needs of customer. It is a
description and elaboration of the project requirements that the development team has
been provided with. Stating these requirements explicitly helps ensure that any potential
miscommunications are dealt with at an early stage, when the cost of implementing
changes is still low.
Customers are encouraged to distribute this document among their potential users
and management in order to provide us with feedback. This will help the development
team ensure that the end product fully meets all needs. This document will also be a
useful resource for those who will be upgrading or maintaining the software after it has
been completed.

1.2 Scope of this Document
The development team arrived at the information contained in this document by
examining the original project description in an individual and group setting. They then
proceeded to research related topics and similar projects using the library and the Internet
as resources. They then formulated specific questions for the customer in order to more
clearly define the project requirements. The team then held further meetings in order to
attempt to clearly define the requirements of the project. The requirements have not been
fully clarified yet, and it is hoped that the submission of this document as well as future
research will remedy this. Updates to this document will be made as time goes by to
reflect any changing needs of customers and the growing knowledge of the development
team. This document is also written so that future development teams who wish to
expand the scope of this Project can use it.
This document makes use of several terms in very narrowly defined ways. The
reader is referred to the glossary at the end of this document if he or she encounters a
word that seems confusing. The first occurrences of all words in the glossary are
italicized in the text, except in cases where the text itself defines them explicitly.


4

1.3 Overview
A software package entitled "Product Name" will be the ultimate product of the
development team. This software will allow organizations to run at their
production location and privately on a server connected to a distributed network
(If required). It will be possible to track the PURCHASES and PRE-
PROCESSING activities. This also includes details of FISH LANDING
CENTERS, FARM DETAILS, AGENTS, PRODUCTS, TRANSPORTERS,
HACCP QUALITY PARAMETERS, INSURANCE COMPANIES and
POLICIES, PROCESSING, FREEZING, PACKING, STORAGE,
MARKETING, ACCOUNTS, INSPECTIONS etc.
All aspects of the software will use a graphical user interface. The system will be
furnished with a basic on-line help system, as well as installation software.
1.4 Scope of the Product Name Project
This software should only be regarded as a pilot project, meant to examine the
feasibility of implementation and to explore its potential. It is not intended that it
perfectly suit all organizations that are involved in Sea Food manufacturing, at
least at this stage. However, the software will be designed to be scalable to
Enterprise Solution level, given the time and resources.







5
II. GENERAL DESCRIPTION

2.1 Product Functions
The Product Name software package will be made up of seven basic
components and a database:
2.1.1 Product Name Procurement
The System will be responsible for maintaining the details of each entities
mentioned above.
Details of Supply
This includes details of Agents and Farm that supplies Raw materials.
It also includes other parameters of quality, purchases and costing
Shipping Details
This involves the Transporter details, Transportation details and Costing
2.1.2 Product Name Pre-Processing
This includes the functionalities of inspections, pre-processing and
utilities.
2.1.3 Product Name Processing / Freezing / Packing
This includes the functionalities of Processing activity, Packing / Freezing
and Storage.
The functionalities of these are verified with reference to HACCP
standards. HACCP parameters are incorporated with this module so as to industry
provide quality products.
2.1.4 Product Name Storage (Inventory)
Storage module involves all the required functionalities related to storage
capacity, products stored and other relevant details.


6
2.1.5 Product Name Marketing (Local Market / Export Marketing)
Marketing module of Product Name covers the relevant details
regarding export marketing and local markets, offer of product to markets,
negotiation and conclusion, shipment formalities, banking and payment
realization.
2.1.6 Product Name Accounts
The account module will be handling all the transactions that involve
money. This will be interacting with the other modules to get the necessary data
related to accounts, since the accounts will be a module being used at various
levels in this software.
2.1.7 Product Name Inspection
Inspection is an independent module that will be interacting with the other
process involved in the business. Inspection module also takes HACCP standards
into consideration for building inspection reports
2.1.8 Product Name Database
The Database will hold the records for each transaction, reports as well as
all required details.
2.2 User Characteristics
2.2.1 Customers
The customers are the people or organizations who purchase the Product
Name Software. They will be authorized to use this as a demo version at
their manufacturing location. The package will be available free of charge
if it is intended for demonstration. The customers will also be responsible
for providing a host where in the package would run on.
2.2.2Product Name Officer
The Product Name Officer is an impartial individual who is given
responsibility for overseeing individual transaction with respect to
procuring and pre-processing activity in the organization. This person is
needed to monitor each activity in a way that is required for the general
overall maintenance of the system.
The Product Name Officer is expected to be well versed in the overall
processes involved in the organization.
7
The other users of this software include data entry peoples who will be
updating the system with the required data for processing.
2.3 Operating Environment
2.3.1 Product Name Package
The Product Name package will be written in Visual Basic 6.0, so the
computer hosting it must be capable of running visual basic exe files.
2.3.3 Product Name Database
The Product Name Database will be built on MS Access / MS SQL
Server. The computer hosting the database must have either MS Access or
SQL Server installed.
2.4 User Problem Statement
As it stands, very few activities are handled electronically in the organization.
This means that there is a great cost and time associated with procuring and pre-
processing activities. Manual verifications call for the expenditure of more time,
and events such as re-verifications can greatly delay the output of the industry.
The industry requires the software that could be used in all the departments
wherever applicable.
There are also many problems relating to the accuracy of manual checks. Having
the verification handled by an entirely impartial computer can eliminate the
intentional or otherwise introduced inaccuracies of supervisory officials. The
unintentional inaccuracies of manual reports, such as improperly printed or
written documents, can also be eliminated by electronic implementation that uses
clear and consistent interfaces.
2.5 User Objectives
Any organization running a Sea Foods business will want software that is easy to
install and run. This package provides complete solution to the user requirements.
2.6 General Constraints
The development team must design, develop and test this software within the
space of three months. Finance limitation They also have important limitations
placed on their time due to many other projects that they must work on. Due to
these constraints, as well as the limited number of people working on the project,
it may be necessary to prioritize certain aspects of the project over others.
Functionality and security will be the first priorities.
8
The developing and testing environment is limited. This means that the
developers do not have access to the full commercial system that is necessary to
fully test this system under realistic working conditions.
III. SYSTEM REQUIREMENTS

The primary priorities of this design are, in order of importance:
1. Functionality
2. Reliability
3. Security and Privacy
4. Maintainability
5. Scalability
6. Interfaces
3.1 Functional Requirements
3.1.1 General
There will be the functionality of maintaining information about
o Fish Landing Center
o Farm
o Agents
o Products (Fish, Shrimp, Squid etc.,)
o Transporters
o Quality Parameters
o Insurance Companies
o Locations (units)
3.1.2 Procuring
Maintains the details of supply. (Agent, supervisor, quality, quantity, date and
time etc.,)
Maintains the quality parameters involved. (Item, count, weight etc.,)
Generates and Maintains the costing for purchases made.(labor, icing etc.,)
Maintains the payment details- commission, advances and etc., (to agent and to
firms).
Maintains agreement details with agents and firms
Maintains the transportation details.(transportation documents)
Maintains delay details of transportation.
Also maintains other utilities involved in this process
Processes the payment and transaction with firms, agents, transporters
Generation of insurance documents.
9
Reports with respect to costing, transportation, preliminary inspection, out
standing payments to firms/ agents, transporters etc.,
Reports on delays are produced for future plans.

3.1.3 Pre-Processing
Maintains the information of products being pre-processed.
Maintains the information of the scraps after pre-processing.
Maintains the pre-processing requirements.
Details of the inspection at the pre-processing shed (point of receiving) are stored.
Details of the percentage in variation are saved.
Details of rejections at point of receiving are saved
Costing for the products until it reaches the point of receiving
Yield details are saved.
Reports on production at pre-processing shed
Reports on products, grade, count, etc.,
Reports on costing
Deviation report with respect to HACCP standards
3.1.4 Verifications
The system verifies for the quality and quantity of purchase with the quality and
quantity at the point of receiving.
Verification is a module that is associated with all other modules wherever
inspection is required.
Maintains the tolerance levels for each product being purchased.
Maintains the record of the deviations in quality.
Reports on percentage mismatch of between purchased and actual received.
3.1.5 Processing
The system will be responsible for checking the availability of materials for
processing.
The system provides the details of the product that is brought for processing like,
product name, count, weight, quality, labors required, Time taken etc., and
HACCP parameters.
With respect to the processing activity the system would be responsible for
maintaining all the required details of other chemicals involved, quality and
quantity.
The system provides the functionality to measure the inputs and outputs for the
processing.
3.1.6 Packing / Freezing
The system will provide details of attributes involved in packing and freezing.
10
The system generates packing codes and batch numbers and packing materials for
every output.
The system provides details with respect to freezing materials required, freezing
times required.
Also the system will be responsible for master packing.
The system integrates HACCP parameters associated with packing and freezing.
The system generates reports on inventory of packing and freezing materials.
The system will be responsible for generating the required reports with respect to
packing and freezing.
3.1.7 Storage
The system will provide details of Store like, capacity and machineries involved.
The system shall provide other details of store layout.
The system provides all relevant details of storage records.
3.1.8 Inventory
The system takes care of all the related functionalities of inventory like quantity
on hand, product expiry and details of the inventory and etc.
The system will be able to provide information of the products in the inventory
that are subject to expire.
Inventory of each product is maintained with respect to the production number.
3.1.9 Marketing
The system will be enabled with a functionality of estimation with available
inventory and the demand.
It also records the details of Negotiation and Price comparison.
The system will be responsible for communicating with the buyer through E-
Mails.
System also maintains the databases of shipment details.
The system provides a functionality to trace the transactions with the banks for
negotiations and final payment realization.
It would also produce a total summary of transaction.
3.1.10 Accounts
This is a module that interacts with the whole system at every stage wherever
transactions are involved.
This would be able to generate required account statements.
A mismatch report.

3.2 System Attributes
11
3.2.1 Data Storage Security and Privacy
The system provides the access to the corresponding authorized persons to
manipulate and to modify the data. The system shall not allow other hosts to
connect from elsewhere to modify and delete data if the database runs on a
Server. The system shall allow users to connect from other hosts only to view the
data with valid passwords. It could also be made in such a way that database
could be accessed through specified hosts which restricts other anonymous user
not to connect to the server machine.
3.2.2 Maintainability
The software will be well documented and it will be designed to be modular. The
use of object-oriented programming will also help to increase maintainability.
This will make it easier for future developers to make changes and updates to the
software with a minimal amount of effort and the users to work with the package
conveniently.
3.2.3 Scalability
Both the Product Name software and this document are meant to be easily
scalable to increase the scope and size of the package. All efforts will thus be
made to use a software design that does not have built in size limitations.
3.2.4 Reliability
All efforts will be made to write software that is entirely reliable. However, the
viability of electronic system rests, in part, on the ability of systems
administrators. Help to develop contingency plans for possible failures.
3.2.5 Interface
All aspects of the Product Name system will have a simple point and click
interface using menus, text fields, buttons and all of the other components of
systems with graphical user interfaces. This interface will be designed to be
consistent. The system will also be having a basic on-line help system.





12


IV. VALIDATION CRITERIA

4.0 Validating the Software Requirement Specification
The development team would like to ask the customer to review this requirements
document and verify it with all of the software stakeholders. This will ensure that
all conceptions of the product are consistent. Requests for additions or changes
should be submitted at this stage so that they can be incorporated into this
document. It is more costly to implement changes at later stages of development.
4.1 Prototyping
The development team will present the customers with working prototypes of
Purchase and Pre-Processing functionalities at various stages of the process. This
will enable the client to be fully aware of all progress and provide useful
feedback.
4.2 Testing
A test plan will be developed from the onset of design to ensure that testing is not
an afterthought. The development team will automate testing by writing software
to test all of the components of the system. Some testing will also be done
manually. Tests and their results will be documented. The following test classes
will be considered necessary:
4.2.1 Security Testing
4.2.1.1 Denial of Service Attacks
The development team will subject the Server to denial of service attacks
to ensure that the System can be properly shut down and restarted in the
exact state that it left off.
4.2.1.2 Encryption Breaking
Tests will be run to ensure that encrypted transmitted information cannot
be decoded within a time that falls within the duration of a Process. This
must be further researched. The development team must know how long
13
relevant and non-relevant data is typically saved and how long it takes to
break various encryption methods.


4.2.1.3 Faulty Database Access
Tests will be run to ensure that the Database cannot be accessed in a
manner, which would bring security or the privacy Problems and also hack
free.
4.2.2 Recovery Testing
Tests will be run to ensure that the state of the system can be completely restored
if a power failure occurs or the Elections Server is shut down.










14


V. OPERATIONAL SCENARIOS
The development team will provide operational scenarios to highlight the major
functionality to be delivered in the software. These scenarios can be used to validate the
functionality of the system. It is expected that scenarios will be added and that the details
of existing scenarios will be filled in, as the projects scope is better realized.











15


VI. PRELIMINARY SCHEDULE
The Software Requirements Specification Document will be completed and
submitted for review by Jul 2, 2002.
The next step will be to amend this document based on the feedback received.
A design document will then be produced, which will also be submitted for
review.
Once the design document is completed, work will begin on implementing the
system.
Testing will be performed throughout all stages the development phase to ensure
quality.
Once the development phase begins, the software will be demonstrated every
Monday.
A first release version of the software will be completed for distribution by early
July of 2002.








16


VII. CONCLUSION
It is the development teams hope that this document will be the first part of a continuing
series of interchanges between themselves and customers. This will ensure that
customers needs are met in a cheap and timely fashion. It will be important to involve
potential persons and users in this feedback process, as end-users such as they often have
many unique insights that might not occur to software developers or people involved in
management. This interchange will involve both information such as this document and
prototypes of the product. The end result will be a product that is functional, reliable,
secure and easy to learn and use.










17


VIII. APPENDICES
8.1 Glossary
Client: a program that connects to a server. In the case of this system, the Client
is a piece of software that users can use to connect to a Product Name Server
and receive data, send their data and possibly change them if this is permitted in
an authorized order.
Customers: peoples or agencies who purchase the Product Name system.
Database: any aggregation data. Files consisting of records (or tables), each of
which is constructed of fields (or columns) of a particular type, together with a
collection of operations.
Denial of Service: explicit attempts by attackers to prevent legitimate users of a
service from using that service. Examples include:
Attempts to "flood" a network, thereby preventing legitimate network traffic
Attempts to disrupt connections between two machines, thereby preventing access
to a service
Attempts to disrupt service to a specific system or person
Development Team: a team of people developing software.
Distributed Network: a network in which processing, storage and other
functions are handled by separate units rather than by a single main computer.
Encryption: the process to making information indecipherable to unauthorized
readers. This can be used for the storage and transmission of information.
GUI: a graphicsbased user interface that incorporates icons, buttons, pull-shown
menus and a mouse.
Hacker: a person who secretively invades other peoples computers to inspect or
tamper with the programs or data stored on them.
MySQL: a relational database management system (RDBMS) that uses
Structured Query Language (SQL) for adding, accessing and processing data in a
database.
18
On-line Help System: a reference on how to use a piece of software that is
integrated into the software.
Operating System: the software responsible for controlling the allocation and
usage of hardware resources such as memory, central processing unit (CPU) time,
disk space and peripheral devices.
Product Name Database: database system used for storing Business data and
information.
Product Name Officer: an impartial individual authorized to Work on this
system.
Product Name Server: a server that manages every transaction and that the
Product Name Client can connect to. It is responsible for jobs such as database
management, user identity checks and reporting of statistics.
Security Break: the act or a result of breaking the security of a software system.
Server: a program that serves clients and controls access to all or part of a
computers resources.
System Administrator: a person responsible for setting up and maintaining the
operational performance of a server and database.
Users: Persons who will use the system to run and update with data or
information. This includes Product Name Officers, Systems Administrators and
Users.