See system.
Acceptability is a combination of social
and practical acceptability. Practical acceptability is defined as cost,
support, reliability, compatibility, and usefulness.
[Nielsen 1993]
Architecture. The conceptual structure and
overall logical organization of a computer or computer-based system
from the point of view of its use or design; a
particular realization of this. [OED]
Component. One of the parts that make up a system. A component may be hardware or software and
may be subdivided into other components. Note: The terms "module",
"component", and "unit" are often used interchangeably or
defined to be sub-elements of one another in different ways depending upon the
context. The relationship of these terms is not yet standardized. [IEEE Std
610.12-1990]
Design. (1) The process of defining the architecture, components,
interfaces, and other characteristics of a system or component.
See also: architectural design; preliminary design; detailed design. (2) The
result of the process in (1). [IEEE Std 610.12-1990]
Design description. A document that
describes the design of a system or component. Typical contents include system or component architecture, control logic, data structures,
input/output formats, interface descriptions,
and algorithms. Syn: design document; design specification. See also: product
specification. Contrast with: requirements specification. [IEEE Std
610.12-1990]
Function (1) A defined objective or
characteristic action of a system or component. For example, a system
may have inventory control as its primary function. See also: functional requirement; functional specification;
functional testing. (2) A software module that
performs a specific action, is invoked by the appearance of its name in an
expression, may receive input values, and returns a single value. See also:
subroutine. [IEEE Std 610.12-1990]
Interface. (1) A shared boundary across which
information is passed. (2) A hardware or software component
that connects two or more other components for the purpose of passing
information from one to the other. (3) To connect two or more components for
the purpose of passing information from one to the other. (4) To serve as
connecting or connected component as in (2). [IEEE Std 610.12-1990]
Knowledge architecture can be
defined as information architecture plus contexts. Information architecture can
be defined as the architecture of a software system that provides for instance
organisation of, navigation within, labelling of, and search for information. (In this
context information architecture should not be understood as the architecture
of information, i.e. taxonomies,
typologies, classifications, etc.) When giving the information architecture a
context, the above examples change as follows. Organisation of information
becomes dynamic/task based/audience based categorisation. Navigation within
information becomes push&pull, connecting people, community of practice.
Labelling of information becomes process orientation, visual tools, personal
labels, communities of practice. Search for information becomes categorisation,
summarisation, personalisation, adaptive search. A knowledge architecture is
the architecture of a computer knowledge
management system featuring the above mentioned examples of knowledge management
support. [Infotoday]
Knowledge
object. In object-oriented programming, components
and functions are programmed using objects. An
object is an entity with attributes and methods. The idea is that an object
simplifies the code by making some of it internal (private), and only parts of
it visible to other objects (public).
A knowledge object is an object
that can be found in computer knowledge
management systems. Not all objects in a knowledge management system
are knowledge objects, but those that are knowledge objects play a role in the
knowledge management support that the system provides. For instance, the
knowledge object might have an attribute or a method that is necessary for the
system to fulfil its objectives.
The "knowledge"-part in the term
"knowledge object" does not refer to what the object consists of, but
rather what it is used to. A knowledge object consists of data (or information stored as
data), and it is part of a knowledge
architecture that supports knowledge management.
Module. One of a number of distinct, well-defined units from which a
computer program may be built up or into which any complex process or activity
is analysed (usu. for computer simulation), each of which is complete in itself
but bears a definite relationship to the other units. [OED]
Requirement refers to (1) A condition or
capability needed by a user to solve a problem or achieve an objective. (2) A
condition or capability that must be met or possessed by a system
or system component to satisfy a contract,
standard, specification, or other formally imposed documents. (3) A documented
representation of a condition or capability as in (1) or (2). [IEEE Std
610.12-1990]
Requirements should not be seen as pre-existing and just needing to be
'captured', but rather as needing to be constructed. Also, good practice advice
to distinguish between ‘issues’ that will be implemented and ‘issues’ that are
under consideration for implementation. Sometimes the former are called
‘requirements’, and the latter ‘needs’ – other times the former are termed
‘specifications’, and the latter ‘requirements’. Anyway, the main point is that
the decision point (for when it is decided to ‘include’ an issue) needs to be
clear.
Requirements Types
Design requirement. A requirement that specifies or constrains
the design of a system or system component. [IEEE Std 610.12-1990]
Functional requirement. A functional requirement
specifies a function that a system or system component must be able to perform. [IEEE Std
610.12-1990]
Implementation requirement. A requirement that
specifies or constrains the coding or construction of a system
or system component. [IEEE Std 610.12-1990]
Interface requirement. A requirement that
specifies an external item with which a system or
system component must interact, or that sets
forth constraints on formats, timing, or other factors caused by such an
interaction. [IEEE Std 610.12-1990]
Performance requirement. A requirement that imposes
conditions on a functional requirement; for example a requirement that
specifies the speed, accuracy, or memory usage with which a given function must
be performed. [IEEE Std 610.12-1990]
Physical requirement. A requirement that
specifies a physical characteristic that a system
or system component must possess; for example,
material, shape, size, weight. [IEEE Std 610.12-1990]
User requirement. An expression of a user need. What the user
need means from the standpoint of the system.
Specification. A document that specifies,
in a complete, precise, verifiable manner, the requirements, design, behavior,
or other characteristics of a system or component, and, often, the procedures for
determining whether these provisions have been satisfied. See also: formal
specification; product specification; requirements specification. [IEEE Std
610.12-1990]
Specification Types
Functional specification. A document that specifies
the functions that a system or component
must perform. Often part of a requirements specification. [IEEE Std
610.12-1990]
Performance specification. A document that specifies
the performance characteristics that a system or component must possess. These characteristics
typically include speed, accuracy, and memory usage. Often part of a
requirements specification. [IEEE Std 610.12-1990]
Product specification. (1) A document that
specifies the design that production copies of a system
or component must implement. Note: For
software, this document describes the as-built version of the software. See
also: design description. (2) A document that describes the characteristics of
a planned or existing product for consideration by potential customers or
users. [IEEE Std 610.12-1990]
Requirements specification. A document that specifies
the requirements for a system or component. Typically included are functional
requirements, performance requirements, interface requirements, design
requirements, and development standards. Contrast with: design description. See
also functional specification; performance specification. [IEEE Std
610.12-1990]
System A collection of components
organised to accomplish a specific function or
set of functions. [IEEE Std 610.12-1990] (see KM System)
Testing. (1) The process of operating a system or component
under specified conditions, observing or recording the results, and making an
evaluation of some aspect of the system or component. (2) The process of analyzing a software
item to detect the differences between existing and required conditions (that
is, bugs) and to evaluate the features of the software items. [IEEE Std
610.12-1990]
Usability refers to the extent to which a
product can be used by specified users to achieve
specified goals with effectiveness, efficiency, and satisfaction in a specified
context of use.
(ISO 9241-11)
Usefulness refers to a measure of whether the system can achieve a desired goal. Divided into
functional usefulness and usability. [Nielsen
1993]
User refers to an individual interacting with the system
(ISO 9241-10:1996)
User need refers to something the user lacks
or wants some necessary thing, or requires some extraneous aid or addition.
[OED]