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

Introduction to User Interface Design

ByWalter Wimberly

The user interface, or UI, is how a user interacts with an application. The application doesn’t matter if it’s a computer application, a mobile phone app, or even your microwave oven. The study of how people interact with computes/apps/etc is called Human Computer Interaction, or HCI. In his book on interface design, Theo Mandel [Man97]…

Planning Principles

ByWalter Wimberly

Communication helps you build and understand what your project is. Planning will help ensure that you can build that project. Understand the scope of the project – This lets you know where your end goal is going to be. Involve Stakeholders – Let them help identify priorities of features, potential deadlines, and even constants of…

Component Level Design

ByWalter Wimberly

Component-level design occurs after the first iteration of architectural design has been completed. At this stage, the overall data and program structure of the software has been established. A component is defined in UML as: “a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.” However, different…