软件需求分析重点.doc

什么是软件工程:
用来制造软件的工程 化的 方法
软件的特性:
软件是抽象的，而不是物理的—看不见摸不到
软件是极其复杂的
软件的手工开发方式、智力密集型
对计算机硬件依赖性
软件是被开发或设计的，而不是被制造的
软件不会磨损和老化，但维护困难
软件的高成本
软件危机的表现:
•对软件开发成本和进度的估算很不准确，甚至严重拖期和超出预算；
•无法满足用户需求，导致用户很不满意；
•质量很不可靠，经常失效；
•难以更改、调试和增强；
•没有适当的文档；
•软件成本比重上升；
•软件开发生产率跟不上计算机应用迅速深入的趋势。
什么是软件神话,它的危害:
软件神话(software myths)：关于软件及其开发过程的一些说法被人盲目相信
• 影响到几乎所有的角色：管理者、顾客、其他非技术性的角色、具体的技术人员；
• 看起来是事实的合理描述(有时的确包含真实的成分)、符合直觉，并经常被拿来做宣传；
• 实际上误导了管理者和技术人员对软件开发的态度，从而引发了严重的问题；
软件工程面临的挑战有哪些:
• 遗留系统(Legacy system)
• 多年以前开发出来的软件，在长期使用过程中不断的被人修改；
• 日益增加的维护成本和修改困难已经成为令人头疼的问题；
• 例如：Y2K问题；
• 高可信软件开发
• 关注软件的正确性、可靠性、安全性、保密性；
• 以形式化方法为发展趋势，通过保证模型的可信度来保证系统的可信度；
• 异构系统的集成与互操作
• 采用不同技术开发出来的系统，运行在不同的硬件平台和操作系统上，它们之间需要进行自动的数据交换；
• 更快的交付时间
• 顾客要求快速响应需求，而软件开发的周期难以有效缩短；
On demand (随需应变)
• 软件开发方式的变化
• Web 2.0、open source
• 基于Internet的协同开发模式
软件工程的范围和目标:
• 范围：
• 软件开发过程(设计、开发、运行、维护)
• 软件开发中应遵循的原则和管理技术
• 软件开发中所采用的技术和工具
• 目标：
• 高质量
• 按时交付
• 控制成本
• 满足用户需求
软件工程的四大组成部分:
工具、方法、过程、质量
第二章 核心概念与思想
功能性需求和非功能性需求及其特性:
功能性需求(Functional Requirements)：系统能够完成所期望的工作的能力
• 完备性：软件能够支持用户所需求的全部功能的能力；
• 正确性：软件按照需求正确执行任务的能力；
• 健壮性：在异常情况下，软件能够正常运行的能力
容错能力；
恢复能力；
——正确性描述软件在需求范围之内的行为，而 健壮性描述软件在需求范围之外的行为。
• 可靠性：在一定的环境下，在给定的时间内，系统不发生故障的概率，或者是快速从错误状态恢复到正确状态的能力。
非功能性需求(Non-Functional Requirements)：系统能够完成所期望的工作的性能与质量
• 性能：软件的“时间-空间”效率；
• 易用性：用户使用软件的容易程度，用户容易使用和学习；
• 清晰性：易读、易理解，可以提高团队开发效率，降低维护代价；
• 安全性：在对合法用户提供服务的同时，阻止未授权用户的使用；
• 可扩展性：软件适应“变化”的能力，系统很容易被修改从而适应新的需求或采用新的算法、数据结构的能力；
• 兼容性：不同产品相互交换信息的能力；
• 移植性：是软件不经修改或稍加修改就可以运行于不同软硬件环境(CPU、OS和编译器)的能力；
• 经济性：开发成本、开发时间和对市场的适应能力。
• 商业质量：上市时间、成本/受益、目标市场、与老系统的集成、生命周期长短等。
软件工程的7条原理:
• 用分阶段的生命周期计划严格管理
• 坚持进行阶段评审
• 实行严格的产品控制
• 采用现代程序设计技术
• 结果应能清楚地审查
• 开发小组的人员应少而精
• 承认不断改进软件工程实践的必要性
软件工程的几个核心思想:
复用(Reuse):
• 在一个新系统中，大部分的内容是成熟的，只有小部分内容是全新的。
• 构造新的软件系统可以不必每次从零做起；
• 直接使用已有的软构件，即可组装成新的系统；
• 复用已有的功能模块，既可以提高开发效率，也可以改善新开发过程中带来的质量问题；
分而治之(Divide and Conquer):
• 将复杂问题分解为若干可独立解决的简单子问题，并分别独立求解，以降低复杂性；
• 然后再将各子问题的解综合起来，形成最初复杂问题的解。
折中(Trade-off):
• 不同的需求之间往往存在矛盾与冲突，需要通过折中来作出的合理的取舍，找到使双方均满意的点。
第三章 软件过程模型
理解黑盒与白盒
各种模型的优缺点及英文缩写如RAD, RUP (瀑布模型、原型模型、RAD）
• 瀑布模型(waterfall model)
• 增量过程模型(incremental process model)
• 增量模型(incremental model)
• 快速应用程序开发(Rapid App. Dev., RAD)
• 演化过程模型(evolutionary model)
• 螺旋模型(spiral model )
• 原型模型(iterative model)
• 开放源码过程(open source)
• 统一过程模型(Rational Unified Process, RUP)
• 其他过程模型(other models)
• 形式化过程(formal method model)
• 软件复用过程(component-based reuse)
瀑布模型(waterfall model)
• 优点：
• 简单、易懂、易用；
• 每个阶段必须提供文档，而且要求每个阶段的所有产品必须由SQA小组仔细验证。
• 缺点：
• 在开发早期，用户难以清楚地确定所有需求，需求的错误很难在开发后期纠正，因此难以快速响应用户需求变更；
• 这种模型几乎完全依赖规格说明文档，而客户无法理解和阅读这些文档，容易导致不能满足客户需求。
• 客户必须在项目接近尾声的时候才能得到可执行的程序，对系统中存在的重大缺陷，如果在评审之前没有被发现，将可能会造成重大损失。
快速应用程序开发(Rapid App. Dev., RAD)
• 快速应用开发RAD (Rapid Application Development)
• 侧重于短开发周期(一般为60~90天)的增量过程模型，是瀑布模型的高速变体，通过基于构件的构建方法实现快速开发；
• 多个团队并行进行开发，但启动时间有先后，先启动团队的提交物将作为后启动团队的输入；
• 缺点：
• 需要大量的人力资源来创建多个相对独立的RAD团队；
• 如果没有在短时间内为急速完成整个系统做好准备，RAD项目将会失败；
• 如果系统不能被合理的模块化，RAD将会带来很多问题；
• 技术风险很高的情况下，不宜采用RAD。
原型模型(iterative model)
• 优点：
• 节省时间和成本；
• 提高和改善客户/用户的参与程度；
• 缺陷：
• 为了尽快完成原型，开发者没有考虑整体软件的质量和长期的可维护性；
• 用户可能混淆原型系统与最终系统，原型系统在完全满足用户需求之后可能会被直接交付给客户使用；
• 过长的开发时间；
• 额外的开发费用。
第四章
软件需求的作用
• “Requirement is the Basics of Quality”
• 充分理解现实中的业务问题，并作为软件设计的基础；
• 为软件项目的成本、时间、风险估计提供准确的依据；
• 减少开发工作量，避免将时间与资源浪费在设计与实现错误的需求上；
• 通过提供需求文档和需求基线，来有效的管理系统演化与变更；
• 作为顾客与开发团队之间正式合同的一部分；
• 为最终的验收测试提供标准和依据；
需求的分类：业务需求、用户需求、功能性需求、非功能性需求
NFR的度量:
• NFR(Non-Functional Requirements)：检验起来非常困难，一般采用一些可度量的特性进行描述。
良好的需求应具备的特性:
• 完整性：每一项需求都必须将所要实现的功能描述清楚
• 正确性：每一项需求都必须准确地陈述其要开发的功能；
• 可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的
• 必要性：每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来
• 划分优先级：给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量
• 无二义性：对所有需求说明的读者都只能有一个明确统一的解释
• 可验证性：检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现
需求工程的总体流程：

需求获取(Requirement Elicitation)
需求分析(Requirement Analysis)
需求规格说明(Software Requirement Specification, SRS)
需求验证(Requirement Verification)
需求管理(Requirement Management)

需求获取有哪些常用方法:
• 面对面访谈(face-to-face interviewing)
• 专题讨论会(workshop)
• 现场观察(observing on the scene)
• 头脑风暴(brainstorming)
• 多种方法要复合在一起使用，效果更好
DFD是什么？
数据流图(Data Flow Diagram, DFD)：结构化系统分析的基本工具
DFD图有哪些元素构成?

会画DFD图（顶层、0层）20分
• DFD：描述数据在功能模块之间的流动；

0层DFD图

例

顶层DFD图

0层DFD图

DD是什么？ 会定义DD
DD：描述数据的具体格式；
数据字典(Data Dictionary)
决策树与决策表的作用
用决策树来描述一个加工的逻辑处理过程，其基本思路与结构化英语类似，但是更直观易懂。
会画用例图 10分
例

用例之间的关系：
包含，扩展，泛化
软件需求规格说明书（SRS）应具备哪些特点:
• 正确性
• 无二义性
• 完整性
• 一致性
• 按重要度/稳定性排序
• 可验证性
• 可修改性
• 可跟踪性
编写SRS的原则有哪些:
• 原则1：只描述“做什么”而无须描述“怎么做”
• 原则2：必须说明运行环境
• 原则3：考虑用户、分析员和实现者的交流
• 对形式化和自然语言之间作出恰当的选择
• 明确的理解最重要，不存在十全十美的软件规格说明书
• 原则4：力求寻找到恰如其分的需求详细程度
• 一个有益的原则就是编写单个的可测试需求文档
• 建议将可测试的需求作为衡量软件产品规模大小的尺度
• 原则5：文档段落不宜太长
• 简短
• 记住：不要在需求说明中使用“和/或”、“等等”之类的词
• 原则6：避免使用模糊的、主观的术语
• 如用户友好、容易、简单、迅速、有效、许多、最新技术、优越的、可接受的、最大化、最小化、提高等
• 不可验证
需求验证要验证哪些内容:
• 软件需求规格说明正确描述了预期的系统行为和特征
• 从系统需求或其它来源中得到软件需求
• 需求是完整的和高质量的
• 所有对需求的看法是一致的
• 需求为继续进行产品设计、构造和测试提供了足够的基础
需求验证的技术:
• 需求评审：由不同代表(如分析员、客户、设计人员、测试人员)组成的评审小组以会议形式对需求进行系统性分析。
• 原型评价：客户和用户在一个可运行的原型系统上实际检验系统是否符合他们的真正需要。
• 测试用例生成：通过设计具体的测试方法，发现需求中的问题。
需求评审过程及退出条件:
过程：

退出条件：
• 已经明确阐述了审查员提出的所有问题
• 已经正确修改了文档
• 修订过的文档已经进行了拼写检查和语法检查
• 所有TBD的问题已经全部解决，或者已经记录下每个待确定问题的解决过程、目标日期和提出问题的人
• 文档已经登记入项目的配置管理系统
• 检查是否已将审查过的资料送到有关收集处
需求变更控制流程:
变更控制过程并不是“拖延时间以敷衍用户”，它是一个渠道和过滤器，通过它可以确保采纳最合适的变更，使变更产生的负面影响减少到最小。

需求跟踪管理:
• 需求跟踪：
• 维护需求与软件制品之间的映射(例如设计对象、用例、测试用例、已实现的软件模块等)
• 全面分析变更所带来的影响，以便作出正确的变更决策。
• 建立需求跟踪的过程：
• 识别并唯一地标识SRS中的每一个需求
• 建立和更新SRS中的跟踪矩阵
• 工作制品的创建者负责增加该制品与需求的跟踪信息
• 跟踪矩阵应该作为工作制品的一部分进行审查需求版本控制
需求版本控制：
• 版本控制是管理需求的一个必要方面。
• 需求文档的每一个版本必须被统一确定。
• 组内每个成员必须能够得到需求的当前版本，必须清楚地将变更写成文档，并及时通知到项目开发所涉及的人员。
• 为防止混乱，应仅允许指定的人来更新需求。