http://tynerblain.com/blog/2006/01/25/a-requirements-documentation-mistake/ Software product success. Sat, 19 May 2012 12:04:06 +0000 hourly 1 http://wordpress.org/?v=3.0.4 http://tynerblain.com/blog/2006/01/25/a-requirements-documentation-mistake/comment-page-1/#comment-278 Requirements vs design - which is which and why? -Tyner Blain Sat, 11 Feb 2006 19:43:30 +0000 http://tynerblain.com/blog/2006/01/25/a-requirements-documentation-mistake/#comment-278 [...] I understand how easy it is to let project realities affect the classification of some design elements as product requirements. I’ve personally made the mistake of taking that perspective to extremes in the past. [...] [...] I understand how easy it is to let project realities affect the classification of some design elements as product requirements. I’ve personally made the mistake of taking that perspective to extremes in the past. [...]

]]> http://tynerblain.com/blog/2006/01/25/a-requirements-documentation-mistake/comment-page-1/#comment-206 Software testing series: Top three measurements of quality -Tyner Blain Fri, 03 Feb 2006 03:40:06 +0000 http://tynerblain.com/blog/2006/01/25/a-requirements-documentation-mistake/#comment-206 [...] This developer perspective is a little misleading, however. To developers, if the software performs according to the spec, it meets the requirements, and is therefore good software. To a product manager, this could represent one of several requirements writing mistakes - the missing behavior should be there but it isn’t, because it was not documented in the spec. In short, the source of this bug is in the requirements. [...] [...] This developer perspective is a little misleading, however. To developers, if the software performs according to the spec, it meets the requirements, and is therefore good software. To a product manager, this could represent one of several requirements writing mistakes – the missing behavior should be there but it isn’t, because it was not documented in the spec. In short, the source of this bug is in the requirements. [...]

]]> http://tynerblain.com/blog/2006/01/25/a-requirements-documentation-mistake/comment-page-1/#comment-169 Describing the software development process -Tyner Blain Mon, 30 Jan 2006 02:28:58 +0000 http://tynerblain.com/blog/2006/01/25/a-requirements-documentation-mistake/#comment-169 [...] There are four roles in our framework, from identifying valuable opportunities to writing great code.  It is a good idea to combine design and implementation responsibilities in a senior person on the development team.  We would have avoided our requirement writing mistake if we had done that on our previous project.  Combining inbound and outbound product management responsibilities makes sense for smaller teams and exceptional individuals. [...] [...] There are four roles in our framework, from identifying valuable opportunities to writing great code.  It is a good idea to combine design and implementation responsibilities in a senior person on the development team.  We would have avoided our requirement writing mistake if we had done that on our previous project.  Combining inbound and outbound product management responsibilities makes sense for smaller teams and exceptional individuals. [...]

]]>