<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.4" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Tutorial#02 Functional and nonfunctional requirements</title>
	<link>http://www.stevenchoy.com/mt356f/tutorial02/</link>
	<description>Archiving the teaching of MT356F from September 2006 to May 2007</description>
	<pubDate>Thu,  8 Jan 2009 11:32:52 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.4</generator>

	<item>
		<title>by: ching_lam68</title>
		<link>http://www.stevenchoy.com/mt356f/tutorial02/#comment-12</link>
		<pubDate>Tue, 03 Oct 2006 13:53:32 +0000</pubDate>
		<guid>http://www.stevenchoy.com/mt356f/tutorial02/#comment-12</guid>
					<description>I'll pay more attention on the coming Lecture :-)</description>
		<content:encoded><![CDATA[<p>I&#8217;ll pay more attention on the coming Lecture <img src='http://www.stevenchoy.com/mt356f/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' />
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Steven Choy</title>
		<link>http://www.stevenchoy.com/mt356f/tutorial02/#comment-11</link>
		<pubDate>Tue, 03 Oct 2006 01:40:34 +0000</pubDate>
		<guid>http://www.stevenchoy.com/mt356f/tutorial02/#comment-11</guid>
					<description>"Functional requirements describe the interactions between the system and its environment independent of its implementation." (Page 125 of the textbook)

"Non-functional requirements describe aspects of the system that are not directly related to the functional behavior of the system. Non-functional requirements include a broad variety of requirements that apply to many different aspects of the system, from usability to performance." (Page 126 of the textbook)

We will have more discussions on these two concepts on Lecture #4.</description>
		<content:encoded><![CDATA[<p>&#8220;Functional requirements describe the interactions between the system and its environment independent of its implementation.&#8221; (Page 125 of the textbook)</p>
<p>&#8220;Non-functional requirements describe aspects of the system that are not directly related to the functional behavior of the system. Non-functional requirements include a broad variety of requirements that apply to many different aspects of the system, from usability to performance.&#8221; (Page 126 of the textbook)</p>
<p>We will have more discussions on these two concepts on Lecture #4.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: ching_lam68</title>
		<link>http://www.stevenchoy.com/mt356f/tutorial02/#comment-10</link>
		<pubDate>Fri, 29 Sep 2006 07:23:24 +0000</pubDate>
		<guid>http://www.stevenchoy.com/mt356f/tutorial02/#comment-10</guid>
					<description>Hi Steven!
Confuse with separate the functional and non-functional requirements.</description>
		<content:encoded><![CDATA[<p>Hi Steven!<br />
Confuse with separate the functional and non-functional requirements.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Steven Choy</title>
		<link>http://www.stevenchoy.com/mt356f/tutorial02/#comment-9</link>
		<pubDate>Wed, 27 Sep 2006 09:36:18 +0000</pubDate>
		<guid>http://www.stevenchoy.com/mt356f/tutorial02/#comment-9</guid>
					<description>IEEE Spectrum September 2005 Issue has a feature article on the issue why software fails (http://www.spectrum.ieee.org/sep05/1685). 

Why do software projects fail so often?

* Unrealistic or unarticulated project goals
* Inaccurate estimates of needed resources
* Badly defined system requirements
* Poor reporting of the project’s status
* Unmanaged risks
* Poor communication among customers, developers, and users
* Use of immature technology
* Inability to handle the project’s complexity
* Sloppy development practices
* Poor project management
* Stakeholder politics
* Commercial pressures</description>
		<content:encoded><![CDATA[<p>IEEE Spectrum September 2005 Issue has a feature article on the issue why software fails (http://www.spectrum.ieee.org/sep05/1685). </p>
<p>Why do software projects fail so often?</p>
<p>* Unrealistic or unarticulated project goals<br />
* Inaccurate estimates of needed resources<br />
* Badly defined system requirements<br />
* Poor reporting of the project’s status<br />
* Unmanaged risks<br />
* Poor communication among customers, developers, and users<br />
* Use of immature technology<br />
* Inability to handle the project’s complexity<br />
* Sloppy development practices<br />
* Poor project management<br />
* Stakeholder politics<br />
* Commercial pressures
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Steven Choy</title>
		<link>http://www.stevenchoy.com/mt356f/tutorial02/#comment-7</link>
		<pubDate>Tue, 26 Sep 2006 02:20:53 +0000</pubDate>
		<guid>http://www.stevenchoy.com/mt356f/tutorial02/#comment-7</guid>
					<description>Please go to &lt;a href="http://plbpc013.ouhk.edu.hk/mt356f/" rel="nofollow"&gt;plbpc013.ouhk.edu.hk&lt;/a&gt; to get the tutorial and discussion questions.</description>
		<content:encoded><![CDATA[<p>Please go to <a href="http://plbpc013.ouhk.edu.hk/mt356f/" rel="nofollow">plbpc013.ouhk.edu.hk</a> to get the tutorial and discussion questions.
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
