UW System and Campuses Framework for IT Project Management –Requirements Definition

Overview

  1. Business Requirements

The Purpose of the project is to create an IT project management resource consisting of:

  • Basic project workflow and activities applicable to common IT projects.
  • Templates for essential project management artifacts
  • Links to online resources for developing essential project management skills
  1. User Roles

These are users that interact with the business process or system. They either use results of the process or rely on the system for results.

Role / Description and Activities
UW System and Campus IT Staff / UW System staff needs a resource with basic project management information including templates, examples and procedures.
  1. Assumptions: Identify anything that adds clarification to or provides background information about the requirement statement, or other related item.

  • The final resource will apply to medium and small projects.

  1. Constraints: Identify anything that puts limits on implementing the requirements.

  • Creating this resource should not require any procurement.
  • Project must be completed by May 14, 2013.

  1. Dependencies: Detail any external event, condition, or system that must be in place for a requirement to be valid.

  • Identification of location to store files post project that is accessible to distributed UW staff.

  1. Out of scope:Work that is beyond the delivery of a defined product, service or process result is considered out-of-scope or beyond what is to be accomplishedby the project.

  • Continuous updates of the results after the end date of the project.

  1. Requirements

Prioritization key: P1: essential, P2: highly beneficial, P3: valuable but can be considered for later

User Role – as defined in section (2.)

Goals – objectives to be met as set by the user as necessary outcomes

  1. User Requirements

User-level requirements are written from the user role’s perspective. Named information is shown quoted in these requirement statements. Information used in the user-level requirements is described in the “Common Information” section below.

  1. Functional Requirements

Functional requirements are written from the system’s (features or functions) perspective. What must the system do to support the user role? Information referenced in the functional requirements is described in the “Common Information” section below.

User Role: UW System and Campus IT staff
Priority Code / Goal U1 / Basic project workflow and activities applicable to common IT projects.
P1 / U1.1 / Focus on small and medium size projects
P1 / U1.1F1 / Information files should be available for use by UW system staff
P1 / U1.1F2 / Information needs to remain current
P3 / U1.1F3 / Information needs updating after the project end date
P1 / U1.2 / Define common IT projects covered by this work
P1 / U1.2F1 / Application upgrades
P1 / U1.2F1 / Service enhancements
Priority Code / Goal U2 / Templates for essential project management artifacts
P1 / U2.1 / Documents are in common file types
P2 / U2.1F1 / Word and excel formats and other common file types
P1 / U2.1F2 / Templates can be edited for individual projects
P1 / U2.2 / Templates need to be easily accessible
P3 / U2.2F1 / Template files should be distributed physically on memory sticks
P2 / U2.2F2 / Hosted on a website
P3 / U2.2F3 / Website is attractive and pleasing to the eye
Priority Code / Goal U3 / Links to online resources for developing essential project management skills
P1 / U3.1 / Resources should provide current information to solve immediate issues.
P3 / U3.1F1 / Resources will need future updating to stay current.
P1 / U3.2 / Resources should be outlined for professional development in project management.
P3 / U3.2F1 / Resources will need future updating to stay current.
  1. Non-functional Requirements

Nonfunctional requirements focus on the qualities that must be applied to design and implement the system. These are specific standards and attributes in support of the other requirements. Following are a sample of possible non-functional requirements. Some, none or all may apply to your project depending on its characteristics and environs. The following list represents possible characteristics for a project as a guide to determine the non-functional requirements for your project.

  1. Product

NF1 / Availability:The results of the project need to be readily accessible to UW system staff via a UW System website.
  1. Service Provider

NF2 / Business Continuity:After May14, 2013, which is the completion of the ITLP project, UW system will own the project results and be responsible for any updating or future development.
  1. Infrastructure/Environment

NF3 / Web-based Authentication and Authorization:Access to the project results will rely on UW System staff logging in to the UW System portal.
NF4 / Client Operations Environment: Downloaded files shall be operable on the following hardware/software platforms:
  • Microsoft Windows
  • Mac OSx

  1. Security

NF5 / Data Security: UW System shall host the website and protect against anticipated threats or hazards to the security or integrity of University data, and protect against unauthorized access to or use of University data.
  1. Legal

NF6 / Access by Individuals with Disabilities: The service shall be accessible and usable to qualified individuals with disabilities.
  1. Contractual

NF7 / Brand Ownership:All data and documents created and/or processed by the project is and shall remain the property of UW System and the UW System Board of Regents.
  1. Common Information

In the other Requirements subsections, specific information that is referenced multiple times may be described once here. This “named information” may then be referenced by its name with quotes around it in the rest of the document.

Named Information / Definition and Usage
Templates / Files to be downloaded serving as a framework document to be completed by the user.
Name
Name
  1. Validation History – Specific stakeholders and roles/areas of expertise

Participant Index
ID / Stakeholder Name / Specific Role or Area of Expertise
P1 / Project Sponsor / Approve the final result.
P2 / Project Staff / Compiling information and templates about project management.
P3
  1. Outcomes – Track identifiable issues from functional and non-functional requirements.

A = Accept, C = Accept with Conditions, R = Reject

Review Date / Overall Outcome / Participant Outcome(s) / Identified Issues
01/20/13 / R / Template files should be distributed physically on memory sticks / U2.2
  1. Requirements Issues – Track identifiable issues from outcomes.

Status: Closed, Open

ID / Description / Assigned to / Status
IS1 / Project Team needs to find a website to host final template and informational files. / Staff committee on final product location / Open
IS2
  1. Specific Terms or Acronyms – Define terms/acronyms unique to the requirements document.

Term/Acronym / Definition
ITLP / Information Technology Leadership Program – UW System
  1. Revision History – Track changes to the document.

Updated By / Updated On / Reasons for the Change
Project Staff / November 20, 2013 / Original document.
Project Staff / January 22, 2013 / Requirements refined at project staff meeting.
Page 1 of 5