Adjust header levels
This commit is contained in:
William Sandner
parent
0d20f4e5b1
commit
ff3bc57b27
@ -3,14 +3,14 @@
|
||||
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.html) for
|
||||
[ReadySET glossary](https://web.archive.org/web/20200701142616/http://readyset.tigris.org/templates/glossary-std.html) 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](#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
|
||||
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
|
||||
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
|
||||
to calculate subtotals or mD-DIAGRAMake specific decisions. That is to say,
|
||||
there is a hierarchy to theD-DIAGRAM templates: there are the main templates,
|
||||
and then worksheets for speD-DIAGRAMcific topics. We have divided the
|
||||
information into several fiD-DIAGRAMles so that each file is focused on one
|
||||
topic, and so that each filD-DIAGRAMe can be worked on by one person in a
|
||||
reasonable amount of time.D-DIAGRAM
|
||||
D-DIAGRAM
|
||||
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 impactD-DIAGRAM
|
||||
|
||||
The process impact box on eD-DIAGRAMach template explains where the current
|
||||
template fits into the softD-DIAGRAMware development process. It usually
|
||||
### 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
|
||||
### Checklist
|
||||
|
||||
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
|
||||
in those artifacts.
|
||||
|
||||
##### Sticky note
|
||||
### 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
|
||||
@ -71,7 +71,7 @@ types of sticky notes:
|
||||
After you have done what the sticky note says, you can delete the
|
||||
sticky note.
|
||||
|
||||
### Computer Science and Technology Terms
|
||||
## Computer Science and Technology Terms
|
||||
|
||||
##### ::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
|
||||
communications such as [SOAP](#soap) messages.
|
||||
|
||||
##### ::SOAP
|
||||
### ::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
|
||||
## 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
|
||||
particular release. Proposed changes are usually rejected if they
|
||||
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
|
||||
as the QA group and key customers.
|
||||
|
||||
##### Feature Complete
|
||||
### Feature Complete
|
||||
|
||||
A release is called "feature complete" when the development team
|
||||
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
|
||||
repair defects.
|
||||
|
||||
##### Code Complete
|
||||
### 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.
|
||||
@ -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
|
||||
future release.
|
||||
|
||||
##### Internal Release Number
|
||||
### 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 Number
|
||||
|
||||
External release numbers are the numbers that users see. Often, they
|
||||
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
|
||||
than "10.1" or "11".
|
||||
|
||||
##### Release Number
|
||||
### 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
|
||||
## Development Tool Terms
|
||||
|
||||
#### Version Control System
|
||||
### Version Control System
|
||||
|
||||
::DEFINITION1
|
||||
|
||||
#### Commit Log Message
|
||||
### Commit Log Message
|
||||
|
||||
::DEFINITION1
|
||||
|
||||
#### Issue Tracker
|
||||
### Issue Tracker
|
||||
|
||||
::DEFINITION1
|
||||
|
||||
#### Unit Testing Automation
|
||||
### Unit Testing Automation
|
||||
|
||||
::DEFINITION1
|
||||
|
||||
#### Automated Build System
|
||||
### Automated Build System
|
||||
|
||||
::DEFINITION1
|
||||
|
||||
#### Style Checker
|
||||
### Style Checker
|
||||
|
||||
::DEFINITION1
|
||||
|
||||
#### Source Code Formatter (Pretty Printer)
|
||||
### Source Code Formatter (Pretty Printer)
|
||||
|
||||
::DEFINITION1
|
||||
|
||||
#### System Test Automation
|
||||
### System Test Automation
|
||||
|
||||
::DEFINITION1
|
||||
|
||||
### Requirements Terms
|
||||
## Requirements Terms
|
||||
|
||||
#### Feature specification
|
||||
### 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
|
||||
@ -187,7 +187,7 @@ 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
|
||||
### 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
|
||||
@ -195,203 +195,200 @@ 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
|
||||
### Actor
|
||||
|
||||
A user or an external system that uses the system being built.
|
||||
|
||||
### Design Terms
|
||||
## Design Terms
|
||||
|
||||
#### ::TERM2
|
||||
### ::TERM2
|
||||
|
||||
::DEFINITION2
|
||||
|
||||
### Design Goals Terms
|
||||
## Design Goals Terms
|
||||
|
||||
#### Correctness
|
||||
### Correctness
|
||||
|
||||
This design correctly matches the given requirements.
|
||||
|
||||
#### Feasibility
|
||||
### Feasibility
|
||||
|
||||
This design can be implemented and tested with the planned amount of
|
||||
time and effort.
|
||||
|
||||
#### Understandability
|
||||
### Understandability
|
||||
|
||||
Developers can understand this design and correctly implement it.
|
||||
|
||||
#### Implementation phase guidance
|
||||
### Implementation phase guidance
|
||||
|
||||
This design divides the implementation into components or aspects
|
||||
that can correspond to reasonable implementation tasks.
|
||||
|
||||
#### Modularity
|
||||
### Modularity
|
||||
|
||||
Concerns are clearly separated so that the impact of most design
|
||||
changes would be limited to only one or a few modules.
|
||||
|
||||
#### Extensibility
|
||||
### Extensibility
|
||||
|
||||
New features or components can be easily added later.
|
||||
|
||||
#### Testability
|
||||
### Testability
|
||||
|
||||
It is easy to test components of this design independently, and
|
||||
information is available to help diagnose defects.
|
||||
|
||||
#### Efficiency
|
||||
### Efficiency
|
||||
|
||||
The design enables the system to perform functions with an
|
||||
acceptable amount of time, storage space, bandwidth, and
|
||||
other resources.
|
||||
|
||||
#### Ease of integration
|
||||
### Ease of integration
|
||||
|
||||
The components will work together.
|
||||
|
||||
#### Capacity matching
|
||||
### Capacity matching
|
||||
|
||||
The architecture deploys components onto machines that provide
|
||||
needed resources with reasonable total expense.
|
||||
|
||||
#### Expressiveness
|
||||
### Expressiveness
|
||||
|
||||
It allows for storage of all valid values and relationships
|
||||
|
||||
#### Ease of access
|
||||
### Ease of access
|
||||
|
||||
Application code to access stored data is simple
|
||||
|
||||
#### Reliability
|
||||
### Reliability
|
||||
|
||||
Stored data cannot easily be corrupted by defective code, concurrent
|
||||
access, or unexpected process termination
|
||||
|
||||
#### Data capacity
|
||||
### Data capacity
|
||||
|
||||
The system can store the amount of data needed.
|
||||
|
||||
#### Data security
|
||||
### Data security
|
||||
|
||||
Protection of sensitive user and corporate data from unauthorized
|
||||
access or modification
|
||||
|
||||
#### Performance
|
||||
### Performance
|
||||
|
||||
Data can be accessed quickly
|
||||
|
||||
#### Interoperability
|
||||
### Interoperability
|
||||
|
||||
The database or data files can be accessed and updated by other
|
||||
applications
|
||||
|
||||
#### Intrusion prevention
|
||||
### Intrusion prevention
|
||||
|
||||
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).
|
||||
|
||||
#### Auditability
|
||||
### Auditability
|
||||
|
||||
All changes can be accounted for later.
|
||||
|
||||
#### Understandability and learnability
|
||||
### 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
|
||||
### 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
|
||||
### Safety
|
||||
|
||||
Users are not likely to accidentally produce an undesired result
|
||||
(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
|
||||
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
|
||||
[defects](#defect). E.g., a developer might erroneously think that
|
||||
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
|
||||
function which allows negative numbers as arguments is defective.
|
||||
Defects can be removed by changing the source code, initial data,
|
||||
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
|
||||
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
|
||||
### Failure
|
||||
|
||||
*n.* The user-visible result of a [fault](#fault). E.g., an error
|
||||
_n._ The user-visible result of a [fault](#fault). E.g., an error
|
||||
message or an incorrect result. This is evidence that can be
|
||||
reported in a defect report. Developers use failure evidence during
|
||||
debugging to eventually find and remove [defects](#defect).
|
||||
|
||||
### QA Goals Terms
|
||||
## QA Goals Terms
|
||||
|
||||
#### Functionality > Correctness
|
||||
### 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
|
||||
### 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
|
||||
### 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
|
||||
### 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
|
||||
### 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
|
||||
D-DIAGRAM
|
||||
D-DIAGRAM
|
||||
D-DIAGRAM
|
||||
D-DIAGRAM
|
||||
#### Usability > Understandability and Readability
|
||||
|
||||
### 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
|
||||
@ -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
|
||||
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
|
||||
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
|
||||
accelerator key.
|
||||
|
||||
#### Usability > Task support
|
||||
### 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
|
||||
@ -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"?
|
||||
E.g., must users total their own tax deductions?
|
||||
|
||||
#### Usability > Efficiency
|
||||
### Usability > Efficiency
|
||||
|
||||
Users should be able to accomplish common tasks with
|
||||
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
|
||||
a very small button?
|
||||
|
||||
#### Usability > Safety
|
||||
### 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
|
||||
### 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
|
||||
@ -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.,
|
||||
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 anoD-DIAGRAM
|
||||
D-DIAGRAM
|
||||
D-DIAGRAM
|
||||
D-DIAGRAM
|
||||
chance that the user is dealing with another currency on that step
|
||||
in his/her task.
|
||||
|
||||
#### Usability > Subjective satisfactionD-DIAGRAM
|
||||
D-DIAGRAM
|
||||
D-DIAGRAM
|
||||
D-DIAGRAM
|
||||
### 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
|
||||
### Security
|
||||
|
||||
The system should allow usage only by authorized users, and restrict
|
||||
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
|
||||
be rejected.
|
||||
|
||||
#### Reliability > Consistency under load
|
||||
D-DIAGRAM
|
||||
D-DIAGRAM
|
||||
D-DIAGRAM
|
||||
D-DIAGRAM
|
||||
#### Reliability > Consistency under concurrency
|
||||
### 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
|
||||
### 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 sD-DIAGRAM
|
||||
D-DIAGRAM
|
||||
D-DIAGRAM
|
||||
D-DIAGRAM
|
||||
requests that it is capable of handling. It should not crash or stop
|
||||
processing all requests.
|
||||
|
||||
#### Reliability > Longevity
|
||||
### Reliability > Longevity
|
||||
|
||||
The system should continue to operate as long as it is needed. ItD-DIAGRAM
|
||||
D-DIAGRAM
|
||||
D-DIAGRAM
|
||||
D-DIAGRAM
|
||||
should not gradually use up a limited resource. Example longevityD-DIAGRAM
|
||||
D-DIAGRAM
|
||||
D-DIAGRAM
|
||||
D-DIAGRAM
|
||||
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
|
||||
|
||||
Scalability is a general quality that holds when the system
|
||||
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.
|
||||
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
|
||||
performance of the system at times when it is servicing many
|
||||
requests from many users.
|
||||
|
||||
#### Scalability > Large data volume
|
||||
### 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
|
||||
@ -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
|
||||
users increases in length.
|
||||
|
||||
#### Operability
|
||||
### Operability
|
||||
|
||||
The long-term needs of system administrators should be
|
||||
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
|
||||
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
|
||||
works?
|
||||
|
||||
#### Maintainability > Evolvability
|
||||
### Maintainability > Evolvability
|
||||
|
||||
Can the system easily be modified and extended over time?
|
||||
|
||||
#### Maintainability > Testability
|
||||
### Maintainability > Testability
|
||||
|
||||
Can the system easily be tested? Do the requirements precisely
|
||||
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
|
||||
practical with the available testing tools?
|
||||
|
||||
### Additional Standard Terms
|
||||
## Additional Standard Terms
|
||||
|
||||
For additional standard terms, see the following reference sites:
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user