H o w

Transcription

H o w

H
Ho
ow
w tto
ou
usse
eT
TH
HE
EG
Gu
uiid
de
eT
Te
em
mp
plla
atte
ess
This Template is an overview for THE Guide’s Templates. Press a blue item (while pressing control, if
needed) below to jump to a topic in this Template
This Template Topics
1. Purpose and Features of the Templates
2. Using the Templates in Microsoft Word
3. Using the Templates
a. A Project Scenario
b. Getting Started with the Working Templates
c. Jumping to a Deliverable Template
d. Beginning-of-Phase Use of the Templates
e. End-of-Phase Actions
f. The Quality Logs
g. The Other Project Management Templates
h. Using the Templates for Remaining Results
i. End of Template Actions
4. Summary
Sample Templates (ctrl+click to review one of the sample templates)
1 Large Project
Requirements
Specification
2 Medimum Proj
Requirements
Document
Copyright 2001, 2002 ProjectExperts
1. Purpose and Features of the Templates
Purpose
About half of all people perform better in unfamiliar work if they have an example or template that
shows what the results should look like. The purpose of the Templates is to provide that reference for
our customers.
THE Guide Templates provide a framework for improved Templateation of results in a Guide project.
They are for system engineering and project management results that complement, rather than
replace your other tools. For example, in addition to the Templates, you should use your
organization’s tools for scheduling and tracking (project management software) or CASE tools or
Repository Management tools (for system engineering results).
Three Template Types
There are three different types of templates, each with a distinctive color on the heading bar:
 Working Templates (red heading bar), to record step-by-step outputs of each activity
 Deliverable Templates (green heading bar), summarizes major results for managers and customers
 Project Management Templates (purple heading bar), to improve your project management results.
Features
There are Templates for Large, Medium, and Small Projects with the following features.
Feature
Easy project and
phase identification
Description
Each Working Template starts with an abbreviation to indicate project
path, size and phase.
Example: “mc1_initiate.doc” is the template for the first phase of a
Medium Component design project.
Structured, easy-toreference results
The template pages are sequenced by number and name so you can
quickly:
 correlate results with activities depicted on the project roadmaps
 find relevant detailed information in The Online Guide, and
 refer to specific results for review or other purposes
Tools for managing
the project’s results!
Each template collection incorporates the key project planning elements to
help you plan the project, complete individual activities, manage issues
and change, assure quality, and get management approval. Each phase
Working Template summarizes with a process check on your Basic 9
Results.
Project Management templates
 Issues Log and Issue Forms
 Change Log and Change Request Forms
 Quality Log and Quality Review Forms
Easy to use and
customize
The templates can be used and customized using standard Microsoft Word
features.
Not a Substitute
The Templates do not replace The Online Guide activity descriptions. They provide high-level context
and instructions for capturing and organizing your project results. For step-by-instructions, tips, and
recommendations on how and when to produce results, you will want to refer to The Online Guide.
Templates Page 2
2. Using the Templates in Microsoft Word
You can use and edit the Templates using the standard features of Microsoft Word. Here we describe
how to use the features that we think may be new or infrequently used by most users.
Feature
How to Use / What to Note
Links
Each template has a table of contents with links to topics. You may have to use
CTRL + Mouse Click to use the links. It also depends on whether you start a
Template from The Online Guide Index from your Intranet, or directly from Word.
Note: This is a Microsoft Word behavior and not a problem with the Templates.
Tables of
Contents
Word automatically updates a table of contents when you exit and re-open a
Template. To update the table of contents within a Word session, do the
following:
 Right-click your mouse anywhere in the table of contents.
 Select “Update Field” from the mouse-induced menu.
Form Fields
Form fields (where you insert text or links to other Templates) will show as blue
text. All other text is black.
Seeing and
Printing
Hidden Text
All of the templates contain hidden text with hints and secret messages.
To see your template’s hidden text, go to
Tools > Options > View tab and check () Hidden Text ( All does the same
thing)
 To print hidden text, go to
Tools > Options > Print tab and check () Hidden Text
Important:
If you skipped over the Hidden Text feature above, go back and read it, then turn on Hidden Text.
Can you see this? No, the “If you can see this line, below.
Checking Those Boxes
We originally built the templates as protected forms; however, unprotecting, then reprotecting
causes the forms to lose data. A Word security feature, we can only guess… So how do I check or x a
box?
Three ways, in recommended priority sequence:
1. Right-click the checkbox. Select Properties. Select the Checked radio button. Select OK.
2. Copy one that is already checked (there is often one nearby) and paste it into position. The
checkboxes always use the same style, that we call text, a blue typeface so you can discern
your entries from the labels.
3. Protect the form: Tools | Protect Template | Forms | OK. Click the box(es) you wish to check,
then unprotect the Template on the Tools menu. It doesn’t lose checkmarks.
Adding Pages
You need to add pages because of the size of your information, or to embed a graphic model of your
system. In addition to inserting a new page (Control+Enter), copy the page title and paste it at the
top of the new page. Then adjust its style as follows:


The first page of a topic has a heading style of Heading 1; this appears in the Table of Contents.
Subsequent pages have a heading style of Heading 2; it does not appear in the Table of Contents.
If you make changes, update your Table of Contents: right click the current contents; select Update
Field. Select Update Page Numbers Only; press OK.
Templates Page 3
3. Using the Templates
To familiarize yourself with THE Guide and the Templates, follow this short tutorial while referring to
THE Guide. After you are familiar with THE Guide and the Templates and how they work together;
then then you can make changes to adapt both to your preferences and organizational needs.
A Project Scenario
You are at the beginning of a project, and you and your team have used Plan By Example (working
with your Project Office or Guide internal experts) to perform project startup. You have determined
that the project is Medium in size, and will possibly involve the purchase of a software package.
You will begin using the Templates by recording results for the first phase.
a. Getting Started with the Working Templates
1. Read THE Guide Overview for Phase MP1 to gain context for the next steps.
2. Navigate to your project folder (either locally or on your intranet, depending on where you have
set your data preferences). Open mp1_initiate.doc, the first Medium phase working Template.
3. Familiarize yourself with the template, scrolling through or jumping to the pages from the links on
the Contents page.
4. Using The Online Guide, read THE Guide description for Activity MP110, and then use the Working
Template to record information in the Output 110 fields. Try recording, then deleting (erasing
entries) the name of the Charter review approver, near the top of the page, and checking and
unchecking boxes (see previous page).
b. Jumping to a Deliverable Template
5. Click (or Control+click) the underlined Document of Understanding listing in the 110a Project
Charter block, at the top of the page. This opens the Document of Understanding (DOU)
Deliverable Template. Move to 1.0 Project Charter, and complete several entries on this page.
6. The Deliverable Templates are summaries of the phase results, for management approval at the
end of the phase. The Working Templates often refers you to the related Deliverable Template to
complete the work there, rather than recording the same information in two places. The Working
Templates are most useful in cases where a result builds through a series of activities in a phase.
Thus the working Template contains all your steps; the DOU only has the summary results that
need management approval.
7. You complete parts of this DOU throughout the first phase in a project, and present it to managers
at phase end for their approval. For now, Close and Save the DOU template.
8. Plan the Phase. Output 110b shows the content of your First Phase Plan. If you are making minor
changes to the plan recommended by PBE, you can do most of them in the MSProject template. If
you are making significant changes, or for more complex phases, we suggest you add source
Templates containing the information at the right of the 110b checkboxes to your project folder.
At this point, you should use Plan By Example to complete your first phase plan.
continued
Templates Page 4
3. Using the Templates, continued
b. Beginning-of-Phase Use of the Templates
1. Go back to the Phase Working Template for MP1 Initiate a Project. After planning the phase, use
the Working Template as an optional way to collect and organize the activity outputs,
summarizations, and phase results.
Key Point: We do not believe in documentation for documentation’s sake. If you can produce
acceptable Major Milestone Deliverables using just the Deliverable Template, do so. Alternatively,
if your models exist in software, just identify where they are located, as opposed to blindly
copying them into the Templates. About the only exception to this is key portions of the
Deliverables Templates, that need to be reviewed and preserved without external linkages.
Where directed, record your results in the correspoinding Deliverables Template. Repeating
ourselves, the same information appears to occur multiple times. This is true for two reasons:
 A work product “grows” through several activities, as more information is added. An
example of this is the process models that accumulate information through the project.
 A series of outputs from Working Templates may be repeated in a reviewed Deliverable
Template, such as the Document of Understanding.
2. Email portions of the Working Templates to team members who are responsible for an activity or
set of activities. Merge their results back in when complete. Note that in the Medium Project
template set, all outputs from a related series of activities are summarized on one or two pages.
In the Large Project templates, results are summarized and reviewed at the Key Result (summary
product) level. This provides logical separation points for this Template distribution.
Tip: make sure those who use the templates keep the styles and formatting intact, so it will be
easy to merge multiple team members’ results into the phase template.
3. Either embed or link to an external Template or software application that illustrates the existing
situation, such as a Visio diagram.
Tip: Precede the external Template’s meaningful name with the phase designation, such as MP1.
Then keep the linked Template in the same project folder, so all files are together.
4. Reviews: The Working Template identifies the type of review needed for each incremental output,
and lists the recommended reviewers. However, this is for your information only. The actual signoff should be in the QualityLog for the MP path you are using, PMqualog_mp.doc.
c. End-of-Phase Template Actions
At the end of each phase, you transfer your final results from the Working Template to the
Deliverable Template. Once again, the rationale: during the phase, you build on the product, each
activity adding more information. You don’t want all the interim details in the template you submit
for Milestone approval to your manager and customer—just the most recent results.
1.
2.
3.
4.
5.
6.
At the end of a phase, review your results to make sure they are accurate and complete.
Make sure you have performed each recommended review and updated the QualityLog.
Use the Basic 9 Checklist at the back of each Working Template to verify your progress.
Transfer any remaining needed information to the current Deliverable Template.
Get needed approvals of Customers, Managers, and Technical Experts.
File the Deliverable Template, and log any changes as they occur.
Templates Page 5
4. Using the Project Management Templates
The Project Management Templates
The Quality Logs
The Quality Logs serve several functions:



To aid phase planning by identifying outputs that need Quality Assurance Reviews, identifying the
type of review (Informal, Formal and Management) and identifying the roles that should be
involved with those reviews.
To aid status tracking of cumulative planned vs. actual review count, a reliable indicator of a
project that is slipping.
To create a trail of successfully planned and completed Formal and Management reviews.
Note: The Quality Log lists all reviews, but the Informal reviews do not necessarily need a Quality
Assurance Review form. The sign-off on the phase Working template is usually sufficient.
Recommendation: For Formal and Management reviews, we recommend that you begin the QAR
form when you plan the phase, including the heading information about the activity, output in
review, and the planned reviewers. Then when it is time for the review, you only need to complete
the bottom of the form.
Templates for Project Issues, Changes and Status
1. The Change-log and Issue-log are similar in structure to the Quality-log, with a tracking log,
followed by individual forms for the detailed instances.
2. The Status Log includes a log of Status Reports, and weekly (or period you select) report of the
status of the project’s most important Vital Signs. Less effective teams merely report Time and
Cost, which are trailing indicators of status (unless you are correctly using Earned Value
tracking). More effective teams use the front-window, leading indicators of tracking.
With all the templates, we recommend that you keep our names for the templates in your project.
Templates Page 6
5. Summary: Templates @ Glance
The …
Should …
Phase Working
Template


Contain the results of individual system engineering activities of a
phase
Contain direction to transfer key phase results to the Milestone
Deliverable templates.
Remind you of needed Quality Reviews, and recommended participants.
Milestone
Deliverable
Template


Contain the results of the system engineering activities
Reflect management approval of the phase results
Microsoft Project
PBE template
Reflects your Work Breakdown Structure, Estimates, Schedule, Resource
requirements and Key Assumptions. Use this information to compare plan
vs. actual.
Quality Log
Reflect completion of each review, and the Formal and Management
reviews should have a completed Quality Assurance Review form
Change Log
Reflect the status of all change requests, and is the basis for a review of
the cumulative downstream (later phases) impact of requests approved.

Also includes a copy of each Change Request, and an analysis of the
impact of the change.
Issue Log
Shows the status of all issues, the details of each Issue, and an analysis of
the pending project impact of the issue.
Projects should have issues; in fact, an open issue count is useful status
tracking and reporting information. However, most issues should be solved
before their must date: the day they must be acted upon to avoid project
damage.
7. File the results; when changes in later phases require updates to already-approved results, such
as additional requirements, note the changes on the original phase templates, and record the
date and change request number. That way you have a trail for all changes.
8. At the end of the project, use the results to view project success. At the end of the warranty
period archieve the entire project folder and back it up on a cd rom.
Templates Page 7
4. We Request Feedback
The Templates have been a work in process for quite some time. Please let us know your reactions.
We are specifically interested in your comments about:
1. Errors or omissions: we found a bunch, but realize that with changes of this magnitude, there are
still some lurking.
2. Improvements and Additions: What would you recommend here?
3. Usefulness: how are they? Are they too detailed? Too repetitive? Too summary?
4. Which do you view as unnecessary? And, please give us some context. For example, is the Status
Log template unnecessary because you use something better, or because you never track status?
5. Other comments?
Thanks!
Stacy Goff
[email protected]
Templates Page 8
Requirements Specification Template
THE Guide
Deliverable Template
2 Requirements Specification
Date: Today’s Date
Project:
Author(s)
Group
Address
Version Information
Current Status
- pending -
© 2004 ProjectExperts
Licensed to Guide Customers
A3.2 Requirements Template.doc
9/9/2011
Requirements Specification Template Page 1 of 20
THE Guide
Requirements Specification
Table of Contents
1. Management Overview
3
2. Business Analysis
5
3. General Requirements for the New System
9
4. Functional Requirements for the New System
10
5. Information Requirements
12
6. Performance Requirements
13
7. Other Requirements
14
8. Documentation and Training Plan
15
9. Preliminary Test Plans
16
10. Basic 9 Results Update
17
11 Approval: Requirements Specification
18
12. Change Log
20
For more information about use of THE Guide Templates, press this
line to load the Templates Overview.
Turn on Hidden Text to see helpful notes: Tools | Options | View | Hidden Text
Revision History
Date
Author
Version
Change Reference
9/9/2011
THE Guide
1. Management Overview
A. Management Overview
1. Purpose of this document
Describe the purpose of the document, and the intended audience.
2. Scope of this document
Describe the scope of this requirements definition effort. Introduces the requirements team,
including users, customers, system engineers, and developers. This section also details any
constraints that were placed upon the requirements process, such as schedules, costs, or the
software engineering environment used to develop requirements. Describes the purpose of the
document, and the intended audience.
3. Overview
Provides a brief overview of the product defined as a result of the requirements elicitation process.
4. Business Context
Provides an overview of the business organization sponsoring the development of this product. This
overview should include the business's mission statement and its organizational objectives or goals.
9/9/2011
THE Guide
1. Management Overview, continued
B. Project Charter
1. Statement of the Business Need
2. Product Description
3. Key Role Assignments
Sponsor:
Project Manager:
Customer(s):
Key Team Members:
4. Project Manager Authority
The Project Manager has the authority to control the working environment of her full-time assigned
resources including blocking interruptions, and rewarding team members’. Authority to hire and fire
team members belongs to her manager, (manager). The Project Manager works with the resource
manager of part-time resources to assure their productive project efforts.
5. Communication Plan
 The team will produce regular weekly status reports.
 The Project Manager will produce progress reports at major phase-end milestones.
 Team members, who first observe issues will produce an Issue Report as needed, distribute it to
the Project Manager. The Project Manager will distribute the Issue Report to those who can
resolve the issue.
 Each weekly project status report will summarize open issues.
 The Project Manager assumes responsibility for ad-hoc and as-needed communication within the
team, and with her or his manager, customer management, and the project sponsor.
 The project sponsor assumes responsibility for ad-hoc and as-needed communication with
executive management, and assures that communication occurs with the customer, both
internal and external.
6. Change Control Plan
This project will adopt THE Guide’s standard Change Control process, introducing the Change
Budget, Change Log template and forms at an all-stakeholders’ meeting at the end of the
Requirements Phase.
9/9/2011
THE Guide
2. Business Analysis
A. Business Problem Analysis
1. What Is The Problem?
2. What Is The Real Problem?
3. Whose Problem Is It? (List all who are affected)
4. Where Does The Problem Come From?
5. Why Do We Want To Solve The Problem?
B. Opportunity Analysis
1. What
2. Why
3. Who
4. Where
5. When
6. How
9/9/2011
THE Guide
2. Business Analysis, continued
C. Project Goal
D. Objectives
E. Scope Statement (or Statement of Work)
F. Items Not In Scope
continued
9/9/2011
THE Guide
G. Models (Process, Data, Object, Use Case, etc.)
Insert appropriate graphic models that show the data and processes of the existing situation.
continued
9/9/2011
THE Guide
H. Problem/Opportunity Location, Timing, Exceptions
Insert a graphic model of the processes, and a list of the problems or opportunities, timings, and
exceptions to show how they map to the processes of the existing situation.
This information is optional in the case of the Component paths.
continued
9/9/2011
THE Guide
3. General Requirements for the New System
1. Vision statements or “stories”
Insert high-level statements of the requirements from Sponsor and Customer Managers.
2. Narrative form of the Requirements
Insert a short-sentence list of requirements, and any supporting documents such as vision
statements, stories, or from the sponsor, customers, and users. Insert text narratives describing
each of the requirements.
3. Vignettes, or detailed process descriptions
This section should describe a set of vignettes that illustrate, from the user's perspective, what will
be experienced when utilizing the system under various situations.
In the broad sense, a vignette is simply a proposed specific use of the system. More specifically, a
vignette is a description of one or more end-to-end transactions involving the required system and
its environment. Vignettes can be documented in different ways, depending up on the level of detail
needed.
The simplest form is a use case, which consists merely of a short description with a number
attached. More detailed forms are called scripts. These are usually represented as tables or
diagrams and involved identifying an action and the agent (doer) of the action. For this reason, a
script can also be called an action table.
Although vignettes are useful in acquiring and validating requirements, they are not themselves
requirements, because they describe the system's behavior only in specific situations; a
specification, on the other hand, describes what the system should do in general.
9/9/2011
THE Guide
4. Functional Requirements for the New System
1. Functional Requirements Models
Functional requirements describe what the system must accomplish. Other kinds of requirements
(such as interface requirements, or performance requirements) describe how well the system
accomplishes its functional requirements. For each requirement in 3.2 that represents a Function,
insert Use Cases or Process Models that graphically describe the requirement. Include or refer to
any supporting documents such as detailed procedure descriptions or Vignettes.
continued
9/9/2011
THE Guide
4. Functional Requirements, continued
2. Prioritized Functional Requirements
This section lists the functional requirements in ranked order.
Use need vs. want, and needed current vs. needed future to categorize all requirements. Then rank
order all the functional requirements so you can identify cut-off points if you have time or funding
constraints in this project.
Specify each functional requirement in a format similar to the following:
a. Rank
b. Requirement: a short, imperative sentence stating the functional requirement.
c. Description: A full description of the requirement. Use the Vignette as a starting point.
d. Criticality: Describes how essential this requirement is to the overall system.
e. Technical issues: Describes any design or implementation issues involved in satisfying this
requirement.
f. Risks: Describes the circumstances under which this requirement might not able to be satisfied,
and what actions can be taken to reduce the probability of this occurrence.
g. Dependencies with other requirements: Describes interactions with other requirements.
h. Assumptions: Identify any factors that might make the project expand, record them as
assumptions.
Copy and paste the block below for each functional requirement
For Each Functional Prioritized Requirement
Insert more detailed function descriptions for each new functional requirement, plus the following
details. You may use the Vignette as a starting point.
a. Rank:
b. Requirement:
c. Description:
d. Criticality:
e. Technical issues:
f. Risks:
g. Dependencies with other requirements:
h. Assumptions:
9/9/2011
THE Guide
5. Information Requirements
1. Data Models or Class Diagrams
Insert Data Models, Class Diagrams or other appropriate graphics to show the data structures.
2. New Data Requirements
Insert any new data requirements, including those you discovered from decomposing the
Information Requirements.
9/9/2011
THE Guide
List and rank each Performance Requirement; identify which functional requirements each
Performance Requirement relates to (if it is specific to one), and who and how they will be validated
during testing. Performance requirements include speed and memory requirements.
9/9/2011
THE Guide
7. Other Requirements
1. Constraining Requirements (Design Constraints)
List the Constraining Requirements that will limit system operation or flexibility, and for each,
identify who can waive or release the constraint. Design Constraints include:
 Application Standards Compliance
 Hardware Limitations
 Needed Controls
2. Subjective Requirements
As much as possible, translate Subjective Requirements into Functional, Information and
Performance requirements by asking the user (for example), “What does it need to do to be userfriendly?” Rank-order any Subjective requirements you were not able to categorize into one of the
other areas. For all remaining Subjective Requirements, identify who will evaluate the completed
requirements, and how they will determine if it passes their judgment.
3. Interface Requirements
Two types of Interface Requirements, with different Review criteria:
- User Interface prototypes: Completeness and Correctness
- Interfaced Systems: Plan (and permission from owner, if needed) for connecting to the system
4. Additional Requirements
Consider and add Requirements in specialty areas, considering the checklist below.
1
2
3
4
5
6
7
8
9
Security
Reliability
Maintainability
Portability
Extensibility
Reusability
Application Affinity/Compatibility
Resource Utilization
Organizational Change
9/9/2011
THE Guide
8. Documentation and Training Plan
1. Documentation Plan
The Documentation and Training Plan is required in this Requirements Deliverable for the
Component Design method. It is optional in this deliverable for other methods; in that case, the
output is required in the Design deliverable. It is item 9 of the Basic 9 minimum results of any
project. Given a visible system with needed pop-up documentation, this plan identifies the
additional documentation and training that will be delivered.
a. Plan for Application Documentation
b. Plan for Installation and Setup, if any
c. Information Systems Support Needed
d. Responsibilities for
Designing and developing the documentation
Reviewing the developed materials
Keeping the developed materials current
Organizational change management
2. Training Plan
This output is the second part of item 9 of the Basic 9 minimum results of any project. Given a
visible system with needed pop-up documentation, this plan identifies the additional documentation
and training that will be delivered.
a. Plan for User Training for New or Revised Business Processes
b. Application-Specific Training:
Who will be trained?
What Learning Objectives will measure their learning?
Who will evaluate results and provide post-training coaching?
c. Information Technology Support Needed (Help Desk, mentors, etc.)
d. Responsibilities for
Designing, developing and delivering the training
reviewing the developed training materials
keeping the developed materials current
9/9/2011
THE Guide
9. Preliminary Test Plans
1. Preliminary System Test Plan
Copy the status of your System Test Plan from your Working Document into the space below. If you
completed the System Test Plan without using the Working Document, update the status of the
recommended elements below. Note that this information is more complete at this point in the
Component path, because you need this detail earlier. Other paths have fewer required items this
early in the project.
Reminder: Remember to update your System Test Plan whenever it changes in any way.
Note: The numbers refer to the sections of the System Test Plan
1. Test Plan Identifier (showing the scope of this test plan)
2. Introduction (including Application Context, System Testing Objectives, and Testing Strategy.)
3. Test Items (all)
4. Features to be Tested
5. Features Not to be Tested
6. Approach for each Test Plan type listed in the Master System Test Plan
11. Environmental Requirements
12. Responsibilities
13. Staffing and Training Needs
15. Assumptions, Risks and Contingencies
2. Preliminary Acceptance Test Plan
Copy the status of your Acceptance Test Plan from your Working Document into the space below. If
you completed the Acceptance Test Plan without using the Working Document, update the status of
the recommended elements below. Note that this information is more complete at this point in the
Component path, because you need this detail earlier. Other paths have fewer required items this
early in the project.
Reminder: Remember to update your Acceptance Test Plan whenever it changes; you complete
and formalize the Acceptance Test Plan during the Design Phase.
Note: The numbers refer to the sections of the Acceptance Test Plan
1. Test Plan Identifier (showing the scope of this test plan)
2. Introduction (including Application Context, System Testing Objectives, and Testing Strategy.)
3. Test Items (all)
4. Features to be Tested
5. Features Not to be Tested
6. Approach for each Test Plan type listed in the Master System Test Plan
11. Environmental Requirements
12. Responsibilities
13. Staffing and Training Needs
15. Assumptions, Risks and Contingencies
Informal Review Approval
Date
Reviewers: Customer, Project Manager, Developer
Perform an informal review when completed; the results receive a Management review when
combined with the Requirements Specification at phase end.
9/9/2011
THE Guide
10. Basic 9 Results Update
The Basic 9 Results
The Basic 9 Results are the minimum results (in addition to a working system) of any successful
Guide project. The Initiate a Project Phase begins half of the Basic 9 Results.
In the table below, record the status of all the Basic 9 Results that should be produced or started by
this point in the project. If comments are needed, place them in the field below the checkbox.
B1. Problem or Opportunity Statements
Updated this phase
B2. Objectives and Scope
Updated this phase
B3. Initial Project Plan and Ongoing Updates
Updated this phase
B4. Quality Reviews Planned in Quality Log
Updated this phase
B5. Requirements Specification
Produced in this phase
B6. Change Control Procedures In Place
Completed in this phase
B7. System Design Documents
Produced in next phase
B8. Test Plans with Expected Results
Introduced in this phase, completed last phase
B9. Training and Documentation Plans
Started for the team in first phase;
for customers, started in next phase
9/9/2011
THE Guide
11 Approval: Requirements Specification
1. Formal Review: Customer and IT Infrastructure Experts
This Requirements Specification reflects an exhaustive work effort on the part of the project team,
with active participation of the project’s customers. To the best of our abilities, we have identified all
Requirements needed to meet our business needs. We have instituted THE Guide’s Change Control
process to manage the impact of additional discovery on project Scope, Time and Cost.
If you agree that this Requirements Specification meets your business needs, please authorize us to
proceed by signing this document. We are prepared to begin work on the Design phase immediately
upon acceptance.
Recommended by Business Analyst and Project Manager: (co-authors)
Approving Technical Staff, and their Roles on right
Approving Business/Customer Staff, and their Roles on right
9/9/2011
THE Guide
11 Approval: Requirements Specification, continued
2. Management Review: Sponsor and IT Managers
a. Accepted Requirements Specification
with active participation of the project’s customers. To the best of our abilities, we have identified
all Requirements needed to meet our business needs. We have instituted THE Guide’s Change
Control process to manage the impact of additional discovery on project Scope, Time and Cost.
If you agree that this Requirements Specification meets your business needs, please authorize us to
proceed by signing this document. We are prepared to begin work on the Design phase immediately
upon acceptance.
Requirements Specification Approved (also indicate approval on this template’s cover page)
b. Change Control Procedures
Change Control Procedures properly introduced and in place
c. Refined Project Plan, updated in the Document of Understanding
Refined Project Plan is approved, including the items below.
Updated responses to The 20 Questions
Revised effort estimates on SWAG or other Estimating Template
Revised project budget
Changes and additions to Documented Assumptions
Link or point to an updated Document of Understanding:
Revised project schedule at milestone (phase-end) level of detail
Link or point to an updated MSProject plan:
Recommended by Business Analyst:
Project Manager: (co-authors)
Accepted, Sponsor, Customer Managers
Accepted, IT Managers
Date:
Date:
9/9/2011
THE Guide
12. Change Log
1. Major Milestone Updates and Approvals Log
At a minimum during each Management Review and Approval point, plus for each major change,
re-evaluate the scope of the requirements to identify additions or deletions of the project’s scope.
Either record changes to these requirements below, or use the Change-Log template.
The rationale: multiple Change Requests can be approved within a phase. The team needs to review
the cumulative impact of compounding changes, especially considering the “downstream” phase
impact.
Change-Log Template used instead; it is located in the project folder.
Date
Phase,
Milestone
Summary of Major Changes
Time
Impact
Cost
Impact
Scope
Impact
2. Cumulative Impact
Date
Phase,
Milestone
Project
Project
End Date Cost
9/9/2011
Measured
Scope
THE Guide
Deliverable Template
MT2 Requirements Specification
Date:
Today’s Date
Project:
Including the Document of Understanding
Author(s)
Group
Address
Version Information
Current Status
- pending -
© 2004 ProjectExperts
Licensed to Guide Customers
9/9/2011
MT Requirements Specification Template
Page 1 of 16
THE Guide
Requirements Specification
Table of Contents
Intended Use of this Template
This template is provided to help speed your learning and use of THE Guide; it does this by providing
a means for you to:
 Record all the components that make up a useful Requirements Specification.
 Review and approve the Requirements Specification.
 Reflect the impact of changes on the Requirements Specification.
In this Template: Requirements Specification
1.0 Management Overview
3
2.0 Analysis of Existing Situation
4
3.0 General, Functional and Information Requirements
5
4.0 Other Requirements
7
5.0 Test Strategy
9
6.0 Document of Understanding
10
7.0 Approval: Requirements Specification
13
8.0 Change Log
14
Basic 9 Results Update
15
For more information about use of THE Guide Templates, press this
line to load the Templates Overview.
Turn on Hidden Text to see helpful notes: Tools | Options | View | Hidden Text
Revision History
Date
9/9/2011
Author
Version
Change Reference
Page 2 of 16
THE Guide
1.0 Management Overview
1. Purpose of this document
2. Scope of this document
3. Overview
4. Business Context
9/9/2011
Page 3 of 16
THE Guide
2.0 Analysis of Existing Situation
1. User Problem Statement
2. User Objectives
3. Product Functions
4. Similar System Information
5. User Characteristics
6. General Constraints
7. Detailed Process Model (Process, Use Case, etc.)
8. Data Models (Entity Relationship, Data Model, Class Diagram)
9/9/2011
Page 4 of 16
THE Guide
3.0 General, Functional and Information Requirements
1. Vision statements
2. Narrative form of the Requirements
3. Vignettes, or detailed function descriptions
4. Functional Requirements Models
9/9/2011
Page 5 of 16
THE Guide
3.0 General, Functional and Information Rqmts., continued
5. Prioritized Functional Requirements
For Each Functional Requirement
a. Rank:
b. Requirement:
c. Description:
d. Criticality:
e. Technical issues:
f. Risks:
g. Dependencies with other requirements:
h. Assumptions:
6. Data Models or Class Diagrams
7. New Data Requirements
9/9/2011
Page 6 of 16
THE Guide
4.0 Other Requirements
1. Interface Requirements
1.1 User Interfaces
Describes how this product interfaces with the user.
a. GUI
b. CLI
c. API
1.2 Hardware Interfaces
1.3 Communications Interfaces
1.4 Software Interfaces
1.5 User Views, Prototype Results
Insert copies of User Views and Prototypes, following this page. See the Phase Document Template
for a checklist of the items to consider.
continued
9/9/2011
Page 7 of 16
THE Guide
4.0 Other Requirements, continued
3. Design Constraints
4. Other Attributes
5. Subjective Requirements
9/9/2011
Page 8 of 16
THE Guide
5.0 Test Strategy
Test Strategy
1. Functional Requirements Test Strategy
2. Information Requirements Test Strategy
3. Performance Requirements Test Strategy
4. Constraints Test Strategy
5. Subjective Requirements Test Strategy
6. Requirements Validation Responsibilities
7. Acceptance Test Plan Framework
8. Test Resources, Equipment and Users
9. Temporary Files or Functions Required for Testing
9/9/2011
Page 9 of 16
THE Guide
6.0 Document of Understanding
6.1 Project Time Management
This schedule is based on our documented assumptions about staffing and scope. Following are our
tentative phase ending dates, assuming quick turnaround on approvals:
Medium Project Phases and Milestone Dates
Planned Completion
MT1 Initiate A Project
MT2 Define Requirements
MT3 Design System
MT4 Construct, Test and Implement System
Project Schedule:
9/9/2011
Page 10 of 16
THE Guide
6.0 Document of Understanding, continued
6.3 Project Quality Management
Management Reviews are scheduled as follows:
Phase
Planned Date
Actual Date
MT1 Initiate A Project
MT2 Define Requirements
MT3 Design System
MT4 Develop, Test and Implement System
6.4 Project Human Resource Management
A summary of roles and the team members filling them
Role
Team Member Names
Responsible For
Project Manager
Customer
Developer
Network Engineer
Database Administrator
IT Manager
Other Resources Needed:
6.5 Project Strategy or Approach
6.6 Key Assumptions
6.7 Project Risk Management
Project risk assessment and risk contingency planning will use KnowRisk®, plus the ProjectExperts’
process for risk identification, quantification, and resolution. A summary of the standard categories of
Structure, Technology and Size is below.
Risk Type
Risk (H, M or L)
Most Important Contingency or Avoidance Plans Committed to
Structure
Technology
Size
Other Risks
9/9/2011
Page 11 of 16
THE Guide
6.0 Document of Understanding, continued
6.8 Project Organization
The project is staffed as a Thin-staffed Medium project, with a Project Manager, and 2-3 half-time
team members, including Customer.
6.9 Status or Progress Reporting
The team will use THE Guide methods for reporting:
A. Team members will track their assigned activities using [time sheet system] on the network.
B. Each team will produce a one-page weekly status report, with a Gantt Plan vs. actual summary
C. At major milestones, progress reports will present the accomplishments to-date.
D. Issue Reports will notify, recommend and act upon issues that will affect the project.
E. Issue logs will track open and resolved issues.
6.10 Change Control Approach
The Guide’s Change Control procedures will be in force upon approval of the Requirements phase.
1. The Project Manager (or team members) will help customers complete change request forms.
2. The Project Manager will maintain a change log, containing current status of all requested
changes.
3. The Project Manager will assign any change to a team member for impact evaluation
4. A team member will work with the requester to determine and help quantify the business benefit.
Each phase plan will include a budgeted amount of effort to cover the cost of evaluating change
requests and, and to implement minor ones (within the Project Manager’s discretion). At the option of
our customer, we will budget for approved changes in the same way.
After Requirements approval, the scope can only change 25% without a management review and
approval of schedule and cost consequences. The customer will make the final ruling on all changes,
based on recommendations from the project team and given a complete understanding of their impact
on vital signs.
9/9/2011
Page 12 of 16
THE Guide
7.0 Approval: Requirements Specification
Formal Review: Customer and Customer Manager; IT Infrastructure Experts and IT
Manager
with active participation of the project’s customers. To the best of our abilities, we have identified all
Requirements needed to meet our business needs. We have instituted THE Guide’s Change Control
process to manage the impact of additional discovery on project Scope, Time and Cost.
If you agree that this Requirements Specification satisfies your review, please authorize us to proceed
by signing this document.
Recommended by Project Manager:
Date:
Accepted:
Sponsor, Customer Managers, Infrastructure Staff, and IT Managers
Role:
Date:
Role:
Date:
Role:
Date:
Role:
Sponsor
Date:
Role:
Customer
Date:
Role:
Role:
Date:
IT Manager
Role:
9/9/2011
Date:
Date:
Page 13 of 16
THE Guide
8.0 Change Log
1 Major Milestone Updates and Approvals Log
At a minimum during each Management Review and Approval point, plus for each major change,
re-evaluate the scope of the requirements to identify additions or deletions of the project’s scope.
Either record changes to these requirements below, or use the Change-Log template.
The rationale: multiple Change Requests can be approved within a phase. The team needs to review
the cumulative impact of compounding changes, especially considering the “downstream” phase
impact.
Change-Log Template used; it is located:
Date
Phase,
Milestone
Summary of Major Changes
Time
Impact
Cost
Impact
Scope
Impact
Project
End Date
Project
Cost
Measured
Scope
2 Cumulative Change Impact
Date
9/9/2011
Phase,
Milestone
Page 14 of 16
THE Guide
Basic 9 Results Update
The Basic 9 Results
The Basic 9 Results are the minimum results (in addition to a working system) of any successful
Guide project. The Initiate a Project Phase begins half of the Basic 9 Results.
In the table below, record the status of all the Basic 9 Results that should be produced or started. If
comments are needed, place them in the field below the checkbox.
B1. Problem or Opportunity Statements
Updated this phase
B2. Objectives and Scope
Updated this phase
B3. Initial Project Plan and Ongoing Updates
Updated this phase
B4. Quality Reviews Planned in Quality Log
B5. Requirements Specification
B6. Change Control Procedures In Place
B7. System Design Documents
Produced in MT3
B8. Test Plans with Expected Results
Introduced in this phase, completed in MT3 & MT4
B9. Training and Documentation Plans
Training Plan started for the team this phase;
for customers, completed in MT3
9/9/2011
Page 15 of 16
THE Guide
This page intentionally blank.
9/9/2011
Page 16 of 16

H o w

Transcription

Similar documents

Walkthrough: Publicaster`s New Free Templates

What`s new in

spin-e-fex curly q templates set 2

Hexaflexagons! 1 Flexagons - Washington University in St. Louis

MG857: 16 oz Double Wall Clear Acrylic Tumbler w/ Color

Prophix 11?

MIT-CHIEF Business Plan Contest Executive Summary Template

Posting Your Job Step One: Step Two: Step Three: Step Four: Step

Iris Folding Tutorial