Adjust header levels
This commit is contained in:
parent
0d20f4e5b1
commit
ff3bc57b27
@ -3,14 +3,14 @@
|
|||||||
as they are used across projects. Individual projects should not need to
|
as they are used across projects. Individual projects should not need to
|
||||||
edit this file. Writing out the definitions of terms and acronyms here
|
edit this file. Writing out the definitions of terms and acronyms here
|
||||||
helps keep other documents more concise and easy to edit. Check the
|
helps keep other documents more concise and easy to edit. Check the
|
||||||
[ReadySET glossary](http://readyset.tigris.org/templates/glossary-std.html) for
|
[ReadySET glossary](https://web.archive.org/web/20200701142616/http://readyset.tigris.org/templates/glossary-std.html) for
|
||||||
updates.
|
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](#desigD-DIAGRAMn-goals-terms) | [QA terms](#qa-terms) | [QA goals terms](#qa-goals-terms) | [Additional terms](#additional-standard-terms)| [Project terms](Glossary)
|
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)
|
||||||
|
|
||||||
### General Terms
|
## General Terms
|
||||||
|
|
||||||
##### Chipping away
|
### Chipping away
|
||||||
|
|
||||||
The process of removing sample text from templates when that text
|
The process of removing sample text from templates when that text
|
||||||
does not apply to the current project. Often some of the sample text
|
does not apply to the current project. Often some of the sample text
|
||||||
@ -22,26 +22,26 @@ 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
|
just started with a big block of marble and chipped away everything
|
||||||
that did not look like a horse."
|
that did not look like a horse."
|
||||||
|
|
||||||
##### Attached worksheetD-DIAGRAM
|
### Attached worksheet
|
||||||
|
|
||||||
The idea is similar to fillD-DIAGRAMing in an IRS form and using worksheets
|
The idea is similar to filling in an IRS form and using worksheets
|
||||||
to calculate subtotals or mD-DIAGRAMake specific decisions. That is to say,
|
to calculate subtotals or make specific decisions. That is to say,
|
||||||
there is a hierarchy to theD-DIAGRAM templates: there are the main templates,
|
there is a hierarchy to the templates: there are the main templates,
|
||||||
and then worksheets for speD-DIAGRAMcific topics. We have divided the
|
and then worksheets for specific topics. We have divided the
|
||||||
information into several fiD-DIAGRAMles so that each file is focused on one
|
information into several files so that each file is focused on one
|
||||||
topic, and so that each filD-DIAGRAMe can be worked on by one person in a
|
topic, and so that each file can be worked on by one person in a
|
||||||
reasonable amount of time.D-DIAGRAM
|
reasonable amount of time.
|
||||||
D-DIAGRAM
|
|
||||||
|
|
||||||
##### Process impactD-DIAGRAM
|
|
||||||
|
|
||||||
The process impact box on eD-DIAGRAMach template explains where the current
|
### Process impact
|
||||||
template fits into the softD-DIAGRAMware development process. It usually
|
|
||||||
|
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
|
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
|
would be expected to make use of it. You can change the process
|
||||||
impact box, but you should not need to.
|
impact box, but you should not need to.
|
||||||
|
|
||||||
##### Checklist
|
### Checklist
|
||||||
|
|
||||||
There are two kinds of checklists:
|
There are two kinds of checklists:
|
||||||
|
|
||||||
@ -52,7 +52,7 @@ There are two kinds of checklists:
|
|||||||
guidelines and checklists that help you identify common errors
|
guidelines and checklists that help you identify common errors
|
||||||
in those artifacts.
|
in those artifacts.
|
||||||
|
|
||||||
##### Sticky note
|
### Sticky note
|
||||||
|
|
||||||
The idea is similar to a post-it note attached to a document that
|
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
|
tells you do "sign here" or fill in a certain part. There are two
|
||||||
@ -71,7 +71,7 @@ types of sticky notes:
|
|||||||
After you have done what the sticky note says, you can delete the
|
After you have done what the sticky note says, you can delete the
|
||||||
sticky note.
|
sticky note.
|
||||||
|
|
||||||
### Computer Science and Technology Terms
|
## Computer Science and Technology Terms
|
||||||
|
|
||||||
##### ::API (Application Programming Interface)
|
##### ::API (Application Programming Interface)
|
||||||
|
|
||||||
@ -80,18 +80,18 @@ available to other software components. That allows other programs
|
|||||||
to "call" this program via direct function calls, or more indirect
|
to "call" this program via direct function calls, or more indirect
|
||||||
communications such as [SOAP](#soap) messages.
|
communications such as [SOAP](#soap) messages.
|
||||||
|
|
||||||
##### ::SOAP
|
### ::SOAP
|
||||||
|
|
||||||
SOAP (Simple Object Access Protocol) is the message format used by
|
SOAP (Simple Object Access Protocol) is the message format used by
|
||||||
standard web services. It entails sending an XML document to a
|
standard web services. It entails sending an XML document to a
|
||||||
server in order to invoke an operation on the server-side.
|
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).
|
[More information on SOAP](http://directory.google.com/Top/Computers/Programming/Internet/Web_Services/SOAP/?tc=1).
|
||||||
|
|
||||||
### Process Terms
|
## Process Terms
|
||||||
|
|
||||||
##### Change Control Board (CCB)
|
### Change Control Board (CCB)
|
||||||
|
|
||||||
A group of people who review proposed changes toD-DIAGRAM the project
|
A group of people who review proposed changes to the project
|
||||||
requirements and/or source code to accept or reject changes in each
|
requirements and/or source code to accept or reject changes in each
|
||||||
particular release. Proposed changes are usually rejected if they
|
particular release. Proposed changes are usually rejected if they
|
||||||
introduce too much risk or would trigger additional effort (e.g.,
|
introduce too much risk or would trigger additional effort (e.g.,
|
||||||
@ -99,7 +99,7 @@ the need to redo a lot of testing on new code). A CCB is usually
|
|||||||
composed of managers and representatives of other stakeholders such
|
composed of managers and representatives of other stakeholders such
|
||||||
as the QA group and key customers.
|
as the QA group and key customers.
|
||||||
|
|
||||||
##### Feature Complete
|
### Feature Complete
|
||||||
|
|
||||||
A release is called "feature complete" when the development team
|
A release is called "feature complete" when the development team
|
||||||
agrees that no new features will be added to this release. New
|
agrees that no new features will be added to this release. New
|
||||||
@ -107,7 +107,7 @@ features may still be suggested for later releases. More development
|
|||||||
work needs to be done to implement all the features and
|
work needs to be done to implement all the features and
|
||||||
repair defects.
|
repair defects.
|
||||||
|
|
||||||
##### Code Complete
|
### Code Complete
|
||||||
|
|
||||||
A release is called "code complete" when the development team agrees
|
A release is called "code complete" when the development team agrees
|
||||||
that no entirely new source code will be added to this release.
|
that no entirely new source code will be added to this release.
|
||||||
@ -116,14 +116,14 @@ still be changes to documentation and data files, and to the code
|
|||||||
for test cases or utilities. New code may be added in a
|
for test cases or utilities. New code may be added in a
|
||||||
future release.
|
future release.
|
||||||
|
|
||||||
##### Internal Release Number
|
### Internal Release Number
|
||||||
|
|
||||||
An internal release number is the number that the development team
|
An internal release number is the number that the development team
|
||||||
gives each release. Internal release numbers typically count up
|
gives each release. Internal release numbers typically count up
|
||||||
logically, i.e., they do not skip numbers. They may have many parts:
|
logically, i.e., they do not skip numbers. They may have many parts:
|
||||||
e.g., major, minor, patch-level, build number, RC number.
|
e.g., major, minor, patch-level, build number, RC number.
|
||||||
|
|
||||||
##### External Release Number
|
### External Release Number
|
||||||
|
|
||||||
External release numbers are the numbers that users see. Often, they
|
External release numbers are the numbers that users see. Often, they
|
||||||
will be the same as the internal release number. That is especially
|
will be the same as the internal release number. That is especially
|
||||||
@ -136,49 +136,49 @@ of their client software because their competition had released
|
|||||||
version 8. Later, the competition used version "10 Optimized" rather
|
version 8. Later, the competition used version "10 Optimized" rather
|
||||||
than "10.1" or "11".
|
than "10.1" or "11".
|
||||||
|
|
||||||
##### Release Number
|
### 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
|
[external release number](#external_release_number). Users normally are not aware
|
||||||
of the existence of any internal release numbers.
|
of the existence of any internal release numbers.
|
||||||
|
|
||||||
### Development Tool Terms
|
## Development Tool Terms
|
||||||
|
|
||||||
#### Version Control System
|
### Version Control System
|
||||||
|
|
||||||
::DEFINITION1
|
::DEFINITION1
|
||||||
|
|
||||||
#### Commit Log Message
|
### Commit Log Message
|
||||||
|
|
||||||
::DEFINITION1
|
::DEFINITION1
|
||||||
|
|
||||||
#### Issue Tracker
|
### Issue Tracker
|
||||||
|
|
||||||
::DEFINITION1
|
::DEFINITION1
|
||||||
|
|
||||||
#### Unit Testing Automation
|
### Unit Testing Automation
|
||||||
|
|
||||||
::DEFINITION1
|
::DEFINITION1
|
||||||
|
|
||||||
#### Automated Build System
|
### Automated Build System
|
||||||
|
|
||||||
::DEFINITION1
|
::DEFINITION1
|
||||||
|
|
||||||
#### Style Checker
|
### Style Checker
|
||||||
|
|
||||||
::DEFINITION1
|
::DEFINITION1
|
||||||
|
|
||||||
#### Source Code Formatter (Pretty Printer)
|
### Source Code Formatter (Pretty Printer)
|
||||||
|
|
||||||
::DEFINITION1
|
::DEFINITION1
|
||||||
|
|
||||||
#### System Test Automation
|
### System Test Automation
|
||||||
|
|
||||||
::DEFINITION1
|
::DEFINITION1
|
||||||
|
|
||||||
### Requirements Terms
|
## Requirements Terms
|
||||||
|
|
||||||
#### Feature specification
|
### Feature specification
|
||||||
|
|
||||||
A feature specification focuses on one feature of a software product
|
A feature specification focuses on one feature of a software product
|
||||||
and completely describes how that feature can be used. It includes a
|
and completely describes how that feature can be used. It includes a
|
||||||
@ -187,211 +187,208 @@ output, and any constraints. Individual bullet items give precise
|
|||||||
details on all aspects of the feature. One feature may be used in
|
details on all aspects of the feature. One feature may be used in
|
||||||
many different ways as part of many different use cases.
|
many different ways as part of many different use cases.
|
||||||
|
|
||||||
#### Use case
|
### Use case
|
||||||
|
|
||||||
The main part of a use case is a set of steps that give an example
|
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
|
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
|
include both user intentions and system responses. One use case may
|
||||||
show how the actor uses several features to accomplish a goal.
|
show how the actor uses several features to accomplish a goal.
|
||||||
|
|
||||||
#### Actor
|
### Actor
|
||||||
|
|
||||||
A user or an external system that uses the system being built.
|
A user or an external system that uses the system being built.
|
||||||
|
|
||||||
### Design Terms
|
## Design Terms
|
||||||
|
|
||||||
#### ::TERM2
|
### ::TERM2
|
||||||
|
|
||||||
::DEFINITION2
|
::DEFINITION2
|
||||||
|
|
||||||
### Design Goals Terms
|
## Design Goals Terms
|
||||||
|
|
||||||
#### Correctness
|
### Correctness
|
||||||
|
|
||||||
This design correctly matches the given requirements.
|
This design correctly matches the given requirements.
|
||||||
|
|
||||||
#### Feasibility
|
### Feasibility
|
||||||
|
|
||||||
This design can be implemented and tested with the planned amount of
|
This design can be implemented and tested with the planned amount of
|
||||||
time and effort.
|
time and effort.
|
||||||
|
|
||||||
#### Understandability
|
### Understandability
|
||||||
|
|
||||||
Developers can understand this design and correctly implement it.
|
Developers can understand this design and correctly implement it.
|
||||||
|
|
||||||
#### Implementation phase guidance
|
### Implementation phase guidance
|
||||||
|
|
||||||
This design divides the implementation into components or aspects
|
This design divides the implementation into components or aspects
|
||||||
that can correspond to reasonable implementation tasks.
|
that can correspond to reasonable implementation tasks.
|
||||||
|
|
||||||
#### Modularity
|
### Modularity
|
||||||
|
|
||||||
Concerns are clearly separated so that the impact of most design
|
Concerns are clearly separated so that the impact of most design
|
||||||
changes would be limited to only one or a few modules.
|
changes would be limited to only one or a few modules.
|
||||||
|
|
||||||
#### Extensibility
|
### Extensibility
|
||||||
|
|
||||||
New features or components can be easily added later.
|
New features or components can be easily added later.
|
||||||
|
|
||||||
#### Testability
|
### Testability
|
||||||
|
|
||||||
It is easy to test components of this design independently, and
|
It is easy to test components of this design independently, and
|
||||||
information is available to help diagnose defects.
|
information is available to help diagnose defects.
|
||||||
|
|
||||||
#### Efficiency
|
### Efficiency
|
||||||
|
|
||||||
The design enables the system to perform functions with an
|
The design enables the system to perform functions with an
|
||||||
acceptable amount of time, storage space, bandwidth, and
|
acceptable amount of time, storage space, bandwidth, and
|
||||||
other resources.
|
other resources.
|
||||||
|
|
||||||
#### Ease of integration
|
### Ease of integration
|
||||||
|
|
||||||
The components will work together.
|
The components will work together.
|
||||||
|
|
||||||
#### Capacity matching
|
### Capacity matching
|
||||||
|
|
||||||
The architecture deploys components onto machines that provide
|
The architecture deploys components onto machines that provide
|
||||||
needed resources with reasonable total expense.
|
needed resources with reasonable total expense.
|
||||||
|
|
||||||
#### Expressiveness
|
### Expressiveness
|
||||||
|
|
||||||
It allows for storage of all valid values and relationships
|
It allows for storage of all valid values and relationships
|
||||||
|
|
||||||
#### Ease of access
|
### Ease of access
|
||||||
|
|
||||||
Application code to access stored data is simple
|
Application code to access stored data is simple
|
||||||
|
|
||||||
#### Reliability
|
### Reliability
|
||||||
|
|
||||||
Stored data cannot easily be corrupted by defective code, concurrent
|
Stored data cannot easily be corrupted by defective code, concurrent
|
||||||
access, or unexpected process termination
|
access, or unexpected process termination
|
||||||
|
|
||||||
#### Data capacity
|
### Data capacity
|
||||||
|
|
||||||
The system can store the amount of data needed.
|
The system can store the amount of data needed.
|
||||||
|
|
||||||
#### Data security
|
### Data security
|
||||||
|
|
||||||
Protection of sensitive user and corporate data from unauthorized
|
Protection of sensitive user and corporate data from unauthorized
|
||||||
access or modification
|
access or modification
|
||||||
|
|
||||||
#### Performance
|
### Performance
|
||||||
|
|
||||||
Data can be accessed quickly
|
Data can be accessed quickly
|
||||||
|
|
||||||
#### Interoperability
|
### Interoperability
|
||||||
|
|
||||||
The database or data files can be accessed and updated by other
|
The database or data files can be accessed and updated by other
|
||||||
applications
|
applications
|
||||||
|
|
||||||
#### Intrusion prevention
|
### Intrusion prevention
|
||||||
|
|
||||||
Prevent, e.g., hackers opening a command shell on our server.
|
Prevent, e.g., hackers opening a command shell on our server.
|
||||||
|
|
||||||
#### Abuse prevention
|
### Abuse prevention
|
||||||
|
|
||||||
Prevention of abuse (e.g., using our system to send spam).
|
Prevention of abuse (e.g., using our system to send spam).
|
||||||
|
|
||||||
#### Auditability
|
### Auditability
|
||||||
|
|
||||||
All changes can be accounted for later.
|
All changes can be accounted for later.
|
||||||
|
|
||||||
#### Understandability and learnability
|
### Understandability and learnability
|
||||||
|
|
||||||
Users can reasonably be expected to understand the UI at
|
Users can reasonably be expected to understand the UI at
|
||||||
first sight. Users will be able to discover additional features
|
first sight. Users will be able to discover additional features
|
||||||
without aid from other users or documentation, and they will be able
|
without aid from other users or documentation, and they will be able
|
||||||
to recall what they have learned.
|
to recall what they have learned.
|
||||||
|
|
||||||
#### Task support and efficiency
|
### Task support and efficiency
|
||||||
|
|
||||||
The UI is well matched to the users' tasks and it can be used with a
|
The UI is well matched to the users' tasks and it can be used with a
|
||||||
reasonable number of clicks and keystrokes.
|
reasonable number of clicks and keystrokes.
|
||||||
|
|
||||||
#### Safety
|
### Safety
|
||||||
|
|
||||||
Users are not likely to accidentally produce an undesired result
|
Users are not likely to accidentally produce an undesired result
|
||||||
(e.g., delete data, or send a half-finished email).
|
(e.g., delete data, or send a half-finished email).
|
||||||
|
|
||||||
#### Consistency and familiarity
|
### Consistency and familiarity
|
||||||
|
|
||||||
Users can apply their knowledge of similar UIs or UI standards to
|
Users can apply their knowledge of similar UIs or UI standards to
|
||||||
this system.
|
this system.
|
||||||
|
|
||||||
### QA Terms
|
## QA Terms
|
||||||
|
|
||||||
#### Bug
|
### Bug
|
||||||
|
|
||||||
*n.* **Deprecated** since 1991. See [defect](#defect).
|
_n._ **Deprecated** since 1991. See [defect](#defect).
|
||||||
|
|
||||||
#### Error
|
### 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
|
miscommunication or bad assumptions. Errors can create
|
||||||
[defects](#defect). E.g., a developer might erroneously think that
|
[defects](#defect). E.g., a developer might erroneously think that
|
||||||
the square root of -4 is -2.
|
the square root of -4 is -2.
|
||||||
|
|
||||||
#### Defect
|
### 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
|
product source code, initial data, or documents. E.g., a square root
|
||||||
function which allows negative numbers as arguments is defective.
|
function which allows negative numbers as arguments is defective.
|
||||||
Defects can be removed by changing the source code, initial data,
|
Defects can be removed by changing the source code, initial data,
|
||||||
or document.
|
or document.
|
||||||
|
|
||||||
#### Fault
|
### 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
|
provided to defective code, it may cause an exception, or go into an
|
||||||
infinite loop, or store an incorrect value in an internal variable.
|
infinite loop, or store an incorrect value in an internal variable.
|
||||||
A fault is not normally visible to users, only the
|
A fault is not normally visible to users, only the
|
||||||
[failure](#failure) is visible.
|
[failure](#failure) is visible.
|
||||||
|
|
||||||
#### Failure
|
### 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
|
message or an incorrect result. This is evidence that can be
|
||||||
reported in a defect report. Developers use failure evidence during
|
reported in a defect report. Developers use failure evidence during
|
||||||
debugging to eventually find and remove [defects](#defect).
|
debugging to eventually find and remove [defects](#defect).
|
||||||
|
|
||||||
### QA Goals Terms
|
## QA Goals Terms
|
||||||
|
|
||||||
#### Functionality > Correctness
|
### Functionality > Correctness
|
||||||
|
|
||||||
Correctness is the most basic quality goal. It means that, when
|
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
|
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.
|
reasonable load, the system's behavior and results will be correct.
|
||||||
|
|
||||||
#### Functionality > Robustness
|
### Functionality > Robustness
|
||||||
|
|
||||||
Robustness is the system's ability to gracefully handle
|
Robustness is the system's ability to gracefully handle
|
||||||
invalid inputs. It should never be possible for any user input to
|
invalid inputs. It should never be possible for any user input to
|
||||||
crash the system or corrupt data, even if that user input is
|
crash the system or corrupt data, even if that user input is
|
||||||
abnormal, unexpected, or malicious.
|
abnormal, unexpected, or malicious.
|
||||||
|
|
||||||
#### Functionality > Accuracy
|
### Functionality > Accuracy
|
||||||
|
|
||||||
Accuracy refers to the mathematical precision of calculations done
|
Accuracy refers to the mathematical precision of calculations done
|
||||||
by the system. Any system that does numeric calculations must
|
by the system. Any system that does numeric calculations must
|
||||||
consider accuracy, e.g., financial or scientific applications.
|
consider accuracy, e.g., financial or scientific applications.
|
||||||
|
|
||||||
#### Functionality > Compatibility
|
### Functionality > Compatibility
|
||||||
|
|
||||||
Systems that claim to follow standards or claim compatibility with
|
Systems that claim to follow standards or claim compatibility with
|
||||||
existing systems must adhere to the relevant file formats,
|
existing systems must adhere to the relevant file formats,
|
||||||
protocols, and APIs. The relevant standards are linked at the top of
|
protocols, and APIs. The relevant standards are linked at the top of
|
||||||
this document.
|
this document.
|
||||||
|
|
||||||
#### Functionality > Factual correctness
|
### Functionality > Factual correctness
|
||||||
|
|
||||||
Is the data in the system a true representation of the real world?
|
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
|
Any system that contains initial data or gathers data about the real
|
||||||
D-DIAGRAM
|
|
||||||
D-DIAGRAM
|
### Usability > Understandability and Readability
|
||||||
D-DIAGRAM
|
|
||||||
D-DIAGRAM
|
|
||||||
#### Usability > Understandability and Readability
|
|
||||||
|
|
||||||
Users need to understand the system to use it. The basic metaphor
|
Users need to understand the system to use it. The basic metaphor
|
||||||
should be understandable and appropriate to user tasks. Some defects
|
should be understandable and appropriate to user tasks. Some defects
|
||||||
@ -399,7 +396,7 @@ in understandability include unclear metaphors, poor or hard-to-see
|
|||||||
labels, lack of feedback to confirm the effects of user actions, and
|
labels, lack of feedback to confirm the effects of user actions, and
|
||||||
missing or inadequate on-line help.
|
missing or inadequate on-line help.
|
||||||
|
|
||||||
#### Usability > Learnability and Memorability
|
### Usability > Learnability and Memorability
|
||||||
|
|
||||||
Every user interface contains some details that users will need to
|
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
|
learn and remember. E.g., Alt-F to open the "File" menu. UI cues and
|
||||||
@ -407,7 +404,7 @@ 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
|
"F" is underlined and, as a rule, the first letter is usually the
|
||||||
accelerator key.
|
accelerator key.
|
||||||
|
|
||||||
#### Usability > Task support
|
### Usability > Task support
|
||||||
|
|
||||||
This is the quality of match between user tasks and the system's UI.
|
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
|
Task support defects are cases where the system forces the user to
|
||||||
@ -416,7 +413,7 @@ no support for a difficult step in a task. E.g., must the user
|
|||||||
invent an 8-character filename for their "Christmas card list"?
|
invent an 8-character filename for their "Christmas card list"?
|
||||||
E.g., must users total their own tax deductions?
|
E.g., must users total their own tax deductions?
|
||||||
|
|
||||||
#### Usability > Efficiency
|
### Usability > Efficiency
|
||||||
|
|
||||||
Users should be able to accomplish common tasks with
|
Users should be able to accomplish common tasks with
|
||||||
reasonable effort. Common tasks should be possible with only one or
|
reasonable effort. Common tasks should be possible with only one or
|
||||||
@ -424,14 +421,14 @@ 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
|
E.g., does the user have to remember a long code number or click on
|
||||||
a very small button?
|
a very small button?
|
||||||
|
|
||||||
#### Usability > Safety
|
### Usability > Safety
|
||||||
|
|
||||||
Humans are error-prone, but the negative effects of common errors
|
Humans are error-prone, but the negative effects of common errors
|
||||||
should be limited. E.g., users should realize that a given command
|
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
|
will delete data, and be asked to confirm their intent or have the
|
||||||
option to undo.
|
option to undo.
|
||||||
|
|
||||||
#### Usability > Consistency and Familiarity
|
### Usability > Consistency and Familiarity
|
||||||
|
|
||||||
Users should be able to apply their past experience from other
|
Users should be able to apply their past experience from other
|
||||||
similar systems. This means that user interface standards should be
|
similar systems. This means that user interface standards should be
|
||||||
@ -440,22 +437,16 @@ Also, UI elements that appear in several parts of the UI should be
|
|||||||
used consistently, unless another UI quality takes priority. E.g.,
|
used consistently, unless another UI quality takes priority. E.g.,
|
||||||
if most currency entry fields do not require a dollar-sign, then one
|
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
|
that does demand it is a consistency defect, unless there is a real
|
||||||
chance that the user is dealing with anoD-DIAGRAM
|
chance that the user is dealing with another currency on that step
|
||||||
D-DIAGRAM
|
|
||||||
D-DIAGRAM
|
|
||||||
D-DIAGRAM
|
|
||||||
in his/her task.
|
in his/her task.
|
||||||
|
|
||||||
#### Usability > Subjective satisfactionD-DIAGRAM
|
### Usability > Subjective satisfaction
|
||||||
D-DIAGRAM
|
|
||||||
D-DIAGRAM
|
|
||||||
D-DIAGRAM
|
|
||||||
|
|
||||||
Users should feel generally satisfied with the UI. This is a
|
Users should feel generally satisfied with the UI. This is a
|
||||||
subjective quality that sums up the other user interface qualities
|
subjective quality that sums up the other user interface qualities
|
||||||
as well as aesthetics.
|
as well as aesthetics.
|
||||||
|
|
||||||
#### Security
|
### Security
|
||||||
|
|
||||||
The system should allow usage only by authorized users, and restrict
|
The system should allow usage only by authorized users, and restrict
|
||||||
usage based on permissions. The system should not allow users to
|
usage based on permissions. The system should not allow users to
|
||||||
@ -463,46 +454,31 @@ side-step security rule or exploit security holes. E.g., all user
|
|||||||
input should be validated and any malicious input should
|
input should be validated and any malicious input should
|
||||||
be rejected.
|
be rejected.
|
||||||
|
|
||||||
#### Reliability > Consistency under load
|
### Reliability > Consistency under load
|
||||||
D-DIAGRAM
|
|
||||||
D-DIAGRAM
|
Every system has some capacity limits. What happens when those
|
||||||
D-DIAGRAM
|
limits are exceeded? The system should never lose or corrupt data.
|
||||||
D-DIAGRAM
|
|
||||||
#### Reliability > Consistency under concurrency
|
### Reliability > Consistency under concurrency
|
||||||
|
|
||||||
Systems that allow concurrent access by multiple users, or that use
|
Systems that allow concurrent access by multiple users, or that use
|
||||||
concurrency internally, should be free of race conditions
|
concurrency internally, should be free of race conditions
|
||||||
and deadlock.
|
and deadlock.
|
||||||
|
|
||||||
#### Reliability > Availability under load
|
### Reliability > Availability under load
|
||||||
|
|
||||||
Every system has some capacity limits. What happens when those
|
Every system has some capacity limits. What happens when those
|
||||||
limits are exceeded? The system should continue to service those
|
limits are exceeded? The system should continue to service those
|
||||||
requests that it is capable of handling. It should not crash or sD-DIAGRAM
|
requests that it is capable of handling. It should not crash or stop
|
||||||
D-DIAGRAM
|
|
||||||
D-DIAGRAM
|
|
||||||
D-DIAGRAM
|
|
||||||
processing all requests.
|
processing all requests.
|
||||||
|
|
||||||
#### Reliability > Longevity
|
### Reliability > Longevity
|
||||||
|
|
||||||
The system should continue to operate as long as it is needed. ItD-DIAGRAM
|
The system should continue to operate as long as it is needed. It
|
||||||
D-DIAGRAM
|
should not gradually use up a limited resource. Example longevity
|
||||||
D-DIAGRAM
|
|
||||||
D-DIAGRAM
|
|
||||||
should not gradually use up a limited resource. Example longevityD-DIAGRAM
|
|
||||||
D-DIAGRAM
|
|
||||||
D-DIAGRAM
|
|
||||||
D-DIAGRAM
|
|
||||||
defects include memory leaks or filling the disk with log files.
|
defects include memory leaks or filling the disk with log files.
|
||||||
|
|
||||||
#### Efficiency
|
### Scalability
|
||||||
|
|
||||||
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
|
Scalability is a general quality that holds when the system
|
||||||
continues to satisfy its requirements when various usage parameters
|
continues to satisfy its requirements when various usage parameters
|
||||||
@ -510,13 +486,13 @@ 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.
|
number of users, or to very large files or very high capacity disks.
|
||||||
Several specific scalability goals are listed below.
|
Several specific scalability goals are listed below.
|
||||||
|
|
||||||
#### Scalability > Performance under load
|
### Scalability > Performance under load
|
||||||
|
|
||||||
This is a specific type of scalability goal dealing with the
|
This is a specific type of scalability goal dealing with the
|
||||||
performance of the system at times when it is servicing many
|
performance of the system at times when it is servicing many
|
||||||
requests from many users.
|
requests from many users.
|
||||||
|
|
||||||
#### Scalability > Large data volume
|
### Scalability > Large data volume
|
||||||
|
|
||||||
This is a specific type of scalability goal dealing with the ability
|
This is a specific type of scalability goal dealing with the ability
|
||||||
for the system to handle large data sets. Operations should continue
|
for the system to handle large data sets. Operations should continue
|
||||||
@ -524,7 +500,7 @@ to be correct and efficient as data set size increases. Furthermore,
|
|||||||
the user interface should still be usable as the data presented to
|
the user interface should still be usable as the data presented to
|
||||||
users increases in length.
|
users increases in length.
|
||||||
|
|
||||||
#### Operability
|
### Operability
|
||||||
|
|
||||||
The long-term needs of system administrators should be
|
The long-term needs of system administrators should be
|
||||||
reliably supported. E.g., is the system easy to install? Can the
|
reliably supported. E.g., is the system easy to install? Can the
|
||||||
@ -532,16 +508,16 @@ administrator recover from a crash? Is there sufficient log output
|
|||||||
to diagnose problems in the field? Can the system's data be backed
|
to diagnose problems in the field? Can the system's data be backed
|
||||||
up without downtime? Can the system be upgraded practically?
|
up without downtime? Can the system be upgraded practically?
|
||||||
|
|
||||||
#### Maintainability > Understandability
|
### Maintainability > Understandability
|
||||||
|
|
||||||
Will it be easy for (future) developers to understand how the system
|
Will it be easy for (future) developers to understand how the system
|
||||||
works?
|
works?
|
||||||
|
|
||||||
#### Maintainability > Evolvability
|
### Maintainability > Evolvability
|
||||||
|
|
||||||
Can the system easily be modified and extended over time?
|
Can the system easily be modified and extended over time?
|
||||||
|
|
||||||
#### Maintainability > Testability
|
### Maintainability > Testability
|
||||||
|
|
||||||
Can the system easily be tested? Do the requirements precisely
|
Can the system easily be tested? Do the requirements precisely
|
||||||
specify possible inputs and the desired results? Can the system be
|
specify possible inputs and the desired results? Can the system be
|
||||||
@ -549,7 +525,7 @@ tested in parts? When failures are observed, can they be traced back
|
|||||||
to defects in specific components (i.e., debugging)? Is testing
|
to defects in specific components (i.e., debugging)? Is testing
|
||||||
practical with the available testing tools?
|
practical with the available testing tools?
|
||||||
|
|
||||||
### Additional Standard Terms
|
## Additional Standard Terms
|
||||||
|
|
||||||
For additional standard terms, see the following reference sites:
|
For additional standard terms, see the following reference sites:
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user