Learning from Failure, Part 1: Scoping and Requirements Woes

The paper is an editorial on software architecture. Software projects fail for the same reasons. The mistakes that can lead software projects to trouble before concrete architecture elaboration even begins include missing, wrong, or creeping system scope; and vague, unnecessary, or extreme nonfunctional requirements. These mistakes aren´t the prime responsibility of architects, but architects are directly affected if they occur because without an appropriate system scope and correspondingly appropriate requirements, they can´t define sustainable architectures. A system´s scope defines its responsibilities, but also its boundaries. Failing to define a precise system scope can result in architectures that support the wrong functionality, too much functionality, too many functionality variations, too few functions, or poor quality. Architects should pay special attention to nonfunctional requirements that too often include vague or unnecessarily extreme specifications. Without precision, architects must guess which nonfunctional qualities are actually needed, and if they must guess, they´ll likely guess wrong. An agile, incremental approach to software development define an initial system scope and set of requirements in a reasonable time and adjust this big picture step-wise until it has enough focus, substance, and clarity. Then, architects get concrete guidance for their work and can act rather than react when designing the system´s architecture. Only then do architects receive a safety network that allows them to identify and correct design flaws in their own area of responsibility.