Suborbital-Systems/ReadySetGit
2
0
Fork 0
Code Pull Requests Packages Projects Releases Activity

Linter cleanup

Browse Source
This commit is contained in:
William Sandner 2018-08-24 12:30:24 +02:00
parent af07911365
commit fb1bdcf829
26 changed files with 664 additions and 694 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
Interview-Checklist.md
View File

@ -1,6 +1,8 @@
##### Related Documents
- [User Needs](User-Needs)
- [Interview Notes](interview-notes.html)
---
**Process impact:** This checklist will help you plan customer
@ -43,25 +45,25 @@ interviews.
### Interview Checklist
1. Be prompt, courteous, and business-like
2. Introduce yourself and explain why you are there
3. Make sure that you are interviewing the person you think you are.
Get their contact information (e.g., email address) if you don't
already have it.
4. Ask permission to take notes. Don't record or video tape.
5. Confirm the amount of time you and the interviewee have for
this session.
6. Give a quick indication of the type and number of questions that you
have
7. Work through the questions.
8. Listen. That is why you are there.
9. If the interviewee refers to existing documents, systems, equipment,
or people, make sure that you understand what he or she is
talking about. If it is important, ask if you may have a copy or
screenshot (but, don't ask for anything containing proprietary
information), or make a note of the important aspects of the items
referred to. Note the URLs of any existing public
websites discussed.
1. Be prompt, courteous, and business-like
2. Introduce yourself and explain why you are there
3. Make sure that you are interviewing the person you think you are.
Get their contact information (e.g., email address) if you don't
already have it.
4. Ask permission to take notes. Don't record or video tape.
5. Confirm the amount of time you and the interviewee have for
this session.
6. Give a quick indication of the type and number of questions that you
have
7. Work through the questions.
8. Listen. That is why you are there.
9. If the interviewee refers to existing documents, systems, equipment,
or people, make sure that you understand what he or she is
talking about. If it is important, ask if you may have a copy or
screenshot (but, don't ask for anything containing proprietary
information), or make a note of the important aspects of the items
referred to. Note the URLs of any existing public
websites discussed.
10. Try not to answer the questions yourself, or to react to interviewee
requests by making promises to solve problems. Interviews are for
understanding the problems, not solving them or setting schedules

15
Legal.md
View File

@ -1,22 +1,28 @@
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Release Audience:
- ::General availability release ||
- ::Customer-specific release: CUSTOMER(S) ||
- ::Developer release (Internal usage only) ||
- ::Early access release (Controlled external access)
##### Intended Product License:
::Commercial license
##### Related Documents
- [Project proposal](Proposal) > [Target audience and benefits](Target-and-Benefits)
- [Project Plan](Project-Plan) > [Resource needs](Resource-Needs)
- [Glossary](Glossary)
---
**Process impact:** This document outlines legal issues that may affect
@ -49,10 +55,11 @@ professional counsel for review as needed.*
| ::Privacy | ::Cannot collect personal information from minors | ::In compliance | ::We ask for user age before asking for other information |
| ::Industry certification | ::Game industry rating | ::In compliance | ::We follow guidelines for "Everyone" rating |
##### Possible Status Values
- In compliance: we are OK to go ahead with this release
- Waived: we decided not to consider this aspect for this release
- Violated: we are not conforming. Comment should describe impact.
> **Possible Status Values**
>
> - In compliance: we are OK to go ahead with this release
> - Waived: we decided not to consider this aspect for this release
> - Violated: we are not conforming. Comment should describe impact.
### Legal Issues Checklist

17
License.md
View File

@ -10,16 +10,9 @@ Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of these files must retain the above copyright
notice, this list of conditions and the following disclaimer. The
individual template files must retain the copyright footnote whenever
they are used as templates.
2. The name "ReadySET" must not be used to endorse or promote
products derived from this software without prior written
permission. For written permission, please contact
jrobbins@jrobbins.org.
1. Redistributions of these files must retain the above copyright notice, this list of conditions and the following disclaimer. The individual template files must retain the copyright footnote whenever they are used as templates.
2. The name "ReadySET" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact jrobbins@jrobbins.org.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
@ -44,7 +37,7 @@ want with them in the context of that project. ***You may even hide the
template copyright statement***: the best way to do that is to edit the
file inst.css.
#### Can I modify these templates for use on several projects at my company?
#### Can I modify these templates for use on several projects at my company?
Yes, absolutely. You may modify and distribute these templates to
others, so long as you retain this file and the footnote with the
@ -56,7 +49,7 @@ If you use the templates and fill in details about a given product,
go ahead. If you are thinking of making a product that includes the
templates for use *as templates*, you must retain this file and the
copyright statement in a visible footnote. An enhanced commercial
version of these templates, [ReadySETPro](http://www.readysetpro.com/),
version of these templates, [ReadySETPro](http://www.readysetpro.com/),
is already in development
#### Can I combine these templates with other templates or documents?

82
Project-Plan.md
View File

@ -59,9 +59,10 @@ For a summary of this project, see the [Project proposal](Proposal).
- ::Issue XXXX made us realize that we forgot to plan time for DEVELOPMENT-TASK.
### Summary of Methodology
#### What general development approach will be used?
::THREE TO FIVE SENTENCES OR BULLETS HERE. COVER GENERAL APPROACH, IMPORTANT ASSUMPTIONS, KEY PRACTICES, AND PROJECT COORDINATION CONTROLS.
::THREE TO FIVE SENTENCES OR BULLETS HERE. COVER GENERAL APPROACH, IMPORTANT ASSUMPTIONS, KEY PRACTICES, AND PROJECT COORDINATION CONTROLS.
For more information see the [Software Development Methodology](SDM).
@ -83,19 +84,11 @@ For more information see the [Software Development Methodology](SDM).
#### How will changes be controlled?
- ::Requests for requirements changes will be tracked in the issue
tracker
- ::The change control board ([CCB](Glossary#ccb))
will review requested changes and authorize work on them as
appropriate
- ::After the [feature
complete](Glossary#featurecomplete) milestone, no
new features will be added to this release.
- ::After the [code complete](Glossary#codecomplete)
milestone, no entirely new product source code will be added to
this release.
- ::All source code commit log messages must refer to a specific
issue ID, after the feature complete milestone.
- ::Requests for requirements changes will be tracked in the issue tracker
- ::The change control board ([CCB](Glossary#ccb)) will review requested changes and authorize work on them as appropriate
- ::After the [feature complete](Glossary#featurecomplete) milestone, no new features will be added to this release.
- ::After the [code complete](Glossary#codecomplete) milestone, no entirely new product source code will be added to this release.
- ::All source code commit log messages must refer to a specific issue ID, after the feature complete milestone.
#### How will this plan be updated?
@ -204,45 +197,28 @@ Please see the [risks worksheet](Risks).
#### The main risks of this project are
1. ::There is a potential conflict between the goals of a high-quality
appearance and one that is completely customizable. We can only
succeed if players find the web site appealing, and game vendors can
customize it with no more effort than would be needed to build a
static website. We already have a design in mind that will address
this risk and we will review it with a web site designer who worked
for a game vendor site.
2. ::There are significant technical difficulties in building a web site
and web application. This will be a risk because one person on our
team has much experience with the relevant tools and technologies.
Although the others will learn, we will certainly make some mistakes
and sub-optimal choices. We will address this risk by scoping the
project such that we have enough time to train and to review the
design and implementation.
3. ::The schedule for this project is very short. We will manage this by
planning a conservatively scoped functional core and series of
functional enhancements that can be individually slipped to later
releases if needed.
4. ::The performance of the system will be significantly impacted by the
decisions made during the [database design task](#3.2.C). None of
our current team members has experience with database optimization.
To address this, we will arrange a review meeting with an
experienced DBA or hire a consultant from the database vendor.
5. ::We could be underestimating known tasks. HOW TO AVOID/MITIGATE?
6. ::We could be underestimating the impact of unknown tasks. HOW TO
AVOID/MITIGATE?
7. ::We could be underestimating the dependencies between tasks. HOW TO
AVOID/MITIGATE?
8. ::We could have misunderstood the customer's requirements. HOW TO
AVOID/MITIGATE?
9. ::The customer could change the requirements. HOW TO AVOID/MITIGATE?
10. ::We could face major difficulties with the technology chosen for
this project. HOW TO AVOID/MITIGATE?
11. ::We could have low quality that demands significant rework. HOW TO
AVOID/MITIGATE?
12. ::We could incorrectly assess our progress until it is too late
to react. HOW TO AVOID/MITIGATE?
13. ::We could lose resources. E.g., team members could get sick, spend
time on other projects, or quit. HOW TO AVOID/MITIGATE?
1. ::There is a potential conflict between the goals of a high-quality appearance and one that is completely customizable. We can only succeed if players find the web site appealing, and game vendors can customize it with no more effort than would be needed to build a static website. We already have a design in mind that will address this risk and we will review it with a web site designer who worked for a game vendor site.
2. ::There are significant technical difficulties in building a web site and web application. This will be a risk because one person on our team has much experience with the relevant tools and technologies. Although the others will learn, we will certainly make some mistakes and sub-optimal choices. We will address this risk by scoping the project such that we have enough time to train and to review the design and implementation.
3. ::The schedule for this project is very short. We will manage this by planning a conservatively scoped functional core and series of functional enhancements that can be individually slipped to later releases if needed.
4. ::The performance of the system will be significantly impacted by the decisions made during the [database design task](#3.2.C). None of our current team members has experience with database optimization. To address this, we will arrange a review meeting with an experienced DBA or hire a consultant from the database vendor.
5. ::We could be underestimating known tasks.
HOW TO AVOID/MITIGATE?
6. ::We could be underestimating the impact of unknown tasks.
HOW TO AVOID/MITIGATE?
7. ::We could be underestimating the dependencies between tasks.
HOW TO AVOID/MITIGATE?
8. ::We could have misunderstood the customer's requirements.
HOW TO AVOID/MITIGATE?
9. ::The customer could change the requirements.
HOW TO AVOID/MITIGATE?
10. ::We could face major difficulties with the technology chosen for this project.
HOW TO AVOID/MITIGATE?
11. ::We could have low quality that demands significant rework.
HOW TO AVOID/MITIGATE?
12. ::We could incorrectly assess our progress until it is too late to react.
HOW TO AVOID/MITIGATE?
13. ::We could lose resources. E.g., team members could get sick, spend time on other projects, or quit.
HOW TO AVOID/MITIGATE?
14. ::There may be a mis-alignment of stakeholder goals or expectations.
HOW TO AVOID/MITIGATE?

6
QA-Plan.md
View File

@ -3,23 +3,28 @@ questions. In cases where multiple answers are already written, delete
those answers that do not apply.*
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number:
::X.Y.Z
##### Release Audience:
- ::General availability release ||
- ::Customer-specific release: CUSTOMER(S) ||
- ::Developer release (Internal usage only) ||
- ::Early access release (Controlled external access)
##### Attached Worksheets:
- QA plan > [Review meeting notes](Review-Meeting-Notes)
- QA plan > [System test case suite](Test-Suite)
- QA plan > [System test runs](Test-Run-Suite)
##### Related Documents
- [Software Requirements Specification](SRS)
- [Design](Design)
- [Project plan](Project-Plan)
@ -76,6 +81,7 @@ on the following components and aspects:
- ::FEATURE-2
#### What is the summary of this plan?
::In this release we will continue to use development practices that
support all of our quality goals, but we will focus on functional
correctness and robustness. We will do that with the following major

9
Release-Checklist.md
View File

@ -3,19 +3,24 @@ questions. In cases where multiple answers are already written, delete
those answers that do not apply.*
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### External release number:
##### External release number
::X.Y.Z
##### Release audience:
##### Release audience
- ::General availability release
- ::Customer-specific release: CUSTOMER(S)
- ::Developer release (Internal usage only)
- ::Early access release (Controlled external access)
---
**Process impact:** The process of working through this checklist helps

47
Release-Notes.md
View File

@ -4,20 +4,25 @@ information.*
*TODO: Make sure to use the **product** name and **external** release
number, not internal information.*
##### Product:
::[PRODUCT-NAME](http://www.COMPANY.com/products/PRODUCT-NAME/)
##### Release Number:
::X.Y.Z
##### Product
##### Release Date:
::YEAR/MONTH/DAY
::[PRODUCT-NAME](http://www.COMPANY.com/products/PRODUCT-NAME/)
##### Release Number
::X.Y.Z
##### Release Date
::YEAR/MONTH/DAY
##### Customer Support
##### Customer Support:
::For more information or support, please visit our
[website](http://www.COMPANY.com/products/PRODUCT-NAME/) or email us
at <support@COMPANY.com>
---
---
### Introduction
@ -93,7 +98,7 @@ information can be helpful.*
#### ::Manifest
::This release consists of the following items:
- ::Release notes (this file)
- ::Installation instructions / Quick start guide
- ::Product installer binary
@ -102,33 +107,33 @@ information can be helpful.*
### ::Minimum System Requirements
#### ::System Processor:
#### ::System Processor
::800MHz
#### ::System Memory:
#### ::System Memory
::256MB
#### ::Free Disk Space:
#### ::Free Disk Space
::10MB
#### ::Operating System:
#### ::Operating System
::Windows 2000, Windows XP, Mac OS X, Linux (kernel 2.4)
#### ::Networking:
#### ::Networking
::Internet access
#### ::Existing Software:
#### ::Existing Software
- ::Standard e-mail client
- ::Popular web browser (IE6, NN7)
- ::SuperWaveEdit(TM) 2.0.2 (Needed for custom playback modes)
#### ::Version Compatibility:
#### ::Version Compatibility
::Files saved by earlier versions of this product may be used with
this version. However, wave files saved in version W.Y.Z, must be

5
Resource-Needs.md
View File

@ -1,18 +1,23 @@
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Project Time-frame:
::START-DATE - END-DATE
##### Related Documents
- [Project proposal](Proposal)
- [Project plan](Project-Plan)
- [QA plan](QA-Plan)
- [Software development methodology](SDM)
- [Glossary](Glossary)
---
**Process impact:** Based on the project plan and the worksheet below,

5
Review-Meeting-Checklists.md
View File

@ -1,14 +1,15 @@
# Review Meeting Checklists
---
### Checklists for Types of Artifacts
## Checklists for Types of Artifacts
- ::[Checklists for peer reviews](http://processimpact.com/pr_goodies.shtml)
by Karl E. Wiegers
- ::[Checklists for UML design](http://www.modelingstyle.info/)
by Scott W. Ambler
### Style Guides
## Style Guides
- ::[Sun's java style guide](http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html)
- ::[Sun's javadoc guide](http://java.sun.com/j2se/javadoc/writingdoccomments/)

23
Review-Meeting-Notes.md
View File

@ -1,16 +1,20 @@
##### Project
::[PROJECT-NAME](Home)
##### Release Number:
##### Release Number
::X.Y.Z
##### Location of Meeting:
##### Location of Meeting
::LOCATION, BUILDING, ROOM
##### Date and Time of Meeting:
##### Date and Time of Meeting
::YEAR/MONTH/DAY HH:MM
##### Attendees:
##### Attendees
- ::PERSON-NAME
- ::PERSON-NAME
@ -18,6 +22,7 @@
- ::PERSON-NAME
##### Related Documents
- [QA Plan](QA-Plan) > Review Meeting Notes
- [Review Meeting Checklists](Review-Meeting-Checklists)
@ -25,11 +30,11 @@
### Documents and Code Reviewed at this Meeting
- ::[Feature list section of requirements](#)
- ::[Multi-user section of requirements](#)
- ::[Hello.java](/source/browse/PROJECT-NAME/src/Hello.java)
- ::[HelloStream.java](/source/browse/PROJECT-NAME/src/HelloStream.java)
- ::[HelloPanel.java](/source/browse/PROJECT-NAME/src/HelloPanel.java)
- ::[Feature list section of requirements](#)
- ::[Multi-user section of requirements](#)
- ::[Hello.java](/source/browse/PROJECT-NAME/src/Hello.java)
- ::[HelloStream.java](/source/browse/PROJECT-NAME/src/HelloStream.java)
- ::[HelloPanel.java](/source/browse/PROJECT-NAME/src/HelloPanel.java)
### Meeting Minutes

223
Risks.md
View File

@ -1,14 +1,18 @@
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Related Documents
- [Project plan](Project-Plan)
- [Software development methodology](SDM)
##### References:
- [Risk Management during Requirements](http://www.systemsguild.com/pdfs/s5req.lo%201.pdf) by Tom DeMarco and Tim Lister
- [Taxonomy-Based Risk Identification](http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr06.93.pdf) by Carr, Konda, Monarch, Ulrich, and Walker (SEI)
@ -29,82 +33,15 @@ plans to control them. For each risk the plan should include:
general contingency plans. In this case you only need to give a
contingency plan if you have a special one for the particular risk.
The severity of a risk is its likel
##### Project
::[PROJECT-NAME](Home)
The severity of a risk is its likelihood multiplied by its impact. Risks
are classified as minor if they have low likelihood, negligible impact,
or medium likelihood and marginal impact.
##### Internal Release Number
::X.Y.Z
##### Related Documents
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
---ihood multiplied by its impact. Risks
are classified as minor if they hav
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Related Documents
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
---e low likelihood, negligible impact,
or medium likelihood and marginal i
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Related Documents
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
---mpact.
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Related Documents
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
---
*TODO: You should update these list
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Related Documents
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
---s regularly. They should be reviewed
by customers and developers from ti
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Related Documents
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
---me to time.*
*TODO: You should update these lists regularly. They should be reviewed
by customers and developers from time to time.*
### General contingency plans
#### Catastrophic risks
::If a catastrophic risk occurs we will make an honest reassessment of
@ -119,6 +56,7 @@ pretend everything is fine and hope that none of the
stakeholders notice.
#### Risks that consume development resources.
::The project has a fixed deadline. The requirements are prioritized.
If we lose time, we will reduce project scope.
@ -130,143 +68,61 @@ features, and meet with the customers to reconsider scope and
delivery date.
#### ::OTHER RISK TYPE
::OTHER CONTINGENCY PLAN
### Major risks
| Name | Description | Likelihood | Impact | Plan | Status | Owner |
|-----------------|---------------------------------------------------------------------------------------------------------------------------------|------------|--------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------|-------------------|
| ::Requirements | Requirements are only partly known at project start. Customers may not allocate sufficient resources to exploring requirements. | Medium | Critical to Catastrophic | Requirements will be detailed first for the top priority goals. Indicator: Track the rate at which requirements are discovered. Contingency: request more customer effort. | Amber | Requirements Lead |
| Name | Description | Likelihood | Impact | Plan | Status | Owner |
|-----------------|---------------------------------------------------------------------------------------------------------------------------------|------------|--------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------|-------------------|
| ::Requirements | Requirements are only partly known at project start. Customers may not allocate sufficient resources to exploring requirements. | Medium | Critical to Catastrophic | Requirements will be detailed first for the top priority goals. Indicator: Track the rate at which requirements are discovered. Contingency: request more customer effort. | Amber | Requirements Lead |
| ::Goals | Stakeholders goals may conflict. | Medium | Critical | Keep an explicit list of stakeholders goals. The project manager will report progress to each declared goal. | Green | Customers |
| ::Communication | Communication problems in development team. They are dispersed among several sites, and have not worked together before. | Medium | Critical | Use these [tools](SDM#communication) to help communication. The main indicator of miscommunication will be software defects detected by our [QA activity](qa-plan). | Green | QA lead |
| ::Acceptance | Customer may accept delivery of the system although it does not really meet their goals. | Medium | Critical | Customers are asked to declare acceptance criteria as each release is planned. | Green | Customers |
| ::Scope | The total features requested may be beyond what the development team can deliver in the time available. | High | Marginal | Assign levels of important to the use cases. Make the first review of project scope after 12 months. | Green | Customers |
| ::Communication | Communication problems in development team. They are dispersed among several sites, and have not worked together before. | Medium | Critical | Use these [tools](SDM#communication) to help communication. The main indicator of miscommunication will be software defects detected by our [QA activity](qa-plan). | Green | QA lead |
| ::Acceptance | Customer may accept delivery of the system although it does not really meet their goals. | Medium | Critical | Customers are asked to declare acceptance criteria as each release is planned. | Green | Customers |
| ::Scope | The total features requested may be beyond what the development team can deliver in the time available. | High | Marginal | Assign levels of important to the use cases. Make the first review of project scope after 12 months. | Green | Customers |
### Minor risks
*TODO: Review this list regularly, to decide whether the likelihood or
impact of a risk has increased to make it a "major" risk.*
| Name | Description | Likelihood | Impact | Mitigation Strategy | Status | Owner |
|-------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------|----------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------|-----------------|
| ::Estimate | The development team might not be able to estimate the work time, preventing customers from deciding priorities effectively. | Medium | Marginal | The development team will gain experience in estimating the work, and deliver the first estimates after 12 months. We will compare estimated work to actual work. | Green | Project Manager |
| ::Retention | Some developers may leave the project before it is finished. | Medium | Marginal | Employing locations should provide support for continuing professional development. The project manager will discuss career goals with each developer, and try to assign tasks appropriately. | Green | Project Manager |
| ::Correctness | The system as delivered may have low take-up because of a lack of confidence in its correctness. | Low | Catastrophic | State of the art [QA activity](QA-Plan). Contingency: stop development of new facilities until the quality of the existing code is assured. | Green | QA Lead
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Related Documents
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
--- |
| ::Usability | The system as
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Related Documents
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
--- delivered may have low take-up because of poor usability.
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Related Documents
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
--- | Low
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Related Documents
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
--- | Critical | We will have a UI style guide. Most of the development of the front end will be in close contact with customers. We will review usability later in the project. | Green | UI design lead |
| ::Desire | The stated requirements might not match the customers' desires and ambitions for the system. | Low | Critical | Incremental delivery of versions will provide experience of using the system, which will help the customers to identify the real requirements. Indicator: a developer saying "I think they mean ...", a customer saying "They know what I mean". Contingency: request customer review of requirements. | Green | Customers |
| ::Changes | After requirements have been documented and agreed, development activities begin to based on them, first design then implementation. If the requirements change later then effort is wasted. | Low | Critical | A change control procedure is required, so changes are only made when the cost is worthwhile. Indicator: compare cost of change t
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Related Documents
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
---o new development. Contingency: request customer review of requirements.
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Related Documents
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
--- | Green | P
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Related Documents
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
---roject Manager |
| ::Process | Some develope
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Related Documents
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
---rs may not cooperate in common standards and processes. | Low | Critical | QA to check conformance, then discussions in development team meetings to change the standard or the actual practice as appropriate. | Green | QA Lead |
| ::Maintainability | The system as delivered might be hard to maintain. | Low | Marginal | We will review the code for maintainability. | Green | Lead Developer |
| ::RISKNAME | ONE-TO-THREE-SENTENCES | Low or Medium or High | Negligible or Marginal or Critical or Catastrophic | ONE-TO-THREE-SENTENCES | Red or Amber or Green | PERSON-NAME |
| Name | Description | Likelihood | Impact | Mitigation Strategy | Status | Owner |
|-------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------|----------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------|-----------------|
| ::Estimate | The development team might not be able to estimate the work time, preventing customers from deciding priorities effectively. | Medium | Marginal | The development team will gain experience in estimating the work, and deliver the first estimates after 12 months. We will compare estimated work to actual work. | Green | Project Manager |
| ::Retention | Some developers may leave the project before it is finished. | Medium | Marginal | Employing locations should provide support for continuing professional development. The project manager will discuss career goals with each developer, and try to assign tasks appropriately. | Green | Project Manager |
| ::Correctness | The system as delivered may have low take-up because of a lack of confidence in its correctness. | Low | Catastrophic | State of the art [QA activity](QA-Plan). Contingency: stop development of new facilities until the quality of the existing code is assured. | Green | QA Lead |
| ::Usability | The system as delivered may have low take-up because of poor usability. | Low | Critical | We will have a UI style guide. Most of the development of the front end will be in close contact with customers. We will review usability later in the project. | Green | UI design lead |
| ::Desire | The stated requirements might not match the customers' desires and ambitions for the system. | Low | Critical | Incremental delivery of versions will provide experience of using the system, which will help the customers to identify the real requirements. Indicator: a developer saying "I think they mean ...", a customer saying "They know what I mean". Contingency: request customer review of requirements. | Green | Customers |
| ::Changes | After requirements have been documented and agreed, development activities begin to based on them, first design then implementation. If the requirements change later then effort is wasted. | Low | Critical | A change control procedure is required, so changes are only made when the cost is worthwhile. Indicator: compare cost of change to new development. Contingency: request customer review of requirements. | Green | Project Manager |
| ::Process | Some developers may not cooperate in common standards and processes. | Low | Critical | QA to check conformance, then discussions in development team meetings to change the standard or the actual practice as appropriate. | Green | QA Lead |
| ::Maintainability | The system as delivered might be hard to maintain. | Low | Marginal | We will review the code for maintainability. | Green | Lead Developer |
| ::RISK-NAME | ONE-TO-THREE-SENTENCES | Low or Medium or High | Negligible or Marginal or Critical or Catastrophic | ONE-TO-THREE-SENTENCES | Red or Amber or Green | PERSON-NAME |
#### Possible risk status values
##### Red
Active & impacting project
##### Amber
Active but contained without impact to scope or delivery time.
##### Green
Not yet active
### Risk Checklist
#### Do the plans provide an indicator to detect each of the risks becoming active?
::Yes, if all activities are carried out as planned, we will know if any
of the risks is becoming troublesome.
::No, some risks could creep up on us.
#### Are the right "risk owners" assigned to monitor the risks?
::Yes, for each risk the assigned owner can detect the indicator, can
launch the contingency plan, and is the person who will suffer by
the risk.
@ -275,6 +131,7 @@ the risk.
not have sufficient authority.
#### Does each risk have a mitigation strategy, or is the risk acceptable?
::Yes, we have plans to control each risk.
::Yes, we have plans to control some risks, and have accepted others.
@ -282,12 +139,14 @@ not have sufficient authority.
::No, this plan leaves open several risks.
#### Does each risk have a contingency plan?
::Yes, most risks cost development time and the general plan applies,
and for each of the others there is a contingency plan above.
::No, there are some risks we still have to plan for.
#### Has this Risk Control Plan been communicated to the development team and other stakeholders?
::Yes, this document is being posted to the project website. It will
also be discussed at an early team meeting, and discussed with the
customers before the commit to the project. Comments are welcome.
@ -295,9 +154,11 @@ customers before the commit to the project. Comments are welcome.
::No, our culture does not allow discussion of risks.
#### Is there a procedure in place for identifying new risks and reviewing the existing ones?
::TBD
#### In the light of these risks, is the project worth carrying out?
::Yes, it is a low risk project
::No, other projects can deliver as much value at lower risk.
@ -307,7 +168,9 @@ we believe we have adequate plans here, considering the value that
the project could deliver.
#### Is there an anonymous reporting channel, to allow developers to communicate concerns to senior management?
::Yes
::No, everything depends on the alertness and strength of character of
the project manager.
::Yes
RISKNAME
RISKNAME and strength of character of
RISKNAME
RISKNAME

7
SRS.md
View File

@ -1,18 +1,23 @@
##### Project
::PROJECT-NAME
##### Internal Release Number
::X.Y.Z
::X.Y.Z
##### Attached worksheets:
- SRS > [Use case suite](Use-Case-Suite)
- SRS > [Feature set](Feature-Set)
##### Related Documents
- [Project proposal](Proposal) > [User needs](User-Needs)
- ::LINKS TO RELEVANT STANDARDS
- ::LINKS TO OTHER DOCUMENTS
- [Glossary](Glossary)
---
**Process impact:** The SRS precisely defines the software product that

95
Status-Report.md
View File

@ -6,15 +6,19 @@ available.*
examples are given, you should select/edit only one.*
##### Project
::[PROJECT-NAME](Home)
##### Status Report Date:
##### Status Report Date
::YEAR/MONTH/DAY
##### Next Internal Release Number:
##### Next Internal Release Number
::X.Y.Z
##### Release Date:
##### Release Date
- ::Original estimate: YEAR/MONTH/DAY
- ::Current estimate: YEAR/MONTH/DAY
- ::Change Since Last Report: No change
@ -22,24 +26,29 @@ examples are given, you should select/edit only one.*
- ::Change Since Last Report: Saved 4 days
##### Open Issues (needing development):
- ::[17 defects](ISSUE-TRACKER-QUERY)
- ::[8 enhancements]()
- ::[8 enhancements](#)
##### Resolved Issues (pending verification):
- ::[0 defects]()
- ::[2 enhancements]()
- ::[0 defects](#)
- ::[2 enhancements](#)
##### Closed Issues:
- ::[34 defects]()
- ::[3 enhancements]()
- ::[34 defects](#)
- ::[3 enhancements](#)
##### Resources used this period:
- ::PERSON-NAME: 18 hours.
- ::PERSON-NAME: 15 hours.
- ::PERSON-NAME: 10 hours.
- ::PERSON-NAME: 12 hours.
##### Status Summary:
- ::Project completed. This is the final status report.
- ::Low risk. Project on track.
- ::Medium risk. Problems are being dealt with.
@ -47,9 +56,11 @@ examples are given, you should select/edit only one.*
- ::Project canceled. This is the final status report.
##### Related Documents
- [Project plan](Project-Plan) > [Resource needs](Resource-Needs)
- [QA plan](QA-Plan)
- [Glossary](Glossary)
---
**Process impact:** This helps keep stakeholders informed of project
@ -67,75 +78,11 @@ words.
::Two major problems have been uncovered...
<!-- End Markdown content -->
</xmp>
<div w3-include-html="_words-of-wisdom.html"></div>
<div w3-include-html="_footer.html"></div>
<script>
w3IncludeHTML();
</script>
<script src="http://strapdownjs.com/v/0.2/strapdown.js"></script>
<!-- Include it AFTER strapdown -->
<script src="assets/strapdown/strapdown-topbar.min.js"></script>
<!-- Include it AFTER EVERYTHING -->
<script src="assets/logo.js"></script>
<script src="assets/themeswitcher.js"></script>
</body>
</html>
the way through the project plan, and
<!-- End Markdown content -->
</xmp>
<div w3-include-html="_words-of-wisdom.html"></div>
<div w3-include-html="_footer.html"></div>
<script>
w3IncludeHTML();
</script>
<script src="http://strapdownjs.com/v/0.2/strapdown.js"></script>
<!-- Include it AFTER strapdown -->
<script src="assets/strapdown/strapdown-topbar.min.js"></script>
<!-- Include it AFTER EVERYTHING -->
<script src="assets/logo.js"></script>
<script src="assets/themeswitcher.js"></script>
</body>
</html>
schedule...
<!-- End Markdown content -->
</xmp>
<div w3-include-html="_words-of-wisdom.html"></div>
<div w3-include-html="_footer.html"></div>
<script>
w3IncludeHTML();
</script>
<script src="http://strapdownjs.com/v/0.2/strapdown.js"></script>
<!-- Include it AFTER strapdown -->
<script src="assets/strapdown/strapdown-topbar.min.js"></script>
<!-- Include it AFTER EVERYTHING -->
<script src="assets/logo.js"></script>
<script src="assets/themeswitcher.js"></script>
</body>
</html>
::We are approximately 30% of the way through the project plan, and running about 2 days ahead of schedule...
::The reason for the change in estimated release date is...
::To stay on schedule, we have slipped enhancements [issue92](ISSUE-TRACKER-URL),
::To stay on schedule, we have slipped enhancements [issue92](ISSUE-TRACKER-URL),
[issue 101](ISSUE-TRACKER-URL), and [issue 129](ISSUE-TRACKER-URL) to a later
release. These issues were selected because ...

57
Summary.md
View File

@ -4,19 +4,20 @@
from the project [Home](Home).*
#### What problem does this project address?
::2-4 SENTENCE PROBLEM
#### What is the goal of this project?
::2-4 SENTENCE GOAL
#### What is the scope of this project
::2-4 SENTENCE SCOPE
### Status
*TODO: Briefly describe the status of this project. E.g., what phase are
you in? And, what is your next major milestone? Detailed project status
is written in the status reports, not here.*
*TODO: Briefly describe the status of this project. E.g., what phase are you in? And, what is your next major milestone? Detailed project status is written in the status reports, not here.*
::We have completed our second beta release and are currently working on
adding more of the functionality described in our product
@ -25,7 +26,8 @@ adding more of the functionality described in our product
::The next major milestone is a third beta release with nearly complete
functionality and a wider set of testers.
#### Status reports:
#### Status reports
- ::[Status report 1](status-report.html)
- ::[Status report 2](status-report2.html)
- ::Etc.
@ -37,23 +39,27 @@ condensed from the [project plan](Project-Plan), [resource needs](Resource-Needs
and [legal issues](legal.html) documents.*
#### What are the deadlines for this project?
- ::DATE: MILESTONE
- ::DATE: MILESTONE
- ::DATE: MILESTONE
- ::DATE: RELEASE-NUMBER
#### Who is working on this project?
- ::100% PERSON-NAME
- ::100% PERSON-NAME
- ::75% PERSON-NAME
- ::33% PERSON-NAME
#### What capital resources are allocated to this project?
- ::HARDWARE
- ::SOFTWARE LICENSE
- ::FACILITIES
#### What are the main legal concerns for this project?
- ::Intellectual property: DESCRIPTION
- ::Privacy and security: DESCRIPTION
- ::Potential harm: DESCRIPTION
@ -67,16 +73,19 @@ condensed from the [user needs](User-Needs),
and [feature set](Feature-Set) documents.*
#### Who are the project stakeholders?
- ::PROJECT CHAMPION / EXECUTIVE SPONSOR
- ::DEPARTMENTS WITHIN YOUR COMPANY
- ::CORPORATE PARTNERS
- ::KEY CUSTOMERS
#### What user needs have you gathered?
- ::[User stories](LINK-TO-USER-STORIES)
- ::[Interview notes](LINK-TO-INTERVIEW-NOTES)
#### What are the requirements specifications?
- ::[Use cases](LINK-TO-USE-CASES)
- ::[Feature specifications](LINK-TO-FEATURE-SPECS)
- ::[Environmental requirements](LINK-TO-ENV-REQ)
@ -89,6 +98,7 @@ condensed from the [design](Design) template and associated
worksheets.*
#### What are your ranked design goals?
1. ::Correctness
- ::This design correctly matches the
given requirements.
@ -118,6 +128,7 @@ worksheets.*
other resources.
#### Where are your design documents?
- ::[UML class diagram](LINK-TO-CLASS-DIAGRAM)
- ::[UML class diagram](LINK-TO-CLASS-DIAGRAM)
- ::[UML state diagram](LINK-TO-STATE-DIAGRAM)
@ -132,18 +143,20 @@ This is condensed from the [QA plan](QA-Plan), [test
suite](test-suite), and [test cases](test-cases.html) documents.*
#### What are your ranked quality goals?
1. ::Correctness
2. ::Robustness
3. ::Accuracy
4. ::Compatibility
5. ::Usability
6. ::Security
7. ::Reliability
8. ::Scalability
9. ::Operability
1. ::Correctness
2. ::Robustness
3. ::Accuracy
4. ::Compatibility
5. ::Usability
6. ::Security
7. ::Reliability
8. ::Scalability
9. ::Operability
10. ::Maintainability
#### What QA activities will you use?
- ::Preconditions and assertions
- ::Buddy reviews
- ::Review meetings
@ -151,28 +164,33 @@ suite](test-suite), and [test cases](test-cases.html) documents.*
- ::System testing
#### Where are the test cases?
- ::[Test case](LINK-TO-TEST-CASE)
- ::[Test case](LINK-TO-TEST-CASE)
- ::[Test case](LINK-TO-TEST-CASE)
- ::[Test case](LINK-TO-TEST-CASE)
### Packaging, Delivery, and Deployment
Where is the release checklist or sign-off document?
::[Release checklist](LINK-TO-RELEASE-CHECKLIST)
#### How is the product packaged and deployed?
- ::Packaging: DESCRIPTION
- ::Deployment: DESCRIPTION
- ::[Release notes](LINK-TO-RELEASE-NOTES)
#### How is the product installed?
- ::System requirements: DESCRIPTION
- ::STEP
- ::STEP
- ::STEP
### User Support
Where is the user documentation?
- ::[User guide](LINK-TO-USER-GUIDE)
@ -184,18 +202,23 @@ Where is the user documentation?
- ::Issue tracking: DESCRIPTION
### Glossary
*TODO: Define any technical terms that you use above, if a new member of
the team would not already know them. This is condensed from the
[glossary](Glossary) documents.*
##### ::TECHNICAL TERM
##### ::TECHNICAL TERM 1
::DEFINITION
##### ::TECHNICAL TERM
##### ::TECHNICAL TERM 2
::DEFINITION
##### ::TECHNICAL TERM
##### ::TECHNICAL TERM 3
::DEFINITION
##### ::TECHNICAL TERM
##### ::TECHNICAL TERM 4
::DEFINITION

64
Target-and-Benefits.md
View File

@ -1,13 +1,17 @@
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Related Documents
- [Proposal](Proposal) > Target Audience and Benefits
- [Project proposal](Proposal) > [User needs](User-Needs)
- [Glossary](Glossary)
---
**Process impact:** This document helps identify potential customers and
@ -72,9 +76,9 @@ products. Benefits to the development organization should be listed in
&lt;ol> tag), otherwise use bullet lists (the HTML &lt;ul> tag).*
- ::Increases play-value
- ::Many players enjoy games more when they play as a team.
- ::Clans can greatly extend the time that a player plays one game,
thus reducing the expense of buying new games.
- ::Many players enjoy games more when they play as a team.
- ::Clans can greatly extend the time that a player plays one game,
thus reducing the expense of buying new games.
- ::Improves customer population
1. ::Clan players often encourage their friends to play the same
game, which gives game vendors more revenue.
@ -85,36 +89,36 @@ products. Benefits to the development organization should be listed in
3. ::Clans attract the more experienced players who can give better
feedback to game vendors.
- ::Reduces current costs
- ::Reduced staffing costs
- ::Reduced training costs
- ::Reduced maintenance costs
- ::Reduced infrastructure costs
- ::Makes current processes more efficient
- ::Avoids penalty clauses of current contracts
- ::Reduced staffing costs
- ::Reduced training costs
- ::Reduced maintenance costs
- ::Reduced infrastructure costs
- ::Makes current processes more efficient
- ::Avoids penalty clauses of current contracts
- ::Opens new business opportunities
- ::Opens new sales opportunities
- ::Improves sales success rate or size
- ::Opens partnership opportunities
- ::Triggers bonus clauses current contracts
- ::Opens new sales opportunities
- ::Improves sales success rate or size
- ::Opens partnership opportunities
- ::Triggers bonus clauses current contracts
- ::Satisfies stakeholders
- ::Satisfies shareholders
- ::Satisfies partners
- ::Satisfies management or executives
- ::Satisfies government regulation or corporate policy
- ::Improves morale
- ::Satisfies shareholders
- ::Satisfies partners
- ::Satisfies management or executives
- ::Satisfies government regulation or corporate policy
- ::Improves morale
- ::Helps take advantage of changing marketplace
- ::Reduced inventory or need for advance planning
- ::Speeds time-to-market
- ::Optimizes supply chain
- ::Reduces fixed costs
- ::Reduced inventory or need for advance planning
- ::Speeds time-to-market
- ::Optimizes supply chain
- ::Reduces fixed costs
- ::Type of benefit
1. ::Most valuable benefit
2. ::Benefit
3. ::Benefit
- ::Type of benefit
- ::Benefit
- ::Benefit
- ::Benefit
- ::Benefit
- ::Benefit
- ::Benefit
### Potential Downside
@ -123,11 +127,11 @@ system? List as above. Note, these are not risks to the success of your
implementation, assume that you build the system as specified on time.*
- ::Privacy
- ::When players opt into clans, they also opt into receiving
marketing information from game vendors. Usually this is a good
thing if the players are interested, but it can also
be annoying.
- ::Cheaters will be publicly named as cheaters and blocked from
- ::When players opt into clans, they also opt into receiving
marketing information from game vendors. Usually this is a good
thing if the players are interested, but it can also
be annoying.
- ::Cheaters will be publicly named as cheaters and blocked from
game servers, thus they lose the ability to play/cheat.
- ::Type of downside
1. ::Worst downside

55
Test-Case-Format.md
View File

@ -1,6 +1,8 @@
##### Related Documents
- [QA Plan](QA-Plan) > [Test Suite](Test-Suite) > Test Case Format
---
**Process impact:** This reference page documents the format of test
@ -14,20 +16,26 @@ given to a new team member who would be able to quickly start to carry
out the tests and find defects.
### unique-test-case-id: Test Case Title
---
#### Purpose
**Purpose:**
::Short sentence or two about the aspect of the system is being tested. If this gets too long, break the test case up or put more information into the feature descriptions.
#### Prereq
Assumptions that must be met before the test case can be run. E.g., &quot;logged in&quot;, &quot;guest login allowed&quot;, &quot;user testuser exists&quot;.
**Prerequisite:**
Assumptions that must be met before the test case can be run. E.g., &quot;logged in&quot;, &quot;guest login allowed&quot;, &quot;user test-user exists&quot;.
**Test Data:**
#### Test Data
List of variables and their possible values used in the test case. You can list specific values or describe value ranges. The test case should be performed once for each *combination* of values. These values are written in set notation, one per line. E.g.:
- ::loginID = {Valid loginID, invalid loginID, valid email, invalid email, empty}
- ::password = {valid, invalid, empty}
- ::loginID = {Valid loginID, invalid loginID, valid email, invalid email, empty}
- ::password = {valid, invalid, empty}
**Steps:**
#### Steps
Steps to carry out the test. See step formating rules below.
- ::visit LoginPage
@ -40,7 +48,7 @@ Steps to carry out the test. See step formating rules below.
- ::see PersonalPage
- ::verify that welcome message is correct username
#### Notes and Questions:
**Notes and Questions:**
- ::NOTE
- ::QUESTION
@ -50,55 +58,65 @@ Steps to carry out the test. See step formating rules below.
Each step can be written very tersely using the following keywords:
#### ::login \[as ROLE-OR-USER\]
::Log into the system with a given user or a user of the given type.
Usually only stated explicitly when the test case depends on the
permissions of a particular role or involves a workflow between
different users.
#### ::visit LOCATION
::Visit a page or screen. For web applications, LOCATION may be
a hyperlink. The location should be a well-known starting point
(e.g., the Login screen), drilling down to specific pages should be
part of the test.
#### ::enter FIELD-NAME \[as VALUE\] \[in SCREEN-LOCATION\]
::Fill in a named form field. VALUE can be a literal value or the name
of a variable defined in the "Test Data" section. The FIELD-NAME
itself can be a variable name when the UI field for that value is
clear from context, e.g., "enter password".
#### ::enter FIELDS
::Fill in all fields in a form when their values are clear from
context or when their specific values are not important in this
test case.
#### ::click "LINK-LABEL" \[in SCREEN-LOCATION\]
::Follow a labeled link or press a button. The screen location can be
a predefined panel name or English phrase. Predefined panel names
are based on GUI class names, master template names, or titles of
boxes on the page.
#### ::click BUTTON-NAME \[in SCREEN-LOCATION\]
::Press a named button. This step should always be followed by a "see"
step to check the results.
#### ::see SCREEN-OR-PAGE
::The tester should see the named GUI screen or web page. The general
correctness of the page should be testable based on the
feature description.
#### ::verify CONDITION
::The tester should see that the condition has been satisfied. This
type of step usually follows a "see" step at the end of the
test case.
#### ::verify CONTENT \[is VALUE\]
::The tester should see the named content on the current page, the
correct values should be clear from the test data, or
given explicitly. This type of step usually follows a "see" step at
the end of the test case.
#### ::perform TEST-CASE-NAME
::This is like a subroutine call. The tester should perform all the
steps of the named test case and then continue on to the next step
of this test case.
@ -108,24 +126,3 @@ expected output is very clear. A test case can have multiple verify
steps in the middle or at the end. Having multiple verify steps can be
useful if you want a smaller number of long tests rather than a large
number of short tests.*
<!-- End Markdown content -->
</xmp>
<div w3-include-html="_words-of-wisdom.html"></div>
<div w3-include-html="_footer.html"></div>
<script>
w3IncludeHTML();
</script>
<script src="http://strapdownjs.com/v/0.2/strapdown.js"></script>
<!-- Include it AFTER strapdown -->
<script src="assets/strapdown/strapdown-topbar.min.js"></script>
<!-- Include it AFTER EVERYTHING -->
<script src="assets/logo.js"></script>
<script src="assets/themeswitcher.js"></script>
</body>
</html>

247
Test-Cases.md
View File

@ -1,34 +1,42 @@
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Related Documents
[QA Plan](QA-Plan) > [Test Suite](Test-Suite) > Test Cases
[System test case format](Test-Case-Format)
::LINKS TO RELEVANT STANDARDS
::LINKS TO OTHER DOCUMENTS
---
### login-1: Normal User Login
#### Purpose:
::Test that users can log in with the proper username or
**Purpose:**
::Test that users can log in with the proper username or
email address and their password.
#### Prereq:
**Prerequisite:**
::User is not already logged in.
::User testuser exists, and account is in good standing.
::User test-user exists, and account is in good standing.
#### Test Data:
::usernameOrEmail = {testuser, bogususer, testuser@nospam.com,
**Test Data:**
::usernameOrEmail = {test-user, bogus-user, test-user@nospam.com,
test@user@nospam.com, empty}
::password = {valid, invalid, empty}
#### Steps:
**Steps:**
::Steps to carry out the test. See step formating rules below.
- ::visit LoginPage
@ -41,28 +49,33 @@ test@user@nospam.com, empty}
- ::see PersonalPage
- ::verify that welcome message is correct username
#### Notes and Questions:
**Notes and Questions:**
- ::This assumes that user has not agreed to terms-of-use already.
- ::Does this work without browser cookies?
---
### login-2: Locked-out User Login
#### Purpose:
::Test that a user who has been locked out by a moderator, cannot
log in, They should see a message indicating that they were locked
**Purpose:**
::Test that a user who has been locked out by a moderator, cannot
log in, They should see a message indicating that they were locked
out.
#### Prereq:
**Prerequisite:**
::User is not already logged in.
::User testuser2 exists, and has been locked out
::User test-user2 exists, and has been locked out
**Test Data:**
#### Test Data:
::usernameOrEmail = {testuser2, testuser2@nospam.com}
::usernameOrEmail = {test-user2, test-user2@nospam.com}
::password = {valid}
#### Steps:
**Steps:**
::Steps to carry out the test. See step formating rules below.
- ::visit LoginPage
@ -72,33 +85,37 @@ out.
- ::see LoginPage
- ::verify warning message is the locked-out message
#### Notes and Questions:
**Notes and Questions:**
- ::Does this work without browser cookies?
### unique-test-case-id1: Test Case Title
#### Purpose:
::Short sentence or two about the aspect of the system is
being tested. If this gets too long, break the test case
**Purpose:**
::Short sentence or two about the aspect of the system is
being tested. If this gets too long, break the test case
up or put more information into the feature descriptions.
#### Prereq:
::Assumptions that must be met before the test case can be run.
E.g., &quot;logged in&quot;, &quot;guest login allowed&quot;,
&quot;user testuser exists&quot;.
**Prerequisite:**
#### Test Data:
::List of variables and their possible values used in the test case.
You can list specific values or describe value ranges. The test case
should be performed once for each *combination* of values. These
::Assumptions that must be met before the test case can be run.
E.g., &quot;logged in&quot;, &quot;guest login allowed&quot;,
&quot;user test-user exists&quot;.
**Test Data:**
::List of variables and their possible values used in the test case.
You can list specific values or describe value ranges. The test case
should be performed once for each *combination* of values. These
values are written in set notation, one per line. E.g.:
- loginID = {Valid loginID, invalid loginID, valid email, invalid
- loginID = {Valid loginID, invalid loginID, valid email, invalid
email, empty}
- password = {valid, invalid, empty}
#### Steps:
**Steps:**
::Steps to carry out the test. See step formating rules below.
- ::visit LoginPage
@ -111,34 +128,40 @@ values are written in set notation, one per line. E.g.:
- ::see PersonalPage
- ::verify that welcome message is correct username
#### Notes and Questions:
**Notes and Questions:**
- ::NOTE
- ::QUESTION
---
### unique-test-case-id2: Test Case Title
#### Purpose:
::Short sentence or two about the aspect of the system is
being tested. If this gets too long, break the test case
**Purpose:**
::Short sentence or two about the aspect of the system is
being tested. If this gets too long, break the test case
up or put more information into the feature descriptions.
#### Prereq:
::Assumptions that must be met before the test case can be run.
E.g., &quot;logged in&quot;, &quot;guest login allowed&quot;,
&quot;user testuser exists&quot;.
**Prerequisite:**
#### Test Data:
::List of variables and their possible values used in the test case.
You can list specific values or describe value ranges. The test case
should be performed once for each *combination* of values. These
::Assumptions that must be met before the test case can be run.
E.g., &quot;logged in&quot;, &quot;guest login allowed&quot;,
&quot;user test-user exists&quot;.
**Test Data:**
::List of variables and their possible values used in the test case.
You can list specific values or describe value ranges. The test case
should be performed once for each *combination* of values. These
values are written in set notation, one per line. E.g.:
- ::loginID = {Valid loginID, invalid loginID, valid email, invalid
- ::loginID = {Valid loginID, invalid loginID, valid email, invalid
email, empty}
- ::password = {valid, invalid, empty}
#### Steps:
**Steps:**
::Steps to carry out the test. See step formating rules below.
- ::visit LoginPage
@ -151,33 +174,38 @@ values are written in set notation, one per line. E.g.:
- ::see PersonalPage
- ::verify that welcome message is correct username
#### Notes and Questions:
**Notes and Questions:**
- ::NOTE
- ::QUESTION
### unique-test-case-id3: Test Case Title
#### Purpose:
**Purpose:**
::Short sentence or two about the aspect of the system is
being tested. If this gets too long, break the test case
up or put more information into the feature descriptions.
#### Prereq:
::Assumptions that must be met before the test case can be run.
E.g., &quot;logged in&quot;, &quot;guest login allowed&quot;,
&quot;user testuser exists&quot;.
**Prerequisite:**
#### Test Data:
::List of variables and their possible values used in the test case.
You can list specific values or describe value ranges. The test case
should be performed once for each *combination* of values. These
::Assumptions that must be met before the test case can be run.
E.g., &quot;logged in&quot;, &quot;guest login allowed&quot;,
&quot;user test-user exists&quot;.
**Test Data:**
::List of variables and their possible values used in the test case.
You can list specific values or describe value ranges. The test case
should be performed once for each *combination* of values. These
values are written in set notation, one per line. E.g.:
- ::loginID = {Valid loginID, invalid loginID, valid email, invalid
- ::loginID = {Valid loginID, invalid loginID, valid email, invalid
email, empty}
- ::password = {valid, invalid, empty}
#### Steps:
**Steps:**
::Steps to carry out the test. See step formating rules below.
- ::visit LoginPage
@ -190,34 +218,40 @@ values are written in set notation, one per line. E.g.:
- ::see PersonalPage
- ::verify that welcome message is correct username
#### Notes and Questions:
**Notes and Questions:**
- ::NOTE
- ::QUESTION
---
### unique-test-case-id4: Test Case Title
#### Purpose:
::Short sentence or two about the aspect of the system is
being tested. If this gets too long, break the test case
**Purpose:**
::Short sentence or two about the aspect of the system is
being tested. If this gets too long, break the test case
up or put more information into the feature descriptions.
#### Prereq:
::Assumptions that must be met before the test case can be run.
E.g., &quot;logged in&quot;, &quot;guest login allowed&quot;,
&quot;user testuser exists&quot;.
**Prerequisite:**
#### Test Data:
::List of variables and their possible values used in the test case.
You can list specific values or describe value ranges. The test case
should be performed once for each *combination* of values. These
::Assumptions that must be met before the test case can be run.
E.g., &quot;logged in&quot;, &quot;guest login allowed&quot;,
&quot;user test-user exists&quot;.
**Test Data:**
::List of variables and their possible values used in the test case.
You can list specific values or describe value ranges. The test case
should be performed once for each *combination* of values. These
values are written in set notation, one per line. E.g.:
- ::loginID = {Valid loginID, invalid loginID, valid email, invalid
- ::loginID = {Valid loginID, invalid loginID, valid email, invalid
email, empty}
- ::password = {valid, invalid, empty}
#### Steps:
**Steps:**
::Steps to carry out the test. See step formating rules below.
- ::visit LoginPage
@ -230,33 +264,38 @@ values are written in set notation, one per line. E.g.:
- ::see PersonalPage
- ::verify that welcome message is correct username
#### Notes and Questions:
**Notes and Questions:**
- ::NOTE
- ::QUESTION
### unique-test-case-id5: Test Case Title
#### Purpose:
::Short sentence or two about the aspect of the system is
being tested. If this gets too long, break the test case
**Purpose:**
::Short sentence or two about the aspect of the system is
being tested. If this gets too long, break the test case
up or put more information into the feature descriptions.
#### Prereq:
::Assumptions that must be met before the test case can be run.
E.g., &quot;logged in&quot;, &quot;guest login allowed&quot;,
&quot;user testuser exists&quot;.
**Prerequisite:**
#### Test Data:
::List of variables and their possible values used in the test case.
You can list specific values or describe value ranges. The test case
should be performed once for each *combination* of values. These
::Assumptions that must be met before the test case can be run.
E.g., &quot;logged in&quot;, &quot;guest login allowed&quot;,
&quot;user test-user exists&quot;.
**Test Data:**
::List of variables and their possible values used in the test case.
You can list specific values or describe value ranges. The test case
should be performed once for each *combination* of values. These
values are written in set notation, one per line. E.g.:
- ::loginID = {Valid loginID, invalid loginID, valid email, invalid
- ::loginID = {Valid loginID, invalid loginID, valid email, invalid
email, empty}
- ::password = {valid, invalid, empty}
#### Steps:
**Steps:**
::Steps to carry out the test. See step formating rules below.
- ::visit LoginPage
@ -269,34 +308,39 @@ values are written in set notation, one per line. E.g.:
- ::see PersonalPage
- ::verify that welcome message is correct username
#### Notes and Questions:
**Notes and Questions:**
- ::NOTE
- ::QUESTION
---
### unique-test-case-id6: Test Case Title
#### Purpose:
::Short sentence or two about the aspect of the system is
being tested. If this gets too long, break the test case
**Purpose:**
::Short sentence or two about the aspect of the system is
being tested. If this gets too long, break the test case
up or put more information into the feature descriptions.
#### Prereq:
::Assumptions that must be met before the test case can be run.
E.g., &quot;logged in&quot;, &quot;guest login allowed&quot;,
&quot;user testuser exists&quot;.
**Prerequisite:**
#### Test Data:
::List of variables and their possible values used in the test case.
You can list specific values or describe value ranges. The test case
should be performed once for each *combination* of values. These
::Assumptions that must be met before the test case can be run.
E.g., &quot;logged in&quot;, &quot;guest login allowed&quot;,
&quot;user test-user exists&quot;.
**Test Data:**
::List of variables and their possible values used in the test case.
You can list specific values or describe value ranges. The test case
should be performed once for each *combination* of values. These
values are written in set notation, one per line. E.g.:
- ::loginID = {Valid loginID, invalid loginID, valid email, invalid
- ::loginID = {Valid loginID, invalid loginID, valid email, invalid
email, empty}
- ::password = {valid, invalid, empty}
#### Steps:
**Steps:**
::Steps to carry out the test. See step formating rules below.
- ::visit LoginPage
@ -309,6 +353,7 @@ values are written in set notation, one per line. E.g.:
- ::see PersonalPage
- ::verify that welcome message is correct username
#### Notes and Questions:
**Notes and Questions:**
- ::NOTE
- ::QUESTION

5
Test-Run-Suite.md
View File

@ -1,14 +1,18 @@
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Related Documents
- [QA Plan](QA-Plan) > Test Run Suite
- [Test suite](Test-Suite)
- ::LINKS TO RELEVANT STANDARDS
- ::LINKS TO OTHER DOCUMENTS
---
**Process impact:** This is a test run log for manual system testing. A
@ -19,6 +23,7 @@ degree to which the system has been tested helps to assess progress,
assess risk, and focus ongoing testing efforts.
*TODO:
- Review the [target audience](Target-and-Benefits),
[environmental requirements](SRS#environmental), and [possible
deployments](Design-Architecturel#deployment) to understand the

44
Test-Runs.md
View File

@ -1,14 +1,18 @@
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Related Documents
- [QA Plan](QA-Plan) > [Test Run Suite](Test-Run-Suite) > Test Runs
- [Test suit](Test-Suite)
- ::LINKS TO RELEVANT STANDARDS
- ::LINKS TO OTHER DOCUMENTS
---
*TODO: Use this file to record the results of each test run. Or, use your
@ -28,11 +32,7 @@ issue tracking tool to plan and track test runs.*
::NAME-OF-SERVER | DESCRIPTION-OF-TEST-ENVIRONMENT
**Test Description**
::Performed all [manual system tests](Test-Cases).
**Test Run Results:**
**Test Description:**
::Pending | Passed | FAILED
@ -40,6 +40,7 @@ issue tracking tool to plan and track test runs.*
- ::NOTE
- ::QUESTION
---
### TR-01: Test Run
@ -56,11 +57,7 @@ issue tracking tool to plan and track test runs.*
::NAME-OF-SERVER | DESCRIPTION-OF-TEST-ENVIRONMENT
**Test Description**
::Performed all [manual system tests](Test-Cases).
**Test Run Results:**
**Test Description:**
::Pending | Passed | FAILED
@ -68,6 +65,7 @@ issue tracking tool to plan and track test runs.*
- ::NOTE
- ::QUESTION
---
### TR-02: Test Run
@ -78,13 +76,13 @@ issue tracking tool to plan and track test runs.*
**Tested by:**
::EMAIL-ADDRESS-OF-TEST-ENGINEER
:: EMAIL-ADDRESS-OF-TEST-ENGINEER
**Location or Configuration:**
::NAME-OF-SERVER | DESCRIPTION-OF-TEST-ENVIRONMENT
**Test Description**
**Test Description:**
::Performed all [manual system tests](Test-Cases).
@ -96,6 +94,7 @@ issue tracking tool to plan and track test runs.*
- ::NOTE
- ::QUESTION
---
### TR-03: Test Run
@ -112,7 +111,7 @@ issue tracking tool to plan and track test runs.*
::NAME-OF-SERVER | DESCRIPTION-OF-TEST-ENVIRONMENT
**Test Description**
**Test Description:**
::Performed all [manual system tests](Test-Cases).
@ -124,6 +123,7 @@ issue tracking tool to plan and track test runs.*
- ::NOTE
- ::QUESTION
---
### TR-10: Test Run
@ -140,7 +140,7 @@ issue tracking tool to plan and track test runs.*
::NAME-OF-SERVER | DESCRIPTION-OF-TEST-ENVIRONMENT
**Test Description**
**Test Description:**
::Performed all [manual system tests](Test-Cases).
@ -152,6 +152,7 @@ issue tracking tool to plan and track test runs.*
- ::NOTE
- ::QUESTION
---
### TR-11: Test Run
@ -168,7 +169,7 @@ issue tracking tool to plan and track test runs.*
::NAME-OF-SERVER | DESCRIPTION-OF-TEST-ENVIRONMENT
**Test Description**
**Test Description:**
::Performed all [manual system tests](Test-Cases).
@ -180,6 +181,7 @@ issue tracking tool to plan and track test runs.*
- ::NOTE
- ::QUESTION
---
### TR-12: Test Run
@ -196,7 +198,7 @@ issue tracking tool to plan and track test runs.*
::NAME-OF-SERVER | DESCRIPTION-OF-TEST-ENVIRONMENT
**Test Description**
**Test Description:**
::Performed all [manual system tests](Test-Cases).
@ -208,6 +210,7 @@ issue tracking tool to plan and track test runs.*
- ::NOTE
- ::QUESTION
---
### TR-13: Test Run
@ -224,7 +227,7 @@ issue tracking tool to plan and track test runs.*
::NAME-OF-SERVER | DESCRIPTION-OF-TEST-ENVIRONMENT
**Test Description**
**Test Description:**
::Performed all [manual system tests](Test-Cases).
@ -236,6 +239,7 @@ issue tracking tool to plan and track test runs.*
- ::NOTE
- ::QUESTION
---
### TR-20: Test Run
@ -252,7 +256,7 @@ issue tracking tool to plan and track test runs.*
::NAME-OF-SERVER | DESCRIPTION-OF-TEST-ENVIRONMENT
**Test Description**
**Test Description:**
::Performed all [manual system tests](Test-Cases).
@ -264,6 +268,7 @@ issue tracking tool to plan and track test runs.*
- ::NOTE
- ::QUESTION
---
### TR-21: Test Run
@ -280,7 +285,7 @@ issue tracking tool to plan and track test runs.*
::NAME-OF-SERVER | DESCRIPTION-OF-TEST-ENVIRONMENT
**Test Description**
**Test Description:**
::Performed all [manual system tests](Test-Cases).
@ -292,4 +297,5 @@ issue tracking tool to plan and track test runs.*
- ::NOTE
- ::QUESTION
---

4
Test-Suite.md
View File

@ -1,14 +1,18 @@
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Related Documents
- [QA Plan](QA-Plan) > Test Suite
- [Test case format](Test-Case-Format)
- ::LINKS TO RELEVANT STANDARDS
- ::LINKS TO OTHER DOCUMENTS
---
**Process impact:** This is a test suite for manual system testing. It

25
Use-Case-Format.md
View File

@ -1,6 +1,8 @@
##### Related Documents
- [SRS](SRS) > [Use Case Suite](Use-Case-Suite) > Use Case Format
---
**Process impact:** This reference page documents the format of use
@ -13,26 +15,28 @@ document. Anything you mention here will apply to all use cases in that
file.*
---
### Aspects common to all use cases
#### Direct Actors:
**Direct Actors:**
- ::User: end-user in any role
- ::System: The system being built
- ::When actors are not listed, assume User is doing it.
- ::Items beginning with &quot;see&quot; indicate that System has presented a new screen.
#### Stakeholders:
**Stakeholders:**
::The user who is entering the data, and those who will read it
#### Prereq:
**Prerequisite:**
::Project is set up
*TODO: Copy and paste this use case template as many times as needed in
your [Use Cases](Use-Cases) document. Only use those fields that
are not the same as the default for all use cases.*
---
### UC-00: USE CASE NAME
**Summary:**
@ -55,7 +59,7 @@ are not the same as the default for all use cases.*
::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER
**Prereq:**
**Prerequisite:**
- ::PRECONDITION
- ::PRECONDITION
@ -75,30 +79,34 @@ are not the same as the default for all use cases.*
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
**Notes and Questions**
**Notes and Questions:**
- ::NOTE
- ::NOTE
- ::QUESTION
- ::QUESTION
---
### Format of Use Case Steps
Try to start each step with one of these action words:
#### login \[as ROLE or USER\]
Log into the system with a given user or a user of the given type.
Usually usually only stated explicitly when the test case involves a
workflow between different users.
#### visit LOCATION
Visit a page or GUI window. State the user's intention, don't say
too much about UI choices that could change later. E.g., WRONG:
"Press the 'Advanced...' button on the File | Page Setup dialog".
RIGHT: "Visit the page margin configuration dialog".
#### enter INFORMATION
Fill in specific information. Try to state the information in
some detail. E.g., WRONG: "Enter customer information." RIGHT:
"Enter customer shipping address and discount code." Don't commit to
@ -106,6 +114,7 @@ details of a particular UI, i.e., don't name specific UI fields that
might change later.
#### COMMAND
Describe a command that the user can tell the system to do. State
the user's intent, not the label on a particular UI widget. This
will usually be followed by a "see" step where the user sees a
@ -113,6 +122,7 @@ confirmation of their action. E.g., WRONG: "Control-P, OK". RIGHT:
"Print the current document with default settings".
#### see CONTENT
The user should see the specified information on the currently
presented web page or GUI window. Try to be specific about the
information that is seen, but try not to refer to specific
@ -121,6 +131,7 @@ supposed to notice on that page?) RIGHT: "see list of users with the
newly added user in the list".
#### perform USE-CASE-NAME
This is like a subroutine call. The user will do all the steps of
the named use case and then continue on with the next step of this
use case.

7
Use-Case-Suite.md
View File

@ -1,10 +1,13 @@
##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
::X.Y.Z
##### Related Documents
- [SRS](SRS) > Use Case Suite
- [Project proposal](Proposal) > [User needs](User-Needs)
- [SRS](SRS) > [Feature set](Feature-Set)
@ -12,6 +15,7 @@
- ::LINK TO USE CASE DIAGRAM
- ::LINKS TO RELEVANT STANDARDS
- ::LINKS TO OTHER DOCUMENTS
---
**Process impact:** A use case suite is simply a table of contents for
@ -53,8 +57,7 @@ cases, explicitly mark it "N/A". Otherwise, mark it "TODO".*
- ::[UC-20](Use-Cases#UC-20) Enroll in course
- ::[UC-21](Use-Cases#UC-21) Drop course
- ::Scalability and availability
- ::N/A: These features are completely automated and internal, users
never interact with them
- ::N/A: These features are completely automated and internal, users never interact with them
- ::Facilities management
- ::[UC-30](Use-Cases#UC-30) View room description
- ::[UC-31](Use-Cases#UC-31) Assign course to room

187
Use-Cases.md
View File

@ -1,16 +1,20 @@
##### Project
::PROJECT-NAME
##### Internal Release Number
::X.Y.Z
##### Related Documents
- [SRS](SRS) > [Use Case Suite](Use-Case-Suite) > Use Cases
- [Project proposal](Proposal) > [User needs](User-Needs), [SRS](SRS) > [Feature set](Feature-Set)
- [Use case format](Use-Case-Format)
- ::LINK TO USE CASE DIAGRAM
- ::LINKS TO RELEVANT STANDARDS
- ::LINKS TO OTHER DOCUMENTS
- [Project proposal](Proposal) > [User needs](User-Needs), [SRS](SRS) > [Feature set](Feature-Set)
- [Use case format](Use-Case-Format)
- ::LINK TO USE CASE DIAGRAM
- ::LINKS TO RELEVANT STANDARDS
- ::LINKS TO OTHER DOCUMENTS
---
*TODO: Note any aspects that are common to all use cases here. This helps
@ -21,16 +25,16 @@ note it's specific value to replace or add to the default.*
**Direct Actors:**
- ::User: end-user in any role
- ::System: The system being built
- ::When actors are not listed, assume User is doing it.
- ::Items beginning with "see" indicate that System has presented a new screen.
- ::User: end-user in any role
- ::System: The system being built
- ::When actors are not listed, assume User is doing it.
- ::Items beginning with "see" indicate that System has presented a new screen.
**Stakeholders:**
::Project Owners and other members
**Prereq:**
**Prerequisite:**
::User is logged in
@ -47,6 +51,7 @@ cases first and come back to less important ones later.*
[guidelines for writing use cases](Use-Case-Format#further-information).*
---
### UC-00: Configure the site
**Summary:**
@ -74,18 +79,18 @@ cases first and come back to less important ones later.*
5. ::confirm changes
6. ::see SiteConfiguration page again, with updated values
**Alternative Scenario Extensions:**
- ::If the timezone abbreviation is incorrect, an error message will be displayed and no changes will be made.
**Notes and Questions**
**Notes and Questions:**
- ::How will administrators know the right timezone abbreviation?
- They would know it if they live in that timezone. Maybe we could
provide a drop-down list of all choices, but each would need some explanation.
---
### UC-01: Register as a new user
**Summary:**
@ -113,13 +118,14 @@ cases first and come back to less important ones later.*
**Alternative Scenario Extensions:**
- ::If the username is taken, then the system will suggest an available username based on the user's email address and/or real name.
**Notes and Questions**
**Notes and Questions:**
- ::NOTE
- ::QUESTION
---
### UC-02: Request new password
**Summary:**
@ -138,12 +144,13 @@ cases first and come back to less important ones later.*
- ::TODO
**Notes and Questions**
**Notes and Questions:**
- ::Alternatively, we could use password hints.
---
### UC-03: Edit user profile
### UC-03: Edit user profile
** Summary:**
@ -162,6 +169,7 @@ cases first and come back to less important ones later.*
- ::TODO
---
### UC-04: View user profile
**Summary:**
@ -185,6 +193,7 @@ cases first and come back to less important ones later.*
- ::TODO
---
### UC-10: Create course
**Summary:**
@ -201,7 +210,7 @@ cases first and come back to less important ones later.*
**Direct Actors:**
::Admin: Web-site adminisator
::Admin: Web-site administrator
**Main Success Scenario:**
@ -212,6 +221,7 @@ cases first and come back to less important ones later.*
- ::see course list with new course added
---
### UC-11: View catalog description
**Summary:**
@ -232,14 +242,13 @@ cases first and come back to less important ones later.*
- ::click link to course description
- ::see course description in pop-up window
- ::close pop-up window to continue using application
**Notes and Questions:**
**Notes and Questions**
- ::How do we accommodate users that configure their browsers to block pop-ups?
---
---
### UC-20: Enroll in course
**Summary:**
@ -270,6 +279,7 @@ cases first and come back to less important ones later.*
- ::Course capacity and number of students currently waiting should be shown so that students may choose the section that they are most likely to be able to get into.
---
### UC-21: Drop a course
**Summary:**
@ -293,12 +303,13 @@ cases first and come back to less important ones later.*
- ::confirm choice
- ::see revised list of currently enrolled courses
**Notes and Questions**
**Notes and Questions:**
- ::Only one course can be dropped at a time. There is no need to allow students to quickly drop more than one course.
- ::It would be nice to offer an atomic "switch sections" operation that drops and adds another, or does nothing.
---
### UC-30: View room description
**Summary:**
@ -318,6 +329,7 @@ cases first and come back to less important ones later.*
- ::TODO
---
### UC-31: Assign course to room
**Summary:**
@ -339,6 +351,7 @@ cases first and come back to less important ones later.*
- ::STEP
---
### UC-40: USE CASE NAME
**Summary:**
@ -361,7 +374,7 @@ cases first and come back to less important ones later.*
::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER
**Prereq:**
**Prerequisite:**
- ::PRECONDITION
- ::PRECONDITION
@ -381,14 +394,15 @@ cases first and come back to less important ones later.*
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
**Notes and Questions**
**Notes and Questions:**
- ::NOTE
- ::NOTE
- ::QUESTION
- ::QUESTION
---
### UC-41: USE CASE NAME
**Summary:**
@ -411,7 +425,7 @@ cases first and come back to less important ones later.*
::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER
**Prereq:**
**Prerequisite:**
- ::PRECONDITION
- ::PRECONDITION
@ -431,14 +445,15 @@ cases first and come back to less important ones later.*
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
**Notes and Questions**
**Notes and Questions:**
- ::NOTE
- ::NOTE
- ::QUESTION
- ::QUESTION
---
### UC-42: USE CASE NAME
**Summary:**
@ -461,7 +476,7 @@ cases first and come back to less important ones later.*
::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER
**Prereq:**
**Prerequisite:**
- ::PRECONDITION
- ::PRECONDITION
@ -481,14 +496,15 @@ cases first and come back to less important ones later.*
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
**Notes and Questions**
**Notes and Questions:**
- ::NOTE
- ::NOTE
- ::QUESTION
- ::QUESTION
---
### UC-50: USE CASE NAME
**Summary:**
@ -511,7 +527,7 @@ cases first and come back to less important ones later.*
::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER
**Prereq:**
**Prerequisite:**
- ::PRECONDITION
- ::PRECONDITION
@ -531,14 +547,15 @@ cases first and come back to less important ones later.*
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
**Notes and Questions**
**Notes and Questions:**
- ::NOTE
- ::NOTE
- ::QUESTION
- ::QUESTION
---
### UC-51: USE CASE NAME
**Summary:**
@ -561,7 +578,7 @@ cases first and come back to less important ones later.*
::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER
**Prereq:**
**Prerequisite:**
- ::PRECONDITION
- ::PRECONDITION
@ -581,14 +598,15 @@ cases first and come back to less important ones later.*
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
**Notes and Questions**
**Notes and Questions:**
- ::NOTE
- ::NOTE
- ::QUESTION
- ::QUESTION
---
### UC-52: USE CASE NAME
**Summary:**
@ -611,7 +629,7 @@ cases first and come back to less important ones later.*
::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER
**Prereq:**
**Prerequisite:**
- ::PRECONDITION
- ::PRECONDITION
@ -631,14 +649,15 @@ cases first and come back to less important ones later.*
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
**Notes and Questions**
**Notes and Questions:**
- ::NOTE
- ::NOTE
- ::QUESTION
- ::QUESTION
---
### UC-60: USE CASE NAME
**Summary:**
@ -661,7 +680,7 @@ cases first and come back to less important ones later.*
::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER
**Prereq:**
**Prerequisite:**
- ::PRECONDITION
- ::PRECONDITION
@ -681,14 +700,15 @@ cases first and come back to less important ones later.*
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
**Notes and Questions**
**Notes and Questions:**
- ::NOTE
- ::NOTE
- ::QUESTION
- ::QUESTION
---
### UC-61: USE CASE NAME
**Summary:**
@ -711,7 +731,7 @@ cases first and come back to less important ones later.*
::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER
**Prereq:**
**Prerequisite:**
- ::PRECONDITION
- ::PRECONDITION
@ -731,14 +751,15 @@ cases first and come back to less important ones later.*
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
**Notes and Questions**
**Notes and Questions:**
- ::NOTE
- ::NOTE
- ::QUESTION
- ::QUESTION
---
### UC-62: USE CASE NAME
**Summary:**
@ -761,7 +782,7 @@ cases first and come back to less important ones later.*
::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER
**Prereq:**
**Prerequisite:**
- ::PRECONDITION
- ::PRECONDITION
@ -781,14 +802,15 @@ cases first and come back to less important ones later.*
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
**Notes and Questions**
**Notes and Questions:**
- ::NOTE
- ::NOTE
- ::QUESTION
- ::QUESTION
---
### UC-70: USE CASE NAME
**Summary:**
@ -811,7 +833,7 @@ cases first and come back to less important ones later.*
::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER
**Prereq:**
**Prerequisite:**
- ::PRECONDITION
- ::PRECONDITION
@ -831,14 +853,15 @@ cases first and come back to less important ones later.*
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
**Notes and Questions**
**Notes and Questions:**
- ::NOTE
- ::NOTE
- ::QUESTION
- ::QUESTION
---
### UC-71: USE CASE NAME
**Summary:**
@ -861,7 +884,7 @@ cases first and come back to less important ones later.*
::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER
**Prereq:**
**Prerequisite:**
- ::PRECONDITION
- ::PRECONDITION
@ -881,14 +904,15 @@ cases first and come back to less important ones later.*
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
**Notes and Questions**
**Notes and Questions:**
- ::NOTE
- ::NOTE
- ::QUESTION
- ::QUESTION
---
### UC-72: USE CASE NAME
**Summary:**
@ -911,7 +935,7 @@ cases first and come back to less important ones later.*
::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER
**Prereq:**
**Prerequisite:**
- ::PRECONDITION
- ::PRECONDITION
@ -931,14 +955,15 @@ cases first and come back to less important ones later.*
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
**Notes and Questions**
**Notes and Questions:**
- ::NOTE
- ::NOTE
- ::QUESTION
- ::QUESTION
---
### UC-80: USE CASE NAME
**Summary:**
@ -961,7 +986,7 @@ cases first and come back to less important ones later.*
::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER
**Prereq:**
**Prerequisite:**
- ::PRECONDITION
- ::PRECONDITION
@ -981,14 +1006,15 @@ cases first and come back to less important ones later.*
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
**Notes and Questions**
**Notes and Questions:**
- ::NOTE
- ::NOTE
- ::QUESTION
- ::QUESTION
---
### UC-81: USE CASE NAME
**Summary:**
@ -1011,7 +1037,7 @@ cases first and come back to less important ones later.*
::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER
**Prereq:**
**Prerequisite:**
- ::PRECONDITION
- ::PRECONDITION
@ -1031,14 +1057,15 @@ cases first and come back to less important ones later.*
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
**Notes and Questions**
**Notes and Questions:**
- ::NOTE
- ::NOTE
- ::QUESTION
- ::QUESTION
---
### UC-82: USE CASE NAME
**Summary:**
@ -1061,7 +1088,7 @@ cases first and come back to less important ones later.*
::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER
**Prereq:**
**Prerequisite:**
- ::PRECONDITION
- ::PRECONDITION
@ -1081,14 +1108,15 @@ cases first and come back to less important ones later.*
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
**Notes and Questions**
**Notes and Questions:**
- ::NOTE
- ::NOTE
- ::QUESTION
- ::QUESTION
---
### UC-90: USE CASE NAME
**Summary:**
@ -1111,7 +1139,7 @@ cases first and come back to less important ones later.*
::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER
**Prereq:**
**Prerequisite:**
- ::PRECONDITION
- ::PRECONDITION
@ -1131,14 +1159,15 @@ cases first and come back to less important ones later.*
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
**Notes and Questions**
**Notes and Questions:**
- ::NOTE
- ::NOTE
- ::QUESTION
- ::QUESTION
---
### UC-91: USE CASE NAME
**Summary:**
@ -1161,7 +1190,7 @@ cases first and come back to less important ones later.*
::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER
**Prereq:**
**Prerequisite:**
- ::PRECONDITION
- ::PRECONDITION
@ -1181,8 +1210,8 @@ cases first and come back to less important ones later.*
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
**Notes and Questions**
**Notes and Questions:**
- ::NOTE
- ::NOTE
- ::QUESTION

14
User-Guide.md
View File

@ -2,18 +2,22 @@
**product** name and **external** release number, not internal
information.*
##### Product:
##### Product
::[PRODUCT-NAME](http://www.COMPANY.com/products/PRODUCT-NAME/)
##### Release Number:
##### Release Number
::X.Y.Z
##### Release Date:
##### Release Date
::YEAR/MONTH/DAY
##### Customer Support:
##### Customer Support
::For more information or support, please visit our
[website](http://www.COMPANY.com/products/PRODUCT-NAME/) or email
[website](http://www.COMPANY.com/products/PRODUCT-NAME/) or email
us at <support@COMPANY.com>
---

31
User-Needs.md
View File

@ -1,13 +1,17 @@
##### Project
::[PROJECT-NAME](Home)
##### Attached worksheets:
##### Attached worksheets
- User needs > [Interview notes](interview-notes.html)
##### Related Documents
- [Project proposal](Proposal) > [Target audience and benefits](Target-and-Benefits)
- [Software requirements specification](SRS)
- [Glossary](Glossary)
---
**Process impact:** The statement of user needs documents and explains
@ -59,6 +63,7 @@ fun with the least effort. This website must be familiar to players
who have used other sites, but it must also be better.
#### What is the system's physical environment?
:: This system is a web server that will run on a machine in a
co-located data center with 24x7 monitoring, UPS,
air-conditioning, etc. Users of this system are typically at
@ -154,18 +159,23 @@ communication took place via email, link to it in the archive or paste
it here.*
#### ::DATE, INTERVIEWEE
::[interview with INTERVIEWEE](interview-notes.html)
#### ::DATE, INTERVIEWEE
#### ::DATE-1, INTERVIEWEE
::NOTES FROM INTERVIEW...(pasted here)
#### ::DATE, INTERVIEWEE
#### ::DATE-2, INTERVIEWEE
::NOTES FROM INTERVIEW...(pasted here)
#### ::DATE, PARTICIPANTS
#### ::DATE-3, PARTICIPANTS
::NOTES FROM BRAINSTORMING SESSION...(pasted here)
#### ::DATE, PARTICIPANTS
#### ::DATE-4, PARTICIPANTS
::[email from INTERVIEWEE](LINK-TO-ARCHIVE)
### User Stories
@ -179,6 +189,7 @@ assumptions about details of the system, instead focus on the users.
Note the source of each user story.*
#### ::invited-to-join
:: John has gotten pretty good at SuperShooter by playing on public
servers about 8 hours a week for the last 3 weeks. John has chatted
with Bob about strategies and they have enjoyed some duels. Bob is a
@ -187,18 +198,22 @@ private server Friday nights. Bob invites John to visit the RedDawn
website and join. (Source: [INTERVIEWEE](interview-notes.html))
#### finding-the-tournament
:: Bob is visiting his friend. He tries to use his friend's computer to
log onto the RedDawn SuperShooter tournament. But, he does not
remember the exact name of the server. So, he visits the RedDawn
clan website to find that information. (Source: PERSON-NAME)
#### STORYNAME1
#### STORY-NAME-1
:: PARAGRAPH
#### STORYNAME2
#### STORY-NAME-2
:: PARAGRAPH
#### STORYNAME3
#### STORY-NAME-3
:: PARAGRAPH
### Performance and Capacity Needs

44
Workflows.md
View File

@ -1,4 +1,5 @@
### By Activity
1. Project Planning
1. [Home](Home)
2. [Proposal](Proposal)
@ -40,6 +41,7 @@
4. [Software Development Methodology](SDM)
### By Suggested Sequence
1. Step 1
1. [Home](Home)
2. [Proposal](Proposal)
@ -82,24 +84,25 @@
1. [Status Report](Status-Report)
### All Templates
1. [Summary](Summary)
2. [Home](Home)
3. [Proposal](Proposal)
- [Target and Benefits](Target-and-Benefits)
4. [Project Plan](Project-Plan)
- [Resource needs](Resource-Needs)
5. [QA Plan](QA-Plan)
- [Test Suite](Test-Suite)
- [Test Case Format](Test-Case-Format)
- [Test Cases](Test-Cases)
- [Review Meeting Notes](Review-Meeting-Notes)
6. [Legal Issues](Legal)
7. [User Needs](User-Needs)
- [Interview Notes](Interview-Notes)
8. [Software Requirements Specification](SRS)
- [Use Case Suite](Use-Case-Suite)
- [Feature Set](Feature-Set)
9. [Glossary](Glossary)
1. [Summary](Summary)
2. [Home](Home)
3. [Proposal](Proposal)
- [Target and Benefits](Target-and-Benefits)
4. [Project Plan](Project-Plan)
- [Resource needs](Resource-Needs)
5. [QA Plan](QA-Plan)
- [Test Suite](Test-Suite)
- [Test Case Format](Test-Case-Format)
- [Test Cases](Test-Cases)
- [Review Meeting Notes](Review-Meeting-Notes)
6. [Legal Issues](Legal)
7. [User Needs](User-Needs)
- [Interview Notes](Interview-Notes)
8. [Software Requirements Specification](SRS)
- [Use Case Suite](Use-Case-Suite)
- [Feature Set](Feature-Set)
9. [Glossary](Glossary)
10. [Design](Design)
- [Architecture Worksheet](Design-Architecture)
- [Source and Build](Design-Src-Org)
@ -116,8 +119,9 @@
18. [Status Report](Status-Report)
19. [Software Development Methodology](SDM)
### How to download these templates:
### How to download these templates
- [Download template archive](http://readyset.tigris.org/servlets/ProjectDocumentList), or
- Use CVS to [check out](http://readyset.tigris.org/servlets/ProjectSource) project
"readyset" or clone from [ReadySet GFM](https://github.com/bike-bill/readyset-gfm.wiki.git)
on Github.
on Github.