More on requirements: a few simple rules

8/23/2010 6:52 PM EDT

These are admirable conditions. However, in the real world, things are a bit more gray than one would expect.

1. A requirement is unambiguous. OK ... unambiguous to the stake-holder(s) More often than not, the requirement is a derivative of many specification. What if one meets most of the specifications, and some are just darned near impossible to meet? Does one spend precious resources, miss time-to-market to get those specifications in-line?
2. A customer is willing to pay for it. Well, most marketing folks will tell you "If you only had this or ... that! Then I can get this customer to pay for it" ... aka Feature Creep!
3. Requirement testability ... we need to be careful here. I have seen many projects get torpedoed because we went overboard making certain all the tests passed ... only to find out later that we shot ourselves in the foot!

8/23/2010 8:08 PM EDT

I'm always in favor of a good quality requirements document. In most cases, it makes life a lot easier for everyone involved. I have worked in some environments where just a discussion starts off a development cycle and a number of discussions during development keep the project on track. That's a weird way to do it though and is too dependent on the cooperation and self-pacing skills of the engineers. In retail oriented OEM companies, the biggest challenge I've run across relates to your second rule: "A requirement is binding. The customer is willing to pay for it, and will not accept the system without it." A retail product tends to be judged and purchased based on a set of features. I like to say "there are features you can sell and features you can use." The fact that what you can sell and what can be used in a retail environment frequently makes the requirements document an object for fighting over.

8/26/2010 9:44 AM EDT

Unambiguous requirements is a good goal, and may not be practical. Some systems are so complicated that writing unambiguous requirements is not practical. The customer may not know what they want the system to do in all situations. Several iterations of the software can be finished in less time than that required to write unambiguous requirements. Sometimes I get more requirements from my customer by showing a prototype than I do from everything else. (This is good and we want to change ….) When I have good requirements, the customer may not like the result and will want to change the requirements.

8/26/2010 11:15 AM EDT

Requirements, specifications and their ilk are a fancy way for one firm to say to another firm - you have failed to fufill the contract. If and when consumer firms become willing to verify the producer firm's interpretation of the consumer's requirement/specification documents, then I will start to pay attention to this subject

8/26/2010 5:26 PM EDT

I would say requirement gathering is an art.And putting them down and keeping it updated is really a very big art. I have seen many time crucial requirements being missed out in documentation part because after its also a work of a human being. Of course there is no doubt if the person who is collecting requirement and making the document is well suited for the job and does his perfectly half of the marathon of project execution is complete. Many (90%) projects fail because either requirements were not understood properly or not documented properly.

8/27/2010 9:46 PM EDT

I think the hardest element of requirements writing is making them unambiguous, especially when the person writing them understands the product well. And the most important thing in getting to unambiguous requirements is agreeing on language. I reduced the three steps above to only 2 in my blog entry http://www.cypress.com/?rID=45668. Step 1 - use unambiguous language, for me that means a requirement uses the word "shall", not "will", not must", not "should". Any statement not using "shall" is information, and not binding. Step 2 - the statement as written (with a "shall") must be implementable and testable. This means the developers AND the testers must review the requirements (the "shalls") and agree on them. When these two steps are followed, marketing can search the document for "shall" and see exactly what the product will (only) do. And test/QA can do the same to find their test requirements. And developers can number the "shalls" and trace their code/implementation to it as they prepare the the inevitable changes.

8/31/2010 7:22 PM EDT

Requirements should also be consistent with each other, and standalone.
I believe that specifying functional requirements with statecharts is a good way to see if there are problems, using text is a sure way to misunderstandings and omissions.

10/23/2010 10:47 PM EDT

Nice to see a mention of formal methods. Formal methods not only raise the assurance on a design, they improve the specification as well.

We use formal tools to design and verify a chunk of safety critical code for an automotive controller. In addition to finding a handful of design defects, the tools have uncovered a set of conflicting, ambiguous requirements. Though the requirements were well written (concise, specific, testable), the nature of the conflicts was very subtle, making it extremely unlikely that the problems would have been found by testing alone.

Our experience using formal methods has shown that the design must be structured to facilitate the verification and vice versa. In other words, work on design and verification goes hand in hand. It is not practical to expect these methods to work in a setting where verification is offloaded to an independent test team. Then again, I don't think this works well for conventional software development either.

(For those that are interested, we use a Haskell DSL called ImProve: http://hackage.haskell.org/package/improve)

10/24/2010 5:20 PM EDT

For myself, a requirement should be quantifiable. This way i can both make it both unambiguous and testable.