Approved Requirements can still be incomplete and/or incorrect...
Me again.
I am looking into what I call a 'false positive', where a business manager/user reviews requirements, and approves them when they should not be approved yet. Two aspects of this are of interest:
1)the known difficulties in communicating requirements to various audiences, such that they truly understand them.
2)the documented requirements, and apparent knowldege of the Business Analyst on the subject of the project, are extensive enough and impressive-looking enough that users take them on without question. "It looks good, must be right!". The personality and projected confidence of the Business Analyst can contribute to this situation as well.
--> Current research on communicating requirements favors models over prose, and use of prototyping to help in analysis. Does anyone have other techniques used during requirements review that can help avoid getting a 'false positivre'?
We have 21+ ways to evaluate requirements adequacy
I find that even the best conventional definitions and reviews of requirements still tend to miss and misunderstand far more than ordinarily is recognized. In fact, much of creep that is attributed to “unforeseeable changes in the business†actually represents changing awareness of requirements (as contrasted with changing requirements) that could have and should have been identified but weren’t.
Given the choice between declaring inadequacies occur because it’s essentially impossible to define such extensively changing requirements or recognizing that much of creep is due to inadequacies of the requirements definers and their process, one shouldn’t be surprised that many people embrace the explanation that excuses responsibility for poor results.
In my book and related seminars, I describe more than 21 ways to review requirements adequacy. Most organizations tend to use only one or two of the techniques, typically ones that are far weaker than they realize. For example, well-intentioned and seemingly well-informed reviewers often miss many issues because they really don’t know what to do, how to do it, or how to tell how well they’ve done. Organizations ordinarily rely largely on the sources of the requirements to confirm they are right; but in fact we know it is hard for people to test their own work and to recognize their own mistakes and omissions. Other reviewers often lack sufficient subject area knoweldge.
Moreover, as we still see in the RQNG postings, the requirements community continues to miss the major source of creep—inadequately defining the REAL business requirements, generally because they persist in thinking that _the_ requirements are for the product or system they intend to create. When we later discover that use cases, prototypes, and other functioning software are incomplete or incorrect, it’s usually because they fail to meet the REAL business requirements because they haven’t been identified adequately.
The 21+ techniques include not only the familiar and fairly weak clarity/testability checking that deals mainly with form, but also ways to strengthen all reviews as well as many less-known additional more powerful methods for detecting wrong and overlooked requirements content issues.
Robin Goldsmith
gopromanagement [dot] com
robin
author of Discovering REAL Business Requirements for Software Project Success