需求工程——如何进行软件需求分析.htm

软件工程的课程设计帮助

            TBD或采用汉语拼音略写DQD）符号作为标准指示器来强调软件需求规格说明中这些需求的缺陷。通过这种方法，你可以在软件需求规格说明中查找所要澄清需求的部分。记录谁将解决哪个问题、怎样解决及什么时候解决。把每个TBD编号并创建一个TBD列表，这有助于方便地跟踪每个项目。<BR>&nbsp;&nbsp;&nbsp;&nbsp;在继续进行构造需求集合之前，必须解决所有的TBD问题，因为任何遗留下来的不确定问题将会增加出错的风险和需求返工。当开发人员遇到一个TBD问题或其它模糊之处时，他可能不会返回到原始需求来解决问题。多半开发者对它进行猜测，但并不总是正确的。如果有TBD问题尚未解决，而你又要继续进行开发工作，那么尽可能推迟实现这些需求，或者解决这些需求的开放式问题，把产品的这部分设计得易于更改。<BR>&nbsp;&nbsp;&nbsp;&nbsp;编写优秀的需求文档没有现成固定的方法，最好是根据经验进行。从过去所遇到的问题中可使你受益匪浅。许多需求文档可以通过使用有效的技术编写风格和使用用户术语而不是计算机专业术语的方式得以改进。<BR>你在编写优秀的需求文档时，希望读者还需牢记以下几点建议：<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            保持语句和段落的简短。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            采用主动语态的表达方式。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            编写具有正确的语法、拼写和标点的完整句子。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            使用的术语与词汇表中所定义的应该一致。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            需求陈述应该具有一致的样式，例如“系统必须..”或者“用户必须..”，并紧跟一个行为动作和可观察的结果。例如，“仓库管理子系统必须显示一张所请求的仓库中有存货的库存清单。”<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            为了减少不确定性，必须避免模糊的、主观的术语，例如，用户友好、简单、有效、、最新技术、优越的、可接受的等。当用客说“用户友好”或者“快”时，你应该明确它们的真正含义并且在需求中阐明用户的意图。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            避免使用比较性的词汇，定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值。当客户说明系统应该“处理”、“支持”或“管理”某些事情时，你应该能理解客户的意图。由于需求的编写是层次化的，因此，可以把顶层不明确的需求向低层详细分解，直到消除不明确性为止。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            文档的编写人员不应该把多个需求集中在一个冗长的叙述段落中。在需求中诸如“和”，“或”之类的连词就表明了该部分集中了多个需求。务必记住，不要在需求说明中使用“和/或”，“等等”之类的连词。<BR>
            <CENTER><B>8．需求分析的过程</B></CENTER>&nbsp;&nbsp;&nbsp;&nbsp;需求获取是在问题及其最终解决方案之间架设桥梁的第一步。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。参与需求获取者只有在他们理解了问题之后才能开始设计系统，否则，对需求定义的任何改进，设计上都必须大量的返工。把需求获取集中在用户任务上—而不是集中在用户接口上—有助于防止开发组由于草率处理设计问题而造成的失误。<BR>&nbsp;&nbsp;&nbsp;&nbsp;需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复的。当你和客户合作时，你就将会问一些问题，并且取得他们所提供的信息（需求获取）。同时，你将处理这些信息以理解它们，并把它们分成不同的类别，还要把客户需求同可能的软件需求相联系。然后，你可以使客户信息结构化，并编写成文档和示意图。下一步，就可以让客户代表评审文档并纠正存在的错误。这四个过程贯穿着需求开发的整个阶段。<BR>&nbsp;&nbsp;&nbsp;&nbsp;由于软件开发项目和组织文化的不同，对于需求开发没有一个简单的、公式化的途径。下面列出了1   
            4个步骤，你可以利用它们指导你的需求开发活动。对于需求的任何子集，一旦你完成了第十三步，那么你就可以很有信心地继续进行系统的每一部分的设计、构造，因为你将开发出一个好的产品:<BR>&nbsp;&nbsp;&nbsp;&nbsp;1.   
            定义项目的视图和范围。<BR>&nbsp;&nbsp;&nbsp;&nbsp;2.   
            确定用户类。<BR>&nbsp;&nbsp;&nbsp;&nbsp;3.   
            在每个用户类中确定适当的代表。<BR>&nbsp;&nbsp;&nbsp;&nbsp;4.   
            确定需求决策者和他们的决策过程。<BR>&nbsp;&nbsp;&nbsp;&nbsp;5.   
            选择你所用的需求获取技术。<BR>&nbsp;&nbsp;&nbsp;&nbsp;6.   
            运用需求获取技术对作为系统一部分的使用实例进行开发并设置优先级。<BR>&nbsp;&nbsp;&nbsp;&nbsp;7.   
            从用户那里收集质量属性的信息和其它非功能需求。<BR>&nbsp;&nbsp;&nbsp;&nbsp;8.   
            详细拟订使用实例使其融合到必要的功能需求中。<BR>&nbsp;&nbsp;&nbsp;&nbsp;9.   
            评审使用实例的描述和功能需求。<BR>&nbsp;&nbsp;&nbsp;&nbsp;10.   
            如果有必要，就要开发分析模型用以澄清需求获取的参与者对需求的理解。<BR>&nbsp;&nbsp;&nbsp;&nbsp;11.   
            开发并评估用户界面原型以助想像还未理解的需求。<BR>&nbsp;&nbsp;&nbsp;&nbsp;12.   
            从使用实例中开发出概念测试用例。<BR>&nbsp;&nbsp;&nbsp;&nbsp;13.   
            用测试用例来论证使用实例、功能需求、分析模型和原型。<BR>&nbsp;&nbsp;&nbsp;&nbsp;14.   
            在继续进行设计和构造系统每一部分之前，重复6~1   
            3步。<BR>需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户—开发者的合作才能成功。分析者必须建立一个对问题进行彻底探讨的环境，而这些问题与产品有关。为了方便清晰地进行交流，就要列出重要的小组，而不是假想所有的参与者都持有相同的看法。对需求问题的全面考察需要一种技术，利用这种技术不但考虑了问题的功能需求方面，还可讨论项目的非功能需求。确定用户已经理解：对于某些功能的讨论并不意味着即将在产品中实现它。对于想到的需求必须集中处理并设定优先级，以避免一个不能带来任何益处的无限大的项目。<BR>&nbsp;&nbsp;&nbsp;&nbsp;需求获取是一个需要高度合作的活动，而并不是客户所说的需求的简单拷贝。作为一个分析者，你必须透过客户所提出的表面需求理解他们的真正需求。询问一个可扩充的问题有助于你更好地理解用户目前的业务过程并且知道新系统如何帮助或改进他们的工作。<BR>需求获取利用了所有可用的信息来源，这些信息描述了问题域或在软件解决方案中合理的特性。一个研究表明：比起不成功的项目，一个成功的项目在开发者和客户之间采用了更多的交流方式。与单个客户或潜在的用户组一起座谈，对于业务软件包或信息管理系统（MIS）的应用来说是一种传统的需求来源。<BR>&nbsp;&nbsp;&nbsp;&nbsp;在每一次座谈讨论之后，记下所讨论的条目，并请参与讨论的用户评论并更正。及早并经常进行座谈讨论是需求获取成功的一个关键途径，因为只有提供需求的人才能确定是否真正获取需求。进行深入收集和分析以消除任何冲突或不一致性。尽量理解用户用于表述他们需求的思维过程。充分研究用户执行任务时作出决策的过程，并提取出潜在的逻辑关系。流程图和决策树是描述这些逻辑决策途径的好方法。<BR>&nbsp;&nbsp;&nbsp;&nbsp;当进行需求获取时，应避免受不成熟的细节的影响。在对切合的客户任务取得共识之前，用户能很容易地在一个报表或对话框中列出每一项的精确设计。如果这些细节都作为需求记录下来，他们会给随后的设计过程带来不必要的限制。你可能要周期性地检查需求获取，以确保用户参与者将注意力集中在与今天所讨论的话题适合的抽象层上。向他们保证在开发过程中，将会详尽阐述他们的需求。<BR>&nbsp;&nbsp;&nbsp;&nbsp;在一个逐次详细描述过程中，重复地详述需求，以确定用户目标和任务，并作为使用实例。然后，把任务描述成功能需求，这些功能需求可以使用户完成其任务，也可以把它们描述成非功能需求，这些非功能需求描述了系统的限制和用户对质量的期望。虽然最初的屏幕构思有助于描述你对需求的理解，但是你必须细化用户界面设计。<BR><FONT 
            color=red>作者小传：</FONT><BR><FONT 
            color=blue>&nbsp;&nbsp;&nbsp;&nbsp;曹伟，南京易点网络软件公司技术总监。从ERP的系统开发，对整体系统有较强的认识欲望，现正在实施企业级软件系统构架，实施一个国际化企业电子化的解决方案。</FONT></TD></TR></TBODY></TABLE></TD>
    <TD class=hui vAlign=top width=195>
      <SCRIPT language=JavaScript 
      src="需求工程——如何进行软件需求分析.files/ListJS.htm"></SCRIPT>
    </TD></TR>
  <TR>
    <TD class=hui14 align=middle colSpan=3><IFRAME id=Opinion name=id=Opinion 
      marginWidth=0 marginHeight=0 
      src="需求工程——如何进行软件需求分析.files/ArticleOpinion.htm" frameBorder=0 width="98%" 
      height=400>
	</IFRAME>
    </TD></TR></TBODY></TABLE></BODY></HTML>