atm syrs v1_3

8/7/2019 ATM SyRS v1_3

1/38

Alchemy Task Manager

(ATM)

System Requirements Document

8/7/2019 ATM SyRS v1_3

2/38

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

8/7/2019 ATM SyRS v1_3

3/38


Version 1.3 12/7/2005

Page ii


Table of Contents1.0 INTRODUCTION.......................................................................................................................... 1

1.1 SYSTEM PURPOSE......................................................................................................................... 11.2 DOCUMENT ASSUMPTIONS........................................................................................................... 11.3 SYSTEM SCOPE............................................................................................................................. 11.4 ACRONYMS AND DEFINITIONS ..................................................................................................... 21.5 REFERENCES ................................................................................................................................ 2

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

1.6 OVERVIEW ................................................................................................................................... 3

2.0 GENERAL SYSTEM DESCRIPTION........................................................................................ 3

2.1 SYSTEM CONTEXT........................................................................................................................ 32.2 MAJOR SYSTEM CAPABILITIES..................................................................................................... 42.3 SYSTEM CONSTRAINTS AND CONDITIONS .................................................................................... 7

2.3.1 Constraints ............................................................................................................................. 72.3.2 Conditions............................................................................................................................... 8

2.4 USER CHARACTERISTICS.............................................................................................................. 82.5 REQUIREMENTS CATEGORIZATION............................................................................................. 10

2.5.1 Functional............................................................................................................................. 102.5.2 Workflow............................................................................................................................... 112.5.3 User Interface....................................................................................................................... 122.5.4 Data Interface....................................................................................................................... 122.5.5 Reporting .............................................................................................................................. 122.5.6 Infrastructure........................................................................................................................ 132.5.7 Security................................................................................................................................. 132.5.8 Performance and Availability............................................................................................... 14

3.0 REQUIREMENTS LIST............................................................................................................. 14

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

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

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

8/7/2019 ATM SyRS v1_3

4/38


Version 1.3 12/7/2005

Page iii


List of Tables

Table 1-1: Acronym List..................................................................................................... 2

Table B-1: ATM Availability Requirements ...................................................................... 1Table B-2: ATM Sizing Requirements............................................................................... 2

Table B-3: ATM System Performance Requirements........................................................ 3

8/7/2019 ATM SyRS v1_3

5/38


Version 1.3 12/7/2005

Page 1


ATM Requirements Document (RD)

1.0 Introduction

This Requirements Document (RD) defines the requirements for the Infusients AlchemyTask Manager (ATM) System . The primary audience of this document includes, but is

not limited to, project leaders, the designers and developers of the system andexisting/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 workflowand 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 contextinformation 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 customers organization and responsible task owner. Furthermore, when the termtasks 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 ATMs 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 WfMCWorkflow Reference Model.

8/7/2019 ATM SyRS v1_3

6/38


Version 1.3 12/7/2005

Page 2


ATM will perform automatic activity routing and approvals per the definedworkflow.

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 ShelfDBI 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 SystemSME 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.

8/7/2019 ATM SyRS v1_3

7/38


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 thegeneration 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, theserequirements 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, archivingand 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

8/7/2019 ATM SyRS v1_3

8/38


Version 1.3 12/7/2005

Page 4


any unscheduled, ad-hoc work packages requiring organizations resources. The systemwill 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 anyunit of work that the enterprise allocates resources to and are responsible for timelydelivery 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 requiredand 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, datamanagement, 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 customersimplementation 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 RequirementsCategorization.

Task Management: ATM should be first and foremost a task management tool thatunifies organizations goals (deliver product on-time and within budget, respond to

customers needs), task owners 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

8/7/2019 ATM SyRS v1_3

9/38


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 theworkflow 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 processesand exceptions. The following are some of the characteristics of the ATM WMS:

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

Provide event triggers to customize workflow execution based on internal andexternal 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 workflowas-required.

Collect performance and cycle-time data for iterative business processimprovement.

Expose the workflow engine API for interacting with other enterprise applicationsor 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) orterminate tasks (i.e. Engineering Drawing). Other related documents, so-called passing

through documents (e.g. test results, analyses, problem reports) symbolize the valueadding activities which finally produce terminating documents. Documents are first class

information objects along with more structured information.

Given the significance ofdocument 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 offormal procedures in the workplace. On the other hand, groupware andcollaboration 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 transitionbetween 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

8/7/2019 ATM SyRS v1_3

10/38


Version 1.3 12/7/2005

Page 6


the system should facilitate and encourage group interactions by providing them the toolsof 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 shallintegrate 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 schedulemetrics and forecasts. ATM shall also interface with third-party tools such as MS-Project

to facilitate simulations and what-ifs..

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 becapable 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 activitysteps and stages representing various levels of organizational structure and decision

making authority. A static security system based on screen access and rigid applicationroles 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. EditTask, Cancel Task, Create Attachment etc.).

Privileges will be granted to roles per ACL categories where ACL categories aredefined 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 Codeetc.

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

Each user shall be assigned one or more roles which are combined to derive theusers privilege/ACL matrix.

8/7/2019 ATM SyRS v1_3

11/38


Version 1.3 12/7/2005

Page 7


At run time, the system shall dynamically compare objects attributes against theACL held by the user and, for all matches, check the ACL matrix for the privilegerequested. Access is granted if privilege is found, denied otherwise.

Traceability: ATM should capture full history of changes performed on tasks and theiractivities. 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 multiplegroups 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 systemadministrator 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 presentationformats 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 andother presentation screens.

Customize the list of searchable task attributes and their layout.

Allow users customize ATM standard reports with their own layout and filteringcriteria. 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 architectureor 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 clientcommunications and user interface.

8/7/2019 ATM SyRS v1_3

12/38


Version 1.3 12/7/2005

Page 8


The system may use other W3C standards such as CSS or Javascript as long asthe client softwares level of, or lack of, support for the standard does not interferewith the primary operational purpose of the system.

The system may use browser plug-ins 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 clients

choice of hardware, operating system or browser software to a single platform or

vendor.

The system must not require installation and maintenance of any softwaremodules, libraries or applications on the clients 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 itstask data storage and management.

The system shall access and maintain all data in the database via a direct databaseconnection 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 thetotal 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 itis 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 usertools, 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 solutionmodel delivered by Infusient. They can, and probably will, be modified as part of

customers implementation plan:

8/7/2019 ATM SyRS v1_3

13/38


Version 1.3 12/7/2005

Page 9


Requester: Requester is the customer who initiated the task (via ATM or someother means outside the system). The requester specifies the need date, hence hascontrol 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 andthey work with requesters and task owners to lay out and manage an executionplan. 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 successfuldelivery 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 thetask owners responsibility to capture deviations from the execution schedule and

escalate as required.

Assignee: Assignee is responsible for completing the current activity of the taskas 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 theworkflow allows it.

Workflow Modeler: Workflow modeler captures the existing manual businessprocess and translates it to a set of interconnected activities along with starting

and completion conditions, stage transitions and resource requirements. Acompleted 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 asneeded, manage field and column attributes such as labels, list of values, field

level access restrictions etc. Some of daily administration tasks such as creatingand 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 metricsgeneration 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 thedata.

Main ATM organizational roles are listed below:

Team: The collaboration group responsible with delivering a set of tasks. Teammembers usually collaborate on team tasks and usually are pulled in from

different organizations to achieve a specific objective.

8/7/2019 ATM SyRS v1_3

14/38


Version 1.3 12/7/2005

Page 10


Requesting Org: The organization responsible for the requirement that led to thecreation of the task. This attribute usually, but not necessarily, refers to theRequesters own organization.

Responsible Org: The organization responsible for the successful delivery of the

task. This attribute usually, but not necessarily, refers to the Task Owners ownorganization.

Performing Org: The organization tasked for executing the task. Performing Orgis usually the Responsible Org except when the task is outsourcedto 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 engineeringdeliverable 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 requiredapprovals, application data and documents at each step.

Capture task status along with changes in ownership, due date, percent completeand 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 therepository

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 bythe users

Provide a mechanism to save the criteria for any search, so that users can re-execute the search without retyping the search parameters.

8/7/2019 ATM SyRS v1_3

15/38


Version 1.3 12/7/2005

Page 11


The system must support administrative functions required for on-going maintenance andmanagement 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 thesystem.

Add, configure and delete field attributes for task and other objects in the system.

Define and customize the parameters and defaults applicable to the wholeapplication (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 systems

integrated WMS. The primary function of WMS is to execute the task specific workflowinstance 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 theprocess 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 theapplicability of any process definition to a task.

Instantiate a workflow by creating a task specific copy at task creation or at anypoint in tasks lifecycle.

Provide a workflow control module (i.e. workflow engine) responsible forinterpreting 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 internalinput.

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 activitysteps including full history of each process enactment.

8/7/2019 ATM SyRS v1_3

16/38


Version 1.3 12/7/2005

Page 12


2.5.3 User Interface

This section captures the main characteristics of the systems user interface, its usabilityand 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 summarizeand 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 offeringalternative 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 forprinting 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 andfiltering criteria

8/7/2019 ATM SyRS v1_3

17/38


Version 1.3 12/7/2005

Page 13


Export task records to MS-Project for further analysis, presentation or schedulesimulations

Generate a task summary form that includes all relevant data for any given taskincluding 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 outputmedium/format (i.e. Flash, PDF, GIF, PNG, Excel etc.)

Provide standard, canned reports for the following system objects:o Taskso Workflow Activitieso History (task & workflow)o Timesheetso Attachmentso 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, andfollow the infrastructure constraints specified in Section 2.3.1 Constraints.

2.5.7 Security

This section describes system security, user authentication/authorization, and transactionintegrity 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 customers 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 thebusiness 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 theuser

Perform user authorization checks by matching target objects ACL and theprivilege required with the ACL and privileges granted to the user

Perform user authorization for every restricted access to the target object(s)

8/7/2019 ATM SyRS v1_3

18/38


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 resourcesand 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 arecomposed 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 sectionnumbering in the rest of the document.

The requirements numbers used in this RD are structured to indicate decomposition ofthe 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) numbersseparated 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 thecorresponding 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 requirementslevel.

8/7/2019 ATM SyRS v1_3

19/38


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 tasks1.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 attributesfor each task type

1.1.1.2.The system shall enforce validation and authorization rules definedfor each required task attribute

1.1.2.The system shall allow only users with Create Task privilege to create anew task

1.1.3.The system shall assign a unique identifier (Task Id) to each new task1.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 bythe user on new task creation

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

1.1.4.2.The system shall default org code, team and other organizationattributes based on the corresponding employee org code using the

latest values from employee directory1.1.4.3.The system shall allow process modeler provide defaults or override

existing defaults for any task attribute on task creation1.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 toautomatically select a released process1.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 exists1.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 modeler1.1.5.4.The system shall make a task unique copy of the selected process as

defined at the time of task creation1.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 attributes1.2.1.The system shall provide the capability for process modeler define theupdateable attributes by task type and process domain

1.2.2.The system shall provide the capability for process modeler define fieldlevel security for any updateable task attribute

1.2.2.1.The system shall check for Edit Task privilege prior to grantingaccess to edit screen

8/7/2019 ATM SyRS v1_3

20/38


Version 1.3 12/7/2005

Page 16


1.2.2.2.The system shall allow process modeler associate task attributes withprivileges and check for the privilege prior to granting edit access for

the attribute to any user1.2.3.The system shall enforce validation and authorization rules defined for each

updateable task attribute1.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 id1.3.The system shall manage task status

1.3.1.The system shall allow users to cancel tasks1.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 orarchived) 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 toallowing any user put the task on hold1.3.2.2.The system shall allow only active tasks (i.e. not complete or

archived) to be put on hold1.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 log1.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 currentvalue to another if and only if there is a transition defined from the

current status to the next one1.3.5.2.The system shall check for the required privileges for each transitionprior to allowing users update task status

1.3.6.The system shall allow users update task attributes related to status1.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 definedfor each task attribute related to status

1.4.The system shall provide and capture the attributes required to support thelifecycle management process

1.4.1.The system shall provide the task attributes defined in Appendix A Task

Attributes1.4.2.The system shall provide ten (10) additional attributes to support customerspecific processes and functionality

2.The system shall manage documents

2.1.The system shall provide a document repository2.1.1.The system shall provide the capability to upload documents

8/7/2019 ATM SyRS v1_3

21/38


Version 1.3 12/7/2005

Page 17


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

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

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

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

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

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

revision2.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 anddocument classification codes2.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 withother users

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

2.1.7.The system shall provide document version tracking and notifications2.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 tasks2.2.1.1.The attachment shall refer to the latest checked-in version of the

document2.2.1.2.The attachment shall update its revision count as new version of the

document are checked-in2.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 attributes2.3.The system shall capture changes to document versions and attributes in thechange log by transaction date and user

2.3.1.The system shall capture document check-out events2.3.2.The system shall capture document check-in events2.3.3.The system shall capture changes in document status (create, release, final

etc.)

8/7/2019 ATM SyRS v1_3

22/38


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 attributes3.1.1.The system shall allow re-labeling field and column titles3.1.2.The system shall allow definition and customization of the list of valid

values for fields3.1.3.The system shall provide a mechanism for specifying validation and lookup

criteria for fields3.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 functionality3.2.1.The system shall allow administrators create new users3.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 ofchanges in users employment status and organizational attributes

3.2.4.The system shall allow administrators assign users to one or more teams3.2.5.The system shall allow administrators grant users one or more roles3.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 users3.3. The system shall provide role management functionality

3.3.1.The system shall allow administrators create new roles3.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 categories3.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 havethe role assigned to them

3.3.3.The system shall provide the functionality to assign one or more roles toany user

3.3.3.1.User specific privilege/ACL matrix shall be the union of allprivilege/ACL matrices for all roles assigned to the user

3.3.4.The system shall allow administrators delete any role3.4.All administrative functions shall be available via the system user interface3.5.All administrative functions shall be available via a batch or scripting interface

Workflow

4.The system shall provide the functionality to manage process workflows4.1.The system shall provide the functionality to create process workflows

8/7/2019 ATM SyRS v1_3

23/38


Version 1.3 12/7/2005

Page 19


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

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

Development or Released4.1.2.2.The system shall only use Released processes in production

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

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

4.2.2.The system shall provide the functionality to mark an activity Mandatoryor Optional

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

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

resource group4.2.5.The system shall provide the functionality to capture user input at the

completion of an activity step4.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 theprocess stage

4.2.6.1.The system shall allow process modeler define process stages4.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 theworkflow

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

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

4.3.1.The system shall support workflow events4.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 resource4.3.1.3.The system shall trigger Finish Activity event when an activity iscompleted

4.3.1.4.The system shall trigger Pick Activity event when an activity isselected by the user to be opened

4.3.1.5.The system shall trigger Assign Resource event when a task isassigned to a user

8/7/2019 ATM SyRS v1_3

24/38


Version 1.3 12/7/2005

Page 20


4.3.1.6.The system shall trigger Reject Activity event when an activity isrejected by the assignee

4.3.1.7.The system shall trigger Reopen Activity event when a completedactivity is reopened

4.3.1.8.The system shall trigger Update Status event when the task status isupdated

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

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

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

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

4.3.2.3.1.The programming environment shall provide read access to all

task attributes4.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 createnew tasks

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

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

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

4.3.2.3.7.The programming environment shall provide an API to triggeruser defined events4.3.2.3.8.The programming environment shall provide an API to start an

activity on the workflow4.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 rejectan activity on the workflow

4.3.2.3.11.The programming environment shall provide an API to reopenan 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 onthe current activity4.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 handleloops 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

8/7/2019 ATM SyRS v1_3

25/38


Version 1.3 12/7/2005

Page 21


4.3.2.3.16.The programming environment shall provide an API toassociate 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 used4.4.The system shall provide the functionality to manage resource groups

4.4.1.The system shall provide the functionality to create resource groups4.4.2.The system shall provide the functionality to associate resource groups with

a process domain4.4.3.The system shall provide the functionality to set the resource group status

to Active or Inactive4.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 policy4.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 policy4.4.4.4.The system shall support minimum cost as an allocation policy4.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 groupindividually

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

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

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

organization codes4.4.6.The system shall provide functionality to automatically update resourcegroup as users are added to or deleted from associated teams, roles and

organizations4.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 eachresource group member to be used for load based allocation

4.4.9.The system shall provide functionality to define a cost factor for eachresource 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 usingthe workflow5.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 asof the snapshot date

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

8/7/2019 ATM SyRS v1_3

26/38


Version 1.3 12/7/2005

Page 22


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

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

workflow5.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 correspondingevent takes place

5.3.1.The system shall execute all applicable global, process level, and activitylevel triggers

5.3.2.The system shall execute any global trigger(s) first, followed by processlevel 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 log5.4.The system shall provide the functionality to promote the task to the next

activity in the workflow5.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 oneactivity are next in-line in the workflow

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

5.4.4.The system shall collect all required data from the user and make itavailable 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 workflow5.5.1.The system shall allow process modeler specify the reject policy for eachactivity in the workflow

5.5.1.1.The system shall reopen the previous activity if reject policy isReopen Previous

5.5.1.2.The system shall allow the user pick the activity to reopen if rejectpolicy is Select Single Activity

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

5.5.1.4.The system shall not reopen any activities if reject policy isWorkflow

5.5.2.The system shall mark current activity Rejected and pick the earliestpending activity as the next activity to start5.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 activitysresource group

5.6.2.The system shall provide the functionality for the process modeler tooverride or turn-off reassignment of tasks within a resource group

8/7/2019 ATM SyRS v1_3

27/38


Version 1.3 12/7/2005

Page 23


5.7.The system shall automatically mark the task Complete when all mandatoryactivities in the workflow are completed

6.The system shall capture workflow execution history6.1.The system shall record each activity completion

6.1.1.The system shall record the performer for each activity step6.1.2.The system shall record the start and finish dates and other cycle time data6.1.3.The system shall record each invocation of an activity step separately6.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 forthe task overall

6.3.The system shall capture the actual activity level schedule along with the plannedactivity level schedule

6.4.The system shall capture the cycle time for each task stage6.5.The system shall capture earned value and schedule performance based of

workflow standards and task actuals7.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 workflowexecution environment

7.1.1.The workflow API shall follow the guidelines set forth by WfMC7.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 scriptingenvironment

7.3.The workflow engine API shall provide a SOAP interface

User Interface

8.The system shall provide a web based user interface8.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 administrativefunctionality

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 aresufficiently supported by the client browser

8.5.The system shall not require installation and maintenance of any software

modules, libraries or applications on the clients machine other than a HTML 3.2compatible browser

8.6.The system shall not use ActiveX or similar technology that limits the clientschoice of hardware, operating system or browser software to a single platform orvendor

8.7.The system shall use browser plug-ins or desktop productivity tools providedsuch use is not essential for the primary functionality of the system

9.The system shall provide role based portals

8/7/2019 ATM SyRS v1_3

28/38


Version 1.3 12/7/2005

Page 24


9.1.The system shall provide a portal (home page) for task owners9.1.1.The portal shall provide a monthly summary of owners tasks by stage and

need date9.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 taskowner and status

9.1.4.The portal shall provide a summary of tasks that needs to be completed inthe current month by task type and status

9.1.5.The portal shall provide links to team portals for teams that the userbelongs to

9.1.6.The portal shall provide links to last ten(10) tasks updated by the usersorted in descending update date

9.2.The system shall provide a team portal9.2.1.The portal shall provide a monthly summary of teams tasks by task type

and need date

9.2.2.The portal shall provide a summary of planned and actual hours by projectfor teams tasks9.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 activetasks owned by and assigned to each team member

9.3.The system shall provide a portal for team leaders9.3.1.The portal shall provide a monthly summary of team leaders tasks by task

type and need date

9.3.2.The portal shall provide a summary of planned and actual hours by project9.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 ofcurrent month by task type and status9.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 portal9.4.1.The system shall allow administrator define organization portals

9.4.1.1.The system shall allow administrator define the task selection criteriafor the portal (i.e. org code, project etc.)

9.4.1.2.The system shall allow administrator define the portal page title andadd 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 structure9.4.2.The portal shall provide a monthly summary of organizations tasks by tasktype and need date

9.4.3.The portal shall provide a summary of planned and actual hours by projectfor organizations tasks

9.4.4.The portal shall provide a summary of organizations tasks needed beforethe end of current month by task type and status

8/7/2019 ATM SyRS v1_3

29/38


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 thatmake up the portal page

10.The system shall provide the functionality to search tasks10.1.The system shall provide the functionality to lookup a task by its unique id10.2.The system shall provide the functionality to search tasks by document number10.3.The system shall provide the functionality to perform advanced searches by

user specified criteria10.3.1.The system shall allow administrator specify searchable task attributes10.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 attributevalues 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 criteria10.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 values10.5.The system shall provide the functionality to sort search results by attributes

specified by the user11.The system shall provide calendarized views

11.1.The system shall provide a weekly calendar view11.2.The system shall provide a monthly calendar view11.3.The system shall display current week/month by default11.4.The system shall permit navigation to the next/previous week/month11.5.The system shall display tasks on calendar view

11.5.1.The system shall place tasks on the calendar by the date attribute specifiedby the user11.5.2.The system shall allow user change the task date attribute used for

placement11.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 view11.6.1.The system shall place log records on the calendar by change date11.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 thecalendar 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 forsummary roll-up12.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 forsummary roll-up

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

8/7/2019 ATM SyRS v1_3

30/38


Version 1.3 12/7/2005

Page 26


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

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

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

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

Data Interface

13.The system shall interface with other enterprise systems13.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 systems13.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 format14.1.The system shall define and make available an XML schema for task data

interchange14.1.1.The system shall provide the functionality to export selected tasks and

attributes in XML format14.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 input14.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 thesystem in XML format

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

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

15.1.The system shall use a RDBMS supported by Infusient enterprise architecture15.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 tomanage its database interaction

15.4.The system shall use SQL to communicate with the database15.4.1.The system shall use standard SQL for all data access and manipulation15.4.2.The systems use of SQL extensions and other RDBMS vendor specific

functionality shall be limited to database triggers and functions15.4.3.The systems use of non standard SQL shall be limited to less than ten(10)

percent of the total system lines of code

8/7/2019 ATM SyRS v1_3

31/38


Version 1.3 12/7/2005

Page 27


Reporting

16.The system shall provide reporting capability

16.1.The system shall provide standard reports16.1.1.The system shall provide a task report16.1.2.The system shall provide a workflow report16.1.3.The system shall provide a change log report16.1.4.The system shall provide a timesheet report16.1.5.The system shall provide a task attachment report16.1.6.The system shall provide a report for task notes and messages16.1.7.The system shall provide a system user report16.1.8.The system shall provide a workflow cycle time report16.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 report16.3.The system shall provide report writing capability

16.3.1.The system shall provide the functionality to customize standard reports16.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 fromthe custom report

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

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

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

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

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

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

16.4.The system shall provide the functionality to export any report to Excel16.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 report16.5.2.The system shall allow user specify the page size (e.g. letter, legal, A4

etc.) for the PDF report16.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 taskattributes and MS-Project fields

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

8/7/2019 ATM SyRS v1_3

32/38


Version 1.3 12/7/2005

Page 28


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

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

17.1.The system shall provide an On-Time Delivery Metric chart17.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 input17.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 time17.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 late17.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 usingselected task attributes as chart dimensions17.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 format17.5.The system shall provide the functionality to generate charts in PNG format17.6.The system shall provide the functionality to convert charts to Excel charts17.7.The system shall provide the functionality to export chart data to Excel17.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 infrastructure18.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 whereit is technically and financially feasible

18.3.The system shall utilize existing Infusient problem reporting and help deskprocesses

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

infrastructure19.The system shall use open standards and formats where they are available20.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

8/7/2019 ATM SyRS v1_3

33/38


Version 1.3 12/7/2005

Page 29


21.1.The system shall authenticate users using unique login id and passwords21.1.1.The system shall enforce customers standards for assigning user ids21.1.2.The system shall enforce customers standards for password selection and

expiration

21.2.The system shall authenticate users for each access to the system21.3.The system shall provide LDAP integration for single sign-on support21.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 identifyuser accounts that are inactive beyond a threshold

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

21.6.The system shall provide the functionality to flag users that have beenterminated using employee status from customers employee directory (if

available)

22.The system shall provide application security22.1.The system shall grant access to only authenticated users22.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 theapplication with named privileges

22.2.2.The system shall allow administrators define user roles22.2.2.1.The system shall allow administrators define a role as a matrix of

privileges and ACLs22.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 userroles as needed22.2.3.The system shall allow administrators assign one or more roles to any user22.2.4.The system shall combine all privileges from the roles assigned to the user

to determine users privilege matrix

22.2.5.The system shall match users privilege matrix with the privilege requiredfor access and grant or deny access accordingly

22.3.The system shall perform user authorization for each access to restricted objectsor functionality

22.4.The system shall provide field level security22.4.1.The system shall allow administrator associate selected task attributes

with privileges22.4.2.The system shall check for the required privilege prior to granting editaccess to any task attribute

23.The system shall provide session management functionality23.1.The system shall ensure login session and transaction integrity across requests23.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

8/7/2019 ATM SyRS v1_3

34/38


Version 1.3 12/7/2005

Page 30


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

23.3.The system shall support and enforce session and transaction timeouts23.3.1.The system shall allow administrator specify session and transaction

timeout values23.3.2.The system shall abort transactions that are timed out23.3.3.The system shall cancel sessions that are timed out23.3.4.The system shall automatically collect and reuse session resources and

allocated objects after timeout

23.4.The system shall provide secure communications23.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 inTable B-1 ATM Availability Requirements

25.The system shall meet or exceed the performance requirements25.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 requirements26.1.The system size shall stay within the sizing requirements listed in

Table B-2 ATM Sizing Requirements

8/7/2019 ATM SyRS v1_3

35/38

ATM SyRS Document# EM-SRS-01

Version 1.0 12/7/2005


Page A-1

Appendix A: Task Attributes

Attribute DefinitionTask 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 capturedEstimated Hours defaulted from standard hours in the workflow

Actual Hours user entered or pulled in from customers timesheet system

Requesting Org defaults to requesters org code

Responsible Org defaults to task owners org code

Performing Org defaults to responsible org

Generic Task Attributes to be used as needed to support customer specific functionality

8/7/2019 ATM SyRS v1_3

36/38


Version 1.0 12/7/2005


Page B-1

Appendix B: Requirements Tables

Table B-1, ATM Availability Requirements, imposes graduated availabilityrequirements 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).

8/7/2019 ATM SyRS v1_3

37/38


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 HoldingsVolume (GB)

3.58 5.48 7.77 10.64 1