文章目录
一、软件需求管理概要
需求分析是软件工程中的重要步骤，是决定软件项目成败的关键影响因素之一。需求阶段的错误在后期的纠错成本远远高于软件设计和实现阶段的错误的纠错成本。因此，需求工程成为软件工程和系统工程重要的分支领域之一，在需求工程中，我们主要关注的是软件和系统需求的获取、建模、分析、验证和管理。
1.需求工程师的职责
当代需求工程师应当具备的能力
- 1.分析问题和解决问题的能力
- 2.主动参与人际沟通及交流能力
- 3.软件工程基本知识和技能
- 4.对应用领域的深厚了解
- 5.书面语言组织和表达能力
优秀需求工程师努力的方向和目标
- 1.识别对环境及系统的错误假设
- 2.确保描述的一致性
- 3.提升对标准和规范的依从性
- 4.减少彼此误解
- 5.提高支持人员的速度和效率
- 6.提升客户满意度
- 7.撰写优质需求文档
需求工程师值得注意的方面是排除一切的干扰、避免沉默、避免过度规约、避免含糊和矛盾的需求描述、避免向前引用以及不切实际和一厢情愿的假设。
2.软件需求的定义
需求的定义：
软件需求的内容：
- 需求是系统为满足客户期望的目标而完成的行为
- 需求要体现出对问题领域的清晰理解
- 给出系统的使用场景和上下文
软件需求定义涵盖如下内容：
- 为什么要设计该系统
- 系统由谁使用
- 系统要做什么
- 系统涉及哪些信息
- 对解决方案有何额外限制
- 如何使用该系统
- 质量需达到何种程度
存在问题的需求描述的实例：
3.获取软件需求的主要途径
- 1.访谈
访谈是需求获取的主要方式，通过当面交流和引导，获取有效信息，例如用户的痛点、用户希望解决的问题、达到什么目的等。
访谈对象的选择很重要，将直接决定需求的有效性，通常会约客户领导、客户接口人、用户进行访谈。不同的角色对软件的期望不一样，收集到的需求点应进行筛选分析再做参考。
- 2.问卷调查
问卷调查适用于大范围的目标人员调查，可以收集到用户对软件的意见和建议，根据收集到的信息进行统计分析，有助于软件需求的挖掘。
优秀的问卷设计有助于获取高质量的信息，信息收集后可以做多维度的统计分析。
- 3.现场考察
现场考察是最直接最有效的需求获取方式，深入现场，观察用户的使用场景和遇到的问题，挖掘潜在需求、分析用户的真正所需，必要时可录像或记录，以便后续深入分析。
- 4.资料查阅
资料查阅是指获取业务相关的资料文献，通过阅读资料挖掘相关的需求点，例如业务流程、SOP、操作手册等。
- 5.市场调研/竞品分析
市场调研和竞品分析有助于扩展需求、升级需求，学习市场上更好的产品和想法，在原需求的范围内进一步做优化和升级，获得客户的认可。
4.软件需求文档的框架
软件需求规格说明
- 是具有一定法律效力地合同文档
- 清楚地描述软件在什么情况下，需要做什么，以及不能做什么
- 以输入/输出、输入到输出之间的转换方式来描述功能性需求
- 描述经过干系人磋商达成共识的非功能性需求
- 一般参考需求定义模板，覆盖标准模板中定义的所有条目
- 作为后续的软件评估依据和变更的基准
软件需求文档的组织形式
文档需要有逻辑组织结构
- 例如：参照IEEE的模板
典型的组织形式包括
- 按系统能够响应的各种外部环境情况来组织
- 按系统特征来组织
- 按系统的响应方式来组织
- 按所管理的外部数据对象来组织
- 按用户类型来组织
- 按软件的工作模式来组织
- 按子系统的划分来组织
高质量需求规格说明
- 是所有需求的集合
- 描述产品要提供的所有功能
- 是软件系统解决方案的商业合同的基础
- 是测试计划的基础
- 定义产品需求的度量标准
- 是产品需求的跟踪的先决条件
- 影响开发产品的项目计划
高质量需求规格说明的评价标准
- 正确性 = 经过验证的
- 无歧义
- 完整的
- 可测试 = 可以证明的
- 可修改的
- 可跟踪的
- 易理解
- 一致的
- 有序的
- 项目或产品特定的其他特征
- 简洁的
总结
- 尽快开始写需求
- 确定哪些属性将被用于分类和细化需求
- 产生有关初始版本来刺激反馈
- 询问需求时需要遵循的法则：
- 使用简单、直接的语言
- 撰写可测试的需求
- 一次只写一项需求
二、软件开发过程
1.软件过程概念及其组成
软件过程概念
软件过程是为了获得高质量软件而实施的一系列活动，它包括问题定义、需求开发、软件设计、软件构造和软件测试等一系列软件开发的实现活动。而每一项活动都会产生相应的中间制品。为了保证软件开发过程能够按照预定的成本、进度、质量顺利完成，还需要诸如项目管理、配置管理、质量保证等一系列开发管理活动。通过建立整个组织的质量管理体系，实现对软件开发实现活动的有效控制和质量保证。
软件过程组成
- 问题定义
- 需求开发
- 软件设计
- 软件构造
- 软件测试
软件维护
软件项目管理
软件配置管理
2.传统软件工程模型的特点及其适用场合（瀑布、原型、增量）
- 瀑布模型
瀑布模型将基本的开发活动看成是一系列界限分明的独立阶段，这是一种计划驱动的软件过程， 有利于规范软件开发活动。瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
特点：
- 1、阶段间具有顺序性和依赖性
必须等前一阶段的工作完成后，才能开始后一阶段的工作；前一阶段的输出文档就是后一阶段的输入文档，因此只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果
- 2、推迟实现的观点
对于规模较大的软件项目来说，往往编码开始的越早，最终完成开发所需时间越长。因为前面阶段的工作没做或做的不扎实，过早地考虑进行程序实现，往往导致大量返工，有时甚至发生无法弥补的问题
瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，分析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现
清楚的区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想
- 3、质量保证的观点
为了保证所开发的软件的质量，在瀑布模型的每一个阶段都应坚持两个重要做法：每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务；每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。
传统的瀑布模型过于理想化，实际的瀑布模型是带"反馈环"的。优缺点
优点：
- 为项目提供了按阶段划分的检查点
- 当前一阶段完成后，您只需要去关注后续阶段
- 可在迭代模型中应用瀑布模型
缺点：
- 不适合需求模糊或需求经常变动的系统
- 由于开销的逐步升级问题，它不希望存在早期阶段的反馈
- 在一个系统完成以前，它无法预测一个新系统引入一个机构的影响
- 在用户可能需要较长等待时间来获得一个可供使用的系统，也许会给用户的信任程度带来影响和打击
- 最终产品往往反映用户的初始需求而不是最终需求
- 原型化模型
原型是一个部分开发的产品，用于加强对系统的理解，有助于明确需求和选择可行的设计策略。原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。
它允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护。
优缺点
优点：
- 克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险
- 适合预先不能确切定义需求的软件系统的开发
缺点：
- 所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下
- 使用前提是要有一个展示性的产品原型，一定程度上可能会限制开发人员的创新
迭代式开发
软件开发具有迭代性，需要不断地反复尝试，通过比较和选择不同的设计，最终确定令人满意的问题的解决方案。
迭代式开发是将描述、开发和验证等不同活动交织在一起，在开发过程中建立一系列版本，将系统一部分一部分地逐步交付。迭代式的开发使得软件系统能够逐步的进行交付，开发人员在完成一部分功能之后形成一个产品版本，然后将其发布给用户使用，当用户使用第一个版本的时候开发人员继续开发下一个版本，如此迭代循环。这样做，不仅可以缩短产品的开发周期，还可以更好的获得用户对产品的反馈。
增量模型和迭代模型是迭代式开发的两种形式。在增量模型中，首先定义一个小的功能系统，然后在每一个新的发布中逐步增加功能，指导构造出全部的功能；在迭代模型中，一开始就提交一个完整的系统，但是每个功能并不完善，然后在后续的发布中，再对其补充完善，下图说明了增量模型和迭代式模型的区别。
- 增量模型
增量模型也称渐增模型。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能
使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。
把软件产品分解成增量构件时，唯一必须遵守的约束条件是，当把新构件集成到现有构件中时，所形成的产品必须是可测试的。
瀑布模型或快速原型模型目标是一次就把一个满足所有需求的产品提交给用户
增量模型把整个软件产品分解成许多个增量构件，分批地逐步向用户提交产品
特点
增增量模型把瀑布模型的顺序特征与快速原型法的迭代特征相结合，将软件看作一系列相互联系的增量，在开发过程的各次迭代中，每次完成其中的一个增量。风险更大的增量模型
确定用户需求后就着手拟定第一个构件的规格说明文档，完成后规格说明组转向第二个构件的规格说明文档，同时设计组开始涉及第一个构件
使用该方法将不同的构件并行构建，可能加快工程进度，但将冒构建无法集成到一起的风险
优缺点
优点：
- 能在较短的时间内向用户提交可完成部分工作的产品
- 将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展
- 以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统
- 开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整
缺点：
- 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构
- 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性
- 如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程
- 可转换模型
可转换模型利用自动化的手段，通过一系列转换将需求规格说明转换为一个可交付使用的系统。
可转换模型是采用形式化的数学方法描述系统，并利用自动化手段通过一系列转换，将形式化的需求规格说明变为可交付使用的系统。
3.迭代模型特点及其适用场合
迭代模型是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。即所有功能一起开发，从粗到细，逐步求精。迭代模型适用于需求不甚明确、难度比较大的软件开发。
迭代模型的选择使用条件
- 1、在项目开发早期需求可能有所变化。
- 2、分析设计人员对应用领域很熟悉。
- 3、高风险项目。
- 4、用户可不同程度地参与整个项目的开发过程。
- 5、使用面向对象的语言或统一建模语言（Unified Modeling Language，UML）。
- 6、使用CASE（Computer Aided Software Engineering，计算机辅助软件工程）工具，如Rose（Rose是非常受欢迎的物件软体开发工具。）。
- 7、具有高素质的项目管理者和软件研发团队。
迭代模型的优点
与传统的瀑布模型相比较，迭代过程具有以下优点：
- 1）降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
- 2）降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。
- 3）加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
- 4）由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。
三、总结
原型化和瀑布模型的区别在于尽快的制作出一款原型，来检验软件是否可行，而迭代式开发的本质其实就是通过多次制作原型来迭代出更符合要求的软件，这三者的本质区别在于制作原型的次数。而可转换模型则区别较大，它通过将无法直接测试的需求转换成可以直接测试的需求，保证了模型的安全、可靠、严密。
此外比较重要的一点就是需求文档的撰写。我觉得这个的撰写光靠阅读概念其实是不够的，应该需要阅读一些优秀的需求文档以及模仿优秀的需求文档实践才能够真正的掌握好撰写需求文档的技能。这一项技能我认为是非常重要的，不光是我们程序员需要掌握这一项技能，其实更多的其他专业的需要给计算机同学提出需求的同学们也应该需要掌握这一项技能，因为这会大大的减少不必要的麻烦。如果一位完全不知道需求文档应该如何撰写的朋友要为一个计算机专业的同学写需求文档的话，这个需求文档可能是不完整，不清晰的，外专业的同学可能不知道要写什么，写了一堆不重要的信息，而计算机的学生也没有办法理解外专业的学生到底想要做什么。这时候事情就会变得事倍功半，而如果是有幸外专业的同学来听一听软件工程课，了解一下需求文档应该怎么来写，那么相信，这对于合作双方都会是一段美好的回忆。
671
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
