Agile Specification-Driven Development

Short Description
Traditional software development methods stress the elicitation and documentation of a “complete” set of requirements, followed by architectural and high-level design, coding, inspection and testing. This general approach is sometimes described as plan-driven development. Agile methods were a reaction to these traditional “documentation driven, heavyweight software development processes” [2], focusing on an iterative design process with rapid feedback in which code appears early [15].

Website: www-users.cs.york.ac.uk | Filesize: 77kb
No of Page(s): 9

Content
…
The conventional, systematic plan-driven approach to software development is inherited from systems engineering. Plan-driven development approaches, such as DbC, stress the elicitation and documentation of a complete set of requirements, followed by architectural and high-level design. Code and tests often appear at the tail end of the process. The gap between requirements and code is thus bridged by specifications, which describe constraints on behaviour shared between the physical world and the system. Iterations between writing specifications and coding are often encouraged. Incremental approaches to plan-driven development have been adopted, but all still emphasise documentation and traceability between requirements, specification, and code.
Plans can be written in a variety of ways, including structured natural language, UML class and sequence diagrams, and formal methods. There is an associated cost with applying mathematical techniques; in general, it is much more than testing with the benefit of obtaining higher quality [3]. The economic reality is that for most software development, testing and inspections trump formal specifications. In plan-driven approaches, complete documentation brings with it two main problems. First, there is the problem of keeping the documentation consistent with changes in the design and code. And second, there is the sheer volume of documentation that must be produced. Analysts must document the requirements, designers must create the design specifications, and programmers must document their code. At each stage, additional detail must be added as we do not know who will be reading the documentation; it may therefore be safer to err on the side of caution.
…

Get the file Download here