Attributes of the requirements element cover both the quality of the requirements specification and, also, the difficulty of implementing a system which satisfies the requirements.
The following attributes characterize the requirements element.
The stability attribute refers to the degree to which the requirements are changing and the possible effect changing requirements and external interfaces will have on the quality, functionality, schedule, design, integration, and testing of the product being built.
The attribute also includes issues which arise from the inability to control rapidly changing requirements. For example, impact analyses may be inaccurate because it is impossible to define the baseline against which the changes will be implemented.
Missing or incompletely specified requirements may appear in many forms, such as: a requirements document with many functions or parameters to be defined," requirements that are not specified adequately to develop acceptance criteria, or inadvertently omitted requirements. When missing information is not supplied in a timely manner, implementation may be based on contractor assumptions which differ from customer expectations.
When customer expectations are not documented in the specification, they are not budgeted into the cost and schedule. cannot be implemented because.
This attribute refers to ambiguously or imprecisely written individual requirements which are not resolved until late in the development phase. This lack of a mutual contractor and customer understanding may require rework to meet the customer intent for a requirement.
This attribute refers to whether the aggregate requirements reflect customer intentions for the product. This may be affected by misunderstandings of the written requirements by the contractor or customer, unwritten customer expectations or requirements, or a specification in which the end user did not have inputs.
This attribute is affected by the completeness and clarity attributes of the requirements specifications, but refers to the larger question of the system as a whole meeting customer intent.
The feasibility attribute refers to the difficulty of implementing a single technical or operational requirement, or of simultaneously meeting conflicting requirements. Sometimes two requirements are by themselves are feasible, but together are not; they cannot both exist in the same product at the same time.
Also included is the ability to determine an adequate qualification method for demonstration that the system satisfies the requirement.
The precedent attribute concerns capabilities that have not been successfully implemented in any existing systems or are beyond the experience program personnel or of the company. The degree of risk depends on allocation of additional schedule and budget to determine the feasibility of their implementation; contingency plans in case the requirements are not feasible as stated; and flexibility in the contract to allocate implementation budget and schedule based on the outcome of the feasibility study.
Even when unprecedented requirements are feasible, there may still be a risk of underestimating the difficulty of implementation and committing to an inadequate budget and schedule.
This attribute covers both technical and management challenges presented by large complex systems development.
Technical challenges include satisfaction of timing, scheduling and response requirements, communication among processors, complexity of system integration, analysis of inter-component dependencies, and impacts due to changes in requirements.
Management of a large number of tasks and people introduces a complexity in such areas as project organization, delegation of responsibilities, communication among management and peers, and configuration management.