alchemy task manager (atm) system requirements … · atm syrs document# atm-srs-01 version 1.3...

Alchemy Task Manager (ATM)

System Requirements Document

ATM SyRS Document# ATM-SRS-01

Version 1.3 12/7/2005

Page i

© Infusient LLC Confidential

Revision History

Date Version Description Author

11/12/01 1.0 Initial Draft Suat Evren

5/19/02 1.1 Incorporate BSS Enhancements John Koray

10/2/03 1.2 Alchemy Release 3.6 Suat Evren

03/15/05 1.3 Alchemy Release 4.0 Sarah Dogan


Version 1.3 12/7/2005

Page ii


Table of Contents 1.0 INTRODUCTION.......................................................................................................................... 1

1.1 SYSTEM PURPOSE......................................................................................................................... 1 1.2 DOCUMENT ASSUMPTIONS........................................................................................................... 1 1.3 SYSTEM SCOPE............................................................................................................................. 1 1.4 ACRONYMS AND DEFINITIONS ..................................................................................................... 2 1.5 REFERENCES ................................................................................................................................ 2

1.5.1 Infusient and ATM Documents ............................................................................................... 3 1.5.2 Standards and Guidelines....................................................................................................... 3

1.6 OVERVIEW ................................................................................................................................... 3 2.0 GENERAL SYSTEM DESCRIPTION........................................................................................ 3

2.1 SYSTEM CONTEXT........................................................................................................................ 3 2.2 MAJOR SYSTEM CAPABILITIES..................................................................................................... 4 2.3 SYSTEM CONSTRAINTS AND CONDITIONS .................................................................................... 7

2.3.1 Constraints ............................................................................................................................. 7 2.3.2 Conditions............................................................................................................................... 8

2.4 USER CHARACTERISTICS.............................................................................................................. 8 2.5 REQUIREMENTS CATEGORIZATION............................................................................................. 10

2.5.1 Functional............................................................................................................................. 10 2.5.2 Workflow............................................................................................................................... 11 2.5.3 User Interface ....................................................................................................................... 12 2.5.4 Data Interface....................................................................................................................... 12 2.5.5 Reporting .............................................................................................................................. 12 2.5.6 Infrastructure........................................................................................................................ 13 2.5.7 Security ................................................................................................................................. 13 2.5.8 Performance and Availability............................................................................................... 14

3.0 REQUIREMENTS LIST............................................................................................................. 14 FUNCTIONAL ............................................................................................................................................ 15 WORKFLOW.............................................................................................................................................. 18 USER INTERFACE...................................................................................................................................... 23 DATA INTERFACE ..................................................................................................................................... 26 REPORTING............................................................................................................................................... 27 INFRASTRUCTURE..................................................................................................................................... 28 SECURITY ................................................................................................................................................. 28 PERFORMANCE AND AVAILABILITY.......................................................................................................... 30

APPENDIX A: TASK ATTRIBUTES........................................................................................................ 1

APPENDIX B: REQUIREMENTS TABLES ............................................................................................ 1


Version 1.3 12/7/2005

Page iii


List of Tables

Table 1-1: Acronym List..................................................................................................... 2 Table B-1: ATM Availability Requirements ...................................................................... 1 Table B-2: ATM Sizing Requirements ............................................................................... 2 Table B-3: ATM System Performance Requirements ........................................................ 3


Version 1.3 12/7/2005

Page 1


ATM Requirements Document (RD) 1.0 Introduction

This Requirements Document (RD) defines the requirements for the Infusient’s Alchemy Task Manager (ATM) System . The primary audience of this document includes, but is not limited to, project leaders, the designers and developers of the system and existing/potential end users. This document follows the conventions of IEEE standard 830-1998 to help ensure that the requirements were well-formed.

1.1 System Purpose

The ATM solution provides a central repository for the management of all engineering deliverables that help organizations handle day-to-day management challenges while providing team leaders and company executives timely decision support visibility for strategic planning.

1.2 Document Assumptions

The following assumptions were made during the development of this document.

• Readers of this document are expected to have a basic knowledge of workflow and task management concepts. This knowledge will be necessary for the reader to understand the subject matter covered herein. Documents listed in Section 1.5, References, of this RD can provide information helpful in understanding the ATM project and the contents of this document.

• Sections 1.0 and 2.0 of this RD are provided as background and context information only. The actual requirements for ATM are listed in Section 3.0 and the tables referenced by Section 3.0.

1.3 System Scope

The scope of ATM includes all scheduled and unscheduled tasks that need to be tracked by customer’s organization and responsible task owner. Furthermore, when the term “tasks” is used it refers to any information that is available within the ATM system (required and optional task attributes, workflow definition and execution data, task change log, attachments etc.). The following statements help define ATM’s scope.

• ATM will create, schedule, assign and track tasks. • ATM will provide task attachments and a document repository with check-in,

check-out and versioning functionality. • ATM will capture full task change history. • ATM will provide a workflow execution environment compatible with WfMC

Workflow Reference Model.


Version 1.3 12/7/2005

Page 2


• ATM will perform automatic activity routing and approvals per the defined workflow.

• ATM will handle event notification/escalation via task and activity level triggers.

1.4 Acronyms and Definitions

Table 1-1, Acronym List, contains a list of acronyms relevant to this document.

Acronym Definition

ACL Access Control List ATM Alchemy Task Manager BPI Business Process Instruction CORBA Common Object Request Broker Architecture CSS Cascading Style Sheet COTS Commercial Off The Shelf DBI Database Interface DMS Document Management System EM Enterprise Metrics ERP Enterprise Resource Planning EV Earned Value GUI Graphical User Interface HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol ICR Initial Concept Review RD Requirements Document RDBMS Relational Data Base Management System SME Subject Matter Expert SOAP Simple Object Access Protocol SQL Structured Query Language SyRS System Requirements Specification W3C World Wide Web Consortium WfMC Workflow Management Consortium WMS Workflow Management System WRM Workflow Reference Model

Table 1-1: Acronym List

1.5 References

The standards, guidelines, and documentation used to develop this RD are described in the sections that follow.


Version 1.3 12/7/2005

Page 3


1.5.1 Infusient and ATM Documents

The following Infusient and ATM project documentation was used to support the generation of this document.

• ATM ICR Document • EM-SRS-02 Enterprise Metrics System Requirements Document

1.5.2 Standards and Guidelines

The standards and guidelines used in preparation of this document are listed below.

• WfMC-TC-1003 v1.1, Workflow Reference Model • WfMC-TC-1002 v2, Workflow Client API Specifications (WAPI) • IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements

Specifications • IEEE Std 1233-1998, IEEE Guide for Developing System Requirements

Specifications • W3C HTML 4.0 Specification • W3C HTTP 1.1 Specification

1.6 Overview

The RD was compiled from information gathered by ATM pilot project, the ATM ICR document, Enterprise Metrics requirements document, interviews with key customer Subject Matter Experts (SMEs), and concept notes written by members of the ATM project team. Requirements were defined and decomposed from those sources to create functional, performance, non-functional, behavioral, and informational requirements. Due to the wide range of sources for the requirements elicitation for this project, there is no way to directly link each requirement to its particular source. Requirements from these sources were combined, refined, and decomposed, and therefore, these requirements are an amalgamation of the work of the sources listed above.

2.0 General System Description

ATM will be an enterprise-wide system capable of supporting the lifecycle management process for engineering deliverable tasks. It will support automating the execution of these lifecycle management processes, and of capturing, managing, reporting, archiving and exporting of engineering deliverable tasks.

2.1 System Context

The ATM system will support target organizations’ lifecycle management process for engineering deliverable tasks. In addition, the system will be used to capture and manage


Version 1.3 12/7/2005

Page 4


any unscheduled, ad-hoc work packages requiring organization’s resources. The system will also support generation of engineering on-time delivery metrics at various organizational levels up to, and including, the enterprise view. For the purposes of this document, tasks are defined in a very broad sense to mean any unit of work that the enterprise allocates resources to and are responsible for timely delivery to their customers (internal or external). Typical tasks include, but are not limited to, specs, engineering designs, analysis or test documents, problem reports or enhancement requests. A task has a unique identifier, a type, an owner, a set of required and optional attributes that identify the responsible team or group, the performance period of the task, the current assignee and other schedule, cost, classification, collaborative and process related elements. Tasks may have an associated workflow instance that executes the relevant lifecycle process with required approvals, reviews, conditions and coordination (automated and manual). The system will provide comprehensive and coherent support for workflow, data management, role based data access and automatic or manual task routing based on resource groups. Collaboration at user, team and other levels of organization will be supported. ATM will be capable of interfacing with other applications throughout the enterprise using standard application interfaces and data exchange formats. The external interfaces and the method and means of each interface will be defined as part of customer’s implementation plan.

2.2 Major System Capabilities

ATM is envisioned as a comprehensive enterprise-caliber tool for complete task life-cycle management. As such, it will exhibit the system capabilities, qualities and characteristics listed below. For a more technical analysis of these capabilities, refer to Section 2.3 System Constraints and Conditions and Section 2.6 Requirements Categorization. Task Management: ATM should be first and foremost a task management tool that unifies organization’s goals (deliver product on-time and within budget, respond to customer’s needs), task owner’s personal objectives (complete task) and the value added artifacts generated as part of the process (part specs and drawings) under one framework. It shall present distinct perspectives of the same data for different organizational, structural and social contexts and their unique needs. It will provide for:

• Workbenches: What is pending, relevant, important? • Prioritization and Agenda Definition: What is in, what should be done next? • Experimentation: Simulation and “what if” • Organizational Analysis: How well are we doing? • Resource/Skills Management


Version 1.3 12/7/2005

Page 5


• Benchmarking and Cycle-time Analysis Workflow: The workflow system should be capable of supporting multiple different workflows, corresponding to the different lines of business, different procedures, and variety of tasks that groups/teams perform. There should be enough flexibility in the workflow management system to allow the workflow to be changed to accommodate exceptions or changes in the business processes. ATM will provide the capability to “customize” workflows on-the-fly to accommodate these changing business processes and exceptions. The following are some of the characteristics of the ATM WMS:

• Capture process definitions, related activities, resource requirements, stage transitions, routing rules and conditions in a workflow model.

• Provide event triggers to customize workflow execution based on internal and external conditions.

• Instantiate the correct workflow model based on task type, responsible team, organizational, contextual and other required criteria.

• Execute the workflow capturing application data, approvals and task attachments; perform automatic activity routing and resource selection.

• Handle exceptions, alarms, time-outs and notifications; modify the task workflow as-required.

• Collect performance and cycle-time data for iterative business process improvement.

• Expose the workflow engine API for interacting with other enterprise applications or scripting inter-organizational coordination.

Document Management: In the context of process modeling, documents are the essential artifacts, especially documents which initiate (i.e. Work Authorization) or terminate tasks (i.e. Engineering Drawing). Other related documents, so-called “passing through documents” (e.g. test results, analyses, problem reports) symbolize the value adding activities which finally produce terminating documents. Documents are first class information objects along with more structured information. Given the significance of document oriented flows beside functional activity oriented flows, ATM shall provide an integrated DMS with versioning, check-in, check-out, collaborative editing, publish-subscribe, categorization, keyword indexing and a document security model that complements task level ACLs. Collaboration and Groupware: The main scope of workflow systems has been the automation of formal procedures in the workplace. On the other hand, groupware and collaboration systems have addressed the informal aspects of organizational interactions. The formal versus informal separation is artificial and a cause of system ineffectiveness. Real work in real organizations is a mixture of both formal and informal processes. ATM should be designed to increase mutual awareness and provide seamless transition between support for formal organizational processes and informal group processes. No WMS can capture the exchanges of a group of engineers brainstorming on a problem, so


Version 1.3 12/7/2005

Page 6


the system should facilitate and encourage group interactions by providing them the tools of collaboration instead of throwing workflow road blocks in their path. ATM shall provide hooks to the WMS for capturing group interactions and customize the workflow on-the-fly. It shall provide native support for basic groupware technology (e-mail, messaging, discussions, notifications, alerts, watch lists, team portals etc.). It shall integrate with third-party end-user tools (e.g. Excel, MS-Project, Powerpoint etc.) to provide a collaborative workspace rich with alternative presentation options such as calendars, charts, graphs, outlines and schedules. Scheduling: ATM shall perform activity-level scheduling and allow flexible resource allocation methods (cost or workload based, round-robin, manual etc.). Tasks shall have scheduling attributes, such as plan, actual, baseline and need dates, to derive schedule metrics and forecasts. ATM shall also interface with third-party tools such as MS-Project to facilitate simulations and “what-if”’s.. Interoperability: A shared task support environment rarely, if ever, functions in isolation. As organizations become more dynamic, the workflow systems that support their goals cross departmental, infrastructure and technological lines. ATM should be capable of interfacing with other enterprise applications using standard application interfaces, data interface formats and database connectivity options. ATM shall expose its workflow engine API via CORBA or SOAP for external coordination and third-party customization as well as workflow scripting. The tool should also work with common desktop office productivity applications to enable alternative data extraction, analysis and presentation modes. Security: An individual task in ATM shall, presumably, go through multiple activity steps and stages representing various levels of organizational structure and decision making authority. A static security system based on screen access and rigid application roles could not be used to implement what is essentially a task oriented model for fine-grained and context-based access control and authorization. ATM shall implement a privilege based security model with the following characteristics:

• Controlled application functions will be associated with privileges (e.g. “Edit Task”, “Cancel Task”, “Create Attachment” etc.).

• Privileges will be granted to roles per ACL categories where ACL categories are defined in terms of attributes possessed by the subject (i.e. user) and the object (i.e. task). Examples of ACL categories are: “Owner”, “Assignee”, “Org Code” etc.

• The system administrator shall dynamically modify the security model by adding new roles or ACL categories without requiring changes to the application.

• Each user shall be assigned one or more roles which are combined to derive the user’s privilege/ACL matrix.


Version 1.3 12/7/2005

Page 7


• At run time, the system shall dynamically compare object’s attributes against the ACL held by the user and, for all matches, check the ACL matrix for the privilege requested. Access is granted if privilege is found, denied otherwise.

Traceability: ATM should capture full history of changes performed on tasks and their activities. The following attributes are required:

• The type of the change (“New Task”, “Task Updated”, “Activity Rejected”) • The transaction date • The user who initiated/performed the change • Old and new values of the task attributes impacted by the change

Additionally, ATM shall provide a repository for all messages, discussions and notes related to any given task by date and user.

Flexibility and Extensibility: As stated earlier, ATM is expected to support multiple groups with different process and data maintenance requirements. Hence, the system should incorporate the flexibility to substantially customize its business logic, user interface and data management rules based on the criteria defined by system administrator and user focals. Primarily the following extensibility and customization characteristics should be supported without changes to the application itself:

• Customize field labels, list of valid values, validation criteria and presentation formats for data entry, search and reporting screens.

• Define new task attributes as needed. • Specify the attributes required when creating a task, customize the attribute list

based on task type, responsible group or the workflow process used. • Customize the list of task attributes that can be edited based on task type,

responsible group or the workflow process used. • Customize the format, layout and sort criteria for standard reports, charts and

other presentation screens. • Customize the list of searchable task attributes and their layout. • Allow users customize ATM standard reports with their own layout and filtering

criteria. Provide a mechanism to save and share customized report definitions.

2.3 System Constraints and Conditions

This section identifies conditions and constraints that may impact the system architecture or specific components of the system.

2.3.1 Constraints

• The system shall provide a web interface for all its functionality. • The system shall utilize HTTP 1.1 and HTML 3.2 or later for client

communications and user interface.


Version 1.3 12/7/2005

Page 8


• The system may use other W3C standards such as CSS or Javascript as long as the client software’s level of, or lack of, support for the standard does not interfere with the primary operational purpose of the system.

• The system may use browser plug-in’s such as PDF or Flash provided that they are not essential to the primary operational purpose of the system.

• The system must not use ActiveX or similar technology that limits the client’s choice of hardware, operating system or browser software to a single platform or vendor.

• The system must not require installation and maintenance of any software modules, libraries or applications on the client’s machine other than a HTML 3.2 compatible browser and a network connection to the ATM server.

• The system shall utilize an RDBMS supported by Alchemy framework for all its task data storage and management.

• The system shall access and maintain all data in the database via a direct database connection using SQL. The system must not use any middleware, translator or any third-party software to manage its database interactions.

• The system may use SQL extensions and other functionality provided by the RDBMS vendor as long as such use is limited to less than ten (10) percent of the total system lines of code.

2.3.2 Conditions

• The system shall permit system administration activities (e.g. creating users, assigning roles, changing application configuration) without interrupting its application services. The administrative changes shall be effective without distrupting or restarting application services.

• The system shall provide an administrative API in a widely available scripting environment for automating or batch processing its administrative functions.

• The system shall use open standards and formats where they are available. • The system shall leverage existing Infusient solutions and infrastructure where it

is technically and financially feasible.

2.4 User Characteristics

The characteristics of ATM users will vary widely with respect to their knowledge of the tasks held by ATM, the functions performed by the user, the activities supported by the system, and their frequency of use of the system. ATM must provide a variety of user tools, workbenches, and help functionality to accommodate the needs of a very diverse user community. Main ATM user roles are listed below. These roles correspond to the default solution model delivered by Infusient. They can, and probably will, be modified as part of customer’s implementation plan:


Version 1.3 12/7/2005

Page 9


• Requester: Requester is the customer who initiated the task (via ATM or some other means outside the system). The requester specifies the need date, hence has control over changes to planned schedule.

• Team Leader: Team leaders are responsible for setting priorities and allocating resources for their own team, as such, they have budget authority over tasks and they work with requesters and task owners to lay out and manage an execution plan. Even though team leaders have authority over their own budgets and execution plan, they do not usually get involved in the day-to-day management and scheduling of individual tasks.

• Task Owner: Task owner has the ultimate responsibility over the successful delivery of a task. He monitors and manages the task as it moves through various stages in its life cycle. Task owner sets due date along with intermediate deadlines on each activity and communicates the expectations to the assignee(s). It is the task owner’s responsibility to capture deviations from the execution schedule and escalate as required.

• Assignee: Assignee is responsible for completing the current activity of the task as defined by the workflow and handing it to the next assignee in sequence. The assignee can choose to reject the task and send it to a previous activity if the workflow allows it.

• Workflow Modeler: Workflow modeler captures the existing manual business process and translates it to a set of interconnected activities along with starting and completion conditions, stage transitions and resource requirements. A completed workflow definition can be instantiated for a given task and executed by a workflow engine to facilitate/automate the corresponding business process.

• Administrator: Administrator is responsible for the overall configuration, customization and management of the system. Administrator will setup and manage user roles and privileges, adjust the look-and-feel of the application as needed, manage field and column attributes such as labels, list of values, field level access restrictions etc. Some of daily administration tasks such as creating and managing users can be delegated to a Help Desk function.

Aside from user roles; ATM defines a set of organizational roles that are primarily used to categorize and summarize tasks for decision support, strategic planning and metrics generation at various organizational levels. It is assumed that these organizational roles have an implicit hierarchy that is either defined in ATM or imported from other enterprise applications. It is also possible that the organization hierarchy is encoded in the data. Main ATM organizational roles are listed below:

• Team: The collaboration group responsible with delivering a set of tasks. Team members usually collaborate on team tasks and usually are pulled in from different organizations to achieve a specific objective.


Version 1.3 12/7/2005

Page 10


• Requesting Org: The organization responsible for the requirement that led to the creation of the task. This attribute usually, but not necessarily, refers to the Requester’s own organization.

• Responsible Org: The organization responsible for the successful delivery of the task. This attribute usually, but not necessarily, refers to the Task Owner’s own organization.

• Performing Org: The organization tasked for executing the task. Performing Org is usually the Responsible Org except when the task is outsourced to another (internal or external) organization.

2.5 Requirements Categorization

In this section, the requirements are summarized into categories based on IEEE Std 1233-1998. A brief description of each category, and a summary of the appropriate requirements, is presented in the following subsections.

2.5.1 Functional

This section covers the bulk of the user accessible functionality of the system. The primary operational purpose of the system is the management of engineering deliverable tasks. The system must support the lifecycle management process for engineering deliverable tasks. The ATM task lifecycle management process includes:

• Create new tasks • Manage task attributes • Associate tasks with the appropriate workflow • Assign tasks to individuals with the right skills to complete it • Promote workflow tasks via required and optional steps, collecting required

approvals, application data and documents at each step. • Capture task status along with changes in ownership, due date, percent complete

and priority • Put tasks on hold or cancel them • Attach notes, messages and documents to the task • Check-out, Check-in, lock, version control or otherwise manage documents in the

repository • Share documents in the repository among multiple tasks so that each task

automatically gets access to the latest release of the shared documents. • Capture the audit trail of all changes to tasks and related application data along

with any customizations of workflow instances • Search for tasks by any combination of task attributes selected and specified by

the users • Provide a mechanism to save the criteria for any search, so that users can re-

execute the search without retyping the search parameters.


Version 1.3 12/7/2005

Page 11


The system must support administrative functions required for on-going maintenance and management of the application. The following are the main administrative activities:

• Add, delete and configure users. Assign roles and privileges to users. • Add, delete and configure roles, teams and other supporting objects for the

system. • Add, configure and delete field attributes for task and other objects in the system. • Define and customize the parameters and defaults applicable to the whole

application (e.g. the default task report format, required attributes for each task type etc.).

• Define and customize any menus used by the application. • Start up and shut down the system.

The system must provide access to all administrative functions via its native interface (interactive) and via a common scripting environment for batch processing and automation.

2.5.2 Workflow

This section describes the business processes and their representation in the system’s integrated WMS. The primary function of WMS is to execute the task specific workflow instance and enforce the business rules, coordination and notification activities specified in the workflow. The WMS should conform to the WRM of WfMC with the following components and characteristics:

• Capture a process definition with its discrete activity steps, with associated computer and/or human operations and rules governing the progression of the process through various activity steps.

• Capture resource groups and participants by various selection criteria (individual, organization, team, role etc.)

• Capture the rules that define, qualify, restrict or otherwise specify the applicability of any process definition to a task.

• Instantiate a workflow by creating a task specific copy at task creation or at any point in task’s lifecycle.

• Provide a workflow control module (i.e. workflow engine) responsible for interpreting and executing the workflow and interacting with the system execution environment, application tools or human resources.

• Allow dynamic alterations to workflow at run-time based on external and internal input.

• Trigger, capture and respond to internal (workflow) and external (user-defined) events per the rules defined in the process model.

• Capture the audit trail of all changes to process models and the related activity steps including full history of each process enactment.


Version 1.3 12/7/2005

Page 12


2.5.3 User Interface

This section captures the main characteristics of the system’s user interface, its usability and visibility requirements, and alternative views of the data model. The system should provide the following user interface elements and features:

• Role based portals (i.e. task owner, team leader, org focal etc.), that summarize and present relevant ATM status and options

• Multi-level summary and drill-down by selected task attributes and criteria • Weekly and monthly calendars with task placement by selected date attributes

(e.g. due date, need date, complete date etc.) • Gannt Chart • On-time delivery metrics presented in various chart formats (bar, line, pie etc.) • User-defined reports and charts with option to drill-down to supporting data

2.5.4 Data Interface

The system shall also provide an API to all its task management functionality and workflow engine with following characteristics:

• Expose all task creation, maintenance and scheduling functions • Provide access to the workflow engine • Trigger and catch events, register handlers, and manage notifications • Make the system API available in one of cross-platform scripting languages • Provide a SOAP or CORBA plug-in for the API • Define an XML schema for the task data and provide a mechanism to export task

attributes in XML as a general purpose data interchange format

2.5.5 Reporting

This section covers the various reporting and data visibility requirements for the system. The system should maximize the value and utility of the data to the user by offering alternative data reporting and presentation options including:

• Change the filtering and sort criteria on all reports. • Customize existing reports by user selected columns and search criteria • Save and share custom reports – provide a mechanism to share/access custom

reports via e-mail and web pages • Export any report, including user defined reports, to Excel • Allow users request any report, including user defined reports, in PDF format for

printing and distribution • Provide a mechanism to summarize, slice and dice, and drill-down on task records • Create pivot tables and charts from task data per user specified dimensions and

filtering criteria


Version 1.3 12/7/2005

Page 13


• Export task records to MS-Project for further analysis, presentation or schedule simulations

• Generate a task summary form that includes all relevant data for any given task including history, attachments, workflow, and approvals. Make the form available in PDF for electronic or paper archiving.

• Drill-down on charts to detail charts or supporting data in real-time • Customize charts by changing chart type (bar, line, pie, radar etc.) and output

medium/format (i.e. Flash, PDF, GIF, PNG, Excel etc.) • Provide standard, canned reports for the following system objects:

o Tasks o Workflow Activities o History (task & workflow) o Timesheets o Attachments o Documents and document revision history

2.5.6 Infrastructure

The system should leverage and conform to Infusient supported IT infrastructure, utilize server components provided and supported by Alchemy framework architecture, and follow the infrastructure constraints specified in Section 2.3.1 Constraints.

2.5.7 Security

This section describes system security, user authentication/authorization, and transaction integrity requirements. The system should implement a security model based on roles and Access Control Lists (ACLs). The system should provide following security services:

• Authenticate users using unique login id and passwords. • Enforce customer’s standards for password validation and expiration • Provide LDAP integration for single sign-on • Authenticate user for each access to system • Support SSL for secured communication with users • Associate users with ACLs based on ACL categories (e.g. Owner Assignee, ..) • Allow system administrator define new ACL categories as dictated by the

business process • Define roles based on ACL categories and privileges supported by the application

logic • Grant one or more roles to users • Build a combined set of privileges and ACLs from all the roles assigned to the

user • Perform user authorization checks by matching target object’s ACL and the

privilege required with the ACL and privileges granted to the user • Perform user authorization for every restricted access to the target object(s)


Version 1.3 12/7/2005

Page 14


• Ensure login session and transaction integrity across requests • Support transaction and session timeouts and automatic reuse of session resources

and allocated objects

2.5.8 Performance and Availability

System performance requirements are specified in terms of peak system load and response times in Appendix B, Table B-3, ATM System Performance Requirements. Availability requirements are on a per-service basis and are addressed in Appendix B, Table B-1, ATM Availability Requirements. For the purposes of performance and availability requirements, the specified services are composed of COTS, and/or custom-developed hardware and software. See Appendix B, Requirements Tables, for further details.

3.0 Requirements List

The requirements in the Requirements List are numbered independently of the numbering of the rest of this document. The requirement numbers do not correspond to the section numbering in the rest of the document. The requirements numbers used in this RD are structured to indicate decomposition of the requirements, from the general to the more detailed, in several levels. The requirements with only one (1) number in their requirement number (e.g., 1, 5, etc.) are the highest level, most general requirements. Requirements with two (2) numbers separated by a dot in their requirement number (e.g., 1.1, 6.7) are the next level of decomposition of their corresponding high level requirement (e.g., 1.1, 1.2, 1.3 are each first level decompositions of Req #1). Requirements with three (3) numbers separated by dots in the requirement numbers (e.g., 1.1.1, 2.3.4, etc.) are decompositions of the corresponding next higher level requirement (e.g., 2.3.4 is a decomposition of 2.3, which is a decomposition of 2). The order of requirements within a particular level does not imply any sort of hierarchical or decomposition relationship between these requirements (e.g., 2.1 is not “more important” than 2.4. 2.4 does not decompose 2.1 just because 2.1 comes first.) The only relationship between requirements at a given level is that they decompose the next higher level requirement (e.g., 2.1 and 2.4 both decompose 2). The -indentation of the successive levels of requirements also helps to indicate a requirements level.


Version 1.3 12/7/2005

Page 15


Functional

1. The system shall manage tasks 1.1. The system shall provide the capability to create tasks

1.1.1. The system shall capture and validate the required attributes by task type 1.1.1.1. The system shall allow process modeler define the required attributes

for each task type 1.1.1.2. The system shall enforce validation and authorization rules defined

for each required task attribute 1.1.2. The system shall allow only users with “Create Task” privilege to create a

new task 1.1.3. The system shall assign a unique identifier (Task Id) to each new task

1.1.3.1. The system shall provide the administrator the means to define the format and sequencing of task identifiers automatically generated.

1.1.4. The system shall provide default values for all attributes not provided by the user on new task creation

1.1.4.1. The system shall default owner, assignee, leader, requester attributes to task creator if they are not provided

1.1.4.2. The system shall default org code, team and other organization attributes based on the corresponding employee org code using the latest values from employee directory

1.1.4.3. The system shall allow process modeler provide defaults or override existing defaults for any task attribute on task creation

1.1.5. The system shall provide the capability to associate a task with a process 1.1.5.1. The system shall use the task type and process domain to

automatically select a released process 1.1.5.2. The system shall provide the users a list of all applicable released

processes if more than one process for a task type exists 1.1.5.3. The system shall provide the capability for process modeler to

override any system default or user selected process based on criteria defined by the process modeler

1.1.5.4. The system shall make a task unique copy of the selected process as defined at the time of task creation

1.1.6. The system shall capture the task creation event in the change log along with transaction date and the user id

1.2. The system shall provide the capability for users to update task attributes 1.2.1. The system shall provide the capability for process modeler define the

updateable attributes by task type and process domain 1.2.2. The system shall provide the capability for process modeler define field

level security for any updateable task attribute 1.2.2.1. The system shall check for “Edit Task” privilege prior to granting

access to edit screen


Version 1.3 12/7/2005

Page 16


1.2.2.2. The system shall allow process modeler associate task attributes with privileges and check for the privilege prior to granting edit access for the attribute to any user

1.2.3. The system shall enforce validation and authorization rules defined for each updateable task attribute

1.2.4. The system shall capture the task update in the change log with the before and after values for updated attributes along with transaction date and the user id

1.3. The system shall manage task status 1.3.1. The system shall allow users to cancel tasks

1.3.1.1. The system shall check for “Cancel Task” privilege prior to allowing any user cancel the task

1.3.1.2. The system shall allow only active tasks (i.e. not complete or archived) to be cancelled

1.3.2. The system shall allow users to put tasks on hold 1.3.2.1. The system shall check for “Put task on-Hold” privilege prior to

allowing any user put the task on hold 1.3.2.2. The system shall allow only active tasks (i.e. not complete or

archived) to be put on hold 1.3.3. The system shall allow users provide a comment explaining the reasons for

the status change 1.3.4. The system shall capture the task status change in the change log 1.3.5. The system shall provide the capability for process modeler define new

task status values and the valid transitions between different status values 1.3.5.1. The system shall only allow the task status change from its current

value to another if and only if there is a transition defined from the current status to the next one

1.3.5.2. The system shall check for the required privileges for each transition prior to allowing users update task status

1.3.6. The system shall allow users update task attributes related to status 1.3.6.1. The system shall provide the capability for process modeler define

task attributes related to status by task type and process domain 1.3.6.2. The system shall enforce validation and authorization rules defined

for each task attribute related to status 1.4. The system shall provide and capture the attributes required to support the

lifecycle management process 1.4.1. The system shall provide the task attributes defined in Appendix A – Task

Attributes 1.4.2. The system shall provide ten (10) additional attributes to support customer

specific processes and functionality 2. The system shall manage documents

2.1. The system shall provide a document repository 2.1.1. The system shall provide the capability to upload documents


Version 1.3 12/7/2005

Page 17


2.1.1.1. The system shall create a new document record in the repository for each uploaded document

2.1.1.2. The system shall capture document owner and setup initial document revision

2.1.2. The system shall provide the capability to check-out documents from the repository

2.1.3. The system shall provide the capability to check-in modified documents into the repository

2.1.3.1. The system shall create a new version for the checked-in document if revision control is enabled

2.1.3.2. The system shall capture modification date and user in the change log 2.1.3.3. The system shall allow users enter change comments for the new

revision 2.1.4. The system shall provide the functionality to lock documents to prevent

further changes 2.1.5. The system shall allow users associate documents with keywords and

document classification codes 2.1.6. The system shall provide document level security and access control

2.1.6.1. The system shall allow document owner share document access with other users

2.1.6.2. The system shall allow administrator define the privileges required for document access and maintenance

2.1.7. The system shall provide document version tracking and notifications 2.1.7.1. The system shall allow users register interest for new document

versions and modifications 2.1.7.2. The system shall notify registered users of new document versions

and other changes via the notification mechanism selected by the user (e-mail, pager, on-login)

2.2. The system shall provide document attachments 2.2.1. The system shall allow documents to be attached to tasks

2.2.1.1. The attachment shall refer to the latest checked-in version of the document

2.2.1.2. The attachment shall update its revision count as new version of the document are checked-in

2.2.2. The system shall provide the functionality for sharing the same document between multiple tasks using document attachments

2.2.3. The system shall provide the functionality to search and identify attachments using a combination of task and document attributes

2.3. The system shall capture changes to document versions and attributes in the change log by transaction date and user

2.3.1. The system shall capture document check-out events 2.3.2. The system shall capture document check-in events 2.3.3. The system shall capture changes in document status (create, release, final

etc.)


Version 1.3 12/7/2005

Page 18


2.3.4. The system shall capture changes in document attributes (owner, writer, category, classification) and keywords

3. The system shall provide system administration capabilities 3.1. The system shall provide the functionality to manage field attributes

3.1.1. The system shall allow re-labeling field and column titles 3.1.2. The system shall allow definition and customization of the list of valid

values for fields 3.1.3. The system shall provide a mechanism for specifying validation and lookup

criteria for fields 3.1.4. The system shall allow administrators define the task attributes that can be

searched, summarized or reported 3.2. The system shall provide user management functionality

3.2.1. The system shall allow administrators create new users 3.2.2. The system shall initialize relevant user attributes (name, org code,

supervisor) from the enterprise employee directory for new users 3.2.3. The system shall provide the functionality to notify administrators of

changes in user’s employment status and organizational attributes 3.2.4. The system shall allow administrators assign users to one or more teams 3.2.5. The system shall allow administrators grant users one or more roles 3.2.6. The system shall allow process modelers assign users to one or more

resource groups 3.2.7. The system shall allow deletion an/or inactivation of users

3.3. The system shall provide role management functionality 3.3.1. The system shall allow administrators create new roles

3.3.1.1. The system shall provide the functionality to associate a role with a set of privileges and ACL categories

3.3.1.2. The system shall allow administrators create new ACL categories 3.3.2. The system shall allow administrators change privilege/ACL matrix for any

role 3.3.2.1. The changes to privilege/ACL matrix shall apply to all users that have

the role assigned to them 3.3.3. The system shall provide the functionality to assign one or more roles to

any user 3.3.3.1. User specific privilege/ACL matrix shall be the union of all

privilege/ACL matrices for all roles assigned to the user 3.3.4. The system shall allow administrators delete any role

3.4. All administrative functions shall be available via the system user interface 3.5. All administrative functions shall be available via a batch or scripting interface

Workflow 4. The system shall provide the functionality to manage process workflows

4.1. The system shall provide the functionality to create process workflows


Version 1.3 12/7/2005

Page 19


4.1.1. The system shall provide the functionality to associate a workflow with a task type and process domain

4.1.2. The system shall provide the functionality to manage process status 4.1.2.1. The system shall allow process modeler mark a workflow

“Development” or “Released” 4.1.2.2. The system shall only use “Released” processes in production

4.1.3. The system shall capture process version and effectivity dates 4.2. The system shall provide the functionality to define workflow steps

4.2.1. The system shall provide the functionality to define the normal workflow progress via activity step numbers

4.2.2. The system shall provide the functionality to mark an activity “Mandatory” or “Optional”

4.2.3. The system shall provide the functionality to limit the number of times any given activity step can be performed

4.2.4. The system shall provide the functionality to associate an activity with a resource group

4.2.5. The system shall provide the functionality to capture user input at the completion of an activity step

4.2.5.1. The system shall allow process modeler specify one or more (i.e. input form) user enterable fields to be filled out when the activity step is completed

4.2.6. The system shall provide the functionality to associate an activity with the process stage

4.2.6.1. The system shall allow process modeler define process stages 4.2.6.2. The system shall provide the functionality to move the process to the

corresponding stage when the activity step is started 4.2.7. The system shall allow process modeler define a duration (in days),

working time (in hours) and waiting time (in hours) for each activity in the workflow

4.2.8. The system shall allow process modeler define the effectivity dates for any workflow activity

4.3. The system shall provide the functionality to define event triggers for workflow activity steps

4.3.1. The system shall support workflow events 4.3.1.1. The system shall trigger “Start Activity” event when an activity is

opened 4.3.1.2. The system shall trigger “Select Resource” event when an activity is

ready to be assigned to a resource 4.3.1.3. The system shall trigger “Finish Activity” event when an activity is

completed 4.3.1.4. The system shall trigger “Pick Activity” event when an activity is

selected by the user to be opened 4.3.1.5. The system shall trigger “Assign Resource” event when a task is

assigned to a user


Version 1.3 12/7/2005

Page 20


4.3.1.6. The system shall trigger “Reject Activity” event when an activity is rejected by the assignee

4.3.1.7. The system shall trigger “Reopen Activity” event when a completed activity is reopened

4.3.1.8. The system shall trigger “Update Status” event when the task status is updated

4.3.2. The system shall provide the functionality to associate triggers with workflow events

4.3.2.1. The system shall provide the functionality to define triggers for activity steps

4.3.2.2. The system shall provide the functionality to define workflow level triggers that apply to all activities of the workflow

4.3.2.3. The system shall provide an scripting / programming environment for capturing trigger logic

4.3.2.3.1. The programming environment shall provide read access to all task attributes

4.3.2.3.2. The programming environment shall provide write access to all task attributes except task id

4.3.2.3.3. The programming environment shall provide an API to create new tasks

4.3.2.3.4. The programming environment shall provide an API to read and write task specific data

4.3.2.3.5. The programming environment shall provide the functionality to query task specific workflow

4.3.2.3.6. The programming environment shall provide write access to all workflow activity attributes except task id and activity id

4.3.2.3.7. The programming environment shall provide an API to trigger user defined events

4.3.2.3.8. The programming environment shall provide an API to start an activity on the workflow

4.3.2.3.9. The programming environment shall provide an API to complete an activity on the workflow

4.3.2.3.10. The programming environment shall provide an API to reject an activity on the workflow

4.3.2.3.11. The programming environment shall provide an API to reopen an activity on the workflow

4.3.2.3.12. The programming environment shall provide an API to assign the task to an available resource based on the resource group on the current activity

4.3.2.3.13. The programming environment shall provide an API to query the next activity/activities on the workflow

4.3.2.3.14. The programming environment shall provide an API to handle loops and branching logic in the workflow

4.3.2.3.15. The programming environment shall provide an API to send e-mail notifications to users


Version 1.3 12/7/2005

Page 21


4.3.2.3.16. The programming environment shall provide an API to associate a workflow with a given task based on task type and process domain

4.3.2.4. The system shall provide the functionality to define global triggers that apply to tasks of a certain task type regardless of workflow used

4.4. The system shall provide the functionality to manage resource groups 4.4.1. The system shall provide the functionality to create resource groups 4.4.2. The system shall provide the functionality to associate resource groups with

a process domain 4.4.3. The system shall provide the functionality to set the resource group status

to “Active” or “Inactive” 4.4.4. The system shall provide the functionality to specify a resource allocation

policy for the resource group 4.4.4.1. The system shall support load balancing as an allocation policy 4.4.4.2. The system shall support round robin as an allocation policy 4.4.4.3. The system shall support priority as an allocation policy 4.4.4.4. The system shall support minimum cost as an allocation policy

4.4.5. The system shall provide the functionality to associate users with resource groups

4.4.5.1. The system shall allow users to be added to a resource group individually

4.4.5.2. The system shall allow users to be added to a resource group based on team membership

4.4.5.3. The system shall allow users to be added to a resource group based on role assignments

4.4.5.4. The system shall allow users to be added to a resource group based on organization codes

4.4.6. The system shall provide functionality to automatically update resource group as users are added to or deleted from associated teams, roles and organizations

4.4.7. The system shall provide functionality to define a priority for each resource group member to be used for priority based allocation

4.4.8. The system shall provide functionality to define a load factor for each resource group member to be used for load based allocation

4.4.9. The system shall provide functionality to define a cost factor for each resource group member to be used for cost based allocation

5. The system shall provide the functionality to execute process workflows 5.1. The system shall create a snapshot of the process workflow for each task using

the workflow 5.1.1. The snapshot shall be a copy of the workflow as it is defined at the time the

workflow is attached to the task 5.1.2. The system shall include in the snapshot the activities that are effective as

of the snapshot date 5.2. The system shall provide the functionality to customize task workflows


Version 1.3 12/7/2005

Page 22


5.2.1. The system shall provide the functionality to add and delete activities to the task workflow

5.2.2. The system shall provide the functionality to modify activity attributes 5.2.3. The changes to task workflow shall be independent of the source process

workflow 5.2.4. The system shall provide an API to customize the task workflow using

activity triggers 5.3. The system shall execute any defined event triggers when the corresponding

event takes place 5.3.1. The system shall execute all applicable global, process level, and activity

level triggers 5.3.2. The system shall execute any global trigger(s) first, followed by process

level and finally any triggers defined for the current activity in the workflow 5.3.3. The system shall capture any trigger failures and errors in the change log

5.4. The system shall provide the functionality to “promote” the task to the next activity in the workflow

5.4.1. The system shall automatically select the next open activity in the workflow when the user promotes the task

5.4.2. The system shall present the user a choice of activities if more than one activity are next in-line in the workflow

5.4.3. The system shall allow process modeler override default execution flow of the workflow via triggers

5.4.4. The system shall collect all required data from the user and make it available to the workflow triggers when a task is promoted to the next activity

5.5. The system shall provide the functionality to “reject” the task to an earlier activity in the workflow

5.5.1. The system shall allow process modeler specify the reject policy for each activity in the workflow

5.5.1.1. The system shall reopen the previous activity if reject policy is “Reopen Previous”

5.5.1.2. The system shall allow the user pick the activity to reopen if reject policy is “Select Single Activity”

5.5.1.3. The system shall allow the user pick one or more closed activities to reopen if reject policy is “Select Multiple Activities”

5.5.1.4. The system shall not reopen any activities if reject policy is “Workflow”

5.5.2. The system shall mark current activity “Rejected” and pick the earliest pending activity as the next activity to start

5.6. The system shall provide the functionality to “assign” the task to another user 5.6.1. The system shall only assign the task to a user from the current activity’s

resource group 5.6.2. The system shall provide the functionality for the process modeler to

override or turn-off reassignment of tasks within a resource group


Version 1.3 12/7/2005

Page 23


5.7. The system shall automatically mark the task “Complete” when all mandatory activities in the workflow are completed

6. The system shall capture workflow execution history 6.1. The system shall record each activity completion

6.1.1. The system shall record the performer for each activity step 6.1.2. The system shall record the start and finish dates and other cycle time data 6.1.3. The system shall record each invocation of an activity step separately 6.1.4. The system shall record the completion status for each invocation of

activity steps 6.2. The system shall capture estimated and actual hours for each activity step and for

the task overall 6.3. The system shall capture the actual activity level schedule along with the planned

activity level schedule 6.4. The system shall capture the cycle time for each task stage 6.5. The system shall capture earned value and schedule performance based of

workflow standards and task actuals 7. The system shall provide an external interface to its workflow engine

7.1. The system shall define an API for all functionality available in the workflow execution environment

7.1.1. The workflow API shall follow the guidelines set forth by WfMC 7.1.2. The API shall be a stand alone library/package and shall not require

communication with the system production instance 7.2. The workflow engine API shall be made available in a common scripting

environment 7.3. The workflow engine API shall provide a SOAP interface

User Interface

8. The system shall provide a web based user interface 8.1. The system shall provide a web based user interface for all its application

functionality 8.2. The system shall provide a web based user interface for all its administrative

functionality 8.3. The system shall utilize HTML 3.2 standard or later for all user screens 8.4. The system shall use other W3C standards for its user interface provided they are

sufficiently supported by the client browser 8.5. The system shall not require installation and maintenance of any software

modules, libraries or applications on the client’s machine other than a HTML 3.2 compatible browser

8.6. The system shall not use ActiveX or similar technology that limits the client’s choice of hardware, operating system or browser software to a single platform or vendor

8.7. The system shall use browser plug-in’s or desktop productivity tools provided such use is not essential for the primary functionality of the system

9. The system shall provide role based portals


Version 1.3 12/7/2005

Page 24


9.1. The system shall provide a portal (home page) for task owners 9.1.1. The portal shall provide a monthly summary of owner’s tasks by stage and

need date 9.1.2. The portal shall provide a summary of planned and actual hours by project 9.1.3. The portal shall provide a summary of all tasks assigned to the user by task

owner and status 9.1.4. The portal shall provide a summary of tasks that needs to be completed in

the current month by task type and status 9.1.5. The portal shall provide links to team portals for teams that the user

belongs to 9.1.6. The portal shall provide links to last ten(10) tasks updated by the user

sorted in descending update date 9.2. The system shall provide a team portal

9.2.1. The portal shall provide a monthly summary of team’s tasks by task type and need date

9.2.2. The portal shall provide a summary of planned and actual hours by project for team’s tasks

9.2.3. The portal shall provide a summary of team tasks needed before the end of current month by task type and status

9.2.4. The portal shall provide a list of team members with a count of all active tasks owned by and assigned to each team member

9.3. The system shall provide a portal for team leaders 9.3.1. The portal shall provide a monthly summary of team leader’s tasks by task

type and need date 9.3.2. The portal shall provide a summary of planned and actual hours by project 9.3.3. The portal shall provide task progress summary by task owner and stage 9.3.4. The portal shall provide a summary of tasks needed before the end of

current month by task type and status 9.3.5. The portal shall provide links to team portals for teams that the user

belongs to 9.4. The system shall provide an organization level portal

9.4.1. The system shall allow administrator define organization portals 9.4.1.1. The system shall allow administrator define the task selection criteria

for the portal (i.e. org code, project etc.) 9.4.1.2. The system shall allow administrator define the portal page title and

add custom content for a particular organization 9.4.1.3. The system shall allow administrator add links to other organizational

portals that are above or below in organizational structure 9.4.2. The portal shall provide a monthly summary of organization’s tasks by task

type and need date 9.4.3. The portal shall provide a summary of planned and actual hours by project

for organization’s tasks 9.4.4. The portal shall provide a summary of organization’s tasks needed before

the end of current month by task type and status


Version 1.3 12/7/2005

Page 25


9.5. The portals shall provide links on all summary panels to drill-down to detail data (i.e. task records) that make up the total numbers

9.6. The portals shall provide links to all related screens and reports for tasks that make up the portal page

10. The system shall provide the functionality to search tasks 10.1. The system shall provide the functionality to lookup a task by its unique id 10.2. The system shall provide the functionality to search tasks by document number 10.3. The system shall provide the functionality to perform advanced searches by

user specified criteria 10.3.1. The system shall allow administrator specify searchable task attributes 10.3.2. The system shall allow users build the search criteria using a subset of

searchable attributes 10.3.3. The system shall provide the functionality to search by single attribute

values or wild-cards 10.3.4. The system shall allow administrators capture common search conditions

and present it to users to be used in conjunction with user specified criteria 10.4. The system shall provide the functionality to save user specified search criteria

to be executed again at a later time without reentering all attribute values 10.5. The system shall provide the functionality to sort search results by attributes

specified by the user 11. The system shall provide calendarized views

11.1. The system shall provide a weekly calendar view 11.2. The system shall provide a monthly calendar view 11.3. The system shall display current week/month by default 11.4. The system shall permit navigation to the next/previous week/month 11.5. The system shall display tasks on calendar view

11.5.1. The system shall place tasks on the calendar by the date attribute specified by the user

11.5.2. The system shall allow user change the task date attribute used for placement

11.5.3. The system shall place tasks on the calendar by due date by default 11.6. The system shall display task change log on calendar view

11.6.1. The system shall place log records on the calendar by change date 11.6.2. The system shall display change type and task title in the calendar

11.7. The system shall provide the functionality to filter records displayed on the calendar by user specified search criteria

12. The system shall provide summary/drill-down functionality 12.1. The system shall allow administrator specify task attributes eligible for

summary roll-up 12.2. The system shall allow users summarize task records by selected task attributes

12.2.1. The system shall allow users select the task attributes to be used for summary roll-up

12.2.2. The system shall allow users specify a search criteria to restrict the summary to a subset of all tasks


Version 1.3 12/7/2005

Page 26


12.2.3. The system shall display a count of tasks by selected attribute values as well as the total of estimated and actuals hours

12.2.4. The system shall allow users add to or delete from the list of task attributes used for summary roll-up

12.2.5. The system shall allow users save any summary roll-up definition to be executed again at a later time

12.3. The system shall provide functionality to drill-down to the task records that make-up any given summary line

Data Interface

13. The system shall interface with other enterprise systems 13.1. The system shall provide and use standard and published application interfaces

when interfacing with other enterprise systems 13.2. The system shall provide and use standard and published data interface formats

when interfacing with other enterprise systems 13.3. The system shall provide and use standard and supported database connectivity

methods when interfacing with other enterprise systems 14. The system shall support XML as a data interchange format

14.1. The system shall define and make available an XML schema for task data interchange

14.1.1. The system shall provide the functionality to export selected tasks and attributes in XML format

14.1.2. The XML schema shall support creating new tasks using a well formed XML file as input

14.1.3. The XML schema shall support updating task attributes and status using a well formed XML file as input

14.2. The system shall support and use Wf-XML 2.0 standard from WfMC to support workflow exchange and management

14.3. The system shall provide the functionality to export any report or record in the system in XML format

14.3.1. The system shall provide a default mapping between columns and XML attributes

14.3.2. The system shall allow administrator override the default XML mapping 15. The system shall use an RDBMS for data storage an management

15.1. The system shall use a RDBMS supported by Infusient enterprise architecture 15.2. The system shall access the RDBMS via a direct database connection 15.3. The system shall not use any middleware, translator or third-party software to

manage its database interaction 15.4. The system shall use SQL to communicate with the database

15.4.1. The system shall use standard SQL for all data access and manipulation 15.4.2. The system’s use of SQL extensions and other RDBMS vendor specific

functionality shall be limited to database triggers and functions 15.4.3. The system’s use of non standard SQL shall be limited to less than ten(10)

percent of the total system lines of code


Version 1.3 12/7/2005

Page 27


Reporting

16. The system shall provide reporting capability 16.1. The system shall provide standard reports

16.1.1. The system shall provide a task report 16.1.2. The system shall provide a workflow report 16.1.3. The system shall provide a change log report 16.1.4. The system shall provide a timesheet report 16.1.5. The system shall provide a task attachment report 16.1.6. The system shall provide a report for task notes and messages 16.1.7. The system shall provide a system user report 16.1.8. The system shall provide a workflow cycle time report 16.1.9. The system shall provide a document report

16.2. The system shall provide the functionality to change the filtering and sorting criteria on any standard report

16.3. The system shall provide report writing capability 16.3.1. The system shall provide the functionality to customize standard reports

16.3.1.1. The system shall provide the functionality to add columns to the custom report

16.3.1.2. The system shall provide the functionality to delete columns from the custom report

16.3.1.3. The system shall provide the functionality to change the order of columns in the custom report

16.3.1.4. The system shall provide the functionality to specify and change the query criteria and sort order for the custom report

16.3.2. The system shall allow users to save any user developed/customized report

16.3.2.1. The system shall capture report query criteria, sort order and column definition for the custom report

16.3.2.2. The system shall provide the functionality to refresh the report with the latest data from the system

16.3.3. The system shall provide a mechanism to share user defined custom reports via e-mail messages and web pages.

16.4. The system shall provide the functionality to export any report to Excel 16.5. The system shall provide the functionality to generate any report in PDF format

16.5.1. The system shall allow user specify the page orientation (portrait/landscape) for the PDF report

16.5.2. The system shall allow user specify the page size (e.g. letter, legal, A4 etc.) for the PDF report

16.6. The system shall provide the functionality to export selected task records to MS-Project

16.6.1. The system shall allow administrator define the mapping between task attributes and MS-Project fields

16.6.2. The system shall allow users to customize the mapping to their own needs


Version 1.3 12/7/2005

Page 28


16.7. The system shall provide a task Gannt chart 16.8. The system shall provide the functionality to add links and hotspots to reports to

drill-down to detail records or lookup relevant data 17. The system shall provide charting capability

17.1. The system shall provide an On-Time Delivery Metric chart 17.1.1. The chart shall present year-to-date on time delivery performance in

monthly buckets 17.1.2. The chart shall use latest task status in real-time as its input 17.1.3. The chart shall include the total number of tasks that are scheduled,

released, late and on time for each month 17.1.4. The chart shall include monthly average days late and percent on time 17.1.5. The chart shall calculate and display a “3 month percent on time average”

and cumulative totals for tasks that are scheduled, released and late 17.1.6. The chart shall provide the functionality to drill-down to the task records

that make up any monthly scheduled, released and late totals 17.2. The system shall provide the functionality for users generate charts using

selected task attributes as chart dimensions 17.3. The system shall provide the functionality to customize charts

17.3.1. The system shall provide the functionality to change chart type (e.g. bar, line, pie, radar etc.)

17.4. The system shall provide the functionality to generate charts in PDF format 17.5. The system shall provide the functionality to generate charts in PNG format 17.6. The system shall provide the functionality to convert charts to Excel charts 17.7. The system shall provide the functionality to export chart data to Excel 17.8. The system shall provide the functionality to drill-down to the supporting data

from any selected chart data point

Infrastructure

18. The system shall conform to Infusient IT infrastructure 18.1. The system shall utilize server and operating system components approved and

supported by Infusient enterprise architecture 18.2. The system shall leverage existing Infusient solutions and infrastructure where

it is technically and financially feasible 18.3. The system shall utilize existing Infusient problem reporting and help desk

processes 18.4. The system shall utilize existing Infusient training and user support

infrastructure 19. The system shall use open standards and formats where they are available 20. The system shall use open source or COTS products for its major components

20.1. The system shall use open source components where it is technically feasible

Security

21. The system shall provide user authentication


Version 1.3 12/7/2005

Page 29


21.1. The system shall authenticate users using unique login id and passwords 21.1.1. The system shall enforce customer’s standards for assigning user id’s 21.1.2. The system shall enforce customer’s standards for password selection and

expiration 21.2. The system shall authenticate users for each access to the system 21.3. The system shall provide LDAP integration for single sign-on support 21.4. The system shall capture each login attempt (successful and failed) 21.5. The system shall capture the last access date for each user

21.5.1. The system shall provide the functionality for administrator to identify user accounts that are inactive beyond a threshold

21.5.2. The system shall provide the functionality for administrator to disable/delete user accounts that have been inactive

21.6. The system shall provide the functionality to flag users that have been terminated using employee status from customer’s employee directory (if available)

22. The system shall provide application security 22.1. The system shall grant access to only authenticated users 22.2. The system shall grant access to restricted parts of the application only to users

with the right privileges 22.2.1. The system shall associate restricted screens and functions of the

application with named privileges 22.2.2. The system shall allow administrators define user roles

22.2.2.1. The system shall allow administrators define a role as a matrix of privileges and ACL’s

22.2.2.2. The system shall allow administrators add or delete ACL categories as needed

22.2.2.3. The system shall allow administrators add, delete and change user roles as needed

22.2.3. The system shall allow administrators assign one or more roles to any user 22.2.4. The system shall combine all privileges from the roles assigned to the user

to determine user’s privilege matrix 22.2.5. The system shall match user’s privilege matrix with the privilege required

for access and grant or deny access accordingly 22.3. The system shall perform user authorization for each access to restricted objects

or functionality 22.4. The system shall provide field level security

22.4.1. The system shall allow administrator associate selected task attributes with privileges

22.4.2. The system shall check for the required privilege prior to granting edit access to any task attribute

23. The system shall provide session management functionality 23.1. The system shall ensure login session and transaction integrity across requests 23.2. The system shall ensure data integrity throughout the lifecycle of a transaction

23.2.1. The system shall not update data until an explicit commit is performed


Version 1.3 12/7/2005

Page 30


23.2.2. The system shall roll back any pending transaction that is aborted or timed out

23.3. The system shall support and enforce session and transaction timeouts 23.3.1. The system shall allow administrator specify session and transaction

timeout values 23.3.2. The system shall abort transactions that are timed out 23.3.3. The system shall cancel sessions that are timed out 23.3.4. The system shall automatically collect and reuse session resources and

allocated objects after timeout 23.4. The system shall provide secure communications

23.4.1. The system shall use SSL 2.0 to securely communicate with the clients

Performance and Availability

24. The system shall meet or exceed the availability requirements 24.1. The system shall meet or exceed the availability requirements listed in

Table B-1 ATM Availability Requirements 25. The system shall meet or exceed the performance requirements

25.1. The system shall meet or exceed the performance requirements listed in Table B-3 ATM System Performance Requirements

26. The total system size shall stay within the sizing requirements 26.1. The system size shall stay within the sizing requirements listed in

Table B-2 ATM Sizing Requirements

ATM SyRS Document# EM-SRS-01

Version 1.0 12/7/2005


Page A-1

Appendix A: Task Attributes

Attribute Definition

Task Id Unique Task Identifier – system assigned Title brief description of task Task Type task type is the main criteria for workflow selection

Status Pending, In Progress, Complete (full list is implementation specific)

Task Code user specified task categorization Document # related document – for document centric tasks Document Type Document Class user specified document category Stage the stage the task is currently in Process Domain used to separate workflows by organizational lines Objective one paragraph SOW Project corresponding project or initiative (when applicable) WBS optionally validated against customer charge numbers Authorization # the document that authorized the task (e.g. change request) Parent Task the reference to the summary task – when applicable Requester requester can be internal or external (i.e. customer) Owner owner has the responsibility for on-time delivery Assignee person currently working on task Team Leader Tean leaders set broad priorities and goals for their teams Created By the person who entered the task to the system

Team Teams can be defined by product lines or formed for specific projects

Approver the final sign-off on the task Create Date system captured Scheduled Start Date Actual Start Date system captured Need Date required completion date specified by requester Due Date promise/commit date from task owner Approval Date the date the approver signs-off on the task Complete Date system captured Baseline Date original need date – system captured Estimated Hours defaulted from standard hours in the workflow Actual Hours user entered or pulled in from customer’s timesheet system Requesting Org defaults to requester’s org code Responsible Org defaults to task owner’s org code Performing Org defaults to responsible org Generic Task Attributes to be used as needed to support customer specific functionality


Version 1.0 12/7/2005


Page B-1

Appendix B: Requirements Tables Table B-1, ATM Availability Requirements, imposes graduated availability requirements on the specified ATM services and functional features.

Service or Feature Average Total Loss of Service per Year in Hours

(FYI)

Availability

Access System via Electronic Interface

1 99.99%

Search Tasks 6 99.93% Access Tasks 12 99.86% Update Tasks 12 99.86% Report Writing 12 99.86% Data Export/Outbound Interface 40 99.54% Data Import/Inbound Interface 48 99.45% Distributed Access via SOAP 48 99.45%

Table B-1: ATM Availability Requirements

Availability is the ratio of time that a service is available to the total time of system operation. As availability is a statistical calculation, mean times are used. Availability takes into account Mean Time to Repair (MTTR) and Mean Time to Failure rates (MTTF). Availability = MTTF/ (MTTF+MTTR).


Version 1.0 12/7/2005


Page B-2

Table B-2, ATM Sizing Requirements, provides requirements concerning transfer to , accumulated archive volumes, and concurrent number of users for the ATM system over time.

Year

I Year

II Year III

Year IV

Year V

Year VI

Avg. Yearly Data Volume (GB) 3.58 1.90 2.29 2.87 3.49 4.83

- Document Repository 2.68 1.50 1.87 2.40 2.98 4.18 - Structured Data 0.89 0.40 0.42 0.46 0.51 0.65 Accumulated Holdings Volume (GB) 3.58 5.48 7.77 10.64 14.12 18.95

Avg. Num. of Concurrent Users* 50 200 250 300 400 500

Table B-2: ATM Sizing Requirements * Concurrent users are defined as the number of active sessions where system services are being exercised. These services include but are not limited to obtaining records, record queries, status checks, and logins and authorizations. The average number of concurrent users is the sum of all user activity across all instances of ATM .


Version 1.0 12/7/2005


Page B-3

Table B-3, ATM System Performance Requirements, lists requirements for peak system load capacity and system response requirements for specific operations in seconds. Peak loads are a function of the number of average concurrent users supported as defined in Table B-2. Peak loads across all functional categories are cumulative (i.e., they are measured concurrently). Response Times are measured under nominal physical and electronic distribution loads.

Category Peak Number of Requests to be

Supported

Specific Operation Response Time*

Log-on and authorization

1/3 of the total number of supported concurrent users

Account confirmation and authorization

2 sec

Search 8 times the total number of supported concurrent users

Single attribute search by task id or document#

2 sec

Advanced Search 5 times the total number of supported concurrent users

Multiple attribute search with filters

5 sec

Portal Access 2 times the total number of supported concurrent users

Task status summary by portal criteria

5 sec

Task Creation 1/10 of the total number of supported concurrent users

Order submission and confirmation

3 sec

Task Maintenance

3 times the total number of supported concurrent users

Task edit, status update, promote, reject or assign

3 sec

Report Writing ½ of the total number of supported concurrent users

Task attribute selection, specify search criteria, generate/export report

15 sec

* From initiation of query to start of display, exclusive of user environment and network delay. System is assumed to contain 100,000 records and associated attributes.

Table B-3: ATM System Performance Requirements