Requirement Evolution

Over the time, The systems environment and the business objectives will almost certainly changed. The requirements must therefore evolve to reflect this.

From an evolution perspective, requirements fall into two classes:

  1. Enduring requirements :  These are relatively stable requirements which derive from the core activity of the organization and which relate directly to the domain of the system.
  2.  Volatile requirements :  These are requirements which are likely to change during the system development or after the system has been

Requirement Evolution

Controlled Evolution of Requirements

Controlled Evolution of Requirements

Requirements Validation

  • Requirements validation is concerned with showing that the requirements actually define the system which the customer wants.
  • Requirements validation is important because errors in a requirements document can lead to extensive rework costs when they are subsequently discovered during development or after the system is in service.

Requirements Validation – Checks

  • Validity checks  -  Systems have diverse users with different needs and any set of requirements is inevitably a compromise across the user community.
  • Consistency checks -  Requirements in a document should not conflict.
  • Completeness checks – The requirements document should include requirements which define all functions and constraints intended by the system user.
  • Realism checks  -  Using knowledge of existing technology, the requirements should be checked to ensure that they can actually be implemented.
  • Verifiability -  The requirements should be given in verifiable manner (eg; Using quantifiable measures)  to reduce the potential for dispute between customer and developer.

Requirements Validation - Techniques

  • Requirements Reviews -  The requirements are analalysed systematically by a team of reviewers.
  • Prototyping  -  In this approach to validation, an executable model of the system is demonstrated to end-users and customers. They can check whether the requirements satisfy their needs.
  • Test-case generation -  Requirements should ideally be testable.  If a test is difficult or impossible to design, this usually means that the requirements will be difficult to implement and should be reconsider.
  • Automated consistency analysis :  If the requirements are expressed as a system model in a structured or formal notation than CASE toolsmay be used to check the consistency of the model.