📄 软件需求.htm
字号:
<P><STRONG> 5. 过于精简的规格说明</STRONG></P>
<P> 有时，客户并不明白需求分析有如此重要，于是只作一份简略之至的规格说明，仅涉及了产品概念上的内容，然后让开发人员在项目进展中去完善，结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明。这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况(McConnell
1996)，不过商业应用大多都不是这种情况。在大多数情况下，这会给开发人员带来挫折(使他们在不正确的假设前提和极其有限的指导下工作)，也会给客户带来烦恼(他们无法得到他们所设想的产品)。</P>
<P><STRONG> 6. 忽略了用户分<A
href="http://www.itisedu.com/phrase/200603090857555.html"
target=_new>类</A></STRONG></P>
<P> 大多数产品是由不同的人使用其不同的特性，使用频繁程度也有所差异，使用者受教育程度和经验水平也不尽相同。如果你不能在项目早期就针对所有这些主要用户进行分类的话，必然导致有的用户对产品感到失望。例如，菜单驱动操作对高级用户太低效了，但含义不清的命令和快捷键又会使不熟练的用户感到困难。</P>
<P><STRONG> 7. 不准确的计划</STRONG></P>
<P> “上述是我对新产品的看法，好，现在你能告诉我你什么时候能完成吗？”许多开发人员都遇到这种难题。对需求分析缺乏理解会导致过分乐观的估计，而当不可避免的超支发生时，会带来颇多麻烦。据报道，导致需求过程中软件成本估计极不准确的原因主要有以下五点：频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规格说明和不完善的需求分析(Davis
1995)。</P>
<P> 对不准确的要求所提问题的正确响应是“等我真正明白你的需求时，我就会来告诉你”。基于不充分信息和未经深思的对需求不成熟的估计很容易为一些因素左右。要作出估计时，最好还是给出一个范围(如最好的情况下，很可能的，最坏情况下)或一个可信赖的程度(我有9
0 %的把握，我能在8周内完成)。未经准备的估计通常是作为一种猜测给出的，听者却认为是一种承诺。因此我们要尽力给出可达到的目标并坚持完成它。</P>
<P><STRONG>四、什么是优秀的需求</STRONG></P>
<P> 讨论软件需求的文章有很多，对于需求的标准也不尽相同，这里我想用NASA的软件开发过程中的概念，软件需求过程的标准是：清楚(Clear)、完整(Complete)、一致(Consistent)、可测试(Testable)，此外还有其他的概念，如可跟踪的、可修改的等等。</P>
<P> 清楚：目前大多数的需求分析采用的仍然是自然语言（因为如果采用形式化语言的话，和用户的沟通将成为一个大问题，这意味着客户在开发软件之前必须先进行形式化语言培训，这是不现实的）。自然语言对需求分析最大的弊病就是它的二义性。所以我们不得不对需求分析中采用的语言做某些限制。例如尽量采用主语＋动作的简单表达方式。说白了，需求分析中的描述让人看上去像是刚学习写作的小孩子就对了，千万不要采用疑问句、修饰这些华丽的表达方式。</P>
<P> 除了语言的二义性之外，主意不要使用行话，就是计算机术语。需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。</P>
<P> 打个比方，如果你要做一个银行的信用卡系统，你就可以这样描述软件需求：银行的卡部管理信用卡，每张信用卡只属于一个帐户。信用卡有卡号、余额。一张信用卡有多笔的交易记录。</P>
<P> 完整：再也没有什么比软件开发接近完成是发现遗漏了一项需求更糟的事情了。需求的完整性是非常非常重要的，想象一下遗漏需求而不得不返工，这简直就是恶梦。可是令人遗憾的是，需求的遗漏是很经常发生的事情，不仅仅是你的问题，更多的问题发生在用户那里，他们不知道该做些什么。要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各方各面，贯穿了整个过程，从最初的计划制定到最后的需求评审。至于完整性的详细讨论，我们会在下面的章节中讨论，现在你只需要拼命的想象缺乏完整性的坏处，直到你出了一身的冷汗。出了吗？好，那我们继续。</P>
<P> 一致：一致性也是一个比较大的概念，很难用几句话讲清楚。还记得我们在开始的时候提到的需求的层次吗？简单的来说，就是用户需求必须和业务需求一致，功能需求必须和用户需求一致。严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。在实现过程中，我们还必须把一致性关系细化。比如说用户需求不能超出先前指定的范围。</P>
<P> 可测试：大家觉得一个项目的测试从什么时候开始呢？有人说从编码完成后开始。更清楚一点的说是编码的时候同时进行<A
href="http://www.itisedu.com/phrase/200602281036115.html"
target=_new>单元测试</A>，编码完成后进行系统测试。这些都没有错。但是实际上测试是从需求分析过程就开始了。需求分析是测试计划的输入和参照。这就要求需求分析是可测试的。什么是可测试呢？“我们要用新的系统完成报表自动化处理”，你觉得这个需求是可测试的吗？当然不是，报表包括哪些？自动化处理的标准是什么？这些在需求中都没有说明。因此这项需求是无法测试的，就是不具有可测试性。说到这里，大家可能就会明白之前的需求的几项标准都是为了保证需求的可测试性的。事实就是这样，只有系统的所有需求是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。</P>
<P><STRONG>五、软件需求过程</STRONG></P>
<P> 软件需求工程主要包括两个方面：需求开发和<A
href="http://www.itisedu.com/phrase/200603282323585.html"
target=_new>需求管理</A>。</P>
<P>
需求开发可进一步分为：需求获取、需求分析、编写需求规格和需求验证四个阶段。各阶段说明如下：</P>
<P><STRONG>
需求获取阶段：</STRONG><BR>
这一阶段的核心任务就是确定三个层次的需求，对于业务层要强调明确业务总目标及使用范围，对于用户层，要强调明晰用户<A
href="http://www.itisedu.com/phrase/200603110944215.html"
target=_new>工作流</A>程，对于功能层还要收集系统运行环境的限制等非功能性需求。不同的时间、不同的用户会由于不同的业务目标及使用范围而提出不尽相同的需求，同时由于没有约定提出方式也会有各不相同的表现形式。针对上述问题，首先要确定用户代表并对其在需求中的主次地位于以划分；其次要确定需求的整个开发过程，最后还要明确不同层次的需求要以约定的形式出具文档，以备双方的交流及问题检查。</P>
<P><STRONG>
需求分析阶段：</STRONG><BR>
这一阶段的核心任务就是确定并完善需求。初期阶段所获得的大量需求往往是不系统、不完整甚至个别需求是错误的、不必要的，只有通过提炼、分析和仔细审查需求，彼此沟通，采用适当的表现形式，比如绘制业务目标关联图、绘制功能结构示意图、编制数据字典、编写用户实例等，明白需求含义并找出其中的错误、遗漏或不足的地方，尤其是应采用特定符号标识需求优先级。</P>
<P><STRONG>
编写需求规格阶段：</STRONG><BR>
这一阶段的任务强调将已收集并做分析处理的需求经编制整理形成规范化的可视文档，即软件需求规格说明书。</P>
<P><STRONG>
需求验证阶段。</STRONG><BR>
本阶段是需求开发工作的最后阶段，要确定在第三阶段所编制的需求文档是否与预期结果一致，是否符合高质量需求的评价标准。这项工作可以通过评审来完成。评审可以根据用户代表的个人偏好、习惯予以审查需求，也可以遵循行业质量控制办法制定严格的步骤进行审查，这主要取决于项目的大小、需求及各个部分的重要程度。</P>
<P>
需求管理需要"建立并维护在软件工程中同客户达成的契约"。这种契约都包含在编写的需求规格说明与模型中。客户的接受仅是需求成功的一半，开发人员也必须能够接受他们，并真正把需求应用到产品中。</P>
<P>
通常的需求管理活动包括：<BR> 定义需求<A
href="http://www.itisedu.com/phrase/200603130850315.html"
target=_new>基线</A>(迅速制定需求文档的主体)。<BR>
评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。<BR>
以一种可控制的方式将需求变更融入到项目中。<BR>
使当前的项目计划与需求一致。<BR>
估计变更需求所产生影响并在此基础上协商新的承诺(约定)。<BR>
让每项需求都能与其对应的设计、源代码和测试<A
href="http://www.itisedu.com/phrase/200604240937105.html"
target=_new>用例</A>联系起来以实现跟踪。<BR>
在整个项目过程中跟踪需求状态从其变更情况。</P>
<P><STRONG>六、软件需求方法</STRONG></P>
<P> 软件需求分析方法大体分为如下四类：<A
href="http://www.itisedu.com/phrase/200602281749185.html"
target=_new>结构化方法</A>、<A
href="http://www.itisedu.com/phrase/200602281513385.html"
target=_new>面向对象方法</A>、面向控制方法和面向数据方法。限于篇幅，本文将主要从结构化方法和<A
href="http://www.itisedu.com/phrase/200603101726185.html"
target=_new>面向对象</A>方法以及<A
href="http://www.itisedu.com/phrase/200604231308415.html"
target=_new>RUP</A>三个方面进行简要的探讨。</P>
<P><STRONG>1、<A href="http://www.itisedu.com/phrase/200604232156585.html"
target=_new>结构化分析方法</A></STRONG></P>
<P> 结构化分折(Structured Analysis, <A
href="http://www.itisedu.com/phrase/200604240907255.html"
target=_new>SA</A>)方法是一种单纯的由顶向下逐步求精的功能分解方法。分析员首先用上下文图表(称为数据流图DFD)表示系统的所有输入／输出，然后反复地对系统求精，每次求精都表示成一更详细的DFD从而建立关于系统的一个DFD层次。为保存DFD中的这些信息，使用数据字典来存取相关的定义、结构及目的。SA方法是目前实际应用效力广泛的需求工程技术。它具有较好的分别、抽象能力，为开发小组找到了一种中间语言，易于软件人员所掌握。但它离应用领域尚有一定的距离，难以直接应用领域术民与软件设计也有一段不小的距离因而为开发小组的思想交流带来了一定的困难。</P>
<P><STRONG>2、<A href="http://www.itisedu.com/phrase/200604231254345.html"
target=_new>面向对象分析</A>方法</STRONG></P>
<P> 面向<A
href="http://www.itisedu.com/phrase/200603090845215.html" target=_new>对象</A>（<A
href="http://www.itisedu.com/phrase/200604231401015.html" target=_new>Object
Oriented</A>, <A href="http://www.itisedu.com/phrase/200604231401365.html"
target=_new>OO</A>）的方法把分析建立在系统对象以及对象间交互的基础之上，使得我们能以3个最基本的方法框架——对象及其属性、分类结构和集合结构来定义和沟通需求。面向对象的问题分析模型从3个侧面进行描述，即对象模型(对象的静态结构)、动态模型(对象相互作用的顺序)和功能模型(数据变换及功能依存关系)。需求工程的抽象原则、层次原则和分割原则同样适用于面向对象方法，即对象抽象与功能抽象原则是一样的，也是从高级到低级、从逻辑到物理，逐级细分．每一级抽象都重复对象建模(对象识别)一动态建模(事件识别)一功能建模(操作识别)的过程，直到每一个对象实例在物理(程序编码)上全部实现为止。</P>
<P>
面向对象需求分析(OORA)利用一些基本概念来建立相应模型，以表达目标系统的不同侧面。尽管不同的方法所采用的具体模型不尽相同，但都无外乎用如下五个基本模型来描述软件需求:</P>
<P>
整体—部分模型：该模型描述对象(类)是如何由简单的对象（类）构成的。将一个复杂对象(类)描述成一个由交互作用的若干对象(类)构成的结构的能力是OO途径的突出优点。该模型亦称聚合模型。</P>
<P>
分类模型：分类模型描述类之间的继承关系。与聚合关系不同，它说明的是一个类可以继承另一个或另一些类的成分，以实现类中成分的复用。</P>
<P>
类—对象模型：分析过程必须描述属于每个类的对象所具有的行为，这种行为描述的详细程度可以根据具体情况而定。既可以只说明行为的输入、输出和功能，也可以采用比较形式的途径来精确地描述其输入、输出及其相应的<A
href="http://www.itisedu.com/phrase/200603051002565.html"
target=_new>类型</A>甚至使用伪码或小说明的形式来详细刻画。</P>
<P> 对象交互模型：一个面向对象的系统模型必须描述其中对象的交互方法。如前所述，对象交互是通过<A
href="http://www.itisedu.com/phrase/200603090938465.html"
target=_new>消息</A>传递来实现的。事实人对象交互也可看作是对象行为之间的引用关系。因此，对象交互模型就要刻画对象之间的消息流。对应于不同的详细程度，有不同的消息流描述分析，分析人员应根据具体馆况而选择。一般地，一个详细的对象交互模型能够说明对象之间的消息及其流向，并且同时说明该消息将激活的对象及行为。一个不太详细的对象交互模型可以只说明对象之间有消息，并指明其流向即可。还有一种状况就是介于此两者之间。</P>
<P>
状态模型：在状态模型中，把一个对象看作是一个有限状态机，由一个状态到另一状态的转变称作状态转换。状态模型将对象的行为描述成其不同状态之间的通路。它也可以刻画动态系统中对象的创建和废除，并称由对象的创建到对象的废除状态之间的退路为对象的生存期。</P>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -