Software Requirements Specification

for

Tollway Itemization System

(Head office order processing) Irpan M
101776 VI sem MCA Aloysius Institute of Management and Information Technology (AIMIT) St. Aloysius College (Autonomous) Beeri, Mangalore 27-02-2013

Under the guidance of Ms.Kavitha Rajmani Lecturer, MCA Department Aloysius Institute of Management and Information Technology (AIMIT) St. Aloysius College (Autonomous) Beeri, Mangalore Submitted to

ALOYSIUS INSTITUTE OF MANAGEMENT AND INFORMATION TECHNOLOGY (AIMIT) ST ALOYSIUS COLLEGE (AUTONOMOUS)
MANGALORE, KARNATAKA

Table of Contents
Table of Contents .......................................................................................................................... 2 Revision History ............................................................................................................................ 2 1. Introduction 1.1 Purpose ........................................................................................................................... 2 1.2 Document Conventions .................................................................................................... 2 1.3 Intended Audience and Reading Suggestions ...................................................................... 2 1.4 Project Scope ............................................................................................................... 3 1.5 References ....................................................................................................................... 3 2. Overall Description 2.1 Product Perspective ......................................................................................................... 3 2.2 Product Features .............................................................................................................. 4 2.3 User Classes and Characteristics ....................................................................................... 4 2.4 Operating Environment .................................................................................................... 5 2.5 Design and Implementation Constraints ............................................................................ 6 2.6 User Documentation........................................................................................................ 6 2.7 Assumptions and Dependencies........................................................................................ 6 3. System Features 3.1 Purchase Order Initiation ............................................................................................... 7 3.2 Purchase Order Review ................................................................................................. 7 3.3 Purchase Order Approval............................................................................................... 8 3.4 Dispatch Request Initiation ............................................................................................ 9 3.5 Dispatch Request Approval............................................................................................ 9 3.6 Reports ......................................................................................................................... 10 3.7 Dashboards ................................................................................................................... 10 4. External Interface Requirements 4.1 User Interfaces ............................................................................................................... 11 4.2 Hardware Interfaces........................................................................................................ 12 4.3 Software Interfaces ..........................................................................................................12 4.4 Communications Interfaces .............................................................................................. 12 5. Other Nonfunctional Requirements 5.1 Performance Requirements .............................................................................................. 12 5.2 Safety Requirements ................................................................ ....................................... 13 5.3 Security Requirements .....................................................................................................13 5.4 Software Quality Attributes.............................................................................................. 13 6. Other Requirements ................................................................................................................. 14 Appendix A: Glossary .................................................................................................................... 14

Revision History

I. Introduction
1.1 Purpose
The purpose of this document is to present a detailed description of the project Tollway Itemization System (Head office order processing). It will also explain the functional specification for the project. This SRS will deal with Head office order processing module. RFID toll collection is the latest technology for collecting the toll. Ordering for RFID tag in traditional system requires more time and resource. Ordering for RFID based on sub office order request. It is a 3 step process. Automated system will reduce the time for processing the order and provide the highly graphical user interface with reports and dashboards. In manual system initiator will send order request to inventory manager, he will intern send to Financial Manager, all these process will done using mail or some other means. It is time consuming and difficult to keep the record of order request. This system will provide automated and highly graphical interface for order processing with reports and dashboards.

1.2 Document Conventions

This document conforms to IEEE standards of documenting Software Requirements Specification. The document has used short forms for some commonly abbreviated terms. The main headings are of font size 18 pt whereas sub-headings are of 14 pt. Main and subheadings are kept bold and formatted to Arial font and Regular font style. The rest of the document is written in Times New Roman font and Regular font style with 1.5 line spacing and the font size is 12 pt. The project name is bolded throughout the document. The first line of every paragraph is indented to two tab spaces.

1.3 Intended Audience and Reading Suggestions

The intended audiences of this system include the members of development team, project managers, solution managers, QAs, documentation writers and end users. Further, this SRS contains the overall description of the system, System Features and the Interface requirements the product needs to be built in and other non functional requirements.

The overall description of the system helps the users and the documentation writers better understand the working and the features of the product. It helps the QAs verify the correctness of the functionalities provided by the application. The interface description will be useful during installation process. Henceforth, in this document The Tollway Itemization System will be referred as The System unless mentioned otherwise.

1.4 Project Scope

The scope of the project extends to all the departments within the organization which requires order processing. This can be used in any organization for order processing with some customizations. The main objective of the project is to allow the head office to process the request for tags from sub office in an organized way by following all the formal activities (workflow) in a less time and provide highly interactive automated application to maintain all the transaction details and generate different kinds of report. Project will provide user friendly application with highly interactive GUI to process the order request and generate interactive reports. This system is advantageous in many ways Automated order processing In every stage user gets email notification Reports and Dashboards help the managers in better decision taking. All the transaction will be recorder appropriately

1.5 References
The following material and links have been referred to document the Software Requirements Specification for project: Functional Specification provided by MetricStream Inc. Software Engineering A Practitioners Approach - Roger S Pressman.

2. Overall Description
2.1 Product Perspective
Order Processing of RFID tags is currently performed by filling the document and it will be sent to Inventory Manager for approval. If he rejects it will be sent to initiator else it will be sent to further approval from Finance Manager. To send the document and approval

process will take more time in current system, it is difficult to generate reports and keep track of the order generated. Manual process is cumbersome and prone to errors as there is no validation as such. This puts burden on both, the initiator requesting for order and also the managers who have to evaluate the documents. The system automates this procedure. It serves different categories of users namely Request Clerk, Inventory Manager, Finance Manager and Dispatch Clerk. Request Clerk initiate the RFID order request, Inventory Manager Reviews it based on the requirement, he can either accept or reject, and Inventory Manager also reviews the dispatch request. Finance Manager Review the order based on the financial aspect and he approves or reject. Dispatch clerk initiate the dispatch of RFID tags to sub office.

2.2 Product Features

The product allows authenticated users perform various tasks based on the roles and responsibilities assigned to them which include: Initiate RFID order Request Initiate RFID dispatch request Revert back Order Request to the initiator(from Review stage, Approve stage) Revert back Order Request to the initiator(from Approve stage by Finance Manager) Approve Order Request by Inventory Manager, Finance Manager Revert back Dispatch Request to the initiator(from approval stage by Inventory Manager) Provides a view of the appraisal process with the help of various reports and dashboards.

2.3 User Classes and Characteristics

There are various kinds of user for the product Tollway Itemization System(Head office order processing). Different users access the application for distinct reasons based on their organization hierarchy level and role.

Request Clerk Initiator is the one who can raise an order request.

Some clerks in an organization will be assigned to this role. This user can access the order request sent by sub offices. This user has access to reports generated by using sub office requests.

Reviewer Inventory Managers at various levels of organization are users who review the requests sent by request clerk and approves the request sent by dispatch clerk. These users have access to reports and dashboards of order request and dispatch requests.

Approver Finance Mangers at various levels of organization is user who approves the requests approved by inventory Manager based on the financial aspect of the organization. These users also have access to reports and dashboards of order requests approved and rejected by Finance Manager.

Dispatch Clerk Dispatch Clerk is one who initiate dispatch request. Some clerks in an organization will be assigned to this role. This user has access to reports generated by using dispatch request.

2.4 Operating Environment

Platform AppStudio 2.2 is certified on ECP(Enterprise Compliance Platform) 6.0 SP4 Data Object Designer, Workflow Designer, Blue Print Designer and Form Designer is available for 6.0 Browser version Microsoft Internet Explorer 8.0, 9.0 and higher

Operating Systems (MetricStream Server) Microsoft Windows Server 2008 (32 bit) Microsoft Windows Server 2008 (64 bit) Linux

MetricStream Application Platform MetricStream Enterprise GRC Platform Version 6.0 Build: 6.0.2.0.0 Database Version: 6.0.2.0.0

Database Oracle Standard Edition 11g or higher.

2.5 Design and Implementation Constraints

The look and feel of the system is governed by the platform i.e., ECP 6.0 SP4. The technical scope for the development of the system is the same as that of the platform. These limitations are documented in user guide of the platform and are proprietary and confidential property of MetricStream Inc., Though the interface to the system is web based and accessed through an html web browser, the system works flawlessly on only Internet Explorer. This issue is attributed to the way in which the platform is developed and is expected to be dealt with the future release of the platform. The development of the system will totally depend upon the availability of required software such as web servers, database and development tools.

2.6 User Documentation

There wont be any user manuals as such given along with Tollway Itemization System. The system itself is very user friendly which will guide the end users about how to go about using the software.. A live demo of project Tollway Itemization System will be given to the concerned user group/client during project release. There are no immediate plans to create detailed user documentation. However, if requested, the user documentation may be created.

2.7 Assumptions and Dependencies

ECP is the fundamental platform for the system. Hence the performance and stability of it will be dependent on that of the ECP. The users of the system have the basic knowledge and skills to work on a regular Metricstream application.

3. System Features
Here are some functionality features which are expected to be provided by the system.

3.1 Purchase Order Initiation

3.1.1 Description and Priority Any of purchase clerks, who are eligible, can initiate RFID order request using this feature. Here, the user is provided a purchase order request initiation form where he can fill all the details. This is a critical priority feature.

3.1.2

Stimulus/Response Sequences An RFID tag purchase order request is initiated by one of the users. This is then sent for review to higher authorities. Appropriate emails and assignments are sent to appropriate users.
. (Currently support 3 levels)

3.1.3

Functional Requirements REQ1: Email must be setup to enable notification on arrival of review request REQ2: Inputs for some fields in the form which are a set of values to choose from must be pulled from the database or LOVs, must be defined priori. REQ3: The business rules to validate form inputs must be coded onto front end page. REQ4: Purchase Order Request info center has to be present REQ5: Purchase Order Request Initiation form link should be available.

3.2 Purchase Order Review

3.2.1 Description and Priority Any of Inventory Managers who is eligible, can review and he can approve or rejects. Here Request initiation form will be carried forward with field for approval by inventory manager.

3.2.2

Stimulus/Response Sequences Once request in approved it will be sent to approver for further approval process. If he rejects then it will be sent to requestor.

3.2.3

Functional Requirements REQ1: All Fields specific to requestor are sealed for change REQ2: All the fields which are entered by requester should be pulled to current form. REQ3: The business rules to validate form inputs must be coded onto front end page. REQ4: Email must be setup to enable notification on arrival of review request REQ5: Assignment should be triggered to notify reviewer.

3.3 Purchase Order Approval

3.3.1 Description and Priority Any of Finance Managers who is eligible, can approve or rejects based on the financial status of organization. Request initiation form will be carried forward with field for approval by finance manager. 3.3.2 Stimulus/Response Sequences Once request in approved, mail will be sent to requestor, inventory manager. If he rejects then mail will be sent with appropriate comment and assignment will be sent to requestor.

3.3.3

Functional Requirements REQ1: All Fields specific to requestor and reviewer are sealed for change REQ2: All the fields which are entered by requester and reviewer should be pulled to current form. REQ3: The business rules to validate form inputs must be coded onto front end page. REQ4: Email must be setup to enable notification on arrival of approval request REQ5: Assignment should be triggered to notify approver. REQ6: Purchase order document should be generated.

3.4 Dispatch Request Initiation

3.4.1 Description and Priority Any of Dispatch clerks, who are eligible, can initiate RFID dispatch request using this feature. This is used to dispatch the tags to sub offices. Here, the user is provided a dispatch initiation form where he can fill all the details. This is a critical priority feature.

3.4.2

Stimulus/Response Sequences A dispatch request is initiated by one of the dispatch clerks. This is then sent for approval to higher authorities. Appropriate emails and assignments are sent to appropriate users.
. (Currently support 2 levels)

3.4.3

Functional Requirements REQ1: Email must be setup to enable notification on arrival of approval request REQ2: Inputs for some fields in the form which are a set of values to choose from must be pulled from the database or LOVs, must be defined priori. REQ3: The business rules to validate form inputs must be coded onto front end page. REQ4: Dispatch Request info center has to be present REQ5: Dispatch Request Initiation form link should be available. REQ6: Sub office name should be clearly mentioned with priority.

3.5 Dispatch Request Approval

3.5.1 Description and Priority Any of Inventory Manager who is eligible, can approve or rejects based on the priority of the sub office requests. Dispatch Request initiation form will be carried forward with field for approval by inventory manager. 3.5.2 Stimulus/Response Sequences Once request in approved, mail will be sent to requestor, inventory manager. If he rejects then mail will be sent with appropriate comment and assignment will be sent to requestor.

3.5.3

Functional Requirements REQ1: All Fields specific to dispatch requestor are sealed for change REQ2: All the fields which are entered by requester should be pulled to current form. REQ3: The business rules to validate form inputs must be coded onto front end page. REQ4: Email must be setup to enable notification on arrival of approval request REQ5: Assignment should be triggered to notify approver. REQ6: Assignment will be closed with generation of dispatch document.

3.6 Reports
3.6.1 Description and Priority The users of various levels will have different types of reports based on the roles of user. Users with higher authority will have high level of reports. 3.6.2 Stimulus/Response Sequences Reports generated are depending upon the parameter that passes to it. The parameter can be order status, sub office name, dispatch request status etc. 3.6.3 Functional Requirements REQ1: Inputs for parameters in the report which are a set of values to choose from must be pulled from the database or LOVs, must be defined priori. REQ2: Tollway Report info port has to be present REQ3: link has to be present in the info port for reports.

3.7 Dashboards
3.7.1 Description and Priority Provides the visualization for requests made as charts. Best supported Chart type are PIE and Bar charts.

3.7.2

Stimulus/Response Sequences Click on the different part of the chart will be drilled down accordingly as report or dashboard

3.7.3

Functional Requirements REQ1: Inputs for parameters in the infolet which are a set of values to choose from must be pulled from the database or LOVs, must be defined priori. REQ2: Tollway Dashboard info port has to be present REQ3: link has to be present in the info port for dashboards.

3.8 Vendor Addition Initiation

3.8.1 Description and Priority Any of clerks, who are eligible, can initiate Addition of vendor. This is used to add the vendors to SYSTEM. Here, the user is provided a vendor addition form where he can fill all the details. This is a critical priority feature. 3.8.2 Stimulus/Response Sequences A Vendor Addition request is initiated by one of the clerks. This is then sent for Approval to higher authorities. Appropriate emails and assignments are sent to appropriate users.
. (Currently support 2 levels)

3.8.3

Functional Requirements REQ1: Email must be setup to enable notification on arrival of approval request REQ2: Inputs for some fields in the form which are a set of values to choose from must be pulled from the database or LOVs, must be defined priori. REQ3: The business rules to validate form inputs must be coded onto front end page. REQ4: Vendor Addition Request info center has to be present REQ5: Vendor Addition Request form link should be available. REQ6: All details should be clearly mentioned with priority.

3.9 Vendor Addition Approval

3.9.1 Description and Priority Any of Finance Manager who is eligible, can approve or rejects based on the priority of the sub office requests. Vendor Addition Request initiation form will be carried forward with field for approval by finance manager.

3.9.2

Stimulus/Response Sequences Once request in approved, mail will be sent to requestor, inventory manager. If he rejects then mail will be sent with appropriate comment and assignment will be sent to requestor.

3.9.3

Functional Requirements REQ1: All Fields specific to vendor addition requestor are sealed for change REQ2: All the fields which are entered by requester should be pulled to current form. REQ3: The business rules to validate form inputs must be coded onto front end page. REQ4: Email must be setup to enable notification on arrival of approval request REQ5: Assignment should be triggered to notify approver.

4. External Interface Requirements

4.1 User Interfaces
The entire system inherits its UI from the platform. It is meant to have a single web based UI. It is a self contained system to manage users, roles, organizations and their hierarchy. It also allows creation and management of data objects and creates interfaces to the same with the help of Data Forms. Tabs to navigate between different groups of functionality
My Task: easy way to provide assignment notification for approval or Clarification request

My Task: easy way to provide assignment notification for approval or Clarification request

Infoport: Provide functionality like (Forms, Report, Dashboard) Browser to quickly access Modules, data objects and forms.

Here are some key UI characteristics: Provides consistent navigational concepts and application patterns across all applications. Information-based user interface. Minimize the number of clicks to get to any form, report or dashboard Minimize clutter and improve visual appeal Provide contextual information

4.2

Hardware Interfaces
This system requires following hardware interfaces: A Printing Device to generate dispatch and purchase document.

4.3 Software Interfaces

The major interface to communicate with the software is the Internet Explorer. Apart from which we can use multiple other applications like Toad, Sql Plus, WinSap, Notepad++,

and SQL Developer. The system works on the apache and tomcat server, this requires both the services to be in running sate for the application to work.

4.4 Communications Interfaces

The system requires the following communication interfaces to operate at full functionality. Network connection to communicate between client and server. Web browser to interact with the system (Certified to work only on Internet Explorer). Email setup to send out notifications.

5. Other Nonfunctional Requirements

5.1 Performance Requirements
It is desired to design the system in a manner where the system would be reasonably responsive all the time. Although the performance aspect which includes responsiveness is basically attributed to the underlying platform there are some key factors that would help from the development front. This would be efficient JS coding and optimizing DB usage/lookups.

5.2 Safety Requirements

The major issue of concerns is when we re-built/deploy our system after making some changes in either of the forms or process-flow at later point of time once the system is already deployed and worked on. Rebuilding or deploying of the system truncates all the data from applications tables. This leads in loss of data. The best practice followed is to take a database dump before deploying any form or process.

5.3 Security Requirements

The system inherits its security features from the platform. This includes various users with different roles and responsibilities, access control to data based on various factors like organization hierarchy, user roles and privileges. The data is abstract from the user and integrally maintained by the system / platform, assuring data integrity.

The system is hosted on a secured server, so a certain set of security risks are eliminated. But it is required to ensure that the host server is free of system security threats / loopholes.

5.4 Software Quality Attributes

Here are a few quality attributes expected of the system.

Intuitive & value-added information presentation

Dynamic presentation of relevant information & actions Maintain context during interactions Tabbed presentation Field and Page-specific help

Sleek & elegant

NOT an Industrial look. Icons & graphics based - More visual. Clean lines and pleasing color palette.

Intuitive navigation

Navigation constructs corresponding to task (e.g. hierarchical control/risk

navigation).

Leverage common metaphors like calendars. Single click for most common actions. No more than two clicks to get to any action.

Consistency

Across applications/platform activities and pages.

6. Other Requirements
There are no other requirements that need a mention for this application.

Appendix A: Glossary
The following are the list of conventions and acronyms used in this document and the project as well: o SRS (Software Requirements Specification) o EGRCP (Enterprise Governance Risk Compliance Platform) o IEEE (Institute of Electrical and Electronic Engineers) o FS (Functional Specification) o QA (Quality Analyst)

Term

Definition MetricStream EGRCP has been designed to enable building, configuring,

EGRCP

and deploying Compliance and Quality Management Applications for large and small enterprises. MetricStream AppStudio is a suite of tools, frameworks, best practices

APPSTUDIO and design methods that enable rapid design, development & sustenance of highly configurable GRC applications on MetricStream platform. Infocenter is an EGRCP module that enables a user to customize a screen Infocenter to see parts of the MetricStream application that is of most interest to the user. Infoport Dashboard Infoport is a part/section in Infocenter which deals with a particular task Dashboard is an EGRCP module that enables you to view the results of a database query in a graphical format.

7. Entity Relationship Diagrams

Basic Notations Shape Notation Entity Description An entity is an object or concept about which you want to store information. A weak entity is an entity that must defined by a foreign key relationship Weak Entity with another entity as it cannot be uniquely identified by its own attributes alone. Attribute Represents the characteristic properties belonging to the entity. A key attribute is the unique, Attribute Key Attribute distinguishing characteristic of the entity. A multivalued attribute can have more Multi-valued Attribute than one value. Relationships illustrate how two Relationship entities share information.

Data Flow Diagrams

DFDs are used to convey how data or information flows through the system and how data is transformed in the process. They are able to provide both high-level system-overview with boundaries and connection to other systems as well as detailed representation of system components. They are easy to understand for both technical, non-technical audiences. Basic notations Shape Notation Description Sources and destinations (sink) define Source/ Destination the systems boundaries. It is represented by a square. A process, or transform, identifies an Process activity that changes, moves, or otherwise transforms data. It is shown as a round-cornered rectangle/ oval Represents data at rest and implies that the data are held (for some logical
Data Store

reason) between processes. It is shown as an open-ended, horizontal rectangle

Flow of Activity or Control

A data flow represents data in motion. It is depicted with an arrow.

Level 0 DFD of the Tollway Itemization System (Head Office)

Level 1 DFD

Level 2 DFD: Tag Purchase

Level 2 DFD: Tag Dispatch

Level 2 DFD: Vendor Addition

Level 2 DFD: Tag Intake

Level 2 DFD: Reports and Dashboards