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

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…

Characteristics of a Software Engineer

ByWalter Wimberly

Obviously mastering the technical aspects of software development are important. However, hopefully as you’ve seen from the class already, there is more to it than just “coding”. The book outlines 7 traits that they feel are necessary to be a good software engineer. Individual Responsibility Works to deliver on promises they make to their peers,…

Requirements Gathering

ByWalter Wimberly

The book calls this Eliciting Requirements. They should be done in a collaborative environment. Generally either face to face meetings and/or virtual meetings. Being done in real time allows for faster feedback than over an email/text/phone calls, etc. The meetings should include developers as well as other stakeholders. Rules and an Agenda for the meeting…

Construction Principles – Coding, Validating, and Testing

ByWalter Wimberly

Constructions (the Software Coding or Development Phase) can be broken down into several small phases. While Coding is only one part of Software Engineering, it is a large part, and part of being an engineer is being able to write good code! Preparation Make sure you understand the problem. Understand the basic design principles and…