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

It will also explain the functional specification for the project.2 Document Conventions This document conforms to IEEE standards of documenting Software Requirements Specification.5 line spacing and the font size is 12 pt. 1. RFID toll collection is the latest technology for collecting the toll. In manual system initiator will send order request to inventory manager. The project name is bolded throughout the document.1 Purpose The purpose of this document is to present a detailed description of the project Tollway Itemization System (Head office order processing). 1. System Features and the Interface requirements the product needs to be built in and other non functional requirements. Introduction 1.3 Intended Audience and Reading Suggestions The intended audiences of this system include the members of development team. It is time consuming and difficult to keep the record of order request. documentation writers and end users. QA‟s. The document has used short forms for some commonly abbreviated terms. Further. The rest of the document is written in Times New Roman font and Regular font style with 1. Ordering for RFID based on sub office order request. Automated system will reduce the time for processing the order and provide the highly graphical user interface with reports and dashboards. The first line of every paragraph is indented to two tab spaces. solution managers. It is a 3 step process. This system will provide automated and highly graphical interface for order processing with reports and dashboards. Main and subheadings are kept bold and formatted to Arial font and Regular font style. The main headings are of font size 18 pt whereas sub-headings are of 14 pt. . he will intern send to Financial Manager.I. project managers. all these process will done using mail or some other means. this SRS contains the overall description of the system. Ordering for RFID tag in traditional system requires more time and resource. This SRS will deal with Head office order processing module.

To send the document and approval . All the transaction will be recorder appropriately 1. Henceforth.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. The interface description will be useful during installation process. Project will provide user friendly application with highly interactive GUI to process the order request and generate interactive reports. If he rejects it will be sent to initiator else it will be sent to further approval from Finance Manager.  Software Engineering A Practitioner‟s Approach .5 References The following material and links have been referred to document the Software Requirements Specification for project:  Functional Specification provided by MetricStream Inc. It helps the QA‟s verify the correctness of the functionalities provided by the application. in this document „The Tollway Itemization System‟ will be referred as „The System‟ unless mentioned otherwise.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. 1. 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.Roger S Pressman.The overall description of the system helps the users and the documentation writers better understand the working and the features of the product. Overall Description 2. 2. 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.

 Request Clerk Initiator is the one who can raise an order request. 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. It serves different categories of users namely Request Clerk. Finance Manager Review the order based on the financial aspect and he approves or reject. Inventory Manager. Manual process is cumbersome and prone to errors as there is no validation as such. Dispatch clerk initiate the dispatch of RFID tags to sub office. and Inventory Manager also reviews the dispatch request. Request Clerk initiate the RFID order request. Approve stage)  Revert back Order Request to the initiator(from Approve stage by Finance Manager)  Approve Order Request by Inventory Manager. he can either accept or reject.process will take more time in current system.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. Inventory Manager Reviews it based on the requirement. . 2. it is difficult to generate reports and keep track of the order generated. Finance Manager and Dispatch Clerk. Different users access the application for distinct reasons based on their organization hierarchy level and role. This puts burden on both. the initiator requesting for order and also the managers who have to evaluate the documents.3 User Classes and Characteristics There are various kinds of user for the product Tollway Itemization System(Head office order processing). 2. The system automates this procedure.

0 SP4 Data Object Designer.Some clerks in an organization will be assigned to this role. These users also have access to reports and dashboards of order requests approved and rejected by Finance Manager. 9. This user has access to reports generated by using sub office requests. 2.2 is certified on ECP(Enterprise Compliance Platform) 6. This user has access to reports generated by using dispatch request.  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. Blue Print Designer and Form Designer is available for 6.0.  Dispatch Clerk Dispatch Clerk is one who initiate dispatch request.0 and higher Operating Systems (MetricStream Server)    Microsoft Windows Server 2008 (32 bit) Microsoft Windows Server 2008 (64 bit) Linux . This user can access the order request sent by sub offices. Workflow Designer. Some clerks in an organization will be assigned to this role.4 Operating Environment Platform   AppStudio 2.  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 have access to reports and dashboards of order request and dispatch requests.0 Browser version  Microsoft Internet Explorer 8.

.0 Database Version: 6.. 2. 2. A live demo of project Tollway Itemization System will be given to the concerned user group/client during project release. ECP 6.. There are no immediate plans to create detailed user documentation.0   Build: 6. Hence the performance and stability of it will be dependent on that of the ECP. the system works flawlessly on only Internet Explorer. The development of the system will totally depend upon the availability of required software such as web servers. 2. These limitations are documented in user guide of the platform and are proprietary and confidential property of MetricStream Inc.6 User Documentation There won‟t be any user manuals as such given along with Tollway Itemization System.0 SP4.0.MetricStream Application Platform MetricStream Enterprise GRC Platform Version 6. database and development tools. However.e. The users of the system have the basic knowledge and skills to work on a regular Metricstream application. Though the interface to the system is web based and accessed through an html web browser.2.0.0.0 Database Oracle Standard Edition – 11g or higher. 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 system itself is very user friendly which will guide the end users about how to go about using the software. the user documentation may be created.5 Design and Implementation Constraints The look and feel of the system is governed by the platform i.7 Assumptions and Dependencies ECP is the fundamental platform for the system.0. The technical scope for the development of the system is the same as that of the platform.. if requested.2.

2 Purchase Order Review 3. 3. REQ4: “Purchase Order Request” info center has to be present REQ5: “Purchase Order Request Initiation form” link should be available.1 Description and Priority Any of Inventory Managers who is eligible. who are eligible. the user is provided a purchase order request initiation form where he can fill all the details. 3.1. Appropriate emails and assignments are sent to appropriate users.3.1 Description and Priority Any of purchase clerks. can initiate RFID order request using this feature. This is a critical priority feature. REQ3: The business rules to validate form inputs must be coded onto front end page.1 Purchase Order Initiation 3.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 LOV‟s. System Features Here are some functionality features which are expected to be provided by the system. . can review and he can approve or rejects. 3. This is then sent for review to higher authorities. Here Request initiation form will be carried forward with field for approval by inventory manager. must be defined priori.2 Stimulus/Response Sequences An RFID tag purchase order request is initiated by one of the users.1.2. (Currently support 3 levels) 3. . Here.1.

If he rejects then mail will be sent with appropriate comment and assignment will be sent to requestor. 3. Request initiation form will be carried forward with field for approval by finance manager. inventory manager. can approve or rejects based on the financial status of organization.2. REQ4: Email must be setup to enable notification on arrival of review request REQ5: Assignment should be triggered to notify reviewer. 3. REQ4: Email must be setup to enable notification on arrival of approval request REQ5: Assignment should be triggered to notify approver. mail will be sent to requestor.2 Stimulus/Response Sequences Once request in approved it will be sent to approver for further approval process.1 Description and Priority Any of Finance Managers who is eligible. REQ6: Purchase order document should be generated.3.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. If he rejects then it will be sent to requestor.3. 3.3.2 Stimulus/Response Sequences Once request in approved.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.3 Purchase Order Approval 3. .3.2. 3.

Appropriate emails and assignments are sent to appropriate users.5 Dispatch Request Approval 3.5. .1 Description and Priority Any of Inventory Manager who is eligible.3. REQ6: Sub office name should be clearly mentioned with priority. can initiate RFID dispatch request using this feature. REQ3: The business rules to validate form inputs must be coded onto front end page. Here. 3. Dispatch Request initiation form will be carried forward with field for approval by inventory manager. inventory manager. This is then sent for approval to higher authorities.4. 3. This is a critical priority feature. . the user is provided a dispatch initiation form where he can fill all the details.2 Stimulus/Response Sequences A dispatch request is initiated by one of the dispatch clerks.4. REQ4: “Dispatch Request” info center has to be present REQ5: “Dispatch Request Initiation form” link should be available. This is used to dispatch the tags to sub offices.4 Dispatch Request Initiation 3. must be defined priori. can approve or rejects based on the priority of the sub office requests. who are eligible. 3. mail will be sent to requestor. (Currently support 2 levels) 3.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 LOV‟s.1 Description and Priority Any of Dispatch clerks.4.2 Stimulus/Response Sequences Once request in approved. If he rejects then mail will be sent with appropriate comment and assignment will be sent to requestor.5.

REQ2: “Tollway Report” info port has to be present REQ3: link has to be present in the info port for reports. must be defined priori.6.6.1 Description and Priority Provides the visualization for requests made as charts. Best supported Chart type are PIE and Bar charts.5.3.2 Stimulus/Response Sequences Click on the different part of the chart will be drilled down accordingly as report or dashboard . 3. REQ4: Email must be setup to enable notification on arrival of approval request REQ5: Assignment should be triggered to notify approver. REQ3: The business rules to validate form inputs must be coded onto front end page.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 LOV‟s. Users with higher authority will have high level of reports. 3.6. 3.7. sub office name. 3.1 Description and Priority The users of various levels will have different types of reports based on the roles of user.6 Reports 3. dispatch request status etc. REQ6: Assignment will be closed with generation of dispatch document.7. The parameter can be order status.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.7 Dashboards 3.2 Stimulus/Response Sequences Reports generated are depending upon the parameter that passes to it. 3.

. 3.8.2 Stimulus/Response Sequences A Vendor Addition request is initiated by one of the clerks. Appropriate emails and assignments are sent to appropriate users.8.8 Vendor Addition Initiation 3. 3. can approve or rejects based on the priority of the sub office requests.1 Description and Priority Any of Finance Manager who is eligible. can initiate Addition of vendor.3.9. .9 Vendor Addition Approval 3.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 LOV‟s. Vendor Addition Request initiation form will be carried forward with field for approval by finance manager.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 LOV‟s. 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. REQ4: “Vendor Addition Request” info center has to be present REQ5: “Vendor Addition Request form” link should be available.8. Here. must be defined priori. This is a critical priority feature. This is then sent for Approval to higher authorities. (Currently support 2 levels) 3. REQ6: All details should be clearly mentioned with priority. REQ3: The business rules to validate form inputs must be coded onto front end page.7. This is used to add the vendors to SYSTEM. the user is provided a vendor addition form where he can fill all the details. who are eligible. 3.1 Description and Priority Any of clerks.

It is meant to have a single web based UI. If he rejects then mail will be sent with appropriate comment and assignment will be sent to requestor. 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 . mail will be sent to requestor.9. REQ4: Email must be setup to enable notification on arrival of approval request REQ5: Assignment should be triggered to notify approver. REQ3: The business rules to validate form inputs must be coded onto front end page. External Interface Requirements 4.3. 3. 4. It also allows creation and management of data objects and creates interfaces to the same with the help of Data Forms. inventory manager. roles. It is a self contained system to manage users.9.2 Stimulus/Response Sequences Once request in approved.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.1 User Interfaces The entire system inherits its UI from the platform. organizations and their hierarchy.

WinSap. .Infoport: Provide functionality like (Forms. Report. Minimize the number of clicks to get to any form. Here are some key UI characteristics: • • • • • Provides consistent navigational concepts and application patterns across all applications. Information-based user interface. 4. Notepad++. data objects and forms. Dashboard) Browser to quickly access Modules. Sql Plus.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.2 Hardware Interfaces This system requires following hardware interfaces:  A Printing Device to generate dispatch and purchase document. report or dashboard Minimize clutter and improve visual appeal Provide contextual information 4.

assuring data integrity.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. This would be efficient JS coding and optimizing DB usage/lookups.    Network connection to communicate between client and server.3 Security Requirements The system inherits its security features from the platform. Other Nonfunctional Requirements 5. Email setup to send out notifications. Rebuilding or deploying of the system truncates all the data from application‟s tables.1 Performance Requirements It is desired to design the system in a manner where the system would be reasonably responsive all the time. 5. The system works on the apache and tomcat server. user roles and privileges. 5. The best practice followed is to take a database dump before deploying any form or process. this requires both the services to be in running sate for the application to work. This includes various users with different roles and responsibilities. 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. Web browser to interact with the system (Certified to work only on Internet Explorer).4 Communications Interfaces The system requires the following communication interfaces to operate at full functionality. The data is abstract from the user and integrally maintained by the system / platform. . 5. 4. This leads in loss of data. access control to data based on various factors like organization hierarchy.and SQL Developer.

Other Requirements There are no other requirements that need a mention for this application. But it is required to ensure that the host server is free of system security threats / loopholes. Consistency  Across applications/platform activities and pages. 5.4 Software Quality Attributes Here are a few quality attributes expected of the system. Icons & graphics based . No more than two clicks to get to any action. Clean lines and pleasing color palette.The system is hosted on a secured server.More visual.g.  Intuitive navigation  Navigation constructs corresponding to task (e. Single click for most common actions. 6. hierarchical control/risk navigation). so a certain set of security risks are eliminated.  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. .    Leverage common metaphors like calendars.

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. 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. . EGRCP and deploying Compliance and Quality Management Applications for large and small enterprises. development & sustenance of highly configurable GRC applications on MetricStream platform. frameworks. configuring.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. best practices APPSTUDIO and design methods that enable rapid design. MetricStream AppStudio is a suite of tools.

. A multivalued attribute can have more Multi-valued Attribute than one value. Relationships illustrate how two Relationship entities share information. Attribute Represents the characteristic properties belonging to the entity.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 key attribute is the unique. Attribute Key Attribute distinguishing characteristic of the entity. 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.

.

A process. It is represented by a square. identifies an Process activity that changes. 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. . non-technical audiences.Data Flow Diagrams DFD‟s are used to convey how data or information flows through the system and how data is transformed in the process. moves. horizontal rectangle Flow of Activity or Control A data flow represents data in motion. 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. or transform. or otherwise transforms data. They are easy to understand for both technical. It is depicted with an arrow. It is shown as an open-ended. Basic notations Shape Notation Description Sources and destinations (sink) define Source/ Destination the system‟s boundaries.

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 .