Dec 28, 2008
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.
Contact information:
Web Site: http://www.gopromanagement.com
Email: RobinGoldsmith@cs.com
Phone: (781) 444-5753
Check out SPaMCAST"s Facebook page and get involved!!!!
http://tinyurl.com/62z5el
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 SPaMCAST:
• Email SPaMCAST at spamcastinfo@gmail.com
• Voice messages can be left at 1-206-888-6111
• Twitter - www.twitter.com/tcagley
• BLOG – www.tcagley.wordpress.com
• FACEBOOK!!!! Software Process and Measurement
http://tinyurl.com/62z5el
Next Software Process and Measurement Cast:
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 it.
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.