Software project management under incomplete and ambiguous specifications

It is noted that large system development and government contracts still adhere to a classical life-cycle approach to software development. A major problem in the classical approach is the completeness and clarity of the user requirements. Some author shave suggested that alternative paradigms are more timely. One such paradigm is the use of prototype software models. The author believes that prototyping is an appropriate approach that can be used as a significant feature of the more formal life-cycle process, with little overall reduction in project control. He explores three aspects of such a development process. First, the underlying assumptions and the evolution of the current life-cycle management control method are discussed. The differing perspectives of the software designer and the user are discussed. A conceptual framework that graphically portrays this difference is proposed. Second, requirements are assumed to be ambiguous and incomplete. The contents of a requirements document are discussed with the perspective that requirements will always be incomplete until late in the development cycle. Third, prototyping activities have a primary objective of reducing ambiguity. Different prototyping strategies are appropriate for different phases of the development cycle. An altered life cycle (which includes prototyping as a format part of the process) is used to trace the evolution of the requirements document from an ambiguous objective to a system reference document.<
>