1 / 40

SRS Example

SRS Example. Overview of a Software Specification Document (SRS). INTRODUCTION States the goals and objectives of the software, describing it in the context of the computer-based system. System Reference Overall Description Software Project Constraints. Introduction (cont’d).

toan
Download Presentation

SRS Example

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SRS Example

  2. Overview of a Software Specification Document (SRS) • INTRODUCTIONStates the goals and objectives of the software, describing it in the context of the computer-based system. • System Reference • Overall Description • Software Project Constraints

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

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

  5. 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 goodsCOES wants to store returned goods • ..........

  6. Deployment Diagram Cust.OrderEntry Manufacturing ICS Purchasing Shipping

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

  8. 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”)

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

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

  11. USE CASE DIAGRAMS

  12. Use Case 1: ICS Dept ICS Manager Chk Parts Inventory Chk/verify Mfg Schedule Create Purchase Requsts ICS Delete cancelled part records.. Add new part records Reconcile machine and physical inventories Create reports required by mgmt

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

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

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

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

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

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

  19. 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. • Vendor Order Master File - Purchasing • Vendor Order Detail File - Purchasing • Customer Order Master File – Customer Order Entry • Customer Order Detail File – Customer Order Entry • Manufacturing Requests – Manufacturing • Manufacturing Schedule– Manufacturing Software Requirements Specification

  20. INFORMATION DESCRIPTION(cont’d) • ICS will create and maintain, as a minimum, the following files: • Part Transaction File • Part Master File • Part Detail File • Part Inventory File

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

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

  23. DFD Level 1 Vendor Order Master File Create New Part or Product Master Record Part Transaction 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 Edit/Delete Part or Product Cust. Order Detail File Enter Returned Part or Product Manufacturing Requests Part Inventory File Issue Part or Product Manufacturing Schedule Re-issue Part or Product All View Part or Product

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

  25. CLASS DESCRIPTIONS

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

  27. Part Transaction Class (cont’d)(note: Data elements are stored in DB) Methods in class • getPartDetail • displayPrint PartDetail • getPartSummary • displayPrint PartSummary • recordStartTime • getUserId • recordUserId • getReservations • displayPrintReservations • updateStatus • recordCompletionTime 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

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

  29. Data Elements partId (*) totalInStock totalOnReserve amountOnOrder(can be one or more fields) amtExpectedByDate(can be one or more fields) lastEntryTransId lastIssueTransId Methods in Class getPartInvRec updatePartInvRec displayPrintPartInvrec Part Inventory Class (cont’d)(note: Data elements are stored in DB)

  30. Part Master Class (note: Data elements are stored in DB) Methods in Class • getPartDetailById • getPartDetailByName • createNewPart • deletePart • updatePartMaster • displayPrintPartMaster Data Elements • partId (*) • partName

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

  32. 3. FUNCTIONAL DESCRIPTION • Each function is described in detail. • Functional Partitioning - None • Functional Description • Processing Narrative • Functional Constraints • Performance Requirements • Design Constraints • Supporting Diagrams Software Requirements Specification

  33. TRANSACTION DESCRIPTIONS

  34. “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: 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 GuidelinesSupporting Diagrams: See Class diagram for PartMaster and Part Detail classes.

  35. “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: 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.

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

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

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

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

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

More Related