http://tynerblain.com/blog/2005/11/26/telescopes-microscopes-and-macro-scopes-%e2%80%93-how-to-view-requirements/ Software product success. Thu, 18 Mar 2010 20:39:50 +0000 http://wordpress.org/?v=2.9.1 hourly 1 http://tynerblain.com/blog/2005/11/26/telescopes-microscopes-and-macro-scopes-%e2%80%93-how-to-view-requirements/comment-page-1/#comment-144 A requirements documentation mistake --Tyner Blain Wed, 25 Jan 2006 13:21:52 +0000 http://tynerblain.com/blog/2005/11/26/telescopes-microscopes-and-macro-scopes-%e2%80%93-how-to-view-requirements/#comment-144 [...] There were many mistakes made by many people. The one we’re talking about today has to do with documenting requirements at the right level of abstraction. [...] [...] There were many mistakes made by many people. The one we’re talking about today has to do with documenting requirements at the right level of abstraction. [...]

]]> http://tynerblain.com/blog/2005/11/26/telescopes-microscopes-and-macro-scopes-%e2%80%93-how-to-view-requirements/comment-page-1/#comment-136 From MRD to PRD: The key to defining a spec --Tyner Blain Tue, 24 Jan 2006 13:54:11 +0000 http://tynerblain.com/blog/2005/11/26/telescopes-microscopes-and-macro-scopes-%e2%80%93-how-to-view-requirements/#comment-136 [...] It can be a daunting task. First, we have to define what our customer needs. High level requirements are just requirements that are too vague or high-level to be directly actionable. “We must reduce our cost of fullfilling orders by 20%” is a high level requirement. We can’t start writing code with only that information. In an early post, we talked about functional requirements being written at the right level - don’t confuse the level of clarity required for writing a functional spec with that required to define goals. [...] [...] It can be a daunting task. First, we have to define what our customer needs. High level requirements are just requirements that are too vague or high-level to be directly actionable. “We must reduce our cost of fullfilling orders by 20%” is a high level requirement. We can’t start writing code with only that information. In an early post, we talked about functional requirements being written at the right level – don’t confuse the level of clarity required for writing a functional spec with that required to define goals. [...]

]]> http://tynerblain.com/blog/2005/11/26/telescopes-microscopes-and-macro-scopes-%e2%80%93-how-to-view-requirements/comment-page-1/#comment-35 Tyner Blain » Top five use case blunders Wed, 04 Jan 2006 08:20:03 +0000 http://tynerblain.com/blog/2005/11/26/telescopes-microscopes-and-macro-scopes-%e2%80%93-how-to-view-requirements/#comment-35 [...] Inconsistency. All the use cases we write need to be at the same level (macro-scopic, not microscopic or telescopic) and use the same format (narrative versus list, formal versus informal). Managing sub-use cases versus use cases is part of getting the level right. [...] [...] Inconsistency. All the use cases we write need to be at the same level (macro-scopic, not microscopic or telescopic) and use the same format (narrative versus list, formal versus informal). Managing sub-use cases versus use cases is part of getting the level right. [...]

]]> http://tynerblain.com/blog/2005/11/26/telescopes-microscopes-and-macro-scopes-%e2%80%93-how-to-view-requirements/comment-page-1/#comment-17 Tyner Blain » Composition in requirements Wed, 04 Jan 2006 07:42:03 +0000 http://tynerblain.com/blog/2005/11/26/telescopes-microscopes-and-macro-scopes-%e2%80%93-how-to-view-requirements/#comment-17 [...] In Telescopes, Microscopes, and Macro-scopes…, I stressed the importance of writing requirements at the right level of detail to avoid ambiguity. There is also a huge benefit to being able to group a set of requirements and talk about them as a single entity. [...] [...] In Telescopes, Microscopes, and Macro-scopes…, I stressed the importance of writing requirements at the right level of detail to avoid ambiguity. There is also a huge benefit to being able to group a set of requirements and talk about them as a single entity. [...]

]]>