软件需求讲义-第一部分

软件需求从谚语开始中国有句谚语：“好的开始就等于成功的一半”西方的谚语是：“Garbagein,garbageout！”

内容概要软件需求的基本概念需求工程与需求工程过程需求获取与需求分析需求文档与需求质量验证软件需求管理软件需求参考书作者：黄国兴

周勇出版社：清华大学出版社软件需求工程

本书着重介绍了软件需求工程的基本概念、基本理论和实际应用技术。内容涵盖了需求工程中的每个重要步骤，提供了一些检查表和比较简单易懂的需求过程模型和建模实践。软件需求参考书作者：（美）karle.wiegers

译者：刘伟琴刘洪涛

出版社：清华大学出版社软件需求（第2版）

本书介绍了贯穿整个开发周期的管理需求工程的实用技术，包括多种可以促进用户、开发人员和管理层之间有效沟通的方法。这一版对第一版进行了扩充，提供了新的实例，及作者在实际工作中遇到的各种实际案例和解决方案。此外，还添加了新的章节、需求示例文档以及故障诊断指南等。

参考教材作者：张海藩编著出版社：清华大学出版社软件工程导论（第4版）

本书是在吸取了国内外有关教材的精华，并结合编者多年来进行软件工程的教学及软件开发实践的经验、体会的基础上编写的，软件工程领域的经典教材，尤其结构化的软件建模方法值得借鉴。参考教材作者：邝孔武，王晓敏编著出版社：清华大学出版社信息系统分析与设计

本书是在吸取了国内外有关教材的精华，并结合编者多年来的教学及软件开发实践的经验、体会的基础上编写的，通过典型案例，展示了使用面向对象方法和结构化方法进行软件建模的具体思路和步骤。

参考教材作者：蔡敏，徐慧慧，黄炳强编著出版社：人民邮电出版社UML基础与Rose建模教程

本书是在吸取了国内外有关教材的精华，并结合编者多年来的教学及软件开发实践的经验、体会的基础上编写的，通过4个综合性的案例，展示了使用UML和Rose进行软件建模的具体方法和步骤。

参考教材4.软件工程SoftwareEngineering,6thEdition作者：（英）IanSommerville出版社：机械工业出版社（影印版）

本书是英国著名软件工程学家IanSommerville系统介绍软件工程理论的力作，以要求极高的一类系统为实例，精辟透彻地阐述了软件工程的内涵。参考网站卡内基梅大学软件工程研究所/

对象技术和构件技术链接Rational公司http://OMG(ObjectManagementGroup)1.

软件工程java实现softwareengineeringwithjavamcagraw-hillStephenR.Schach袁兆山机械工业出版社1999-9-1本书介绍经典的和面向对象的软件工程，强调理论、抽象和设计相结合，重视对软件工程学有指导作用的重要概念。2.软件工程概论清华大学殷人坤3.软件工程导论清华大学张海藩(第四版)4.Java面向对象编程指南韩柯电子工业出版社5.面向对象的系统分析与设计（uml）清华大学出版社6.Uml系统分析设计与应用案例人民邮电编写有效用例机械工业8.Ood启思录人民邮电9.重构——改善既有代码的设计（中文版）Refactoring:ImprovingtheDesignofExistingCode作者：[美]MartinFowler/著译者：侯捷熊节/译出版社：中国电力出版社2003年8参考书10.设计模式:可复用面向对象软件的基础

designpatterns:elementsofreusableobject-orientedsoftwareAddsionWesley/Personpublisherauthor:ErichGamma李英军机械工业出版社2000-9-1软件工程的重要概念就是可复用。近几年来“模式”给出了“软件可复用”的漂亮解决方案。所谓模式一词来源于城市建筑领域，“每一个模式描述了一个在我们周围不断重复发生的问题以及该问题的解决方案的核心。这样，你就能多次使用该方案而不必做重复劳动。”这种思想应用在面向对象设计领域，指的是总结软件设计中遇到的各类问题，并提出设计的解决方案。有经验的设计者知道，不是解决任何问题都要从头开始。这本书的目的就是将面向对象软件的设计经验作为设计模式记录下来，每一个设计模式系统地命名、解释和评价了面向对象系统中一个重要的和重复的设计。参考书11.敏捷软件开发：原则、模式与实践

AgileSoftwareDevelopment:Principles,Patterns,andPractices原出版社：PearsonEducation作者：[美]RobertC.Martin/著邓辉译清华大学出版社2003年9月

1.讲述在预算和时间要求下，软件开发人员和项目经理如何使用敏捷开发完成项目。

2.使用真实案例讲解如何用极限编程来设计、测试、量构和结对编程

3.包含了极具价值的可多次使用的C++和JAVA源代码。

4.重点讲述了如何使用UML和设计模式解决面向客户系统参考书12.与熊共舞：软件项目风险管理

WaltzingWithBears:ManagingRiskonSoftwareProjects书中，作者展示了风险管理的益处√风险管理使企业可以积极地迎接风险√使管理不致陷于盲目√使项目能够以最小代价应对风险√使责权划分更加明确√使子项目的失败不致影响全盘。13.软件工程思想电子林锐14.软件工程36计金樽和机械工业出版社15.Uml核心建模技术参考书第一部分软件需求的基本概念需求问题 需求的层次第1章 需求问题需求是软件项目成败的关键所在越早发现需求错误，越早改正它，其代价越小需求的定义好需求的特征：无歧义、完整、一致、可检验、确定、可跟踪的，正确的，可行的和必要的。

软件开发中的错误观点只要掌握了1-2门程序设计语言，进行软件开发就没有问题。只要有最好的开发工具、最好的计算机，一定能做出优秀的软件。软件需求分析很困难，不管三七二十一，先把软件做了再说，反正软件是灵活的，随时可以修改。总之，错误认为：软件就是程序，开发软件就是编写程序。

项目失败与成功的原因*三种最经常使项目“遇到困难”的因素是：缺乏用户介入：占所有项目的13%不完整的需求和规格说明：占所有项目的12%不断改变的需求和规格说明：占所有项目的12%三种项目最主要的“成功因素”是：用户介入：占所有成功项目的16%高层管理的支持：占所有成功项目的14%需求陈述清晰：占所有成功项目的12%*[StandishGroup，1994]软件开发的目标软件开发的目标，简单而言，就是满足用户的需要。需求在项目中的作用未真正明白这些问题就开始编码，结果没有人对产品满意。在项目开发中，所有的涉众（Stakeholder）都对需求分析阶段备感兴趣。（没有理所当然的需求）2-8原则：举足轻重2-8原则*80%的工程活动是由20%的需求消耗的80%的软件成本是由20%的构件消耗的*[Royce，1998]

需求错误的代价在生命周期的不同阶段修复缺陷的相对成本23需求的重要性重要性

DavisA.M.研究发现，在需求阶段检查和修复一个错误所需的费用只有编码阶段的1/5到1/10，而在维护阶段做同样的工作所需付出的代价却是编码阶段的20倍。结论 在软件开发过程中，必须极早、有效地发现和解决与需求相关的问题。需求缺陷造成的成本增加重新进行需求规格说明重新设计重新编码重新测试改变订单——告诉用户将以一个修正后的版本来替代有缺陷的版本。纠正活动——消除由于不准确的特定系统的错误造成的危害，可能涉及到赔偿客户损失。报废——包括对于已经完成的代码、设计和测试，当发现它们是根据不正确的需求进行的时候，这些工作成果不得不被丢弃。收回有缺陷的软件产品以及相关的用户手册。产品赔偿或保修的成本。重新安装新版本的成本。重新建档的成本。高质量的需求过程带来的好处

在开发后期和整个维护阶段的重做的工作大大减少了。让用户积极参与需求收集过程能使产品更富有吸引力，而且能建立起更加忠实的客户关系。用户的参与能弥补用户期望和开发者实际开发之间的“鸿沟”（期望差异）。将确定的系统需求明确地分配到各软件子系统，确保软硬件系统功能匹配适当。有效的变更控制也能降低需求变更带来的负面影响。将需求编写成清晰、无二义性的文档将会极大地有利于系统测试，确保产品质量。需求定义[IEEE1997]IEEE软件工程标准词汇表定义需求为：用户解决问题或达到目标所需的条件或能力。系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。一种反映上面(1)或(2)所描述的条件或能力的文档说明。需求定义[Thayer,Dorfman.1997]MerlinDorfman和RichardH.Thayer提出了一个包容且更为精练的定义：用户解决某一问题或达到某一目标所需的软件功能。系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。好的需求应具有的特性无歧义性完整性一致性可检验性确定性可跟踪性正确性可行性必要性无歧义性产生歧义的原因同一个词具有多种含义编写人员会下意识假设所有人对某个主题都具有和自己一样的认知水准缩写叙述不够具体……无歧义性（续）示例：系统只允许保留5个有效的相关记录和保障计划，它必须包括最新的。系统只允许5个有效的相关记录最新的相关记录一定包含在上述相关记录中每个保障计划都被放在其相关记录中结论：每个需求都应该只叙述一个主体，在一个需求中包含多个主体时，会产生歧义。无歧义性（续）消除歧义的方法对感到模糊的地方刨根问底关键字技术其他技术完整性不能遗漏任何需求或必要的信息遗漏需求将很难查出来如果不能确定某项需求，务必用TBD（tobedetermined，待确定）来标识项目开发前，必须解决需求中所有的TBD项每项需求必须完整描述即将交付使用的功能完整性（续）防止遗漏的方法注重用户的任务而不是系统的功能。将高层需求分解足够细，让用户真正的需求显示出来：“应该、将要、可能”

→“将、必须”。务必让所有用户类都提出意见，确保每个用例都至少有一个执行者。用多种方式表达需求：UML模型、数据流图、判定表（树）、E-R图等。跟踪系统需求、业务规则、用例，直至详细的软件功能性需求，确保导出了所有必须的功能。检查边界值完整性（续）示例：如果可能的话，应该根据主要法人账号列表在线确认所输入账号的合法性。TBD，尽快确定其必要性验证成功如何验证失败又该如何修订：当请求者输入账户号码时，系统将根据在线的法人账号列表来验证所输入的账号。如果在此列表中查不到该账号，则系统将显示一个出错信息并拒绝订货；否则进入订货流程。一致性任何一项需求不会与其他需求或更高层次的需求发生冲突记下每项需求的来源，当发现需求冲突知道该找谁商量项目开发前，必须解决需求不一致的问题可检验性需求可以通过合理的方式充分检测开发人员能够确认软件是否满足用户需求测试人员能够设计合理的测试方法，检验系统能否正常运行示例1：用新的系统完成报表自动化处理。示例2：员工标识号必须在一个有效的范围内。确定性使得所有人都知道在所有可能的条件下系统应该做什么处理有条件的行为，要使用两种不同的需求一条：说明满足条件系统如何另一条：说明不满足条件系统如何确定性（续）示例：系统1应该每隔5分钟向系统2发送一次新记录。每隔5分钟的时间起点在哪里，不确定当无新记录可发时，系统1该如何修订：如果自上次向系统2发送消息以来，5分钟内收到了新记录，则系统1向系统2发送新记录；如果在上述5分钟内没有收到新记录，则系统1向系统2发送“无新记录”的提示消息。可跟踪性可跟踪的（软件）需求都能找到它的来源可跟踪的（软件）需求都有它对应的设计单元、实现代码可跟踪的（软件）需求都有它被正确实现的测试用例可跟踪的（软件）需求都有一个固定、惟一的标识可行性需求必须在已知系统和环境的限制范围内能够实施需要软件开发人员配合，检查技术可行性忌讳使用“迅速、瞬间、及时”等用词必要性每一项需求都必须是用户真正的需要，或者是为符合外部系统的需求，或者是符合某一标准每项需要都必须来源于有权定义需求的一方，可追溯至特定的客户要控制软件开发的风险，一定要确认所要开发的内容是用户实际需要的练习题产品应在不少于每60秒的正常周期内提供状态信息。不少于每60秒，一年如何？状态信息有哪些内容，在哪里显示，如何显示？修订：1.产品将在用户界面的指定区域显示状态信息。

1.1自产品启动后，状态信息必须每隔60±10秒更新一次。

1.2状态信息必须保持持续的可见性。

1.3任务执行过程中，状态信息将显示任务的完成百分比。

1.4任务完成时，状态信息将显示“已完成（Done）”。

1.5任务中止时，状态信息将显示“Error”。练习题(续）HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速解决错误。“快速”这个词有歧义，不可行错误报告什么时候产生，有哪些内容，如何帮助初学者？不确定、不可检验修订：1.在HTML分析器完全解析完一个文件后，该分析器将生成一个出错报告，其内容包括解析文件过程中所发现的所有HTML错误的行号及其文本内容，还包括对每个错误的描述。

2.如果在解析过程中未发现任何错误，将不生成出错报告。练习题(续）产品应瞬间在文本中的显示和隐藏不可打印字符间切换。“瞬间”这个需求不可行？需求不完整：未声明切换的源头（自动还是外部触发）需求不确定：“不可打印字符”是什么，文中发生变化的范围有多大修订：用户在编辑文档时，通过特定的菜单项，可以在显示和隐藏文本中所有控制字符之间进行切换。改变显示方式所需的时间为0.1秒或更短。第二章需求的层次需求是多层次的，包括目标需求、业务（用户）需求、功能需求和非功能需求。需求路线图：涉众需要—〉系统的特性—〉建立软件需求软件需求包括不同的层次目标需求内容：表示组织或客户对系统、产品高层次的目标来源：投资人、购买产品的客户、市场营销部门、产品策划部门、实际使用者的管理者描述方式：前景（视图）和范围文档示例：为乘坐航空公司航班的乘客购票提供便利，增加航空公司的客流量，需要开发

“网上机票预订系统”。业务（用户）需求内容：描述了用户要求系统、产品必须能完成的任务来源：实际使用系统的所有潜在用户描述方式：用例模型示例：“机票预订”、“修改预订”、“取消预订”、“机票查询”功能需求内容：规定开发人员必须在系统、产品中实现的软件功能来源：实际使用者、开发人员描述方式：软件需求规格说明书（SRS）示例：“编辑订单”、“提交订单”、“取消提交”、“取消订单”、“计算费用”、“选择付费方式”等术语：系统需求内容：包含多个子系统的产品（即系统）的顶级需求。纯软件产品只包含软件子系统，否则既包含软件又包含硬件子系统示例：系统需求：系统能控制实验室设备给整排烧杯加入精确数量的化学药品（即把这项乏味的工作自动化）软件的功能需求：向硬件发送“移动加药喷头”的信号；读取定位传感器；向硬件发送“开泵”的信号；向硬件发送“关泵”的信号；软件的6个质量特征[ISO9126]软件的非功能性需求（质量属性）可靠性可用性有效性可维护性可移植性可靠性如果一个系统不能可靠运行（例如，在加载时发生故障，或在系统故障时不知所措等），则它就不能满足客户的需要。影响可靠性的因素：MTBF（平均无故障时间）。要仔细定义什么是故障MTTR（平均修复时间）。系统出故障后修复所需要的时间。即使出现故障，系统也能可靠运行吗？（健壮性）复制和故障转移的方案是什么？系统故障时，需要手动干预，还是系统可以自动进行故障转移。系统的安全性：系统如何访问授权，如何保护系统不受攻击。可用性如果用户不能方便地使用系统，则它就不能满足用户的需要，影响可用性的因素：系统是否为用户带来不适当的负担（如，需要特殊浏览器）？系统是否不间断地为所有用户提供所有服务？系统是否提供好的体系结构，使多用户界面成为可能，方便多用户同时使用。训练用户所需的时间，这里需要区分新手、普通用户和高级用户。指明在线帮助、使用向导、工具提示、上下文相关帮助、用户手册和其他形式的文档和帮助。有效性如果没有有效地使用资源（例如处理器、内存和磁盘空间），功能性、可靠性和可用性再好的系统最后都会失败。可以将有效性划分成性能可可伸缩性两个子范围：性能：系统能够多快多好的运行工作，它只是平稳缓慢地运行吗？系统可以达到响应时间目标吗？可伸缩性：如果系统在小范围内运行看起来相当快，那么当成千上万个活动的时候呢？它的设计能够达到怎样的吞吐量目标，是否存在瓶颈（例如公共数据库）？可维护性这是一个极其重要的需求，它表明了系统需要升级或修正时，系统被修改的能力。可预见的可维护性：例如当用户数超过某一界限时，系统的吞吐量要相应增加，需求中就可以规定维护的定量指标。不可预见的可维护性：为了提高不确定情况下系统的可维护水平，需求要制定一些约束规则。可移植性可移植性对系统未来改变部署提出了要求。例如，如何采用标准来提供某种形式的平台独立性？是否计划将应用程序迁移到客户最新最高版本的应用服务器上？需求规格说明中的非功能需求练习题由于软件故障引起实验失败的概率不超过5‰。只有那些被授权可以在家访问公司内联网的用户，才可以在公司以外的地方使用“内部订餐系统“。如果在用户保存文件之前编辑器发生故障，那么下次同一用户启动程序时，编辑器能恢复发生在1分钟之前对所编辑文件所作的修改。XX系统软件菜单中的所有功能都必须定义快捷键。在预计的峰值负载条件下，至少25%的处理能力和应用程序可用内存必须留出备用。在上午9点到11点这一高峰时段，数据库系统最多能支持50个用户的并发访问。（可靠性）（可靠性或安全性）（可靠性或健壮性）（可用性）（有效性）（有效性或灵活性或可扩展性）练习题（续）ATM柜员机系统对提款请求的身份认证不能超过10秒。一个合格的技师能在10分钟内更换打印头电缆，在5分钟内更换色带感应器。函数调用的嵌套层次不能超过2层。以前从没有使用过“化学品跟踪系统”的化学家，在经过最多不超过30分钟的适应之后，能够正确地对一个