Requirements analysis: Difference between revisions

Revision as of 19:02, 27 November 2004

Revision as of 19:15, 27 November 2004

Line 72:

===Contract style requirement lists===

The most common way of documenting requirements has been contract style requirement lists. In a complex system such requirements lists can run to hundreds of pages. InAn addition,appropriate thesemetaphor requirementswould listsbe doan notextremely lendlong themselvesshopping to applicationlist. Such lists provideare avery checklistmuch forout theof eventualfavour systemin modern analysis; as they have proved spectacularly unsuccessful at achieving their aims; but they doare notstill helpseen into systemthis designday.

Strengths:

Such lists are very much out of favour in modern analysis; but they are still seen to this day.

* Provides a checklist of requirements.

Weaknesses:

* Such lists can run to hundreds of pages. It is virtually impossible to read such documents as a whole and have a detailed idea about the system.

* Such requirements lists abstract all the requirements and so there is little context to see how they fit together.

* This abstraction makes it difficult to identify which are the most important requirements.

* These requirements lists are no help in system design, since they do not lend themselves to application.

===Prototypes===