Rapid prototyping and requirements specification using PDS
Proceedings of the workshop on Rapid prototyping
A methodology for minimizing maintenance costs
AFIPS '83 Proceedings of the May 16-19, 1983, national computer conference
| Hi-index | 0.00 |
Software development is a process which has evolved into a number of phases. Although the names of the phases and some of their characteristics differ from contractor to contractor and customer to customer, the functional similarities among sets of phases cannot be ignored. The basic software development scenario depicted by these phases starts with problem identification and definition, requirements specification, design, code, test, and installation and maintenance. Although some “smearing&rdquo of one phase activity into other(s) may occur, this represents the basic flow. However, it is just that smearing which occurs between requirements and design that we wish to explore here. Identifying or defining problems and solving problems are viewed by many to be separate, distinguishable activities. They are complementary in that one identifies what must be done (requirements) while the other depicts how it will be done (design). But software designers complain bitterly that requirements are poorly defined while customers and analysts often complain that the design is not responsive to the problem(s) as they perceive it. Somehow software designers end up discovering previously unknown requirements and end up solving a problem which is foreign to the customer. Is there a workable mechanism to reduce this difficulty?