Professional Consulting Group One (PCG-1)

User Requirements Document

Prepared for:

VIVC, Inc.
(Very Important Venture Capitalist)

Regarding:

APMS – Distributed Project Management Tool

November 12, 2006

Brian Allain
Nancy Johnson
Scott Shipley
Ginger Wilkinson

Page 1 of 20
Document Status
Project Title T1003
System/Subsystem Title User Requirement Document
Document Issue Date November 12, 2006
Revision Number 1
Client Reference RE003
Status Final

Approval
Role Name Signature Date
Author G Wilkinson
Author B Allain
Technical Approval S Shipley
Project Manager N Johnson

Page 2 of 20
General

Abstract

Managing large scale projects for global teams is not adequately supported by
software today. The existing Project Management Software (PMS) only
addresses a small portion of the overall tasks required for these projects and fails
to meet the needs of a widely-distributed workforce in multiple geographic areas
across multiple time zones.

There is a significant opportunity to capitalize on the rapid advances in internet-

enabled technology, combined with our enhanced understanding of the business
needs of globally-dispersed project teams and the fact that project management
must be closely linked to the strategic management of those organizations.

This document defines the user requirements that, when implemented, will
demonstrate the qualities and functionalities that sufficiently differentiate APMS
from its competition. It provides a lucrative investment opportunity and allows
APMS a quick and significant gain in market share, and consequently positions
APMS as a key player in the Distributed Project Management Software (DPMS)
market.

Page 3 of 20
 CONTENTS
Document Status 2
Approval ......................................................................................................................... 2
General 3
Abstract ........................................................................................................................... 3
Table of tables................................................................................................................. 5
Table of figures ............................................................................................................... 5
Introduction 6
Purpose............................................................................................................................ 6
Scope............................................................................................................................... 7
Business Goals ............................................................................................................ 7
Domain Concepts........................................................................................................ 7
System Overview ........................................................................................................ 8
List of Definitions ........................................................................................................... 9
List of References ......................................................................................................... 10
Overview....................................................................................................................... 10
General Description 11
Product Perspective....................................................................................................... 11
General Capabilities...................................................................................................... 12
General Constraints....................................................................................................... 13
User Characteristics ...................................................................................................... 14
Environment Description .............................................................................................. 14
Product Interfaces ..................................................................................................... 15
Specific Requirements 15
Capability Requirements............................................................................................... 15
Constraint Requirements............................................................................................... 18
Appendix 19
Appendix A - IEEE Implementation Constraint Considerations.................................. 19
Appendix B – Use Cases............................................................................................... 20

Page 4 of 20
 Table of tables
Table 1: Intended audience of this document .................................................................... 6
Table 2: Main domain concepts of the users ..................................................................... 7
Table 3: System overview - Key functions........................................................................ 8
Table 4: References.......................................................................................................... 10
Table 5: Project Management Life Cycle ........................................................................ 12
Table 6: Use Case Descriptions ....................................................................................... 13
Table 7: High level system operational constraints ......................................................... 13
Table 8: User Characteristics ........................................................................................... 14
Table 9: Functional requirements .................................................................................... 16
Table 10: Non-functional requirements (quality attributes & their properties)............... 17
Table 11: High level system operational constraints ....................................................... 18

Table of figures
Figure 1: System context ................................................................................................. 11
Figure 2: Use Cases ......................................................................................................... 12

Page 5 of 20
Introduction
Purpose

The purpose of this document is to define the user requirements for Advanced
Project Management Systems’ (APMS) new DISTRIBUTED Project Management
software tool suites: APMS-DPM (Business release version) and APMS e-
DPM™ (Enterprise release).

This user requirements document helps demonstrate and document how APMS’s
products have qualities and functionalities that are sufficiently differentiated from
its competition as to allow APMS to gain significant market share quickly, and
thus rendering APMS a key player in the DPM Market.

This document is being prepared exclusively by PCG-1 (Professional Consulting

Group One) for APMS specifically for the purpose of apprising VIVC (Very
Important Venture Capitalist) of the unique capabilities that will place the DPM
product suites in high demand within the burgeoning Distributed Project
Management Market (Reference Forrester Research report) thereby making
APMS DPM tools a lucrative investment opportunity.

Table 1: Intended audience of this document

Reviewer
Reasons for Reviewing
Group
VIVC Investor To obtain additional information from the user’s perspective about how this tool
group will be used in the market, to further demonstrate investment worthiness
To confirm that the requirements are expressed from the user’s perspective and
APMS
have been done so such that they are in alignment with the stated company
Executives
strategic goals
Users and To give APMS feedback about the system requirements from a user’s
customers perspective
System To understand what functions and properties the customers and users believe
developers DPM and e-DPM™ must include and deliver.
To exercise the system functions and ability against the stated requirements,
Testing Staff
verifying satisfaction of needs.
Technical To be able to ascertain sufficient system use materials to be able to construct
Writer Staff and publish the user manuals
Project team To provide status of the project against the user requirements

Page 6 of 20
Scope

The non-distributed project management products today simply are not designed
to support a widely disbursed workforce, usually requires a “thick” client, and thus
fail to leverage all of the capabilities offered through internet technologies.
Additionally, as was usually the case with these legacy tool suites, features such
as time zone management and role based thin client administration and
dashboard controls were not considered. Updating reports and publishing
content did not leverage the capabilities of an internet based distributed tool.

Business Goals

The Business Goals that the new APMS DPM and e-DPM™ product suite
address include: extensive use of remote and internet based distributed
workforce; the explosion of sourcing into the marketplace; and the general trend
for collaboration heighten the need for a distributed project management tool.

Integrally woven into these business goal areas is the need for project
management that supports a disparate and globally diversified project horizon
and project workforce.

Domain Concepts

Within the main Distributed Project Management Domain, customers are finding
developments in project management methodology and processes, and an
industry trending towards virtual and globally disbursed project teams. These
findings offer new opportunities for the development of distributed project
portfolio management systems.

Table 2: Main domain concepts of the users

Concept Description
Virtual So many of the members of our team now work from remote locations. We really
Workforce need a way to effectively manage projects across this expanse.
Our budget constraints and need for ever increasing efficiencies have lead us to
Sourcing use more and more of the commoditized resources from external sources. The
Influx sourcing really adds to the mix of being able to communicate with our colleagues
who are not even employees of our company.
The need to integrate remote and partnered resources really calls upon
consideration of member’s ability to access centralized planning resources, taking
Collaboration
into considerations disparate time zones, easily incorporating data from other
Trend
resources, and easily making status data available to the browser based
audience.

Page 7 of 20
System Overview
APMS is becoming a key player in the DPM Market by offering products suites
that exceed our competitors in the areas of functionality and quality attributes.
The following table gives examples of key areas that DPM and e-DPM™
products are superior to the competition:
Table 3: System overview - Key functions
Hierarchical
Category Requirement
Upload historical corporate data &
Project Integrate standardized
Startup methodologies
Create roll-up scorecards of key
business metrics. Measure
progress to the objectives
Control (metrics).
Forecast resource requirements
for short-term and long-term
capacity resource allocation and
assignments by centralized
Planning resource scheduling
Estimate project resource
demands in order to determine
Planning hiring needs
Centralized tracking system that
enables teams to record, assign,
and resolve issues ( customizable
Execution by time zone or geographic area)
Central repository with version
and editing control features to
Control develop,
Assign role-based access to
system information/ Security /
Control Authentication, Authorization
Page 8 of 20
Description: Short Paragraph "what"
not "how"
Information from previous product
management systems can be imported
with ease into the APMS product. PM
practices are either emulated or
transitioned.
Provide role based customizable
dashboards and scorecards view real
time performance and perform
predictive analysis that supports
forecasting cost, scheduling and
resource requirements. Additional
modules support alerts, user’s workload,
calendars, upcoming milestones and
issues.
Management can view demand and
skilled/available resources to forecast
projects with the highest win confidence.
They can also create consistent
processes to assign the right resources
to the right positions on the right
projects the right time.
Project managers can maintain a skill
inventory, assign personnel to skills,
and assign skills and personnel to
project tasks.
Provide users with a role based,
customizable, real time tracking
includes roles, time zone and
geographic area so that the user can
view the project according to their
needs.
Distributed Project Members are able to
easily use the version controlled
document repository.
User roles can be selected from a
standard list of roles or additional roles
can be custom defined. User roles are
configurable to tailor the access
authority granted to each role. .
 Hierarchical Description: Short Paragraph "what"
Category Requirement not "how"
Organizations are able to staff and
manage geographically-dispersed
Work in multiple time zones. teams by delivering and accessing
Access system from any applications and data securely and
Execution geographic location quickly,

List of Definitions

Constraint: A factor that is imposed on the system by force or compulsion,

provides measurable boundaries, and may limit or modify the design changes.

Client: A computer system that accesses a remote service on another

computer (server) by some type of network. A “thick” client performs the bulk of
any data processing operations itself and does not readily rely on a server on the
network. A “thin” client uses the resources of an application server which
performs the bulk of the data processing, and requires that the client be
networked to the server in order to access the results of the processing.

Customer: The person, organization, or company for whom the requirements

are to be satisfied in the system being defined and developed.

Distributed project management (DPM) software: Internet-enables software

with a set of project management functionalities designed specifically for use by
geographically-dispersed teams in a global environment.

Environment: The circumstances, objects, and conditions that will influence the
completed system.

Function: A task, action, or activity that must be accomplished to achieve a

desired outcome.

Requirement: A condition or capability needed by a user to solve a problem or

achieve an objective. Functional requirements describe what the system will
do. Non-functional requirements, or quality attributes, describe the system’s
intended behavior within the environment for which it was built and provide the
means for measuring the fitness and suitability of a product.

Role-based access Control: An approach to restricting system access to

authorized users.

System: An interdependent group of people, objects, and procedures created to

achieve defined objectives or some operational role by performing specified
functions. A complete system includes all of the associated equipment, facilities,
material, computer programs, technical documentation, services and personnel

Page 9 of 20
required for operations and support to the degree necessary for self-sufficient
use in its intended environment.

Use Case: A technique for capturing functional requirements for systems. Each
use case provides scenarios that convey how the system should interact with the
users to achieve a specific business goal or function.

User: The person or persons who will ultimately be using the system for its
intended purpose.

List of References

Table 4: References
Name
IEEE Std 830-1993 - 00392555
IEEE Std 1220-1998
Description
IEEE recommended practice for software requirements
specifications
IEEE standard for application and management of the
systems engineering process

Overview

The remainder of this document consists of two sections. The General

Description highlights the key differentiating features and capabilities. The
Specific Requirements section discusses specific functional requirements. As
the product is intentionally constrained to internet protocols and related
technologies, a list of operational constraints is also provided for each section.

Page 10 of 20
General Description
Product Perspective

Advanced Project Management Systems’ (APMS) new DISTRIBUTED Project

Management software tool suites: APMS-DPM (Business release version) and
APMS e-DPM™ (Enterprise release) represent the new state of the art in project
portfolio management software solutions. Key features provide the project
management tools needed by today’s virtual project teams that

• Maximize resource productivity

• Ensure collaboration at all levels
• Measure productivity & quality
• Improve decision-making process
• Track costs, schedule, and risks.

Incorporating current best-practice project management theory, the complete

project lifecycle is supported: Project startup, Planning, Execution, Control, and
Closing.

The use of industry standard web services, internet networking, database,

directory services, and role-based access controls; both products can be
deployed in a wide variety of business environments. Whether the selected
solution is the AMPS-DPM Business release version intended for small project
groups or the AMPS e-DPM™ Enterprise release version intended for large
project groups and complex project management; the business customer is
provided a solution that is simple to deploy, integrates with existing business
processes and tools, is scalable, reliable, and easy to use.

Figure 1: System context

Page 11 of 20
General Capabilities

In order to understand the capabilities required by users of the proposed AMPS

distributed project management products, PCG-1 prepared several use cases to
describe key functions. The following use case diagram illustrates the use
cases. The use case descriptions are contained in Appendix B.

e-DPM
Import
Historical Data
Legacy
System
View
Dashboard
User

Track Issues

Project View Demand

Manager Pipeline

Corporate
Add New User identity
registry
Authorizing
Manager

Figure 2: Use Cases

PCG-1 believes that the capabilities of distributed project management products

are best organized by the project management phases described in PMBOK
theory. The following phases of the project management lifecycle are defined by
PMBOK.

Table 5: Project Management Life Cycle

Phase Description
Project Startup The user tasks required to define a project
Planning The user tasks define the details of a project
Execution The user tasks that track project issues and activities
The user tasks and system processes that manage user access to project
Control
resources and track project deliverables activity
Closing The user tasks association with project completion

Page 12 of 20
The use cases developed by PCG-1 are intended to illustrate a key capability
supporting one or more of the PMBOK project phases.

Table 6: Use Case Descriptions

Use Case Description
Information from previous project management systems can be imported with
Import Historical Data
ease into the AMPS product.
The events that occur when a user requests information via the project
View Dashboard
management dashboard.
Track Issues TBD
The events that occur when a user requests information pertaining to the
View Demand Pipeline
availability of skilled resources.
The events that occur when a request is received to add a new user and
Add New User
assign project roles.

A detailed list of key capabilities is provided in the Capability Requirements

section of this document.

General Constraints

As with any development project in which there are limits on resources, APMS
will constrain their product development to focus on those considerations which
best position the product offering in the marketplace in accordance with the
strategic goals and business objectives, and with the prioritized needs of the
stakeholders.

The product will be intentionally constrained to internet protocols and related

technologies. Additionally, some of the more relevant constraints are listed here,
with additional functionality-dependent constraints delineated in the Constraint
Requirements section.

Table 7: High level system operational constraints

Traces to use
ID Ver Constraint Source Rationale Priority Status
cases
The user interface People have
must run on any Technical different All use cases
C1 1 well-known browser Coordinator browsers – we Must Proposed with browser
including IE, Opera N.N want to serve interface
and Mozilla. them all.
The transactions Proprietary or
are communicated Architect LAN based
Integrated Transactional
C2 1 via standard Stakeholder protocols Must
to J2EE use case
internet protocols B.J.A. defeat ubiquity
only. of app.

Page 13 of 20
 Traces to use
ID Ver Constraint Source Rationale Priority Status
cases
J2EE allows OK on
Alternate Operating Ease of
Developer Penetration of Linux,
D7 2 system are High deployment
stakeholder market across Windows,
supported and integration
OS types and UNIX
Wide support
Major relational and Common OK on Import
DBA
A3 1 databases are interface allow High Oracle, MS historical data
stakeholder
supported for market SQL and integration
penetration

User Characteristics

Table 8: User Characteristics

Role Description
Executive Sponsor Executive Sponsor
Project Sponsor / Directors Project Sponsor / Directors
Steering Committee Steering Committee contains representatives
from organizations that have a stake in the
project.
Project Manager Project Manager for the project.
Team Members Team members come from many areas within
the organization or they can be outside
consultants. Some of the roles that they will fill
are: Technical Managers, Functional
Managers, program analysts, functional
business analysts, subject matter experts, data
delivery specialists, external consultants,
readiness leaders, trainers, DBAs, testing
team, infrastructure experts, data
administration, etc.
Customers Business Customer and End Users

Environment Description

PCG-1 envisions APMS-DPM (Business release version) and APMS e-DPM™

(Enterprise release) products that include a web-based Dashboard user
interface, project management software modules, a central database, a workflow
engine, reporting, data import and export, and methods for accessing corporate
identity directories. Multiple operating systems are supported including Linux,
UNIX, and Windows.

The Dashboard user interface supports all categories of users and can be
tailored for each user group and individual user. Users are granted access to
project resources based on configurable project roles.

Page 14 of 20
The project management software modules support basic project management
tasks such as project creation, team assignments, project task definition and
tracking. Advanced project management tasks include project resource
forecasting, optimization, and demand management; project scheduling and
tracking across multiple time zones; and project cost management. Project
portfolio capability allows multiple projects to be managed concurrently within a
common framework.

A suite of standard table definitions and procedures provided support the

customer’s choice of deployment in several of the market leading databases.
The project database can be deployed locally or on distributed database servers.

User information can be imported from corporate identity directories and user
authentication can be integrated into the customer’s single sign on infrastructure.

A reporting capability produces structured and ad-hoc reports in multiple file

formats.

Data import and export facilities facilitate the upload of corporate data and
download of project data.

Product Interfaces

• Corporate identity directory

• Other project management products
• Business finance systems
• Business document management systems
• Web proxy services
• Web services

Specific Requirements
The user requirements presented in this document represent key functional
capabilities, qualities, and constraints of the proposed AMPS project
management products. The focus is the user functions and qualities required to
1) realize the goal of AMPS to become a key provider of distributed project
management solutions, 2) differentiate AMPS from competitors in the
marketplace, and 3) allow AMPS to quickly capture market share in the
distributed project management product domain.

Capability Requirements

In addition to the General System Capabilities discussed in the General

Capabilities section above, this section outlines the capability requirements that

Page 15 of 20
define the key user requirements and qualities that distinguish the AMPS project
management products from other project management products in the
marketplace.

Respective to the individual use cases highlighted in the Concept of Operations,

the four use case scenarios include one or more of the following capability and
quality requirements:

Table 9: Functional requirements

Traces to use
ID Ver Feature Requirement Source Rationale
cases
The user shall be Allow users to view real
Product
able to create roll- time performance and Request
CF1 1 Control Manager
up scorecard cost measurements and Measurements
N.N.
reports metrics.
The user shall be Allow users to perform
Product
able to track predictive analysis that Request
CF2 1 Control Manager
project level supports forecasting Measurements
N.N.
budgets project costs.
Project deliverables can
The user shall be Product be accessed from a
CF3 1 Control able to manage Manager central repository that TBD
project deliverables N.N. includes version and
access controls.
Project team members
The system shall
Product are assigned project roles.
provide project
CF4 1 Control Manager Project roles determine Add New User
team role
N.N. access to project
categories
functions and resources.
The user shall be Product Project team members
EF1 1 Execution able to record Manager have visibility of project Track Issues
project issues N.N. issues.
The user shall be Collaboration capability
able to assign Product allows project issue
EF2 1 Execution project issues to Manager management to be Track Issues
project team N.N. distributed to project team
members members.
Project issues are tracked
The user shall be Product through issue resolution.
EF3 1 Execution able to update Manager Project team members Track Issues
project issue status N.N. have visibility of project
issue status.
To support geographically
The user shall be
dispersed virtual project
able to work in the Product All use cases
teams, date and time data
EF4 1 Execution time zone of the Manager including
should be presented in
user’s geographic N.N. date/time data
the local date/time
location
representation of the user.

Page 16 of 20
 Traces to use
ID Ver Feature Requirement Source Rationale
cases
Project management is
The system shall Product All user cases
essential to all product
EF5 1 Execution provide support for Manager with browser
and service development
multiple languages N.N. interface
regardless of nationality.
The user shall be View project resource
Product
able to forecast demand and available Allocate
PF1 1 Planning Manager
project resource skills and project Resources
N.N.
requirements resources.
Skill and resource
The user shall be allocation and availability
Product
able to determine data combined with Allocate
PF2 1 Planning Manager
project hiring finance and project cost Resources
N.N.
needs data facilitates project
hiring decisions.
The user shall be
Product Integrate the
Project able to upload Import Historical
SF1 1 Manager organization’s existing
Startup historical project Data
N.N. project management data.
data

Table 10: Non-functional requirements (quality attributes & their properties)

Quality
Traces to
ID Ver Requirement Attribute Rationale
use cases
type
All user
Project management Virtual project teams can be
cases with
QA1 1 system is available Availability geographically dispersed and
browser
when needed working in multiple time zones.
interface
Import wizard shall
Provide simple and easy Import
recognize primary
QI1 1 Interface integration of historical project Historical
project management
data. Data
data file types
User role should determine the
Access to project
level of user authority within the
management Add New
QM1 1 Modifiability project management system and
functions is based on User
the user access level for project
user role
data.
Project data updates are dynamic,
Project data
either the result of user input or All user
presented in the user
update or system task automation. cases with
QP1 1 dashboard is current Performance
Dashboard users require browser
at the time of the
information that is current at the interface
request
time of the request.
Project teams should be able to
determine issue categorization,
Issue tracking is Track
QU1 1 Usability issue data that needs to be
customizable Issues
tracked, and the presentation of
issue data.

Page 17 of 20
Constraint Requirements

In addition to the General System Operational Environment Constraints listed in

the General Constraints section above, this section outlines the constraint
requirements that set restrictions on how the user requirements are to be
implemented.

To facilitate continuity with the previously provided Concept of Operations, this

User Requirements Document will constrain consideration to the use cases that
were presented therein.

Respective to the individual use cases highlighted in the Concept of Operations,

the four use case scenarios have constraint requirements as follows:

Table 11: High level system operational constraints

Traces to
ID Ver Constraint Source Rationale Priority Status
use cases
project manager or Control input to
their designee will PM / and format of
View
U1.1 1 have admin Coordinator dashboard, Must Proposed
Dashboard
privileges for the N.J Access control,
dashboard Auth. of users
Users must use a
web browser that PM / Ubiquity of use,
View
U1.2 1 is compatible with Coordinator deployment / Must Proposed
Dashboard
the dashboard N.J implementation
implementation
wizard designed to
Architect Customer use,
work with last 2 load
U2.1 2 Stakeholder ease of High Proposed
release of: IBM, historical
B.J.A. implementation
Project, Primavera
Importation
requires networks Migration and
DBA lead: load
U2.2 1 that can startup - Preferred Proposed
M.C historical
communicate with implementation
one another
Resource Mgr’s Resource Mgr’s
assigned to job Info Protect must have a web
Demand
U3.1 1 roles, and have and Security browser and Must Proposed
Pipeline
update capability officer: L.T. authority to view
only for those roles the data
“Project manager”
Add new user,
privileges will have
PM / Update user Role based
U4.1 2 the authority to Must Proposed
Coordinator profile, Grant access
perform the
access to project
following actions

Page 18 of 20
Appendix
Appendix A - IEEE Implementation Constraint Considerations

Constraint requirements set restrictions on how the user requirements are to be

implemented.

• Interface Requirements.
How external interfaces with other systems must be done.
An interface is a boundary between two systems. It can be described in terms of what is
exchanged across the boundary.
o Communication Interfaces.
The networks and protocols to be used.
o Hardware Interfaces.
The computer hardware the software is to execute on.
o Software Interfaces.
How the software should be compatible with other software: applications, compilers,
operating systems, programming languages, database management systems.
o User Interfaces.
Style, format, messages, responsiveness.
• Quality Requirements.
o Portability.
How easy it is to move the software from one environment to another.
Measured in terms of lines of code or modules that do not have to be changed when
porting the system.
These can be absolute of relative measures.
o Adaptability.
How easily a system copes with requirements changes.
o Availability.
The ability to use the system during its intended period of operation:
"The user shall be provided with 98% average availability over 1 year during working
hours and never less than 50% of working hours in any week."
o Security.
A secure system protects users from their own errors as well as the illegal activities
from unauthorized users.
"No single event, such as a fire, should cause the loss of more than 1 week's
information."
"Unauthorized users shall be unable to use the system."
o Safety.
How the users should be protected from software and hardware faults.
"No data shall be lost when a power failure occurs."
• Other Requirements.
These are not described in the URD, but in the Software Project Management Plan (SPMP).
o Standards. Process Standards and product standards.
o Resources. If information is available about the resources for producing and
operating the software, they are stated in the SPMP.
o Time scales. Acceptable time scales for development and production.

Page 19 of 20
Appendix B – Use Cases

AMPS - URD Use

Case.doc

Page 20 of 20