<?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>「{iThome 書評} 從需求到設計—Exploring Requirements」的迴響</title>
	<atom:link href="http://www.kenming.idv.tw/a_cec_af_e_ap_a_deuseu_a_exploring_requi/feed" rel="self" type="application/rss+xml" />
	<link>http://www.kenming.idv.tw/a_cec_af_e_ap_a_deuseu_a_exploring_requi</link>
	<description>不用牽掛過去，不必擔心未來，踏實於現在，就與過去和未來同在！</description>
	<lastBuildDate>Fri, 10 Feb 2012 06:28:36 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>由：Kenming Wang</title>
		<link>http://www.kenming.idv.tw/a_cec_af_e_ap_a_deuseu_a_exploring_requi/comment-page-1#comment-2136</link>
		<dc:creator>Kenming Wang</dc:creator>
		<pubDate>Wed, 16 Jul 2008 22:50:47 +0000</pubDate>
		<guid isPermaLink="false">#comment-2136</guid>
		<description>Hi Patrick:&lt;br /&gt;
耶！ 先前不是回應過？&lt;br /&gt;
------------------------------------&lt;br /&gt;
&quot;Change&quot; 一直是軟體開發最大的議題。軟工會致力於如何 &quot;控制改變&quot;；而我倒是有另個想法， 如何讓系統 具備 &quot;應變&quot; 的彈性，也是另外一個方向的。 ^^</description>
		<content:encoded><![CDATA[<p>Hi Patrick:<br />
耶！ 先前不是回應過？<br />
&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;<br />
"Change" 一直是軟體開發最大的議題。軟工會致力於如何 "控制改變"；而我倒是有另個想法， 如何讓系統 具備 "應變" 的彈性，也是另外一個方向的。 ^^</p>
]]></content:encoded>
	</item>
	<item>
		<title>由：Patrick</title>
		<link>http://www.kenming.idv.tw/a_cec_af_e_ap_a_deuseu_a_exploring_requi/comment-page-1#comment-2135</link>
		<dc:creator>Patrick</dc:creator>
		<pubDate>Mon, 14 Jul 2008 20:03:56 +0000</pubDate>
		<guid isPermaLink="false">#comment-2135</guid>
		<description>I agree. The requirements are always changing and sometimes it contradicted each other. That&#039;s why there is a process called change management. After business owner has signed off the &quot;agreed&quot; requirements, any change request will go on change management process and it is very expensive to raise a change request after signed off.&lt;br /&gt;
&lt;br /&gt;
</description>
		<content:encoded><![CDATA[<p>I agree. The requirements are always changing and sometimes it contradicted each other. That&#8217;s why there is a process called change management. After business owner has signed off the "agreed" requirements, any change request will go on change management process and it is very expensive to raise a change request after signed off.</p>
]]></content:encoded>
	</item>
	<item>
		<title>由：Kenming Wang</title>
		<link>http://www.kenming.idv.tw/a_cec_af_e_ap_a_deuseu_a_exploring_requi/comment-page-1#comment-2133</link>
		<dc:creator>Kenming Wang</dc:creator>
		<pubDate>Mon, 02 Jun 2008 17:41:42 +0000</pubDate>
		<guid isPermaLink="false">#comment-2133</guid>
		<description>Hello sda:&lt;br /&gt;
軟體的重心在於人的調和與對系統的應變，此兩者一直是最重要的課題。 :)</description>
		<content:encoded><![CDATA[<p>Hello sda:<br />
軟體的重心在於人的調和與對系統的應變，此兩者一直是最重要的課題。 <img src='http://www.kenming.idv.tw/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>由：sda</title>
		<link>http://www.kenming.idv.tw/a_cec_af_e_ap_a_deuseu_a_exploring_requi/comment-page-1#comment-2134</link>
		<dc:creator>sda</dc:creator>
		<pubDate>Mon, 02 Jun 2008 15:17:10 +0000</pubDate>
		<guid isPermaLink="false">#comment-2134</guid>
		<description>The writing is great. It pin points real time problems the project team and the business owner. It is important for project team to understand how to manage the change requests even though during SIT and UAT stages.&lt;br /&gt;
</description>
		<content:encoded><![CDATA[<p>The writing is great. It pin points real time problems the project team and the business owner. It is important for project team to understand how to manage the change requests even though during SIT and UAT stages.</p>
]]></content:encoded>
	</item>
	<item>
		<title>由：Kenming Wang</title>
		<link>http://www.kenming.idv.tw/a_cec_af_e_ap_a_deuseu_a_exploring_requi/comment-page-1#comment-2132</link>
		<dc:creator>Kenming Wang</dc:creator>
		<pubDate>Mon, 25 Feb 2008 00:48:55 +0000</pubDate>
		<guid isPermaLink="false">#comment-2132</guid>
		<description>Hi Partick:&lt;br /&gt;
您所提貴單位的環境，比較像是傳統 2-tier 的模式，一般而言，那會比較重視功能的實作，而比較不具備應變的彈性。那麼，什麼又是 &quot;應變的彈性&quot; 呢？ 重視系統結構性元素的分析與設計，那是應變系統的根本所在！ 但是，諸多軟體公司，並不重視此，只重視現實需求的功能面實作，那是屬於短線式的作法。&lt;br /&gt;
&lt;br /&gt;
另您所提預算等問題，這與軟體人員素質亦有關係，兩者互為正因子。但以國內台灣，兩者都比較偏向負因子，而負+負越往負面循環之路走了。</description>
		<content:encoded><![CDATA[<p>Hi Partick:<br />
您所提貴單位的環境，比較像是傳統 2-tier 的模式，一般而言，那會比較重視功能的實作，而比較不具備應變的彈性。那麼，什麼又是 "應變的彈性" 呢？ 重視系統結構性元素的分析與設計，那是應變系統的根本所在！ 但是，諸多軟體公司，並不重視此，只重視現實需求的功能面實作，那是屬於短線式的作法。</p>
<p>另您所提預算等問題，這與軟體人員素質亦有關係，兩者互為正因子。但以國內台灣，兩者都比較偏向負因子，而負+負越往負面循環之路走了。</p>
]]></content:encoded>
	</item>
	<item>
		<title>由：Patrick</title>
		<link>http://www.kenming.idv.tw/a_cec_af_e_ap_a_deuseu_a_exploring_requi/comment-page-1#comment-2131</link>
		<dc:creator>Patrick</dc:creator>
		<pubDate>Sun, 24 Feb 2008 03:21:29 +0000</pubDate>
		<guid isPermaLink="false">#comment-2131</guid>
		<description>I read about both books you&#039;ve mentioned. They are great and I believe I did learn a lot from them. Some of ideas in these books I&#039;ve never thought about. The credit card company I work for is now using PEGA. The UI is written by JS, applet and certain parts that I am not too sure but it is linked to main frame (I think is Unix). We used to use main frame + sql database + a UI written from VB6 but it is kind of unstable.&lt;br /&gt;
&lt;br /&gt;
Back to your comment above, &quot;讓系統 具備 &quot;應變&quot; 的彈性&quot;. I would say, unless business can offer unlimited budget, it is almost impossible to build a system has such flexibility for future change. I mean, it is less challenge to build a system that business can add extra to existing functions. It is quite impossible to build a system that can be flexible to accept new functions especially a system is shared and used by different regions (eg. Asia Pacific, Australia and Europe). Am I understand it right in 具備 &quot;應變&quot; 的彈性? Please excuse if any misunderstanding as I am not good in mandarin.</description>
		<content:encoded><![CDATA[<p>I read about both books you&#8217;ve mentioned. They are great and I believe I did learn a lot from them. Some of ideas in these books I&#8217;ve never thought about. The credit card company I work for is now using PEGA. The UI is written by JS, applet and certain parts that I am not too sure but it is linked to main frame (I think is Unix). We used to use main frame + sql database + a UI written from VB6 but it is kind of unstable.</p>
<p>Back to your comment above, "讓系統 具備 "應變" 的彈性". I would say, unless business can offer unlimited budget, it is almost impossible to build a system has such flexibility for future change. I mean, it is less challenge to build a system that business can add extra to existing functions. It is quite impossible to build a system that can be flexible to accept new functions especially a system is shared and used by different regions (eg. Asia Pacific, Australia and Europe). Am I understand it right in 具備 "應變" 的彈性? Please excuse if any misunderstanding as I am not good in mandarin.</p>
]]></content:encoded>
	</item>
	<item>
		<title>由：Kenming Wang</title>
		<link>http://www.kenming.idv.tw/a_cec_af_e_ap_a_deuseu_a_exploring_requi/comment-page-1#comment-2130</link>
		<dc:creator>Kenming Wang</dc:creator>
		<pubDate>Tue, 15 Jan 2008 16:13:55 +0000</pubDate>
		<guid isPermaLink="false">#comment-2130</guid>
		<description>Hi Partick:&lt;br /&gt;
&quot;Change&quot; 一直是軟體開發最大的議題。軟工會致力於如何 &quot;控制改變&quot;；而我倒是有另個想法， 如何讓系統 具備 &quot;應變&quot; 的彈性，也是另外一個方向的。 ^^</description>
		<content:encoded><![CDATA[<p>Hi Partick:<br />
"Change" 一直是軟體開發最大的議題。軟工會致力於如何 "控制改變"；而我倒是有另個想法， 如何讓系統 具備 "應變" 的彈性，也是另外一個方向的。 ^^</p>
]]></content:encoded>
	</item>
	<item>
		<title>由：Patrick</title>
		<link>http://www.kenming.idv.tw/a_cec_af_e_ap_a_deuseu_a_exploring_requi/comment-page-1#comment-2129</link>
		<dc:creator>Patrick</dc:creator>
		<pubDate>Tue, 15 Jan 2008 09:58:58 +0000</pubDate>
		<guid isPermaLink="false">#comment-2129</guid>
		<description>The writing is great. It pin points real time problems the project team and the business owner. It is important for project team to understand how to manage the change requests even though during SIT and UAT stages.&lt;br /&gt;
&lt;br /&gt;
Just to add, the common failure in understanding the business requirements is due to the person who has been apointed as &quot;Subject Matter Expert&quot; not really a subject matter expert. This often leads to UAT test case limitation and lack of coverage in critical areas.</description>
		<content:encoded><![CDATA[<p>The writing is great. It pin points real time problems the project team and the business owner. It is important for project team to understand how to manage the change requests even though during SIT and UAT stages.</p>
<p>Just to add, the common failure in understanding the business requirements is due to the person who has been apointed as "Subject Matter Expert" not really a subject matter expert. This often leads to UAT test case limitation and lack of coverage in critical areas.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

