Requirements analysis: Difference between revisions

Revision as of 19:15, 27 November 2004

Revision as of 19:24, 27 November 2004

Line 76:

Strengths:

* Provides a checklist of requirements.

* Provide a contract between the project sponsor(s) and developers.

Weaknesses:

* Such lists can run to hundreds of pages. It is virtually impossible to read such documents as a whole and have a detailedcoherent ideaunderstanding aboutof 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 difficultimpossible to identifysee which arehow the mostrequirements importantfit requirementstogether.

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

** This abstraction means that the more people who read such requirements the more different visions of the system you get.

** This abstraction means that it extremely difficult to be sure that you have the majority of the requirements. Necessarily, these documents speak in generality; but the devil as they say is in the details.

* These lists create a false sense of mutual understanding between the stakeholders and developers.

* These contract style lists give the stakeholders a false sense of security that the developers must achieve certain things. However, due to the nature of these lists, they inevitably miss out crucial requirements which are identified later in the process. Developers use these discovered requirements to renegotiate the terms and conditions in their favour.

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