software requirements specificational495/eport/docs/info627srs.pdfsoftware requirements...

Software Requirements Specification

Project Name: Home-grown Complementary Issue Tracking System

Company Name: PTI Team Members:

Adam Lerman Abdalla Hashem Danijela Lazarevic James Mallon

2010 PTI

REVISION HISTORY Date Revision Description Author 03/14/2010 1.0 Initial version Group 3

Software Requirements Specification Page i

Table of Contents 1. Introduction ................................................................................................................................ 1

1.1 Purpose............................................................................................................................. 1 1.2. Scope ................................................................................................................................ 1 1.3 References ........................................................................................................................ 2 1.4 Assumptions and Dependencies ...................................................................................... 2

2. Software Product Overview ....................................................................................................... 3 2.1 System Scope ................................................................................................................... 3 2.2 System Architecture ......................................................................................................... 3

2.2.1 External View of Software Product ........................................................................... 3 2.2.2 Internal View of Software Product ........................................................................... 2

2. 3 Feature Overview ................................................................................................................. 2 3. System Use ................................................................................................................................. 2

3.1 Support for User Workflows ................................................................................................. 2 3.2 Actor Survey .......................................................................................................................... 1 3.3 Use-Case Model and System Events ..................................................................................... 3 3. 4 System Interfaces ................................................................................................................ 2

4. Specific requirements ................................................................................................................. 1 4.1 System Use-Cases ................................................................................................................. 1

Use Case 1: Create and Access Reports .................................................................................. 1 Use Case 2: Add/Edit Issue ..................................................................................................... 3 Use Case 3: Report Issue by Email .......................................................................................... 3 Use-Case 4: Use Audit Trail ..................................................................................................... 3 Use Case 5: Generate Work Order.......................................................................................... 2 Use Case 6: System Administration ........................................................................................ 3

4.2 System Functional Specification ...................................................................................... 2 4.3 System Domain Models ........................................................................................................ 2

4.3.1 Internal Domain Model ............................................................................................. 2 4.3.2 Data Models .............................................................................................................. 1

4.4 Non-Functional Requirements .............................................................................................. 1 4.4.1 Usability .................................................................................................................... 1 4.4.2 Reliability ................................................................................................................... 1 4.4.3 Performance ............................................................................................................. 2 4.4.4 Supportability ............................................................................................................ 2

5. SUPPLEMENTARY REQUIREMENTS ............................................................................................ 2 5.1 Project management strategy .......................................................................................... 2 5.2 Systems Security and Audit .............................................................................................. 2 5.3 Assumptions and Dependencies ...................................................................................... 3 5.4 Requirements Traceability ............................................................................................... 3

6. Online User Documentation and Help System Requirements ................................................... 6 7. Design Constraints ...................................................................................................................... 6 8. Purchased Components ............................................................................................................. 6 9. Interfaces .................................................................................................................................... 6

9.1 User Interfaces ................................................................................................................. 6 9.2 Hardware Interfaces ......................................................................................................... 6 9.3 Software Interfaces .......................................................................................................... 6 9.4 Communications Interfaces ............................................................................................. 7

Software Requirements Specification Page ii

10. Licensing Requirements ....................................................................................................... 7 11. Legal, Copyright, and Other Notices .................................................................................... 7 12. Applicable Standards ........................................................................................................... 7

Software Requirements Specification Page 1

1. INTRODUCTION 1.1 Purpose This document, the software requirements specification (SRS), for PTI’s new home-grown complementary issue tracking system serves to provide the reader with a detailed description of the attributes and behaviors of the system to be implemented and built. The system will consist of upgrading and modifying an existing system as well building and supplementing a new one with additional features. The document will include functional, non-functional, and supplementary requirements through diagrams, use cases, and discussions, which will enable the designers and developers to create the system based on the users’ needs and imposed system constraints. The intended audience shall be the multiple stakeholders of the system, including the customers, salespeople and partners, account managers, application consultants, product managers, developers, testers, and system administrators, all of which will be detailed in future sections. Since there is a wide variety of user roles and needs, this document will attempt to address each one in such a manner that everyone can understand the proposed system outcomes and lay the foundation for it to be created. In addition, everyone can be on the same page and ensure that their needs are being met, by coming to an agreement that the system will fulfill these expectations as based on this document. Therefore, it may also serve as a contract by which customers and PTI staff can sign off on. Further sections will include internal and external views of the system, user roles, workflows, and use cases, specific functional and non-functional requirements and system domain models. In addition, issues such as design constraints, interfaces, licensing requirements, and legal notices will also be touched upon. 1.2. Scope This SRS details the new home-grown complementary issue tracking system to be implemented at PTI. Its purpose is to serve as a more robust issue tracking system with additional features than are currently available, and to involve more stakeholders in the process than are traditionally using today’s system. Since there are many features to be added and the process will involve both external and internal aspects, the system will be rolled out in three phases. This SRS mainly discusses the first phase of implementation, as they are the most important features and can become very detailed, although the following versions are touched on as well. The first phase will include the search, reporting, and work order modules, in addition to issue tracking, knowledge management, demographics, email, and admin modules. Once stable, version two will include priority, security, audit trail and web modules, and version three will contain the dashboard, discussion thread, file attachment, date/time translator, VM, test case, automation, and duplication modules. More information about these modules can be found in section 2.2.2.

Together these will provide the following benefits to PTI and its customers and stakeholders: • Enhanced software issue resolution • Allow for enhanced reporting of issues and defects • Allow for improved viewing and tracking of issues and defects • Ability to add notes to reported issues • Permit ease of searching with basic and advanced options • Improved knowledge base


• Ability to track assigned issues and follow through on resolutions • Generation of multiple reports, both manually and automatically • Provide issue/defect accountability • Determine, store, and track issue/defect priority • Help to ensure work orders are closed when complete • Provide additional stakeholders with system access and greater robustness • Allow for confirmation of fixed issues • Keep users informed of progress at all times • Reduce information fragmentation • Open lines of communication between teams

1.3 References

Communications with various stakeholders, including testers and developers. Hashem, A., Lerman, A., Lazarevic, D., & Mallon, J. (2010). Project Assignment 1: Problem and

Context Analysis. INFO627, Drexel University: Philadelphia. Hashem, A., Lerman, A., Lazarevic, D., & Mallon, J. (2010). Project Assignment 2: Vision

Document. INFO627, Drexel University: Philadelphia. Proscape Technologies, Inc. (2010). About Proscape: What We Do. Accessed on February 11,

2010 from <http://www.proscape.com/about.aspx>. Proscape Technologies, Inc. (2010). Closed Loop Marketing: Closed Loop Marketing for

Pharmaceutical Companies. Accessed on February 11, 2010 from <http://www.proscape.com/clm.aspx>.

1.4 Assumptions and Dependencies The new home-grown issue tracking system will not come without required assumptions and dependencies. One area of concern is the level of buy-in from upper management, as the majority of the leadership team did not initially share the same concerns as the QA and development teams with respect to their inability to collaborate, communicate, and share information. Also, it must be ensured that, during the implementation phases, the users test and validate the requirements so that each affected department’s needs are properly met. Resources for implementing this change should be assessed and gathered, and an impact analysis should be conducted. The new system will rely on the existing infrastructure and will make use of current applications and systems already in place. Additional components will then be added. Therefore, a solid server and database system will play a key role in the development of the new system and any upgrades should utilize these effectively. New features should be integrated seamlessly and attempt to minimize any additional overhead, while allowing the user base to increase over time with no interruptions in service. The system shall also provide for the ability to instantiate users and provide them with the correct read/write privileges as assigned by a system administrator. This will limit the information that can be viewed by particular users/user groups, and a solid security policy should be implemented and audited.


2. SOFTWARE PRODUCT OVERVIEW This section serves to offer an overview of the home-grown complementary issue tracking system and may be used by all of the stakeholders involved. Therefore, it presents diagrams and descriptions of the product as a whole, and will include the system scope, architecture (both external and internal), and an overview of its features. 2.1 System Scope The proposed system will include a number of modules new to the issue tracking system currently in place. Some will be provided via upgrade to the third party system as is now available by the company, while others will come as PTI-created modules to supplement the existing system. The interface will, therefore, remain the same, and additional features will be added using existing UI conventions. This will provide for seamless integration and ease of use among current stakeholders, providing for as little of a learning curve as possible. The new issue tracking system will be web-based and will, therefore, utilize web server technology, including Microsoft Server 2003 and 2008 bases. 2.2 System Architecture This section defines the external and internal system architecture. It will present diagrams and discussions for ease of understanding and completeness.

2.2.1 External View of Software Product Figure 1 shows an overview of PTI's proposed computer architecture with respect to the complete issue tracking process. The figure demonstrates how the new Home-grown Complementary Issue Tracking system will fit within the existing company's architecture, providing additional services and taking advantage of the current working processes. The new system is meant to be incorporated into the back end of the company's architecture so it results in one whole system that works seamlessly and synergetically to the users providing optimal service to PTI’s customers and its employees. The final Issue Tracking System will have one user interface accessible through the web access currently in place. The Home-grown Complementary Issue Tracking System will be storing data in to the same database as the current system and working with the current email system used in the organization to support system notification outputs. The Knowledge Based search will work on the same principle pulling the stored data from the central database and allowing incorporation of the documentation from the local file system via attachments. The mid-tier server will be crucial in processing and incorporating all systems' data to and from users and the database.


Figure 1. External view of Home-grown Issue Tracking System

2.2.2 Internal View of Software Product The block diagram provides a high level view of the system in its entirety. The system management module reflects the architecture model provided above in section 2.2.1. The individual blocks depict the software modules that make up the system. Due to the complexity of the system and the interrelationship between the existing issue tracking system and the home-grown system, it was necessary to break out the components and create multiple versioning for deployment. The blocks outlined in blue should be developed and deployed as part of Version 1. The blocks outlined in red should be developed and deployed in Verson 2, and the yellow blocks should be developed and deployed on Version 3. The 12 modules depicted in Version 1 are integral to the success of the project because it contains the most important features identified by the stakeholders. Out of the 12 modules, 7 have the highest priority. They are, Report, Dashboard, Issue Tracking, Work Order, Admin, Email, Discussion Thread, File Attachment and Audit Trail. The Use Cases for these modules can be found in section 3.3. Once Version 1 has been implemented, the system should stay in a steady state for a period of time to measure any deficiencies or issues within the modules. Any outstanding items should be forwarded to change control for proper identification and remediation. Once Version 1 has met the stakeholders’ expectations, development and deployment of Version 2 can begin. Version 2 contains the Security, Priority, and Web modules. After Version 2 has met the


stakeholders’ expectations Version 3 can be developed. Version 3 consists of the following modules: Date/Time Translator, VM, Test Case, and Automation and Duplication modules.

Figure 2. Internal view of Home-grown Issue Tracking System

2. 3 Feature Overview This section provides a high-level overview of the system features, allowing the reader to understand the activities that the system provides users with. FEA1: Provide enhanced reporting tools that include templates, auto generated reports, manual reports and a running dashboard for up to the minute reporting statistics. FEA2: Browser-based module for access, system administration and the ability to work offline. FEA3: ACL for enhanced security and individualized work order view based on login credentials, user defined fields, field-level security, along with customizable forms, and form-level audit trail and change history. FEA4: Auto-generate work order number, display manual percent complete indicator, fully searchable knowledge base, and duplicate issue search tracker. FEA5: Report issues by email, parse data from emails and convert them to a ticket, configure email reminders and triggers, and receive status updates, ticket related correspondence and inactivity notifications. FEA6: Detailed discussion view thread and the ability to attach files to related ticket.


FEA7: Tracking mechanism to monitor ticket from submission to completion along with the ability to bill time to each ticket and disseminate approval requests. FEA8: Close or change ticket status based on pre-defined criteria, create customized views based on credentials, and customizable systems options based on preferences. FEA9: Add (new and templated) and edit issues, descriptions, priority, ownership and reopen issues. Generate test cases from resolved issue. FEA10: View test phases, ticket progress, ownership of test modules, and allow customers to track their own issues. FEA11: Auto assign issues to individuals or groups based on pre-defined criteria and convert time to local time zone of logged in user based on user profile and settings.

3. SYSTEM USE This section discusses an overview of the functionality that is supported by the system, based on multiple user perspectives. It presents the reader with user workflows, user roles, the business use case diagram, system events, and the system interfaces, via diagrams and text. 3.1 Support for User Workflows The swimlane diagram details the different user roles and their interactions with the system. In the first swim lane, Production, Sales, and the Customer is defined. In this lane the stakeholders can open, view, and reopen issues along with the ability to track their issues. This lane begins the process of identifying, recording, and submitting an issue. Once an issue has been opened or reopened the third lane is involved. The issue generates a work order that is used by the Development/QA team. From the first lane an issue or a range of issues can be searched which involves Knowledge Management in the second swimlane. From the second lane reports can be generated. The Development/QA team works within their lane to create a test case in order to resolve the issue. In addition to creating the test environment, they can research the issue by crossing into the second swimlane to search the knowledge base and they can run reports for additional analysis. Once the Development/QA team resolves the issue, a fix can be implemented and the work order is closed. Once the work order is closed the issue owner in the first lane is notified of the resolution. The fourth swimlane is owned by the System Administrator. While changes to the system can impact the other lanes, the fourth swimlane is not involved in the issue process.


Figure 3. Swimlane Diagram depicting user workflows

3.2 Actor Survey This section serves to provide a description of the actors who will be involved with using the system or who have an interest in its implementation. They will be described by user roles, which characterize the activities and responsibilities of the individual or group of people in a team. We will discuss the actions that the individual(s) within the specified roles will perform with respect to a set of unified activities, and we will demonstrate the work products that they will supply. In short, this sections shows who does what, how, and when with respect to the system. Role: Customers Customers of PTI and its partners are typically the leading users of the current issue tracking system and are anticipated to be so for the new system as well. Their intentions of interaction are to submit issues/errors/defects that they come across when using PTI software and need resolution. They must be able to submit supporting documents, screenshots, log files, etc. so that enough details are provided to enable the issue to be resolved in a timely manner. When an issue is submitted, a ticket should be automatically created and tracked and a confirmation email sent to both the customer and PTI for reference. In addition, customers should have the ability to search a knowledge base of information so that they can attempt to resolve issues on their own and to limit the number of duplicate reported errors. One unique aspect of


customers is that they are globally located and, therefore, language barriers must be taken into consideration and it may be helpful to support multiple language packs. Role: PTI Salespeople and Partners Although they work for PTI, these individuals do not have direct daily contact with development/testing/QA and must also have a means by which to report issues. Hopefully these will be encountered before a sales call, if at all, although the content is created by others and their use is strictly during sales presentations. Similar outcomes as customers should be expected, although additional features such as private notes can be implemented for further discussion that should not be seen by the public. Role: Account Managers PTI’s account managers are employed to act as liaisons between the company and its customers, keeping them happy when they are dissatisfied, needs arise, or a plan of action for implementation and usage of the software is necessary. Therefore, being a part of the issue tracking process helps them to do so by allowing them to understand the issue from the start and to negotiate a process of customer service. They will want to be able to be notified when an issue of concern to them is reported and should be able to run automated and manual reports based on specified criteria. In addition, they should have the ability to report an issue on the customers’ behalf and to access private information about the issue that the customer should not see. Role: Application Consultants These team members are forwarded issues in which they have expertise so that they may provide advice and attempt to solve the problem from its inception. In addition, when the problem submitted is too big to be handled by typical discussion but is not due to a defect in the software, an application consultant may be called upon to walk the customer through to a solution for an additional fee for service. Therefore, they must keep a careful eye on the issue tracking system at all times and should be provided with automatic notification of a pending issue. In addition, reports should be run on a regular basis to ensure that every issue is being properly handled, and the application consultants should be provided with specialized reports of their own particular cases. Since their jobs may be difficult and time-consuming, being supplied with only the issues they are responsible for would be beneficial. Also, the ability to write personal notes as well as private and public ones to the internal staff and customers, respectively, should be provided. Role: Product Managers The product managers are concerned with enhancement requests and the number of issues reported. They should have the ability to track these separately or in conjunction, and should be able to run various levels of reports to maintain integrity. Their concern is to guide the product’s vision and help determine which issues are of high importance, and they must have a means of segregating issues or organizing them into various constructs. The system should also facilitate communication between the product managers and developers, allowing them to write notes, keep track of conversations, and prioritize and plan requirements and goals. In addition, they should have the authority to submit and maintain knowledge base articles for the public interest.


Role: Developers Developers rarely currently use the issue tracking system but the new one should also come with a change in business processes to encourage their participation. Since they are the ones who create, fix, modify, and enhance the software, they should be informed of any true software defects which need a resolution. Therefore, they should not receive every issue that comes through the system, but should have a filter that sorts what have been deemed as defects by the product managers and application consultants. They should also be provided with an additional list of product enhancements as determined to be necessary by the product managers. In addition, communication and work order submission and tracking should be enhanced with respect to the testers and other developers. Internal collaboration should also be facilitated so that modules can be created, modified, shared, and discussed, and all of the above aspects will need to be able to be sorted and organized as appropriate. Role: Testers Again, the software testers do not use the issue tracking system either, but should work this into their daily processes alongside the developers. The system should enhance communication and serve to log their interactions with developers for historical purposes, and defect reporting and tracking capabilities should be supplied. Internal communications should remain private, even apart from other employees such as salespeople so that future enhancements are not leaked. Accountability for issue testing and reporting should be made clear, and assignments should be provided here. In addition, their findings should also be sorted by the developers according to priority so that testers know whether an issue will be fixed, placed on hold for future versions, or ignored due to lack of importance. Role: System Administrator The system administrator for the issue tracking system is currently being filled by the third party software licenser but will be an important internal addition to the new system. This individual will serve to maintain the integrity of the system, administer and manage user accounts, and handle the knowledge base system and search capabilities. He or she will be involved in the administrative aspects of the system and will not directly access any of the material supplied within. It is important to ensure that the system is secure and that the correct people are given or denied access to confidential information in addition to issues being opened, tracked, closed, and archived accordingly. 3.3 Use-Case Model and System Events Figure 4 shows a diagram of the Use-Case Model. The diagram shows how the 7 new features in version 1 will solve PTI's current business needs. The model shows high level features and how these will be utilized within the whole company to improve the current product quality assurance process.


Figure 4. System Use-Case Diagram

The following table presents an event list, which defines the external triggers or workflow events that cause the system processing to occur. It demonstrates the essential aspects that the system provides from a business workflow perspective and relates to the swimlane diagram presented in figure 3 above, as well as the use cases outline in section 4.1 below.

Business Events System Action System Interactions (Inputs/Outputs)

System Admin Creates/Edits User Accounts

Creates new user and saves new user information or updates existing ones.

Enter new user details; Send email confirmation with login info to the new user; Send email with updates to an existing user.

System Admin Edits Knowledge Base System

New entries are saved into the system, referenced with existing knowledge for traceability, and made viewable to all users.

Enter new system information; Link new entries with existing ones.

User Reports/Edits Issue Creates a new issue record or edits an existing one and sends email to relevant users; Test case generation enabled.

Enter issue details; Add attachments; Send email notification to users; Exports issue details for test script generation.

User Browses Knowledge Base System

Performs searches based on chosen criteria and displays results.

Enter search criteria; Display personalized views based on user’s criteria and privileges.

User w/Managerial Privileges Manages

Performs user-specified searches and displays SDLC status results

Enter search criteria; Display results based on user-specified


Product Road Map related to issues/enhancements. criteria; Make changes to SDLC related issues; Send email notification to relevant users.

User w/Managerial Privileges Manages Work Load/Flow

Performs user-specified BI searches and makes changes project planning analysis.

Run BI searches; Display search results with project planning statistical analysis; Make changes to project planning tasks; Send email notification to relevant users.

3. 4 System Interfaces The following figure shows a model of the user-interface navigation for the Issue Tracking System. Looking at the diagram we can see that the system begins with the Login screen. Once the user logs in, s/he will be taken to the application main menu which has several options to choose from. Each selection will take the user to the selected module. Each module provides certain features that are logically grouped together. For example, the Reports Module has all features that have to do with generating reports (manual and automated reports). Some modules are subject to access rights and may not be visible to users who do not have these access rights. Sometimes a user may have partial access rights and, consequently, s/he will have a partial view of the selected module, meaning some menu selections will be visible (the ones s/he has access rights to) but not all. Additionally, the system is a menu-driven system which means that the user will have to drill down to get to the desired feature. Every step of the way, the user is presented with options to choose from, where applicable, until the desired feature is selected. This interface navigation diagram does not show all of the potential user interface functions, just those that will be released in version 1.0 of the Issue Tracking System.

Figure 5. User-interface navigation for the Home-grown Issue Tracking System


4. SPECIFIC REQUIREMENTS This section is geared towards the developer and system maintenance provider, and it outlines detailed technical and design guidance. It will present the system use cases, functional specification, domain models, and non-functional requirements. 4.1 System Use-Cases Functional requirements identify the essential actions that must take place in the software product with regards to receiving and handling inputs and processing and producing outputs. These will be defined in the following set of use cases. Use Case 1: Create and Access Reports

Customers

PTI Salespeople

Account Managers

Product Managers

Developers

Testers

Select Report Menu

Select New Report

Select ReportTemplate

Select DashboardReport

Display ReportEnter ReportCriteria

«uses»

«uses»

«uses»

«uses» «uses»

«uses»

«uses»

«uses»

«uses»

«uses»

«uses»

«uses»

«uses»

Figure 6. UC1: Create and Access Reports Use Case Diagram


Use-case name UC1: Create and Access Reports System or subsystem Issue Tracking System Actors All Users* Brief Description This use case explains how a user can create a report, access a report or view

report in the Issue Tracking System. Basic flow of events Basic flow begins when a user needs to create or view a report.

1. The system will present the user with the Main Menu screen. The Report option can be selected at anytime. 2. Once the Report option is selected the user can select from a menu of predefined reports, create a new report from a list of templates, or, if the user is upper management click on the Dashboard option. 3. When the user selects a predefined report the report will be loaded and the system will display the intended results. 4. When the user selects ‘New Report’ a list of report templates are revealed. The user can select a template then enter in the report criteria by choosing the subject matter from a series of drop-down fields. When the user clicks Submit the report will be loaded and the system will display the intended results. 5. When upper management enters the report module a selection for ‘Dashboard’ will appear. Clicking on the ‘Dashboard’ will reveal a high level-report showing various statistics concerning the issues in the database.

Alternative flow of events If the user wants to change the look of the report, s/he can: 1. Right-click on the graphic to choose another display format.

If the user wants to see the details of the report: 1. They need to have the proper credentials. 2. Clicking on any of the results graphics will return a list of issues that make up the report. 3. The user can click on the issue for a more detailed analysis.

Special requirements Usability: The current UI has been rated by users as easy to use. Thus, the new

system will not change the current UI in order to keep change/training management process to the minimum. Performance: The system will return process (failure/success) messages in ≤ 5 sec. Security: The connection to the Issue Tracking System is session based. The system will prompt user when the current session is about to be closed after 5 mins of idle time.

Pre-conditions The user has to have valid login information (UserID and Password) for the Issue Tracking System and be logged in.

Post-condition(s) After successful report submission, the system will display the appropriate report.

Notes *Subject to user security privileges. All users will be able to run predefined reports and have access to the report templates. Only upper management will have access to the dashboard. All users, except Customers, will have the ability to access the detailed issues that make up the report.


Use Case 2: Add/Edit Issue

Figure 7. UC2: Add/Edit Issue Use Case Diagram


Use-case name UC2: Add/Edit Issue System or subsystem Issue Tracking System Actors All Users* Brief Description This use case explains how a user can report a new issue or make changes to an

existing one in the Issue Tracking System. Basic flow of events Basic flow begins when a user needs to report an issue with the software

product in question. 1. The system will present the user with the Main Menu screen with the Issue Tracking option as one of the main options. 2. After the user chooses the Issue Tracking option, the system will present a form to be filled out about the issue e.g. product, version, module, description/steps for reproduction, attachments, owner, etc. 3. When the user submits the issue, the system will check for the minimal information input requirements and prompt the user to complete the form. 4. Once the form is completed, the user will submit the issue and the system will make a new issue record in the Issue Tracking database. 5. The system will display a submission confirmation message and details of the issue submitted. 6. The system will send an email trigger to notify the user and the new owner of this record/change.

Alternative flow of events If the user finds a related issue during the initial Knowledge based search, s/he can: a. Reopen a closed issue;

a. The system will provide an alternative to reopen a previously closed issue.

b. The editing will be allowed based on user privileges.* b. Edit an open issue;

a. The editing will be allowed based on user privileges.* c. Template a similar issue.

a. The system will display a pre-populated Issue Tracking form, and will follow the basic flow of events 1-5.

Special requirements Usability: The current UI has been rated by users as easy to use. Thus, the new system will not change the current UI in order to keep change/training management process to the minimum. Performance: The system will return process (failure/success) messages in ≤ 5 sec. Security: The connection to the Issue Tracking System is session based. The system will prompt user when the current session is about to be closed after 5 mins of idle time.

Pre-conditions The user has to have valid login information (UserID and Password) for the Issue Tracking System and be logged in.

Post-condition(s) After successful issue submission, the system will display a confirmation message with issue details, and email messages will be sent to the user and the new owner. The users will now be able to search for this issue and track its progress based on its IssueID.

Extension points The desired issue reporting process will have the user first search the Knowledge Based System for similar issues before reporting a new one in an attempt to reduce reporting duplication occurrences. The Knowledge Based System search will be described in a separate Use Case. All shaded events in the model are parts of a different Use case, and will be described appropriately.

Notes *Subject to user security privileges. All users will be able to Add New Issue and Add Notes to an existing issue. Only selected users will be able to Edit Issue details after the initial submission. The edit Issue privilege will be restricted to


the internal users and exclusive to Development/QA, C-Level/Product/Project Managers, and System Administrator. Application Consultant/Sales Force, and Customers will have the ability to Add Notes.

Use Case 3: Report Issue by Email

Figure 8. UC3: Report Issue by Email Use Case Diagram

Use-case name UC3: Report Issue by Email Actors Customer Brief Description This use case explains how a customer can report an issue by email and track it. If a

similar issue exists, no new ticket will be opened; rather, the information provided by the customer will be logged in the existing ticket.

Flow of events The flow of events begins when a customer discovers an issue and wants to report it by email.

1.The customer uses the issue tracking system’s email to report the issue. The system recognizes who the user is from the login information. 2. The customer populates the email issue description and the type of issue (system crashing, corrupted data, inaccessible menu, etc.) 3. The system parses the email, extracting the necessary information from it. 4. The system uses this information to search for similar open issues. 5. If a similar issue is found, the system logs the information received from the customer into the existing open ticket. 6. Otherwise, the system creates a new ticket, logging the issue’s details in it.


7. Once a new ticket is created or an existing ticket is updated, the system will send email notification to all stakeholders 8. The system determines the stakeholders. 9. The system notifies all stakeholders (based on their user email notification preferences). 10.The issue reporter will be notified whether a new ticket was opened or an open ticket with the issue was updated. In either case, the customer receives the ticket number (id).

Alternative flow of events The customer wants to track the reported issue 1. The customer selects the track issue function. S/he will be brought to the knowledge base screen. The customer view is limited to tickets related to his firm or tickets shared with other firms (more than one firm having the same issue). 2. The customer selects to view ticket by number (id). The customer can also choose to view tickets requested or updated by his firm or himself. 3. The customer enters ticket number. 4. The system validates the ticket number and loads the ticket. 5. The customer is able to view his/her notifications settings and change them. The customer can also update the ticket’s log with new information, or questions.

Pre-conditions The customer is logged into issueTrak and at the main menu screen. Post-condition(s) The user’s selected action is completed and a success message is displayed, or was

not completed and an error message is shown to the customer and the system awaits further user input.

Special requirements Usability: The system will provide clear and intuitive menus that are not cluttered with many options. The system will provide status messages while the user is navigating the system that make it clear to the user what is happening at any particular moment. For example, if the user chooses a search option and search is taking long time to retrieve the data, the system will display a message such as “searching … too many results found … this may take a minute or two … please wait!” Additionally, when certain option fails, the system will display a message indicating what failed and how to work-around the issue (if there is a work around) and a contact # to ask for help/report the issue. Hovering with mouse over a menu item there will be description of what that menu item is and how to use it. Performance: For navigating the system, actions such as jumping from one menu to another and loading that menu’s items, should take less than 5 seconds. In terms of knowledge base searches and reports, the time it takes to access the search results may vary depending on the number of records in the db. Some searches may require a long time to compile the results (30 seconds to 3 minutes) in such situations the results can be compiled and emailed to the user based on the user preferences (the user will be given the option to wait for results or select “email me the results”, or save the results to local machine) Reliability: The system will create a restore-point after each issue entry. If an error is encountered, the system will roll back to the previous restore-point, then return control to the user.


Use-Case 4: Use Audit Trail

Figure 9. UC4: Use Audit Trail Use Case Diagram

Use-case name UC4: Use Audit Trail Actors Admin/internal user Brief Description This use case explains how an admin or internal user can use audit trail to view historical

changes to certain ticket(s). Access is based on credentials of the user. The user may be an admin where he has an unlimited view, or may be a regular user; s/he can view own tickets or own private fields, etc.

Flow of events The flow of events begins when the user wants to track historical changes to certain fields.

1. The user selects the audit trail feature from the issue tracking system main menu. 2. A list of options to choose from is displayed. 3. The user selects an option:

a. Search for tickets that matches certain criteria or b. The user has a specific ticket id that s/he wants to look up 4. The user selects the desired ticket. 5. The system based on login information determines the user views. 6. If the user is does not have the access rights, the system informs the user that s/he

does not have sufficient access rights to view the ticket along with information on who to contact to obtain such access rights.

7. Otherwise, the ticket is displayed. 8. The user selects the type of view s/he wants: a. General view (public fields)

Historical changes are displayed b. Private view (private fields)

If the user has sufficient access rights the historical changes are displayed. Otherwise, a system message is displayed informing the user of not having sufficient access rights for this view

9. Once done, the user can select to go back to the main menu


Pre-conditions The user is logged into IssueTrak and at the main menu screen. Post-condition(s) The user selected action is completed and success message displayed, or was not

completed and a warning message is displayed informing the user that s/he does not have sufficient access rights and the system awaits further user input.

Use Case 5: Generate Work Order

Figure 10. UC5: Generate Work Order Use Case Diagram

Use-case name UC5: Generate Work Order System or subsystem Issue Tracking System

Work Order module, discussion thread module, and file attachment module Actors All Users* Brief Description This use case describes how a work order is generated and users can participate in

the discussion thread of a submitted issue and attach files. Basic flow of events The basic flow begins when a user reports an issue, or reopens an issue, or

navigates to an already submitted issue in regards to the software product in question. 1. The system takes the contents of the submitted issue and generates a Work Order. 2. The Work Order is submitted to the management team who decides to which

Developer/QA team to assign it based on the credentials of the issue and team availability.

3. The Develpment/QA team selects the Work Order for review. 4. The Developer provides a fix for the issue. 5. The Development/QA team create a test case for the issue. 6. The Development/QA team create and distribute the virtual machine. 7. Files that are necessary for testing can be attached. 8. The user chooses the option to view details and open discussion thread. 9. The system presents the user with the submitted information, including the date

and time, owner, module, affected users, problem experienced and


description/steps for reproduction, etc. A list of responses is shown with regards to additional comments.

10. The user views the discussion thread by means of captions and short descriptions of up to 256 characters.

11. The user may initiate discussion by clicking the option to respond and posting his information.

12. The system will display a submission confirmation message and details of the issue submitted.

13. The system will send an email trigger to notify the user and anyone who previously posted to the thread of this record/change.

14. When he is finished, the user may log off or navigate to another page and the system shall respond accordingly.

Alternative flow of events 7a. If the user chooses to add an attachment: 1. The user clicks on the add attachment tree. 2. The system expands the tree to allow the user to type or search for the desired location of the attachment. 3. The user clicks okay. 4. The system refreshes the screen with the added attachment displayed

next to the thread. 10a. If the user chooses to view more information, he may click a section of the

thread, which will then present the user with a pop-up detailing the rest of the discussion post.

Special requirements Usability: The system shall follow the same UI conventions as was already implemented for the issue submission. Any further learning to find the discussion thread and learn how to participate should take under 1 minute for 95% of users. Performance: The system will return process (failure/success) messages in ≤ 5 sec. Security: The connection to the Issue Tracking System is session based. The system will prompt user when the current session is about to be closed after 5 mins of idle time. Also, users should only be presented with issues that they are privileged to view according to their login credentials.

Pre-conditions The user has logged in to the Issue Tracking System and browsed or searched for an issue of interest.

Post-condition(s) After successful submission, the system will display a confirmation message with issue details, and email messages will be sent to the user and anyone involved in the thread, in addition to the PTI staff in charge. Attachments will be available for all users with access to the issue to view and/or download.

Notes

*Subject to user security privileges. A user will be able to access his/her own submitted issue and those which have been submitted to the knowledge base, but should not have access to other users’ issues as they may contain confidential and proprietary information. Systems administrators and PTI staff should have access to all issues and should be able to share private notes between them that traditional users will not see.


Use Case 6: System Administration

Figure 11. UC6: System Administration Use Case Diagram

Use-case name UC6: System Administration System or subsystem Issue Tracking System Actors System Administrator Brief Description This use case explains how an user with system administration

privileges can create new user account and manage knowledge base. Basic flow of events Basic flow begins when a system administrator need to add a new user

into the system: 1. The system will present user with the Main Menu with a. Add New

User and b. Manage KB as the two main options. 2a. After the admin chooses Add New User option, the system will

present the screen with fields to be filled out with required user information such as: name, emploee#, department, role, access privileges.

3a. When the admin submits the request for the new user account, the system will check the information input for completeness, accuracy, and minimal security requirements (e.g. password strenght).

4a. Upon successful information check completion, the new user account will be created in the database.

5a. The system will display a conformation message and the new account details.

6a. The system will send an email notification with account login information to the new user.

2b. After the admin chooses Manage KB option, the system will present the Search KB screen and options to Edit or Add New Record into the KB.

3b. After the admin chooses Add New Record, the system presents a screen with required fields to be filled out about the records, traceability option to relate issues and current KB records, and attachments.


4b. When the admin submits the new record, the system will check the information input for completeness, and upon successful submission, a new KB records will be created in the database.

Alternative flow of events 2b. After the admin chooses Manage KB option, the system will present the Search KB screen and options to Edit or Add New Record into the KB. i. If the admin chooses to edit record, s/he will select an existing record from the KB search results and choose the Edit Record option.

3b i. The system opens the chosen record in an editable screen. 4b i. After the changes have been made, the admin submits the changes into the KB.

ii. Alternatively, the admin amy choose to Delete the record from the Edit screen, in which case the record will be archived (soft delete).

Special requirements Access: The current Issue Tracking System is managed by the third party vendor. This role will be internal to the PTI company and will have the same level of access as the current system administrator. Usability: The current UI has been rated by users as easy to use. Thus, the new system will not change the current UI in order to keep change/training management process to the minimum. Performance: The system will return process (failure/success) messages in ≤ 5 sec. Security: The connection to the Issue Tracking System is session based. The system will prompt user when the current session is about to be closed after 5 mins of idle time.

Pre-conditions The user is logged into the system with valid system administrator credentials.

Post-condition(s) a. After successful Add new User request submission, the system will display a conformation message with the new account details, and an email with the account login inforamtion will be sent to the new user. b. The new record will be searchable in the KB system. Alternatively, the record will no longer appera in the KB search results.

4.2 System Functional Specification This section provides an overview of the high-level functional processes required for the system. These are categorized by software product component

Figure 12. Version 1 System Module


User Interface Functions UIF1: User login and authorization; main menu screen (system recognizes Admin/user) UIF2: Main menu screen (visible menu items are dependent on login access rights) UIF3: Reports screen UIF4: Dashboard screen (access rights based on organizational membership hierarchy) UIF5: Issue tracking screen UIF6: Work order screen UIF7: System Administration and management screen (Visible only to admins) UIF8: Email configuration screen (users can configure their own email preferences) UIF9: Audit trail screen (user can lookup ticket’s change history) Server Application Modules Reports RPT1: Allows users to run & print reports (some reports are subject to access rights) RPT2: Allows users to configure/customize his/her reports (includes setting and automating reports to be emailed periodically) RPT3: Allows user to generate graphs/charts based on reports Dashboard DSHB1: Allows dashboard user to customize personal settings (views based on access rights) DSHB2: Allows user to run drill up/down by department, group, customer, region, dates, etc. DSHB3 Allows user to generate graphs/charts based on the view information Issue Tracking ITRK1: Allows user to enter new issue ITRK2: Allows user to edit existing issue ITRK3: Allows user to set priority for an issue ITRK4: Allows user to discuss issues through discussion threads ITRK5: Allows user to attach files to discussions threads ITRK6: Allows user to attach files to ticket of an issue Work Order WRKO1: Allows user to view work order tickets for allocated VMs WRKO2: Allows user to generate a work order ticket to allocate VMs WRKO3: Allows user view work order tickets that generated specific test cases WRKO4: Allows user to generate work order tickets for test cases WRKO5: Allows user to attach files to work order tickets WRKO6: Allows user to link discussion threads to work order tickets


Administration ADMN1: Allows admin to view users security settings ADMN2: Allows admin to set users’ access rights ADMN3: Allows admin to create add-hoc fields in DB ADMN4: Allows admin to set access rights to add-hoc fields Knowledge Management KMGT1: Allows user to create custom searches KMGT2: Allows user to run searches (user can search work order tickets, issues, discussion threads, etc.) KMGT3: Allows user copy search and share searches Email Configuration EML1: Allows user to configure his/her personal email settings (when to receive emails which events of interest that would trigger email alerts, etc) EML2: Allows admin to configure certain user settings EML3: Allows admin to configure general email settings & automated alerts triggers Audit Trail AUDT1: Allows user to view changes history (certain views require access rights) 4.3 System Domain Models

4.3.1 Internal Domain Model The Data Flow Diagram (DFD) shown in Figure 13 represents data inputs and outputs within the future issue tracking system, as well as processes that control storage and activities that foster reusage of data and eliminate storage and process redundancy. The DFD outlines seven major processes, numbering them in a logical data flow order and not by the importance of the data source or storage. These are as following: 1. Search Knowledge Base (KB) is the first data process that any user will encounter when utilizing the issue tracking system. The main input data source for this process will be the KB repository (1.1D) established by the Add Issue into KB process (1.1). Additionally, the Search KB process will have the ability to pull data from the current issue tracking database (2D). The cross-referenced outputs from this search will give the basis for the run result process (5) explained below. 2. Create Issue is the single most important data input process within the issue tracking system. The process is home for the original data collection and storage around reported product issues. It is mostly the collection process of data with a goal of gathering as much information about an issue as collectively required by all the other processes within the


system. The collected data will be stored into an issue repository (2D), which will serve as a main repository of data for many other processes depicted in the DFD below. 3. Send Email Notification is a process that will integrate the email system currently used in house with the issue tracking system processes resulting in a comprehensive notification system that supports high collaboration and communication standards. The process will offer optional predefined user group configuration (3.1) stored in its own data repository for ease of access (3D). The process will offer automated as well as manual ad hoc configuration of notification content. 4. Add User w/Specified Privileges is a process utilized by the System Administrator that allows creation of new user accounts. This is a second level process within the system providing significant support to the issue tracking systemem but not directly participating in the issue tracking data flow. 5. Run Reports process will be pulling data from the KB (1.1D) and Issues (2D) repositories to create user-specified reports of current and past issues. The cross-referenced results may be saved in the reports repository (5D), which will serve as an input data source for running dashboards (6). 6. Establish Dashboard process will use the Reports repository (5D) as its main data input source and will so enable users with relevant privileges to create high level information visualization extracts and use them as a business decision support tool. 7. Create Work Order is a data process that ties to the Create Issue process. It is also a work flow process and, as such, solves the business need for work assignment and ownership delegation.


Figure 13. Internal Domain Model

4.3.2 Data Models Figure 14 represents a high level Entity Relationship Diagram (ERD) with only primary keys (identifiers) specified for all entities. Some relevant attributes have been listed in the entities' description below. The list of mentioned attributes is not exclusive and will be appended and analyzed in a separate database analysis and design document. The entities depicted in this diagram relate to the data repositories outlined in the DFD in 4.3.1 section in the following manner: Knowledge Base = Issue Added to KB (1.1D); The Knowledge Base entity will have a KB EntryID recorded in the database as its primary key. This will be a system-generated record number that will tie an issue to the KB database, but will still ensure the appropriate content display during KB search. This will be important in case of reopened issues and enable traceability of a KB entity to multiple related issues. Issue = IssueID Established (2D); The Issue entity will have an IssueID recorded in the database as it primary key and it will be assigned to the entity by the issue tracking system. The input data that will be required to be entered by a user and saved as attributes


associated with it will include following: title, description, product name, version, date/time entered, date/time altered, notes, etc. Email Groups = Notification Settings Saved (3D); The Email Groups entity will use data from the email system and save it under a new Group Name. Other attributes of this entity will include Group Name, which will serve as its primary key and be required upon group creation. User = UserID Established (4D); The user entity will have UserID established upon a new account creation. Other attributes associated with this entity will be the user's name, role, and privileges. Report = Reports Saved (5D); The Reports entity will be saving reports under the Report# primary key. The entity will provide data for dashboard generation. Order = Work Order Saved (7D); The Work Order entity will have a WO# attached to it as its primary key, and Issue#, date, owner(s) as its other attributes.

Figure 14. Data Model


4.4 Non-Functional Requirements This section provides us with the non-functional requirements of the new home-grown issue tracking system for PTI. They will serve to define how the system should operate and what it should be, as opposed to the behaviors of the system and what it should do. The requirements are broken down into separate sections for ease of review.

4.4.1 Usability This section includes the requirements related to usability, or ease of use. NFR-1 The system shall follow the conventions used in the current user interface so as to

provide for continuity and ease of use. NFR-2 The system shall provide for ease of use, such that 95% of all new users should learn

the basics of navigation in under five minutes. NFR-2.1 Power users should become proficient in the system in under 15 minutes.

NFR-3 Once familiar with navigation, users should be able to submit or find issues in under three minutes, taking into account time for inputting information and/or searching.

NFR-4 The system shall include a help feature located on every page. NFR-4.1 When clicked on, the help link should open a new page and start with the topic

corresponding to the page the user navigated from. NFR-5 The system should follow best practices for web site creation and usage (eg.

standard fonts, colors, navigation, etc.) NFR-6 The system shall integrate seamlessly with internal and external architecture. NFR-7 The system shall only present users with information/options that they are

authorized to see to avoid information leakage, reduce clutter, and enhance ease of use.

4.4.2 Reliability The reliability of the system relates to how it needs to act so that it is acceptable to the user community. It discusses the likelihood of an error-free environment for a distinct amount of time. NFR-8 The issue reporting, tracking, and managing features, along with use of the

knowledge base must be available 100% of the time when not being serviced. This is due to the fact that PTI is a global company and customers will access it across multiple time zones.

NFR-8.1 Work Order and VM assignment modules must be functional 100% of the time between the hours of 6am and midnight Eastern Standard Time (U.S.).

While it would be beneficial for it to always work, access between midnight and 6am is not likely. NFR-9 Access for necessary maintenance should be made available between midnight and

6am Friday through Sunday. An email confirmation should be sent to users prior to any planned system outage.

NFR-10 “Mean time to repair” should be 20 minutes for noncritical errors and 2 hours for critical ones 95% of the time. This should ensure the restoration of complete functionality.


4.4.3 Performance System performance is discussed here and relates to the speed and ability of system operation under a given workload. NFR-11 The site shall load in under two seconds on average and under five seconds

maximum. This is assuming modern technology is used to access the site (eg. high-speed modem, at least 1GB RAM, etc.)

NFR-12 The system shall respond to a search query within two seconds on average and five seconds maximum assuming modern technology is used as above in NFR-11.

NFR-13 The system shall handle a maximum of 1000 requests per second. NFR-14 The system shall handle a maximum of 1000 simultaneous users. NFR-15 The system will return process (failure/success) messages in ≤ 5 sec. 4.4.4 Supportability The creation of the system will take place over three phases. The first phase will include all of the basic functions of the system including searching, reporting, and tracking, in addition to knowledge base material. These should be modeled in such a way that additional features can be seamlessly added, including the priority and audit trail modules in version 2 and the Dashboard, discussion thread, VM and test case modules, etc. in version 3. All of the enhancements and implementations across the three versions can be reviewed in section 2.2.2 above. Adding these extra features should still ensure continuity of use with no interruption and little additional learning obligations. NFR-16 Additional features should be learned in under 10 minutes and proficiency should

be achieved in under 20 minutes for 95% of users. 5. SUPPLEMENTARY REQUIREMENTS This section serves to provide information necessary to implement the system and is used mainly for developer and maintenance intentions. 5.1 Project management strategy Since the current project is founded upon an existing issue tracking system, there is little risk in implementation. A vast portion of the new system will still be hosted and maintained by a third party, while the new features are integrated by PTI. The risk involved is one of accurately meeting the user needs and seamlessly implementing the new product with the existing one. This will take place across three phases, first upgrading to a newer version of third party applications and adding additional PTI-produced features, and then strictly by incorporating additional aspects alongside them. One particular concern is going to be the communication between PTI and the third party, and the product managers must remain in contact to ensure timely releases and full compatibility. 5.2 Systems Security and Audit Since a portion of the system will be hosted by PTI, firewalls and data encryption should limit external access to the web server. For the system itself, usernames and passwords will be delegated and access privileges will be set depending on user needs and qualifications. This will limit the options that the user has when he is logged on, by hiding items that he does not have access to. Security auditing should be turned on and a security policy implemented.


SR-1 The system should allow for a superuser to control passwords and restrict access, in addition to maintaining information.

SR-2 Modern firewalls and data encryption to be implemented in order to limit connections to the web server.

SR-3 The system shall require authentication by means of username and password which will be delegated by the system administrator.

SR-3.1 The user’s password must be changed at first logon and must include at least one uppercase and one lowercase character in addition to at least one non-character-based symbol (eg. !@#$%_). The password must be between 6 and 16 characters.

SR-4 Access privileges should be able to be set by the system administrator based on user qualifications and predefined criteria, including needs-based access and job position.

SR-5 Audit trails must be enabled and a security policy implemented and followed. SR-6 The connection to the Issue Tracking System will be session based. The system will

prompt the user when the current session is about to be closed after 5 minutes of idle time.

SR-6.1 The user will have the ability to choose to remain active by clicking Ok in the resulting dialog box.

SR-6.2 If Ok is not selected within one minute, the system will log the user out and return him to the sign-in screen.

5.3 Assumptions and Dependencies There are few assumptions and dependencies that must be clarified outside of what has already been discussed. As has been stated, upper management backing is important, users must test and validate the system, and resources should be analyzed. Since this system relies on the existing one, we assume that the infrastructure should remain and additional features added. It is important, however, to allow room for growth, as new customers are added on a routine basis and the system must be able to support the workload. The user base is expected to increase from around 1000 current users to about an additional 100 users per year for the next 5 years, upon which the system will be reevaluated. 5.4 Requirements Traceability The following tables map the high-level features from section 2.3 to the use cases discussed in section 4.1. In addition, the use cases are then mapped to the non-functional requirements of section 4.4 and the supplementary requirements of section 5.

Key: FEAn is High-Level System Feature n (from section 2.3).

NFRn and SRn are Non-Functional or Supplementary requirements n (respectively) (from sections 4.4 and 5).


High-Level Features Mapped onto Use-Cases Feature UC1 UC2 UC3 UC4 UC5 UC6 FEA1: Provide enhanced reporting tools that include

templates, auto generated reports, manual reports and a running dashboard for up to the minute reporting statistics.

X X

FEA2: Browser-based module for access, system administration and the ability to work offline. X X

FEA3: ACL for enhanced security and individualized work order view based on login credentials, user defined fields, field-level security, along with customizable forms, and form-level audit trail and change history.

X X

FEA4: Auto-generate work order number, display manual percent complete indicator, fully searchable knowledge base, and duplicate issue search tracker.

X X

FEA5: Report issues by email, parse data from emails and convert them to a ticket, configure email reminders and triggers, and receive status updates, ticket related correspondence and inactivity notifications.

X

FEA6: Detailed discussion view thread and the ability to attach files to related ticket. X

FEA7: Tracking mechanism to monitor ticket from submission to completion along with the ability to bill time to each ticket and disseminate approval requests.

X

FEA8: Close or change ticket status based on pre-defined criteria, create customized views based on credentials, and customizable systems options based on preferences.

X

FEA9: Add (new and templated) and edit issues, descriptions, priority, ownership and reopen issues. Generate test cases from resolved issue.

X FEA10: View test phases, ticket progress, ownership

of test modules, and allow customers to track their own issues.

X FEA11: Auto assign issues to individuals or groups

based on pre-defined criteria and convert time to local time zone of logged in user based on user profile and settings.

X


Use-Cases Mapped Onto Non-Functional and Supplementary Requirements Use-Case NFR1 NFR2 NFR2.1 NFR3 NFR4 NFR4.1 NFR5 NFR6 NFR7 NFR8 NFR8.1 NFR9 UC1. Create and Access Reports X X X X X X X X X UC2. Add/Edit Issue X X X X X X X X X X UC3. Report Issue by Email X X X X X X X X X X UC4. Use Audit Trail X X X X X X X X X X UC5. Generate Work Order X X X X X X X X X X UC6.System Administration X X X X X X X X X

Use-Case NFR10 NFR11 NFR12 NFR13 NFR14 NFR15 NFR16 UC1. Create and Access Reports X X X X X X X UC2. Add/Edit Issue X X X X X X X UC3. Report Issue by Email X X X X X X UC4. Use Audit Trail X X X X X X UC5. Generate Work Order X X X X X X UC6.System Administration X X X X

Use-Case SR1 SR2 SR3 SR3.1 SR4 SR5 SR6 SR6.1 SR6.2 UC1. Create and Access Reports X X X X X X UC2. Add/Edit Issue X X X X X X UC3. Report Issue by Email X X X X X X UC4. Use Audit Trail X X X X X X X UC5. Generate Work Order X X X X X X UC6.System Administration X X X X X X


6. ONLINE USER DOCUMENTATION AND HELP SYSTEM REQUIREMENTS

Being that this system is based online, the user documentation and help system must also be contained on the web. It should provide users with the ability to search the various functions they have access to and should filter results according to user privileges. Basic training on how to use the features should be provided, along with descriptions of each. Screenshots of the features would also be helpful along with the descriptions. Training for the system will not be necessary, but users can refer to this guide for any particular questions or concerns related to using the knowledge base/issue tracking system. 7. DESIGN CONSTRAINTS Since this is an external system to the PTI software, there are no specific design constraints that limit the system at the moment. Universal access should be able to be provided from any web browser. 8. PURCHASED COMPONENTS There are no physical components which must be purchased, but a great portion of the system will be supplied and hosted by a third-party vendor. Access to the issue tracking system should be limited to those who qualify. In order to do so, the user has to pass PTI software certification by attending a three day course and completing three short assignments that demonstrate the user’s competence. In addition, issue tracking system licenses may be purchased for an additional fee. A username and password will be supplied and the password should be changed on login. 9. INTERFACES This section defines the interfaces that must be supported by the application. It should contain adequate specificity, protocols, ports and logical addresses, etc, so that the software can be developed and verified against the interface requirements. This section provides technical detail for the high-level view of these interfaces provided in section 2. 9.1 User Interfaces The user interface will be web-based and should provide ease of navigation with minimal need for clarification of use. Links must be clearly defined and main navigational elements should be provided on each page so that the user can easily retrace his steps or access core pages with one click. The interface should be consistent between web browsers and should support basic HTML, CSS, and Javascript, without interfering with outdated browsers. 9.2 Hardware Interfaces Since this is a web-based system there will be no hardware interface constraints. 9.3 Software Interfaces This is a self-contained application and does not directly interface with other software components.


9.4 Communications Interfaces The issue tracking system will be partially hosted by a third party and partially by PTI. Communications will be standard TCP/IP protocols and will be served by Windows 2003/2008 servers. 10. LICENSING REQUIREMENTS In order to use the software, participants must be licensed as stated in section 8 of this SRS. This is specifically for use of this system and PTI will not need to obtain any additional licenses themselves. 11. LEGAL, COPYRIGHT, AND OTHER NOTICES The documents contained within the knowledge base are provided strictly for general informational purposes. Use of the issue tracking system is at the risk of the participant and no warranties or responsibility will be claimed by PTI. All information contained therein is confidential and solely for the use of registered users and will be provided as-is, with no warranties and may be used only at the risk of the reader. All information will be subject to the terms and conditions of the PTI Authorized Business Partner Agreement and related addenda or the PTI Master Software License Agreement and related addenda. PTI, the PTI logo and PTI’s product names contained within the system are trademarks of PTI and may be registered in certain jurisdictions. 12. APPLICABLE STANDARDS No applicable standards currently exist.

software requirements specificational495/eport/docs/info627srs.pdfsoftware requirements...

Documents