Software Engineering: A Methodical Approach (2014)

PART G. Appendices

Appendix 9. Requirements Specification for a Generic Inventory Management System

This appendix provides excerpts from a sample requirements specification (RS) for a generic Inventory Management System (IMS) that may be suitable for a small or medium sized organization. The document is a follow-up to the ISR of Appendix 8, and includes the following:

· System Overview

· Storage Requirements

· Operational Requirements

· Business Rules

· Summary and Concluding Remarks

A9.1 System Overview

A9.1.1 Problem Definition

See section A8.1 of Appendix 8.

A9.1.2 Proposed Solution

See section A8.2 of Appendix 8.

A9.1.3 System Architecture

The System will have four main components:

· Acquisitions Management Subsystem (Java or Delphi)

· Financial Management Subsystem (Java or Delphi)

· Point of Sale Subsystem (POSS)

· Database Backbone (MySQL)

Figure A9-1 provides the information topology chart (ITC) and Figure A9-2 shows the object flow diagram (OFD).

Figure A9-1. IMS Information Topology Chart

Figure A9-2. IMS Object Flow Diagram

A9.2 Storage Requirements

The main storage requirements of the system will be covered in this chapter. The conventions used are summarized below:

· Each information entity referenced is identified by a reference code and a descriptive name.

· For each entity the attributes (data elements) to be stored are identified.

· The entities as presented, will easily transition into a set of normalized relations in a normalized relational database.

· Data elements that will be implemented as foreign keys, in the normalized relational database, are identified by an asterisk (*) followed by a parenthesized comment, specifying what entity they reference.

· Data elements that will be used as primary key attributes (or part of the primary key) at database implementation time are also identified by parenthesized comments.

· For each entity a comment describing the data to be stored is provided.

The Acquisitions Management Subsystem will be addressed first, followed by the Financial Management Subsystem.

A9.2.1 Acquisitions Management Subsystem

Figure A9-3 provides storage specifications for the main information entities comprising the Acquisitions Management Subsystem.

Figure A9-3. Storage Specifications for the Acquisitions Management Subsystem

A9.2.2 Financial Management Subsystem

Figure A9-4 provides storage specifications for the Financial Management Subsystem.

Figure A9-4. Storage Specifications for the Financial Management Subsystem

A9.3 Operational Requirements

The information entities of the previous chapter will be implemented as a relational database using MySQL or some other appropriate DBMS. Superimposed on this database will be an OO GUI consisting of various operations that provide functionality and flexibility to the end users.

The user functionality and flexibility will be provided based on the following approach:

· For each information entity, define an object type of the same name.

· For each object type, define a set of basic operations that will facilitate addition, modification, deletion, inquiry, and reporting of data related to that object type (note that each object type does not necessarily require all five basic operations).

· For selected object types, introduce flexibility and sophistication such as additional and/or more complex inquiry and/or report operations that facilitate end users specifying selection criteria of their choice.

· Define additional utility operations that will support the user interface of the system.

Figure A9-5 shows an initial list of operations that will be defined on each object type. An operation specification will be provided for each of these operations in the project’s design specification. The reference code for each operation is indicated in square brackets.

Figure A9-5. IMS User Operations List

A9.4 Business Rules

A9.4.1 Overview

There are four types of business rules to be covered:

· Relationship Integrity Rules: These will not be emphasized here since most of them can be deduced from the Storage Requirements.

· Data Integrity Rules: Most of these can also be deduced from the Storage Requirements.

· Derivation Rules: These will be mentioned in this chapter.

· Procedural Rules: These will also be mentioned in this chapter.

A9.4.2 Derivation and Procedural Rules

The following derivation and procedural rules will be enforced:

1. Supplier and Customer entities will each store a record called Miscellaneous for Cash Purchases and Cash Sales respectively.

2. Cash Purchases will include the following updates:

a. Write a record to Purchase Invoice Summary (related Purchase Order is null). If the Supplier is not listed in the Supplier entity use the default Miscellaneous Supplier record and put a comment in the comment field.

b. Write corresponding detail records in Purchase Invoice Detail.

c. Write a record in the Payments Made entity, for the relevant items.

d. Adjust the Quantity-on-Hand in the Inventory Master entity.

e. Write corresponding record in the Financial Transactions Log.

3. Credit Purchases will include the following updates:

a. Write a record to Purchase Invoice Summary.

b. Write corresponding records to Purchase Invoice Detail.

c. Update the related Purchase Order Summary record.

d. Adjust Quantity-on-Hand in Inventory Master entity for the relevant items.

e. Write Accounts Payable entry in Financial Transactions Log.

4. Payments Made will include the following updates:

a. Write a record to Payments Made entity.

b. Update the Invoice Outstanding Amount in the Purchase Invoice Summary entity.

c. Write a record in the Financial Transactions Log.

5. Each Purchase Return will include the following updates:

a. Write a record to the Purchase Returns Summary entity.

b. Write corresponding detail records to Purchase Returns Detail.

c. Adjust the Quantity-on-Hand in the Inventory Master entity, for the relevant items.

d. Adjust Outstanding-Amount in Purchase Invoice Summary.

e. Write corresponding record in Financial Transactions Log.

6. Cash Sales will include the following updates:

a. Write a record to the Sales Invoice Summary. If the customer is not listed in the Customer entity, use the default Miscellaneous Customer, with an appropriate comment in the comment field.

b. Write corresponding detail records in the Sales Invoice Detail.

c. Write a record in the Payments Received entity.

d. Adjust the Quantity-on-Hand in the Inventory Master entity, for the relevant items.

e. Issue a receipt and write record(s) in the Financial Transactions Log.

7. Credit Sales will include the following updates:

a. Write a record to the Sales Invoice Summary entity.

b. Write corresponding detail records in Sales Invoice Detail.

c. Adjust the Quantity-on-Hand in the Inventory Master entity, for the relevant items.

d. Write Accounts Receivable record in Financial Transactions Log.

8. Payments Received will include the following updates:

a. Write a record to Payments Received entity.

b. Update the Invoice Outstanding Amount in the Sales Invoice Summary entity.

c. Issue a receipt.

d. Write corresponding record in Financial Transactions Log.

9. Sales Returns will include the following changes:

a. Write a record to the Sales Returns Summary log.

b. Write corresponding details records to Sales Returns Detail log.

c. Adjust the Quantity-on-Hand in the Inventory Master entity, for the relevant items.

d. Adjust the Outstanding-Amount for the related Sale Invoice.

e. Write corresponding record in Financial Transactions Log.

10.Accounts Payable is determined by the formula:

Accounts Payable = [Purchase Invoices with non-zero Outstanding Amounts minus Purchase Returns with non-zero Return Amounts]

11.Accounts Receivable is determined by the formula:

Accounts Receivable = [Sales Invoices with non-zero Outstanding Amounts minus Sales Returns with non-zero Return Amounts]

These rules will be extremely useful during system development. Some of them will be incorporated into the relevant operation specifications, and included in the project’s design specification.

A9.5 Summary and Concluding Remarks

This document provided a basic blueprint for a generic Inventory Management System (IMS). It includes the following:

· An overview of the system, including problem definition, proposed solution, and system architecture.

· Storage requirements, including draft outlines for the basic information entities comprising the system.

· Operational requirements, including an initial list of user operations.

· Business rules, including derivation and procedural rules.

The design specification will use these requirements to prepare a more detailed set of specifications from which the system will be developed.