Verification Requirements

[NOTE: It would appear that this page isn't all that useful in the general discussion of requirements. Specifically, the issues here are covered in other pages devoted to requirements and testing. This page, therefore, makes an excellent DeletionCandidate. Any thoughts?]

Isn't this a case of a Tree a Rope or a Wall? ItDepends, one person may see a requirement one way, and another person may perceive it another way. Verification is a way of discovering by AskingQuestions. Verification may indeed be one of the most important requirements. You have employed VerificationRequirements by specifying criteria and then asking the question "Any thoughts/" above. -- DonaldNoyes.20101222

Uhh...the tree, rope, and wall thing sorta eludes me...

 See: TreeRopeOrWall

Anyway, it would seem that there has been significant discussion already about the application of modern science to the collection, organization, and filtering of requirements. In specific, the bit about perceiving requirements differently by multiple parties in the requirements organization phase is neatly answered in PutaNumberOnIt. If requirements are quantified then they are very hard to misunderstand.

So, that sorta leads back to the question of whether this page really has any purpose any more...

This page might serve the purpose of AskingQuestions in such a way so that the QuestionsWeAsk will lead to a developed understanding of how we can determine what is required. It can serve this purpose by being a StartingPoint? and an EntryPoint? regarding the issue of Requirements. No such page yet exists to my knowledge.

The whole point being to determine goals everyone can agree upon and then know when that goal has been met.

As counterpoint, the entire goal of asking the right questions should be to assist the client in discovering what it is he wants the product to do and not how he wants the product to do it. How many of us have talked ourselves out of paying work because we offered an easier, off-the-shelf solution to some task that the client was willing to pay hard development cash to solve? It is incumbent upon our professional ethic to solve as many of the client's task issues this way as we can.

But at some point the client must arrive at the conclusion that his real need is different enough from previous products and their solutions that a new product must be developed to meet this new need. At that point we can help the client recognize those differences and formalize them into a set of written requirements so that everybody involved knows what we're talking about. Hopefully there won't be a need for "asking the right questions" (within reason) beyond that point.

I see what point you are making and what viewpoint you have from the above two paragraphs. My viewpoint is developed in the following:

• AskingQuestions
  • "How we do this is one of the most important things done in the process of discovery."
• QuestionsWeAsk
  • "Questions are posed to discover information that we feel may be important or relevant to our understanding of stuff. When we are AskingQuestions, we must ConsiderTheSource from which we are to discover answers, and to make our query clear and unambiguous."
• PutaNumberOnIt
  • "If you want to write a specification on how a product is to perform you need to do so in terms of measurable quanta, not vague qualitative assertions."
• AbstractModelsAnswerQuestions
  • "If I want to know how to use something, I like a model of it, a picture. What I don't want is to be given a list of how-to's for tasks I might want to undertake."
• ElicitingRequirements
  • "Engineers will always need to manufacture requirements. The important issue is that requirements are collected up-front and that the customer is involved in creating as many of the functional requirements as is possible. In most cases, the customer (especially if it is a marketing department) wants to define the features or overall feel of the system. They don't want to, nor should the have to, comprehend and dictate the optimal length or space between the threads of a screw."
• "AdoptingNewInventionAndInnovations"
  • Especially those which have found public acceptance in the way business is conducted and how money is spent and records are kept and maintained. No longer is it enough to keep all the currency and data in a cashbox and ledger "in the cloud".
    • http://blog.innovations-software.com
  • The place of open software, cheap hardware and software which maintained by purchases of consumable materials and services.

---

ExtremeRequirementsGathering

• "Requirements is a dialog, not a document. Also, programmers should make technical decisions, and business people should make business decisions. You will eventually get in trouble if this isn't true."

Counterpoint:

"Requirements is a dialog, not a document." This is possibly the single least understood fallacy about requirements that exists in the Agile/XP world. If the client is still changing his "mind" about what the product is while development is under way then the product is not only not specified correctly, it is still in discovery. Of course discovery is an ongoing part of creating any new product, but the limits on what is changeable and what isn't need to be set in stone long before actual development of a production product can begin. This is the point of establishing a hard baseline; without that the dev team can't create an unchanging architecture designed to address the base needs of the system.

---

Requirements for the amount of verification to be done. Examples:

• Tests to be developed to exercise all equivalence partitions
• Black box tests to be developed to achieve 100% statement coverage
• ....

---

Requirements are required by the various people involved in a Process or Project. The Requirments serve the basic purpose of what is wanted and who is responsible for seeing to it that they are fulfilled.

There are:

• Requirements Of Cost
  • http://www.hyperthot.com/pm_meth4.htm
• Requirements Of Time
  • http://www.noop.nl/2008/06/10-principles-of-agile-project-time-management.html
• Requirements Of Staging And Introduction
  • http://en.wikipedia.org/wiki/Product_life_cycle_management_(marketing)
  • http://www.valuebasedmanagement.net/methods_mcgahan_four_trajectories_industry_change.html
• Requirements Of Programming a System
  • ExtremeProgramming
    • http://en.wikipedia.org/wiki/Extreme_programming_practices
• Requirements Of Delivery
  • AgileDevelopment
    • http://www.accelerateddeliveryplatform.com/Default.aspx?Page=SmartDeliverables&NS=&AspxAutoDetectCookieSupport=1
• Requirments Of Training and Support for End Users
  • Microsoft Product Example
    • http://technet.microsoft.com/en-us/library/dd361920.aspx
• ...

Different people are responsible and the verification and management of the process and product falls generally on the ProjectManager and his or her delegates and agents. The bringing to market of a product is more complicated than simply writing and compiling code. The product when delivered needs to be UsefulUsableUsed.

---

Related: AbstractModelsAnswerQuestions

---

CategoryRequirements