next previous contents
Next: KADS Up: Knowledge acquisition for requirements Previous: Knowledge acquisition for requirements

Introduction

Until recently, the requirements analysis part of the software development process had been rather left out in advances in the rest of software engineering. Many software systems never get to the stage of customer acceptance and prolonged use, and faulty or fatally limited requirements analysis is often the problem.gif

New specialist research in requirements engineering is making common ground with knowledge acquisition techniques developed in Knowledge Based Systems/Expert Systems work. This addresses the problem of getting domain expertise (whether of `experts' or not) into representations usable for subsequent design (or in our case, evaluation). NLP has its own methods, particularly for actual language analysis, and it might well be fruitful to treat these as analagous to experts in KBS design; however, the actual requirements for software systems must take into account more than the basic NLP performance of a system, and concentrate on the user task, where the best practice should be followed with more general methods.

One difficulty for adequacy evaluation (or indeed the design of mass-market rather than bespoke software systems) is that the needs of the user must be taken to be implied, since there are no extensionally defined users to state them. It is here that the requirements analysis process will be most different for adequacy evaluation as opposed to progress evaluation, since realistic requirements analysis for design usually requires dialogue with all stake-holders, prototypes and mockups to iteratively develop and test a description of the user's needs.

The following sections give a quick overview of KADS and related knowledge acquisition methods.



ceditor@tnos.ilc.pi.cnr.it