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

Fix markdown lint errors

Browse Source
This commit is contained in:
William Sandner 2023-03-24 17:29:16 +01:00
parent 0d20f4e5b1
commit c504fc26da
50 changed files with 702 additions and 637 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
.vscode/settings.json vendored
View File

@ -1,5 +1,4 @@
{
"markdownlint.config": {
"MD026": { "punctuation": "?" }
}
}
"markdownlint.config": {},
"cSpell.words": ["JDBC"]
}

2
Demo-Script.md
View File

@ -1,4 +1,4 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::[PROJECT-NAME](Home)

14
Design-Architecture.md
View File

@ -1,4 +1,4 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::PROJECT-NAME(Home)
@ -17,8 +17,8 @@
---
*TODO: Answer the questions below to help you define your system
architecture. Some example text is provided.*
_TODO: Answer the questions below to help you define your system
architecture. Some example text is provided._
### Overview
@ -49,7 +49,7 @@ architecture. Some example text is provided.*
#### What are the components of this system?
::The components of this system are clearly defined in this [UML Model
with Component Diagram](LINK-TO-MODEL).
with Component Diagram](LINK-TO-MODEL).
::The components of this system are listed below by type:
@ -152,11 +152,11 @@ and down-time.
### Architectural Scenarios
*TODO: Provide architecture scenarios that show how objects will
_TODO: Provide architecture scenarios that show how objects will
communicate across components, processes, and machines. Focus on
scenarios where the architecture itself is changing, e.g., system
startup, shutdown, adding or upgrading components, load balancing or
fail-over.*
fail-over._
The following sequence diagrams give step-by-step descriptions of how
components communicate during some important usage scenarios:
@ -167,7 +167,7 @@ components communicate during some important usage scenarios:
### Architecture Checklist
*TODO: Evaluate your architecture with respect to each of your goals.*
_TODO: Evaluate your architecture with respect to each of your goals._
#### Ease of integration: Have mechanisms been provided for all needed types of integration?

10
Design-Components.md
View File

@ -1,4 +1,4 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::PROJECT-NAME
@ -15,11 +15,11 @@
---
*TODO: Briefly describe each component in the system. Focus on
_TODO: Briefly describe each component in the system. Focus on
architectural issues such as communication mechanisms, environmental
concerns that affect deployment options, and concurrency. Note key
aspects of each interface, but avoid duplicating details of interfaces
that are specified in the UML class diagrams or other documents.*
that are specified in the UML class diagrams or other documents._
Each interface can be an API (application program interface), standard
protocol (e.g., HTTP), config files, input data file format, or
@ -28,8 +28,8 @@ may have multiple interfaces: e.g., a server may handle requests in a
standard protocol, but also have a config file, command-line options, an
administrative control panel GUI, and a performance monitoring API.
*TIP: Use an HTML anchor for each component so that a direct link can be
made from other documents, issues, and email messages.*
_TIP: Use an HTML anchor for each component so that a direct link can be
made from other documents, issues, and email messages._
---

9
Design-Persistence.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::PROJECT-NAME
@ -17,8 +18,8 @@
### Overview
*TODO: Answer the questions below to help you design needed persistence
features. Some example text is provided. Add or delete text as needed.*
_TODO: Answer the questions below to help you design needed persistence
features. Some example text is provided. Add or delete text as needed._
#### What are the most important facts that a developer should know about persistent data storage in this system?
@ -112,7 +113,7 @@ attachments are written to files on the server hard disk.
```
::Users store files anywhere on their computer, with the filename
extension ```.TST```.
extension `.TST`.
#### What file system access controls will be used?

27
Design-Scalability.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::PROJECT-NAME
@ -17,28 +18,28 @@
### Overview
*TODO: Briefly describe the approach to scalability. Rank your
scalability goals for this design.*
_TODO: Briefly describe the approach to scalability. Rank your
scalability goals for this design._
::2-4 SENTENCES.
### Relevant parameters
| Parameter | Description |
|---------------------|-----------------------------------------------------------------------------------------|
| ::registered\_users | ::Number of registered users in the database. |
| ::concurrent\_users | ::Number of users logged into the system at a given time. |
| ::map\_size | ::Number of game squares in the playing area. E.g., a 10 x 25 map would be 250 squares. |
| ::game\_pieces | ::Number of game pieces on the playing area at a given time. |
| Parameter | Description |
| ------------------ | --------------------------------------------------------------------------------------- |
| ::registered_users | ::Number of registered users in the database. |
| ::concurrent_users | ::Number of users logged into the system at a given time. |
| ::map_size | ::Number of game squares in the playing area. E.g., a 10 x 25 map would be 250 squares. |
| ::game_pieces | ::Number of game pieces on the playing area at a given time. |
### Scalability Mechanisms
### Performance Goals and Estimates
| Action | Goal | Time Formula | Description |
|----------------|--------------|-------------------------------|-----------------------------------------------------------------------------|
| ::login | ::1 second | ::O(Log(registered\_users)) | ::Time that it takes to look up a user by their login name in the database. |
| ::display\_map | ::1/5 second | ::O(map\_size + game\_pieces) | ::Time that it takes to redraw the game map and all game pieces. |
| Action | Goal | Time Formula | Description |
| ------------- | ------------ | --------------------------- | --------------------------------------------------------------------------- |
| ::login | ::1 second | ::O(Log(registered_users)) | ::Time that it takes to look up a user by their login name in the database. |
| ::display_map | ::1/5 second | ::O(map_size + game_pieces) | ::Time that it takes to redraw the game map and all game pieces. |
### System Scalability Checklist

5
Design-Security.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::PROJECT-NAME
@ -17,7 +18,7 @@
### Overview
*TODO: Answer the questions below to help you design needed security features. Some example text is provided. Add or delete text as needed.*
_TODO: Answer the questions below to help you design needed security features. Some example text is provided. Add or delete text as needed._
#### What are the most important facts that a developer should know about the security of this system?

29
Design-Src-Org.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::PROJECT-NAME
@ -19,10 +20,10 @@
### Overview
*TODO: Answer the questions below to help you define your source code
_TODO: Answer the questions below to help you define your source code
organization and build process. Some example text is provided. Add or
delete text as needed. E.g., not all projects try to be platform
independent.*
independent._
#### What are the most important facts that a developer should know about this source code organization and build system?
@ -40,12 +41,12 @@ projects at the Apache Software Foundation.
### Key Directories and Files in Developer Working Copies
*TODO: Describe the purpose of each directory that will appear in a
_TODO: Describe the purpose of each directory that will appear in a
developer's work copy, also include any files that are important to the
overall structure or build process.*
overall structure or build process._
| Path | VC | Description |
|--------------------------------------|-------|---------------------------------------------------------------------------------|
| ------------------------------------ | ----- | ------------------------------------------------------------------------------- |
| ::build.xml | ::Yes | ::Build file |
| ::build.properties | ::Yes | ::Build properties file |
| ::src/ | ::Yes | ::Source code |
@ -68,11 +69,11 @@ overall structure or build process.*
### Build Targets
*TODO: Describe the build targets that developers will use in daily
development. The examples below should fit most projects.*
_TODO: Describe the build targets that developers will use in daily
development. The examples below should fit most projects._
| Target | Description |
|---------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ::compile = default | ::Compiles Java source code and creates .class files under the "build" directory. |
| ::dist | ::Packages the system for distribution/deployment to servers or end users. Specifically, it creates .war archive of compiled classes and configuration files. |
| ::install | ::Places executable code into location where it will actually be executed. Specifically, it copies .war file into Tomcat's webapps directory for use. You must then restart Tomcat or use the "reload" link in the Tomcat Manager. |
@ -81,11 +82,11 @@ development. The examples below should fit most projects.*
### Build Configuration Options
| Property | Description |
|----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| ::app.name | ::The name of this application. This should be one short word. Used in the name of resulting package files. Specifically, the .war file. And, it will be used to access the application via <http://localhost:8080/APP.NAME/> |
| ::app.version | ::Version number of this release. Used in the name of resulting package files. Specifically, the .war file. |
| ::webapps.path | ::Path to the Tomcat "webapps" directory. Defaults to C:\Program Files\Apache Group\Tomcat 4.1\webapps\ |
| Property | Description |
| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ::app.name | ::The name of this application. This should be one short word. Used in the name of resulting package files. Specifically, the .war file. And, it will be used to access the application via <http://localhost:8080/APP.NAME/> |
| ::app.version | ::Version number of this release. Used in the name of resulting package files. Specifically, the .war file. |
| ::webapps.path | ::Path to the Tomcat "webapps" directory. Defaults to C:\Program Files\Apache Group\Tomcat 4.1\webapps\ |
::These build system properties can be modified by editing the
build.properties file.

83
Design-UI.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::PROJECT-NAME
@ -17,9 +18,9 @@
### Overview
*TODO: Answer the questions below to help you design the user interface
_TODO: Answer the questions below to help you design the user interface
features of your system. Some example text is provided. Add or delete
text as needed.*
text as needed._
#### What are the most important facts that a developer should know about the user interface of this system?
@ -65,60 +66,60 @@ text as needed.*
### Content Model / Interaction Contexts
*TODO: List interaction contexts. Each interaction context is a "place"
_TODO: List interaction contexts. Each interaction context is a "place"
where users see information and where they select commands or options.
In a graphical user interface, a interaction context will eventually be
implemented as a window or dialog box. In other applications, an
interaction context may be implemented as, e.g., a web page, a voice
menu prompt, or a physical control panel.*
menu prompt, or a physical control panel._
*TIP: Each interaction context is an exclusive mode: the user can only
_TIP: Each interaction context is an exclusive mode: the user can only
use one interaction context at a time. All the components within one
context are visible and usable at the same time. E.g., if a window has
three tabs, that is three interaction contexts because only one tab can
be used at a time.*
be used at a time._
*TODO: For each interaction context, list the abstract components within
_TODO: For each interaction context, list the abstract components within
that context. Each component is a piece of information, or a user
interface affordance. In a GUI, each abstract component will eventually
become a widget, but the choice of specific widgets happens later.
Choice of abstract components corresponds to step 2 in the
[HTML prototyping example](http://www.ics.uci.edu/~jrobbins/htmlproto/index.html)
demonstrated in class.*
demonstrated in class._
*TIP: Most high frequency use cases should be carried out in only one
_TIP: Most high frequency use cases should be carried out in only one
interaction contexts. A use case that requires three interaction
contexts could be hard to use. However, interaction contexts with too
many components can also be hard to use.*
many components can also be hard to use._
| Interaction Context --Abstract UI Components | Purpose | Contents / Constraints / Behavior |
|------------------------------------------------|------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| ::[Login dialog](LINK-TO-MOCKUP) | ::Verify that the current user is actually the person that they claim to be. | |
| ::--Prompt | ::Tell the user that this dialog is to log in. | ::"Please log in". |
| ::--Message area | ::Give the user some feedback about the login process. | ::Initially blank. Changes to "Checking username and password" when the user presses "Login". Changes to "Invalid username or password, please try again", if login fails. |
| ::--Username | ::Identify the user account that the current user is trying to access. | ::The name of the user account. Regex: [-_a-z0-9]{1-16}. The application should not do anything that would help users guess usernames. E.g., this should not be a combo-box with recent users listed, and it should not offer auto-complete. |
| ::--Password | ::Verify that the current user knows a secret password that only the true user of that user account should know. | ::The password of 4-16 characters. Do not display the password on the screen. The application should not do anything that would help users guess passwords. |
| ::--Login | ::Allow the user to indicate that they have completed entry of their username and password. | ::"Login" Only enabled when Username != "". If the username or password is incorrect, delay a few seconds, and then clear all fields. |
| ::--Lost Password | ::Allow the current user to start a process of generating a new password for a given username. | ::"Forgot your password? Click here." Only enabled when Username != "". |
| ::[PAGE-NAME](LINK-TO-MOCKUP) | ::PURPOSE | |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::[PAGE-NAME](LINK-TO-MOCKUP) | ::PURPOSE | |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::[MAIN-WINDOW-NAME](LINK-TO-MOCKUP) | ::PURPOSE | |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::[DIALOG-NAME](LINK-TO-MOCKUP) | ::PURPOSE | |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::[DIALOG-NAME](LINK-TO-MOCKUP) | ::PURPOSE | |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| Interaction Context --Abstract UI Components | Purpose | Contents / Constraints / Behavior |
| -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ::[Login dialog](LINK-TO-MOCKUP) | ::Verify that the current user is actually the person that they claim to be. | |
| ::--Prompt | ::Tell the user that this dialog is to log in. | ::"Please log in". |
| ::--Message area | ::Give the user some feedback about the login process. | ::Initially blank. Changes to "Checking username and password" when the user presses "Login". Changes to "Invalid username or password, please try again", if login fails. |
| ::--Username | ::Identify the user account that the current user is trying to access. | ::The name of the user account. Regex: [-_a-z0-9]{1-16}. The application should not do anything that would help users guess usernames. E.g., this should not be a combo-box with recent users listed, and it should not offer auto-complete. |
| ::--Password | ::Verify that the current user knows a secret password that only the true user of that user account should know. | ::The password of 4-16 characters. Do not display the password on the screen. The application should not do anything that would help users guess passwords. |
| ::--Login | ::Allow the user to indicate that they have completed entry of their username and password. | ::"Login" Only enabled when Username != "". If the username or password is incorrect, delay a few seconds, and then clear all fields. |
| ::--Lost Password | ::Allow the current user to start a process of generating a new password for a given username. | ::"Forgot your password? Click here." Only enabled when Username != "". |
| ::[PAGE-NAME](LINK-TO-MOCKUP) | ::PURPOSE | |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::[PAGE-NAME](LINK-TO-MOCKUP) | ::PURPOSE | |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::[MAIN-WINDOW-NAME](LINK-TO-MOCKUP) | ::PURPOSE | |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::[DIALOG-NAME](LINK-TO-MOCKUP) | ::PURPOSE | |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::[DIALOG-NAME](LINK-TO-MOCKUP) | ::PURPOSE | |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
### Technical Constraints / Operational Context
@ -156,8 +157,8 @@ four menu buttons along the right-hand edge of the screen.
### User Interface Checklist
*TODO: Answer the following questions to help evaluate the design. You
may add or remove questions to fit your project.*
_TODO: Answer the following questions to help evaluate the design. You
may add or remove questions to fit your project._
#### Understandability and learnability

18
Design.md
View File

@ -1,5 +1,5 @@
<!-- markdownlint-disable-next-line first-line-h1 -->
<!-- markdownlint-disable-next-line MD041 -->
##### Project
::[PROJECT-NAME](Home)
@ -31,7 +31,7 @@
This design document describes a system that will satisfy the requirements of the [SRS](SRS). Decisions made in creating this design document are based on those requirements and an understanding of available technologies and components. Once the design has been drafted, work on the system implementation and unit testing may begin.
*TODO: Fill in the sections below. Add ore remove items as needed for your project.*
_TODO: Fill in the sections below. Add ore remove items as needed for your project._
### Introduction
@ -59,8 +59,8 @@ interface and database design.
### UML Structural Design
*TODO: Link to a design model and/or design diagrams that describe your
system's structure in detail.*
_TODO: Link to a design model and/or design diagrams that describe your
system's structure in detail._
#### The system's structural design is described in the following UML model
@ -81,8 +81,8 @@ system's structure in detail.*
### UML Behavioral Design
*TODO: Link to a design model and/or design diagrams that describe your
system's behavior in detail.*
_TODO: Link to a design model and/or design diagrams that describe your
system's behavior in detail._
#### The system's behavioral design is described in the following UML model
@ -107,10 +107,10 @@ system's behavior in detail.*
### UML Design Checklist
*TODO: Answer the following questions to help evaluate your design. Add
_TODO: Answer the following questions to help evaluate your design. Add
or remove questions to fit your project. If you cannot answer a question
positively, that may indicate an aspect of the design that should be
revised.*
revised._
#### Correctness: How do you know that this design is correct?
@ -148,4 +148,4 @@ revised.*
- ::Yes, everyone understands. Feedback is welcome.
- ::No, this is a risk that is noted in the
[Risk Management](Project-Plan#Risk-Management) section.
[Risk Management](Project-Plan#Risk-Management) section.

31
Document-Cross-Ref.md
View File

@ -1,21 +1,22 @@
<!-- markdownlint-disable-next-line MD041 -->
*TODO: This template is not done yet. Feel free to contribute your ideas.*
<!-- markdownlint-disable-next-line first-line-h1 -->
_TODO: This template is not done yet. Feel free to contribute your ideas._
This document defines the artifacts the team creates during your software
development process. Documenting artifact types helps define the inputs and
outputs of each development task. The producer/consumer matrix helps document
development process. Documenting artifact types helps define the inputs and
outputs of each development task. The producer/consumer matrix helps document
the software development workflow.
### Artifact Producer / Consumer Matrix
| Read By \ Written By | Everyone | Project Manager | Product Manager | Dev Team | QA Team | Tech Writer | Tech Support | Operations | Sales |
|----------------------|----------------------------------------------------|--------------------------------------------------------------------------|------------------------------------------------------|------------------------------------------------------------------------------------------|--------------------------------------------------------------|---------------------------------------------------------------|----------------|-------------------------|----------------------------|
| Everyone | [Release-Checklist](Release-Checklist), [SDM](SDM) | [Overview](Overview), [Proposal](Proposal), [Plan](Plan), [Risks](Risks) | [SRS](SRS) | Mockups, Prototyes, Working-product | | [User-Guide](User-Guide), [Release-Notes](Release-Notes) | | | |
| Project Manager | [Status-Report](Status-Report) | [Resource-Needs](Resource-Needs) | | [Review-Report](Review-Report) | [QA-Plan](QA-Plan), [Test-Runs](Test-Runs), Defect-reports | | Support-issues | | Customer-feedback |
| Product Manager | | | [User-Needs](User-Needs) | | | | Support-issues | | Customer-feedback |
| Dev Team | | Task-assignments | | [Design](Design) | [QA-Plan](QA-Plan), [Test-Runs](Test-Runs), Defect-reports | | | | |
| QA Team | | Task-assignments | | [Design](Design), [Status-Report](Status-Report) | [QA-Plan](QA-Plan), [Test-Suite](Test-Suite), Defect-reports | [FAQ](FAQ), [Install](Install) | Support-issues | | |
| Tech Writer | | Task-assignments | [User-Needs](User-Needs) | [Design-UI](Design-UI) | | | Support-issues | | Customer-feedback |
| Tech Support | | | | [Design-UI](Design-UI) | | | Support-issues | | Customer-feedback |
| Operations | | | [User-Needs](User-Needs) | [Design-Architecture](Design-Architecture), [Implementation-Notes](Implementation-Notes) | | [Install](Install) | | | |
| Sales | | | [User-Needs](User-Needs), [Demo-Script](Demo-Script) | [Implementation-Notes](Implementation-Notes) | | [Install](Install) | | | [Demo-Script](Demo-Script) |
| Read By \ Written By | Everyone | Project Manager | Product Manager | Dev Team | QA Team | Tech Writer | Tech Support | Operations | Sales |
| -------------------- | -------------------------------------------------- | ------------------------------------------------------------------------ | ---------------------------------------------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------ | -------------------------------------------------------- | -------------- | ---------- | -------------------------- |
| Everyone | [Release-Checklist](Release-Checklist), [SDM](SDM) | [Overview](Overview), [Proposal](Proposal), [Plan](Plan), [Risks](Risks) | [SRS](SRS) | Mockups, Prototyes, Working-product | | [User-Guide](User-Guide), [Release-Notes](Release-Notes) | | | |
| Project Manager | [Status-Report](Status-Report) | [Resource-Needs](Resource-Needs) | | [Review-Report](Review-Report) | [QA-Plan](QA-Plan), [Test-Runs](Test-Runs), Defect-reports | | Support-issues | | Customer-feedback |
| Product Manager | | | [User-Needs](User-Needs) | | | | Support-issues | | Customer-feedback |
| Dev Team | | Task-assignments | | [Design](Design) | [QA-Plan](QA-Plan), [Test-Runs](Test-Runs), Defect-reports | | | | |
| QA Team | | Task-assignments | | [Design](Design), [Status-Report](Status-Report) | [QA-Plan](QA-Plan), [Test-Suite](Test-Suite), Defect-reports | [FAQ](FAQ), [Install](Install) | Support-issues | | |
| Tech Writer | | Task-assignments | [User-Needs](User-Needs) | [Design-UI](Design-UI) | | | Support-issues | | Customer-feedback |
| Tech Support | | | | [Design-UI](Design-UI) | | | Support-issues | | Customer-feedback |
| Operations | | | [User-Needs](User-Needs) | [Design-Architecture](Design-Architecture), [Implementation-Notes](Implementation-Notes) | | [Install](Install) | | | |
| Sales | | | [User-Needs](User-Needs), [Demo-Script](Demo-Script) | [Implementation-Notes](Implementation-Notes) | | [Install](Install) | | | [Demo-Script](Demo-Script) |

13
FAQ.md
View File

@ -1,11 +1,12 @@
<!-- markdownlint-disable-next-line MD041 -->
*TODO: Answer these common questions. Some sample answers are provided
for you. Add new questions and new sections to fit the needs of your
users.*
<!-- markdownlint-disable-next-line first-line-h1 -->
*TIP: This FAQ is for end users, you may want to write FAQ's for other
_TODO: Answer these common questions. Some sample answers are provided
for you. Add new questions and new sections to fit the needs of your
users._
_TIP: This FAQ is for end users, you may want to write FAQ's for other
types of stakeholders such as potential customers, open source
contributors, members of a developers' network, or administrators.*
contributors, members of a developers' network, or administrators._
### General Information

9
Feature-Format.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::[PROJECT-NAME](Home)
@ -19,8 +20,8 @@ feature specification template into your [Features](Features)
document. This file itself should not be edited to hold specific
features.
*TODO: Copy and paste this feature specification template as many times
as needed in your [Features](Features) document.*
_TODO: Copy and paste this feature specification template as many times
as needed in your [Features](Features) document._
---
@ -42,7 +43,7 @@ Description:
Precise Details:
- ::LOGICAL CONSTRAINT
- ::LOGICAL CONSTRAINT
- ::LOGICAL CONSTRAINT
Notes and Questions:

15
Feature-Set.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::PROJECT-NAME
@ -25,24 +26,24 @@ feature set by priority, functional area, actor, business object, or
release can help identify missing, extra, or poorly motivated features
early.
*TODO: Before writing individual feature descriptions, list all the
_TODO: Before writing individual feature descriptions, list all the
features that you think you will need. Organize them so that missing
features appear as blanks on this page, and extra features will appear
to be extras that don't fit anywhere. See the
[feature format](Feature-Format#further-information) document for more
tips on specifying features and feature sets.*
tips on specifying features and feature sets._
*TIP: Refer back to the user stories in your [user needs](User-Needs)
_TIP: Refer back to the user stories in your [user needs](User-Needs)
document and to the [use case suite](Use-Case-Suite).
Use them for ideas and make sure that you cover all of them.*
Use them for ideas and make sure that you cover all of them._
### Features by Release and Priority
*TODO: Select subset of features can be implemented for a given release.
_TODO: Select subset of features can be implemented for a given release.
When features are listed in priority order, choosing the features to
implement in a release simply becomes a matter of "drawing a line":
features below the line must wait for a later release. Make sure to also
consider estimated effort and risk.*
consider estimated effort and risk._
- ::Release 1.0
- ::Essential

26
Features.md
View File

@ -1,4 +1,4 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::PROJECT-NAME
@ -20,23 +20,23 @@
**Process impact:** This is a set of detailed feature descriptions.
*TODO: For each feature listed in the [feature set](Feature-Set),
_TODO: For each feature listed in the [feature set](Feature-Set),
give a detailed description of the feature here. Describe each feature
in enough detail that it could be implemented by any member of the
development team (not only someone who already informally knows what to
do).*
do)._
*TIP: Start with a short textual description of each feature. Then, add
_TIP: Start with a short textual description of each feature. Then, add
more formal information as needed to make each description precise and
unambiguous. E.g.,*
unambiguous. E.g.,_
- *Precisely define valid inputs, and error handling*
- *Specify data structures with UML or logical schema*
- *Specify UI aspects of features with tiny mock-ups*
- *Specify key decisions with decision trees or tables*
- *Specify key algorithms with pseudo-code or flow charts*
- *Specify state-based behavior with state machines or tables*
- *Specify sequences of events with scenario diagrams*
- _Precisely define valid inputs, and error handling_
- _Specify data structures with UML or logical schema_
- _Specify UI aspects of features with tiny mock-ups_
- _Specify key decisions with decision trees or tables_
- _Specify key algorithms with pseudo-code or flow charts_
- _Specify state-based behavior with state machines or tables_
- _Specify sequences of events with scenario diagrams_
---
@ -116,7 +116,7 @@ Functional area(s): ::WORD, WORD, WORD
Use case(s): ::[UC-01](Use-Cases#UC-01)
Description:
:: 1-4 PARAGRAPHS. USE BULLETS OR TABLES TO ORGANIZE INFORMATION. LINK TO WORKSHEETS OR ADDITIONAL INFORMATION.
:: 1-4 PARAGRAPHS. USE BULLETS OR TABLES TO ORGANIZE INFORMATION. LINK TO WORKSHEETS OR ADDITIONAL INFORMATION.
Precise Details:

31
Glossary-Standard-Terms.md
View File

@ -1,4 +1,4 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
**Process impact:** This file as a dictionary of standard terms defined
as they are used across projects. Individual projects should not need to
edit this file. Writing out the definitions of terms and acronyms here
@ -6,11 +6,12 @@ helps keep other documents more concise and easy to edit. Check the
[ReadySET glossary](http://readyset.tigris.org/templates/glossary-std.html) for
updates.
<!-- markdownlint-disable-next-line link-fragments -->
Jump to: [General](#general-terms) | [Computer science & technology](#computer-science-and-technology-terms) | [Process](#process-terms) | [Software development tools](#development-tool-terms) | [Requirements](#requirements-terms) | [Design](#design-terms) | [Design goals terms](#desigD-DIAGRAMn-goals-terms) | [QA terms](#qa-terms) | [QA goals terms](#qa-goals-terms) | [Additional terms](#additional-standard-terms)| [Project terms](Glossary)
### General Terms
##### Chipping away
#### Chipping away
The process of removing sample text from templates when that text
does not apply to the current project. Often some of the sample text
@ -82,9 +83,9 @@ communications such as [SOAP](#soap) messages.
##### ::SOAP
SOAP (Simple Object Access Protocol) is the message format used by
standard web services. It entails sending an XML document to a
server in order to invoke an operation on the server-side.
SOAP (Simple Object Access Protocol) is the message format used by
standard web services. It entails sending an XML document to a
server in order to invoke an operation on the server-side.
[More information on SOAP](http://directory.google.com/Top/Computers/Programming/Internet/Web_Services/SOAP/?tc=1).
### Process Terms
@ -138,7 +139,7 @@ than "10.1" or "11".
##### Release Number
The term "release number" by itself refers to an
The term "release number" by itself refers to an
[external release number](#external_release_number). Users normally are not aware
of the existence of any internal release numbers.
@ -191,7 +192,7 @@ many different ways as part of many different use cases.
The main part of a use case is a set of steps that give an example
of how an [actor](#actor) can use the product to succeed at
a goal. These steps are called the "Main success scenario", and they
a goal. These steps are called the "Main success scenario", and they
include both user intentions and system responses. One use case may
show how the actor uses several features to accomplish a goal.
@ -225,7 +226,7 @@ Developers can understand this design and correctly implement it.
This design divides the implementation into components or aspects
that can correspond to reasonable implementation tasks.
#### Modularity
#### Modularity
Concerns are clearly separated so that the impact of most design
changes would be limited to only one or a few modules.
@ -323,18 +324,18 @@ this system.
#### Bug
*n.* **Deprecated** since 1991. See [defect](#defect).
_n._ **Deprecated** since 1991. See [defect](#defect).
#### Error
*v.* A mistaken thought in the developer's mind. Often caused by
_v._ A mistaken thought in the developer's mind. Often caused by
miscommunication or bad assumptions. Errors can create
[defects](#defect). E.g., a developer might erroneously think that
the square root of -4 is -2.
#### Defect
*n.* The result of the developer's [error](#error) embodied in the
_n._ The result of the developer's [error](#error) embodied in the
product source code, initial data, or documents. E.g., a square root
function which allows negative numbers as arguments is defective.
Defects can be removed by changing the source code, initial data,
@ -342,7 +343,7 @@ or document.
#### Fault
*n.* The execution of defective code. E.g., if a certain input is
_n._ The execution of defective code. E.g., if a certain input is
provided to defective code, it may cause an exception, or go into an
infinite loop, or store an incorrect value in an internal variable.
A fault is not normally visible to users, only the
@ -350,7 +351,7 @@ A fault is not normally visible to users, only the
#### Failure
*n.* The user-visible result of a [fault](#fault). E.g., an error
_n._ The user-visible result of a [fault](#fault). E.g., an error
message or an incorrect result. This is evidence that can be
reported in a defect report. Developers use failure evidence during
debugging to eventually find and remove [defects](#defect).
@ -391,6 +392,7 @@ D-DIAGRAM
D-DIAGRAM
D-DIAGRAM
D-DIAGRAM
#### Usability > Understandability and Readability
Users need to understand the system to use it. The basic metaphor
@ -447,6 +449,7 @@ D-DIAGRAM
in his/her task.
#### Usability > Subjective satisfactionD-DIAGRAM
D-DIAGRAM
D-DIAGRAM
D-DIAGRAM
@ -464,10 +467,12 @@ input should be validated and any malicious input should
be rejected.
#### Reliability > Consistency under load
D-DIAGRAM
D-DIAGRAM
D-DIAGRAM
D-DIAGRAM
#### Reliability > Consistency under concurrency
Systems that allow concurrent access by multiple users, or that use

45
Glossary.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
**Process impact:** This file as a dictionary of terms defined as they
are used during the project. Writing out the definitions of terms and
acronyms here helps keep other documents more concise and precise. A
@ -13,25 +14,25 @@ Jump to: [A](#a) | [B](#b) | [C](#c) | [D](#d) | [E](#e) | [F](#f) |
### Project-specific Terms
*TIPs:*
_TIPs:_
- *Define HTML anchors on your terms with id="TERMNAME" so that other
documents can link to the definition of specific terms.*
- *If there is any question about the meaning of a term, note it here.
- _Define HTML anchors on your terms with id="TERMNAME" so that other
documents can link to the definition of specific terms._
- _If there is any question about the meaning of a term, note it here.
If someone (e.g., the customer) gave you a definition to use, note
that here too. If something is best defined by using a hyperlink to
another document or website, include a hyperlink in the definition.*
- *If a term was used in the past, but is no longer going to be used,
another document or website, include a hyperlink in the definition._
- _If a term was used in the past, but is no longer going to be used,
you should keep it in the list, mark it as "deprecated", and link to
the term or terms that replace it. E.g., deprecated standard term
[bug](glossary-std.html#bug).*
- *Define only project-specific terms, or ones that a new team member
[bug](glossary-std.html#bug)._
- _Define only project-specific terms, or ones that a new team member
would not know. Don't define standard textbook terms that can be
easily found elsewhere.*
- *This glossary can serve as simple domain model or data dictionary.
easily found elsewhere._
- _This glossary can serve as simple domain model or data dictionary.
You can define important data objects by describing their meaning
and key attributes. For example, see [student](#student) and
[GPA](#gpa).*
[GPA](#gpa)._
#### A
@ -47,7 +48,7 @@ Jump to: [A](#a) | [B](#b) | [C](#c) | [D](#d) | [E](#e) | [F](#f) |
- ::Real-world meaning of values:
| | |
|-------------|---------------------------------|
| ----------- | ------------------------------- |
| ::Freshman | ::Less than 90 units |
| ::Sophomore | ::Between 90 and 180 units |
| ::Junior | ::Between 180 and 270 units |
@ -59,12 +60,12 @@ Jump to: [A](#a) | [B](#b) | [C](#c) | [D](#d) | [E](#e) | [F](#f) |
##### ::GEF
::*n.* The [Graph Editing Framework](http://gef.tigris.org/). An open
::_n._ The [Graph Editing Framework](http://gef.tigris.org/). An open
source library for editing diagrams (boxes and arrows).
##### ::GPA
::*n.* Grade Point Average. GPA is a float between 0.00 and 4.00,
::_n._ Grade Point Average. GPA is a float between 0.00 and 4.00,
accurate to 2 decimal places. Computed from average of completed
course grades in transcript weighted by course units. Used to
determine student ranking, and to trigger Dean's List and
@ -74,22 +75,22 @@ academic probation.
##### ::ICS
::*n.* Acronym for the [School of Information and Computer
::_n._ Acronym for the [School of Information and Computer
Science](http://www.ics.uci.edu/) at [UC Irvine](http://www.uci.edu/).
#### S
##### ::Student
::*n.* A person who attends a school to earn a degree. Persistent
attributes include: student\_id\_number (primary key), GPA, major,
and years\_at\_school.
::_n._ A person who attends a school to earn a degree. Persistent
attributes include: student_id_number (primary key), GPA, major,
and years_at_school.
##### ::Senior
::*n.* A senior is special type of [undergraduate](#undergraduate) who
::_n._ A senior is special type of [undergraduate](#undergraduate) who
has a certain number of course credits on his or her transcript.
Years\_at\_school does not determine senior standing. TODO: how many
Years_at_school does not determine senior standing. TODO: how many
credits needed?
#### T
@ -111,4 +112,4 @@ credits needed?
##### ::Undergraduate
::A type of [student](#student). *TODO: add more detail.*
::A type of [student](#student). _TODO: add more detail._

34
Home.md
View File

@ -1,10 +1,12 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
## Project Overview
### Mission and Scope
<!-- markdownlint-disable-next-line MD036 -->
*TODO: Answer these questions in your own words by filling in each*
<!-- markdownlint-disable-next-line no-emphasis-as-header -->
_TODO: Answer these questions in your own words by filling in each_
#### What problem does this project address?
@ -28,9 +30,9 @@
### Status
*TODO: Briefly describe the status of this project. E.g., what phase are
_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.*
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
@ -41,8 +43,8 @@ functionality and a wider set of testers.
### Project Documents
|By Activity |Documents |
|---------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| By Activity | Documents |
| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Inception: | [Home](Home), [Project Proposal](Proposal), [Target Audience and Benefits](Target-and-Benefits), [Statement of User Needs](User-Needs) |
| Reference: | [Glossary](Glossary), [Software Development Methodology](SDM), [Document Cross Reference](Document-Cross-Ref), [All-in-one project summary](Summary) |
| Elaboration: | [Project Plan](Project-Plan), [Software Requirements Specification](SRS), [Feature Set](Feature-Set), [Use Case Suite](Use-Case-Suite), [Design](Design), [QA Plan](QA-Plan), [Test Suite](Test-Suite) |
@ -50,12 +52,12 @@ functionality and a wider set of testers.
| Transition: | [Install / Quick Start](Installation-Guide), [Demo Script](Demo-Script), [Release notes](Release-Notes), [Release checklist](Release-Checklist), [Post Mortem](Post-Mortem) |
| Continuous: | [Status Report](Status-Report) |
|By Audience |Documents |
|---------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| For Everyone: | [Home](Home), [Project Proposal](Proposal), [Target Audience and Benefits](Target-and-Benefits), [Statement of User Needs](User-Needs), [Software Requirements Specification](SRS), [Project Plan](Project-plan), [Release Checklist](Release-Checklist), [Glossary](Glossary) |
| For Management: | [Project Resource Needs](Resource-Needs), [Status Report](Status-Report) |
| For Developers: | [Design](Design), [Review Meeting Notes](Review-Meeting-Notes), [Software Development Methodology](SDM) |
| For QA: | [QA Plan](QA-Plan) |
| For End Users: | [Install / Quick start](Installation-Guide), [User Guide](User-Guide), [Release Notes](Release-Notes) |
| For Support and Ops:| [Implementation Notes](Implementation-Notes), [FAQ / Troubleshooting Guide](FAQ) |
| For Sales/Legal: | [Demo Script](Demo-Script), [Legal Issues](Legal) |
| By Audience | Documents |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| For Everyone: | [Home](Home), [Project Proposal](Proposal), [Target Audience and Benefits](Target-and-Benefits), [Statement of User Needs](User-Needs), [Software Requirements Specification](SRS), [Project Plan](Project-plan), [Release Checklist](Release-Checklist), [Glossary](Glossary) |
| For Management: | [Project Resource Needs](Resource-Needs), [Status Report](Status-Report) |
| For Developers: | [Design](Design), [Review Meeting Notes](Review-Meeting-Notes), [Software Development Methodology](SDM) |
| For QA: | [QA Plan](QA-Plan) |
| For End Users: | [Install / Quick start](Installation-Guide), [User Guide](User-Guide), [Release Notes](Release-Notes) |
| For Support and Ops: | [Implementation Notes](Implementation-Notes), [FAQ / Troubleshooting Guide](FAQ) |
| For Sales/Legal: | [Demo Script](Demo-Script), [Legal Issues](Legal) |

29
Implementation-Notes.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::[PROJECT-NAME](Home)
@ -30,9 +31,9 @@ guide".
### Type of Implementation
*TODO: Fill in information that will help other engineers understand this
_TODO: Fill in information that will help other engineers understand this
system at-a-glance. Feel free to use relevant technical terms and name
specific technology platforms.*
specific technology platforms._
#### Type of system
@ -75,8 +76,8 @@ specific technology platforms.*
### Runtime Environment
*TODO: List and describe runtime objects that make up a running system.
These objects may be referred to by name in the sections below.*
_TODO: List and describe runtime objects that make up a running system.
These objects may be referred to by name in the sections below._
#### Processes
@ -99,7 +100,7 @@ These objects may be referred to by name in the sections below.*
#### Data Files
- ::*.ext: Data files saved by the user on their local hard disk.
- ::\*.ext: Data files saved by the user on their local hard disk.
- ::/var/PRODUCT-NAME/upload-XXXX.dat: Files uploaded to the server.
#### Temporary Files
@ -115,11 +116,11 @@ These objects may be referred to by name in the sections below.*
### Implementation of Specific Features
*TODO: Write short descriptions of interesting or unexpected algorithms,
_TODO: Write short descriptions of interesting or unexpected algorithms,
limiting assumptions, or any other implementation detail that will
impact the work of other groups. E.g., long-running operations that must
not be interrupted. E.g., start up or shutdown scripts that are
automatically run by the operating system.*
automatically run by the operating system._
- ::Feature name: 1-3 SENTENCE DESCRIPTION
- ::Feature name: 1-3 SENTENCE DESCRIPTION
@ -134,8 +135,8 @@ automatically run by the operating system.*
### Operational Procedures
*TODO: Briefly describe procedures that should be followed by operations
engineers when the system is being run in an ASP production environment.*
_TODO: Briefly describe procedures that should be followed by operations
engineers when the system is being run in an ASP production environment._
#### Install
@ -173,8 +174,8 @@ engineers when the system is being run in an ASP production environment.*
### Security
*TODO: Write notes on security to help operations engineers keep the
system secure while it is in operation.*
_TODO: Write notes on security to help operations engineers keep the
system secure while it is in operation._
We take the following precautions to make the system secure
@ -190,8 +191,8 @@ The security of the system depends on the following external factors
### Performance and Scalability
*TODO: Write notes on performance and scalability to help operations
engineers operate the system efficiently.*
_TODO: Write notes on performance and scalability to help operations
engineers operate the system efficiently._
::NOTES ON PERFORMANCE.

19
Installation-Guide.md
View File

@ -1,7 +1,8 @@
<!-- markdownlint-disable-next-line MD041 -->
*TODO: Fill in information about this product. Make sure to use the
<!-- markdownlint-disable-next-line first-line-h1 -->
_TODO: Fill in information about this product. Make sure to use the
**product** name and **external** release number, not internal
information.*
information._
##### Product
@ -34,12 +35,12 @@ PRODUCT-NAME.
### Installation
*TODO: Give detailed installation instructions. Make sure to test these
instructions by doing them yourself on a target machine.*
_TODO: Give detailed installation instructions. Make sure to test these
instructions by doing them yourself on a target machine._
*TIP: For development releases, or products that are reusable components
_TIP: For development releases, or products that are reusable components
rather than end-user applications, you should include information on
needed development and bugging tools, e.g., Ant and JUnit.*
needed development and bugging tools, e.g., Ant and JUnit._
#### What other software must be installed first?
@ -75,9 +76,9 @@ packages:
### Getting Started
*TODO: Briefly describe how the user would accomplish one or two of the
_TODO: Briefly describe how the user would accomplish one or two of the
main use cases for new users. For development releases or reusable
components, include instructions on running unit tests.*
components, include instructions on running unit tests._
#### How can I run post-install unit tests?

3
Interview-Checklist.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Related Documents
- [User Needs](User-Needs)

19
Interview-Notes.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::[PROJECT-NAME](Home)
@ -27,9 +28,9 @@
---
*TODO: Copy this file once for each interview. Fill in the details. Link
_TODO: Copy this file once for each interview. Fill in the details. Link
to this file from the "Notes from Interviews and Brainstorming" section
of user-needs.md.*
of user-needs.md._
**Process impact:** Planning questions for interviews with stakeholders
is key to effective requirements gathering. Good requirements are needed
@ -39,9 +40,9 @@ documentation on [user needs](User-Needs) are referred to when the
### Interview Questions and Answers
*TODO: Before the interview, plan the questions you will ask. Afterwords,
_TODO: Before the interview, plan the questions you will ask. Afterwords,
type up the answers you received and any additional questions and
answers, and any new follow-up questions.*
answers, and any new follow-up questions._
#### ::How did you learn about the need for this product?
@ -77,8 +78,8 @@ answers, and any new follow-up questions.*
### New Questions and Action Items
*TODO: Often early interviews will raise more questions than they answer.
Note these new questions and what you must do to find the answer.*
_TODO: Often early interviews will raise more questions than they answer.
Note these new questions and what you must do to find the answer._
- ::Can we do X?
- ::Do we support Y?
@ -88,11 +89,11 @@ Note these new questions and what you must do to find the answer.*
### Other Interview Notes
*TODO: Note anything else that came out of the interview, either
_TODO: Note anything else that came out of the interview, either
explicitly or implicitly. Remember to confirm things that you picked up
implicitly if there is any doubt. E.g., make a note if the interviewee
uses an unusual meaning for a certain term. Add links to any documents
provided to you by the interviewee.*
provided to you by the interviewee._
- ::NOTE
- ::NOTE

15
Legal.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::[PROJECT-NAME](Home)
@ -30,14 +31,14 @@
this release. Failure to carefully consider these issues may put the
development organization at risk for legal action.
*TODO: Fill in the information above and below. Add or remove rows as
_TODO: Fill in the information above and below. Add or remove rows as
needed. Use the worksheet to help identify legal issues. Seek
professional counsel for review as needed.*
professional counsel for review as needed._
### Ownership of Intellectual Property
| Component | Owner | License | Status | Comments |
|----------------------------|--------------|----------------------|-----------------------------------------------|----------------------------------------------------------------|
| -------------------------- | ------------ | -------------------- | --------------------------------------------- | -------------------------------------------------------------- |
| ::Product name | ::Us | ::Trademark | ::Registration pending | ::We must use "(TM)", not "(R)" |
| ::Database | ::VENDOR | ::Commercial license | ::In compliance, paid normal fee | ::Limits us to 2 CPUs/server |
| ::Encryption library | ::VENDOR | ::Commercial license | ::In compliance, signed partnership agreement | |
@ -51,7 +52,7 @@ professional counsel for review as needed.*
### Regulatory Compliance
| Type | Regulation | Status | Comments |
|--------------------------|---------------------------------------------------|-----------------|-----------------------------------------------------------|
| ------------------------ | ------------------------------------------------- | --------------- | --------------------------------------------------------- |
| ::Export | ::Strong encryption exports must be declared | ::In compliance | ::We will not distribute out of country |
| ::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 |
@ -68,9 +69,9 @@ The goal of this checklist is to help expose legal issues that might
otherwise be missed. It does not help with the actual management of
legal issues.
*TODO: Answer the questions below. If multiple sample answers are
_TODO: Answer the questions below. If multiple sample answers are
provided, delete the ones that do not apply. Edit any provided answers
as needed.*
as needed._
#### Does the development organization hold trademarks on the product name and any other names used in marketing the product?

9
License.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
Do not modify or delete this file. This file describes the license under
which you may use the ReadySET templates.
@ -33,8 +34,8 @@ POSSIBILITY OF SUCH DAMAGE.
Yes, absolutely. Once you fill in the template with detailed
information about a specific project, you are free to do what you
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
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?
@ -47,7 +48,7 @@ copyright statement clearly visible in each file.
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
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/),
is already in development

123
Project-Plan.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::[PROJECT-NAME](Home)
@ -24,8 +25,8 @@ project. Key assumptions that affect the plan should be documented here.
The project plan should be updated throughout the life-time of the
project.
*TODO: Fill in the information above and below. Add or remove rows as
needed. Use the worksheet to help identify and scope resource needs.*
_TODO: Fill in the information above and below. Add or remove rows as
needed. Use the worksheet to help identify and scope resource needs._
### Summary of Project
@ -101,59 +102,59 @@ to a project mailing list.
### Work Breakdown Structure and Estimates
*TODO: List tasks that will be needed for this project. Keep dividing
_TODO: List tasks that will be needed for this project. Keep dividing
tasks into subtasks until you feel that you have enough detail to expose
risks and make reasonable estimates in ideal engineering hours.*
risks and make reasonable estimates in ideal engineering hours._
*TIP: Label each step uniquely to show its position in the WBS, e.g.,
_TIP: Label each step uniquely to show its position in the WBS, e.g.,
Step 1.1.4.A. Use numbers for steps that you intend to do in sequence,
and use letters for steps that you intend to do in parallel. E.g., Step
1.1 comes before Steps 1.2.A and 1.2.B, but those two steps may be done
in parallel, and Step 1.3 will be done after all 1.2.\* steps have been
finished. Don't worry about renumbering if you delete a step.*
finished. Don't worry about renumbering if you delete a step._
| Step | Description | Estimate |
|-----------|-----------------------------------------------------------|----------|
| 1. | ::Preparation | |
| 1.1. | ::Developer training | 30h |
| 2. | ::Inception | |
| 2.1. | ::Requirements gathering | 30h |
| 2.2. | ::Requirements specification | 20h |
| 2.3. | ::Requirements validation | 10h |
| 3. | ::Elaboration | |
| 3.1. | ::High-level design | 5h |
| 3.2. | ::Low-level design (break down by component) | |
| 3.2.A. | ::Object design | 10h |
| 3.2.B. | ::User interface design | 10h |
| 3.2.C. | ::Database design | 3h |
| 3.3. | ::Design review and evaluation | 5h |
| 4. | ::Construction | |
| 4.1.A. | ::System implementation | |
| 4.1.A.1. | ::Implement COMPONENT-NAME 1 | 25h |
| 4.1.A.2. | ::Implement COMPONENT-NAME 2 | 25h |
| 4.1.A.3. | ::Implement COMPONENT-NAME 3 | 25h |
| 4.1.A.4. | ::Implement COMPONENT-NAME 4 | 25h |
| 4.1.A.5. | ::Integrate Components (mostly done during implementation)| 5h |
| 4.1.B. | ::Technical documentation (break down by component) | 10h |
| 4.1.C. | ::User documentation (break down by component) | 10h |
| 4.1.D. | ::Testing | |
| 4.1.D.1. | ::Test planning | 10h |
| 4.1.D.2. | ::Test code implementation (break down by component) | 30h |
| 4.1.D.3. | ::Test execution | 10h |
| 4.2. | ::Implementation review and evaluation | 15h |
| 5. | ::Transition | |
| 5.A. | ::Release packaging | 3h |
| 5.B. | ::Documentation for other groups | 3h |
| 6. | ::Reflection | |
| 6.1. | ::Postmortem report | 10h |
| | ::Total | 329 hours|
| Step | Description | Estimate |
| -------- | ---------------------------------------------------------- | --------- |
| 1. | ::Preparation | |
| 1.1. | ::Developer training | 30h |
| 2. | ::Inception | |
| 2.1. | ::Requirements gathering | 30h |
| 2.2. | ::Requirements specification | 20h |
| 2.3. | ::Requirements validation | 10h |
| 3. | ::Elaboration | |
| 3.1. | ::High-level design | 5h |
| 3.2. | ::Low-level design (break down by component) | |
| 3.2.A. | ::Object design | 10h |
| 3.2.B. | ::User interface design | 10h |
| 3.2.C. | ::Database design | 3h |
| 3.3. | ::Design review and evaluation | 5h |
| 4. | ::Construction | |
| 4.1.A. | ::System implementation | |
| 4.1.A.1. | ::Implement COMPONENT-NAME 1 | 25h |
| 4.1.A.2. | ::Implement COMPONENT-NAME 2 | 25h |
| 4.1.A.3. | ::Implement COMPONENT-NAME 3 | 25h |
| 4.1.A.4. | ::Implement COMPONENT-NAME 4 | 25h |
| 4.1.A.5. | ::Integrate Components (mostly done during implementation) | 5h |
| 4.1.B. | ::Technical documentation (break down by component) | 10h |
| 4.1.C. | ::User documentation (break down by component) | 10h |
| 4.1.D. | ::Testing | |
| 4.1.D.1. | ::Test planning | 10h |
| 4.1.D.2. | ::Test code implementation (break down by component) | 30h |
| 4.1.D.3. | ::Test execution | 10h |
| 4.2. | ::Implementation review and evaluation | 15h |
| 5. | ::Transition | |
| 5.A. | ::Release packaging | 3h |
| 5.B. | ::Documentation for other groups | 3h |
| 6. | ::Reflection | |
| 6.1. | ::Postmortem report | 10h |
| | ::Total | 329 hours |
### Deliverables in this Release
*TODO: List project deliverables in detail, with delivery dates.*
_TODO: List project deliverables in detail, with delivery dates._
| Deliverable Name | Description | Delivery Date |
|------------------|---------------------------------------------------------------|---------------|
| ---------------- | ------------------------------------------------------------- | ------------- |
| Deliverable Name | ::Description | Delivery Date |
| Deliverable Name | ::Description | Delivery Date |
| Deliverable Name | ::Description Description Description Description Description | Delivery Date |
@ -161,20 +162,20 @@ finished. Don't worry about renumbering if you delete a step.*
### Schedule for this Release
*TODO: Make the rows in this table match the steps in your WBS above. If
_TODO: Make the rows in this table match the steps in your WBS above. If
you have a large number of detailed steps, you can skip the most
detailed ones. The columns of the table represent weeks of calendar
time. For each cell in the table, enter the number of hours ideal
engineering time that the team will spend on that task that week. Total
your hours across and down.*
your hours across and down._
*TIP: These hours should total to the same as the total of the hours
_TIP: These hours should total to the same as the total of the hours
listed in your [resource needs](Resource-Needs) document. And, the
hours for each type of effort resources needed should correspond to the
sum for each type of task.*
sum for each type of task._
| Task \ Week | W-01 | W-02 | W-03 | W-04 | W-05 | W-06 | W-07 | W-08 | W-09 | W-10 | W-11 | W-12 | Task Total |
|-----------------|------|------|------|------|------|------|------|------|------|------|------|------|------------|
| --------------- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---------- |
| ::1. | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 |
| ::2. | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 |
| ::3. | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 |
@ -189,10 +190,10 @@ sum for each type of task.*
### Risk Management
*TODO: List and rank the major risks of this project, and what you plan
_TODO: List and rank the major risks of this project, and what you plan
to do to mitigate each risk. If you don't plan to do anything to
mitigate the risk, state that. Use the risk list below, or the [risks
worksheet](Risks).*
worksheet](Risks)._
Please see the [risks worksheet](Risks).
@ -203,15 +204,15 @@ Please see the [risks worksheet](Risks).
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?
HOW TO AVOID/MITIGATE?
6. ::We could be underestimating the impact of unknown tasks.
HOW TO AVOID/MITIGATE?
HOW TO AVOID/MITIGATE?
7. ::We could be underestimating the dependencies between tasks.
HOW TO AVOID/MITIGATE?
HOW TO AVOID/MITIGATE?
8. ::We could have misunderstood the customer's requirements.
HOW TO AVOID/MITIGATE?
HOW TO AVOID/MITIGATE?
9. ::The customer could change the requirements.
HOW TO AVOID/MITIGATE?
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.
@ -230,23 +231,23 @@ Please see the [risks worksheet](Risks).
::No, this is the only project that we are working on.
::Yes, and we have determined how many hours each person can actually
dedicate to this project.
dedicate to this project.
#### Are the same human or machine resources allocated to maintenance of past versions and/or planning of future versions during this release time period?
::No, this is the first release and we will not plan the next release.
::Yes, we predict that team members will spend an average of 20% of
their time maintaining previous releases and planning future
releases during this release time frame. Some weeks may be higher if
an urgent patch to a previous release is needed.
their time maintaining previous releases and planning future
releases during this release time frame. Some weeks may be higher if
an urgent patch to a previous release is needed.
#### Does this project depend on the success of any other project?
::No, this project stands alone.
::Yes, project P1 must provide library L, and project P2 must prove
the usability of feature F, and....
the usability of feature F, and....
#### Does any other project depend on this project?

17
Proposal.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::[PROJECT-NAME](Home)
@ -30,10 +31,10 @@ project.
### Background and Motivation
*TODO: Replace the example text below with text that describes your
_TODO: Replace the example text below with text that describes your
project. What are the needs or problems that you are trying to address?
Why do these needs (still) exist? Why are these problems worth solving?
Who is the customer? Write 2-4 paragraphs.*
Who is the customer? Write 2-4 paragraphs._
#### What is the setting and history behind this project?
@ -137,12 +138,12 @@ allows players to quickly find, evaluate, and join clans.
### Scope
*TODO: Replace the sample text below with a clear statement of the scope
_TODO: Replace the sample text below with a clear statement of the scope
of your project. What are the high-level things that you plan to do, and
that you will not do? What are your important simplifying assumptions?
Try to guard against reasonable misunderstandings that might arise if
you did not explain the scope. It can take the form of a paragraph,
bullet list, in/out list, and/or UML context diagram.*
bullet list, in/out list, and/or UML context diagram._
::We want to focus on the web application itself, and the features of that
application that help build a good gaming community.
@ -158,7 +159,7 @@ application that help build a good gaming community.
actually integrate with any game software
| In Scope | Out of Scope |
|----------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| -------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ::Building a web application for use with standard web servers and application servers | ::Building a new web server or application server |
| ::Working the most popular browsers (IE6, NN7/Mozilla) | ::Working with uncommon or outdated browsers |
| ::Security in the form of user accounts, passwords, and permissions | ::Special security against hackers. Finding or patching security holes in existing software components. |
@ -169,9 +170,9 @@ application that help build a good gaming community.
### Deliverables
*TODO: Briefly list project deliverables. When you are done, what will
_TODO: Briefly list project deliverables. When you are done, what will
you deliver to the customer? This can be copied from the draft project
plan and simplified to reduce technical detail.*
plan and simplified to reduce technical detail._
- ::Clan website directory engine
- ::Customization guide

71
QA-Plan.md
View File

@ -1,9 +1,7 @@
<!-- markdownlint-disable MD033 -->
<!-- markdownlint-disable-next-line MD041 -->
*TODO: For each release, update this file by filling in answers to the
<!-- markdownlint-disable-next-line first-line-h1 -->
_TODO: For each release, update this file by filling in answers to the
questions. In cases where multiple answers are already written, delete
those answers that do not apply.*
those answers that do not apply._
##### Project
@ -76,7 +74,7 @@ this release.
::There are many quality goals and approaches to assuring them. Since
we have limited time and resources for this release, we will focus
on the following components and aspects:
- ::COMPONENT-1
- ::COMPONENT-2
- ::COMPONENT-3
@ -99,8 +97,8 @@ activities:
### Quality Goals for this Release
*TODO: Add or edit goals to fit your project. Group them by priorities
that make sense for your project on this particular release.*
_TODO: Add or edit goals to fit your project. Group them by priorities
that make sense for your project on this particular release._
- ::Essential
- [Functionality > Correctness](Glossary-Standard-Terms#functionality--correctness)
@ -133,18 +131,18 @@ that make sense for your project on this particular release.*
### QA Strategy
*TODO: Consider the activities listed below and delete those that are not
_TODO: Consider the activities listed below and delete those that are not
applicable to your project. Edit and add new activities if needed. For
each activity, specify the coverage or frequency that you plan to
achieve. If you do not plan to perform an activity, write "N/A".*
achieve. If you do not plan to perform an activity, write "N/A"._
<!-- Hint: view this large table with text wrapping turned off -->
<!-- markdownlint-disable no-inline-html -->
| Activity | Coverage or Frequency | Description |
|--------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| ::Preconditions | <ul><li>::Every public method</li><li>::Every public method in COMPONENT-NAME</li><li>::All public methods that modify data</li></ul> | ::We will use if-statements at the beginning of public methods to validate each argument value. This helps to document assumptions and catch invalid values before they can cause faults. |
| ::Assertions | <ul><li>::Every private method</li><li>::Every private method in COMPONENT-NAME</li><li>::All private methods that modify data</li></ul> | ::Assertions will be used to validate all arguments to private methods. Since these methods are only called from our other methods, arguments passed to them should always be valid, unless our code is defective. Assertions will also be used to test class invariants and some postconditions. |
| ::Static analysis | <ul><li>::Strict compiler warnings</li><li>::Automated style checking</li><li>::XML validation</li><li>Detect common errors</li></ul> | ::We will use source code analysis tools to automatically detect errors. Style checkers will help make all of our code consistent with our coding standards. XML validation ensures that each XML document conforms to its DTD. Lint-like tools help detect common programming errors. E.g.: [lint](http://www.freebsd.org/cgi/man.cgi?query=lint), [lclint/splint](http://www.splint.org/), [jlint](http://artho.com/jlint/), [checkstyle](http://sourceforge.net/projects/checkstyle/), [Jcsc](http://sourceforge.net/projects/jcsc), [PyLint](https://www.pylint.org/), [PyChecker](http://pychecker.sourceforge.net/), [Tidy](http://www.html-tidy.org/) |
| ::Static analysis | <ul><li>::Strict compiler warnings</li><li>::Automated style checking</li><li>::XML validation</li><li>Detect common errors</li></ul> | ::We will use source code analysis tools to automatically detect errors. Style checkers will help make all of our code consistent with our coding standards. XML validation ensures that each XML document conforms to its DTD. Lint-like tools help detect common programming errors. E.g.: [lint](http://www.freebsd.org/cgi/man.cgi?query=lint), [lclint/splint](http://www.splint.org/), [jlint](http://artho.com/jlint/), [checkstyle](http://sourceforge.net/projects/checkstyle/), [Jcsc](http://sourceforge.net/projects/jcsc), [PyLint](https://www.pylint.org/), [PyChecker](http://pychecker.sourceforge.net/), [Tidy](http://www.html-tidy.org/) |
| ::Buddy review | <ul><li>::All changes to release branches</li><li>::All changes to COMPONENT-NAME</li><li>::All changes</li></ul> | ::Whenever changes must be made to code on a release branch (e.g., to prepare a maintenance release) the change will be reviewed by another developer before it is committed. The goal is to make sure that fixes do not introduce new defects. |
| ::Review meetings | <ul><li>::Weekly</li><li>::Once before release</li><li>::Every source file</li></ul> | ::We will hold review meetings where developers will perform formal inspections of selected code or documents. We choose to spend a small, predetermined amount of time and try to maximize the results by selecting review documents carefully. In the review process we will use and maintain a variety of checklists. |
| ::Unit testing | <ul><li>::100% of public methods, and 75% of statements</li><li>::100% of public methods</li><li>::75% of statements</li></ul> | ::We will develop and maintain a unit test suite using the JUnit framework. We will consider the boundary conditions for each argument and test both sides of each boundary. Tests must be run and passed before each commit, and they will also be run by the testing team. Each public method will have at least one test. And, the overall test suite will exercise at least 75% of all executable statements in the system. |
@ -155,24 +153,25 @@ achieve. If you do not plan to perform an activity, write "N/A".*
| ::Beta testing | <ul><li>::4 current customers</li><li>::40 members of our developers network</li><li>::1000 members of the public</li></ul> | ::We will involve outsiders in a beta test, or early access, program. We will beta testers directions to focus on specific features of the system. We will actively follow up with beta testers to encourage them to report issues. |
| ::Instrumentation and monitoring | <ul><li>::Monitor our ASP servers</li><li>::Remotely monitor customer servers</li></ul> | ::As part of our SLA, we will monitor the behavior of servers to automatically detect service outages or performance degradation. We have policies and procedures in place for failure notification, escalation, and correction. |
| ::Field failure reports | <ul><li>::Prompt users to report failures</li><li>::Automatically report failures</li></ul> | ::We want to understand each post-deployment system failure and actively take steps to correct the defect. The system has built-in capabilities for gathering detailed information from each system failure (e.g., error message, stack traceback, operating system version). This information will be transmitted back to us so that we may analyze it and act on it. |
<!-- markdownlint-enable no-inline-html -->
### QA Strategy Evaluation
*TODO: Use the following table to evaluate how well your QA Strategy will
assure your QA goals.*
_TODO: Use the following table to evaluate how well your QA Strategy will
assure your QA goals._
| Goal | Preconditions | Assertions | Buddy review | Review meeting | Unit testing | Manual system testing | Overall assurance |
|-----------------|-----------------|--------------|----------------|------------------|----------------|-------------------------|---------------------|
| Functionality | ::Medium | ::Medium | ::Medium | ::High | ::High | ::High | ::Strong |
| Correctness | ::High | ::High | ::Medium | ::Medium | ::High | ::Medium | ::Strong |
| Robustness | ::High | ::High | ::Medium | ::Medium | ::High | ::Medium | ::Strong |
| Usability | ::None | ::None | ::None | ::High | ::None | ::Medium | ::Strong |
| Security | ::Medium | ::None | ::Medium | ::High | ::None | ::Medium | ::Strong |
| Reliability | ::None | ::Medium | ::Low | ::Medium | ::Medium | ::Medium | ::Weak |
| Efficiency | ::None | ::None | ::Low | ::Medium | ::None | ::Low | ::At-Risk |
| Scalability | ::None | ::None | ::Low | ::Medium | ::Low | ::Low | ::At-Risk |
| Operability | ::None | ::None | ::None | ::Low | ::None | ::Low | ::At-Risk |
| Maintainability | ::Medium | ::Low | ::Medium | ::High | ::Low | ::None | ::Weak |
| Goal | Preconditions | Assertions | Buddy review | Review meeting | Unit testing | Manual system testing | Overall assurance |
| --------------- | ------------- | ---------- | ------------ | -------------- | ------------ | --------------------- | ----------------- |
| Functionality | ::Medium | ::Medium | ::Medium | ::High | ::High | ::High | ::Strong |
| Correctness | ::High | ::High | ::Medium | ::Medium | ::High | ::Medium | ::Strong |
| Robustness | ::High | ::High | ::Medium | ::Medium | ::High | ::Medium | ::Strong |
| Usability | ::None | ::None | ::None | ::High | ::None | ::Medium | ::Strong |
| Security | ::Medium | ::None | ::Medium | ::High | ::None | ::Medium | ::Strong |
| Reliability | ::None | ::Medium | ::Low | ::Medium | ::Medium | ::Medium | ::Weak |
| Efficiency | ::None | ::None | ::Low | ::Medium | ::None | ::Low | ::At-Risk |
| Scalability | ::None | ::None | ::Low | ::Medium | ::Low | ::Low | ::At-Risk |
| Operability | ::None | ::None | ::None | ::Low | ::None | ::Low | ::At-Risk |
| Maintainability | ::Medium | ::Low | ::Medium | ::High | ::Low | ::None | ::Weak |
Cell values in the table above are subjective estimates of the
effectiveness of each activity. This table helps to identify quality
@ -204,12 +203,13 @@ rating.
### Plan of Action
*TODO: Adjust this plan to fit your project.*
_TODO: Adjust this plan to fit your project._
*TODO: Once the plan is outlined, tasks should be assigned to individuals
and tracked to completion.*
_TODO: Once the plan is outlined, tasks should be assigned to individuals
and tracked to completion._
1. Preconditions and Assertions
- ::Refine requirements document whenever preconditions are not
already determined
- ::Create validation functions for use by preconditions and
@ -217,6 +217,7 @@ and tracked to completion.*
- ::Write preconditions and assertions in code
2. Review meetings
- ::Assign buddy reviewers whenever a change to a release branch is
considered
- ::Select an at-risk document or section of code for weekly review
@ -228,6 +229,7 @@ and tracked to completion.*
repository and track any issues identified in review meetings
3. Unit tests
- ::Set up infrastructure for easy execution of JUnit tests (this is
just an Ant target)
- ::Create unit tests for each class when the class is created
@ -241,6 +243,7 @@ and tracked to completion.*
- ::Update unit tests whenever requirements change
4. System tests
- ::Design and specify a detailed manual [test suite](Test-Suite).
- ::Review the system test suite to make sure that every UI screen
and element is covered
@ -266,12 +269,12 @@ and tracked to completion.*
#### Do the selected activities in the QA Strategy provide enough assurance that the project will meet it's quality goals?
::Yes, if all activities are carried out as planned, we are confident
that the quality goals will be satisfied. We will, of course, adjust
this plan as needed.
that the quality goals will be satisfied. We will, of course, adjust
this plan as needed.
::No, this plan leaves open several quality risks that have been noted
in the [Risk Management](Project-Plan#Risk-Management) section of the
[Project Plan](Project-Plan).
in the [Risk Management](Project-Plan#Risk-Management) section of the
[Project Plan](Project-Plan).
#### Have human resources been allocated to carry out the QA activities?

35
Release-Checklist.md
View File

@ -1,7 +1,8 @@
<!-- markdownlint-disable-next-line MD041 -->
*TODO: For each release, copy this file and fill in answers to the
<!-- markdownlint-disable-next-line first-line-h1 -->
_TODO: For each release, copy this file and fill in answers to the
questions. In cases where multiple answers are already written, delete
those answers that do not apply.*
those answers that do not apply._
##### Project
@ -30,16 +31,16 @@ stakeholders of their upcoming responsibilities. Once this checklist has
been satisfied, this release may be sent to manufacturing and sold to
customers with the full support of the organization.
*TODO: Discuss each item with the relevant stakeholders and update its
_TODO: Discuss each item with the relevant stakeholders and update its
status. Add comments as needed to record important decisions or link to
resulting documents. Add new items as needed for your particular project
or process. Any uncovered problems or tasks should be tracked in the
issue tracker.*
issue tracker._
### Marketing / Product Management
| Item | Status | Comments |
|--------------------------------------------------------------------------|---------|----------|
| ------------------------------------------------------------------------ | ------- | -------- |
| ::All new requirements for this release have been tracked | Pending | |
| ::All prior defects needing resolution in this release have been tracked | Pending | |
| ::All marketing documents have been updated | Pending | |
@ -48,7 +49,7 @@ issue tracker.*
### Development
| Item | Status | Comments |
|--------------------------------------------------------|---------|----------|
| ------------------------------------------------------ | ------- | -------- |
| ::All needed design work has been completed | Pending | |
| ::All needed design work has been reviewed | Pending | |
| ::All development work has been completed | Pending | |
@ -61,7 +62,7 @@ issue tracker.*
### Quality Assurance {#quality-assurance}
| Item | Status | Comments |
|-------------------------------------------------|---------|----------|
| ----------------------------------------------- | ------- | -------- |
| ::The QA plan and test cases have been updated | Pending | |
| ::The QA plan has been completely carried out | Pending | |
| ::All discovered defects have been tracked | Pending | |
@ -71,7 +72,7 @@ issue tracker.*
### Release Engineering / Configuration Management
| Item | Status | Comments |
|----------------------------------------------------------------------------------------------------------------------|---------|----------|
| -------------------------------------------------------------------------------------------------------------------- | ------- | -------- |
| ::All components have been properly tagged for release, and the release configuration is clearly defined | Pending | |
| ::Change-control practices have been followed, meaning that the released product does not contain unapproved changes | Pending | |
| ::The RelEng team is satisfied with this release | Pending | |
@ -79,7 +80,7 @@ issue tracker.*
### User Experience
| Item | Status | Comments |
|-----------------------------------------------------------|---------|----------|
| --------------------------------------------------------- | ------- | -------- |
| ::Any new or changed functionality is deemed usable | Pending | |
| ::On-line and printed user documentation has been updated | Pending | |
| ::The UE team is satisfied with this release | Pending | |
@ -87,7 +88,7 @@ issue tracker.*
### Technical Support / Operations
| Item | Status | Comments |
|--------------------------------------------------------------------------------------------------------------|---------|----------|
| ------------------------------------------------------------------------------------------------------------ | ------- | -------- |
| ::Theory of operations document has been updated | Pending | |
| ::Tech support / Operations has successfully installed, upgraded, and used this release | Pending | |
| ::Any "Early access" or "Beta" program was conducted successfully and all resulting issues have been tracked | Pending | |
@ -98,7 +99,7 @@ issue tracker.*
### Services / Training
| Item | Status | Comments |
|----------------------------------------------------------------------------------|---------|----------|
| -------------------------------------------------------------------------------- | ------- | -------- |
| ::Services / Training has had access to this release | Pending | |
| ::The impact of any changes on service offerings has been identified and tracked | Pending | |
| ::Training materials have been updated | Pending | |
@ -107,7 +108,7 @@ issue tracker.*
### Legal
| Item | Status | Comments |
|-------------------------------------------------------------------------------|---------|----------|
| ----------------------------------------------------------------------------- | ------- | -------- |
| ::Legal risks associated with this release have been identified and tracked | Pending | |
| ::We hold proper licenses for all reused components and intellectual property | Pending | |
| ::We conform to all relevant laws and regulations (e.g., export, safety) | Pending | |
@ -122,13 +123,13 @@ issue tracker.*
- Done: The stakeholders agree that the item has been satisfied
- Failed: This item has forced us to abandon this release
*TIP: If a stakeholder hits difficulties with this release after it goes
_TIP: If a stakeholder hits difficulties with this release after it goes
out, add those issues to the checklist template so that everyone knows
that they will be explicitly managed on the next release. Conduct a
postmortem review to help expose difficulties rather than repeat them.*
postmortem review to help expose difficulties rather than repeat them._
*TIP: You might consider some of the following additional stakeholders at
_TIP: You might consider some of the following additional stakeholders at
your organization: Other engineering groups (i.e., hardware design),
Manufacturing and Shipping, Software Process Improvement, Key customers
and partners, External developers, Risk Management, Business
Development, and Upper Management.*
Development, and Upper Management._

37
Release-Notes.md
View File

@ -1,9 +1,10 @@
<!-- markdownlint-disable-next-line MD041 -->
*TODO: For each release, copy this file and fill in the needed
information.*
<!-- markdownlint-disable-next-line first-line-h1 -->
*TODO: Make sure to use the **product** name and **external** release
number, not internal information.*
_TODO: For each release, copy this file and fill in the needed
information._
_TODO: Make sure to use the **product** name and **external** release
number, not internal information._
##### Product
@ -32,7 +33,7 @@ The following sections describe the release in detail and provide
late-breaking or other information that supplements the main
documentation.
*TODO: Consider using one of the following example paragraphs.*
_TODO: Consider using one of the following example paragraphs._
::This is a developer release for internal evaluation only. Please report
any issues via the internal issue tracker.
@ -70,11 +71,11 @@ this release.
### What's New?
*TODO: Briefly list major user-visible enhancements. Or, note that
_TODO: Briefly list major user-visible enhancements. Or, note that
nothing major has been added. Technical issues should only be mentioned
if this is a reusable software component that will be used to build
larger products. Do not include issue numbers. Links to detailed
information can be helpful.*
information can be helpful._
- ::Added 4 new play-back modes
- ::Increased play-back speed by as much as 30%
@ -85,16 +86,16 @@ information can be helpful.*
### Installation and Upgrade Notes
*TODO: Fill in these sections. The text here is only an example.*
_TODO: Fill in these sections. The text here is only an example._
#### ::Installation
::See the [installation instructions](Installation-Guide) for full details.
Please note that in this release, ...
Please note that in this release, ...
::IMPORTANT: You must completely uninstall any previous "developer
release" or "early access" version of this product before installing
this release.
release" or "early access" version of this product before installing
this release.
#### ::Manifest
@ -142,13 +143,13 @@ updated by using the WaveUpgrade utility.
### Recent Changes
*TODO: Query your public issue tracking system to produce a report of
_TODO: Query your public issue tracking system to produce a report of
changes in this release. Include the issue number, type, and one-line
summary. Include issues that were highlighted in the "What's New?"
section above. You may revise one-line summaries in the issue tracker,
prior to generating the report, if you notice that they are incorrect.
You may exclude or summarize changes that might give away valuable
proprietary information.*
proprietary information._
- ::FIX [09823](#tbd) Screen frozen when caps-lock is on
- ::FIX [09912](#tbd) Static heard while downloading
@ -160,16 +161,16 @@ proprietary information.*
### Known Problems and Workarounds
*TODO: Query your public issue tracking system to produce a report of
_TODO: Query your public issue tracking system to produce a report of
defects discovered in this release, or in previous releases that are
still not resolved. Include information on workarounds from the issues.
Otherwise, same as above.*
Otherwise, same as above._
- ::DEFECT [07293](#tbd) Player skips on very loud playback.
- ::WORKAROUND: Limit volume to settings 1 through 9.
- ::DEFECT [10509](#tbd) Cannot switch directly from random play mode to
Internet play-list.
Internet play-list.
- ::WORKAROUND: Switch to local play-list first. Click [here](#tbd) for
detailed instructions.
detailed instructions.
- ::DEFECT [10589](#tbd) Static heard while booting
- ::DEFECT [10944](#tbd) Repeat-mode cannot play more than 999 times

151
Resource-Needs.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::[PROJECT-NAME](Home)
@ -26,16 +27,16 @@ this project will need the following resources to meet its goals. If
fewer resources are available, the scope of the release should be
reconsidered or the process must be changed.
*TODO: Fill in the information above and below. Add or remove rows as
_TODO: Fill in the information above and below. Add or remove rows as
needed. Use the worksheet to help identify and scope resource needs.
These rows are just examples. The total effort listed in this example
may not even match the totals given in other examples of related
documents.*
documents._
### Human Resource Needs
| Need | Resource | Amount | Status | Comments/Responsibilities |
|-------------------------------------------|-----------------------------------------|------------|------------|---------------------------|
| ----------------------------------------- | --------------------------------------- | ---------- | ---------- | ------------------------- |
| ::Project Management | ::PERSON-NAME | ::20 hours | ::Pending | |
| ::Requirements | ::PERSON-NAME | ::20 hours | ::Assigned | |
| ::Requirements | ::PERSON-NAME, PERSON-NAME, PERSON-NAME | ::10 hours | ::Assigned | |
@ -56,7 +57,7 @@ documents.*
### Capital Needs
| Need | Resource | Amount | Status | Comments |
|------------------------------------|-------------------------------------------------------|-----------|---------------------------|---------------------------------------------------------------------------------|
| ---------------------------------- | ----------------------------------------------------- | --------- | ------------------------- | ------------------------------------------------------------------------------- |
| ::Training materials | ::Book/Course on specific technology | ::1 | ::Allocated | ::Book ordered |
| ::Development Workstations | ::800MHz PC, 256MB RAM | ::4 | ::Satisfied | ::Dev group will use existing workstations |
| ::Development DB Server | ::Dual CPU 1GHz PC, 512MB RAM: SERVERNAME.company.com | ::1 | ::Allocated | |
@ -89,10 +90,10 @@ The goal of this checklist is to help expose resource needs that might
otherwise be missed. It does not help with the actual estimated number
of hours needed. Those estimates should be based on the project plan.
*TODO: Answer the questions below. If multiple sample answers are
_TODO: Answer the questions below. If multiple sample answers are
provided, [chip away](Glossary-Standard-Terms#chipping-away) the ones that do
not apply. Edit any provided answers as needed. Use this exercise to
help you fill in the tables above.*
help you fill in the tables above._
#### Does this project need more than a few days work?
@ -127,7 +128,7 @@ help you fill in the tables above.*
#### Does the project plan include complex configuration of existing components?
:: Yes. Component expert needed. Also need time to coordinate with
development and operations teams.
development and operations teams.
:: No. No component experts are needed
@ -136,19 +137,19 @@ help you fill in the tables above.*
:: Yes. No training time needed.
:: No. Effort needed for training. Need training materials, courses, or
time with experts or mentors. List specific training
needs individually.
time with experts or mentors. List specific training
needs individually.
#### Is the entire development team have an agreed upon software development methodology?
:: Yes. No effort needed for defining a methodology.
:: Yes. But, effort is needed to refine the methodology to the project
at hand.
at hand.
:: No. Effort needed to define and document a methodology and train all
team members. Additional effort needed for refinements throughout
the project.
team members. Additional effort needed for refinements throughout
the project.
#### Does the project plan include end-user documentation?
@ -169,131 +170,131 @@ help you fill in the tables above.*
:: No, but other developers will need training to reuse this component.
:: No. Effort put into producing good technical documentation should
be enough.
be enough.
#### Will the product of this project be sold to customers, directly or indirectly?
:: Yes. The full SDM must be followed, including effort by a change
control board and release engineering.
:: Yes. The full SDM must be followed, including effort by a change
control board and release engineering.
:: No, it is for internal use only but it will be used repeatedly to
help build a shipping product. Release engineering and CCB effort is
still needed.
:: No, it is for internal use only but it will be used repeatedly to
help build a shipping product. Release engineering and CCB effort is
still needed.
:: No, it is for internal use only and will only be used once. Release
engineering and CCB effort not needed.
:: No, it is for internal use only and will only be used once. Release
engineering and CCB effort not needed.
#### Does the QA plan call for the running of automated unit tests?
:: Yes. Development effort will be needed to implement unit tests.
:: Yes. Development effort will be needed to implement unit tests.
:: No. Additional QA effort will be needed for manual testing.
:: No. Additional QA effort will be needed for manual testing.
#### Does the QA plan call for more than the running of automated unit tests?
:: Yes. QA effort will be needed.
:: Yes. QA effort will be needed.
:: No. Unit tests will be enough for this component, full QA can be
done on products that use this component.
:: No. Unit tests will be enough for this component, full QA can be
done on products that use this component.
#### How many development workstations will be needed?
:: 1 per developer.
:: 1 per developer.
:: 1 per developer, plus extra for...
:: 1 per developer, plus extra for...
#### What development servers are needed?
:: None.
:: None.
:: One for the whole team.
:: One for the whole team.
:: One for the one aspect of development, another for another aspect.
:: One for the one aspect of development, another for another aspect.
:: One for the one branch of development, another for another branch.
:: One for the one branch of development, another for another branch.
#### What database servers are needed?
:: None. No database is being used.
:: None. No database is being used.
:: None. Database is integrated into product and does not require a
separate server.
:: None. Database is integrated into product and does not require a
separate server.
:: One for the whole team.
:: One for the whole team.
:: One for the developers, one for QA.
:: One for the developers, one for QA.
:: One for one branch of development, another for another branch.
:: One for one branch of development, another for another branch.
:: One for the developers, one for QA, one for load testing.
:: One for the developers, one for QA, one for load testing.
:: One for each developer or tester, plus one for load testing.
:: One for each developer or tester, plus one for load testing.
#### What machines are needed for automated testing?
:: None. Automated testing will not be done.
:: None. Automated testing will not be done.
:: None. Automated testing will be done on workstations.
:: None. Automated testing will be done on workstations.
:: One for all nightly automated tests.
:: One for all nightly automated tests.
:: One for one aspect of nightly automated tests, another for
another aspect.
:: One for one aspect of nightly automated tests, another for
another aspect.
:: One for one branch of development, another for another branch.
:: One for one branch of development, another for another branch.
#### What machines are needed for load testing?
:: None. Load testing will not be done.
:: None. Load testing will not be done.
:: None. Load testing will be done on workstations.
:: None. Load testing will be done on workstations.
:: One machine will do all load testing.
:: One machine will do all load testing.
:: Several machines needed to act as clients and servers.
:: Several machines needed to act as clients and servers.
:: One cluster of load testing machines for each branch of development.
:: One cluster of load testing machines for each branch of development.
#### What development tools must be licensed for this project?
:: None. Everything is implemented by us.
:: None. Everything is implemented by us.
:: None. All development tools are open source.
:: None. All development tools are open source.
:: Some tools: IDE, database, testing tools. These tools have already
been purchased, installed, and configured.
:: Some tools: IDE, database, testing tools. These tools have already
been purchased, installed, and configured.
:: Some tools: IDE, database, testing tools. Budget must be allocated
to purchase these tools. Effort must be allocated to research and
select tools for purchase, install, and configure them.
:: Some tools: IDE, database, testing tools. Budget must be allocated
to purchase these tools. Effort must be allocated to research and
select tools for purchase, install, and configure them.
#### What software components must be licensed for this project?
:: None. Everything is implemented by us.
:: None. Everything is implemented by us.
:: None. All reused components are open source.
:: None. All reused components are open source.
:: Some components: database, server software, libraries. These
components have already been selected, purchased, installed,
and configured.
:: Some components: database, server software, libraries. These
components have already been selected, purchased, installed,
and configured.
:: Some components: database, server software, libraries. Effort must
be allocated to research, select, install and configure
these components. Budget must be allocated to purchase them.
:: Some components: database, server software, libraries. Effort must
be allocated to research, select, install and configure
these components. Budget must be allocated to purchase them.
#### Are any of the personnel assignments of capital allocations conditional?
:: Yes. All such conditions are written in the comments column above.
We have a contingency plan that will still achieve (an
acceptable subset) of the project goals.
:: Yes. All such conditions are written in the comments column above.
We have a contingency plan that will still achieve (an
acceptable subset) of the project goals.
:: No. Management has set aside these resources as promised, and the
needs of this project will take priority over any other project that
is likely to need the same resources.
:: No. Management has set aside these resources as promised, and the
needs of this project will take priority over any other project that
is likely to need the same resources.
#### Have these resource assignments been communicated to the people being assigned and their managers?
:: Yes, everyone understands. Feedback is welcome.
:: Yes, everyone understands. Feedback is welcome.
:: No, this is a risk that is noted in the [Risk
Management](Project-Plan#Risk-Management) section.
:: No, this is a risk that is noted in the [Risk
Management](Project-Plan#Risk-Management) section.

6
Review-Meeting-Notes.md
View File

@ -1,5 +1,5 @@
<!-- markdownlint-disable-next-line first-line-h1 -->
<!-- markdownlint-disable-next-line MD041 -->
##### Project
::[PROJECT-NAME](Home)
@ -40,8 +40,8 @@
### Meeting Minutes
*TODO: Fill in the information above and write a brief summary of what
happened at the meeting. The text below is just a sample.*
_TODO: Fill in the information above and write a brief summary of what
happened at the meeting. The text below is just a sample._
::We started on time with 3 members and the other team members arrived
shortly thereafter.

29
Risks.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::[PROJECT-NAME](Home)
@ -38,8 +39,8 @@ 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.
*TODO: You should update these lists regularly. They should be reviewed
by customers and developers from time to time.*
_TODO: You should update these lists regularly. They should be reviewed
by customers and developers from time to time._
### General contingency plans
@ -74,21 +75,21 @@ delivery date.
### 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 |
| ::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 |
| 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 |
### 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.*
_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 |
@ -97,7 +98,7 @@ impact of a risk has increased to make it a "major" risk.*
| ::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 |
| ::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

5
SDM.md
View File

@ -1,5 +1,6 @@
<!-- markdownlint-disable-next-line MD041 -->
*TODO: This template is not done yet. Feel free to contribute your ideas.*
<!-- markdownlint-disable-next-line first-line-h1 -->
_TODO: This template is not done yet. Feel free to contribute your ideas._
A Software Development Methodology is always specific to a given
company, but the outline of that document could be reused, as could some

15
SRS.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::PROJECT-NAME
@ -30,8 +31,8 @@ and validated by activities outlined in the [QA plan](QA-Plan).
### Introduction
*TODO: Provide a brief overview of this release of the product. You can
copy text from the project proposal, paste it here, and shorten it.*
_TODO: Provide a brief overview of this release of the product. You can
copy text from the project proposal, paste it here, and shorten it._
::PARAGRAPH
@ -60,8 +61,8 @@ Details:
### Non-Functional Requirements
*TODO: Describe the non-functional requirements for this release. Some
examples are provided below.*
_TODO: Describe the non-functional requirements for this release. Some
examples are provided below._
#### What are the usability requirements?
@ -199,10 +200,10 @@ Details:
### Environmental Requirements
*TODO: Describe the environmental requirements for this release.
_TODO: Describe the environmental requirements for this release.
Environmental requirements describe the larger system of hardware,
software, and data that this product must work within. Some examples are
provided below.*
provided below._
#### What are the system hardware requirements?

31
Status-Report.md
View File

@ -1,10 +1,11 @@
<!-- markdownlint-disable-next-line MD041 -->
*TODO: Copy this file for each status report. Fill in the information
below. Email a notification to stakeholders when this report is made
available.*
<!-- markdownlint-disable-next-line first-line-h1 -->
*TODO: Edit the rows in the following table. In some rows, multiple
examples are given, you should select/edit only one.*
_TODO: Copy this file for each status report. Fill in the information
below. Email a notification to stakeholders when this report is made
available._
_TODO: Edit the rows in the following table. In some rows, multiple
examples are given, you should select/edit only one._
##### Project
@ -89,9 +90,9 @@ release. These issues were selected because ...
### Risk Management
*TODO: List 3-10 of the top project risks that are still outstanding.
_TODO: List 3-10 of the top project risks that are still outstanding.
This list may be an **updated** copy from [project plan](Project-Plan.html#Risk-Management)
or a previous status report.*
or a previous status report._
- ::We could face major difficulties with the technology chosen for
this project. HOW TO AVOID/MITIGATE?
@ -104,15 +105,15 @@ or a previous status report.*
### Upcoming Activity
*TODO: Provide a few bullets describing what you will do between now and
_TODO: Provide a few bullets describing what you will do between now and
the next status report. The text below is just an example, replace it
with your own words. Link to open issues in the issue tracker whenever
possible.*
possible._
- ::Fix [issue 130](ISSUE-TRACKER-URL)
- ::Fix [issue 133](ISSUE-TRACKER-URL)
- ::Verify [issue 102](ISSUE-TRACKER-URL), [issue 103](ISSUE-TRACKER-URL),
[issue 107](ISSUE-TRACKER-URL), and [issue 109](ISSUE-TRACKER-URL)
[issue 107](ISSUE-TRACKER-URL), and [issue 109](ISSUE-TRACKER-URL)
- ::Conduct regular team meeting: Tuesday, 1 hour
- ::Conduct review meeting: Wednesday, 2 hours
- ::Make major progress on COMPONENT
@ -123,11 +124,11 @@ possible.*
### Tracking to Plan
*TODO: Copy the Work Breakdown Structure from the [project plan](Project-Plan) and paste it here.
Add a new column for actual effort spent so far by all team members.*
_TODO: Copy the Work Breakdown Structure from the [project plan](Project-Plan) and paste it here.
Add a new column for actual effort spent so far by all team members._
| Step | Description | Planned Hours | Spent To-Date |
|------------|----------------------------------------------------------------------|---------------|---------------|
| ---------- | -------------------------------------------------------------------- | ------------- | ------------- |
| ::1. | ::Preparation | | |
| ::1.1. | ::Developer training | ::30h | ::0h |
| ::2. | ::Inception | | |
@ -135,7 +136,7 @@ Add a new column for actual effort spent so far by all team members.*
| ::2.2. | ::Requirements specification | ::20h | ::0h |
| ::2.3. | ::Requirements validation | ::10h | ::0h |
| ::3. | ::Elaboration | | |
| ::3.1. | ::High-level design | ::5h |::0h |
| ::3.1. | ::High-level design | ::5h | ::0h |
| ::3.2. | ::Low-level design (break down by component) | | |
| ::3.2.A. | ::Object design | ::10h | ::0h |
| ::3.2.B. | ::User interface design | ::10h | ::0h |

29
Summary.md
View File

@ -1,8 +1,9 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
### Mission and Scope
*TODO: Answer these questions in your own words. This is condensed
from the project [Home](Home).*
_TODO: Answer these questions in your own words. This is condensed
from the project [Home](Home)._
#### What problem does this project address?
@ -18,7 +19,7 @@ from the project [Home](Home).*
### 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
@ -35,9 +36,9 @@ functionality and a wider set of testers.
### Resources and schedule
*TODO: Briefly describe the project resources and schedule. This is
_TODO: Briefly describe the project resources and schedule. This is
condensed from the [project plan](Project-Plan), [resource needs](Resource-Needs),
and [legal issues](legal.html) documents.*
and [legal issues](legal.html) documents._
#### What are the deadlines for this project?
@ -67,11 +68,11 @@ and [legal issues](legal.html) documents.*
### Requirements
*TODO: Briefly describe the most important system requirements. This is
_TODO: Briefly describe the most important system requirements. This is
condensed from the [user needs](User-Needs),
[interview notes](interview-notes.html), [SRS](SRS),
[use case suite](Use-Case-Suite),
and [feature set](Feature-Set) documents.*
and [feature set](Feature-Set) documents._
#### Who are the project stakeholders?
@ -94,9 +95,9 @@ and [feature set](Feature-Set) documents.*
### Design
*TODO: Briefly describe the most important aspects of the design. This is
_TODO: Briefly describe the most important aspects of the design. This is
condensed from the [design](Design) template and associated
worksheets.*
worksheets._
#### What are your ranked design goals?
@ -139,9 +140,9 @@ worksheets.*
### Quality Assurance
*TODO: Briefly describe your quality goals and how you will achieve them.
_TODO: Briefly describe your quality goals and how you will achieve them.
This is condensed from the [QA plan](QA-Plan), [test
suite](test-suite), and [test cases](test-cases.html) documents.*
suite](test-suite), and [test cases](test-cases.html) documents._
#### What are your ranked quality goals?
@ -204,9 +205,9 @@ Where is the user documentation?
### Glossary
*TODO: Define any technical terms that you use above, if a new member of
_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.*
[glossary](Glossary) documents._
#### ::TECHNICAL TERM 1

21
Target-and-Benefits.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::[PROJECT-NAME](Home)
@ -23,8 +24,8 @@ cases.
### Target Audience
*TODO: Fill in the information above and below. Provided answers are only
examples. Delete them and answer in your own words.*
_TODO: Fill in the information above and below. Provided answers are only
examples. Delete them and answer in your own words._
#### What market segment is this product in?
@ -66,15 +67,15 @@ about the potential for viruses.
### Benefits to Customers
*TODO: List high-level benefits that this product will provide. For each,
_TODO: List high-level benefits that this product will provide. For each,
identify the type of customer or user that will benefit. Each benefit
should be in real-world terms, not involving just this product itself.
You may want to highlight benefits that are not offered by competing
products. Benefits to the development organization should be listed in
[Risks and Rewards](Project-Plan#risk-management).*
[Risks and Rewards](Project-Plan#risk-management)._
*TIP: If you can rank benefits by value, use numbered lists (the HTML
&lt;ol> tag), otherwise use bullet lists (the HTML &lt;ul> tag).*
_TIP: If you can rank benefits by value, use numbered lists (the HTML
&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.
@ -123,9 +124,9 @@ products. Benefits to the development organization should be listed in
### Potential Downside
*TODO: Could anyone be harmed or put at a disadvantage because of your
_TODO: Could anyone be harmed or put at a disadvantage because of your
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.*
implementation, assume that you build the system as specified on time._
- ::Privacy
- ::When players opt into clans, they also opt into receiving
@ -133,7 +134,7 @@ implementation, assume that you build the system as specified on time.*
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.
game servers, thus they lose the ability to play/cheat.
- ::Type of downside
1. ::Worst downside
2. ::Downside

9
Test-Case-Format.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Related Documents
- [QA Plan](QA-Plan) > [Test Suite](Test-Suite) > Test Case Format
@ -29,7 +30,7 @@ Assumptions that must be met before the test case can be run. E.g., &quot;logged
**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.:
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}
@ -123,8 +124,8 @@ the end of the test case.
steps of the named test case and then continue on to the next step
of this test case.
*Every test case must include a verify step at the end so that the
_Every test case must include a verify step at the end so that the
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.*
number of short tests._

15
Test-Cases.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::[PROJECT-NAME](Home)
@ -110,7 +111,7 @@ E.g., &quot;logged in&quot;, &quot;guest login allowed&quot;,
::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
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
@ -156,7 +157,7 @@ E.g., &quot;logged in&quot;, &quot;guest login allowed&quot;,
::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
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
@ -202,7 +203,7 @@ E.g., &quot;logged in&quot;, &quot;guest login allowed&quot;,
::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
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
@ -248,7 +249,7 @@ E.g., &quot;logged in&quot;, &quot;guest login allowed&quot;,
::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
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
@ -294,7 +295,7 @@ E.g., &quot;logged in&quot;, &quot;guest login allowed&quot;,
::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
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
@ -339,7 +340,7 @@ E.g., &quot;logged in&quot;, &quot;guest login allowed&quot;,
::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
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

43
Test-Run-Suite.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::[PROJECT-NAME](Home)
@ -23,34 +24,34 @@ have been tested and those that have not. Clearly understanding the
degree to which the system has been tested helps to assess progress,
assess risk, and focus ongoing testing efforts.
*TODO:*
_TODO:_
- *Review the [target audience](Target-and-Benefits),
- _Review the [target audience](Target-and-Benefits),
[environmental requirements](SRS#environmental), and [possible
deployments](Design-Architecture#deployment) to understand the
set of possible system configurations that could be tested.*
- *Use a table or list to describe that set of possible configurations.
Mark each possibility with Pending, N/A, or Waived.*
- *Track each test run with an issue in the issue tracker or an item in
the [test-runs](Test-Runs) document.*
- *Periodically review the set of possible system configurations to
identify any additional needed test runs.*
set of possible system configurations that could be tested._
- _Use a table or list to describe that set of possible configurations.
Mark each possibility with Pending, N/A, or Waived._
- _Track each test run with an issue in the issue tracker or an item in
the [test-runs](Test-Runs) document._
- _Periodically review the set of possible system configurations to
identify any additional needed test runs._
### ::Test Runs by Operating System and Browser
| OS \ Browser | IE | Firefox | Safari | Chrome | other |
|----------------|------------------------------------------|----------------------------------|----------------------------------|-----------|---------|
| ::Windows | ::[Passed](Test-Runs#TR-01) | ::[Passed](Test-Runs#TR-02) | ::N/A | ::Pending | ::N/A |
| ::Linux | ::N/A | ::[Passed](Test-Runs#TR-03) | ::Pending | ::Pending | ::N/A |
| ::Mac | ::[FAILED](Test-Runs#TR-10) | ::Pending | ::[Passed](Test-Runs#TR-11) | ::Pending | ::N/A |
| ::iOS | ::N/A | ::N/A | ::Pending | ::N/A | ::N/A |
| ::Android | ::N/A | ::N/A | ::Pending | ::Pending | ::N/A |
| OS \ Browser | IE | Firefox | Safari | Chrome | other |
| ------------ | --------------------------- | --------------------------- | --------------------------- | --------- | ----- |
| ::Windows | ::[Passed](Test-Runs#TR-01) | ::[Passed](Test-Runs#TR-02) | ::N/A | ::Pending | ::N/A |
| ::Linux | ::N/A | ::[Passed](Test-Runs#TR-03) | ::Pending | ::Pending | ::N/A |
| ::Mac | ::[FAILED](Test-Runs#TR-10) | ::Pending | ::[Passed](Test-Runs#TR-11) | ::Pending | ::N/A |
| ::iOS | ::N/A | ::N/A | ::Pending | ::N/A | ::N/A |
| ::Android | ::N/A | ::N/A | ::Pending | ::Pending | ::N/A |
### ::Test Runs by Locale
*TIP: Use this outline to guide the testing of internationalized
_TIP: Use this outline to guide the testing of internationalized
applications. Each locale indicates a native language as well as formats
for presenting money, dates, times, etc.*
for presenting money, dates, times, etc._
- ::English US: [Passed](Test-Runs#TR-00)
- ::English UK: [Passed](Test-Runs#TR-01)
@ -64,10 +65,10 @@ for presenting money, dates, times, etc.*
### ::Test Runs by Hardware Configuration
*TIP: Use this outline for products that depend on specific hardware.
_TIP: Use this outline for products that depend on specific hardware.
E.g., a disk crash recovery product would depend on the type of drive, a
game might depend on processor speed and graphics cards, other products
might depend on memory or other hardware specs.*
might depend on memory or other hardware specs._
- ::PCs
- ::IDE drive: Pending

7
Test-Runs.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->##### Project
<!-- markdownlint-disable-next-line first-line-h1 -->##### Project
::[PROJECT-NAME](Home)
##### Internal Release Number
@ -14,8 +15,8 @@
---
*TODO: Use this file to record the results of each test run. Or, use your
issue tracking tool to plan and track test runs.*
_TODO: Use this file to record the results of each test run. Or, use your
issue tracking tool to plan and track test runs._
### TR-00: Test Run

37
Test-Suite.md
View File

@ -1,5 +1,6 @@
<!-- markdownlint-disable MD033 -->
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::[PROJECT-NAME](Home)
@ -24,51 +25,51 @@ Organizing the suite of test cases by priority, functional area, actor,
business object, or release can help identify parts of the system that
need additional test cases.
*TODO: Before writing individual test cases, list the test cases that you
_TODO: Before writing individual test cases, list the test cases that you
think you will need. Organize them in a way that will purposely leave
visible blanks on this page if you are missing use cases. Choose one or
more of the organizations show below.*
more of the organizations show below._
*TIP: Refer back to your [use cases](Use-Cases) document. Use them
_TIP: Refer back to your [use cases](Use-Cases) document. Use them
for ideas and make sure that you cover all of them. Remember that test
cases are more precise than use cases, test cases should reference
specific details of your implementation, and there may be several test
cases for a given use case.*
cases for a given use case._
*TIP: The test case suite can be organized into nested lists according to
_TIP: The test case suite can be organized into nested lists according to
other coverage criteria, e.g., by actor. Or, it can be organized into
tables that consider two aspects at a time, e.g., business objects vs.
actor. If a certain section of the tree or table does not need test
cases, explicitly mark it "N/A". Otherwise, if a section needs more test
cases than you have written yet, mark it "TODO". If one cell or list
item contains many tests, break that section out into its own table, as
done for the enrollment feature below.*
done for the enrollment feature below._
### Test Cases by Business Object and Operation
<!-- Hint: turn off word wrapping to edit this big table -->
| BO \ Action | ::add | ::list/browse | ::edit | ::delete | ::search | ::other |
|---------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------|
| ::Student | <ul><li>::[student-add-1](Test-Cases#student-add-1)</li><li>::[student-add-2](Test-Cases#student-add-2)</li><li>::[student-add-3](Test-Cases#student-add-3)</li></ul> | ::[student-list-1](Test-Cases#student-list-1) | <ul><li>::[student-edit-1](Test-Cases#student-edit-1)</li><li>::[student-edit-2](Test-Cases#student-edit-2)</li></ul> | ::[student-delete-1](test-casesstudent-delete-1) | <ul><li>::[student-search-1](Test-Cases#student-search-1)</li><li>::[student-search-2](Test-Cases#student-search-2)</li></ul> | ::[See grid below](#enroll-grid) |
| ::Course | <ul><li>::[course-add-1](Test-Cases#course-add-1)</li><li>::[course-add-2](Test-Cases#course-add-2)</li></ul> | ::[course-list-1](Test-Cases#course-list-1) | <ul><li>::[course-edit-1](Test-Cases#course-edit-1)</li><li>::[course-move-1](Test-Cases#course-move-1)</li><li>::[course-add-prereq-1](Test-Cases#course-add-prereq-1)</li></ul> | ::[course-cancel-1](Test-Cases#course-cancel-1) | ::[course-search-1](Test-Cases#course-search-1) | ::N/A |
| ::Room | <ul><li>::[room-add-1](Test-Cases#room-add-1)</li><li>::[room-add-2](Test-Cases#room-add-2)</li></ul> | ::[room-list-1](Test-Cases#room-list-1) | ::TODO | ::TODO | ::TODO | ::N/A |
| ::Instructor | ::[inst-add-1](Test-Cases#inst-add-1) | ::N/A | ::[inst-edit-1](Test-Cases#inst-edit-1) | ::[inst-delete-1](Test-Cases#inst-delete-1) | ::N/A | <ul><li>::[inst-eval-1](Test-Cases#inst-eval-1)</li><li>::[inst-eval-2](Test-Cases#inst-eval-2)</li></ul> |
| BO \ Action | ::add | ::list/browse | ::edit | ::delete | ::search | ::other |
| ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| ::Student | <ul><li>::[student-add-1](Test-Cases#student-add-1)</li><li>::[student-add-2](Test-Cases#student-add-2)</li><li>::[student-add-3](Test-Cases#student-add-3)</li></ul> | ::[student-list-1](Test-Cases#student-list-1) | <ul><li>::[student-edit-1](Test-Cases#student-edit-1)</li><li>::[student-edit-2](Test-Cases#student-edit-2)</li></ul> | ::[student-delete-1](test-casesstudent-delete-1) | <ul><li>::[student-search-1](Test-Cases#student-search-1)</li><li>::[student-search-2](Test-Cases#student-search-2)</li></ul> | ::[See grid below](#enroll-grid) |
| ::Course | <ul><li>::[course-add-1](Test-Cases#course-add-1)</li><li>::[course-add-2](Test-Cases#course-add-2)</li></ul> | ::[course-list-1](Test-Cases#course-list-1) | <ul><li>::[course-edit-1](Test-Cases#course-edit-1)</li><li>::[course-move-1](Test-Cases#course-move-1)</li><li>::[course-add-prereq-1](Test-Cases#course-add-prereq-1)</li></ul> | ::[course-cancel-1](Test-Cases#course-cancel-1) | ::[course-search-1](Test-Cases#course-search-1) | ::N/A |
| ::Room | <ul><li>::[room-add-1](Test-Cases#room-add-1)</li><li>::[room-add-2](Test-Cases#room-add-2)</li></ul> | ::[room-list-1](Test-Cases#room-list-1) | ::TODO | ::TODO | ::TODO | ::N/A |
| ::Instructor | ::[inst-add-1](Test-Cases#inst-add-1) | ::N/A | ::[inst-edit-1](Test-Cases#inst-edit-1) | ::[inst-delete-1](Test-Cases#inst-delete-1) | ::N/A | <ul><li>::[inst-eval-1](Test-Cases#inst-eval-1)</li><li>::[inst-eval-2](Test-Cases#inst-eval-2)</li></ul> |
### ::Test Cases for Enrolling in Courses
| ::Course \ Student | ::New Freshman | ::Senior | ::Any Honors | ::Other |
|--------------------|-----------------------------------------------------|-----------------------------------------------------|-----------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------|
| ------------------ | --------------------------------------------------- | --------------------------------------------------- | --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| ::In Major | [::enroll-priority-2](Test-Cases#enroll-priority-2) | [::enroll-priority-1](Test-Cases#enroll-priority-1) | [::enroll-priority-1](Test-Cases#enroll-priority-1) | <ul><li>[::enroll-1](Test-Cases#enroll-1)</li><li>[::enroll-2](Test-Cases#enroll-2)</li><li>[::enroll-3](Test-Cases#enroll-3)</li></ul> |
| ::Non-Major | [::enroll-priority-2](Test-Cases#enroll-priority-2) | [::enroll-priority-1](Test-Cases#enroll-priority-1) | [::enroll-priority-1](Test-Cases#enroll-priority-1) | <ul><li>[::enroll-1](Test-Cases#enroll-1)</li><li>[::enroll-2](Test-Cases#enroll-2)</li><li>[::enroll-3](Test-Cases#enroll-3)</li></ul> |
| ::Honors Course | [::enroll-priority-1](Test-Cases#enroll-priority-1) | [::enroll-priority-1](Test-Cases#enroll-priority-1) | [::enroll-priority-1](Test-Cases#enroll-priority-1) | [::enroll-restricted-1](Test-Cases#enroll-restricted-1) |
### Test Cases by Feature Priority
*TODO: Use this outline to make sure that high priority features are
_TODO: Use this outline to make sure that high priority features are
adequately tested. List features by priority, and then list the test
cases for each feature. If a feature needs more test cases, note that
with "TODO".*
with "TODO"._
- Essential
- ::[F-01](features#F-01):
@ -97,10 +98,10 @@ with "TODO".*
### Test Cases by Use Case Priority
*TODO: Use this outline to make sure that high priority use cases are
_TODO: Use this outline to make sure that high priority use cases are
adequately tested. List use cases by priority, and then list the test
cases for each use case. If a use case needs more test cases, note that
with "TODO".*
with "TODO"._
- Essential
- ::[UC-01](Use-Cases#UC-01)

12
Use-Case-Format.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Related Documents
- [SRS](SRS) > [Use Case Suite](Use-Case-Suite) > Use Case Format
@ -10,9 +11,9 @@ cases and gives tips on writing use cases. You can copy and paste the
sample use case into your [Use Cases](Use-Cases) document. This
file itself should not be edited to hold specific use cases.
*TODO: Use this template once in your [Use Cases](Use-Cases)
_TODO: Use this template once in your [Use Cases](Use-Cases)
document. Anything you mention here will apply to all use cases in that
file.*
file._
---
@ -31,9 +32,9 @@ file.*
**Prerequisite:**
::Project is set up
*TODO: Copy and paste this use case template as many times as needed in
_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.*
are not the same as the default for all use cases._
---
@ -74,6 +75,7 @@ are not the same as the default for all use cases.*
**Alternative Scenario Extensions:**
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
- ::If CONDITION, then ALTERNATIVE STEPS.

25
Use-Case-Suite.md
View File

@ -1,5 +1,6 @@
<!-- markdownlint-disable MD033 -->
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::[PROJECT-NAME](Home)
@ -26,22 +27,22 @@ of use cases by priority, functional area, actor, business object, or
release can help identify parts of the system that need additional use
cases.
*TODO: Before writing individual use cases, list the use cases that you
_TODO: Before writing individual use cases, list the use cases that you
think you will need. Organize them in a way that will purposely leave
visible blanks on this page if you are missing use cases. E.g., see
"Scalability and availability". Choose one or more of the organizations
show below.*
show below._
*TIP: Refer back to the user stories in your [user needs](User-Needs)
_TIP: Refer back to the user stories in your [user needs](User-Needs)
document. Use them for ideas and make sure that you cover all of them.
Remember that use cases are more precise than user stories, and there
may be several use cases for a given user story.*
may be several use cases for a given user story._
*TIP: The use case suite can be organized into nested lists according to
_TIP: The use case suite can be organized into nested lists according to
other coverage criteria, e.g., by actor. Or, it can be organized into
tables that consider two aspects at a time, e.g., business objects vs.
actor. If a certain section of the tree or table does not need use
cases, explicitly mark it "N/A". Otherwise, mark it "TODO".*
cases, explicitly mark it "N/A". Otherwise, mark it "TODO"._
### Use Cases by Functional Area
@ -140,8 +141,8 @@ more noticeable.
<!-- Hint: turn off text wrap for this large table -->
| BO \ Actor | All | ::Student | ::Instructor | ::Admin |
|--------------------------------|-----------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------|-----------------------------------------------------------------------------------------------|
| ::Student record | ::N/A | <ul><li>::[Register as new user](Use-Cases#uc-01)</li><li>::[Request new password](Use-Cases#uc-02)</li><li>::[Edit user profile](Use-Cases#uc-03)</li></ul> | ::[View user profile](Use-Cases#uc-04) | ::N/A |
| ::Course | ::[View catalog description](Use-Cases#uc-11) | <ul><li>::[Enroll in course](Use-Cases#uc-20)</li><li>::[Drop course](Use-Cases#uc-21)</li></ul> | ::TODO | <ul><li>::[Create course](Use-Cases#uc-10)</li><li>::[Assign room](Use-Cases#uc-31)</li></ul> |
| ::Room | ::[View room description](Use-Cases#uc-30) | ::N/A | ::N/A | ::[Assign room](Use-Cases#uc-31) |
| BO \ Actor | All | ::Student | ::Instructor | ::Admin |
| ---------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------- | --------------------------------------------------------------------------------------------- |
| ::Student record | ::N/A | <ul><li>::[Register as new user](Use-Cases#uc-01)</li><li>::[Request new password](Use-Cases#uc-02)</li><li>::[Edit user profile](Use-Cases#uc-03)</li></ul> | ::[View user profile](Use-Cases#uc-04) | ::N/A |
| ::Course | ::[View catalog description](Use-Cases#uc-11) | <ul><li>::[Enroll in course](Use-Cases#uc-20)</li><li>::[Drop course](Use-Cases#uc-21)</li></ul> | ::TODO | <ul><li>::[Create course](Use-Cases#uc-10)</li><li>::[Assign room](Use-Cases#uc-31)</li></ul> |
| ::Room | ::[View room description](Use-Cases#uc-30) | ::N/A | ::N/A | ::[Assign room](Use-Cases#uc-31) |

38
Use-Cases.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::PROJECT-NAME
@ -18,9 +19,9 @@
---
*TODO: Note any aspects that are common to all use cases here. This helps
_TODO: Note any aspects that are common to all use cases here. This helps
keep the use cases themselves short. If any use case is an exception,
note it's specific value to replace or add to the default.*
note it's specific value to replace or add to the default._
### Default Aspects of All Use Cases
@ -39,17 +40,17 @@ note it's specific value to replace or add to the default.*
::User is logged in
*TODO: For each use case listed in the [use case
_TODO: For each use case listed in the [use case
suite](Use-Case-Suite), create an HTML anchor and heading with it's
unique ID, then fill in the rows of the table to specify the use case in
detail.*
detail._
*TIP: It is OK to simply list the names of a lot of use cases without
_TIP: It is OK to simply list the names of a lot of use cases without
actually writing the use case in detail. Document the most important use
cases first and come back to less important ones later.*
cases first and come back to less important ones later._
*TIP: See detailed tips in the
[guidelines for writing use cases](Use-Case-Format#further-information).*
_TIP: See detailed tips in the
[guidelines for writing use cases](Use-Case-Format#further-information)._
---
@ -88,7 +89,7 @@ cases first and come back to less important ones later.*
- ::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.
provide a drop-down list of all choices, but each would need some explanation.
---
@ -390,6 +391,7 @@ cases first and come back to less important ones later.*
**Alternative Scenario Extensions:**
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
- ::If CONDITION, then ALTERNATIVE STEPS.
@ -441,6 +443,7 @@ cases first and come back to less important ones later.*
**Alternative Scenario Extensions:**
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
- ::If CONDITION, then ALTERNATIVE STEPS.
@ -492,6 +495,7 @@ cases first and come back to less important ones later.*
**Alternative Scenario Extensions:**
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
- ::If CONDITION, then ALTERNATIVE STEPS.
@ -543,6 +547,7 @@ cases first and come back to less important ones later.*
**Alternative Scenario Extensions:**
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
- ::If CONDITION, then ALTERNATIVE STEPS.
@ -594,6 +599,7 @@ cases first and come back to less important ones later.*
**Alternative Scenario Extensions:**
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
- ::If CONDITION, then ALTERNATIVE STEPS.
@ -645,6 +651,7 @@ cases first and come back to less important ones later.*
**Alternative Scenario Extensions:**
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
- ::If CONDITION, then ALTERNATIVE STEPS.
@ -696,6 +703,7 @@ cases first and come back to less important ones later.*
**Alternative Scenario Extensions:**
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
- ::If CONDITION, then ALTERNATIVE STEPS.
@ -747,6 +755,7 @@ cases first and come back to less important ones later.*
**Alternative Scenario Extensions:**
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
- ::If CONDITION, then ALTERNATIVE STEPS.
@ -798,6 +807,7 @@ cases first and come back to less important ones later.*
**Alternative Scenario Extensions:**
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
- ::If CONDITION, then ALTERNATIVE STEPS.
@ -849,6 +859,7 @@ cases first and come back to less important ones later.*
**Alternative Scenario Extensions:**
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
- ::If CONDITION, then ALTERNATIVE STEPS.
@ -900,6 +911,7 @@ cases first and come back to less important ones later.*
**Alternative Scenario Extensions:**
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
- ::If CONDITION, then ALTERNATIVE STEPS.
@ -951,6 +963,7 @@ cases first and come back to less important ones later.*
**Alternative Scenario Extensions:**
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
- ::If CONDITION, then ALTERNATIVE STEPS.
@ -1002,6 +1015,7 @@ cases first and come back to less important ones later.*
**Alternative Scenario Extensions:**
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
- ::If CONDITION, then ALTERNATIVE STEPS.
@ -1053,6 +1067,7 @@ cases first and come back to less important ones later.*
**Alternative Scenario Extensions:**
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
- ::If CONDITION, then ALTERNATIVE STEPS.
@ -1104,6 +1119,7 @@ cases first and come back to less important ones later.*
**Alternative Scenario Extensions:**
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
- ::If CONDITION, then ALTERNATIVE STEPS.
@ -1155,6 +1171,7 @@ cases first and come back to less important ones later.*
**Alternative Scenario Extensions:**
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
- ::If CONDITION, then ALTERNATIVE STEPS.
@ -1206,6 +1223,7 @@ cases first and come back to less important ones later.*
**Alternative Scenario Extensions:**
- ::If CONDITION, then ALTERNATIVE STEPS.
- ::NOTES or DETAILS.
- ::If CONDITION, then ALTERNATIVE STEPS.

13
User-Guide.md
View File

@ -1,7 +1,8 @@
<!-- markdownlint-disable-next-line MD041 -->
*TODO: Fill in information on this product. Make sure to use the
<!-- markdownlint-disable-next-line first-line-h1 -->
_TODO: Fill in information on this product. Make sure to use the
**product** name and **external** release number, not internal
information.*
information._
##### Product
@ -25,11 +26,11 @@ us at <support@COMPANY.com>
### Table of Contents
*TODO: Fill in the user guide outline below.*
_TODO: Fill in the user guide outline below._
*TIP: Consider providing both tutorial (step-by-step) and reference
_TIP: Consider providing both tutorial (step-by-step) and reference
material. You can organize the user guide by features, by use cases, by
roles, or in other ways.*
roles, or in other ways._
1. Introduction
- ::What is PRODUCT-NAME?

51
User-Needs.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
##### Project
::[PROJECT-NAME](Home)
@ -17,20 +18,20 @@
**Process impact:** The statement of user needs documents and explains
the actual desires of stakeholders in roughly their own words. What they
*desire* is never exactly what the product *provides*. Documenting user
_desire_ is never exactly what the product _provides_. Documenting user
needs here, independently from the [SRS](SRS), helps to keep the
SRS precise and makes the tasks of verification and validation more
effective. This document is *not* an informal draft of the SRS, it is
effective. This document is _not_ an informal draft of the SRS, it is
different document with a complementary purpose.
### Agreed Goals
*TODO: Has there been a clear statement of the overall goal of this
_TODO: Has there been a clear statement of the overall goal of this
project that the stakeholders agree to? If so, paste it here or add a
hyperlink. If not, you should summarize your understanding of the
project goals into a brief statement and try to get the stakeholders to
agree to it. The text below gives three alternative examples, select
one, or write your own.*
one, or write your own._
::We were given an [initial project description](LINK) that is agreed to
by all stakeholders.
@ -44,10 +45,10 @@ will be hyper-linked from here.
### Environment
*TODO: Briefly describe various aspects of the environment where the
_TODO: Briefly describe various aspects of the environment where the
software will be used. Describe the environment as it \*is\* or \*will be\*,
not what you would wish it to become. The text below gives a few
examples.*
examples._
#### What is the system's business environment?
@ -70,10 +71,10 @@ co-located data center with 24x7 monitoring, UPS,
air-conditioning, etc. Users of this system are typically at
their offices.
:: This application runs on hand-held devices that will often be used
while the user is walking from one section of the warehouse
to another. Lighting is good in that environment, but there are many
noises and distractions.
:: This application runs on hand-held devices that will often be used
while the user is walking from one section of the warehouse
to another. Lighting is good in that environment, but there are many
noises and distractions.
#### What is the system's technology environment (hardware and software)?
@ -87,25 +88,25 @@ monitors or laptops with 1024x768 resolution are also common.
### Stakeholders / Actors
*TODO: List and describe the stakeholders for this product. These can be
_TODO: List and describe the stakeholders for this product. These can be
named individuals or roles that people play. For each stakeholder,
list/rank their key needs. Consider the expected technical expertise of
the stakeholders and how often they are likely to use the system, as
well as key strengths, weaknesses, preferences, or other
characteristics. Use a greater-than sign to indicate inheritance among
types of actors.*
types of actors._
*TIP: To get information on types of users, you can talk to actual users.
_TIP: To get information on types of users, you can talk to actual users.
You may also want to talk to user surrogates (people who work with
users), such as domain experts, technical trainers, technical support
staff, technical writers, supervisors of users, and your own sales and
marketing department. You can find clues in manuals and marketing
materials for competing products.*
materials for competing products._
#### ::All
:: All stakeholders share the following key needs:
:: All stakeholders share the following key needs:
1. ::Security against abuses by other site visitors
2. ::Convenient access to the site any time over the Internet
@ -120,7 +121,7 @@ users and have high expectations for the functionality and quality
of the site, but they may not have much knowledge of
computer science.
:: Key needs:
:: Key needs:
1. ::Easily find information about clans
2. ::Keep in touch with members of his/her own clan
@ -148,16 +149,16 @@ more of the game details, now the need to see the "big picture".
::PARAGRAPH
#### ::STAKEHOLDER3
::PARAGRAPH
### Notes from Interviews and Brainstorming
*TODO: Keep a log of your requirements gathering. Paste in notes from any
_TODO: Keep a log of your requirements gathering. Paste in notes from any
face-to-face or telephone conversations with stakeholders or from
brainstorming sessions with members of the development team. If the
communication took place via email, link to it in the archive or paste
it here.*
it here._
#### ::DATE, INTERVIEWEE
@ -181,13 +182,13 @@ it here.*
### User Stories
*TODO: Write brief user stories to explain how various actors would
_TODO: Write brief user stories to explain how various actors would
interact with the system (directly and indirectly) to accomplish a
real-world goal. User stories are \*not\* use cases: user stories are
brief (3-5 sentences) paragraphs that describe one specific scenario in
concrete terms. In this description of user needs, do not make
assumptions about details of the system, instead focus on the users.
Note the source of each user story.*
Note the source of each user story._
#### ::invited-to-join
@ -219,9 +220,9 @@ clan website to find that information. (Source: PERSON-NAME)
### Performance and Capacity Needs
*TODO: Briefly list the stakeholders' desired values for various aspects
_TODO: Briefly list the stakeholders' desired values for various aspects
of the system capacity. If you have a good idea about averages or rates
of increase, note that as well.*
of increase, note that as well._
::By the end of the first year of service, we should to reach the
following system capacity:

3
Workflows.md
View File

@ -1,4 +1,5 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
### By Activity
1. Project Planning

2
_Footer.md
View File

@ -1,4 +1,4 @@
<!-- markdownlint-disable-next-line MD041 -->
<!-- markdownlint-disable-next-line first-line-h1 -->
**TODO:** Check for [words of wisdom](Words-of-Wisdom) for additional advice on this template.
::**Your-Organization Proprietary**

12
_Sidebar.md
View File

@ -1,6 +1,6 @@
<!-- markdownlint-disable-next-line MD041 -->
* [Home](Home)
* [Summary](Summary)
* [Project Plan](Project-Plan)
* [Workflows](Workflows)
* [Words of Wisdom](Words-of-Wisdom)
<!-- markdownlint-disable-next-line first-line-h1 -->
- [Home](Home)
- [Summary](Summary)
- [Project Plan](Project-Plan)
- [Workflows](Workflows)
- [Words of Wisdom](Words-of-Wisdom)