http://tynerblain.com/blog/2005/12/27/managing-requirements-conversations/ Software product success. Sun, 27 May 2012 14:59:31 +0000 hourly 1 http://wordpress.org/?v=3.0.4 http://tynerblain.com/blog/2005/12/27/managing-requirements-conversations/comment-page-1/#comment-115 Tyner Blain » Document proliferation Sat, 21 Jan 2006 04:43:55 +0000 http://tynerblain.com/blog/2005/12/27/managing-requirements-conversations/#comment-115 [...] Many people get so frustrated with all of these different ways to document requirements that they either look for a novel approach (or another here), or declare that requirements are counter-productive. The problem gets exacerbated when a bunch of former technologists attend a training class and start preaching the importance of (pick one of the docs above) without an understanding of the big picture. The current software-development outsourcing trend in the US has forced a lot of people to scramble to find new homes in the org chart. Cote’ is spot-on with his application of Conway’s law to this problem. [...] [...] Many people get so frustrated with all of these different ways to document requirements that they either look for a novel approach (or another here), or declare that requirements are counter-productive. The problem gets exacerbated when a bunch of former technologists attend a training class and start preaching the importance of (pick one of the docs above) without an understanding of the big picture. The current software-development outsourcing trend in the US has forced a lot of people to scramble to find new homes in the org chart. Cote’ is spot-on with his application of Conway’s law to this problem. [...]

]]> http://tynerblain.com/blog/2005/12/27/managing-requirements-conversations/comment-page-1/#comment-16 Tyner Blain » Agile Requirements Wed, 04 Jan 2006 07:40:55 +0000 http://tynerblain.com/blog/2005/12/27/managing-requirements-conversations/#comment-16 [...] Ultimately, it’s collaboration with the development team. And you have to rely on the developers to (be able to) tell you what assumptions they are making in their estimates / approaches. But unless they are really good - you also have to ask them. And for any non-trivial project, this means a ton of collaboration. And that’s a good thing. [...] [...] Ultimately, it’s collaboration with the development team. And you have to rely on the developers to (be able to) tell you what assumptions they are making in their estimates / approaches. But unless they are really good – you also have to ask them. And for any non-trivial project, this means a ton of collaboration. And that’s a good thing. [...]

]]>