P. 1
SRS Example (2)

SRS Example (2)

|Views: 11|Likes:
Published by Ajita Verma

More info:

Published by: Ajita Verma on May 03, 2011
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PPT, PDF, TXT or read online from Scribd
See more
See less






  • 4. Behavioural Description
  • 5. Validation Criteria
  • 6. Bibliography
  • 7. Appendices(Ekler)

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 ‡ .

Order Entry Manu factur ing ICS Purch asing Ship ping .Deployment Diagram Cust.

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´) .

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-2) ‡ Providing Sales personnel with inventory information ‡ Issuing goods to/from COES for shipping.

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 1: ICS Dept ICS Manager Chk Parts Inventory Chk/verify Mfg Schedule Create Purchase Requsts Delete cancelled part records.. Add new part records Reconcile machine and physical inventories Create reports required by mgmt ICS .

ICS ICS .Use Case 2: Customer Order Entry Salesperson (COES) ChkAvail Chk Goods Availability View Sales Prog.

progress View/ update Get/order parts ICS Mfg.Use Case 3 . Chk mfg.Manufacturing Manufacturing Manager Collect Mfg Requests Create Mfg Schedule Get/order parts. Prog. Update finished goods inventory .

Enter arriving parts Return defective parts to vendor . Prog.Purchasing Purchasing Manager Analyze purchasing requests Analyze vendors Get bids.Use Case 4 . View/ update Purchase parts ICS Order parts Purch.

Shipping Shipping Manager (COES) Get finished orders View/ update Ship Order ICS Ship to customer Shipping Prog.Use Case 5 . .

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

relationships. flow and structure ‡ Hardware. software and human interfaces are described for external system elements and internal software functions Software Requirements Specification 18 .2. INFORMATION DESCRIPTION ‡ Detailed description of the problem the software must solve ‡ Information content.

Purchasing 3. Manufacturing Requests ± Manufacturing 6.Purchasing 2. Customer Order Master File ± Customer Order Entry 4. Manufacturing Schedule± Manufacturing Software Requirements Specification 19 . Vendor Order Master File . 1. See Class Diagrams for details. Customer Order Detail File ± Customer Order Entry 5.ICS Information Description ICS will use the following data from other subsystems. Vendor Order Detail File . The formats can be found in the Design Documents of the related systems.

the following files: 1. as a minimum. Part Inventory File .INFORMATION DESCRIPTION (cont¶d) ‡ ICS will create and maintain. Part Master File 3. Part Detail File 4. Part Transaction File 2.

Order Detail File Manufacturing Requests Manufacturing Schedule Part Transaction File Part Master File ICS Part Detail File Part Inventory File .Data Flow Diagrams (DFD Level 0) Vendor Order Master File Vendor Order Detail File Customer Order Master File Cust.

..... 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 ..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.

Order Detail File Manufacturing Requests Enter New Part or Product Edit/Delete Part or Product Enter Returned Part or Product Part Inventory File Part Master File Part Detail File Create New Part or Product Master Record Part Transaction File Manufacturing Schedule Issue Part or Product Re-issue Part or Product All View Part or Product .DFD Level 1 Vendor Order Master File Vendor Order Detail File Edit/Delete Part or Product Master Record Customer Order Master File Cust.

Will be discussed in more detailed later. (do not have to be very detailed at this stage.) .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.


Part Transaction Class ‡ It will list details of all parts entry and parts issue transactions. ‡ The outputs can be routed to the display. person making the transaction. It will allow a joker character (?) to match any character in that position. ‡ It will be searchable by the various portions of the Part ID. date of the transaction. and the transaction type indicating the reason for the transaction. a file or the printer. May be used with the Part ID to display all transactions for a given part. using the Transaction ID as the Primary Key. .

Part Transaction Class (cont¶d) (note: Data elements are stored in DB) Data Elements ‡ Trans ID (*) ‡ Trans type: View Part ‡ Trans start time ‡ User ID ‡ Part ID ‡ View type: Detail ‡ Amount on Reserve (may be more than one field) ‡ Status: ‡ Completion time Methods in class ‡ getPartDetail ‡ displayPrint PartDetail ‡ getPartSummary ‡ displayPrint PartSummary ‡ recordStartTime ‡ getUserId ‡ recordUserId ‡ getReservations ‡ displayPrintReservations ‡ updateStatus ‡ recordCompletionTime .

Its output can be directed to the display. It will update fields as required. a file or a printer. . Its contents should be verified periodically by complete or partial physical inventories.Part Inventory Class This class will allow viewing the inventory of parts by part ID or part name. This file will be searchable by Part ID in ways similar to to the preceding file.

Part Inventory Class (cont¶d) (note: Data elements are stored in DB) Methods in Class Data Elements ‡ getPartInvRec ‡ partId (*) ‡ updatePartInvRec ‡ totalInStock ‡ displayPrintPartInvrec ‡ totalOnReserve ‡ amountOnOrder (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) Methods in Class Data Elements ‡ getPartDetailById ‡ partId (*) ‡ getPartDetailByName ‡ partName ‡ createNewPart ‡ deletePart ‡ updatePartMaster ‡ displayPrintPartMaster .

Part Detail Class (note: Data elements are stored in DB) Methods in Class Data Elements ‡ getPartDetailById ‡ partId (*) ‡ updatePartDetailById ‡ partName ‡ displayPrintPartDetail ‡ partDrawingNo ‡ ‡ ‡ ‡ height width weight price .

3. FUNCTIONAL DESCRIPTION ‡ Each function is described in detail.3. Functional Description 1. 4.None B. 2. A. Functional Partitioning . 5. Processing Narrative Functional Constraints Performance Requirements Design Constraints Supporting Diagrams Software Requirements Specification 32 .


Constraints: Requires ³Product Administrator´ rights for use. Uses PartMaster Class and PartDetail Class. Design Constraints: Must check type code for compliance with Guidelines Supporting Diagrams: See Class diagram for PartMaster and Part Detail classes. part or product instances can be entered. the transaction should constraints time-out after 15 seconds and backout all changes. 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.³Create New Part or Product´ Transaction Narrative: Creates a new part or product type. Performance constraints: Since it locks PartMaster. After the type has been created.

only certain fields may be edited. . it can not be deleted. PartDetail Class and PartInventory Class. If there are any instances of the part or product. Constraints: Requires ³Product Administrator´ rights for use. Uses PartMaster Class. Design Constraints: Must check type code for compliance with Guidelines. the transaction should time-out after 15 seconds and backout all changes. Any instances of the part or product are in existence. 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. PartDetail and constraints PartInventory Classes. Performance constraints: Since it locks PartMaster.

‡ enterReturnedPartProduct ‡ issuePartProduct ‡ re-issuePartProduct ‡ viewPartProduct (described similarly) .Other transactions supported by ICS ‡ enterNewPart.

Behavioural Description ‡ Operation as a result of external events and internal conditions A. Events and Actions Software Requirements Specification 37 .4. System States B.

5. Classes of tests C. Test to be performed and expected software response D. performance and constraints? A. Special considerations Software Requirements Specification 38 . Validation Criteria ‡ How do we recognize a successful implementation? What classes of tests must be conducted to validate function. Performance bounds B.

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

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

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->