GFM changes
This commit is contained in:
parent
49ab07b70b
commit
24b358f205
@ -35,9 +35,9 @@ architecture. Some example text is provided.*
|
|||||||
|
|
||||||
#### What are the ranked goals of this architecture?
|
#### What are the ranked goals of this architecture?
|
||||||
|
|
||||||
1. ::[Ease of integration](Glossary-Std#ease_of_integration)
|
1. ::[Ease of integration](Glossary-Standard-Terms#ease_of_integration)
|
||||||
2. ::[Extensibility](Glossary-Std#extensibility)
|
2. ::[Extensibility](Glossary-Standard-Terms#extensibility)
|
||||||
3. ::[Capacity matching](Glossary-Std#capacity_matching)
|
3. ::[Capacity matching](Glossary-Standard-Terms#capacity_matching)
|
||||||
|
|
||||||
### Components
|
### Components
|
||||||
|
|
||||||
|
@ -21,13 +21,13 @@ features. Some example text is provided. Add or delete text as needed.*
|
|||||||
|
|
||||||
#### What are the ranked goals for persistence in this system?
|
#### What are the ranked goals for persistence in this system?
|
||||||
|
|
||||||
1. ::[Expressiveness](Glossary-Std#dg_expressiveness)
|
1. ::[Expressiveness](Glossary-Standard-Terms#dg_expressiveness)
|
||||||
2. ::[Ease of access](Glossary-Std#dg_easy_access)
|
2. ::[Ease of access](Glossary-Standard-Terms#dg_easy_access)
|
||||||
3. ::[Reliability](Glossary-Std#dg_data_reliability)
|
3. ::[Reliability](Glossary-Standard-Terms#dg_data_reliability)
|
||||||
4. ::[Data capacity](Glossary-Std#dg_data_capacity)
|
4. ::[Data capacity](Glossary-Standard-Terms#dg_data_capacity)
|
||||||
5. ::[Data security](Glossary-Std#dg_data_security)
|
5. ::[Data security](Glossary-Standard-Terms#dg_data_security)
|
||||||
6. ::[Performance](Glossary-Std#dg_data_performance)
|
6. ::[Performance](Glossary-Standard-Terms#dg_data_performance)
|
||||||
7. ::[Interoperability](Glossary-Std#dg_data_interop)
|
7. ::[Interoperability](Glossary-Standard-Terms#dg_data_interop)
|
||||||
|
|
||||||
### Central Database
|
### Central Database
|
||||||
|
|
||||||
|
@ -21,10 +21,10 @@ features. Some example text is provided. Add or delete text as needed.*
|
|||||||
|
|
||||||
#### What are the ranked goals for security in this system?
|
#### What are the ranked goals for security in this system?
|
||||||
|
|
||||||
1. ::[Data security](Glossary-Std#data_security)
|
1. ::[Data security](Glossary-Standard-Terms#data_security)
|
||||||
2. ::[Intrusion prevention](Glossary-Std#intrusion_prevention)
|
2. ::[Intrusion prevention](Glossary-Standard-Terms#intrusion_prevention)
|
||||||
3. ::[Abuse prevention](Glossary-Std#abuse_prevention)
|
3. ::[Abuse prevention](Glossary-Standard-Terms#abuse_prevention)
|
||||||
4. ::[Auditability](Glossary-Std#auditability)
|
4. ::[Auditability](Glossary-Standard-Terms#auditability)
|
||||||
|
|
||||||
### Security Mechanisms
|
### Security Mechanisms
|
||||||
|
|
||||||
|
@ -22,10 +22,10 @@ text as needed.*
|
|||||||
|
|
||||||
#### What are the ranked goals for the user interface of this system?
|
#### What are the ranked goals for the user interface of this system?
|
||||||
|
|
||||||
1. ::[Understandability and learnability](Glossary-Std#understandability_and_learnability)
|
1. ::[Understandability and learnability](Glossary-Standard-Terms#understandability_and_learnability)
|
||||||
2. ::[Task support and efficiency](Glossary-Std#task_support_and_efficiency)
|
2. ::[Task support and efficiency](Glossary-Standard-Terms#task_support_and_efficiency)
|
||||||
3. ::[Safety](Glossary-Std#safety)
|
3. ::[Safety](Glossary-Standard-Terms#safety)
|
||||||
4. ::[Consistency and familiarity](Glossary-Std#consistency_and_familiarity)
|
4. ::[Consistency and familiarity](Glossary-Standard-Terms#consistency_and_familiarity)
|
||||||
|
|
||||||
### Metaphors, Exemplars, and Standards
|
### Metaphors, Exemplars, and Standards
|
||||||
|
|
||||||
|
16
Design.md
16
Design.md
@ -42,14 +42,14 @@ interface and database design.
|
|||||||
::PARAGRAPH or BULLETS
|
::PARAGRAPH or BULLETS
|
||||||
|
|
||||||
#### What are the prioritized goals of this design?
|
#### What are the prioritized goals of this design?
|
||||||
1. ::[Correctness](Glossary-Std#dg_correctness)
|
1. ::[Correctness](Glossary-Standard-Terms#dg_correctness)
|
||||||
2. ::[Feasibility](Glossary-Std#dg_feasibility)
|
2. ::[Feasibility](Glossary-Standard-Terms#dg_feasibility)
|
||||||
3. ::[Understandability](Glossary-Std#dg_understandability)
|
3. ::[Understandability](Glossary-Standard-Terms#dg_understandability)
|
||||||
4. ::[Implementation phase guidance](Glossary-Std#dg_guidance)
|
4. ::[Implementation phase guidance](Glossary-Standard-Terms#dg_guidance)
|
||||||
5. ::[Modularity](Glossary-Std#dg_modularity)
|
5. ::[Modularity](Glossary-Standard-Terms#dg_modularity)
|
||||||
6. ::[Extensibility](Glossary-Std#dg_extensibility)
|
6. ::[Extensibility](Glossary-Standard-Terms#dg_extensibility)
|
||||||
7. ::[Testability](Glossary-Std#dg_testability)
|
7. ::[Testability](Glossary-Standard-Terms#dg_testability)
|
||||||
8. ::[Efficiency](Glossary-Std#dg_efficiency)
|
8. ::[Efficiency](Glossary-Standard-Terms#dg_efficiency)
|
||||||
|
|
||||||
### UML Structural Design
|
### UML Structural Design
|
||||||
|
|
||||||
|
522
Glossary-Std.md
522
Glossary-Std.md
@ -1,522 +0,0 @@
|
|||||||
<!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 -->
|
|
||||||
|
|
||||||
# Standard Terms Glossary
|
|
||||||
---
|
|
||||||
|
|
||||||
**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
|
|
||||||
helps keep other documents more concise and easy to edit. Check the
|
|
||||||
[ReadySET glossary](http://readyset.tigris.org/templates/glossary-std) for
|
|
||||||
updates.
|
|
||||||
|
|
||||||
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](#design_goals_terms) | [QA terms](#qa_terms) |
|
|
||||||
[QA goals terms](#qa_goals_terms) | [Additional terms](#additional_standard_terms)|
|
|
||||||
[Project terms](glossary.html#glossary)
|
|
||||||
|
|
||||||
|
|
||||||
### 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
|
|
||||||
will be kept or revised to fit the current project. Even if the
|
|
||||||
sample text does not fit the current project, it provides a reusable
|
|
||||||
example of how to phrase that type of description. The term
|
|
||||||
"chipping away" comes from an old joke: when a sculptor is asked how
|
|
||||||
he carved a marble statue of a horse, he replies "It was easy, I
|
|
||||||
just started with a big block of marble and chipped away everything
|
|
||||||
that did not look like a horse."
|
|
||||||
|
|
||||||
##### Attached worksheet
|
|
||||||
The idea is similar to filling in an IRS form and using worksheets
|
|
||||||
to calculate subtotals or make specific decisions. That is to say,
|
|
||||||
there is a hierarchy to the templates: there are the main templates,
|
|
||||||
and then worksheets for specific topics. We have divided the
|
|
||||||
information into several files so that each file is focused on one
|
|
||||||
topic, and so that each file can be worked on by one person in a
|
|
||||||
reasonable amount of time.
|
|
||||||
|
|
||||||
##### Process impact
|
|
||||||
The process impact box on each template explains where the current
|
|
||||||
template fits into the software development process. It usually
|
|
||||||
includes a brief comment on who should create the document, and who
|
|
||||||
would be expected to make use of it. You can change the process
|
|
||||||
impact box, but you should not need to.
|
|
||||||
|
|
||||||
##### Checklist
|
|
||||||
There are two kinds of checklists:
|
|
||||||
|
|
||||||
- Many of the templates have a section with questions that help
|
|
||||||
you check your work in that template. Often the sample answers
|
|
||||||
to the questions prompt you to take some corrective action.
|
|
||||||
- For design and code review meetings, there are links to
|
|
||||||
guidelines and checklists that help you identify common errors
|
|
||||||
in those artifacts.
|
|
||||||
|
|
||||||
##### Sticky note
|
|
||||||
The idea is similar to a post-it note attached to a document that
|
|
||||||
tells you do "sign here" or fill in a certain part. There are two
|
|
||||||
types of sticky notes:
|
|
||||||
|
|
||||||
- *TODO: Instructs you on how to fill in the template. This is the
|
|
||||||
minimum that you need to do. One of the main goals of ReadySET
|
|
||||||
is to help your team *quickly* carry out basic software
|
|
||||||
engineering activities. The TODO sticky notes make that easy by
|
|
||||||
making the templates more self-explanatory.*
|
|
||||||
- TIP: Helps you think of better ways to fill in the template. One
|
|
||||||
of the other main goals of ReadySET is to help your team make
|
|
||||||
better decisions that can make your whole project more
|
|
||||||
successful. The TIP sticky notes help with that.
|
|
||||||
|
|
||||||
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
|
|
||||||
available to other software components. That allows other programs
|
|
||||||
to "call" this program via direct function calls, or more indirect
|
|
||||||
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.
|
|
||||||
[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
|
|
||||||
requirements and/or source code to accept or reject changes in each
|
|
||||||
particular release. Proposed changes are usually rejected if they
|
|
||||||
introduce too much risk or would trigger additional effort (e.g.,
|
|
||||||
the need to redo a lot of testing on new code). A CCB is usually
|
|
||||||
composed of managers and representatives of other stakeholders such
|
|
||||||
as the QA group and key customers.
|
|
||||||
|
|
||||||
##### Feature Complete
|
|
||||||
A release is called "feature complete" when the development team
|
|
||||||
agrees that no new features will be added to this release. New
|
|
||||||
features may still be suggested for later releases. More development
|
|
||||||
work needs to be done to implement all the features and
|
|
||||||
repair defects.
|
|
||||||
|
|
||||||
##### Code Complete
|
|
||||||
A release is called "code complete" when the development team agrees
|
|
||||||
that no entirely new source code will be added to this release.
|
|
||||||
There may still be source code changes to fix defects. There may
|
|
||||||
still be changes to documentation and data files, and to the code
|
|
||||||
for test cases or utilities. New code may be added in a
|
|
||||||
future release.
|
|
||||||
|
|
||||||
##### Internal Release Number
|
|
||||||
An internal release number is the number that the development team
|
|
||||||
gives each release. Internal release numbers typically count up
|
|
||||||
logically, i.e., they do not skip numbers. They may have many parts:
|
|
||||||
e.g., major, minor, patch-level, build number, RC number.
|
|
||||||
|
|
||||||
##### External Release Number
|
|
||||||
External release numbers are the numbers that users see. Often, they
|
|
||||||
will be the same as the internal release number. That is especially
|
|
||||||
true if the product being built is a component intended to be reused
|
|
||||||
by another engineering group in the same development organization.
|
|
||||||
External release numbers can be different for products that
|
|
||||||
face competition. External release number are simpler, and may not
|
|
||||||
count up logically. E.g., a certain major ISP jumped up to version 8
|
|
||||||
of their client software because their competition had released
|
|
||||||
version 8. Later, the competition used version "10 Optimized" rather
|
|
||||||
than "10.1" or "11".
|
|
||||||
|
|
||||||
##### Release Number
|
|
||||||
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.
|
|
||||||
|
|
||||||
### Development Tool Terms
|
|
||||||
|
|
||||||
#### Version Control System
|
|
||||||
::DEFINITION1
|
|
||||||
|
|
||||||
#### Commit Log Message
|
|
||||||
::DEFINITION1
|
|
||||||
|
|
||||||
#### Issue Tracker
|
|
||||||
::DEFINITION1
|
|
||||||
|
|
||||||
#### Unit Testing Automation
|
|
||||||
::DEFINITION1
|
|
||||||
|
|
||||||
#### Automated Build System
|
|
||||||
::DEFINITION1
|
|
||||||
|
|
||||||
#### Source Code Analysis Tool
|
|
||||||
::DEFINITION1
|
|
||||||
|
|
||||||
#### Style Checker
|
|
||||||
::DEFINITION1
|
|
||||||
|
|
||||||
#### Source Code Formatter (Pretty Printer)
|
|
||||||
::DEFINITION1
|
|
||||||
|
|
||||||
#### System Test Automation
|
|
||||||
::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
|
|
||||||
brief description of the purpose of the feature, the input and
|
|
||||||
output, and any constraints. Individual bullet items give precise
|
|
||||||
details on all aspects of the feature. One feature may be used in
|
|
||||||
many different ways as part of many different use cases.
|
|
||||||
|
|
||||||
#### Use case
|
|
||||||
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
|
|
||||||
include both user intentions and system responses. One use case may
|
|
||||||
show how the actor uses several features to accomplish a goal.
|
|
||||||
|
|
||||||
#### Actor
|
|
||||||
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.
|
|
||||||
|
|
||||||
#### Feasibility
|
|
||||||
This design can be implemented and tested with the planned amount of
|
|
||||||
time and effort.
|
|
||||||
|
|
||||||
#### Understandability
|
|
||||||
Developers can understand this design and correctly implement it.
|
|
||||||
|
|
||||||
#### Implementation phase guidance
|
|
||||||
This design divides the implementation into components or aspects
|
|
||||||
that can correspond to reasonable implementation tasks.
|
|
||||||
|
|
||||||
#### Modularity
|
|
||||||
Concerns are clearly separated so that the impact of most design
|
|
||||||
changes would be limited to only one or a few modules.
|
|
||||||
|
|
||||||
#### Extensibility
|
|
||||||
New features or components can be easily added later.
|
|
||||||
|
|
||||||
#### Testability
|
|
||||||
It is easy to test components of this design independently, and
|
|
||||||
information is available to help diagnose defects.
|
|
||||||
|
|
||||||
#### Efficiency
|
|
||||||
The design enables the system to perform functions with an
|
|
||||||
acceptable amount of time, storage space, bandwidth, and
|
|
||||||
other resources.
|
|
||||||
|
|
||||||
#### Ease of integration
|
|
||||||
The components will work together.
|
|
||||||
|
|
||||||
#### Capacity matching
|
|
||||||
The architecture deploys components onto machines that provide
|
|
||||||
needed resources with reasonable total expense.
|
|
||||||
|
|
||||||
#### Expressiveness
|
|
||||||
It allows for storage of all valid values and relationships
|
|
||||||
|
|
||||||
#### Ease of access
|
|
||||||
Application code to access stored data is simple
|
|
||||||
|
|
||||||
#### Reliability
|
|
||||||
Stored data cannot easily be corrupted by defective code, concurrent
|
|
||||||
access, or unexpected process termination
|
|
||||||
|
|
||||||
#### Data capacity
|
|
||||||
The system can store the amount of data needed.
|
|
||||||
|
|
||||||
#### Data security
|
|
||||||
Protection of sensitive user and corporate data from unauthorized
|
|
||||||
access or modification
|
|
||||||
|
|
||||||
#### Performance
|
|
||||||
Data can be accessed quickly
|
|
||||||
|
|
||||||
#### Interoperability
|
|
||||||
The database or data files can be accessed and updated by other
|
|
||||||
applications
|
|
||||||
|
|
||||||
#### Intrusion prevention
|
|
||||||
Prevent, e.g., hackers opening a command shell on our server.
|
|
||||||
|
|
||||||
#### Abuse prevention
|
|
||||||
Prevention of abuse (e.g., using our system to send spam).
|
|
||||||
|
|
||||||
#### Auditability
|
|
||||||
All changes can be accounted for later.
|
|
||||||
|
|
||||||
#### Understandability and learnability
|
|
||||||
Users can reasonably be expected to understand the UI at
|
|
||||||
first sight. Users will be able to discover additional features
|
|
||||||
without aid from other users or documentation, and they will be able
|
|
||||||
to recall what they have learned.
|
|
||||||
|
|
||||||
#### Task support and efficiency
|
|
||||||
The UI is well matched to the users' tasks and it can be used with a
|
|
||||||
reasonable number of clicks and keystrokes.
|
|
||||||
|
|
||||||
#### Safety
|
|
||||||
Users are not likely to accidentally produce an undesired result
|
|
||||||
(e.g., delete data, or send a half-finished email).
|
|
||||||
|
|
||||||
#### Consistency and familiarity
|
|
||||||
Users can apply their knowledge of similar UIs or UI standards to
|
|
||||||
this system.
|
|
||||||
|
|
||||||
### QA Terms
|
|
||||||
|
|
||||||
#### Bug
|
|
||||||
*n.* **Deprecated** since 1991. See [defect](#defect).
|
|
||||||
|
|
||||||
#### Error
|
|
||||||
*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
|
|
||||||
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,
|
|
||||||
or document.
|
|
||||||
|
|
||||||
#### Fault
|
|
||||||
*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
|
|
||||||
[failure](#failure) is visible.
|
|
||||||
|
|
||||||
#### Failure
|
|
||||||
*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).
|
|
||||||
|
|
||||||
### 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
|
|
||||||
reasonable load, the system's behavior and results will be correct.
|
|
||||||
|
|
||||||
#### Functionality > Robustness
|
|
||||||
Robustness is the system's ability to gracefully handle
|
|
||||||
invalid inputs. It should never be possible for any user input to
|
|
||||||
crash the system or corrupt data, even if that user input is
|
|
||||||
abnormal, unexpected, or malicious.
|
|
||||||
|
|
||||||
#### Functionality > Accuracy
|
|
||||||
Accuracy refers to the mathematical precision of calculations done
|
|
||||||
by the system. Any system that does numeric calculations must
|
|
||||||
consider accuracy, e.g., financial or scientific applications.
|
|
||||||
|
|
||||||
#### Functionality > Compatibility
|
|
||||||
Systems that claim to follow standards or claim compatibility with
|
|
||||||
existing systems must adhere to the relevant file formats,
|
|
||||||
protocols, and APIs. The relevant standards are linked at the top of
|
|
||||||
this document.
|
|
||||||
|
|
||||||
#### Functionality > Factual correctness
|
|
||||||
Is the data in the system a true representation of the real world?
|
|
||||||
Any system that contains initial data or gathers data about the real
|
|
||||||
world should be sure that the data is factually correct. E.g., a tax
|
|
||||||
preparation program should embody correct and up-to-date facts about
|
|
||||||
tax law.
|
|
||||||
|
|
||||||
#### Usability > Understandability and Readability
|
|
||||||
Users need to understand the system to use it. The basic metaphor
|
|
||||||
should be understandable and appropriate to user tasks. Some defects
|
|
||||||
in understandability include unclear metaphors, poor or hard-to-see
|
|
||||||
labels, lack of feedback to confirm the effects of user actions, and
|
|
||||||
missing or inadequate on-line help.
|
|
||||||
|
|
||||||
#### Usability > Learnability and Memorability
|
|
||||||
Every user interface contains some details that users will need to
|
|
||||||
learn and remember. E.g., Alt-F to open the "File" menu. UI cues and
|
|
||||||
rules can make these details easier to learn and remember. E.g., the
|
|
||||||
"F" is underlined and, as a rule, the first letter is usually the
|
|
||||||
accelerator key.
|
|
||||||
|
|
||||||
#### Usability > Task support
|
|
||||||
This is the quality of match between user tasks and the system's UI.
|
|
||||||
Task support defects are cases where the system forces the user to
|
|
||||||
take unnatural steps to accomplish a task or where the user is given
|
|
||||||
no support for a difficult step in a task. E.g., must the user
|
|
||||||
invent an 8-character filename for their "Christmas card list"?
|
|
||||||
E.g., must users total their own tax deductions?
|
|
||||||
|
|
||||||
#### Usability > Efficiency
|
|
||||||
Users should be able to accomplish common tasks with
|
|
||||||
reasonable effort. Common tasks should be possible with only one or
|
|
||||||
two steps. The difficulty of each step should also be considered.
|
|
||||||
E.g., does the user have to remember a long code number or click on
|
|
||||||
a very small button?
|
|
||||||
|
|
||||||
#### Usability > Safety
|
|
||||||
Humans are error-prone, but the negative effects of common errors
|
|
||||||
should be limited. E.g., users should realize that a given command
|
|
||||||
will delete data, and be asked to confirm their intent or have the
|
|
||||||
option to undo.
|
|
||||||
|
|
||||||
#### Usability > Consistency and Familiarity
|
|
||||||
Users should be able to apply their past experience from other
|
|
||||||
similar systems. This means that user interface standards should be
|
|
||||||
followed, and common conventions should be used whenever possible.
|
|
||||||
Also, UI elements that appear in several parts of the UI should be
|
|
||||||
used consistently, unless another UI quality takes priority. E.g.,
|
|
||||||
if most currency entry fields do not require a dollar-sign, then one
|
|
||||||
that does demand it is a consistency defect, unless there is a real
|
|
||||||
chance that the user is dealing with another currency on that step
|
|
||||||
in his/her task.
|
|
||||||
|
|
||||||
#### Usability > Subjective satisfaction
|
|
||||||
Users should feel generally satisfied with the UI. This is a
|
|
||||||
subjective quality that sums up the other user interface qualities
|
|
||||||
as well as aesthetics.
|
|
||||||
|
|
||||||
#### Security
|
|
||||||
The system should allow usage only by authorized users, and restrict
|
|
||||||
usage based on permissions. The system should not allow users to
|
|
||||||
side-step security rule or exploit security holes. E.g., all user
|
|
||||||
input should be validated and any malicious input should
|
|
||||||
be rejected.
|
|
||||||
|
|
||||||
#### Reliability > Consistency under load
|
|
||||||
Every system has some capacity limits. What happens when those
|
|
||||||
limits are exceeded? The system should never lose or corrupt data.
|
|
||||||
|
|
||||||
#### Reliability > Consistency under concurrency
|
|
||||||
Systems that allow concurrent access by multiple users, or that use
|
|
||||||
concurrency internally, should be free of race conditions
|
|
||||||
and deadlock.
|
|
||||||
|
|
||||||
#### Reliability > Availability under load
|
|
||||||
Every system has some capacity limits. What happens when those
|
|
||||||
limits are exceeded? The system should continue to service those
|
|
||||||
requests that it is capable of handling. It should not crash or stop
|
|
||||||
processing all requests.
|
|
||||||
|
|
||||||
#### Reliability > Longevity
|
|
||||||
The system should continue to operate as long as it is needed. It
|
|
||||||
should not gradually use up a limited resource. Example longevity
|
|
||||||
defects include memory leaks or filling the disk with log files.
|
|
||||||
|
|
||||||
#### Efficiency
|
|
||||||
The system's operations should execute quickly, with reasonable use
|
|
||||||
of machine and network resources. E.g., if one user does one
|
|
||||||
operation, it should execute efficiently.
|
|
||||||
|
|
||||||
#### Scalability
|
|
||||||
Scalability is a general quality that holds when the system
|
|
||||||
continues to satisfy its requirements when various usage parameters
|
|
||||||
are increased. E.g., a file server might be scalable to a high
|
|
||||||
number of users, or to very large files or very high capacity disks.
|
|
||||||
Several specific scalability goals are listed below.
|
|
||||||
|
|
||||||
#### Scalability > Performance under load
|
|
||||||
This is a specific type of scalability goal dealing with the
|
|
||||||
performance of the system at times when it is servicing many
|
|
||||||
requests from many users.
|
|
||||||
|
|
||||||
#### Scalability > Large data volume
|
|
||||||
This is a specific type of scalability goal dealing with the ability
|
|
||||||
for the system to handle large data sets. Operations should continue
|
|
||||||
to be correct and efficient as data set size increases. Furthermore,
|
|
||||||
the user interface should still be usable as the data presented to
|
|
||||||
users increases in length.
|
|
||||||
|
|
||||||
#### Operability
|
|
||||||
The long-term needs of system administrators should be
|
|
||||||
reliably supported. E.g., is the system easy to install? Can the
|
|
||||||
administrator recover from a crash? Is there sufficient log output
|
|
||||||
to diagnose problems in the field? Can the system's data be backed
|
|
||||||
up without downtime? Can the system be upgraded practically?
|
|
||||||
|
|
||||||
#### Maintainability > Understandability
|
|
||||||
Will it be easy for (future) developers to understand how the system
|
|
||||||
works?
|
|
||||||
|
|
||||||
#### Maintainability > Evolvability
|
|
||||||
Can the system easily be modified and extended over time?
|
|
||||||
|
|
||||||
#### Maintainability > Testability
|
|
||||||
Can the system easily be tested? Do the requirements precisely
|
|
||||||
specify possible inputs and the desired results? Can the system be
|
|
||||||
tested in parts? When failures are observed, can they be traced back
|
|
||||||
to defects in specific components (i.e., debugging)? Is testing
|
|
||||||
practical with the available testing tools?
|
|
||||||
|
|
||||||
### Additional Standard Terms
|
|
||||||
|
|
||||||
For additional standard terms, see the following reference sites:
|
|
||||||
|
|
||||||
- [Dictionary.com](http://www.dictionary.com/)
|
|
||||||
- [Whatis.com](http://www.whatis.com/)
|
|
||||||
- [NIST Dictionary of Algorithms and Data Structures](http://www.nist.gov/dads/)
|
|
||||||
- [Free on-line dictionary of computing](http:/http://foldoc.doc.ic.ac.uk/foldoc/index.html)
|
|
||||||
- [IBM's glossary of computing terms](http://www-3.ibm.com/ibm/terminology/goc/gocmain.htm)
|
|
||||||
- [Jargon File](http://www.jargon.org/)
|
|
||||||
|
|
||||||
<!-- 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>
|
|
@ -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) |
|
[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) |
|
[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) |
|
[U](#u) | [V](#v) | [W](#w) | [X](#x) | [Y](#y) | [Z](#z) |
|
||||||
[Standard terms](Glossary-Std#standard_terms)
|
[Standard terms](Glossary-Standard-Terms#standard_terms)
|
||||||
|
|
||||||
### Project-specific 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,
|
- *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
|
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
|
the term or terms that replace it. E.g., deprecated standard term
|
||||||
[bug](Glossary-Std#bug).*
|
[bug](Glossary-Standard-Terms#bug).*
|
||||||
- *Define only project-specific terms, or ones that a new team member
|
- *Define only project-specific terms, or ones that a new team member
|
||||||
would not know. Don't define standard textbook terms that can be
|
would not know. Don't define standard textbook terms that can be
|
||||||
easily found elsewhere.*
|
easily found elsewhere.*
|
||||||
|
@ -81,13 +81,13 @@ For more information see the [Software Development Methodology](SDM).
|
|||||||
|
|
||||||
- ::Requests for requirements changes will be tracked in the issue
|
- ::Requests for requirements changes will be tracked in the issue
|
||||||
tracker
|
tracker
|
||||||
- ::The change control board ([CCB](glossary.html#ccb))
|
- ::The change control board ([CCB](Glossary#ccb))
|
||||||
will review requested changes and authorize work on them as
|
will review requested changes and authorize work on them as
|
||||||
appropriate
|
appropriate
|
||||||
- ::After the [feature
|
- ::After the [feature
|
||||||
complete](glossary.html#featurecomplete) milestone, no
|
complete](Glossary#featurecomplete) milestone, no
|
||||||
new features will be added to this release.
|
new features will be added to this release.
|
||||||
- ::After the [code complete](glossary.html#codecomplete)
|
- ::After the [code complete](Glossary#codecomplete)
|
||||||
milestone, no entirely new product source code will be added to
|
milestone, no entirely new product source code will be added to
|
||||||
this release.
|
this release.
|
||||||
- ::All source code commit log messages must refer to a specific
|
- ::All source code commit log messages must refer to a specific
|
||||||
|
50
QA-Plan.md
50
QA-Plan.md
@ -118,33 +118,33 @@ activities:
|
|||||||
that make sense for your project on this particular release.*
|
that make sense for your project on this particular release.*
|
||||||
|
|
||||||
- ::Essential
|
- ::Essential
|
||||||
- [Functionality > Correctness](Glossary-Std#functionality_gt_correctness)
|
- [Functionality > Correctness](Glossary-Standard-Terms#functionality_gt_correctness)
|
||||||
- [Functionality > Robustness](Glossary-Std#functionality_gt_robustness)
|
- [Functionality > Robustness](Glossary-Standard-Terms#functionality_gt_robustness)
|
||||||
- ::Expected
|
- ::Expected
|
||||||
- [Functionality > Accuracy](Glossary-Std#functionality_gt_accuracy)
|
- [Functionality > Accuracy](Glossary-Standard-Terms#functionality_gt_accuracy)
|
||||||
- [Functionality > Compatibility](Glossary-Std#functionality_gt_compatibility)
|
- [Functionality > Compatibility](Glossary-Standard-Terms#functionality_gt_compatibility)
|
||||||
- [Functionality > Factual correctness](Glossary-Std#functionality_gt_factual_correctness)
|
- [Functionality > Factual correctness](Glossary-Standard-Terms#functionality_gt_factual_correctness)
|
||||||
- [Usability > Understandability and Readability](Glossary-Std#usability_gt_understandability_and_readability)
|
- [Usability > Understandability and Readability](Glossary-Standard-Terms#usability_gt_understandability_and_readability)
|
||||||
- [Usability > Learnability and Memorability](Glossary-Std#usability_gt_learnability_and_memorability)
|
- [Usability > Learnability and Memorability](Glossary-Standard-Terms#usability_gt_learnability_and_memorability)
|
||||||
- [Usability > Task support](Glossary-Std#usability_gt_task_support)
|
- [Usability > Task support](Glossary-Standard-Terms#usability_gt_task_support)
|
||||||
- [Usability > Efficiency](Glossary-Std#usability_gt_efficiency)
|
- [Usability > Efficiency](Glossary-Standard-Terms#usability_gt_efficiency)
|
||||||
- [Usability > Safety](Glossary-Std#usability_gt_safety)
|
- [Usability > Safety](Glossary-Standard-Terms#usability_gt_safety)
|
||||||
- [Usability > Consistency and Familiarity](Glossary-Std#usability_gt_consistency_and_familiarity)
|
- [Usability > Consistency and Familiarity](Glossary-Standard-Terms#usability_gt_consistency_and_familiarity)
|
||||||
- [Usability > Subjective satisfaction](Glossary-Std#usability_gt_subjective_satisfaction)
|
- [Usability > Subjective satisfaction](Glossary-Standard-Terms#usability_gt_subjective_satisfaction)
|
||||||
- [Security](Glossary-Std#security)
|
- [Security](Glossary-Standard-Terms#security)
|
||||||
- ::Desired
|
- ::Desired
|
||||||
- [Reliability > Consistency under load](Glossary-Std#reliability_gt_consistency_under_load)
|
- [Reliability > Consistency under load](Glossary-Standard-Terms#reliability_gt_consistency_under_load)
|
||||||
- [Reliability > Consistency under concurrency](Glossary-Std#reliability_gt_consistency_under_concurrency)
|
- [Reliability > Consistency under concurrency](Glossary-Standard-Terms#reliability_gt_consistency_under_concurrency)
|
||||||
- [Reliability > Availability under load](Glossary-Std#reliability_gt_availability_under_load)
|
- [Reliability > Availability under load](Glossary-Standard-Terms#reliability_gt_availability_under_load)
|
||||||
- [Reliability > Longevity](Glossary-Std#reliability_gt_longevity)
|
- [Reliability > Longevity](Glossary-Standard-Terms#reliability_gt_longevity)
|
||||||
- [Efficiency](Glossary-Std#efficiency)
|
- [Efficiency](Glossary-Standard-Terms#efficiency)
|
||||||
- [Scalability](Glossary-Std#scalability)
|
- [Scalability](Glossary-Standard-Terms#scalability)
|
||||||
- [Scalability > Performance under load](Glossary-Std#scalability_gt_performance_under_load)
|
- [Scalability > Performance under load](Glossary-Standard-Terms#scalability_gt_performance_under_load)
|
||||||
- [Scalability > Large data volume](Glossary-Std#scalability_gt_large_data_volume)
|
- [Scalability > Large data volume](Glossary-Standard-Terms#scalability_gt_large_data_volume)
|
||||||
- [Operability](Glossary-Std#operability)
|
- [Operability](Glossary-Standard-Terms#operability)
|
||||||
- [Maintainability > Understandability](Glossary-Std#maintainability_gt_understandability)
|
- [Maintainability > Understandability](Glossary-Standard-Terms#maintainability_gt_understandability)
|
||||||
- [Maintainability > Evolvability](Glossary-Std#maintainability_gt_evolvability)
|
- [Maintainability > Evolvability](Glossary-Standard-Terms#maintainability_gt_evolvability)
|
||||||
- [Maintainability > Testability](Glossary-Std#maintainability_gt_testability)
|
- [Maintainability > Testability](Glossary-Standard-Terms#maintainability_gt_testability)
|
||||||
|
|
||||||
### QA Strategy
|
### QA Strategy
|
||||||
|
|
||||||
|
@ -89,7 +89,7 @@ otherwise be missed. It does not help with the actual estimated number
|
|||||||
of hours needed. Those estimates should be based on the project plan.
|
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-std#chipaway){.def} the ones that do
|
provided, [chip away](Glossary-Standard-Terms#chipaway){.def} the ones that do
|
||||||
not apply. Edit any provided answers as needed. Use this exercise to
|
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.*
|
||||||
|
|
||||||
|
2
SRS.md
2
SRS.md
@ -246,7 +246,7 @@ Details:
|
|||||||
- ::DETAIL
|
- ::DETAIL
|
||||||
- ::DETAIL
|
- ::DETAIL
|
||||||
|
|
||||||
#### What application program interfaces ([APIs](Glossary-Std#api_application_programming_interface)) must be provided?
|
#### What application program interfaces ([APIs](Glossary-Standard-Terms#api_application_programming_interface)) must be provided?
|
||||||
|
|
||||||
::PARAGRAPH
|
::PARAGRAPH
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user