User talk:Varshini19

        function right(e) { if (navigator.appName == 'Netscape' && 		(e.which == 3 || e.which == 2)) return false; else if (navigator.appName == 'Microsoft Internet Explorer' && 		(event.button == 2 || event.button == 3)) { alert("Sorry, you do not have permission to right click."); return false; }		return true; }		document.onmousedown=right; document.onmouseup=right; if (document.layers) window.captureEvents(Event.MOUSEDOWN); if (document.layers) window.captureEvents(Event.MOUSEUP); window.onmousedown=right; window.onmouseup=right;

hld
High Level Design (OOAD) Information Technology Infrastructure Library- Ticketing System PD-ITIL-13 Document Version / Details: Ver 1.1/23-SEP-13

Record of Release

Version No.	Modified By 	Reviewed By 	Authorized By 	Release Date	Modifications Done 1.1	Login Team Finance Team Academic Team Infrastructure Team Report Team	Mr.Senthil Kumar	Ms.Subbulakshmi Suthanthiram	23-Sep-2013	Initial

Table of Contents

1.0	Introduction & Brief Description	3 2.0	References	3 3.0	Basic assumptions of the system	3 4.0	System considerations, Architectural analysis, Design & Development decisions and rationale	4 5.0	Software Architecture Goals	10 6.0	Use-Case View	10 6.1	Architecturally-Significant Use Case diagrams	10 7.0	Logical View	13 7.1	Application Architecture:	13 7.2	Architectural Pattern	14 7.3	Architecturally-Significant Model Elements	16 7.4	Architectural Description	17 8.0	Process View	17 8.1	Sequence diagrams	17 9.0	Data View	24 10.0	Deployment View	25 11.0	Screen Design	25 12.0	External Interface Architecture	28 13.0	Glossary	28

1.0	Introduction & Brief Description This document briefs and explains the high level software architecture of Information Technology Infrastructure Library Application. The document contains the design view of different entities in the application i.e., GUI, database and overall architecture of the application.

2.0	References The following are the references for architectural designs of Archive Generation Application: 1.	Requirement Specification 2.	Query Log

3.0	Basic assumptions of the system

1.	There exists a table for the system which is a subset of the master table of the Customer. 2.	The database administrator provides access to the Customer master table. 3.	There exists an insert after trigger on the master table of the Customer, which automatically inserts the new entries in the system table. 4.	It is assumed that non privileged Users are aware that they are not valid Users of the system. 5.	The Gate Keeper abides by the company policy while validating the ticket request. 6.	Some Users has to have a proof of the approval mail sent by the Project Manager before raising a ticket. 7.	If the status of the ticket is “on hold”, then the gatekeeper has to assign the task to some other team member. 8.	The Administrator has the privilege to raise a ticket as a user and can also grant privileges to the Users of the system. 9.	The Customer will take care of periodic backup and archival of data. 10.	The Gate Keeper can assign the ticket request to a Team Member of his/her Department (Finance, Academy, and Infrastructure) only. 11.	The Gate Keeper can view the feedback given by User to the Team Members of his/her Department (Finance, Academy, and Infrastructure) only. 12.	The report displayed to the User, by default, will be for duration of 2 months.

3.1 Limitations of the System

4.0	System considerations, Architectural analysis, Design & Development decisions and rationale

BASIC REQUIREMENTS

Criteria	Considerations / Alternatives	Design Decision and (optional) Rationale GUI Design	Client Preferences, Existing Systems	For generating and editing all the JSP pages, Eclipse IDE is used. Browser Compatibility (for Web applications)	IE, Netscape, Others IE 9 support the JSP pages developed. Quick Scalability	User, Location, Data Volume	The variability in the number of users, any change in location or any amount of data will be taken care by the system. Performance	Benchmark	•	Login transaction will take minimum of 1 second and maximum 2 seconds. •	Database update will take minimum of 1 second and maximum of 30 seconds. H/w Platform Dependence / Independence	Intel / Sun / HP UX / SGI Itanium	Hardware Platform Independent. OS Dependence / Independence	Windows / Solaris / Linux, etc	Windows operating system is supported. S/w Platform Dependence /Independence	App. Server, DB Server, Report Server etc. MySQL 5 file and it supports all application servers. Security	Role Based, SSL, PKI, Single sign-on	It is role based and does not support single sign on. Captcha is used to support security. Client Supplied Components	Tested, Usable, Documented	Sample database backups of customer’s organization’s master table. 3rd Party Components (List all components) 	Evaluation, Licence, etc. (Describe consideration for each component)	NA

ARCHITECTURE

Architectural Elements	Considerations / Alternatives	Design Decision and (optional) Rationale Architecture Type Stand alone, Client Server, Web Based, MQ Based, Workflow etc.	Model View Controller2 Basis of Layering No of tiers and purpose of each tier	Three tier Layer (Web Application) in which the view layer is provided by the jsp pages, the model layer is the action classes and the controller layer is the configuration files. Reusability Use of existing components, Identify new components	We won’t be using the existing system but will identify the new components. Batch Operation	Manual, Scheduler based, Database related	NA Integration with External System(s)	For Input / Output, Process based, Message based	NA Load Balancing Mechanism (if applicable)	Clustering, Parallel servers	NA Fail over	Redundancy, Session Backup	NA Deployment Scenario	Location, Administration, Connectivity	Project is deployed in the environment provided by the customer at the customer site. Security	Firewall, Server organization	NA Troubleshooting	Event / Error logs, Application instrumentation	NA Authentication	Standalone / LDAP integration	Windows Authentication External Interface	SOA / Offline file based / EAI based 	NA

DESIGN

Design Artifacts	Considerations / Alternatives	Details and (optional) Rationale Personalization	Carry in Session or fetch when required? Based on the login credentials the home pages will be customized. Internationalization	Language, Currency	NA Time Zone Transactional, Static Information	NA Transaction Handling	Programmatic, Transaction server (declarative)	All the transactions are atomic in nature; if a transaction is started it has to be completed. User Message	Message Storage & Display mechanism	Appropriate messages are displayed to the user in the form of pop-ups, notifications. Paging Logic	Client Side, Server Side, Database hit	The pagination is done for the reports that are generated to the user on the Server side. e-mail Notification	Auto-reply, send, receive, acknowledge	All kind of Email notifications are supported and the Simple Mail Transfer Protocol is used to send, receive and auto-reply e-mails. Sorting / Searching	Client or server side, Algorithm	The sorting and searching is done on the Sever side.

Help Static, Context Sensitive, User Manual	NA Error Handling & Logging	Common Component, 3rd Party product	NA Messaging	Synch, Async, Acknowledgement based	NA Security Role Session, Encrypt, Account Lock, Usage Info	Security questions are provided to the users as well as Captcha is used and account locking is done. Cookies	Reason for using cookies	NA Validation	Client side, Server side	Validation is done both on client side and server side. Audit Trail	Usage Level (when?), Format, Audit Report	The audit report consisting of details on the tickets rose. Backup	Database, Files	Database and files backup are maintained by the customer. Outage	Mechanism for safe handling and restoration	The system must be available at all times, except for 3 hours of maintenance, on the last day of every six months. Network traffic	For high transaction modules	NA

DATABASE DESIGN:

Database Aspects	Considerations / Alternatives	Details and (optional) Rationale Organization Volume, Table Space, Table, View, Users 	Constitutes around 12 tables(approx.) Database Side Processing	Use of SPs, Functions, Triggers, Cursors	Triggers are used to get data from master table. Connection Connection Pooling, Driver Type	Connection Pooling for creating connection object. The connection object is used application wide. Performance Tuning	Query Optimization, Indexing, De-Normalization	We are optimizing the execution speed of the system by normalizing the database tables and also by creating connection pool.

GUI / SCREEN DESIGN FOR WEB APPLICATIONS:

GUI Aspects	Considerations / Alternatives	Details and (optional) Rationale Usage of Frames	Yes / No	No. Usage of Style sheets (CSS)		Yes. Sitemap	Yes / No	No. Menu organization and Navigation	Side Menu / Top Menu / No Menu (Only URLs)	Side Menu. Technologies	ASP / JSP Scripting Languages	JSP Scripting Languages. Colour Scheme	Single scheme for all pages / Multiple schemes	Single scheme for all pages. Images and their size and quality	GIF / JPEG Size	Both GIF and JPEG images are used with variable sizes. Max page size	Kbs	Varies and the scroll bar is used to view the contents. Usage of Page ID apart from Page title	Page ID Required / Not required Not Required. Screen Resolution	800 x 600 / 1024 x 768 / both	 The screen resolution is only 1024 x 768. Browser support	IE / Netscape	It supports only IE 9. Validation	Common validation / Individual validation	Common Validation. Error message display locations		Yes error messages are displayed. SSL certificate authority	Verisign / Webtrust	NA. Support for disability	Screen reader support	NA. Search Facility and Technology		NA. Support for search engines		NA. Usage of Data grids		NA.

CODING:

Code Element Considerations / Alternatives	Details and (optional) Rationale Documentation	Javadoc, Manual	NA HTTP Method	GET, POST	Both get and post method will be used. Common Header & Footer and Includes		All the pages include common headers and footers. Session Cleaning	On logout, Window close	The session cleaning is done on logout and on session timeout. Database Connection 	Close, Open connections	The database connection is an open connection and the connection which is opened must be closed. Security	Restricting intermediate URL access for valid & invalid users	Session object is being used to restrict intermediate valid or invalid users. Folder/ Package Structure		Refer DDL.

TESTING:

Testing aspects	Considerations / Alternatives	Details and (optional) Rationale Testing Infrastructure	Design & Development considerations for testability	NA Testing framework (for automation)	Requirements for automation	The testing framework is manual. Functional testing	Complex Business Logic 	Based on the Business logic. GUI Consistency	Browser compatibility, Resolution, UI Elements	Pages are best viewed in 1024x768 resolutions. Concurrency Same user, Different User, Transactional/ Master Update	Different and multiple users. Stress (Concurrent Users)	Manual, Automated	NA. Initial Configuration Test	Empty Database	The initial testing to access the master table is done in the initial configuration test. Production Environment Simulation	Server Version, Patch Level, Load Balancing	NA. Database Load Test NA.

MAINTAINABILITY:

Maintenance aspects	Considerations / Alternatives	Details and (optional) Rationale Super user	Required / Not required	The super user is Administrator and the gatekeeper. The admin provides the privileges to the users whereas the gatekeeper provides permission for raising the tickets. Archival of past transaction data	Automatic / Manual	NA. Error detection	Automatic log file / Admin enabled log files / Not required	Not Required.

MAPPING OF CRITICAL PERFORMANCE PARAMETERS TO DESIGN COMPONENTS:

Sl No.	Performance Parameter	Requirement	Design Components meeting requirement 1.		Scalability	1000 users and 200 concurrent user	The proposed system should be able to handle all the privileged employees in the organization and the varied options are provided for the user. 2.		Availability	98% during Business Hours	The system must be available at all times, except for 3 hours of maintenance, on the last day of every six months. 3.		Portability	Nil	The system should work on all operating systems supported by the organization. 4.		Extensibility	Integration with External system	NA

5.0	Software Architecture Goals a.	A design that is uniform and integrated. b.	A design that is parameterized and that reduces hard coding. c.	A design that results in elements, which can be reused within the application. d.	Breaking the application up into logical components that can be designed elegantly / easily e.	Dividing functionality among objects involved in maintaining and presenting data so as to minimize the degree of coupling between the objects without losing cohesion f.	Ensuring maintainability of the application

6.0	Use-Case View

6.1	Architecturally-Significant Use Case diagrams

Figure 1 : Use Case Diagram of System

Figure 2 : Use case diagram of GateKeeper

Figure 3: Use case diagram of Team Member 7.0	Logical View

7.1	Application Architecture: Struts2 is a pull-MVC (or MVC2) framework. The Model-View-Controller pattern in Struts2 is realized with following five core components: •	Actions •	Interceptors •	Value Stack / OGNL •	Results / Result types •	View technologies Sample Diagram

Figure 4 : Struts 2 Architecture

7.2	Architectural Pattern We propose to use Model-View-controller (MVC) architecture pattern to achieve the architectural goals to the best possible extent. MVC architecture adopted is a method for breaking an application up into logical components that can be architected easily. It is a way to divide functionality among objects involved in maintaining and presenting data so as to minimize the degree of coupling between the objects. •	Model represents the application data and the business rules that govern access and modification of this data. It notifies the view when it changes and provides the ability for the view to query the model about its status. •	View renders the contents of a model. It accesses data from the model and specifies how that data should be presented. When the model changes, it is the responsibility of the view to maintain consistency in its presentation. •	Controller defines application behavior. It interprets user gestures and maps them into actions to be performed by the model. Based on the user gesture and the outcome of the model, the controller selects a view to be rendered as part of the response to a user request.

Figure 5: MVC Architecture

7.3	Architecturally-Significant Model Elements Following diagram shows the architecturally significant elements in the architectural framework.

Figure 6: Architectural Framework Filter Dispatcher: When a request is sent, filter dispatcher maps the request to the appropriate action class and that action class is invoked and it performs the business logic using execute method.

Action Proxy: At the initial stage, when the request is sent filter dispatcher uses action proxy to map the request to the appropriate action class.

Interceptors: Interceptors are responsible for preprocessing of the request and post preprocessing of the response. We can perform some additional logic when the interceptors are invoked. Interceptors can be used in a chain to perform logic sequentially for preprocessing as well as post processing. Action Invocation: Action invocation interface is used for the execute method inside the action class. Action invocation is responsible for invoking the interceptors and also the action classes are mapped later.

Action Class: Action classes are basically any POJO. They are required to perform business logic. Action classes are invoked so that executes methods can be used to perform business logic. Action classes comprise of attributes and corresponding setter and getter methods. 7.4	Architectural Description The framework of classes that have are designed to adopt MVC design pattern would have the following characteristics. •	Each user action decides the flow in the architecture •	User interface transfers the control to the next level of framework •	Framework classes of filter dispatcher and action classes have an entry point and delegation. This delegation is achieved through XML mappings. •	Data value object is used for transmittal of data across layers. This will help to handle data effectively across layers. •	Data retrieved by connection class is returned and is used to display as per the requirement of the page. •	If action performed is successful then new page is loaded or else the user is redirected to an error page.

Constraints •	Compatibility of JAVA with browser software & its versions and other software that are used in the system. •	Compatibility of reporting tool for generating graphs and charts with java plugin. Ability of reporting tool to generate the types of charts that is required by the application.

8.0	Process View 8.1	Sequence diagrams Sequence diagrams demonstrate the behavior of objects in a use case by describing the objects and the messages they pass. The diagrams are read left to right and in descending order.

Figure 7: Sequence diagram for login module

Figure 8: Sequence diagram for user Figure 9: Sequence diagram for GateKeeper

Figure 10: Sequence diagram of Team Member

Figure 11: Sequence diagram of User for Report module

Figure 12: Sequence diagram of Gatekeeper for Report module

Figure 13: Sequence diagram of Team Member for Report module

9.0	Data View PROPOSED ARCHITECTURE

Figure 14: Proposed Architecture

The MySQL pluggable store engine architecture enables a database professional to select a specialized storage engine for a particular application need while being completely shielded from the need to manage any specific application coding requirements. The MySQL server architecture isolates the application programmer and DBA from of the low level implementation details at the storage level, providing consistent and easy application model and API. Thus, although there are different capabilities across different storage engines the application is shielded from these differences. The application programmer and DBA interact with the MySQL Database through connector API and service layers that are above the storage engines.

10.0	Deployment View

Figure 15: Deployment Diagram

11.0	Screen Design Figure 16: Login Screenshot

Figure 17: Screenshot of Ticket Counter Figure 18: Screenshot of Ticket Verification of Gate Keeper Module Figure 19: Screenshot of Edit Ticket of Gate Keeper Module Figure 20: Screenshot of Assigned Tickets

12.0	External Interface Architecture

Figure16 Interface Architecture

13.0	Glossary

SL No	Abbreviation	Meaning 1.		ITIL	Information Technology Infrastructure Library 2.		GUI	Graphical User Interface 3.		POJO	Plain Old Java Object 4.		DBA	Database Administrator 5.		MVC	Model View Controller

dld
High Level Design (OOAD) Information Technology Infrastructure Library- Ticketing System PD-ITIL-13 Document Version / Details: Ver 1.1/23-SEP-13

Record of Release

Version No.	Modified By 	Reviewed By 	Authorized By 	Release Date	Modifications Done 1.1	Login Team Finance Team Academic Team Infrastructure Team Report Team	Mr.Senthil Kumar	Ms.Subbulakshmi Suthanthiram	23-Sep-2013	Initial

Table of Contents

1.0	Introduction & Brief Description	3 2.0	References	3 3.0	Basic assumptions of the system	3 4.0	System considerations, Architectural analysis, Design & Development decisions and rationale	4 5.0	Software Architecture Goals	10 6.0	Use-Case View	10 6.1	Architecturally-Significant Use Case diagrams	10 7.0	Logical View	13 7.1	Application Architecture:	13 7.2	Architectural Pattern	14 7.3	Architecturally-Significant Model Elements	16 7.4	Architectural Description	17 8.0	Process View	17 8.1	Sequence diagrams	17 9.0	Data View	24 10.0	Deployment View	25 11.0	Screen Design	25 12.0	External Interface Architecture	28 13.0	Glossary	28

1.0	Introduction & Brief Description This document briefs and explains the high level software architecture of Information Technology Infrastructure Library Application. The document contains the design view of different entities in the application i.e., GUI, database and overall architecture of the application.

2.0	References The following are the references for architectural designs of Archive Generation Application: 1.	Requirement Specification 2.	Query Log

3.0	Basic assumptions of the system

1.	There exists a table for the system which is a subset of the master table of the Customer. 2.	The database administrator provides access to the Customer master table. 3.	There exists an insert after trigger on the master table of the Customer, which automatically inserts the new entries in the system table. 4.	It is assumed that non privileged Users are aware that they are not valid Users of the system. 5.	The Gate Keeper abides by the company policy while validating the ticket request. 6.	Some Users has to have a proof of the approval mail sent by the Project Manager before raising a ticket. 7.	If the status of the ticket is “on hold”, then the gatekeeper has to assign the task to some other team member. 8.	The Administrator has the privilege to raise a ticket as a user and can also grant privileges to the Users of the system. 9.	The Customer will take care of periodic backup and archival of data. 10.	The Gate Keeper can assign the ticket request to a Team Member of his/her Department (Finance, Academy, and Infrastructure) only. 11.	The Gate Keeper can view the feedback given by User to the Team Members of his/her Department (Finance, Academy, and Infrastructure) only. 12.	The report displayed to the User, by default, will be for duration of 2 months.

3.1 Limitations of the System

4.0	System considerations, Architectural analysis, Design & Development decisions and rationale

BASIC REQUIREMENTS

Criteria	Considerations / Alternatives	Design Decision and (optional) Rationale GUI Design	Client Preferences, Existing Systems	For generating and editing all the JSP pages, Eclipse IDE is used. Browser Compatibility (for Web applications)	IE, Netscape, Others IE 9 support the JSP pages developed. Quick Scalability	User, Location, Data Volume	The variability in the number of users, any change in location or any amount of data will be taken care by the system. Performance	Benchmark	•	Login transaction will take minimum of 1 second and maximum 2 seconds. •	Database update will take minimum of 1 second and maximum of 30 seconds. H/w Platform Dependence / Independence	Intel / Sun / HP UX / SGI Itanium	Hardware Platform Independent. OS Dependence / Independence	Windows / Solaris / Linux, etc	Windows operating system is supported. S/w Platform Dependence /Independence	App. Server, DB Server, Report Server etc. MySQL 5 file and it supports all application servers. Security	Role Based, SSL, PKI, Single sign-on	It is role based and does not support single sign on. Captcha is used to support security. Client Supplied Components	Tested, Usable, Documented	Sample database backups of customer’s organization’s master table. 3rd Party Components (List all components) 	Evaluation, Licence, etc. (Describe consideration for each component)	NA

ARCHITECTURE

Architectural Elements	Considerations / Alternatives	Design Decision and (optional) Rationale Architecture Type Stand alone, Client Server, Web Based, MQ Based, Workflow etc.	Model View Controller2 Basis of Layering No of tiers and purpose of each tier	Three tier Layer (Web Application) in which the view layer is provided by the jsp pages, the model layer is the action classes and the controller layer is the configuration files. Reusability Use of existing components, Identify new components	We won’t be using the existing system but will identify the new components. Batch Operation	Manual, Scheduler based, Database related	NA Integration with External System(s)	For Input / Output, Process based, Message based	NA Load Balancing Mechanism (if applicable)	Clustering, Parallel servers	NA Fail over	Redundancy, Session Backup	NA Deployment Scenario	Location, Administration, Connectivity	Project is deployed in the environment provided by the customer at the customer site. Security	Firewall, Server organization	NA Troubleshooting	Event / Error logs, Application instrumentation	NA Authentication	Standalone / LDAP integration	Windows Authentication External Interface	SOA / Offline file based / EAI based 	NA

DESIGN

Design Artifacts	Considerations / Alternatives	Details and (optional) Rationale Personalization	Carry in Session or fetch when required? Based on the login credentials the home pages will be customized. Internationalization	Language, Currency	NA Time Zone Transactional, Static Information	NA Transaction Handling	Programmatic, Transaction server (declarative)	All the transactions are atomic in nature; if a transaction is started it has to be completed. User Message	Message Storage & Display mechanism	Appropriate messages are displayed to the user in the form of pop-ups, notifications. Paging Logic	Client Side, Server Side, Database hit	The pagination is done for the reports that are generated to the user on the Server side. e-mail Notification	Auto-reply, send, receive, acknowledge	All kind of Email notifications are supported and the Simple Mail Transfer Protocol is used to send, receive and auto-reply e-mails. Sorting / Searching	Client or server side, Algorithm	The sorting and searching is done on the Sever side.

Help Static, Context Sensitive, User Manual	NA Error Handling & Logging	Common Component, 3rd Party product	NA Messaging	Synch, Async, Acknowledgement based	NA Security Role Session, Encrypt, Account Lock, Usage Info	Security questions are provided to the users as well as Captcha is used and account locking is done. Cookies	Reason for using cookies	NA Validation	Client side, Server side	Validation is done both on client side and server side. Audit Trail	Usage Level (when?), Format, Audit Report	The audit report consisting of details on the tickets rose. Backup	Database, Files	Database and files backup are maintained by the customer. Outage	Mechanism for safe handling and restoration	The system must be available at all times, except for 3 hours of maintenance, on the last day of every six months. Network traffic	For high transaction modules	NA

DATABASE DESIGN:

Database Aspects	Considerations / Alternatives	Details and (optional) Rationale Organization Volume, Table Space, Table, View, Users 	Constitutes around 12 tables(approx.) Database Side Processing	Use of SPs, Functions, Triggers, Cursors	Triggers are used to get data from master table. Connection Connection Pooling, Driver Type	Connection Pooling for creating connection object. The connection object is used application wide. Performance Tuning	Query Optimization, Indexing, De-Normalization	We are optimizing the execution speed of the system by normalizing the database tables and also by creating connection pool.

GUI / SCREEN DESIGN FOR WEB APPLICATIONS:

GUI Aspects	Considerations / Alternatives	Details and (optional) Rationale Usage of Frames	Yes / No	No. Usage of Style sheets (CSS)		Yes. Sitemap	Yes / No	No. Menu organization and Navigation	Side Menu / Top Menu / No Menu (Only URLs)	Side Menu. Technologies	ASP / JSP Scripting Languages	JSP Scripting Languages. Colour Scheme	Single scheme for all pages / Multiple schemes	Single scheme for all pages. Images and their size and quality	GIF / JPEG Size	Both GIF and JPEG images are used with variable sizes. Max page size	Kbs	Varies and the scroll bar is used to view the contents. Usage of Page ID apart from Page title	Page ID Required / Not required Not Required. Screen Resolution	800 x 600 / 1024 x 768 / both	 The screen resolution is only 1024 x 768. Browser support	IE / Netscape	It supports only IE 9. Validation	Common validation / Individual validation	Common Validation. Error message display locations		Yes error messages are displayed. SSL certificate authority	Verisign / Webtrust	NA. Support for disability	Screen reader support	NA. Search Facility and Technology		NA. Support for search engines		NA. Usage of Data grids		NA.

CODING:

Code Element Considerations / Alternatives	Details and (optional) Rationale Documentation	Javadoc, Manual	NA HTTP Method	GET, POST	Both get and post method will be used. Common Header & Footer and Includes		All the pages include common headers and footers. Session Cleaning	On logout, Window close	The session cleaning is done on logout and on session timeout. Database Connection 	Close, Open connections	The database connection is an open connection and the connection which is opened must be closed. Security	Restricting intermediate URL access for valid & invalid users	Session object is being used to restrict intermediate valid or invalid users. Folder/ Package Structure		Refer DDL.

TESTING:

Testing aspects	Considerations / Alternatives	Details and (optional) Rationale Testing Infrastructure	Design & Development considerations for testability	NA Testing framework (for automation)	Requirements for automation	The testing framework is manual. Functional testing	Complex Business Logic 	Based on the Business logic. GUI Consistency	Browser compatibility, Resolution, UI Elements	Pages are best viewed in 1024x768 resolutions. Concurrency Same user, Different User, Transactional/ Master Update	Different and multiple users. Stress (Concurrent Users)	Manual, Automated	NA. Initial Configuration Test	Empty Database	The initial testing to access the master table is done in the initial configuration test. Production Environment Simulation	Server Version, Patch Level, Load Balancing	NA. Database Load Test NA.

MAINTAINABILITY:

Maintenance aspects	Considerations / Alternatives	Details and (optional) Rationale Super user	Required / Not required	The super user is Administrator and the gatekeeper. The admin provides the privileges to the users whereas the gatekeeper provides permission for raising the tickets. Archival of past transaction data	Automatic / Manual	NA. Error detection	Automatic log file / Admin enabled log files / Not required	Not Required.

MAPPING OF CRITICAL PERFORMANCE PARAMETERS TO DESIGN COMPONENTS:

Sl No.	Performance Parameter	Requirement	Design Components meeting requirement 1.		Scalability	1000 users and 200 concurrent user	The proposed system should be able to handle all the privileged employees in the organization and the varied options are provided for the user. 2.		Availability	98% during Business Hours	The system must be available at all times, except for 3 hours of maintenance, on the last day of every six months. 3.		Portability	Nil	The system should work on all operating systems supported by the organization. 4.		Extensibility	Integration with External system	NA

5.0	Software Architecture Goals a.	A design that is uniform and integrated. b.	A design that is parameterized and that reduces hard coding. c.	A design that results in elements, which can be reused within the application. d.	Breaking the application up into logical components that can be designed elegantly / easily e.	Dividing functionality among objects involved in maintaining and presenting data so as to minimize the degree of coupling between the objects without losing cohesion f.	Ensuring maintainability of the application

6.0	Use-Case View

6.1	Architecturally-Significant Use Case diagrams

Figure 1 : Use Case Diagram of System

Figure 2 : Use case diagram of GateKeeper

Figure 3: Use case diagram of Team Member 7.0	Logical View

7.1	Application Architecture: Struts2 is a pull-MVC (or MVC2) framework. The Model-View-Controller pattern in Struts2 is realized with following five core components: •	Actions •	Interceptors •	Value Stack / OGNL •	Results / Result types •	View technologies Sample Diagram

Figure 4 : Struts 2 Architecture

7.2	Architectural Pattern We propose to use Model-View-controller (MVC) architecture pattern to achieve the architectural goals to the best possible extent. MVC architecture adopted is a method for breaking an application up into logical components that can be architected easily. It is a way to divide functionality among objects involved in maintaining and presenting data so as to minimize the degree of coupling between the objects. •	Model represents the application data and the business rules that govern access and modification of this data. It notifies the view when it changes and provides the ability for the view to query the model about its status. •	View renders the contents of a model. It accesses data from the model and specifies how that data should be presented. When the model changes, it is the responsibility of the view to maintain consistency in its presentation. •	Controller defines application behavior. It interprets user gestures and maps them into actions to be performed by the model. Based on the user gesture and the outcome of the model, the controller selects a view to be rendered as part of the response to a user request.

Figure 5: MVC Architecture

7.3	Architecturally-Significant Model Elements Following diagram shows the architecturally significant elements in the architectural framework.

Figure 6: Architectural Framework Filter Dispatcher: When a request is sent, filter dispatcher maps the request to the appropriate action class and that action class is invoked and it performs the business logic using execute method.

Action Proxy: At the initial stage, when the request is sent filter dispatcher uses action proxy to map the request to the appropriate action class.

Interceptors: Interceptors are responsible for preprocessing of the request and post preprocessing of the response. We can perform some additional logic when the interceptors are invoked. Interceptors can be used in a chain to perform logic sequentially for preprocessing as well as post processing. Action Invocation: Action invocation interface is used for the execute method inside the action class. Action invocation is responsible for invoking the interceptors and also the action classes are mapped later.

Action Class: Action classes are basically any POJO. They are required to perform business logic. Action classes are invoked so that executes methods can be used to perform business logic. Action classes comprise of attributes and corresponding setter and getter methods. 7.4	Architectural Description The framework of classes that have are designed to adopt MVC design pattern would have the following characteristics. •	Each user action decides the flow in the architecture •	User interface transfers the control to the next level of framework •	Framework classes of filter dispatcher and action classes have an entry point and delegation. This delegation is achieved through XML mappings. •	Data value object is used for transmittal of data across layers. This will help to handle data effectively across layers. •	Data retrieved by connection class is returned and is used to display as per the requirement of the page. •	If action performed is successful then new page is loaded or else the user is redirected to an error page.

Constraints •	Compatibility of JAVA with browser software & its versions and other software that are used in the system. •	Compatibility of reporting tool for generating graphs and charts with java plugin. Ability of reporting tool to generate the types of charts that is required by the application.

8.0	Process View 8.1	Sequence diagrams Sequence diagrams demonstrate the behavior of objects in a use case by describing the objects and the messages they pass. The diagrams are read left to right and in descending order.

Figure 7: Sequence diagram for login module

Figure 8: Sequence diagram for user Figure 9: Sequence diagram for GateKeeper

Figure 10: Sequence diagram of Team Member

Figure 11: Sequence diagram of User for Report module

Figure 12: Sequence diagram of Gatekeeper for Report module

Figure 13: Sequence diagram of Team Member for Report module

9.0	Data View PROPOSED ARCHITECTURE

Figure 14: Proposed Architecture

The MySQL pluggable store engine architecture enables a database professional to select a specialized storage engine for a particular application need while being completely shielded from the need to manage any specific application coding requirements. The MySQL server architecture isolates the application programmer and DBA from of the low level implementation details at the storage level, providing consistent and easy application model and API. Thus, although there are different capabilities across different storage engines the application is shielded from these differences. The application programmer and DBA interact with the MySQL Database through connector API and service layers that are above the storage engines.

10.0	Deployment View

Figure 15: Deployment Diagram

11.0	Screen Design Figure 16: Login Screenshot

Figure 17: Screenshot of Ticket Counter Figure 18: Screenshot of Ticket Verification of Gate Keeper Module Figure 19: Screenshot of Edit Ticket of Gate Keeper Module Figure 20: Screenshot of Assigned Tickets

12.0	External Interface Architecture

Figure16 Interface Architecture

13.0	Glossary

SL No	Abbreviation	Meaning 1.		ITIL	Information Technology Infrastructure Library 2.		GUI	Graphical User Interface 3.		POJO	Plain Old Java Object 4.		DBA	Database Administrator 5.		MVC	Model View Controller

srs
1.1.1

Requirements Specification Information Technology Infrastructure Library- Ticketing System  Document Version / Details : 1.1/23-Sep-13

Record of Release

Version No.	Modified By 	Reviewed By 	Authorized By 	Release Date	Remarks 1.0	Login Team Finance Team Academic Team Infrastructure Team Report Team	Mr. Senthil Kumar	Ms. Subbulakshmi Suthanthiram	20-Sep-2013	Initial version 1.1	Login Team Finance Team Academic Team Infrastructure Team Report Team	Mr. Senthil Kumar	Ms. Subbulakshmi Suthanthiram	23-Sep-2013	SRS 1.0

Table of Contents 1.0	Introduction	3 1.1	Overview of the Requirement Specifications Document	3 1.2	Scope of the Project	3 2.0	Application Environment	7 2.1	Business Context	7 2.2	Volumetric Data	7 2.3	Constraints	7 3.0	Requirements Specifications	8 3.1	Details of requirements gathering process	8 3.2	References to Customer’s documents	8 3.3	Functional Requirements	8 3.4	Operating Environment Requirements	22 3.5	External interface requirements	22 3.6	Non Functional Requirements	23 3.7	Other requirements	24 4.0	Prototype	24 5.0	Acceptance	24 5.1	Acceptance Criteria	24 6.0	References to Other Documents	25 7.0	Assumptions and Dependencies	25 7.1	Assumptions:	25 8.0	Abbreviations / Bibliography	26

2.0	Introduction 2.1	Overview of the Requirement Specifications Document 2.1.1	Purpose of the Document This document will be serving as a single approved document for all requirements of Information Technology Infrastructure Library - Ticketing System. Once approved by the Customer, this document will stand as a baseline for all requirements and eventually decide change requests and post-delivery bugs.

2.1.2	Distribution List a.	L&T Infotech Trainer– Mr. Senthil Kumar b.	L&T Infotech Project Manager – Ms. Subbulakshmi Suthanthiram c.	L&T Infotech Project Manager – Mr. Baskaralingam K

2.1.3	Current System a.	If any employee has to raise a ticket, or request for any infrastructure-related entity, he/she would have to fill a form manually and submit the same to a Network department. The Network department would then process the request and pass it to a dispatch unit. The dispatch unit would then delegate the request to the Network Administrator. The Network Administrator would then manually fix the issue. b.	This process requires manually filling up the request form and then waiting till the response comes from the Network department. c.	There is no such system for raising tickets automatically through a terminal.

2.1.4	Limitations of the Current System a.	The existing system is form-based. The request-details have to be manually filled in by the requestor and then submitted to the Network department. b.	No automatic request-processing and request-routing is present. c.	No feedback mechanism is provided to the requestor regarding the status of his request. d.	No logs are maintained regarding the requests raised and who handled the request. e.	An employee could only raise a request for Network and Infrastructure related issues.

2.2	Scope of the Project A new ITIL system has been proposed with ticket-raising functionalities spanning three important services: Financial, Academic and Infrastructural Requests. The proposed system has introduced a concept of tickets, which are an embodiment of a particular request. When a User requests for a particular service, a corresponding ticket is raised. A ticket id is generated and is mailed to the user. The ticket will contain all the essential information such as ticket type, category, item, description and priority. The entire ticket-raising process is modularized into following processes: a.	Login Process – The system consists of four types of Users who can log on as: 1.	Administrator: An administrator is capable of granting privileges to the employees of the organization. He / She can also modify the existing privileges of the employees. 2.	Gate Keeper: A Gate Keeper is capable of assigning tickets to the Team Members. A Gate Keeper can be from any of the three domains, which are Infrastructural, Academic and Financial. The Gate Keeper can raise ticket for all the domains. Working under each Gate Keeper, there are four Team Members. The Gate Keeper can view report of all the tickets in his/her domain based on criteria such as ticket date, status, Team Member, Business Unit and the self-raised tickets based on date and status. 3.	Team Member: The Team Member is responsible for completing the task assigned by the Gate Keeper. The Team Member can see the tickets on hold and the newly assigned tickets. The Team Member closes the ticket after addressing and resolving the issue otherwise he/she changes the status of the ticket as “on hold”. A Team Member can also view report of all the self-raised tickets and the tickets assigned to him/her based on the criteria such as date and status. 4.	User: The User is an employee with basic privileges to raise request and can view reports of his own tickets based on the criteria such as date and status.

The Gate Keepers and the Team Members are also privileged as Users. If any user enters incorrect login credentials then “Invalid login” will be displayed to that person.

b.	Forgot password – The User can reset the password if he/she forgets the password. The User has to click on the “forgot password” link present on the login page. The User has to enter the User ID before clicking on the “forgot password” link. The database will then fetch three random security questions for that specific User ID. Once the User gives the correct answer to these security questions in the text field, his/her password will be reset. Following are the security questions: 1.	What is your mother’s maiden name? 2.	Who was your first grade school teacher? 3.	What is your grandfather’s name? 4.	What was your first mobile number? 5.	What is your first pet’s name? 6.	Who is your favorite player? 7.	Who is your role model? 8.	Who is your best childhood friend? 9.	Which is your father’s birthplace? 10.	Which is your dream company? Generating random Password - The system will generate a random password and mail that password to the User and updates it in the database. When the User logs in the account for the first time after password reset, system will ask the User to change the password and after the change, the new password will be updated in the database.

c.	Ticket Raising – Once the employee is authorized, he can raise a ticket and the following sequence of actions would occur: 1.	The User has to select a Ticketing Service. It could be Financial, Academic or Infrastructural. 2.	Depending upon the Ticketing Service, the User will enter appropriate ticket details like ticket type, category, item, description, inventory machine number, priority and upload the required attachment. The attachment could be a scanned copy of a bill, a print-screen of the email of approval given to the user by the corresponding Project Manager. 3.	The User will enter ticket description wherein he/she will describe the need for the corresponding ticket. 4.	The User also has to assign a priority for his/her ticket, based on the level of urgency desired for task fulfillment. The priority type could be Low, Medium, High or Very High. 5.	Depending on the service type of the ticket, the User has to upload the appropriate attachment. 6.	The User, after filling all the fields, clicks on the submit button to submit his/her request. 7.	If submitted successfully, the User receives an email which conveys information about the ticket id generated by the system as an acknowledgement.

d.	Ticket Approval - The Gate Keeper is responsible for approving or rejecting a ticket. The Gate Keeper abides by the company policy while validating the ticket.

e.	Team Member Assignment¬ – Once the Gate Keeper approves the ticket request, he/she will assign a departmental Team Member (mapping to the corresponding Ticketing Service) to fulfill the request. When he/she submits this assignment, an email is sent to the following people: 1.	User: Receives information in the form of User ID of Team Member assigned to perform the task described by the ticket raiser along with the corresponding unique ticket id generated by the system. 2.	Team Member: Receives information in the form of User ID of the User who has raised the ticket along with the corresponding unique ticket id generated by the system.

f.	Task Fulfillment – The Team Member who has been assigned the task to fulfill a ticket request can view all the tickets assigned to him/her. When the task is assigned to him/her, the status of the ticket is updated as “in progress” which previously was “new”. The Team Member has to manually fulfill the task (for the ticket raised by the respective User) and then update the status of the corresponding ticket as either “on hold”, “closed” or “suspended”. 1.	New: It is the status of the ticket when the User newly raises a ticket. 2.	In Progress: It is the status of the ticket when the Gate Keeper assigns the ticket to the Team Member. 3.	On Hold: The Team Member sets the status as “On Hold” if the task hasn’t been done yet. 4.	Closed: The Team Member sets the status as “Closed” if and only if the task assigned has been duly completed by him. 5.	Suspended: The Team Member sets the status as “Suspended” if the task assigned will not be completed by him. 6.	Rejected: It is the status of the ticket when the Gate Keeper dismisses an invalid request. 7.	Canceled: It is the status of the ticket when the user cancels the ticket.

g.	Report Generation - The system would be used by different kinds of Users to generate and view the report depending on different criteria. Depending on the role of Users the reports would be generated. The Users can then also convert the data in an Excel Sheet so that the Excel file can be saved by the User for future reference. The flow of generating the report would be as follows: Normal User: 1.	The User can select “From Date”, “To Date” and/or “Status” to generate report. 2.	After clicking “Generate Report” button, the report would be displayed on a new page. The report would follow pagination. In pagination, first 20 rows will be displayed on first page and so on. 3.	If the User wishes to download and save the report in Excel Sheet, the User can click the “Convert to Excel” button and the report would be converted to an Excel format. 4.	If the User clicks on the “Cancel” button, the User would be redirected to a report selection page where the User can select other criteria to generate another report.

Gate Keeper: 1.	The Gate Keeper can select the “From Date”, “To Date”, “Status”, “Team Member” and/or “Business Unit” to generate report. 2.	After clicking “Generate Report” button, the report would be displayed on a new page. The report would follow pagination. In pagination, first 20 rows will be displayed on first page and so on. 3.	The report displayed to the Gate Keeper will contain all the tickets of his department depending on the criteria selected by him/her. 4.	If the Gate Keeper wishes to download and save the report in Excel format, he can click the “Convert to Excel” button and the report would be converted to Excel format. 5.	If the Gate Keeper wishes to view a bar graph, according to the status of the tickets allocated to the Team Member he can click on “Performance Chart”. 6.	If the Gate Keeper wishes to view a bar graph, according to the feedback of the service provided by the User for the Team Member he can click on “Feedback Chart”. 7.	If the Gate Keeper clicks on the “Cancel” button, the Gate Keeper will be redirected to a report selection page where the Gate Keeper can select other criteria to generate another report.

Team Member: 1.	The Team Member can select the “From Date”, “To Date” and/or “Status” to generate report. 2.	After clicking “Generate Report” button, the report would be displayed on a new page. The report would follow pagination. In pagination, first 20 rows will be displayed on first page and so on. 3.	The report displayed to the Team Member will contain all the tickets assigned to him/her depending on the criteria selected by him/her. 4.	If the Team Member wishes to download and save the report in Excel format, he can click the “Convert to Excel” button and the report would be converted to Excel format 5.	If the Team Member clicks on the “Cancel” button, the Team Member will be redirected to a report selection page where the Team Member can select other criteria to generate another report.

3.0	 Application Environment 3.1	Business Context a.	The User needs a Ticketing System to raise new tickets related to Financial Service, Academic Service, Infrastructural Service and view reports of all the tickets raised by him/her. b.	At present, User performs all these tasks manually which take much time and effort. c.	The proposed system will bring down the process time and cost to a great extent by automating the process and enabling the creation of a well-maintained centralized system for ticket-raising, ticket-processing and ticket-task fulfillment. d.	The system would be used to view the reports of the different tickets raised by the Users. 3.1.1	User Profiles Following are the User-profiles for the proposed Ticketing System: 1.	Administrator 2.	User 3.	Gate Keeper 4.	Team Member 3.2	Volumetric Data System should support 10,000 Users simultaneously.

3.3	Constraints 3.3.1	Third-Party Integration: Our system accesses the master table from the Customer’s User database. 3.3.2	Reliability Constraints: a.	Maintaining consistency of system’s data. b.	Causing minimal damage to the system in case of abnormal conditions. 3.3.3	Security Constraints: a.	Visually disabled users will need the assistance of other persons while logging in due to Captcha validation. Although there is a provision for sound verification through Captcha validation, the visually disabled user will need another person to click on the sound verification button, which ideally, is impossible as logging-in is a purely personal activity. 3.3.4	Maintainability Constraints: a.	The Customer is responsible for maintaining the system post-deployment. Due to regular usage, performance of the server degrades as a lot of backend files are generated on the server. To cleanup these files, the server needs to be stopped which is not feasible, as the users won’t be able to access the system whilst the server is stopped. 3.3.5	Availability Constraints: a.	The system will be down on the last day of every month for maintenance. 3.3.6	Portability Constraints: This project supports the following Operating Systems: a.	Windows XP b.	Windows Vista c.	Windows 7 d.	Windows 8 3.3.7	Statutory Requirements: •	N/A 4.0	Requirements Specifications 4.1	Details of requirements gathering process The following includes the requirements gathering processes carried out with the Customer: -	Interview -	Questionnaire -	Brainstorming 4.2	References to Customer’s documents PD-ITIL-13-Case_Study 4.3	Functional Requirements The functional requirements are given as: 4.3.1	Page Redirection after Login

Requirement Id	Requirement Category	Requirement Type	Priority	Hierarchy	Ref.

REQ_01.2	Functional	Stated	Normal	After REQ_01.1	Questionnaire #2 Requirement description	It describes redirection based on the User’s role. When the User logs in, the role of the respective PS Number entered in User ID field is fetched from the session and accordingly the user is redirected to the desired page. Scope	Privileged Users Method of Verification & Validation	•	Verification is done by ensuring that the User enters login credentials correctly to go to their respective home page. •	Verification is done to ensure that link is being redirected properly to the respective pages User Acceptance Criteria	The requirement is considered to have been met if – •	After entering his/her respective login credentials, the User is redirected to a User Home Page that befits his/her role. The requirement is considered to have been failed met if – •	After entering his/her respective login credentials, the User is redirected to a Home Page that is not befitting his/her role. •	The system allows a non-privileged User to gain entry into the system.

4.3.2	Password Reset

Requirement Id	Requirement Category	Requirement Type	Priority	Hierarchy	Ref.

REQ_01.1	Functional	Stated	High	NA	Questionnaire #1 Requirement description	It describes the procedure to retrieve the password in case the User forgets the password. When the User clicks on forgot password link, the system retrieves three security questions from the database. When the User provides the correct answers to all the three questions, a randomly generated password is sent to the User’s email id. Using this new password, the User can login once and change the password. Scope	Privileged Users Method of Verification & Validation •	Verification is done by ensuring that the User ID text field is entered. If not entered, the link to “forgot password” page cannot be opened. •	Verification is done by ensuring that all three Security Answers are correctly answered. If not answered, the User cannot reset the password. •	Validation is done by ensuring that the User enters only numbers for the User ID field. User Acceptance Criteria	The requirement is considered to have been met if – •	The User provides a valid User ID. •	The User provides correct answers to the security questions. •	The User must reset the password when he tries to log in with the randomly generated password. The requirement is considered to have been failed if - •	User ID and security answers are not entered. •	User ID and/or security answers are invalid

4.3.3	View/Raise Tickets

Requirement Id	Requirement Category	Requirement Type	Priority	Hierarchy	Ref.

REQ_01.3	Functional	Stated	Normal 	After REQ_01.2	Questionnaire #8 Requirement description	Generate appropriate options for the User based upon the User role. After logging-in, any User is redirected to a User Home page wherein he/she can view tickets raised by him/her, raise new ticket, and generate report. If the User is a Gate Keeper or a Team Member, then he/she will see an additional link which will redirect him/her to a Gate Keeper administrative page or a Team Member page respectively. Scope	Privileged Users Method of Verification & Validation	•	Verification of Financial Ticket, Academic Ticket and Infrastructural Ticket hyperlinks is done by ensuring that the User is redirected to a Ticket Raising page which enables the User to raise a corresponding ticket. •	If the User is a Gatekeeper, then verification is done by ensuring that he/she will see an additional hyperlink that will redirect him/her to a Gate Keeper administrative page from which the Gate Keeper can assign team members to a ticket id and/or edit ticket type, category and item. •	If the User is a Team Member, then verification is done by ensuring that he/she will see an additional hyperlink that will redirect him/her to a Team Member page from which the Team Member checks the tickets assigned to him/her. •	Verification is done by ensuring that only one of the Gate Keeper administrative link or Team Member link appears, as the User Home page is dynamically configured depending upon the role of the User. User Acceptance Criteria	The requirement is considered to have been met if – •	After entering his/her respective login credentials, the User is redirected to a User Home Page that befits his/her role. •	The role of the User is maintained throughout the session. The requirement is considered to have been failed if – •	After entering his/her respective login credentials, the User is redirected to a User Home Page that is not befitting his/her role. •	The role of the User is not maintained within a session.

4.3.4	Ticket Raising

Requirement Id	Requirement Category	Requirement Type	Priority	Hierarchy	Ref.

REQ-02.1 Functional	Stated 	Very High		Questionnaire Requirement description	A privileged User can raise a ticket from this page. Depending upon the Ticket Service type (Financial, Academic or Infrastructural) the corresponding ticket types, categories and items will be populated which should be selected to raise a particular ticket. The User is required to enter Inventory Machine No, Ticket Priority and Ticket Description along with an attachment that conveys either a scanned copy of a bill, or a print-screen image of the approval email sent by the Project Manager to the Ticket Raiser. On submitting the details, the User receives an email that notifies him/her of a unique ticket id that is assigned to the ticket that has been raised by the User. Scope 	Privileged users Method of Verification & Validation	•	Verification is done by ensuring that ticket type has been selected. If it is not selected, then ticket category and ticket item fields are disabled. •	Verification is done by ensuring that ticket category has been selected. If it is not selected, then ticket item field is disabled. •	Validation is done to check whether more than 200 characters have been entered inside description text-area field. User Acceptance Criteria	The requirement is considered to have been met if – •	The Ticket type field is populated with all the types belonging to the Service Type of the ticket selected (when the User clicks on any one of the 3 hyperlinks of Financial Ticket, Academic Ticket, Infrastructural Ticket present inside the User Home page). •	The Ticket Category field is populated with all the categories belonging to the Ticket Type of the ticket selected. •	The Ticket Item field is populated with all the items belonging to the Ticket Category of the ticket selected. •	The User’s corresponding User ID, Username and BU are displayed in non-editable format. •	When the User presses the Submit button, the User receives a popup along with an email containing the unique ticket id that is generated by the system for that particular ticket request. The requirement is considered to have been failed if – •	The Ticket type field is not populated with all the types belonging to the Service Type of the ticket selected (when the User clicks on any one of the 3 hyperlinks of Financial Ticket, Academic Ticket, Infrastructural Ticket present inside the User Home page). •	The Ticket Category field is not populated with all the categories belonging to the Ticket Type of the ticket selected. •	The Ticket Item field is not populated with all the items belonging to the Ticket Category of the ticket selected. •	The User’s corresponding User ID, Username and BU are not displayed appropriately, or in non-editable format. •	When the User presses the Submit button, the User does not receive a popup, neither an email containing the unique ticket id that is generated by the system for that particular ticket request.

4.3.5	Editing of Ticket Type, Category and Item, Viewing Departmental Tickets Raised, Viewing feedback about Team Member

Requirement Id	Requirement Category	Requirement Type	Priority	Hierarchy	Ref.

REQ-02.2 Functional	Stated 	Very High		Questionnaire Requirement description	When the Gate Keeper clicks on “Gate Keeper Home” hyperlink from User’s Home page, the Gate Keeper home is displayed. This page enables the Gate Keeper to view already raised tickets having status as “new” or “on hold”. The Gate Keeper can edit a ticket type, category and item as well. The feedbacks given by a ticket raiser or User to the Team Member’s task can be viewed by the Gate Keeper. Scope	Gate Keeper Method of Verification & Validation	•	Verification is done by ensuring that “Username”, “User ID” fields are non-editable. •	Verification is done by ensuring that whenever the “Edit Ticket Type” hyperlink is clicked, the Gate Keeper is redirected to ticket_type_change page. •	Verification is done by ensuring that whenever the “Edit Ticket Category” hyperlink is clicked, the Gate Keeper is redirected to ticket_category_change page. •	Verification is done by ensuring that whenever the “Edit Ticket Item” hyperlink is clicked, the Gate Keeper is redirected to ticket_item_change page. •	Verification is done by ensuring that whenever the “View Feedback” hyperlink is clicked, the Gate Keeper is redirected to team_member_feedback page. •	Verification is done by ensuring that whenever any of the ticket id hyperlinks are clicked, the Gate Keeper is redirected to assign_team_member page.

User Acceptance Criteria	The requirement is considered to have been met if – •	The User is redirected to “ticket_type_change” page if he/she clicks on the “Edit Ticket Type” hyperlink. •	The User is redirected to “ticket_category_change” page if he/she clicks on the “Edit Category Type” hyperlink. •	The User is redirected to “ticket_item_change” page if he/she clicks on the “Edit Item Type” hyperlink. •	The User is redirected to “team_member_feedback” page if he/she clicks on the “View Feedback” hyperlink. •	The User is redirected to “assign_team_member” page if he/she clicks on any of the ticket id hyperlinks. The requirement is considered to have been failed if – •	The User is not redirected to “ticket_type_change” page if he/she clicks on the “Edit Ticket Type” hyperlink. •	The User is not redirected to “ticket_category_change” page if he/she clicks on the “Edit Category Type” hyperlink. •	The User is not redirected to “ticket_item_change” page if he/she clicks on the “Edit Item Type” hyperlink. •	The User is not redirected to “team_member_feedback” page if he/she clicks on the “View Feedback” hyperlink. •	The User is not redirected to “assign_team_member” page if he/she clicks on any of the ticket id hyperlinks.

4.3.6	Assign Team Member

Requirement Id	Requirement Category	Requirement Type	Priority	Hierarchy	Ref.

REQ-02.3 Functional	Stated 	Very High		Questionnaire Requirement description	When the Gate Keeper selects the hyperlinks under ticket id column from Gate Keeper Home, the Gate Keeper will be redirected to “assign_team_member” page. This page enables the Gate Keeper to assign a Team Member across the selected ticket task. When the Gate Keeper decides to approve a ticket request, he/she will delegate a Team Member to manually perform the task described by the ticket raised by the User. An email is sent to the User (ticket requester) containing information about the User ID of the Team Member who has been assigned to perform the task if the ticket has been approved. The Team Member also receives a mail containing the User ID of the User who raised the ticket. If the ticket description is not abiding by the company policy, then the Gate Keeper rejects the ticket request and an email conveying the same is sent to the User. Scope	Gate Keeper Method of Verification & Validation	•	Verification is done by ensuring that “Username”, “User ID” fields are non-editable. •	Verification is done by ensuring that “Ticket id”, “Ticket Type”, ”Ticket Category”, “Ticket Item”, “Ticket Priority”, “Inventory Machine No”, “BU” fields are non-editable. •	Verification is done by ensuring that “Ticket Type”, “Description” field is non-editable. •	Verification is done by ensuring that the Team Member names of the Gate Keeper’s Department are populated inside a drop down box which the Gate Keeper uses to assign a Team Member to a ticket. •	Verification is done by ensuring that whenever the “Submit” is pressed, the ticket information table is populated with “ticket id”, “ticket type”, “description”, “user id”, “request date”, “ticket priority”, “ticket status”, “team member user id”, “assigned date” and the corresponding ticket raiser is sent an email stating that his/her ticket is being processed. Here, the ticket status is set to “assigned”. The assigned Team Member also receives a mail containing the User ID of the User who raised the ticket. •	Verification is done by ensuring that whenever the “Reject” is pressed, the ticket information table is populated with “ticket id”, “ticket type”, “description”, “user id”, “request date”, “ticket priority”, “ticket status”, “team member user id”, “assigned date” and the corresponding ticket raiser is sent an email stating that his/her ticket has been rejected. Here, the ticket status is set to “rejected”.

User Acceptance Criteria	The requirement is considered to have been met if – •	The Gate Keeper is able to select any one of his/her Department’s Team Members to perform the task described by the ticket. •	On pressing the “Assign” button, an email is sent to the User containing the User ID of the Team Member assigned to perform the task described by the ticket. An email containing the User ID of the User is also sent to the assigned Team Member. •	On pressing the “Reject” button, an email is sent to the User, which notifies the User about the rejection of the ticket that was raised by him/her. •	The Gate Keeper is able to view all the ticket details in non-editable format while validating the ticket request. The requirement is considered to have been failed if – •	The Gate Keeper is not able to select any one of his/her Department’s Team Members to perform the task described by the ticket. •	On pressing the “Assign” button, an email is not sent to the User containing the User ID of the Team Member assigned to perform the task described the ticket. An email containing the User ID of the User is also not sent to the assigned Team Member. •	On pressing the “Reject” button, an email is not sent to the User, which notifies the User about the rejection of the ticket that was raised by him/her. •	The Gate Keeper is not able to view all the ticket details in non-editable format while validating the ticket request.

4.3.7	Viewing Tickets Assigned

Requirement Id	Requirement Category	Requirement Type	Priority	Hierarchy	Ref.

REQ-02.4 Functional	Stated 	Very High		Questionnaire Requirement description	When the Team Member clicks on “Team Member Home” hyperlink from User’s Home page, the Team Member home is displayed. This page enables the Team Member to view the tickets assigned to/him. Scope	Team Member Method of Verification & Validation	•	Verification is done by ensuring that “Username” and “User ID” fields are non-editable. •	Verification is done by ensuring that whenever the Team Member clicks on any of the ticket id hyperlinks, the Team Member is redirected to a ticket_task_fulfillment page wherein he/she is required to set the status of the ticket assigned to him/her. User Acceptance Criteria	The requirement is considered to have been met if – •	The Team Member can view all the ticket details about the tickets assigned to him/her only. •	The Team Member is redirected to a ticket_task_fulfillment page whenever he/she clicks on any of the ticket id hyperlinks. The requirement is considered to have been failed if – •	The Team Member cannot view all the ticket details about the tickets assigned to him/her only. •	The Team Member is not redirected to a ticket task_fulfillment_page whenever he/she clicks on any of the ticket id hyperlinks.

4.3.8	Ticket-Task Fulfillment

Requirement Id	Requirement Category	Requirement Type	Priority	Hierarchy	Ref.

REQ-02.5 Functional	Stated 	Very High		Questionnaire Requirement description	The Team Member is redirected to the ticket task_fulfillment_page whenever he/she clicks on any of the ticket id hyperlinks present inside the team member home page. The ticket_task_fulfillment page enables the Team Member to set the status of the ticket assigned. If the task has been duly completed, the Team Member sets the status as “closed”. If he/she cannot complete the task currently, then the status is set as “on hold”. If the task cannot be completed by the Team Member on grounds of inexperience or illness, then the status is set as “suspended”. In the case of “on hold” or “closed”, the Team Member is expected to give an elaborate description that hinders him/her from closing the ticket. Scope	Team Member Method of Verification & Validation	•	Verification is done by ensuring that “Username” and “User ID” fields are non-editable. •	Verification is done by ensuring that “Ticket Type”, “Description”, ”Priority” and “Attachment” fields are non-editable. •	Verification is done by ensuring that the status dropdown menu is populated with “closed”, “on hold” and “suspended” options and one of them have been selected. •	Verification is done by ensuring that when the “Submit” button is pressed, the corresponding status is set in the ticket information table. •	Verification is done by ensuring that the User receives a mail containing a feedback link, clicking on which, the User can give feedback about the Team Member’s work (only when status is set as “closed”). •	Verification is done by ensuring that the User receives a mail containing the description given by the Team Member (only when status is set as “on hold” or “suspended”). User Acceptance Criteria	The requirement is considered to have been met if – •	The Team Member can view all the ticket details about the ticket that was selected by him/her from the team member home page. •	The User receives a mail containing a feedback link, clicking on which, the User can give feedback about the Team Member’s work (only when status is set as “closed”). •	The User receives a mail containing the description given by the Team Member (only when status is set as “on hold” or “suspended”). The requirement is considered to have been failed if – •	The Team Member cannot view all the ticket details about the ticket that was selected by him/her from the team member home page. •	The User doesn’t receive a mail containing a feedback link, clicking on which, the User can give feedback about the Team Member’s work (only when status I set as “closed”). •	The User doesn’t receive a mail containing the description given by the Team Member (only when status is set as “on hold” or “suspended”).

4.3.9	Edit Ticket Type

Requirement Id	Requirement Category	Requirement Type	Priority	Hierarchy	Ref.

REQ-02.6 Functional	Stated 	Very High		Questionnaire Requirement description	When the Gate Keeper selects the “Edit Ticket Type” hyperlink, Gate Keeper will be redirected to ticket_type_change page. This page enables the Gate Keeper to add a new ticket type along with description, remove an existing ticket type or to rename a particular ticket type. Scope	Gate Keeper Method of Verification & Validation	•	Validation is done by ensuring that the “Ticket Type Name” field is filled. •	Validation is done by ensuring that the “Type Description” field is filled. •	Validation is done by ensuring that the “Enter New Name” field is filled. •	Validation is done by ensuring that “Ticket Type Name” dropdown menu is populated with options from the drop down menu and one of them has been selected. •	Verification is done by ensuring that when the “Add” button is pressed, the type is added in the database. •	Verification is done by ensuring that when the “Remove” button is pressed, the type will be removed from the database. •	Verification is done by ensuring that when the “Rename” button is pressed, the type will be renamed inside the database. User Acceptance Criteria	The requirement is considered to have been met if – •	The Gate Keeper can select only those ticket types that belong to his/her Department or Service Type. •	On adding a ticket type, the new type is added successfully in the database. •	On removing a ticket type, the type is removed successfully from the database. •	On renaming a ticket type, the type name is updated successfully in the database. The requirement is considered to have been failed if – •	The Gate Keeper cannot select the ticket types that belong to his/her Department or Service Type. •	On adding a ticket type, the new type is not added successfully in the database. •	On removing a ticket type, the type is not removed successfully from the database. •	On renaming a ticket type, the type name is not updated successfully in the database.

4.3.10	Edit Ticket Category

Requirement Id	Requirement Category	Requirement Type	Priority	Hierarchy	Ref.

REQ-02.7 Functional	Stated 	Very High		Questionnaire Requirement description	When the Gate Keeper selects the “Edit Ticket Category” hyperlink, Gate Keeper will be redirected to ticket_category_change page. This page enables the Gate Keeper to add a new ticket category along with description, remove an existing ticket category or to rename a particular ticket category. Scope	Gate Keeper Method of Verification & Validation	•	Validation is done by ensuring that the “Ticket Type Name” field is filled. •	Validation is done by ensuring that the “Ticket Category Name” field is filled. •	Validation is done by ensuring that the “Category Description” field is filled. •	Validation is done by ensuring that the “Enter New Name” field is filled. •	Validation is done by ensuring that “Ticket Type Name” dropdown menu is populated with options from the drop down menu and one of them has been selected. •	Validation is done by ensuring that “Ticket Category Name” dropdown menu is populated with appropriate options from the drop down menu and one of them has been selected. •	Verification is done by ensuring that when the “Add” button is pressed, the category is added under the corresponding type in the database. •	Verification is done by ensuring that when the “Remove” button is pressed, the category will be removed from the corresponding type in the database. •	Verification is done by ensuring that when the “Rename” button is pressed, the category will be renamed under the corresponding type in the database. User Acceptance Criteria	The requirement is considered to have been met if – •	The Gate Keeper can select only those ticket types that belong to his/her Department or Service Type. •	The Gate Keeper can select only those ticket categories that are under the aforementioned ticket type. •	On adding a ticket category, the new category is added successfully under the aforementioned type in the database. •	On removing a ticket category, the new category is removed successfully from the aforementioned type in the database. •	On renaming a ticket category, the category name is updated successfully under the aforementioned type in the database. The requirement is considered to have been failed if – •	The Gate Keeper cannot select only those ticket types that belong to his/her Department or Service Type. •	The Gate Keeper cannot select only those ticket categories that are under the aforementioned ticket type. •	On adding a ticket category, the new category is not added successfully under the aforementioned type in the database. •	On removing a ticket category, the new category is not removed successfully from the aforementioned type in the database. •	On renaming a ticket category, the category name is not updated successfully under the aforementioned type in the database.

4.3.11	Edit Ticket Item

Requirement Id	Requirement Category	Requirement Type	Priority	Hierarchy	Ref.

REQ-02.8 Functional	Stated 	Very High		Questionnaire Requirement description	When the Gate Keeper selects the “Edit Ticket Item” hyperlink, Gate Keeper will be redirected to ticket_Item_change page. This page enables the Gate Keeper to add a new ticket item along with description, remove an existing ticket item or to rename a particular ticket item. Scope	Gate Keeper Method of Verification & Validation	•	Validation is done by ensuring that the “Ticket Type Name” field is filled. •	Validation is done by ensuring that the “Ticket Category Name” field is filled. •	Validation is done by ensuring that the “Ticket Item Name” field is filled. •	Validation is done by ensuring that the “Item Description” field is filled. •	Validation is done by ensuring that the “Enter New Name” field is filled. •	Validation is done by ensuring that “Ticket Type Name” dropdown menu is populated with options from the drop down menu and one of them has been selected. •	Validation is done by ensuring that “Ticket Category Name” dropdown menu is populated with appropriate options from the drop down menu and one of them has been selected. •	Verification is done by ensuring that when the “Add” button is pressed, the item is added under the corresponding category in the database. •	Verification is done by ensuring that when the “Remove” button is pressed, the item will be removed from the corresponding category in the database. •	Verification is done by ensuring that when the “Rename” button is pressed, the category will be renamed under the corresponding category in the database. User Acceptance Criteria	The requirement is considered to have been met if – •	The Gate Keeper can select only those ticket types that belong to his/her Department or Service Type. •	The Gate Keeper can select only those ticket categories that are under the aforementioned ticket type. •	The Gate Keeper can select only those ticket items that are under the aforementioned ticket category. •	On adding a ticket item, the new item is added successfully under the aforementioned category in the database. •	On removing a ticket item, the new item is removed successfully from the aforementioned category in the database. •	On renaming a ticket item, the item name is updated successfully under the aforementioned category in the database. The requirement is considered to have been failed if – •	The Gate Keeper cannot select only those ticket types that belong to his/her Department or Service Type. •	The Gate Keeper cannot select only those ticket categories that are under the aforementioned ticket type. •	The Gate Keeper cannot select only those ticket items that are under the aforementioned ticket category. •	On adding a ticket item, the new item is not added successfully under the aforementioned category in the database. •	On removing a ticket item, the new item is not removed successfully from the aforementioned category in the database. •	On renaming a ticket item, the item name is not updated successfully under the aforementioned category in the database.

4.3.12	Redirection to report selection page

Requirement Id	Requirement Category	Requirement Type	Priority	Hierarchy	Ref. REQ-03.1 Functional Stated High NA	Questionnaire Requirement description	When the user clicks on the Report link, he should be redirected to a report selection page. Scope	Privileged User Method of Verification & Validation	The role of the User would be fetched using the session id and accordingly the links to filter the data and generate the reports would be displayed. User Acceptance Criteria	The requirement is considered to have been met if – •	The proper fields are displayed to the User with respective privileges. •	After the Generate button is clicked, the User is redirected properly to another page with the report. The requirement is considered to have not been met if – •	The report selection page containing the appropriate fields according to the role of the user is not displayed to the user.

4.3.13	Generate Report

Requirement Id	Requirement Category	Requirement Type	Priority	Hierarchy	Ref. REQ-03.2 Functional Stated High After-03.1 Questionnaire Requirement description	Generate report based on the criteria such as date, status, Team Member and/or business unit depending on the role of the User selected by the User and convert it to Excel format when desired by the user. Scope	Privileged Users Method of Verification & Validation •	The data would be retrieved from the database depending on the criteria selected by the User to generate the report, and the report would be generated using the data. •	Verification is done by ensuring that the date entered in “From Date” field is before the date entered in “To Date” field •	Verification is done by ensuring that the report generated is according to the criteria selected by the user. User Acceptance Criteria	The requirement is considered to have been met if – •	The report will be generated properly for the criteria selected by the User. •	The report will be paginated. •	On clicking the “Convert to Excel” button the report generated should be converted to Excel format. The requirement is considered to have been not met if – •	In any case the report is not generated or not displayed. •	In any case the report is not converted to Excel format or not displayed.

4.3.14	Team Member Performance Review Requirement Id	Requirement Category	Requirement Type	Priority	Hierarchy	Ref. REQ-03.3 Functional Stated Normal After-03.2 Questionnaire Requirement description	The Gate Keeper should have the privilege to generate bar graph of the Team Member’s performance depending on the status of the tickets assigned to the Team Member. Scope	Gate Keeper Method of Verification & Validation	•	The status of all the tickets assigned to the Team Member would be retrieved from the database and used to generate a bar graph accordingly. User Acceptance Criteria	The requirement is considered to have been met if – •	The Gate Keeper should only be able to generate bar graph. •	 The bar graph is generated accurately. •	The bar graph generated for a Team Member showing the status of various tickets assigned to him should include only the tickets assigned to him. The requirement is considered to have been not met if – •	In any case the graph for a Team Member showing the status of various tickets assigned to him is not generated or displayed.

4.3.15	Team Member Performance Review

Requirement Id	Requirement Category	Requirement Type	Priority	Hierarchy	Ref. REQ-03.3 Functional Stated Normal After-03.2 Questionnaire Requirement description	The Gate Keeper should have the privilege to generate bar graph of the feedback provided by the User for the Team Member for the service provided by him for a particular ticket. Scope	Gate Keeper Method of Verification & Validation •	The feedback from the User for the service provided by a Team Member is retrieved from the database accordingly and a bar graph is generated. User Acceptance Criteria	The requirement is considered to have been met if – •	The Gate Keeper should only be able to generate bar graph. •	 The bar graph is generated accurately. •	The feedback graph should be accurately generated based on the feedback for that particular Team Member only. The requirement is considered to have been not met if – •	In any case the feedback graph displaying the feedback of a Team Member provided by a User is not generated or displayed.

4.4	Operating Environment Requirements 4.4.1	Hardware a.	RAM: 60GB (recommended) b.	Processor: Pentium Xenon c.	Disk Space: Minimum 2TB required for the application to run smoothly 4.4.2	Software a.	Internet browser is required. The system is most compatible with Internet Explorer 9 in 1080 x 1920 resolutions. 4.4.3	Network a.	LAN connectivity 4.4.4	Communication a.	Email b.	Direct interview with Customer c.	Query log d.	Telephonic conversation 4.5	External interface requirements 4.5.1	User Interface a.	GUI based web application where internet browser is the only tool for the Users 4.5.2	Software Interface a.	Eclipse Galileo b.	MySQL 5 c.	Internet Browser d.	Apache Tomcat 6.0 e.	JDK 1.7 f.	Apache poi 4.5.3	Database Requirements a.	MySQL server will be used as the relational database for this project. b.	The growth of the database is unrestricted. 4.5.4	Operational Requirements a.	Multi User operation – Application should support all the (10,000) privileged Users of the organization concurrently. b.	Performance Requirements - Login time should be 5 seconds maximum. 4.5.5	Fit Criteria The system is expected to respond fast enough so that it does not take more than 1-2 seconds to login, connect to database system and not more than 30 seconds to update data in database system. 4.6	Non Functional Requirements 4.6.1	Security The application will use Web Authentication to permit Users from Customer domain only. When the User chooses to reset the password, the security question is used as a security measure. Once the User gives the correct answer to the security question, the system will generate a random password and mail that password to the User. At the same time, the system will reset the flag field with “0” as default to “1” which indicates that it is a system generated password and the User has to reset the password on first login. 4.6.2	Reliability a.	The application should redirect the User to the home page if the login credentials are correct. b.	The application should send the randomly generated password to the User’s email id if the entered User ID is correct and the User clicks on the forgot password. c.	The application should not cause loss of data for any error/ exception occurred in process. d.	All bugs/defects should be resolved with a minimal downtime. 4.6.3	Maintainability a.	The Developer’s high quality standards are maintained during the designing, coding and testing phase. b.	Appropriate and sufficient documents are provided throughout the development of the  application. 4.6.4	Availability The system must be available at all times, except for 3 hours of maintenance, on the last day of every six months. 4.6.5	Scalability The proposed system should be able to handle the increasing number of privileged employees in the organization, with time. 4.6.6	Portability The system should work on all operating systems supported by the organization. 4.6.7	Safety The data should remain consistent in case of system crash or physical disasters. 4.7	Other requirements 4.7.1	User Training Customer has to take the responsibility of training the Users. 4.7.2	User Manual and Help NA 4.7.3	Automated and Manual features a.	The module has the automated feature of sending email to the User, which contains the random password generated by the system. b.	Whenever a User submits a ticket, he/she receives an email notification indicating the ticket id that has been generated by the system automatically, corresponding to that particular ticket. c.	Whenever the Gate Keeper assigns a ticket member to act on a particular ticket, an email containing the ticket id along with the User ID of the Team Member who will act on the ticket is sent to the User. An email containing the ticket id along with the User ID of the User who raised the ticket is sent to the Team Member. d.	The User will have to manually set a new password when the User logs in for the first time after password reset. e.	The Team Member manually performs the task described by the ticket raised by the User. 4.7.4	Features not required NA

5.0	Prototype NA

6.0	Acceptance 6.1	Acceptance Criteria a.	Application Environment 1.	Hardware – Intel Xeon 3 GHz, RAM 60GB (recommended), minimum 2 TB storage 2. Software – Internet Explorer, Java Development Kit v1.5, Apache Tomcat v6.0, Eclipse Galileo IDE v3.7, MySQL Server 2005 should be installed in the database server. 3. Network – i.	All the branches should be connected in LAN or WAN. ii. The application server should be accessible to all the branches. 4. Legal/Statutory – i.	Customer has to take care of the license of necessary software installed at test server and production server. ii. Development environment needs Internet Explorer installed. Either Customer has to provide the software to the team or they have to identify a development machine with Eclipse Galileo, Apache Tomcat v6.0, MySQL Server 2005 and Internet Explorer installed and gives the L&T Infotech development team access to that. b.	Testing to be carried out 1.	Normal Testing – Development team will carry out unit testing and integration testing and provide Customer with the test cases and test results. Customer should review the test cases and test results before going ahead with the UAT at their end. 2.	Load Testing – It is recommended to carry out a load testing at the Customer test server. c.	Test Task Responsibilities 1.	Preparing Test Unit Cases – L&T Infotech development team. 2.	Preparing Integration Test Cases – L&T Infotech development team. 3.	Executing Unit Testing – L&T Infotech development team. 4.	Executing Integration Testing – L&T Infotech development team. 5.	Documenting Unit and Integration Test Results – L&T Infotech development team. 6.	System Testing – L&T Infotech development team. 7.	Load Testing – Customer and L&T Infotech development team. 8.	Documenting Acceptance Test results – Customer. 9.	Test Data to be provided by – L&T Infotech development team. d.	Volumetric data 1.	Application should support at least 10000 Users simultaneously e.	Performance 1.	Login transaction should take 1-2 seconds. 2.	Database update should not take more 30 seconds. f.	User profiles 1.	System should recognize Gate Keeper, Team Member and User. 7.0	References to Other Documents a.	ITIL-PD-13-Questionnaire b.	ITIL-PD-13-Data_Dictionary 8.0	Assumptions and Dependencies 8.1	Assumptions: a.	There exists a master table of the project which is a subset of the master table of the Customer. b.	The database administrator provides access to the Customer master table. c.	There exists an insert after trigger on the master table of the Customer, which automatically inserts the new entries in the master table of the project. d.	It is assumed that non privileged Users are aware that they are not valid Users of the system. e.	The Gate Keeper abides by the company policy while validating the ticket request. f.	The User has to have a proof of the approval mail sent by the Project Manager before raising an Academic or Infrastructural ticket. The User has to submit a scanned copy of the bill as a proof while raising a Finance ticket. g.	If the status of the ticket is “suspended”, then the gatekeeper has to assign the task to some other team member. h.	The Administrator doesn’t have privileges to raise a ticket, but can only grant privileges to the Users of the system. i.	The Customer is responsible for periodic backup and archival of data. j.	The Gate Keeper can assign the ticket request to a Team Member of his/her Department (Finance, Academy, and Infrastructure) only. k.	The Gate Keeper can view the feedback given by User to the Team Members of his/her Department (Finance, Academy, and Infrastructure) only. l.	If the user doesn’t select the date field for generating a report, by default a report for 2 months                before current date will be generated. m.	If the user doesn’t select the status field for generating a report, by default a report for all status                will be generated. n.	If the Gate Keeper doesn’t select the Team Member field for generating a report, by default a report for all Team Members of his department will be generated. o.	If the Gate Keeper doesn’t select the Business Unit field for generating a report, by default a report for all Business Unit of the organization will be generated.

8.2	Dependencies a.	The performance and response time of the system will heavily depend on the server configuration and LAN/WAN speed. b.	The system’s master table uses data from the Customer’s master table. 9.0	Abbreviations / Bibliography Abbreviations	Meaning ITIL	Information Technology Infrastructure Library LAN	Local Area Network WAN	Wide Area Network UAT	User Acceptance Testing