Software Requirements

Specification
For

Diaposa

Version 1.0 approved

Prepared by Adam G. Saslow, David Rappo

The Diaposa Project

4/30/2006
Software Requirements Specification for Diaposa Page 1

Table of Contents
1. Introduction................................................................................................................................2
1.1 Purpose ............................................................................................................................................... 2
1.2 Intended Audience.............................................................................................................................. 2
1.3 Project Scope....................................................................................................................................... 2
1.4 References........................................................................................................................................... 2
2. Overall Description....................................................................................................................3
2.1 Product Perspective............................................................................................................................. 3
2.2 Product Features.................................................................................................................................. 3
2.3 User Classes and Characteristics........................................................................................................ 4
2.4 Operating Environment....................................................................................................................... 4
2.5 Design and Implementation Constraints............................................................................................. 4
2.6 User Documentation........................................................................................................................... 4
2.7 Assumptions and Dependencies......................................................................................................... 4
3. System Features......................................................................................................................... 5
3.1 Requirements Priority - Legend.......................................................................................................... 5
3.2 Inventory Management....................................................................................................................... 5
3.2.1 Duties of the Inventory Clerk....................................................................................................... 5
3.2.2 Labeling........................................................................................................................................ 6
3.2.3 Suppliers – Refunds & Returns.................................................................................................... 6
3.3 Point of Sale........................................................................................................................................ 7
3.3.1 Duties of the Cashier.................................................................................................................... 7
3.4 Management........................................................................................................................................ 8
3.4.1 Duties of the Manager.................................................................................................................. 8
3.4.2 Reporting...................................................................................................................................... 9
3.4.3 System Options............................................................................................................................ 9
4. External Interface Requirements........................................................................................... 10
4.1 User Interfaces.................................................................................................................................. 10
4.2 Hardware Interfaces.......................................................................................................................... 10
4.2.1 UPC Barcode Scanner................................................................................................................ 10
4.2.2 Credit Card Reader..................................................................................................................... 10
4.2.3 Cash Drawer............................................................................................................................... 10
4.2.4 Receipt Printer / Printer.............................................................................................................. 11
4.2.5 PDA w/ Barcode Scanner (optional system component)........................................................... 11
4.2.6 Video Capture............................................................................................................................ 11
4.3 Software Interfaces........................................................................................................................... 11
4.4 Communications Interfaces............................................................................................................... 11
5. Other Nonfunctional Requirements.......................................................................................11
5.1 Performance Requirements............................................................................................................... 11
5.2 Safety Requirements......................................................................................................................... 12
5.3 Security Requirements...................................................................................................................... 12
5.4 Software Quality Attributes.............................................................................................................. 12
6. Other Requirements................................................................................................................ 12

Revision History
Name Date Reason For Changes Version
Initial Draft 4/30/06 N/A x.1
Software Requirements Specification for Diaposa Page 2

1. Introduction

1.1 Purpose

Diaposa is a Point of Sale Application (and its name is recursive! How ‘bout that?)

The Diaposa Project aims to fill two needs. First, Diaposa will be a tool for small businesses to
accomplish various tasks associated with small business management. Second, the Diaposa
Project aims to create a service based market for Open Source Software Engineers; that they
may be able to provide businesses with powerful, robust software under a business model based
on software support.

1.2 Intended Audience

This document is intended to deliver a high-level overview of Diaposa. Software Developers,

System Engineers, and small Business Owners (with a basic knowledge of software; what it is,
how it is generally developed) will benefit from this document. In addition, the Diaposa Project
hopes that these aforementioned individuals will be able to contribute insight and suggestions on
the system requirements defined later in this document.

1.3 Project Scope

Diaposa is designed to be a replacement for old or obsolete Point of Sale systems. Many
businesses are working with very old Point of Sale technology. While older systems may remain
functional, it is noteworthy that businesses continue to operate these older systems, often with no
support whatsoever. In this regard, old systems can be a disaster waiting to happen, often with
no recovery plan in place!

1.4 References

Diaposa’s BountySource page will hold documentation relating to the project.

Software Requirements Specification for Diaposa Page 3

2. Overall Description

2.1 Product Perspective

Diaposa will replace old, obsolete systems with a better approach that will better connect
business locations, make time-consuming tasks more efficient, and put the business in a better
position to succeed.

• Diaposa will consist of 1 or more Diaposa Workstations at any given Business Location
• The option to utilize PDA software (with a UPC barcode scanner interface) is available for
the purpose of taking inventory. The PDA will use a wireless connection to interface with
the Main Data Store.
• One or more Business Locations will connect to that business’ Main Data Store.

A (very generic) high level Enterprise Application Diagram follows:

2.2 Product Features

Diaposa will include the following functionality in the initial release:

• Inventory Management
• Bar-Code Scanning
• Trend Reporting
• Loss Prevention
Software Requirements Specification for Diaposa Page 4

• Point of Sale

2.3 User Classes and Characteristics

A use case diagram is posted on Diaposa’s BountySource page, defining users and their
interactions with Diaposa. For the purpose avoiding multiple versions of diagrams, it is NOT
embedded in this document.

2.4 Operating Environment

The Diaposa Workstation is designed to run on a Windows PC with .NET 2.0 framework installed.
The Diaposa Main Data Store will also be a Windows PC with .NET 2.0. The Main Data Store will
run XAMPP, providing Apache / MySQL / phpMyAdmin.

2.5 Design and Implementation Constraints

Implementation Constraints
Software Based:
• This application will be a C# MDI Application
• The Database within the Main Data Store will be MySQL, running under XAMPP.
Hardware Based
• Where hardware is concerned (i.e. – Cash Drawer; programmatically controlled via
parallel port), cost efficiency and ease-of-implementation will delegate a unified
hardware platform that all instances of Diaposa will run on. As of this document’s
release, no hardware has been identified as the standard for Diaposa.

2.6 User Documentation

User documentation will be authored at a later date. It is likely that if Diaposa is a success,
Diaposa’s distributors will write their own user-documentation (and share it with the community,
we would hope!). If distributors do not generate documentation, then it will become a
requirement that Diaposa be delivered with user-documentation.

2.7 Assumptions and Dependencies

N/A
Software Requirements Specification for Diaposa Page 5

3. System Features

3.1 Requirements Priority - Legend

Color Priority
RED HIGH
ORANGE Medium
GREEN Low
BLUE Optional

3.2 Inventory Management

3.2.1 Duties of the Inventory Clerk

3.2.1.1 A user with the role of Inventory Clerk will be able to M/A/C a supplier, and the items that
supplier provide.

3.2.1.2 A user with the role of Inventory Clerk will be able to specify a reorder point for any item in the
system. When an inventory item falls below the reorder point, the system will record this. Management
will later be notified via an inventory report.

3.2.1.3 A user with the role of Inventory Clerk will be able to send a Supplier an Email with a Purchase
Order for inventory.

3.2.1.4 A user with the role of Inventory Clerk will be able to take inventory. A PDA will have a UPC
scanner attached to it, and will be used for the purpose of taking inventory.

3.2.1.5 A user with the role of Inventory Clerk will be able to take inventory in the traditional sense;
inventory is manually checked and the results entered into the system.

3.2.1.6 When the analysis of inventory is complete, a report will be generated identifying possible
shrinkage. This report can be emailed, printed, or both.

3.2.1.7 A user with the role of Inventory Clerk must approve an inventory survey before a report can be
generated. This will act as a safeguard against entering an erroneous report.

3.2.1.8 A user with the role of Inventory Clerk will be able to physically receive a shipment from a
supplier, and verify the shipment contains the desired stock by scanning UPC codes on the inventory
items. This operation can be performed via a PDA hooked up to the local Workstation.

3.2.1.9 When an Inventory Clerk scans the UPC barcode of an item included in a supplier’s shipment,
Inventory is automatically adjusted.
Software Requirements Specification for Diaposa Page 6

3.2.2 Labeling

3.2.2.1 The Inventory Clerk will be able to create a UPC label and associate that label with an inventory
item. The labels can be printed out with special paper and used as the user sees fit.

3.2.3 Suppliers – Refunds & Returns

3.2.3.1 If a supplier’s shipment is NOT complete, a Request for Credit document can be generated and
sent to the supplier via email, or printed out for snail mail delivery. The Request for Credit Document
will provide two documents: the original purchase order, a list of contents received in the supplier’s
shipment, and a gap analysis of the aforementioned two documents.

3.2.3.2 A user with the role of Inventory Clerk will be able to generate a report for the purpose of
returning stock to a supplier. This report can be sent via Email or Printed out. The report will detail the
contents of the return shipment, along with an itemized list defining the reason for return of the
suppliers’ goods. Upon generation of this report, inventory is automatically adjusted.
Software Requirements Specification for Diaposa Page 7

3.3 Point of Sale

3.3.1 Duties of the Cashier

3.3.1.1 A user with the role of Cashier will be able to Log on and off the System. The system will note
then date and time the user logs into and out of the system.

3.3.1.2 A user with the role of Cashier will be able to open a new cash drawer session, with an initial
amount of money in the drawer. The system will keep track at all times of what monies should be in the
cash drawer.

3.3.1.3 A user with the role of Cashier will be able to close an existing cash drawer session. When
closing the cash drawer, the system will display the amount of money that should be in the register so the
Cashier will know what monies should be in the drawer.

3.3.1.4 A user with the role of Cashier will be able to initiate a new transaction when serving a customer
in line.

3.3.1.5 A user with the role of Cashier will be able to scan a UPC bar code. The scanned item will
appear in a “cart” – a list containing all items purchased by the user. The scanned item may be a receipt,
in the event of a return.

3.3.1.6 A user with the role of Cashier will be able to view a past purchase by scanning a customer’s
receipt. The Cashier will then be able to select items from that purchase, and perform a “return item”
operation on line items in that purchase. The system will handle cash back / store credit situations.

3.3.1.7 A user with the role of Cashier will be able to manually M/A/C on the customer’s “cart”

3.3.1.8 A user with the role of Cashier will be able to apply a discount against the user’s cart. This
discount may be a general discount (i.e. – 10% off total purchase), or a targeted discount (i.e. – Buy 4
widgets; get the 5th widget 40% off). Discounts may come in the form of a coupon which is scanned and
applied to the cart in a similar manner to any other scanned item.

3.3.1.9 A user with the role of Cashier will be able to select an Employee from a list of employees, and
attribute the customer’s purchase to a store Employee (this is a commission assignment).

3.3.1.10 A user with the role of Cashier will be able to accept payment from a customer. Payment
can come in the following forms:

• Credit Card
• Cash
• Store Credit
• Gift Card
• Check
Software Requirements Specification for Diaposa Page 8

3.3.1.11 A user with the role of Cashier will be able to give change from the cash drawer to the
customer.

3.3.1.12 A user with the role of Cashier will be able to present the customer with a receipt. The
customer may be instructed to sign this receipt.

3.3.1.13 A user with the role of Cashier will be able to choose to “Complete Transaction.” This
operation will adjust inventory, and close the transaction.

3.4 Management

3.4.1 Duties of the Manager

3.4.1.1 A manager must be present when opening or closing a cash drawer session. The manager will
approve the session, signing off on the amount of money in the cash register at the beginning of the
session, or signing off on the amount of money in the cash drawer at the end of the session. The system
will keep track of what monies should be in the drawer throughout the day. In the event of a discrepancy
between the system’s calculation (“what SHOULD be in the drawer”) and the cashier’s counted amount
(“what IS in the drawer”), the manager will enter the discrepancy amount into the system.

3.4.1.2 A user with the role of Manager will be able to start and stop a security recording session. The
manager may also perform a timed recording (i.e. - Record from 4 a.m. to 8 a.m., when the store is
closed, to capture any break-ins on camera).

3.4.1.3 A user with the role of Manager must approve an Inventory Clerk’s inventory analysis. Upon
approval by the manager, inventory is automatically adjusted, and the system will note discrepancies in
the inventory (potential shrinkage).

3.4.1.4 A user with the role of Manager will be able to M/A/C on users in the system, including
assignment and un-assignment of roles.
Software Requirements Specification for Diaposa Page 9

3.4.2 Reporting

3.4.2.1 A user with the role of Manager will be able to generate a Trend Report for a specified period of
time. The report’s purpose is to identify the best products over the given period of time, and the products
whose sales have significantly increased in the specified period of time.

3.4.2.2 A user with the role of Manager will be able to generate an inventory report. The inventory
report is designed to give the manager an idea of what the store has, what the store does not have, what
the store needs, and what shrinkage may have occurred.

3.4.2.3 Reports can be viewed through the system, sent via Email, or printed out.

3.4.3 System Options

3.4.3.1 The system will have an option to require a manger’s approval on all Purchase orders made by
an Inventory Clerk.
Software Requirements Specification for Diaposa Page 10

4. External Interface Requirements

4.1 User Interfaces

Overview:
• Diaposa will be a Windows MDI Application
• The UI will be designed with real-world scenarios in mind. For example, the cashier must
be able to efficiently navigate the UI without using the mouse mid-transaction
• Access privileges to User-specific UI screens will only be accessible to users with the
proper roles (i.e. – a “need to know” basis).
• The UI will be highly streamlined and easily accessible. Icons and images will readily
display functionality (when viewed by a user with reasonable experience). The UI will be
laid out in a logical progression where common functional items are grouped together
(The user will not scratch their head wondering, “Why the heck is this HERE?” when using
the interface).
• Where logical, toolbars and tab-controls will be used, as this document champions the
notion that these are the easiest controls to code, and the most robust (read: useful) for
the user.

Figure: Diaposa Main Form (Prototype)

4.2 Hardware Interfaces

4.2.1 UPC Barcode Scanner

This device scans UPC barcodes and interprets a barcode into an SKU number, used by Diaposa
for various purposes (e.g. – Point of Sale transaction, inventory management, etc.).

4.2.2 Credit Card Reader

This device will read a customer’s credit card and charge an amount based on a Point of Sale
transaction. How this will be integrated is TBD.

4.2.3 Cash Drawer

A cash drawer will be used to hold cash and change. Diaposa will interact with the cash drawer
and send appropriate commands to open the drawer at a specific time (identified in Diaposa’s use
case document).
Software Requirements Specification for Diaposa Page 11

4.2.4 Receipt Printer / Printer

A receipt printer will print out a receipt based on a transaction. This could be a smaller receipt
only printer, or a standard 8.5 x 11 printer. The 8.5 x 11 printer is mandatory for the purposes of
printing out reports, sending Purchase Orders, etc.

4.2.5 PDA w/ Barcode Scanner (optional system component)

Diaposa will have an optional subsystem in a PDA / UPC barcode scanner that will make more
efficient the process of receiving shipments and taking inventory. The PDA will use a wireless
interface to relay information from the PDA to the Diaposa Main Data Store.

4.2.6 Video Capture

A network of one or more video cameras with PC connectivity will be used such that Diaposa can
communicate with the camera interface and carry out desired security operations, including:
• Timed / Scheduled Video Recordings
• Still Image Capture

4.3 Software Interfaces

<Describe the connections between this product and other specific software components (name
and version), including databases, operating systems, tools, libraries, and integrated commercial
components. Identify the data items or messages coming into the system and going out and
describe the purpose of each. Describe the services needed and the nature of communications.
Refer to documents that describe detailed application programming interface protocols. Identify
data that will be shared across software components. If the data sharing mechanism must be
implemented in a specific way (for example, use of a global data area in a multitasking operating
system), specify this as an implementation constraint.>

4.4 Communications Interfaces

<Describe the requirements associated with any communications functions required by this
product, including e-mail, web browser, network server communications protocols, electronic
forms, and so on. Define any pertinent message formatting. Identify any communication
standards that will be used, such as FTP or HTTP. Specify any communication security or
encryption issues, data transfer rates, and synchronization mechanisms.>

5. Other Nonfunctional Requirements

5.1 Performance Requirements

<If there are performance requirements for the product under various circumstances, state them
here and explain their rationale, to help the developers understand the intent and make suitable
design choices. Specify the timing relationships for real time systems. Make such requirements
as specific as possible. You may need to state performance requirements for individual functional
requirements or features.>
Software Requirements Specification for Diaposa Page 12

5.2 Safety Requirements

<Specify those requirements that are concerned with possible loss, damage, or harm that could
result from the use of the product. Define any safeguards or actions that must be taken, as well
as actions that must be prevented. Refer to any external policies or regulations that state safety
issues that affect the product’s design or use. Define any safety certifications that must be
satisfied.>

5.3 Security Requirements

<Specify any requirements regarding security or privacy issues surrounding use of the product or
protection of the data used or created by the product. Define any user identity authentication
requirements. Refer to any external policies or regulations containing security issues that affect
the product. Define any security or privacy certifications that must be satisfied.>

5.4 Software Quality Attributes

<Specify any additional quality characteristics for the product that will be important to either the
customers or the developers. Some to consider are: adaptability, availability, correctness,
flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability,
and usability. Write these to be specific, quantitative, and verifiable when possible. At the least,
clarify the relative preferences for various attributes, such as ease of use over ease of learning.>

6. Other Requirements
<Define any other requirements not covered elsewhere in the SRS. This might include database
requirements, internationalization requirements, legal requirements, reuse objectives for the
project, and so on. Add any new sections that are pertinent to the project.>

Appendix A: Glossary
<Define all the terms necessary to properly interpret the SRS, including acronyms and
abbreviations. You may wish to build a separate glossary that spans multiple projects or the
entire organization, and just include terms specific to a single project in each SRS.>

Appendix B: Analysis Models

<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams,
state-transition diagrams, or entity-relationship diagrams.>

Appendix C: Issues List

< This is a dynamic list of the open requirements issues that remain to be resolved, including
TBDs, pending decisions, information that is needed, conflicts awaiting resolution, and the like.>