SRS Example

Overview of a Software
Specification Document (SRS)
1. INTRODUCTION

States the goals and objectives of the

software, describing it in the context of the
computer-based system.
A. System Reference
B. Overall Description
C. Software Project Constraints
 Introduction (cont’d)
• System Reference for an Inventory Control Subsystem:
“ The Inventory Control System (ICS) will work in the existing
Enterprise Planning System (ERP) system. It will interface with the
Purchasing, Manufacturing, Customer Order Entry/Shipping, and
subsystems.
It will be invoked mainly when:
– purchased goods arrive from vendors,
– goods are returned to the vendor for various reasons,

– stock is issued to/from manufacturing,

– finished goods are entered in the Finished Goods Warehouse

– finished goods are shipped to the customer,

– sales persons wish to check the availability of products.
 System Reference for the Inventory
Control Subsystem (cont’d):

• Interface with Purchasing:

When an order from a vendor arrives, our Purchase Order

Number on the vendor’s invoice will be used to locate the
the PO and other related documents, such as vendor
proposals, price lists, product specifications.

These will then be forwarded to Quality Control to be used in

the inspection of the goods.

An interface will be worked out with Purchasing subsystem

currently running on Server PS1 so that ICS can find all
documents related to the current purchase.
 System Reference for the Inventory Control
Subsystem:
(cont’d)

• Interface with Manufacturing:

Mfg requests materials

Mfg wants to store finished goods

• Interface with Customer Order Entry/Shipping:

COES wants to ship goods

COES wants to store returned goods
•
..........
Deployment Diagram

Cust.
Order Manu
Entry factur
ing

ICS

Purch
asing

Ship
ping
 Overall Description of ICS

ICS’s main objective is to keep track of all the parts and

finished goods in the warehouses and all the transactions
involving these parts and goods.

An automatic purchase order generation when the stock

levels of parts falls below the minimum has been
contemplated but postponed to a future date.
 Overall Description of ICS (cont’d)

The main functions of ICS are:

• Entering new parts into the inventory
(see “Interface with Purchasing”)

• Issuing parts to Manufacturing

(see “Interface with Manufacturing”)

• Entering finished goods to the inventory

(see “Interface with Manufacturing”)
 Overall Description of ICS (cont’d-2)

• Providing Sales personnel with inventory information

• Issuing goods to/from COES for shipping, entering returned goods

(see “Interface with Customer Order Entry/Shipping”)

• Assisting IC Department with reconciliation of results of

physical inventories and machine records (internal).

• Providing IC Department Manager and the Vice

President of Manufacturing with management reports
about our inventories (internal).
 Overall Description of ICS (cont’d-3)

ICS should:
• Provide a user interface consistent with
the other subsystems
• Verify user identities and access rights
• Do error checking on all inputs
• Permit users to add customized reports
USE CASE DIAGRAMS
 Use
ICS
Case 1: ICS Dept
Manager
Chk Parts Inventory

Chk/verify Mfg Schedule

Create Purchase Requsts

Delete cancelled part ICS

records..

Add new part records

Reconcile machine and

physical inventories
Create reports
required by mgmt
Use Case 2: Customer Order Entry
Salesperson
(COES) View
ChkAvail

Chk Goods
Availability
Sales
Prog. ICS
ICS
 Use Case 3 - Manufacturing
Manufacturing
Manager Collect Mfg Requests
View/
Create Mfg Schedule update
Get/order
Get/order parts. parts
ICS
Chk mfg. progress
Mfg.
Prog.
Update finished goods
inventory
 Use Case 4 - Purchasing
Purchasing Analyze purchasing
Manager requests
View/
Analyze vendors update
Purchase
Get bids. parts
ICS
Order parts Purch.
Prog.
Enter arriving parts

Return defective parts to

vendor
 Use Case 5 - Shipping
Shipping
Manager
View/
(COES) Get finished orders update
Ship Order
ICS
Ship to customer Shipping
Prog.
 Software Project Constraints
• Compatibility
– ICS software should run compatibly (i.e. under the same operating system,
database and networking capabilities) with the other subsystems software it
works together with.
– It should allow an Administrator to enroll new users and give them access rights
required by their duties.
• Reliability and Availability
– Since it interfaces with Purchasing, Customer Order Entry and Manufacturing, it
should be available as a minimum when any one of these subsystems are
available.
– It should permit 1 hour per day for maintenance and backup activities with
minimal disruption to users.
– Any failure should cause no more than 10-minute downtime, with the average not
exceding 2 minutes.
– Backup should spot-tested to ensure they are reliable.
• Performance
– It should allow up to 10 users to logon simultaneously and receive an average
response time not exceeding 3 seconds.
– Parts received should be in the recorded in the system in no more than 2 hours,
with the average under 30 minutes.
2. INFORMATION DESCRIPTION
• Detailed description of the problem the
software must solve

• Information content, relationships, flow and

structure

• Hardware, software and human interfaces

are described for external system elements
and internal software functions
Software Requirements Specification 18
 ICS Information Description
ICS will use the following data from other subsystems.
See Class Diagrams for details. The formats can be
found in the Design Documents of the related
systems.

1. Vendor Order Master File - Purchasing

2. Vendor Order Detail File - Purchasing

3. Customer Order Master File – Customer Order Entry

4. Customer Order Detail File – Customer Order Entry

5. Manufacturing Requests – Manufacturing

6. Manufacturing Schedule– Manufacturing

Software Requirements Specification 19

 INFORMATION DESCRIPTION
(cont’d)

• ICS will create and maintain, as a

minimum, the following files:

1. Part Transaction File

2. Part Master File
3. Part Detail File
4. Part Inventory File
 Data Flow Diagrams
(DFD Level 0)
Vendor Order Master File

Part Transaction File

Vendor Order Detail File
Part Master File
Customer Order Master
File Part Detail File
Cust. Order Detail File ICS
Manufacturing Part Inventory File
Requests
Manufacturing
Schedule
 INFORMATION DESCRIPTION
(cont’d-3)
• Transactions to be provided by ICS:

– Create New Part or Product Master Record

(“Note:Part and Product Record formats can be obtained from
Manufacturing Subsystem, File: prd_rec_fmt” )

– Edit/Delete Part or Product Master Record

– Edit/Delete Part or Product Record
– Enter New Part or Product
– Enter Returned Part or Product
– Issue Part or Product
– Re-issue Part or Product
– View Part or Product
......
 DFD Level 1
Vendor Order Master File Create New Part or Product Part Transaction
Master Record File
Vendor Order Detail File
Edit/Delete Part or Product Master Record Part Master File
Customer Order Master
File Enter New Part or Product
Part Detail File

Cust. Order Detail File Edit/Delete Part or Product

Enter Returned Part or Product

Manufacturing Requests
Part Inventory File

Manufacturing Issue Part or Product

Schedule
Re-issue Part or Product

All View Part or Product

 INFORMATION DESCRIPTION
(cont’d-4)

• List of transactions should be expanded and details

should be given as required.

• The transactions will use the classes described below

as required

• Data flow and Control flow diagrams should be

supplied.

(do not have to be very detailed at this stage. Will be

discussed in more detailed later.)
CLASS DESCRIPTIONS
 Part Transaction Class

• It
will list details of all parts entry and parts issue
transactions, using the Transaction ID as the Primary
Key. May be used with the Part ID to display all
transactions for a given part.

• It will be searchable by the various portions of the Part

ID, date of the transaction, person making the
transaction, and the transaction type indicating the
reason for the transaction. It will allow a joker character
(?) to match any character in that position.

• The outputs can be routed to the display, a file or the

printer.
 Part Transaction Class (cont’d)
(note: Data elements are stored in DB)

Data Elements Methods in class

• Trans ID (*) • getPartDetail
• Trans type: View Part • displayPrint PartDetail
• Trans start time • getPartSummary
• User ID • displayPrint PartSummary
• Part ID • recordStartTime
• View type: Detail • getUserId
• Amount on Reserve • recordUserId
(may be more than one field) • getReservations
• Status: • displayPrintReservations
• Completion time • updateStatus
• recordCompletionTime
 Part Inventory Class
This class will allow viewing the inventory of
parts by part ID or part name. It will update fields
as required.
This file will be searchable by Part ID in ways
similar to to the preceding file. Its output can be
directed to the display, a file or a printer. Its
contents should be verified periodically by
complete or partial physical inventories.
 Part Inventory Class (cont’d)
(note: Data elements are stored in DB)
Data Elements Methods in Class
• partId (*) • getPartInvRec
• totalInStock
• updatePartInvRec
• totalOnReserve
• amountOnOrder
• displayPrintPartInvrec
(can be one or more fields)
• amtExpectedByDate
(can be one or more fields)
• lastEntryTransId
• lastIssueTransId
 Part Master Class
(note: Data elements are stored in DB)
Data Elements Methods in Class
• partId (*) • getPartDetailById
• partName • getPartDetailByName
• createNewPart
• deletePart
• updatePartMaster
• displayPrintPartMaster
 Part Detail Class
(note: Data elements are stored in DB)
Data Elements Methods in Class
• partId (*) • getPartDetailById
• partName • updatePartDetailById
• partDrawingNo • displayPrintPartDetail
• height
• width
• weight
• price
 3. FUNCTIONAL DESCRIPTION
• Each function is described in detail.
A. Functional Partitioning - None
B. Functional Description

1. Processing Narrative
2. Functional Constraints
3. Performance Requirements
4. Design Constraints
5. Supporting Diagrams

Software Requirements Specification 32

TRANSACTION
DESCRIPTIONS
 “Create New Part or Product”
Transaction
Narrative: Creates a new part or product type. After the type has been created,
part or product instances can be entered. Permits user to enter a new type
code and its description. The type code should be selected according to the
“Part/product Type Code Guidelines” document. Uses PartMaster Class
and PartDetail Class.

Constraints:
Requires “Product Administrator” rights for use.
Performance constraints:
constraints Since it locks PartMaster, the transaction should
time-out after 15 seconds and backout all changes.
Design Constraints: Must check type code for compliance with Guidelines
Supporting Diagrams: See Class diagram for PartMaster and Part Detail
classes.
 “Edit/Delete Part or Product”
Transaction
Permits user to edit the description of a part or product or delete it. If there are
any instances of the part or product, it can not be deleted. Uses PartMaster
Class, PartDetail Class and PartInventory Class.

Constraints:
Requires “Product Administrator” rights for use.
Performance constraints:
constraints Since it locks PartMaster, PartDetail and
PartInventory Classes, the transaction should time-out after 15 seconds and
backout all changes.
Design Constraints: Must check type code for compliance with Guidelines.
Any instances of the part or product are in existence, only certain fields may
be edited.
Supporting Diagrams: See Class diagram for PartMaster and Part Detail
classes.
 Other transactions supported by
ICS
• enterNewPart,
• enterReturnedPartProduct
• issuePartProduct
• re-issuePartProduct
• viewPartProduct
(described similarly)
 4. Behavioural Description
• Operation as a result of external events
and internal conditions

A. System States
B. Events and Actions

Software Requirements Specification 37

 5. Validation Criteria
• How do we recognize a successful
implementation? What classes of tests must be
conducted to validate function, performance and
constraints?

A. Performance bounds
B. Classes of tests
C. Test to be performed and expected software
response
D. Special considerations

Software Requirements Specification 38

 6. Bibliography
• List of references used (books, reports,
papers, web sites/pages). Make reference
as specific as possible, including
chapter/page for paper pubs and detailed
URL for Web.

Software Requirements Specification 39

 7. Appendices (Ekler)
• An executable prototype
• A paper prototype
• Preliminary user manual.
(Represents software as a black-box.
Emphasis is on input and output.)

Software Requirements Specification 40