软件需求教程 软件需求分析方法

发布日期：2020-10-19

【需求定义】什么是需求领导让我做软件需求。

怎么弄呀

软件需求的定义 IEEE软件工程标准词汇表（1997年）中定义需求为： （1）用户解决问题或达到目标所需的条件或权能（Capability）。

(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。

（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。

需求的层次 下面这些定义是需求工程领域中常见术语的定义说明。

软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。

业务需求（ business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。

用户需求（user requirement） 文档描述了用户使用产品必须要完成的任务，这在使用实例（use case）文档或方案脚本（scenario）说明中予以说明。

功能需求（functional requirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

所谓特性（feature）是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。

软件需求各组成部分之间的关系如图所示。

作为补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。

它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。

所谓约束是指对开发人员在软件产品设计和构造上的限制。

质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。

多角度描述产品对用户和开发人员都极为重要。

计算机软件需求说明编制指南有哪些

1. 完整性 每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。

2. 正确性 每一项需求都必须准确地陈述其要开发的功能。

做出正确判断的参考是需求的来源，如用户或高层的系统需求规格说明。

若软件需求与对应的系统需求相抵触则是不正确的。

只有用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。

没有用户参与的需求评审将导致此类说法：“那些毫无意义，这些才很可能是他们所要想的。

”其实这完全是评审者凭空猜测。

3. 可行性 每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。

为避免不可行的需求，最好在获取（elicitation）需求（收集需求）过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。

4. 必要性 每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。

“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。

要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。

5. 划分优先级 给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。

如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度。

6. 无二义性 对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。

避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。

7. 可验证性 检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。

如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。

一份前后矛盾，不可行或有二义性的需求也是不可验证的。

软件需求说明书的主要作用是什么？

有电脑就可以，这电脑不必很高级的，很老的电脑可以编程，关键是你要精通各种计算机语言和编程技巧，还要有很强的数学和逻辑分析能力，还要有这个天分和兴趣还要有足够的时间，这些不是三言两语可以说明白，自学编程可能最少都要三年才能做一些小软件。

如果是要做一个真正的软件通常还要有一个漂亮的界面，做界面也要精通平面设计才才行，做平面设计的要有一定的美术基础。

做软件是靠完全靠脑袋的，其他软件和设备都只是辅助，做一个真正的软件不是有两个人可以做出来的，通常是要一个团队合作才可以。

要学习做软件,需要学习那些东西？

当几个需求模式有共同的特性，可以建立一个需求模式组，用于描述它们共同的方面，而不必在每个模式中重复。

一个需求模式组不是一个需求模式：不能建立这种类型的需求。

但是一个组可以包含下列出现在需求模式定义中的任何部分：“额外需求”，“开发考虑”，和“测试考虑”。

包括哪一部分而省略其他部分的原则是是否有一些事情值得说。

任何时候如果某一部分出现在了需求模式组里，模式的相应的部分应该包含一个注释，提醒参考需求模式组。

领域和需求模式组的区别在于领域中的模式共有一个主题，而在模式组中的模式有共同的细节特性。

一个组中的模式不一定属于同样的领域。

（对于熟悉Java编程的人，需求模式与领域的关系类似于类与包之间的关系：每个类属于一个包，就像每个模式属于一个领域。

同样，需求模式可以在属于不同领域的模式基础上开发，就像Java类可以继承自不同包的类。

软件和需求如何实践？

煮鸡蛋的启示 有个英国人学煮鸡蛋，开始，他把鸡蛋放到开水里煮时总会炸裂。

他为此想了各种方法，并找到了一个解决方案：在鸡蛋上打个孔。

但在鸡蛋上打孔带来了另一个问题：孔打小了，鸡蛋还会裂；孔打大了，蛋清会在它凝固以前流出来。

于是，这个英国人给一批鸡蛋分别打了各种不同孔径的洞，并记录下每个鸡蛋孔径的大小。

通过这一方法，他找到了一个最合适的大小──既避免了炸裂，又保证蛋清不会流出来。

这时，虽然煮鸡蛋炸裂的问题解决了，但这个英国人仍然不知道煮多长时间才能把鸡蛋煮熟。

为了解决这个问题，他又开始尝试煮不同时间的结果，并从中找出最佳的时间长度。

最后，他终于找到了一个放之四海而皆准的煮鸡蛋的方法。

这个案例对很多中国人来说是个可笑的例子。

因为聪明的中国人早就知道把鸡蛋放在水中与之一起加热至鸡蛋浮起来就可以了。

从煮鸡蛋这样一个小小的事件上，中国人和英国人体现了两种完全不同的思维习惯──中国人凭借他的聪明直奔结果，而英国人却仔细地把每一个过程细化到最简单，然后按部就班地执行。

（管理软件的发展之路 洪奇） 聪明的中国人虽然拥有四大发明，但是对于现代的管理思想，中国人一直没有领会到真谛所在。

无论是哪一种的管理方法，过程能力都是特别重要的，虽然生产一件产品的相关人员有千千万万，但是生产出来的产品却只有一种。

这种能力并不是从天上掉下来的，是通过制定极为详尽的生产过程规定得到的。

在中国接受了ISO的思想之后，这种能力也在国内的制造业中逐渐体现出来。

但是在软件行业中，拥有这种过程能力的软件组织仍然是少的可怜，大多数的软件组织奉行的还是一种在八九十年代的个人英雄主义，开发软件单靠个人的力量，能力强的程序员能够成功的完成软件，能力差的则失败。

大多数的软件组织中，少数人掌握着代码，他们就是一切，如果他们因为私人原因离开所在的组织，手上的代码则是他们的资本，原有的组织将受到沉重的打击。

中国人热衷于结果，2001年的热点在CMM上，现在还很难说CMM中是不是有一定的泡沫存在，但是可以肯定的一点是，CMM之进入中国软件组织为中国软件工业的发展开创了一个新的时代。

中国的软件工业将逐渐摆脱原来的作坊式开发，进入软件工业时代。

之所以用软件工业而不用软件产业的原因是希望软件产品能够像工业革命那样进入大规模生产，降低价格的时代。

可惜，软件毕竟不同于工业产品，在工业化生产的过程中，质量检测的一个方法是在产品出厂前设置质量检测，通过质量检测的出厂，否则回收。

这种方法无法适用于软件。

后来，质量检测逐渐倾向于生产过程，在过程中监测产品质量。

这种方法比起前一种方法进步了很多，但是它需要对生产全过程进行追踪。

这种方法的思想正是软件过程的质量保证的精髓所在。

在《软件工程》一书中，作者把软件工程分成三层，最底层是软件过程，上一层是软件方法，最高层是CASE工具。

软件过程中充满了各种各样的方法论，从需求到最后的维护。

要在自己软件组织中应用所有的方法是不可能的。

所以你如果看完软件工程的文章后有一种要在明天就实现现代化的冲动的话，打消那种念头，从零做起。

需求过程 需求过程是软件过程的一个很重要的部分。

软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的＂祸根＂（Leffingwell 1997）。

我在自己的身边也做过一次小范围的调查，结果显示成功的项目都离不开成功的需求（一个重要的标志是用户的支持）。

需求过程，也有叫做需求工程和需求阶段的，包括了需求开发和需求管理，他们所涉及到的具体工作流如图所示： 需求分析的这个过程，我们可以称它为需求工程，也有叫做需求过程和需求阶段的。

需求工程包括了需求开发和需求管理，他们所涉及到的具体工作流如上图标明的那样。

需求过程和CMM 软件工程协会 （SEI Softwae Engineeing Institude） 的能力成熟度模型 （CMM Capaility Matuity Model） 提供了一种著名的软件过程成熟度基准。

CMM 已经成为了许多领域内的流行工具，用于评估一个组织的软件过程的成熟程度。

（更详细的定义和说明请参看《CMM白皮书》）。

CMM中和需求有关系的是第2级（可重复级）中对需求管理的要求和第3级（已定义级）中对需求跟踪能力的要求。

必须指出的是，CMM只是规定成熟的软件组织应该达到的关键能力，是一种改进软件过程的策略，对具体的方法并没有做限制规定。

所以CMM中没有涉及到需求开发的内容。

需求过程和软件生命周期模型 任何软件都是从最模糊的概念开始的：为某个公司设计办公的流程处理；设计一种商务信函打印系统并投放市场。

这个概念是不清晰的，但却是最高层的业务需求的原型。

这个概念都会伴随着一个目的，例如在一个＂银行押汇系统＂ 的目的是提高工作的效率。

这个目的将会成为系统的核心思想，系统成败的评判标准。

99年政府部门上了大量的OA系统，学过一点Lotus Notes的人都发了财（IBM更不用说了），但是更普遍的情况是，许多的政府部门原有的处理模式并没有变化，反而又加上了自动化处理的一套流程...