Table of Contents

3. Main System Features * ................................................................................................2
 4. External Interface Requirements................................................................................4
4.1  User Interfaces..................................................................................................................... 4
4.2  Hardware Interfaces.................................................................................... ........................4
4.3 Software Interfaces............................................................................................................. ..4
4.4  Communications Interfaces........................................................................................ .........5

Revision History
Name Date Reason For Changes Version

1. Introduction
1.1 Purpose

ATMed is an easy to use interface software designed to help pharmacies mainly with their
inventory, stock checking and transaction needs. ATMed can help a user can select the
item required , check for its availability and process the transaction. This document
describes the software requirements for ATMed.

1.2 Document Conventions

Source code will be listed in VERDANA font, with emphasized sections in bold type.

1.3 Intended Audience and Reading Suggestions

The intent of this document is to show prospective buyers of the proposed features of
ATMed .The current design is a product of preliminary discussions and is still a prototype
for the final document. This document covers only the current release; further
functionality can be added to future releases.
1.4 Product Scope

This document describes the basic features and uses of the software and is a prototype to
the fully generated document hence product scope is limited to certain constrains.

1.5 References
Documentation for downlink can be found in the

3. Main System Features * 

Suitable for Traders / Manufacturers / Distribution / Retails

Multi-company options
Multi Level Grouping for Items and Accounts
Discount structures for Item Level, Group Level, and Party Level
Analysis parameters
User definable charges and Charge Sets
Purchase and Sales Orders Entry
Definable Registers
Account system Control
Printable invoice

3.1 Secondary Features

Ease of Use
ATMed is simple and easy to understand and use. It is not necessary to know more about
computers. A person having typing knowledge and some accounting knowledge can
master the application.

Invoice generation / Printing

All necessary care has been taken in Invoice Generation option which includes printing of 
the same with calculation of VAT in special states in the Indian Territory. 

While entering Purchase bills, the bills including Purchase Rate Calculation, Sale Rate 
Calculation along with Taxes, Discounts etc. can be verified. Entire Stock is monitored 
through Batches. Expiry Dates can also be monitored. Checklist for Purchases in desired 
format to cross verify the purchase bills can also be generated.

Stock Inventory and Control

ATMed can generate all stock related reports and analysis reports based on purchases and 
sales. Reports like stock position, Stock & Sale Statement, Non­moving Stock, Excess 
Stock Holding Report, To be expired Stock Reports and Sales Analysis help immensely in 
keeping control over inventory.

[* : Prototype features]

Security

Access to ATMed is restricted by passwords with the support of User Manager. You can 
define feature level control for any user. Besides, sensitive information can be viewed, 
printed or changed only by using an admin password .

Further Security features and requirements are discussed later in the document
4. External Interface Requirements

4.1 User Interfaces

Initial discussions have generated a the use a simple GUI.

4.2 Hardware Interfaces

Discussions Pending

4.3Software Interfaces

Will mainly incorporate the use of C++ programing
4.4 Communications Interfaces

Will consist of communications using human inputs on a computer , HTTP protocol data
transfer and use of physical CPU hardware.

5. Other Nonfunctional Requirements
5.1 Performance Requirements

AT­med must run rapidly enough so that user input is not slowed. Methods which take a 
long time to execute must not block user input. This is being satisfied in the current 
implementation by causing the software invocation to run as a thread.

5.2 Security Requirements
Any   security   issues   concerning   the   software   are   inherited   by   AT­med,   especially   the 
potential   of   overwriting   the   results   of   previous   software   runs,   since   in   general   the 
software invoked by AT­med read from and write to the file system. It is recommended 
that   reprocessing   be   done   in   a   private   copy   of   the   automated   processing   directory 
structure Policies for accessing data from the sandbox or archive should be followed in 
the context of using AT­med. AT­med itself reads and writes property files to remember 
user   settings,   but   these   files   are   uniquely   named   and   will   not   interfere   with   other 
software.

5.3 Software Quality Attributes

The main attribute of AT­med must be ease of use, for it is currently possible, though 
difficult,   to   run   the   pipelines   offline   without   AT­med.   While   constrained   by   the 
previously determined software design, details of the implementation should be handled 
by the internal workings of AT­med, leaving as its outward form the clear and rapid 
facilitation of user input.

AT­med   is   being   designed   via   the   use   of   software   patterns   wherever   possible,   for 
robustness and for clarity of code to facilitate future maintenance. Each AT­med function 
is written as a package contains its own view class contained in a panel, so that it can be 
inserted into AT­med or perhaps another application as a discrete component.

6. Other Requirements

It is expected that user feedback will result in requests of increased functionality. To aid in 
extensibility,   AT­med   is   being   designed   using   an   event­driven   software   architecture 
model. The design is based on that used in the software. Further information can be found 
in the source code documentation in preparation.

Appendix : To Be Determined List 
There is no TBD for the current version. The exact use and form of features to be added 
in future versions are yet to be determined.