Resolving the algorithms-as-requirements versus algorithms-as-design conundrum

This paper explores the origins and consequences of two inherent non-uniformities in the software systems engineering process: 1. An inherent non-uniformity of requirements "levels" in the beginning of the software systems requirements engineering process. 2. A resultant lack of parallelism between levels of refinement of abstraction in the expression of requirements and levels of refinement and decomposition in systems and software design. These non-uniformities are shown to be potentially contributing factors, possibly the principal contributing factors, to the "algorithms as requirements" versus "algorithms as design" conundrum, a key component of the "what" versus "how" distinction in software requirements versus software design documents that has never been as settled as we might wish it to have been. A reasonably rigorous argument is made that the first of these non-uniformities is related to an intrinsically ambiguous role for algorithms in the software systems engineering process and that it is intrinsic problem, not an artifact of poor requirements syntax in the various languages in which requirements are expressed. As the second problem, the lack of parallelism between levels of requirements and levels of design follows from the first, it too would seem therefore to be an intrinsic issue, not unique to any specific requirements or design methodology. To resolve the ambiguity and the problems it has lead to in software systems engineering processes, the necessity for a dualistic view of algorithms is proposed and the practical engineering consequences of the dualism are discussed. A careful set of semantics to distinguish between the dualism\´s alternatives is proposed and recommended for use in organizing and expressing requirements for software intensive systems.