Comments on: Getting to Clear and Complete Requirements http://www.b2ttraining.com/2007/07/23/getting-to-clear-and-complete-requirements/ Connecting Business Requirements to Technology Wed, 28 Jul 2010 20:41:26 -0500 http://wordpress.org/?v=2.8.5 hourly 1 By: Kupe http://www.b2ttraining.com/2007/07/23/getting-to-clear-and-complete-requirements/comment-page-1/#comment-1024 Kupe Thu, 16 Aug 2007 19:00:59 +0000 http://www.b2ttraining.com/2007/07/23/getting-to-clear-and-complete-requirements/#comment-1024 Great comments! You know the question "How do you eat an 800 lb gorilla? Answer: One bite at a time. This concept so relates to what we do! Great comments! You know the question “How do you eat an 800 lb gorilla? Answer: One bite at a time.

This concept so relates to what we do!

]]> By: Marcus Gopalan http://www.b2ttraining.com/2007/07/23/getting-to-clear-and-complete-requirements/comment-page-1/#comment-1023 Marcus Gopalan Thu, 16 Aug 2007 17:19:29 +0000 http://www.b2ttraining.com/2007/07/23/getting-to-clear-and-complete-requirements/#comment-1023 To elaborate on that second point - producing drafts quickly and early touches upon the efficacy of the iterative process (or rather, itereative and incremental.) This basically points to a need to constantly elicit requirements continuously throughout the life cycle of a project in order to provide the most suitable product possible. The value will be seen as the business owner may not know everything he/she needs during the inception of the project. The danger herein, does of course lie in possible scope creep, as the boundaries are constantly being pushed. I believe this is a job for both the RA and PMO alike to keep track of and constantly asses where the project plan needs to be addressed. All in all, iterative projects of this sort have proven to be the most successful. To elaborate on that second point – producing drafts quickly and early touches upon the efficacy of the iterative process (or rather, itereative and incremental.) This basically points to a need to constantly elicit requirements continuously throughout the life cycle of a project in order to provide the most suitable product possible. The value will be seen as the business owner may not know everything he/she needs during the inception of the project. The danger herein, does of course lie in possible scope creep, as the boundaries are constantly being pushed. I believe this is a job for both the RA and PMO alike to keep track of and constantly asses where the project plan needs to be addressed. All in all, iterative projects of this sort have proven to be the most successful.

]]> By: Rajeev Singh http://www.b2ttraining.com/2007/07/23/getting-to-clear-and-complete-requirements/comment-page-1/#comment-1022 Rajeev Singh Wed, 01 Aug 2007 03:33:43 +0000 http://www.b2ttraining.com/2007/07/23/getting-to-clear-and-complete-requirements/#comment-1022 The first tip I have to share on documents is to get a template in place that has all the sections that have just the required information in it. A consitent format is great for all the consumers of information. They know where to look for what information.The, to some degree, insures that people will read the documents. To get a template in place, get feedback from all the consumers of any documents. Generally, it's the QA and the Dev groups. But, let's not forget that even BAs are, to an extent, the consumers. They have to refer back to these while taking care of enhancements, bug fixes, or at the time of ramping up new analysts on the proejcts. The second point about reviewing the documents early in the stage. To me, it seems, that it is wise to let the audience know that documents are work in progress and the intent of sharing them with early on is course correction, in case I am headed in the wrong direction, and making my thought process and understanding clear upfront. A mature group/organization doesn't treat this as a half baked requirement but a self-correctiing process consumable that is growing with the best possible feedback. The first tip I have to share on documents is to get a template in place that has all the sections that have just the required information in it. A consitent format is great for all the consumers of information. They know where to look for what information.The, to some degree, insures that people will read the documents. To get a template in place, get feedback from all the consumers of any documents. Generally, it’s the QA and the Dev groups. But, let’s not forget that even BAs are, to an extent, the consumers. They have to refer back to these while taking care of enhancements, bug fixes, or at the time of ramping up new analysts on the proejcts.

The second point about reviewing the documents early in the stage. To me, it seems, that it is wise to let the audience know that documents are work in progress and the intent of sharing them with early on is course correction, in case I am headed in the wrong direction, and making my thought process and understanding clear upfront. A mature group/organization doesn’t treat this as a half baked requirement but a self-correctiing process consumable that is growing with the best possible feedback.

]]>