The attributes of the design element cover the design and feasibility of
algorithms, functions or performance requirements and of the internal and
external product interfaces. Difficulty in testing may begin here with failure
to work to testable requirements or to include test features in the
The following attributes characterize the design element.
This attribute covers functional requirements which may not submit to a
feasible design, or use of specified algorithms or designs without a high
degree of certainty that they will satisfy their source requirements.
Algorithm and design studies may not have used appropriate investigation
techniques or may show marginal feasibility.
The difficulty attribute refers to functional or design requirements that
may be extremely difficult to realize. Systems engineering may design a system
architecture difficult to implement, or requirements analysis may have been
based on optimistic design assumptions.
The difficulty attribute differs from design feasibility in that it does
not proceed from preordained algorithms or designs.
This attribute covers all hardware and software interfaces that are within
the scope of the development program including interfaces between
configuration items, and the existence of techniques for defining and managing
the interfaces. Special note is taken of non-developmental software and
developmental hardware interfaces.
The performance attribute refers to time critical performance: user and
real- time response requirements, throughput requirements, performance
analyses, and performance modeling throughout the development cycle.
The testability attribute covers the amenability of the design to testing,
design of features to facilitate testing, and the inclusion in the design
process of people who will design and conduct product tests.
f) Hardware Constraints
This attribute covers target hardware with respect to system and processor
architecture, and the dependence on hardware to meet system and software
performance requirements. These constraints may include throughput or memory
speeds, real-time response capability, database access or capacity
limitations, insufficient reliability, unsuitability to system function, or
insufficiency in the amount of specified hardware.
g) Non-Developmental Software
Since non-developmental software (NDS) is not designed to system
requirements, but selected as a best fit," it may not conform precisely to
performance, operability or supportability requirements.
The customer may not accept vendor or developer test and reliability data
to demonstrate satisfaction of the requirements allocated to NDS. It may be
then be difficult to produce this data to satisfy acceptance criteria and
within the estimated NDS test budget.
Requirements changes may be necessitate re-engineering or reliance on
vendors for special purpose upgrades.