Comments on: Intimate Domains – navigating areas of expertise http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/ Software product success. Thu, 18 Mar 2010 20:39:50 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: iRise - software prototyping tool -Tyner Blain http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/comment-page-1/#comment-181 iRise - software prototyping tool -Tyner Blain Wed, 01 Feb 2006 05:37:35 +0000 http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/#comment-181 [...] OK - now I’m getting concerned. Why is it a good idea to have non-experts specify the branding, layout, interaction design, and usability of a web-based application? Assuming that an expert business process modeler is at the helm, we can expect that high-level workflow is well designed. But the user experience? Show me a business expert who’s competent at designing interfaces and I’ll show you a switch-hitter currently occupying the chair of a business expert. [...] [...] OK – now I’m getting concerned. Why is it a good idea to have non-experts specify the branding, layout, interaction design, and usability of a web-based application? Assuming that an expert business process modeler is at the helm, we can expect that high-level workflow is well designed. But the user experience? Show me a business expert who’s competent at designing interfaces and I’ll show you a switch-hitter currently occupying the chair of a business expert. [...]

]]> By: A requirements documentation mistake --Tyner Blain http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/comment-page-1/#comment-142 A requirements documentation mistake --Tyner Blain Wed, 25 Jan 2006 13:01:04 +0000 http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/#comment-142 [...] The project was one that was designed to improve both management accounting and sales decision support processes for this large company. Understanding the objectives required relatively deep business domain expertise. Our development team did not have that expertise, and our business consultants were already overloaded with rainmaking and pathfinding activities. [...] [...] The project was one that was designed to improve both management accounting and sales decision support processes for this large company. Understanding the objectives required relatively deep business domain expertise. Our development team did not have that expertise, and our business consultants were already overloaded with rainmaking and pathfinding activities. [...]

]]> By: Tyner Blain » Where bugs come from http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/comment-page-1/#comment-125 Tyner Blain » Where bugs come from Sun, 22 Jan 2006 21:19:56 +0000 http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/#comment-125 [...] E3 - Misinterpreting the requirements. The developers can implement something that doesn’t match the requirements. This can happen in either be a faulty design or a faulty implementation. It may be that the developers didn’t understand the requirements (perhaps they were too vague or ambiguous), or it could be that they were incomplete and didn’t account for all of the possibilities. Validation of the requirements with the developers is critical to making sure that your spec is unambiguous and complete. Developers bring a level of rigor and analysis that can help you make a spec bullet-proof. Use their skills to fix a bad spec before it’s been signed off as “correct”. Even after you do all that, the implementation may not match the spec. That’s one reason why we test. E4 - Testing for the wrong implementation. Developers will create tests of their implementation. Unit tests are the most common example. A developer could incorrectly test their implementation (incomplete coverage, incorrect analysis). However, even good implementation tests can only make sure that what was intended (by the developer) was achieved. If the developer misunderstood the requirements, the test won’t assure that the desired outcomes are achieved. [...] [...] E3 – Misinterpreting the requirements. The developers can implement something that doesn’t match the requirements. This can happen in either be a faulty design or a faulty implementation. It may be that the developers didn’t understand the requirements (perhaps they were too vague or ambiguous), or it could be that they were incomplete and didn’t account for all of the possibilities. Validation of the requirements with the developers is critical to making sure that your spec is unambiguous and complete. Developers bring a level of rigor and analysis that can help you make a spec bullet-proof. Use their skills to fix a bad spec before it’s been signed off as “correct”. Even after you do all that, the implementation may not match the spec. That’s one reason why we test. E4 – Testing for the wrong implementation. Developers will create tests of their implementation. Unit tests are the most common example. A developer could incorrectly test their implementation (incomplete coverage, incorrect analysis). However, even good implementation tests can only make sure that what was intended (by the developer) was achieved. If the developer misunderstood the requirements, the test won’t assure that the desired outcomes are achieved. [...]

]]> By: Tyner Blain » Document proliferation http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/comment-page-1/#comment-116 Tyner Blain » Document proliferation Sat, 21 Jan 2006 04:45:54 +0000 http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/#comment-116 [...] I do disagree with Cote’ that some of these layers of documents exist to enable people who aren’t “technical enough” to participate.  Different people play different roles, and care about different information.  Communicating with these people, in their language, is critical. [...] [...] I do disagree with Cote’ that some of these layers of documents exist to enable people who aren’t “technical enough” to participate.  Different people play different roles, and care about different information.  Communicating with these people, in their language, is critical. [...]

]]> By: Tyner Blain » Are people reading your requirements? A blogversation. http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/comment-page-1/#comment-80 Tyner Blain » Are people reading your requirements? A blogversation. Wed, 11 Jan 2006 14:45:14 +0000 http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/#comment-80 [...] These techniques, while effective, are not sufficient. Making sure the writing is targeted at the audience, and reviewing the spec for changes (because from change you infer engagement) is certainly important. Getting stakeholders to put some skin in the game is also a great idea. But these are still primarily passive activities - worth doing, but there is more you can do. [...] [...] These techniques, while effective, are not sufficient. Making sure the writing is targeted at the audience, and reviewing the spec for changes (because from change you infer engagement) is certainly important. Getting stakeholders to put some skin in the game is also a great idea. But these are still primarily passive activities – worth doing, but there is more you can do. [...]

]]> By: Tyner Blain » Readability and requirements http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/comment-page-1/#comment-47 Tyner Blain » Readability and requirements Wed, 04 Jan 2006 08:42:59 +0000 http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/#comment-47 [...] The goal of writing a requirement is not pedantic accuracy, it’s effective communication. In addition to crossing domain-boundaries with the different audiences that consume our requirements, we often are crossing language barriers and varying educational levels. It’s hard enough conveying concepts that presume contextual knowledge, our readers shouldn’t have to parse the text repeatedly. [...] [...] The goal of writing a requirement is not pedantic accuracy, it’s effective communication. In addition to crossing domain-boundaries with the different audiences that consume our requirements, we often are crossing language barriers and varying educational levels. It’s hard enough conveying concepts that presume contextual knowledge, our readers shouldn’t have to parse the text repeatedly. [...]

]]> By: Tyner Blain » Secret decoder ring http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/comment-page-1/#comment-25 Tyner Blain » Secret decoder ring Wed, 04 Jan 2006 08:02:12 +0000 http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/#comment-25 [...] I’m having a little trouble reading the spec - I left my secret decoder ring at home! Ever hear that before? A set of requirements that makes perfect sense to one team member can be completely unintelligible to others. Requirements written in business-speak, or full of accounting jargon may be unintelligible to the development team. Unless you’ve staffed the dev team with switch-hitters, you have to provide supporting documents that explain this domain-specific information. [...] [...] I’m having a little trouble reading the spec – I left my secret decoder ring at home! Ever hear that before? A set of requirements that makes perfect sense to one team member can be completely unintelligible to others. Requirements written in business-speak, or full of accounting jargon may be unintelligible to the development team. Unless you’ve staffed the dev team with switch-hitters, you have to provide supporting documents that explain this domain-specific information. [...]

]]> By: Tyner Blain » A picture is worth a thousand requirements http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/comment-page-1/#comment-18 Tyner Blain » A picture is worth a thousand requirements Wed, 04 Jan 2006 07:52:37 +0000 http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/#comment-18 [...] OOA allows for clarity of communication, by creating descriptive and unambiguous documentation of requirements. It comes with a great big giant caveat – the consumers of the requirement need to know UML. This is usually not a problem for development teams, however stakeholders are also consumers of requirements – they have to validate that what you’ve documented expresses what they require. Without a tech-savvy stakeholder, this approach is unlikely to provide unambiguous documentation. [...] [...] OOA allows for clarity of communication, by creating descriptive and unambiguous documentation of requirements. It comes with a great big giant caveat – the consumers of the requirement need to know UML. This is usually not a problem for development teams, however stakeholders are also consumers of requirements – they have to validate that what you’ve documented expresses what they require. Without a tech-savvy stakeholder, this approach is unlikely to provide unambiguous documentation. [...]

]]> By: Tyner Blain » Agile Requirements http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/comment-page-1/#comment-15 Tyner Blain » Agile Requirements Wed, 04 Jan 2006 07:40:36 +0000 http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/#comment-15 [...] One of the key points that enables James’ approach is “tight collaboration” between the program manager and the developers. He talks about the “miracles” that can happen when you have this, as conversations can cause time to miraculously appear in the schedule. And his use of the toaster analogy is spot on. The key takeaway is that you must have a program manager who can interact with, and understand developers well enough to ask questions like “why is X so expensive?”. This is just one manifestation of the switch hitter archetype, the tech-savvy stakeholder, doing his job. In an awkward (non-agile) development process, your switch hitter may have to rely on reviews of design documents and documented assumptions to identify when money is being spent that shouldn’t. [...] [...] One of the key points that enables James’ approach is “tight collaboration” between the program manager and the developers. He talks about the “miracles” that can happen when you have this, as conversations can cause time to miraculously appear in the schedule. And his use of the toaster analogy is spot on. The key takeaway is that you must have a program manager who can interact with, and understand developers well enough to ask questions like “why is X so expensive?”. This is just one manifestation of the switch hitter archetype, the tech-savvy stakeholder, doing his job. In an awkward (non-agile) development process, your switch hitter may have to rely on reviews of design documents and documented assumptions to identify when money is being spent that shouldn’t. [...]

]]> By: Scott Sehlhorst http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/comment-page-1/#comment-11 Scott Sehlhorst Wed, 04 Jan 2006 07:28:53 +0000 http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/#comment-11 # Scott Sehlhorst said, December 28, 2005 at 10:59 pm · Edit Marcus has posted a complimentary article on his site at http://rationalizedthoughts.blogspot.com/2005/12/why-of-business-analysis.html It’s worth a read #

Scott Sehlhorst said,

December 28, 2005 at 10:59 pm · Edit

Marcus has posted a complimentary article on his site at http://rationalizedthoughts.blogspot.com/2005/12/why-of-business-analysis.html

It’s worth a read

]]> By: Tyner Blain » More on talking to your audience http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/comment-page-1/#comment-10 Tyner Blain » More on talking to your audience Wed, 04 Jan 2006 07:26:46 +0000 http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/#comment-10 [...] Kevin talks in particular about how to communicate with different team members as part of incorporating UI designs into the finished product - by understanding that you need to communicate with people in the language to which they are accustomed. I just wrote about this same topic at a general level in my recent post, Intimate domains. Kevin provides great specific suggestions along the same vein. [...] [...] Kevin talks in particular about how to communicate with different team members as part of incorporating UI designs into the finished product – by understanding that you need to communicate with people in the language to which they are accustomed. I just wrote about this same topic at a general level in my recent post, Intimate domains. Kevin provides great specific suggestions along the same vein. [...]

]]> By: Tyner Blain » Telescopes, microscopes, and macro-scopes – how to view requirements http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/comment-page-1/#comment-5 Tyner Blain » Telescopes, microscopes, and macro-scopes – how to view requirements Wed, 04 Jan 2006 07:01:56 +0000 http://tynerblain.com/blog/2005/12/02/intimate-domains-%e2%80%93-navigating-areas-of-expertise/#comment-5 [...] Maintain use of language that is clear to the customer [...] [...] Maintain use of language that is clear to the customer [...]

]]>