fix GFM links
This commit is contained in:
William Sandner
parent
b9a83ae836
commit
154f9e132a
@ -5,9 +5,9 @@
|
||||
::X.Y.Z
|
||||
|
||||
##### Related Documents:
|
||||
- [Software Requirements Specification](srs.html)
|
||||
- [Design](design.html) > [Security Worksheet](design-security.html)
|
||||
- [Glossary](glossary.html)
|
||||
- [Software Requirements Specification](SRS)
|
||||
- [Design](Design) > [Security Worksheet](Design-Security)
|
||||
- [Glossary](Glossary)
|
||||
- ::LINKS TO RELEVANT STANDARDS
|
||||
- ::LINKS TO OTHER DOCUMENTS
|
||||
---
|
||||
@ -35,9 +35,9 @@ architecture. Some example text is provided.*
|
||||
|
||||
#### What are the ranked goals of this architecture?
|
||||
|
||||
1. ::[Ease of integration](glossary-std.html#ease_of_integration)
|
||||
2. ::[Extensibility](glossary-std.html#extensibility)
|
||||
3. ::[Capacity matching](glossary-std.html#capacity_matching)
|
||||
1. ::[Ease of integration](Glossary-Std#ease_of_integration)
|
||||
2. ::[Extensibility](Glossary-Std#extensibility)
|
||||
3. ::[Capacity matching](Glossary-Std#capacity_matching)
|
||||
|
||||
### Components
|
||||
|
||||
@ -49,11 +49,11 @@ architecture. Some example text is provided.*
|
||||
::The components of this system are listed below by type:
|
||||
|
||||
- ::Presentation/UI Components
|
||||
- ::[C-00: COMPONENTNAME](design-components.html#c-00)
|
||||
- ::[C-00: COMPONENTNAME](Design-Components#c-00)
|
||||
- ::Application Logic Components
|
||||
- ::[C-10: COMPONENTNAME](design-components.html#c-10)
|
||||
- ::[C-10: COMPONENTNAME](Design-Components#c-10)
|
||||
- ::Data Storage Components
|
||||
- ::[C-20: COMPONENTNAME](design-components.html#c-20)
|
||||
- ::[C-20: COMPONENTNAME](Design-Components#c-20)
|
||||
|
||||
### Deployment
|
||||
|
||||
@ -67,25 +67,25 @@ defined below:
|
||||
|
||||
- ::All-in-one server
|
||||
- ::Tomcat process
|
||||
- ::[C-00: Tomcat web server](design-components.html#c-00)
|
||||
- ::[C-00: Tomcat web server](Design-Components#c-00)
|
||||
- ::[C-10: PROJECTNAME
|
||||
application](design-components.html#c-10)
|
||||
application](Design-Components#c-10)
|
||||
- ::Database process
|
||||
- ::[C-20: COMPONENTNAME](design-components.html#c-30)
|
||||
- ::[C-20: COMPONENTNAME](Design-Components#c-30)
|
||||
|
||||
::The deployment of components to processes and machines is clearly
|
||||
defined below:
|
||||
|
||||
- ::Load-balanced front-end servers
|
||||
- ::[C-01: COMPONENTNAME](design-components.html#c-00)
|
||||
- ::[C-01: COMPONENTNAME](Design-Components#c-00)
|
||||
- ::Back-end server
|
||||
- ::JVM process
|
||||
- ::[C-00: COMPONENTNAME](design-components.html#c-00)
|
||||
- ::[C-10: COMPONENTNAME](design-components.html#c-10)
|
||||
- ::[C-11: PLUG-IN COMPONENTNAME](design-components.html#c-11)
|
||||
- ::[C-12: PLUG-IN COMPONENTNAME](design-components.html#c-12)
|
||||
- ::[C-00: COMPONENTNAME](Design-Components#c-00)
|
||||
- ::[C-10: COMPONENTNAME](Design-Components#c-10)
|
||||
- ::[C-11: PLUG-IN COMPONENTNAME](Design-Components#c-11)
|
||||
- ::[C-12: PLUG-IN COMPONENTNAME](Design-Components#c-12)
|
||||
- Database process
|
||||
- ::[C-20: COMPONENTNAME](design-components.html#c-30)
|
||||
- ::[C-20: COMPONENTNAME](Design-Components#c-30)
|
||||
|
||||
#### What aspects/resources of their environment are shared?
|
||||
|
||||
|
||||
@ -19,7 +19,7 @@
|
||||
<xmp theme="readable" style="display:none;">
|
||||
<!-- Markdown content here -->
|
||||
|
||||
# [Design](design.html) > [Architecture](design-architecture.html) > Components
|
||||
# [Design](Design)> [Architecture](design-architecture.html) > Components
|
||||
---
|
||||
|
||||
##### Project:
|
||||
|
||||
@ -19,7 +19,7 @@
|
||||
<xmp theme="readable" style="display:none;">
|
||||
<!-- Markdown content here -->
|
||||
|
||||
# [Design](design.html) > Persistence
|
||||
# [Design](Design) > Persistence
|
||||
---
|
||||
|
||||
##### Project:
|
||||
@ -44,13 +44,13 @@ features. Some example text is provided. Add or delete text as needed.*
|
||||
|
||||
#### What are the ranked goals for persistence in this system?
|
||||
|
||||
1. ::[Expressiveness](glossary-std.html#dg_expressiveness)
|
||||
2. ::[Ease of access](glossary-std.html#dg_easy_access)
|
||||
3. ::[Reliability](glossary-std.html#dg_data_reliability)
|
||||
4. ::[Data capacity](glossary-std.html#dg_data_capacity)
|
||||
5. ::[Data security](glossary-std.html#dg_data_security)
|
||||
6. ::[Performance](glossary-std.html#dg_data_performance)
|
||||
7. ::[Interoperability](glossary-std.html#dg_data_interop)
|
||||
1. ::[Expressiveness](Glossary-Std#dg_expressiveness)
|
||||
2. ::[Ease of access](Glossary-Std#dg_easy_access)
|
||||
3. ::[Reliability](Glossary-Std#dg_data_reliability)
|
||||
4. ::[Data capacity](Glossary-Std#dg_data_capacity)
|
||||
5. ::[Data security](Glossary-Std#dg_data_security)
|
||||
6. ::[Performance](Glossary-Std#dg_data_performance)
|
||||
7. ::[Interoperability](Glossary-Std#dg_data_interop)
|
||||
|
||||
### Central Database
|
||||
|
||||
@ -107,7 +107,7 @@ protect against data corruption that could be caused by
|
||||
other applications.
|
||||
|
||||
### File Storage
|
||||
|
||||
|
||||
#### What data needs to be stored in files?
|
||||
|
||||
::Nothing is stored in files, everything is in the database.
|
||||
@ -153,7 +153,7 @@ user "archdaemon".
|
||||
::A custom binary file in the following format: ...
|
||||
|
||||
### Distributed Storage
|
||||
|
||||
|
||||
#### What information (if any) will be stored on client machines? For how long?
|
||||
|
||||
::A cookie will be stored on the user machine for the purpose of
|
||||
@ -173,7 +173,7 @@ kept indefinitely.
|
||||
::All the user data will be stored on files on their computers.
|
||||
|
||||
### Persistence Mechanisms Checklist
|
||||
|
||||
|
||||
|
||||
#### Expressiveness: To what extent has this been achieved?
|
||||
|
||||
|
||||
@ -19,7 +19,7 @@
|
||||
<xmp theme="readable" style="display:none;">
|
||||
<!-- Markdown content here -->
|
||||
|
||||
# [Design](design.html) > Scalability
|
||||
# [Design](Design) > Scalability
|
||||
---
|
||||
|
||||
##### Project:
|
||||
@ -50,7 +50,7 @@ scalability goals for this design.*
|
||||
| ::game\_pieces | ::Number of game pieces on the playing area at a given time. |
|
||||
|
||||
### Scalability Mechanisms
|
||||
|
||||
|
||||
|
||||
### Performance Goals and Estimates
|
||||
|
||||
|
||||
@ -19,7 +19,7 @@
|
||||
<xmp theme="readable" style="display:none;">
|
||||
<!-- Markdown content here -->
|
||||
|
||||
# [Design](design.html) > Security
|
||||
# [Design](Design) > Security
|
||||
---
|
||||
|
||||
##### Project:
|
||||
@ -44,13 +44,13 @@ features. Some example text is provided. Add or delete text as needed.*
|
||||
|
||||
#### What are the ranked goals for security in this system?
|
||||
|
||||
1. ::[Data security](glossary-std.html#data_security)
|
||||
2. ::[Intrusion prevention](glossary-std.html#intrusion_prevention)
|
||||
3. ::[Abuse prevention](glossary-std.html#abuse_prevention)
|
||||
4. ::[Auditability](glossary-std.html#auditability)
|
||||
1. ::[Data security](Glossary-Std#data_security)
|
||||
2. ::[Intrusion prevention](Glossary-Std#intrusion_prevention)
|
||||
3. ::[Abuse prevention](Glossary-Std#abuse_prevention)
|
||||
4. ::[Auditability](Glossary-Std#auditability)
|
||||
|
||||
### Security Mechanisms
|
||||
|
||||
|
||||
|
||||
#### What physical security mechanisms will be used?
|
||||
|
||||
@ -153,7 +153,7 @@ features. Some example text is provided. Add or delete text as needed.*
|
||||
be supported.
|
||||
|
||||
### Security Checklist
|
||||
|
||||
|
||||
|
||||
#### Protection of data: To what extent has this been achieved?
|
||||
|
||||
|
||||
@ -19,7 +19,7 @@
|
||||
<xmp theme="readable" style="display:none;">
|
||||
<!-- Markdown content here -->
|
||||
|
||||
# [Design](design.html) > Source Code Organization and Build System
|
||||
# [Design](Design) > Source Code Organization and Build System
|
||||
---
|
||||
|
||||
##### Project:
|
||||
|
||||
24
Design-UI.md
24
Design-UI.md
@ -19,7 +19,7 @@
|
||||
<xmp theme="readable" style="display:none;">
|
||||
<!-- Markdown content here -->
|
||||
|
||||
# [Design](design.html) > User Interface
|
||||
# [Design](Design) > User Interface
|
||||
---
|
||||
|
||||
##### Project:
|
||||
@ -45,13 +45,13 @@ text as needed.*
|
||||
|
||||
#### What are the ranked goals for the user interface of this system?
|
||||
|
||||
1. ::[Understandability and learnability](glossary-std.html#understandability_and_learnability)
|
||||
2. ::[Task support and efficiency](glossary-std.html#task_support_and_efficiency)
|
||||
3. ::[Safety](glossary-std.html#safety)
|
||||
4. ::[Consistency and familiarity](glossary-std.html#consistency_and_familiarity)
|
||||
1. ::[Understandability and learnability](Glossary-Std#understandability_and_learnability)
|
||||
2. ::[Task support and efficiency](Glossary-Std#task_support_and_efficiency)
|
||||
3. ::[Safety](Glossary-Std#safety)
|
||||
4. ::[Consistency and familiarity](Glossary-Std#consistency_and_familiarity)
|
||||
|
||||
### Metaphors, Exemplars, and Standards
|
||||
|
||||
|
||||
|
||||
#### What is the central metaphor of this UI design?
|
||||
|
||||
@ -73,7 +73,7 @@ text as needed.*
|
||||
- ::[W3C Accessibility guidelines](http://www.w3.org/TR/WCAG10/)
|
||||
|
||||
### Task Models
|
||||
|
||||
|
||||
|
||||
#### What types of users will use this system?
|
||||
|
||||
@ -141,7 +141,7 @@ many components can also be hard to use.*
|
||||
| ::--ABSTRACT-COMPONENT-NAME | ::PURPOSE | ::CONTENTS |
|
||||
|
||||
### Technical Constraints / Operational Context
|
||||
|
||||
|
||||
|
||||
#### What are your assumptions about the output devices?
|
||||
|
||||
@ -181,7 +181,7 @@ four menu buttons along the right-hand edge of the screen.
|
||||
may add or remove questions to fit your project.*
|
||||
|
||||
#### Understandability and learnability
|
||||
|
||||
|
||||
|
||||
##### Are there any labels of icons that are likely to be misunderstood?
|
||||
|
||||
@ -199,7 +199,7 @@ may add or remove questions to fit your project.*
|
||||
::1-3 SENTENCES
|
||||
|
||||
#### Task Support and Efficiency
|
||||
|
||||
|
||||
|
||||
##### Which use cases force the user to work through more than two interaction contexts?
|
||||
|
||||
@ -210,14 +210,14 @@ may add or remove questions to fit your project.*
|
||||
::1-3 SENTENCES
|
||||
|
||||
#### Safety
|
||||
|
||||
|
||||
|
||||
##### Are there any dangerous or irreversible actions that are done with only one step?
|
||||
|
||||
::1-3 SENTENCES
|
||||
|
||||
#### Consistency and Familiarity
|
||||
|
||||
|
||||
##### Do UI elements in your system work the same as they do in the existing example systems you identified?
|
||||
|
||||
::1-3 SENTENCES
|
||||
|
||||
24
Design.md
24
Design.md
@ -34,18 +34,18 @@
|
||||
<!-- - Design > [Scalability Worksheet](design-scalability.html) -->
|
||||
- Design > [User Interface Worksheet](design-ui.html)
|
||||
- Design > [Persistent Storage Worksheet](design-persistence.html)
|
||||
- Design > [Security Worksheet](design-security.html)
|
||||
- Design > [Security Worksheet](Design-Security)
|
||||
|
||||
##### Related Documents:
|
||||
- [SRS](srs) > [Use case suite](use-case-suite.html)
|
||||
- [SRS](srs) > [Feature set](feature-set.html)
|
||||
- [Glossary](glossary.html)
|
||||
- [Glossary](Glossary)
|
||||
- ::LINKS TO RELEVANT STANDARDS
|
||||
- ::LINKS TO OTHER DOCUMENTS
|
||||
---
|
||||
|
||||
**Process impact:** This design document describes a system that will
|
||||
satisfy the requirements of the [SRS](srs.html). Decisions made in
|
||||
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
|
||||
@ -55,7 +55,7 @@ begin.
|
||||
your project.*
|
||||
|
||||
### Introduction
|
||||
|
||||
|
||||
#### How is this design document organized?
|
||||
This main page describes the system design in terms of packages,
|
||||
classes, relationships, and behavior. Several attached worksheets
|
||||
@ -66,14 +66,14 @@ interface and database design.
|
||||
::PARAGRAPH or BULLETS
|
||||
|
||||
#### What are the prioritized goals of this design?
|
||||
1. ::[Correctness](glossary-std.html#dg_correctness)
|
||||
2. ::[Feasibility](glossary-std.html#dg_feasibility)
|
||||
3. ::[Understandability](glossary-std.html#dg_understandability)
|
||||
4. ::[Implementation phase guidance](glossary-std.html#dg_guidance)
|
||||
5. ::[Modularity](glossary-std.html#dg_modularity)
|
||||
6. ::[Extensibility](glossary-std.html#dg_extensibility)
|
||||
7. ::[Testability](glossary-std.html#dg_testability)
|
||||
8. ::[Efficiency](glossary-std.html#dg_efficiency)
|
||||
1. ::[Correctness](Glossary-Std#dg_correctness)
|
||||
2. ::[Feasibility](Glossary-Std#dg_feasibility)
|
||||
3. ::[Understandability](Glossary-Std#dg_understandability)
|
||||
4. ::[Implementation phase guidance](Glossary-Std#dg_guidance)
|
||||
5. ::[Modularity](Glossary-Std#dg_modularity)
|
||||
6. ::[Extensibility](Glossary-Std#dg_extensibility)
|
||||
7. ::[Testability](Glossary-Std#dg_testability)
|
||||
8. ::[Efficiency](Glossary-Std#dg_efficiency)
|
||||
|
||||
### UML Structural Design
|
||||
|
||||
|
||||
16
FAQ.md
16
FAQ.md
@ -31,16 +31,16 @@ types of stakeholders such as potential customers, open source
|
||||
contributors, members of a developers' network, or administrators.*
|
||||
|
||||
### General Information
|
||||
|
||||
|
||||
#### What is ::PRODUCTNAME?
|
||||
::It is a XXXXX. Read our [PRODUCTNAME overview](http://www.COMPANY.com/products/PRODUCTNAME/).
|
||||
|
||||
#### Who should use ::PRODUCTNAME?
|
||||
::Anyone who wants XXXXXXX. Read more about our [target audience and
|
||||
benefits](target-and-benefits.html).
|
||||
benefits](Target-and-Benefits).
|
||||
|
||||
### Download and Install
|
||||
|
||||
|
||||
#### How can I obtain ::PRODUCTNAME?
|
||||
::You may [download PRODUCTNAME](LINK-TO-DOWNLOAD).
|
||||
|
||||
@ -62,10 +62,10 @@ OSX, Linux.
|
||||
::[Installation instructions](install.html) are available on-line.
|
||||
|
||||
### Getting Started
|
||||
|
||||
|
||||
#### What is ::TECHNICAL-TERM?
|
||||
::It means XXXXX. For additional technical terms, see the
|
||||
[glossary](glossary.html).
|
||||
[glossary](Glossary).
|
||||
|
||||
#### What is ::GUI-ELEMENT?
|
||||
::It is a XXXXX. It is used for YYYYY.
|
||||
@ -78,7 +78,7 @@ OSX, Linux.
|
||||
3. ::Step three
|
||||
|
||||
### SECTION NAME
|
||||
|
||||
|
||||
|
||||
#### ::QUESTION?
|
||||
::ANSWER.
|
||||
@ -93,7 +93,7 @@ OSX, Linux.
|
||||
::ANSWER.
|
||||
|
||||
### Troubleshooting
|
||||
|
||||
|
||||
#### ::I see an error message "ERROR-MESSAGE". What's wrong?
|
||||
::ANSWER.
|
||||
|
||||
@ -101,7 +101,7 @@ OSX, Linux.
|
||||
::ANSWER.
|
||||
|
||||
### Other Questions
|
||||
|
||||
|
||||
|
||||
#### ::My question is not on this page. How do I find the answer?
|
||||
:: First read the [user guide](user-guide) and other
|
||||
|
||||
@ -19,7 +19,7 @@
|
||||
<xmp theme="readable" style="display:none;">
|
||||
<!-- Markdown content here -->
|
||||
|
||||
# [SRS](srs.html) > [Feature Set](feature-set.html) > Feature Specification Format
|
||||
# [SRS](SRS) > [Feature Set](feature-set.html) > Feature Specification Format
|
||||
---
|
||||
|
||||
**Process impact:** This reference page documents the format of feature
|
||||
|
||||
@ -19,7 +19,7 @@
|
||||
<xmp theme="readable" style="display:none;">
|
||||
<!-- Markdown content here -->
|
||||
|
||||
# [SRS](srs.html) > Feature Set
|
||||
# [SRS](SRS) > Feature Set
|
||||
---
|
||||
|
||||
##### Project:
|
||||
@ -30,7 +30,7 @@
|
||||
|
||||
##### Related Documents:
|
||||
- [Project proposal](proposal.html) > [User needs](user-needs.html)
|
||||
- [SRS](srs.html) > [Use case suite](use-case-suite.html)
|
||||
- [SRS](SRS) > [Use case suite](use-case-suite.html)
|
||||
- [Feature format](feature-format.html)
|
||||
- ::LINK TO USE CASE DIAGRAM
|
||||
- ::LINKS TO RELEVANT STANDARDSuser-needs
|
||||
|
||||
@ -19,7 +19,7 @@
|
||||
<xmp theme="readable" style="display:none;">
|
||||
<!-- Markdown content here -->
|
||||
|
||||
# [SRS](srs.html) > [Feature Set](feature-set.html) > Features
|
||||
# [SRS](SRS) > [Feature Set](feature-set.html) > Features
|
||||
---
|
||||
|
||||
##### Project:
|
||||
|
||||
@ -40,7 +40,7 @@ Jump to: [General](#general_terms) |
|
||||
|
||||
|
||||
### General Terms
|
||||
|
||||
|
||||
##### 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
|
||||
@ -97,7 +97,7 @@ After you have done what the sticky note says, you can delete the
|
||||
sticky note.
|
||||
|
||||
### Computer Science and Technology Terms
|
||||
|
||||
|
||||
|
||||
##### ::API (Application Programming Interface)
|
||||
An API is a set of functions that one software component makes
|
||||
@ -112,7 +112,7 @@ 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
|
||||
|
||||
|
||||
|
||||
##### Change Control Board (CCB)
|
||||
A group of people who review proposed changes to the project
|
||||
@ -162,7 +162,7 @@ The term "release number" by itself refers to an
|
||||
of the existence of any internal release numbers.
|
||||
|
||||
### Development Tool Terms
|
||||
|
||||
|
||||
#### Version Control System
|
||||
::DEFINITION1
|
||||
|
||||
@ -191,7 +191,7 @@ of the existence of any internal release numbers.
|
||||
::DEFINITION1
|
||||
|
||||
### Requirements Terms
|
||||
|
||||
|
||||
#### Feature specification
|
||||
A feature specification focuses on one feature of a software product
|
||||
and completely describes how that feature can be used. It includes a
|
||||
@ -211,12 +211,12 @@ show how the actor uses several features to accomplish a goal.
|
||||
A user or an external system that uses the system being built.
|
||||
|
||||
### Design Terms
|
||||
|
||||
|
||||
#### ::TERM2
|
||||
::DEFINITION2
|
||||
|
||||
### Design Goals Terms
|
||||
|
||||
|
||||
#### Correctness
|
||||
This design correctly matches the given requirements.
|
||||
|
||||
@ -306,7 +306,7 @@ Users can apply their knowledge of similar UIs or UI standards to
|
||||
this system.
|
||||
|
||||
### QA Terms
|
||||
|
||||
|
||||
#### Bug
|
||||
*n.* **Deprecated** since 1991. See [defect](#defect).
|
||||
|
||||
@ -337,7 +337,7 @@ reported in a defect report. Developers use failure evidence during
|
||||
debugging to eventually find and remove [defects](#defect).
|
||||
|
||||
### QA Goals Terms
|
||||
|
||||
|
||||
#### Functionality > Correctness
|
||||
Correctness is the most basic quality goal. It means that, when
|
||||
valid inputs are given and the system is in a valid state and under
|
||||
|
||||
22
Glossary.md
22
Glossary.md
@ -32,7 +32,7 @@ Jump to: [A](#a) | [B](#b) | [C](#c) | [D](#d) | [E](#e) | [F](#f) |
|
||||
[G](#g) | [H](#g) | [I](#i) | [J](#j) | [K](#k) | [L](#l) | [M](#m) |
|
||||
[N](#n) | [O](#o) | [P](#p) | [Q](#q) | [R](#r) | [S](#s) | [T](#t) |
|
||||
[U](#u) | [V](#v) | [W](#w) | [X](#x) | [Y](#y) | [Z](#z) |
|
||||
[Standard terms](glossary-std.html#standard_terms)
|
||||
[Standard terms](Glossary-Std#standard_terms)
|
||||
|
||||
### Project-specific Terms
|
||||
|
||||
@ -47,7 +47,7 @@ Jump to: [A](#a) | [B](#b) | [C](#c) | [D](#d) | [E](#e) | [F](#f) |
|
||||
- *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).*
|
||||
[bug](Glossary-Std#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.*
|
||||
@ -57,13 +57,13 @@ Jump to: [A](#a) | [B](#b) | [C](#c) | [D](#d) | [E](#e) | [F](#f) |
|
||||
[GPA](#gpa).*
|
||||
|
||||
#### A
|
||||
|
||||
|
||||
|
||||
#### B
|
||||
|
||||
|
||||
|
||||
#### C
|
||||
|
||||
|
||||
##### ::Class standing
|
||||
|
||||
- ::Computed attribute of [student](#student) based on number of
|
||||
@ -79,10 +79,10 @@ Jump to: [A](#a) | [B](#b) | [C](#c) | [D](#d) | [E](#e) | [F](#f) |
|
||||
| ::Senior | ::More than 270 units completed |
|
||||
|
||||
#### D
|
||||
|
||||
|
||||
|
||||
#### G
|
||||
|
||||
|
||||
##### ::GEF
|
||||
::*n.* The [Graph Editing Framework](http://gef.tigris.org/). An open
|
||||
source library for editing diagrams (boxes and arrows).
|
||||
@ -95,13 +95,13 @@ determine student ranking, and to trigger Dean's List and
|
||||
academic probation.
|
||||
|
||||
#### I
|
||||
|
||||
|
||||
##### ::ICS
|
||||
::*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,
|
||||
@ -114,7 +114,7 @@ Years\_at\_school does not determine senior standing. TODO: how many
|
||||
credits needed?
|
||||
|
||||
#### T
|
||||
|
||||
|
||||
##### ::Term1
|
||||
::Definition1
|
||||
|
||||
@ -126,7 +126,7 @@ credits needed?
|
||||
::Definition3
|
||||
|
||||
#### U
|
||||
|
||||
|
||||
##### ::Undergraduate
|
||||
::A type of [student](#student). *TODO: add more detail.*
|
||||
|
||||
|
||||
@ -29,10 +29,10 @@
|
||||
::X.Y.Z
|
||||
|
||||
##### Related Documents:
|
||||
- [Software Requirements Specification](srs.html)
|
||||
- [Software Requirements Specification](SRS)
|
||||
- [Release notes](release-notes.html)
|
||||
- [FAQ](faq.html)
|
||||
- [Glossary](glossary.html)
|
||||
- [Glossary](Glossary)
|
||||
---
|
||||
|
||||
**Process impact:** This document is a brief and fairly technical
|
||||
@ -218,7 +218,7 @@ Do these implementation notes provide enough information for operations engineer
|
||||
[operations manual](LINK-TO-OPERTIONS-MANUAL).
|
||||
- ::No, a member of the development team is available on-call whenever
|
||||
the operations team may need help. This is listed in the
|
||||
[Resource Needs](resource-needs.html) document and in the
|
||||
[Resource Needs](Resource-Needs) document and in the
|
||||
[on-call schedule](LINK-TO-ON-CALL-SCHEDULE).
|
||||
|
||||
Have these implementation notes been communicated to the operations and development teams and other stakeholders?
|
||||
@ -227,7 +227,7 @@ Have these implementation notes been communicated to the operations and developm
|
||||
- ::Yes, it has been posted to the project website.
|
||||
- ::No, some developers or operations engineers are not aware of
|
||||
this document. This is a risk that is noted in the
|
||||
[Risk Management](plan#risks.html) section of the [Project Plan](plan.html).
|
||||
[Risk Management](plan#risks.html) section of the [Project Plan](Project-Plan).
|
||||
|
||||
|
||||
<!-- End Markdown content -->
|
||||
|
||||
@ -38,9 +38,9 @@
|
||||
::LOCATION
|
||||
|
||||
##### Related Documents:
|
||||
- [Project proposal](proposal.html) > [Target audience and benefits](target-and-benefits.html)
|
||||
- [Project proposal](proposal.html) > [Target audience and benefits](Target-and-Benefits)
|
||||
- [Interview checklist](interview-checklist.html)
|
||||
- [Glossary](glossary.html)
|
||||
- [Glossary](Glossary)
|
||||
---
|
||||
|
||||
*TODO: Copy this file once for each interview. Fill in the details. Link
|
||||
@ -51,7 +51,7 @@ of user-needs.md.*
|
||||
is key to effective requirements gathering. Good requirements are needed
|
||||
to build the right system. These notes should be kept as part of the
|
||||
documentation on [user needs](user-needs.html) are referred to when the
|
||||
[software requirements specification](srs.html) is written or updated.
|
||||
[software requirements specification](SRS) is written or updated.
|
||||
|
||||
### Interview Questions and Answers
|
||||
|
||||
|
||||
6
Legal.md
6
Legal.md
@ -38,9 +38,9 @@
|
||||
::Commercial license
|
||||
|
||||
##### Related Documents:
|
||||
- [Project proposal](proposal.html) > [Target audience and benefits](target-and-benefits.html)
|
||||
- [Plan](plan) > [Resource needs](resource-needs.html)
|
||||
- [Glossary](glossary.html)
|
||||
- [Project proposal](proposal.html) > [Target audience and benefits](Target-and-Benefits)
|
||||
- [Plan](plan) > [Resource needs](Resource-Needs)
|
||||
- [Glossary](Glossary)
|
||||
---
|
||||
|
||||
**Process impact:** This document outlines legal issues that may affect
|
||||
|
||||
59
Proposal.md
59
Proposal.md
@ -1,26 +1,3 @@
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<meta charset="utf-8"/>
|
||||
<link type="image/png" href="assets/logo.png" rel="icon">
|
||||
<title>ReadySet Markdown</title>
|
||||
</head>
|
||||
<script src="https://www.w3schools.com/lib/w3data.js"></script>
|
||||
<body>
|
||||
|
||||
<topbar style="display:none;">
|
||||
<item><a href="index.html">Overview</a></item>
|
||||
<item><a href="plan.html">Project Plan</a></item>
|
||||
<item><a href="index-all.html">Workflows</a></item>
|
||||
<menu name="Themes"><item><a id="settheme"><b>Current</b></a></item></menu>
|
||||
<toc></toc>
|
||||
</topbar>
|
||||
|
||||
<xmp theme="readable" style="display:none;">
|
||||
<!-- Markdown content here -->
|
||||
|
||||
# Project Proposal
|
||||
---
|
||||
##### Project:
|
||||
::[PROJECTNAME](Home)
|
||||
|
||||
@ -31,11 +8,11 @@
|
||||
::2-4 SENTENCE SUMMARY
|
||||
|
||||
##### Attached Worksheets:
|
||||
Project Proposal > [Target audience and benefits](target-and-benefits.html)
|
||||
Project Proposal > [Target audience and benefits](Target-and-Benefits)
|
||||
|
||||
##### Related Documents:
|
||||
- [Project plan](plan.html) > [Resource needs](resource-needs.html)
|
||||
- [Glossary](glossary.html)
|
||||
- [Project plan](Project-Plan) > [Resource needs](Resource-Needs)
|
||||
- [Glossary](Glossary)
|
||||
---
|
||||
|
||||
**Process impact:** This proposal, along with drafts of related
|
||||
@ -45,7 +22,7 @@ expectations that will be used later to evaluate the success of the
|
||||
project.
|
||||
|
||||
### Background and Motivation
|
||||
|
||||
|
||||
*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?
|
||||
@ -121,7 +98,7 @@ those advantages.
|
||||
- ::[Quotes from game players](#)
|
||||
|
||||
### Goal
|
||||
|
||||
|
||||
|
||||
#### What is the goal of this project?
|
||||
|
||||
@ -197,7 +174,7 @@ plan and simplified to reduce technical detail.*
|
||||
- ::Command-line advertising configuration tool and report generator
|
||||
|
||||
### Risks and Rewards
|
||||
|
||||
|
||||
|
||||
#### What are the main risks of this project?
|
||||
|
||||
@ -213,7 +190,7 @@ plan and simplified to reduce technical detail.*
|
||||
site and web application. This will be a risk because one person
|
||||
on our team has much experience with the relevant tools
|
||||
and technologies. Although the others will learn, we will
|
||||
certainly make some mistakes and suboptimal choices. We will
|
||||
certainly make some mistakes and sub-optimal choices. We will
|
||||
address this risk by scoping the project such that we have
|
||||
enough time to train and to review the design
|
||||
and implementation.
|
||||
@ -235,24 +212,4 @@ over time.
|
||||
|
||||
### Project Plan
|
||||
|
||||
See attached draft of [project plan](plan.html) and [resource needs](resource-needs.html).
|
||||
|
||||
<!-- End Markdown content -->
|
||||
</xmp>
|
||||
|
||||
<div w3-include-html="_words-of-wisdom.html"></div>
|
||||
<div w3-include-html="_footer.html"></div>
|
||||
|
||||
<script>
|
||||
w3IncludeHTML();
|
||||
</script>
|
||||
|
||||
<script src="http://strapdownjs.com/v/0.2/strapdown.js"></script>
|
||||
<!-- Include it AFTER strapdown -->
|
||||
<script src="assets/strapdown/strapdown-topbar.min.js"></script>
|
||||
<!-- Include it AFTER EVERYTHING -->
|
||||
<script src="assets/logo.js"></script>
|
||||
<script src="assets/themeswitcher.js"></script>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
See attached draft of [project plan](Project-Plan) and [resource needs](Resource-Needs).
|
||||
|
||||
70
QA-Plan.md
70
QA-Plan.md
@ -44,9 +44,9 @@ those answers that do not apply.*
|
||||
- QA plan > [System test runs](test-run-suite.html)
|
||||
|
||||
##### Related Documents:
|
||||
- [Software Requirements Specification](srs.html)
|
||||
- [Design](design.html)
|
||||
- [Project plan](plan.html)
|
||||
- [Software Requirements Specification](SRS)
|
||||
- [Design](Design)
|
||||
- [Project plan](Project-Plan)
|
||||
- [Software development methodology](sdm.html)
|
||||
- ::LINKS TO RELEVANT STANDARDS
|
||||
- ::LINKS TO OTHER DOCUMENTS
|
||||
@ -58,7 +58,7 @@ strategies for assuring that those goals have been met, and details a
|
||||
plan of action to carry out those strategies.
|
||||
|
||||
### Introduction
|
||||
|
||||
|
||||
#### Why is this QA plan needed?
|
||||
|
||||
::"Quality" refers to all the good things that we would like to see in
|
||||
@ -118,33 +118,33 @@ activities:
|
||||
that make sense for your project on this particular release.*
|
||||
|
||||
- ::Essential
|
||||
- [Functionality > Correctness](glossary-std.html#functionality_gt_correctness)
|
||||
- [Functionality > Robustness](glossary-std.html#functionality_gt_robustness)
|
||||
- [Functionality > Correctness](Glossary-Std#functionality_gt_correctness)
|
||||
- [Functionality > Robustness](Glossary-Std#functionality_gt_robustness)
|
||||
- ::Expected
|
||||
- [Functionality > Accuracy](glossary-std.html#functionality_gt_accuracy)
|
||||
- [Functionality > Compatibility](glossary-std.html#functionality_gt_compatibility)
|
||||
- [Functionality > Factual correctness](glossary-std.html#functionality_gt_factual_correctness)
|
||||
- [Usability > Understandability and Readability](glossary-std.html#usability_gt_understandability_and_readability)
|
||||
- [Usability > Learnability and Memorability](glossary-std.html#usability_gt_learnability_and_memorability)
|
||||
- [Usability > Task support](glossary-std.html#usability_gt_task_support)
|
||||
- [Usability > Efficiency](glossary-std.html#usability_gt_efficiency)
|
||||
- [Usability > Safety](glossary-std.html#usability_gt_safety)
|
||||
- [Usability > Consistency and Familiarity](glossary-std.html#usability_gt_consistency_and_familiarity)
|
||||
- [Usability > Subjective satisfaction](glossary-std.html#usability_gt_subjective_satisfaction)
|
||||
- [Security](glossary-std.html#security)
|
||||
- [Functionality > Accuracy](Glossary-Std#functionality_gt_accuracy)
|
||||
- [Functionality > Compatibility](Glossary-Std#functionality_gt_compatibility)
|
||||
- [Functionality > Factual correctness](Glossary-Std#functionality_gt_factual_correctness)
|
||||
- [Usability > Understandability and Readability](Glossary-Std#usability_gt_understandability_and_readability)
|
||||
- [Usability > Learnability and Memorability](Glossary-Std#usability_gt_learnability_and_memorability)
|
||||
- [Usability > Task support](Glossary-Std#usability_gt_task_support)
|
||||
- [Usability > Efficiency](Glossary-Std#usability_gt_efficiency)
|
||||
- [Usability > Safety](Glossary-Std#usability_gt_safety)
|
||||
- [Usability > Consistency and Familiarity](Glossary-Std#usability_gt_consistency_and_familiarity)
|
||||
- [Usability > Subjective satisfaction](Glossary-Std#usability_gt_subjective_satisfaction)
|
||||
- [Security](Glossary-Std#security)
|
||||
- ::Desired
|
||||
- [Reliability > Consistency under load](glossary-std.html#reliability_gt_consistency_under_load)
|
||||
- [Reliability > Consistency under concurrency](glossary-std.html#reliability_gt_consistency_under_concurrency)
|
||||
- [Reliability > Availability under load](glossary-std.html#reliability_gt_availability_under_load)
|
||||
- [Reliability > Longevity](glossary-std.html#reliability_gt_longevity)
|
||||
- [Efficiency](glossary-std.html#efficiency)
|
||||
- [Scalability](glossary-std.html#scalability)
|
||||
- [Scalability > Performance under load](glossary-std.html#scalability_gt_performance_under_load)
|
||||
- [Scalability > Large data volume](glossary-std.html#scalability_gt_large_data_volume)
|
||||
- [Operability](glossary-std.html#operability)
|
||||
- [Maintainability > Understandability](glossary-std.html#maintainability_gt_understandability)
|
||||
- [Maintainability > Evolvability](glossary-std.html#maintainability_gt_evolvability)
|
||||
- [Maintainability > Testability](glossary-std.html#maintainability_gt_testability)
|
||||
- [Reliability > Consistency under load](Glossary-Std#reliability_gt_consistency_under_load)
|
||||
- [Reliability > Consistency under concurrency](Glossary-Std#reliability_gt_consistency_under_concurrency)
|
||||
- [Reliability > Availability under load](Glossary-Std#reliability_gt_availability_under_load)
|
||||
- [Reliability > Longevity](Glossary-Std#reliability_gt_longevity)
|
||||
- [Efficiency](Glossary-Std#efficiency)
|
||||
- [Scalability](Glossary-Std#scalability)
|
||||
- [Scalability > Performance under load](Glossary-Std#scalability_gt_performance_under_load)
|
||||
- [Scalability > Large data volume](Glossary-Std#scalability_gt_large_data_volume)
|
||||
- [Operability](Glossary-Std#operability)
|
||||
- [Maintainability > Understandability](Glossary-Std#maintainability_gt_understandability)
|
||||
- [Maintainability > Evolvability](Glossary-Std#maintainability_gt_evolvability)
|
||||
- [Maintainability > Testability](Glossary-Std#maintainability_gt_testability)
|
||||
|
||||
### QA Strategy
|
||||
|
||||
@ -277,7 +277,7 @@ and tracked to completion.*
|
||||
[SDM](sdm.html#issuetracking).
|
||||
|
||||
### QA-Plan Checklist
|
||||
|
||||
|
||||
#### 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
|
||||
@ -291,10 +291,10 @@ and tracked to completion.*
|
||||
#### Have human resources been allocated to carry out the QA activities?
|
||||
|
||||
::Yes, human resources have been allocated. They are listed in the
|
||||
[Resource Needs](resource-needs.html) document.
|
||||
[Resource Needs](Resource-Needs) document.
|
||||
|
||||
::No, human resources have not been allocated. They are listed as
|
||||
"pending" in the [Resource Needs](resource-needs.html) document.
|
||||
"pending" in the [Resource Needs](Resource-Needs) document.
|
||||
|
||||
#### Have machine and software resources been allocated as needed for the QA activities?
|
||||
|
||||
@ -302,10 +302,10 @@ and tracked to completion.*
|
||||
already allocated to them.
|
||||
|
||||
::Yes, a QA Lab has been set up. The needed machine and software
|
||||
resources are listed in the [Resource Needs](resource-needs.html) document.
|
||||
resources are listed in the [Resource Needs](Resource-Needs) document.
|
||||
|
||||
::No, needed machine and software resources are listed as pending in
|
||||
the [Resource Needs](resource-needs.html) document.
|
||||
the [Resource Needs](Resource-Needs) document.
|
||||
|
||||
#### Has this QA Plan been communicated to the development team and other stakeholders?
|
||||
|
||||
@ -318,7 +318,7 @@ is welcome.
|
||||
|
||||
::No, some developers are not aware of the quality goals and planned
|
||||
QA activities for this release. This is a risk that is noted in the
|
||||
[Risk Management](plan.html#risks) section of the [Project Plan](plan.html).
|
||||
[Risk Management](plan.html#risks) section of the [Project Plan](Project-Plan).
|
||||
|
||||
|
||||
<!-- End Markdown content -->
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
|
||||
|
||||
# [Plan](plan.html) > Resource Needs
|
||||
# [Plan](Project-Plan) > Resource Needs
|
||||
---
|
||||
|
||||
##### Project:
|
||||
@ -14,10 +14,10 @@
|
||||
|
||||
##### Related Documents:
|
||||
- [Project proposal](proposal.html)
|
||||
- [Project plan](plan.html)
|
||||
- [Project plan](Project-Plan)
|
||||
- [QA plan](qa-plan.html)
|
||||
- [Software development methodology](sdm.html)
|
||||
- [Glossary](glossary.html)
|
||||
- [Glossary](Glossary)
|
||||
---
|
||||
|
||||
**Process impact:** Based on the project plan and the worksheet below,
|
||||
|
||||
6
Risks.md
6
Risks.md
@ -29,7 +29,7 @@
|
||||
::X.Y.Z
|
||||
|
||||
##### Related Documents:
|
||||
- [Project plan](plan.html)
|
||||
- [Project plan](Project-Plan)
|
||||
- [Software development methodology](sdm.html)
|
||||
|
||||
##### References:
|
||||
@ -60,7 +60,7 @@ or medium likelihood and marginal impact.
|
||||
by customers and developers from time to time.*
|
||||
|
||||
### General contingency plans
|
||||
|
||||
|
||||
|
||||
#### Catastrophic risks
|
||||
|
||||
@ -117,7 +117,7 @@ impact of a risk has increased to make it a "major" risk.*
|
||||
| ::RISKNAME | ONE-TO-THREE-SENTENCES | Low or Medium or High | Negligible or Marginal or Critical or Catastrophic | ONE-TO-THREE-SENTENCES | Red or Amber or Green | PERSONNAME |
|
||||
|
||||
#### Possible risk status values
|
||||
|
||||
|
||||
##### Red
|
||||
Active & impacting project
|
||||
|
||||
|
||||
4
SRS.md
4
SRS.md
@ -36,7 +36,7 @@
|
||||
- [Project proposal](proposal.html) > [User needs](user-needs.html)
|
||||
- ::LINKS TO RELEVANT STANDARDS
|
||||
- ::LINKS TO OTHER DOCUMENTS
|
||||
- [Glossary](glossary.html)
|
||||
- [Glossary](Glossary)
|
||||
---
|
||||
|
||||
**Process impact:** The SRS precisely defines the software product that
|
||||
@ -246,7 +246,7 @@ Details:
|
||||
- ::DETAIL
|
||||
- ::DETAIL
|
||||
|
||||
#### What application program interfaces ([APIs](glossary-std.html#api_application_programming_interface)) must be provided?
|
||||
#### What application program interfaces ([APIs](Glossary-Std#api_application_programming_interface)) must be provided?
|
||||
|
||||
::PARAGRAPH
|
||||
|
||||
|
||||
@ -71,9 +71,9 @@ examples are given, you should select/edit only one.*
|
||||
- ::Project canceled. This is the final status report.
|
||||
|
||||
##### Related Documents:
|
||||
- [Project plan](plan.html) > [Resource needs](resource-needs.html)
|
||||
- [Project plan](Project-Plan) > [Resource needs](Resource-Needs)
|
||||
- [QA plan](qa-plan.html)
|
||||
- [Glossary](glossary.html)
|
||||
- [Glossary](Glossary)
|
||||
---
|
||||
|
||||
**Process impact:** This helps keep stakeholders informed of project
|
||||
@ -136,7 +136,7 @@ possible.*
|
||||
|
||||
### Tracking to Plan
|
||||
|
||||
*TODO: Copy the Work Breakdown Structure from the [project plan](plan.html) and paste it here.
|
||||
*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 |
|
||||
|
||||
10
Summary.md
10
Summary.md
@ -20,7 +20,7 @@ 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
|
||||
[specification](srs.html) and fixing defects.
|
||||
[specification](SRS) and fixing defects.
|
||||
|
||||
::The next major milestone is a third beta release with nearly complete
|
||||
functionality and a wider set of testers.
|
||||
@ -33,7 +33,7 @@ functionality and a wider set of testers.
|
||||
### Resources and schedule
|
||||
|
||||
*TODO: Briefly describe the project resources and schedule. This is
|
||||
condensed from the [project plan](plan.html), [resource needs](resource-needs.html),
|
||||
condensed from the [project plan](Project-Plan), [resource needs](Resource-Needs),
|
||||
and [legal issues](legal.html) documents.*
|
||||
|
||||
#### What are the deadlines for this project?
|
||||
@ -62,7 +62,7 @@ and [legal issues](legal.html) documents.*
|
||||
|
||||
*TODO: Briefly describe the most important system requirements. This is
|
||||
condensed from the [user needs](user-needs.html),
|
||||
[interview notes](interview-notes.html), [SRS](srs.html),
|
||||
[interview notes](interview-notes.html), [SRS](SRS),
|
||||
[use case suite](use-case-suite.html),
|
||||
and [feature set](feature-set.html) documents.*
|
||||
|
||||
@ -85,7 +85,7 @@ and [feature set](feature-set.html) documents.*
|
||||
### Design
|
||||
|
||||
*TODO: Briefly describe the most important aspects of the design. This is
|
||||
condensed from the [design](design.html) template and associated
|
||||
condensed from the [design](Design) template and associated
|
||||
worksheets.*
|
||||
|
||||
#### What are your ranked design goals?
|
||||
@ -186,7 +186,7 @@ Where is the user documentation?
|
||||
### Glossary
|
||||
*TODO: Define any technical terms that you use above, if a new member of
|
||||
the team would not already know them. This is condensed from the
|
||||
[glossary](glossary.html) documents.*
|
||||
[glossary](Glossary) documents.*
|
||||
|
||||
##### ::TECHNICAL TERM
|
||||
::DEFINITION
|
||||
|
||||
@ -30,7 +30,7 @@
|
||||
|
||||
##### Related Documents:
|
||||
- [Project proposal](proposal.html) > [User needs](user-needs.html)
|
||||
- [Glossary](glossary.html)
|
||||
- [Glossary](Glossary)
|
||||
---
|
||||
|
||||
**Process impact:** This document helps identify potential customers and
|
||||
|
||||
@ -42,7 +42,7 @@ degree to which the system has been tested helps to assess progress,
|
||||
assess risk, and focus ongoing testing efforts.
|
||||
|
||||
*TODO:
|
||||
- Review the [target audience](target-and-benefits.html),
|
||||
- Review the [target audience](Target-and-Benefits),
|
||||
[environmental requirements](srs.html#environmental), and [possible
|
||||
deployments](design-architecture.html#deployment) to understand the
|
||||
set of possible system configurations that could be tested.
|
||||
|
||||
@ -19,7 +19,7 @@
|
||||
<xmp theme="readable" style="display:none;">
|
||||
<!-- Markdown content here -->
|
||||
|
||||
# [SRS](srs.html) > [Use Case Suite](use-case-suite.html) > Use Case Format
|
||||
# [SRS](SRS) > [Use Case Suite](use-case-suite.html) > Use Case Format
|
||||
---
|
||||
|
||||
**Process impact:** This reference page documents the format of use
|
||||
@ -33,7 +33,7 @@ file.*
|
||||
|
||||
---
|
||||
### Aspects common to all use cases
|
||||
|
||||
|
||||
#### Direct Actors:
|
||||
- ::User: end-user in any role
|
||||
- ::System: The system being built
|
||||
|
||||
@ -19,7 +19,7 @@
|
||||
<xmp theme="readable" style="display:none;">
|
||||
<!-- Markdown content here -->
|
||||
|
||||
# [SRS](srs.html) > Use Case Suite
|
||||
# [SRS](SRS) > Use Case Suite
|
||||
---
|
||||
|
||||
##### Project:
|
||||
|
||||
@ -29,7 +29,7 @@
|
||||
::X.Y.Z
|
||||
|
||||
##### Related Documents:
|
||||
- [Project proposal](proposal.html) > [User needs](user-needs.html), [SRS](srs.html) > [Feature set](feature-set.html)
|
||||
- [Project proposal](proposal.html) > [User needs](user-needs.html), [SRS](SRS) > [Feature set](feature-set.html)
|
||||
- [Use case format](use-case-format)
|
||||
- ::LINK TO USE CASE DIAGRAM
|
||||
- ::LINKS TO RELEVANT STANDARDS
|
||||
|
||||
@ -29,15 +29,15 @@
|
||||
- User needs > [Interview notes](interview-notes.html)
|
||||
|
||||
##### Related Documents:
|
||||
- [Project proposal](proposal.html) > [Target audience and benefits](target-and-benefits.html)
|
||||
- [Software requirements specification](srs.html)
|
||||
- [Glossary](glossary.html)
|
||||
- [Project proposal](proposal.html) > [Target audience and benefits](Target-and-Benefits)
|
||||
- [Software requirements specification](SRS)
|
||||
- [Glossary](Glossary)
|
||||
---
|
||||
|
||||
**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
|
||||
needs here, independently from the [SRS](srs.html), helps to keep the
|
||||
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
|
||||
different document with a complementary purpose.
|
||||
|
||||
42
Workflows.md
42
Workflows.md
@ -2,24 +2,24 @@
|
||||
1. Project Planning
|
||||
1. [Home](Home)
|
||||
2. [Proposal](proposal.html)
|
||||
- [Target and benefits](target-and-benefits.html)
|
||||
3. [Project plan](plan.html)
|
||||
- [Resource needs](resource-needs.html)
|
||||
- [Target and benefits](Target-and-Benefits)
|
||||
3. [Project plan](Project-Plan)
|
||||
- [Resource needs](Resource-Needs)
|
||||
4. [Legal issues](legal.html)
|
||||
5. [QA Plan](qa-plan.html)
|
||||
2. Requirements and Specification
|
||||
1. [User needs](user-needs.html)
|
||||
- [Interview notes](interview-notes.html)
|
||||
2. [Software Requirements Specification](srs.html)
|
||||
2. [Software Requirements Specification](SRS)
|
||||
- [Use case suite](use-case-suite.html)
|
||||
- [Feature set](feature-set.html)
|
||||
3. Architecture and Design
|
||||
1. [Design](design.html)
|
||||
1. [Design](Design)
|
||||
- [Architecture worksheet](design-architecture.html)
|
||||
- [Source and build](design-src-org.html)
|
||||
- [User interface worksheet](design-ui.html)
|
||||
- [Persistence worksheet](design-persistence.html)
|
||||
- [Security worksheet](design-security.html)
|
||||
- [Security worksheet](Design-Security)
|
||||
4. Implementation and Testing
|
||||
1. [User guide](userguide.html)
|
||||
2. [Test suite](test-suite.html)
|
||||
@ -34,7 +34,7 @@
|
||||
1. [FAQ / Troubleshooting](faq.html)
|
||||
2. [Implementation notes](implementation-notes.html)
|
||||
7. Continuous or Final
|
||||
1. [Glossary](glossary.html)
|
||||
1. [Glossary](Glossary)
|
||||
2. [Status report](status-report.html)
|
||||
3. [Review meeting notes](review-meeting-notes.html)
|
||||
4. [Software development methodology](sdm.html)
|
||||
@ -43,24 +43,24 @@
|
||||
1. Step 1
|
||||
1. [Home](Home)
|
||||
2. [Proposal](proposal.html)
|
||||
- [](target-and-benefits.html)[Target and benefits](target-and-benefits.html)
|
||||
3. [Project plan](plan.html)
|
||||
- [Resource needs](resource-needs.html)
|
||||
- [](Target-and-Benefits)[Target and benefits](Target-and-Benefits)
|
||||
3. [Project plan](Project-Plan)
|
||||
- [Resource needs](Resource-Needs)
|
||||
4. [Legal issues](legal.html)
|
||||
5. [Glossary](glossary.html)
|
||||
5. [Glossary](Glossary)
|
||||
2. Step 2
|
||||
1. [User needs](user-needs.html)
|
||||
- [Interview notes](interview-notes.html)
|
||||
2. [Software Requirements Specification](srs.html)
|
||||
2. [Software Requirements Specification](SRS)
|
||||
- [Use case suite](use-case-suite.html)
|
||||
- [Feature set](feature-set.html)
|
||||
3. Step 3
|
||||
1. [Design](design.html)
|
||||
1. [Design](Design)
|
||||
- [Architecture worksheet](design-architecture.html)
|
||||
- [Source and build](design-src-org.html)
|
||||
- [User interface worksheet](design-ui.html)
|
||||
- [Persistence worksheet](design-persistence.html)
|
||||
- [Security worksheet](design-security.html)
|
||||
- [Security worksheet](Design-Security)
|
||||
4. Step 4
|
||||
1. [QA Plan](qa-plan.html)
|
||||
2. [Test suite](test-suite.html)
|
||||
@ -84,9 +84,9 @@
|
||||
1. [All-in-one](all-in-one.html)
|
||||
2. [Home](Home)
|
||||
3. [Proposal](proposal.html)
|
||||
- [Target and benefits](target-and-benefits.html)
|
||||
4. [Project plan](plan.html)
|
||||
- [](resource-needs.html)[Resource needs](resource-needs.html)
|
||||
- [Target and benefits](Target-and-Benefits)
|
||||
4. [Project plan](Project-Plan)
|
||||
- [](Resource-Needs)[Resource needs](Resource-Needs)
|
||||
5. [QA Plan](qa-plan.html)
|
||||
- [Test suite](test-suite.html)
|
||||
- [Test case format](test-case-format.html)
|
||||
@ -95,16 +95,16 @@
|
||||
6. [Legal issues](legal.html)
|
||||
7. [User needs](user-needs.html)
|
||||
- [Interview notes](interview-notes.html)
|
||||
8. [Software Requirements Specification](srs.html)
|
||||
8. [Software Requirements Specification](SRS)
|
||||
- [Use case suite](use-case-suite.html)
|
||||
- [Feature set](feature-set.html)
|
||||
9. [Glossary](glossary.html)
|
||||
10. [Design](design.html)
|
||||
9. [Glossary](Glossary)
|
||||
10. [Design](Design)
|
||||
- [Architecture worksheet](design-architecture.html)
|
||||
- [Source and build](design-src-org.html)
|
||||
- [User interface worksheet](design-ui.html)
|
||||
- [Persistence worksheet](design-persistence.html)
|
||||
- [Security worksheet](design-security.html)
|
||||
- [Security worksheet](Design-Security)
|
||||
11. [User guide](userguide.html)
|
||||
12. [Release checklist](release-checklist.html)
|
||||
13. [Installation / Quick start guide](install.html)
|
||||
|
||||
Loading…
Reference in New Issue
Block a user