第4章需求工程

1SoftwareRequirements第4章需求工程（1）学习引导

本章介绍软件系统需求概念和发现并表达这些需求的多种方法。主要内容：用户需求和系统需求的概念以及这些需求要使用不同的方法表达的原因；功能需求和非功能需求之间的不同；需求如何组织在软件需求文档中。2软件的描述是复杂的，但没有大量的描述积累是不可能形成的，为此，我们必须从基本的描述入手，来尝试这种复杂描述的方法，才能找到克服复杂性的一些思路。如果你打算赋予某件事情注意力，就必须描述它，而且必须直接地描述它，特别是它所在的问题领域。3软件的问题就在于描述4程序设计软件设计社会学与人类学模糊精确局部全局部分精确，部分不精确很不精确很精确基本概念对服务和约束的发现、分析、建立文档、检验的过程叫做需求工程.什么是需求工程？什么是软件需求？开发软件所需要的各种条件。需求分析的任务是什么？需求分析的任务准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。并用<需求规格说明书>规范的形式准确地表达用户的需求。需求的层次和分类是什么？分两个层次：用户需求

系统需求分两类：功能需求非功能需求重要性需求获取困难一是用户需求的动态性(不稳定性)二是需求的模糊性(不准确性)三是需求必须得到用户的确认，否则毫无意义需求分析是发现、求精、建模、规格说明和复审的过程；需求分析是系统设计的基础，关系到工程的成败和软件产品的质量。需求分析的重要性及困难是什么？软件需求的层次:用户需求是用自然语言加图表的形式给出的关于系统需要提供哪些服务以及系统操作受到哪些约束的声明。系统需求详细地给出系统将要提供的服务以及系统所受到的约束。系统需求文档有时也称为功能描述，应该是精确的。它可能成为系统买方和软件开发者之间合同的重要内容。不同类型需求的读者对象不同类型的需求描述的读者用户需求和系统需求举例（1）1.MHC-PMS系统每月都要产生报告来显示当月每个诊所所开药物的成本。用户需求定义1.1在每个月的最后一个工作日,对新开的药物、药物成本以及开药诊所应该产生一个汇总报告;I.2系统应该在当月最后一个工作日的17:3O之后自动生成打印报告;I.3应该为每一个诊所生成一个报告,并列出各种药的药名、处方的总数、药物总量,以及所开药物的成本；I.4如果药物可以分为不同剂量单位(如10mg,mg),就要为每一剂量单位单独生成报告;I.5对所有成本报告的访问权限应只限于管理访问控制单上的授权用户。系统需求描述比较用户需求和系统需求举例（2）1.软件必须提供表达和访问外部文件的手段，这些外部文件是由其他工具创建的用户需求定义1．1为用户提供定义外部文件类型的工具1．2每种外部文件类型具有一个相关联的工具1．3每种外部文件类型在界面上用一种专门的图标来表示1．4提供一种工具，使用图标表示由用户定义的外部文件类型1．5当用户选择一个代表外部文件的图标时，选择的效果是将与该外部文件类型相关联的工具启动起来系统需求描述比较练习：请对校园网学生活动一卡通系统中的“IPQ统计分析”功能进行描述系统需求和用户需求。

一个软件系统的需求描述了系统应该做什么以及定义系统运行时和实现时的约束。134.1功能需求和非功能需求怎样开发软件？计算机以及运行于其上的软件是针对问题的解决方案；而问题则处于计算机以外的世界中。——所以，软件工程人员首先要懂得直接关注于问题，而不是径直进入对解决方案的设计。在研究解决方案之前，我们应该关注什么？——解决方案之前的问题，就是软件的需求问题。——开发者的失败发生在捕获和理解问题上，而不是设计和实现解决方案上。14什么是软件需求？一个软件系统的需求，描述了系统应该做什么以及定义系统运行时和实现时的约束需求。然而，“需求”这个术语在软件行业中使用得可能很不一致。——从用户的观点看，需求是系统应该提供的服务或对系统应该受到的约束；——从开发者的观点看，需求被定义为系统的功能，是采取详细的、甚至是用数学方法对软件功能的形式化描述。15还有一些观点，对于指导需求分析很有意义从过程文档的观点看，需求就是定义系统需要做什么而不是怎么做。这个观点对于“问题”格外关注，这是有益的。从表达方式看：一个需求是系统必须满足的单一的、可测量的目标，并使用清晰的文字来表达出每个需求。这个观点强烈希望需求的描述与设计的思考合为一体，这对于一些关键系统的需求分析有着指导意义。从最终结果看，需求是系统必须具有的特征，或者是客户可接受的、系统必须满足的约束。16我的观点需求的描述的结构、内容和形式，要努力靠近让软件体系结构设计环节的需要；软件体系结构的设计，要努力满足需求描述的那些特性和约束。17软件描述软件设计和实现过程推进例如，在设计阶段，体系结构设计是首要的任务，主要解决以下内容的决策：整个系统范围内，可以划分为哪些功能？即我们需要完成哪些系统功能？这些功能可以在哪些子系统内集成，从而提供特定的功能集或服务集？这些子系统又是分布在哪些商业运作节点/物理地点？这些子系统提供各自的哪些接口，如何衔接？为此，设计阶段要求其上一级的需求阶段提供相应的信息。18请看一个采用结构化方法给出的需求分析19干部队伍分析辅助决策支持系统

功能需求是有关系统一定要提供的服务或者是必须执行的计算的描述。领域需求是起源于其应用领域特性的功能需求。204.1.1功能需求关于功能需求的定义与解释何为功能？我们先看看计算机所能做到的操作功能：生成，如：创建、消除、分配、释放；连接，如：数据连接、程序连接、对象连接。；状态，如：激活、挂起、等待、消除、终止等。执行，如：程序执行、解释执行、过程调用等中断，如：中断请求、中断排队、中断分派等这些是需求要描述的功能吗？——不是。应该是来自系统模型描述的那些功能（见第5章系统模型，如上下文模型）21所以，我们就知道了功能需求应该描述什么1.功能需求是系统应该提供的服务、如何对输入做出反应以及系统在特定条件下的行为的描述。在某些情况下，功能需求可能还需明确声明系统不应该做什么。既然功能需求是用户所要使用的那个系统的需求，那么，用户为什么提出了那些功能需求呢？——为了解决用户领域中的一些问题。所以：2.领域需求这是来自系统的应用领域的需求，反映了该领域的特点。它们也可能是功能需求或非功能需求。22解释：领域问题先看一个词汇：Stakeholders，意思是“有利害关系的人”。通常，软件系统的投入/废弃，其影响将涉及到各类Stakeholder，或者说，是这些Stakeholder的利益目标追求的导致了软件系统的投入。通过开发和运行某个软件系统，来保证Stakeholder的利益目标追求，是软件需求的根本所在。Stakeholders的问题，就是所谓的“领域问题”。关注领域问题，才能获得真正的需求——所谓的“用户需求分析”，其实只是一些业务人员从业务视角提出的信息收集和整理的需求。23关于功能需求的示例大学图书馆系统LIBSYS的几种功能需求这个系统为学生和教工从其他图书馆借阅图书和文献提供服务：1.用户能从总的数据库中查询或者是选择其中的一个子集。——查询功能2.系统能提供适当的浏览器供用户阅读馆藏文献。——浏览功能3.每次借阅能对应一个独特的识别符（ORDER_D），可拷贝到用户账户的常备储存区内。——读者管理功能思考：从上述功能需求可以看到什么领域需求？24领域需求描述的一个例子例如一个图书馆系统的需求：1。需要一个基于Z39.50标准的、面向所有数据库的标准用户界面。2。因为版权限制，一些文档只能根据用户需要输出到本地打印机或网络打印机上。关于版权法对图书资料保护的需求，描述了一类文档打印完立即删除的功能功能需求

非功能需求约束所开发的系统和所采用的开发过程。它们可能是产品需求、机构需求或者是外部需求。这些需求与系统的总体特性相关，且作用于系统整体。264.1.2非功能需求“非功能需求”这个概念的由来功能需求的“功能”，来自“解决问题的设备”中的“功能”——即该设备可观察到的行为。“非功能”指的是与“解决问题的设备”中的“功能”无关的需求。这是一种误解——误导了人们只关注“功能”而不关注所谓的“非功能”——认为“非功能”与“功能”无关，至少非功能需求是被认为是次要的。——对非功能需求的描述要求不严格，是模糊的和主观的，对它们也只是给予它模糊和主观的关注。272.非功能需求对系统提供的服务或功能给出的约束。包括时间约束、开发过程的约束、标准等。非功能需求常用于整个系统。通常不用在单个系统或服务中。单个的非功能需求,比如一个信息安全性需求,可能会产生数个相关的功能性需求,这些功能性需求定义了新系统所要求的服务。非功能需求可能描述系统的性能、信息安全性、可用性和其他总体特性。这就意味着它们比功能需求对系统更关键。28非功能需求的分类非功能性需求示例（1）

——MHC-PMS中的非功能需求实例

产品需求MHC-PMS系统必须对所有诊所在正规工作时间内(周一至周五,08:30-17:30）都是可用的，任何一天的正规工作时间内系统的关闭时间不应超过5秒钟。机构需求MHC-PMS系统的用户应该使用他们的卫生局身份证件来验证自己。外部需求系统必须依照法律Hstan-03-2006–priv贯彻病人隐私条款。非功能性需求示例（2）

——图书馆系统LIBSYS的几个非功能需求产品方面：4.C.8它应该能将所有APSE和用户之间的必需的通信用标准的Ada字符集表达——这是一个约束：要求该系统必须能够保持Ada语言程序设计支持环境（APSE）下具有符合该环境的标准字符集。机构方面：9.32系统开发过程和可交付的文档将遵照XYZCo-SP-STAN-95中的相关定义——这也是一个约束：指定了系统的项目文档所应遵守的标准外部需求：7.6.5系统不应该对系统的操作人员公开客户除名字和索引代码之外的任何个人信息。——这是信息安全要求31非功能需求的检验举例系统应该很好用，即使对一个没有经验的用户，而且应该使得用户错误降到最少系统目标对一个没有经验的用户来说，经过两个小时的培训就应该能使用系统的所有功能。在这样的培训之后，一个有经验的用户每天的出错平均数不应超过两次可检验的非功能需求非功能需求的检验非常困难，用定量化的描述来衡量非功能需求是否达到目标是一种不错的办法。指定非功能需求的度量指定非功能需求的度量目标依赖语句的百分数目标系统的数目失败后重启时间事件引起失败的百分数失败中数据崩溃的概率平均失败时间；不可用的概率失败发生频率；可用性培训时间帮助帧数兆字节数ROM芯片数处理的交易/秒；用户/事件响应时间；屏幕刷新时间度量可移植性鲁棒性可靠性易用性规模速度属性非功能需求和功能需求之间的关系非功能需求和功能需求之间会产生冲突，比如性能的要求和目标之间。3D画面，容量与功能等等。P56举例。尽管非功能需求和功能需求在文档困难，尽量分开叙述，易于采用不同的指标分析功能是否达到要求。不能分开的视具体系统情况而定，可以采用折中办法。

用户需求是为面向购买和使用系统的用户而写的。应该使用自然语言、表格或图表的形式给出，以便用户容易理解。36用户需求和系统需求的比较

系统需求想要达到能以准确的方式表述系统必须提供的功能。为减少二义性，可以采用某种结构化自然语言辅之以表格和系统模型给出。关于用户需求的描述

站在用户的角度来描述系统功能和非功能需求只描述系统的外部行为，要尽量避免对系统设计特性的描述。使用自然语言、图表和直观的图形描述的内容是“中、高层次”的概念及其下的功能为。示例——LIBSYS应该提供交易记费系统以维护用户的所有支付记录。系统管理员会配置此系统使得长期用户会得到折扣。37关于系统需求的描述系统需求是对用户需求的扩展内容，主要描述系统的外部行为和对它的操作上的限制，不包括系统应该如何设计和如何实现。主要的描述内容给出系统的初始的体系结构，借助这个框架来构造需求描述。然后按照构成系统的不同子系统结构来给出细节层次上更完善的定义。系统和其他已存在的系统存在互操作。38说明系统需求是比用户需求更详细的需求描述，是系统实现的基本依据。因此，是一个完全的和一致的系统描述，是软件工程人员系统设计的起点。系统需求描述可能包括许多不同模型，如对象模型和数据流模型。用户需求和系统需求的描述，共同构成需求文档——在需求分析后期，软件人员要编写出需求分析报告来提交给用户看。在需求文档中先概要地描述用户需求；再使用模板描述系统需求；添加额外信息到自然语言的需求描述中——采用表格形式或图形模型形式给出描述40

软件需求文档是经过认可的系统需求描述。它应该被很好地组织，以便既可以供系统客户使用又可以供软件开发者使用。414.2软件需求文档

要制订专门的需求描述标准，与需求文档相关的IEEE标准是一个合适的起点。软件需求文档（softwarerequirementspecification,SRS）是给系统开发者看的、对应当实现的内容的正式陈述。——注意，这可不是需求分析报告。软件需求文档是软件项目组的第一个软件文档，需要有一个统一的，符合开发组织特点的文档模板（企业标准）教材中给出了基于IEEE标准的需求文档模板，表4-7给出了这个需求文档的结构说明42软件需求文档4.3需求描述系统需求是比用户需求更详细的需求描述，是系统实现的基本依据。因此，是一个完全的和一致的系统描述，是软件工程人员系统设计的起点。需求描述就是在需求文档中写下用户需求和系统需求。系统需求描述可能包括许多不同模型，如对象模型和数据流模型。原则上讲，系统需求应该陈述系统应该做什么而不包括系统应该如何实现。然而，在细节层次上会提到设计信息.书写用户需求应该遵守的原则设计一个标准的格式，保证所有的需求定义都按照该格式书写。这种格式包括对初始需求描述的扩展、用户需求的基本原理以及详细的系统需求描述的索引。使用一致的语言。尤其要区别强制性和希望性的需求。定义强制性需求时要使用“必须”，定义希望性需求时使用“应该”。对文本加亮（使用黑体或斜体）来突出显示关键性的需求。尽量避免用计算机专业术语。但不可避免地会用到应用领域的专业术语。自然语言的问题(NL)不够清楚使用语言时有时候很难精确、清楚的描述需求混淆功能与非功能需求可能会产生混淆需求混合将好几种不同需求一同表示Dogsmustbecarried.Shoesmustbeworn.（〔乘车时〕鞋子必须穿上）（〔乘车时〕必须穿着鞋子）（〔乘车时〕必须把鞋子穿在脚上）（〔乘车时〕狗必须抱着）（〔乘车时〕必须抱着狗）（〔乘车时〕必须把狗抱在身上）NL的表现到１９９９年底，它还欠款１０００元。自行车还没有修好，修车的急坏了。北京图书馆收藏着章太炎的书。

这辆车没有锁。

巴勒斯坦游击队对以色列的进攻是早有准备的。………………NL規格的替代表示法结构化语言结构化语言描述判定表判定树窗体式规格（1）结构化语言描述结构化语言使用的词汇进行了限制，并且可以使用固定的模板来定义系统的需求。例如：结构化英语结构化英语的词汇表由英语命令动词数据词典中定义的名字有限的自定义词逻辑关系词IF_THEN_ELSE、

CASE_OF、WHILE_DO、

REPEAT_UNTIL等组成。结构化英语的特点是一种介于自然语言和形式化语言之间的语言语言的正文用基本控制结构进行分割，加工中的操作用自然语言短语来表示其基本控制结构有三种：简单陈述句结构：避免复合语句；重复结构：while_do

或

repeat_until结构。判定结构：if_then_else

或

case_of结构；商店业务处理系统中“检查发货单”if发货单金额超过$500thenif欠款超过了60天then

在偿还欠款前不予批准

else（欠款未超期）发批准书，发货单

else（发货单金额未超过$500）

if欠款超过60天then

发批准书，发货单及赊欠报告

else（欠款未超期）发批准书，发货单

（2）判定表如果数据流图的加工需要依赖于多个逻辑条件的取值，使用判定表来描述比较合适以“检查发货单”为例（3）判定树判定树也是用来表达加工逻辑的一种工具。有时侯它比判定表更直观。检查发货单金额>$500金额$500欠款>60天不发出批准书欠款60天发货单发出批准书、欠款>60天发出批准书、发货单及赊欠报告欠款60天发出批准书、发货单窗体式规格定义功能或实体描述输入数据以及它们的来源描述输出数据以及它们的去处指示其它所需的实体前条件与后条件副作用窗体式规格需求描述举例（4）PDL(ProgramDescriptionLanguage)语言描述PDL语言即为程序描述语言，描述内容接近极易于翻译为程序代码。表达系统功能的能力不够充分；使用的符号专业；需求被看成了一个设计的过程，而不是帮助；用户了解系统的一个模型。所描述的操作功能单一，且动作执行顺序非常关键，而不易