SPaMCAST 49 - Goldsmith, Requirements – Part 2, A Game Plan For 2009
The Software Process and Measurement Cast provides a forum to explore the varied world of software process improvement and measurement. The SPaMCast covers topics that deal the challenges how work is done in information technology organizations as they grow and evolve. The show combines commentaries, interviews and your feedback to serve up ideas, options, opinions, advice and even occasionally facts.
Show Forty Nine concludes a two part interview with Robin Goldsmith
on requirements. If you have not already done so,
please go back to show 47 to listen to the first half of the
interview. Requirements are one of those foundational
components that can make or break a project as it gets
started. I believe that Robin's ideas and insights are
thought provoking and that you will find them useful.
Robin is the president of Go Pro Management. Go Pro
Management, Inc. is a consultancy that works directly with and
trains professionals in business engineering, requirements
analysis, software acquisition, project management, quality and
testing. Mr Goldsmith was previously a developer, systems
programmer/DBA/QA, and project leader with the City of Cleveland,
leading financial institutions, and a "Big 4” consulting
firm. He holds degrees from Kenyon College, A.B.;
Pennsylvania State University, M.S. in Psychology; Suffolk
University, J.D.; Boston University, LL.M. in Tax Law.
Robin is the author of the Artech House book, Discovering REAL
Business Requirements for Software Project Success, and numerous
articles in prominent periodicals, and frequent featured speaker at
leading professional conferences.
Web Site: http://www.gopromanagement.com
Phone: (781) 444-5753
Check out SPaMCAST"s Facebook page and get involved!!!!
The essay is titled “A Game Plan For 2009”. The essay looks
to 2009 or any moment where a line can be drawn as time to
celebrate change and decide to enrich the world around you (as well
re-invigorating your own brand).
There are a number of ways to share your thoughts with
• Email SPaMCAST at firstname.lastname@example.org
• Voice messages can be left at
• Twitter - www.twitter.com/tcagley
• BLOG – www.tcagley.wordpress.com
• FACEBOOK!!!! Software Process and
Next Software Process and
The next Software Process and Measurement Cast will feature an
David Andersen discussing organizational culture and embracing
agile, kanban and kaizen requirements and testing. This
interview covered a lot of ground and is very germane to the world
we find ourselves in today. Very very powerful, do not miss
over fourteen years ago
I don’t want to disagree with Robin’s methods; however, I don’t believe that he has “solved the problem of requirements quality.”
We are going to continue to have problems with requirements until we understand that all requirements are a translation of the users’ model of an idealized world into a language that engineers understand. We struggle with multiple problems here. First, the users must formulate a mental model of an idealized domain of use. They must then describe that model to the engineers. Next the engineers must translate that model into a set of requirements. The understanding for the second model will be incomplete unless the engineers are able to understand the users’ value proposition(s) for the new “system in use.” These requirements have to be tested for completeness and consistency with the users’ goals and values. Part of that consistency checking gets into the semantics of the language. It is relatively easy to use the same words but not share the same meaning. Language translation is particularly difficult. Finally, we have to recognize that the users’ idealized model will include some representation of the design and that may not represent the best design as it relates to the desired outcomes.
Modeling is the heart of the problem. A model is a tool for learning about something. Humans are wonderful tool builders and the most effective tool users (that we know about). However, we all have a tendency to overuse our most effective tools. As a result, developers have a (mental) model of how the users work and what the users believe is valuable based on the developers past experience. If we are entering any new user domain, it is likely that our current model has some significant holes – it does not represent either the way the new user works or how the service or function provided is valuable to the users’ stakeholders.
The best way to learn what the user and user stakeholder stuff value is to have someone versed in engineering language go forth and watch these users work. Ask their stakeholders and customers about perceived value of the services provided. The story that models this approach is the story of the Toyota minivan. Toyota’s first version of the minivan was a flop. Toyota sent the “chief engineer” on a tour of the country. He rode in minivans with mothers to watch how they used the minivan. The second version of the minivan was a huge success. This approach is significantly different and more expensive than asking “what the customer needs,” but it is precisely what is needed to understand what a new customer or new product needs to do. Focus groups and traditional requirements methods are not the same thing. We actually have to understand how and why our user is providing a service of value to his customer.
Philip Boxer and Bernie Cohen have been working this topic for a while. Their stuff is hard to read. It becomes most critical when we start thinking about the systems of systems concerns (such as services oriented architectures).
At any rate, as soon as we realize that requirements are themselves a model, we realize that the requirements model must be verified and validated. Validation of requirements means the customer checks the developer’s understanding of the requirements and why those requirements are important. Asking whether the developer understands the requirements is not sufficient. Developers and users must arrive at a common means of expression. This view – facing the engineer – of “validating the model” is opposite the view required for validating of the delivered product.