<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: Part of the product</title>
	<atom:link href="http://www.onemanwrites.co.uk/2008/09/28/part-of-the-product/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.onemanwrites.co.uk/2008/09/28/part-of-the-product/</link>
	<description>musings on technical communications</description>
	<pubDate>Tue, 06 Jan 2009 23:04:50 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: VaishVijay</title>
		<link>http://www.onemanwrites.co.uk/2008/09/28/part-of-the-product/comment-page-1/#comment-6285</link>
		<dc:creator>VaishVijay</dc:creator>
		<pubDate>Mon, 29 Sep 2008 09:01:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.onemanwrites.co.uk/?p=213#comment-6285</guid>
		<description>Hi, from my experience I'd suggest that you should make documentation requests as a part of requirements. 

During SDLC, we too were facing similar problems. Often, after  releasing the help topics for user testing, we would be told that certain work around or tips is missing, as the business team would have missed to inform us! 

Then after much discussion and analysis we made documentation requirement as part of the System Specification document. Because of this we were able to play a more proactive role and content related defects were much reduced. Other benefits included:
 * We had a chance to look at the spec at a very early stage and hence able to help the team in terms of usability and design.
 * Collecting the the key tips/work around from the business people when everything is still fresh in their minds.

 * Able to come up with more accurate estimates.   

 * The writers and testing team had a clear expectation on help topics.</description>
		<content:encoded><![CDATA[<p>Hi, from my experience I&#8217;d suggest that you should make documentation requests as a part of requirements. </p>
<p>During SDLC, we too were facing similar problems. Often, after  releasing the help topics for user testing, we would be told that certain work around or tips is missing, as the business team would have missed to inform us! </p>
<p>Then after much discussion and analysis we made documentation requirement as part of the System Specification document. Because of this we were able to play a more proactive role and content related defects were much reduced. Other benefits included:<br />
 * We had a chance to look at the spec at a very early stage and hence able to help the team in terms of usability and design.<br />
 * Collecting the the key tips/work around from the business people when everything is still fresh in their minds.</p>
<p> * Able to come up with more accurate estimates.   </p>
<p> * The writers and testing team had a clear expectation on help topics.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
