Each requirement, when modeled, should be examined for: inconsistency, omissions, and ambiguity.

You also need to check for:

  • Is each requirement consistent with the overall objectives for the system or product?
  • Have all requirements been specified at the proper level of abstraction?
  • Is the requirement really necessary? Or does it represent an add-on feature that may not be essential to the objective of the system? (This may need to be negotiated.)
  • Is each requirement bounded and unambiguous?
  • Do any requirements conflict with other requirements?
  • Is each requirement achievable in the technical environment that will house the system or product?
  • Is each requirement testable, once implemented?
  • Does the requirements model properly reflect the information, function, and behavior of the system to be built?
  • Have requirements patterns been used to simplify the requirements model? Have all patterns been properly validated? Are all patterns consistent with customer requirements?

Requirements negotiation is often used to help ensure that requirements are reasonable, and can be met in a reasonable amount of time. You should look to a win-win situation, not a winner takes all contest.

Validating Requirements was originally found on Access 2 Learn

Assistant Professor

Walter Wimberly is an Assistant Professor at a regional college in Tennessee, teaching Computer Science in the Software Engineering track. He works as a student advisor, oversees curriculum changes, develops new courses, and manages the advisory panel.
Walter taught full time for about 7 years, before going back into “industry” as a full stack Software Developer for a dozen years. There he focused on web based projects coding in JavaScript/jQuery and utilizing the Bootstrap CSS Framework on the front-end, and coding in PHP, ASP/ASP.Net, SQL on the back-end.

Since he loves teaching, he taught as an adjunct web and digital media classes for eight (8) years, while working in industry, and has since returned to teaching full time.

He has been married for over 25 years, and is father to several special needs boys. As such, he is working on some projects to help others who have special needs to be self-sufficient, and support the care givers of those with special needs. Check out his Autism blog for more info.

Similar Posts

Reasons for Software Architecture

ByWalter Wimberly

Software Architecture is the structure, or structures, of the system that comprise of software components, the externally visible properties of the components, and the relationships among them. Architecture is not operational software, rather it is representative to allow you to see how effective your design is and consider alternatives. It focuses on components. It may…

Pattern-Based Design

ByWalter Wimberly

A design pattern can be characterized as “a three-part rule which expresses a relation between a certain context, a problem, and a solution” [Ale79] For software design, context allows the reader to understand the environment in which the problem resides and what solution might be appropriate within that environment. A set of requirements, including limitations and constraints, acts as…

Review Techniques

ByWalter Wimberly

Within the context of the software development, the terms defect and fault are synonymous. Both imply a problem that is discovered after the software has been released to end users. The book makes a distinction between error – a problem found before being released to the end user and defect or fault. However, in the real world,…