软件需求分析
概念：
软件需求包括：功能需求、非功能需求、设计约束
（1） 业务需求：业务需求指反应组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求.通常在项目定义与范围文档中予以说明。
（2） 用户需求：用户需求指描述用户使用产品必须要完成什么任务，如何完成需求。通常是在问题定义的基础上进行用户访谈、调查、对用户使用的场景进行整理，从而建立从用户角度出发的需求.这在使用实例或方案脚本中予以说明。
（3） 系统需求：系统需求是从系统的角度来说明软件的需求，包括用特性说明的功能需求、质量属性，以及其他非功能需求，还有涉及约束；
（4） 功能需求：功能需求指系统必须完成的任务，即为了向其用户提供有用的功能，产品必须执行的动作
（5） 非功能需求：非功能需求指产品必须具备的属性和品质，如可靠性、性能、响应时间、容错性、扩展性等
一、软件可靠性 ：
软件可靠性是软件在给定的时间间隔及给定的环境条件下，按设计要求，成功地运行程序的概率；通常用平均无故障时间（MTTF, mean-time to fault）来衡量
第一个层面：软件不出现故障；
第二个层面：软件即使出现故障，也仅对性能有部分影响，而设备的功能不受损失；
第三个层面：软件出现故障并造成部分功能受损失，但是能够很快恢复业务；
第四个层面：软件出现较大故障，并造成大部分功能受损、业务中断或瘫痪，但能够尽快恢复业务（
无论是手工恢复还是自动恢复）；
对应于不同的可靠性层次，要求系统有相应的层次设计要求和维护要求，例如：
对于第一个层面：要求系统能够按照充分的规范来进行设计，加强各种异常处理能力和环境适应能力等；
对于第二个层面：要求系统有较高的容错能力，使用冗余技术和备份技术等；
对于第三个层面：要求系统有很好的可测试性，能迅速隔离问题和定位问题等；
对于第四个层面：要求系统有较高的可维护性等。
二、性能需求：
一般包括：
1)列出有各种性能要求的功能，如有并发要求的功能及相应的并发要求、有响应时间要求的功能，
2)数据库容量，或指定时间的业务处理量，
3)系统用户容量的需求，
4)如果有机器配置上的要求，则说明相应的机器配置要求；
5)网络环境，如1MADSL或者512k拨号上网环境，
6)系统运行时间，如7×24小时不间断运行，或者可连续运行一周。
三、响应时间：
一个交易过程（例如一个请求，完成一个查询）可能由几个客户请求和服务器响应组成，从客户发出请求（信息包层或交易层）至他收到最后一个响应的时间就是整体的响应时间。
计算机用户最讨厌等待。在大量的处理环境中，超过3秒以上的响应时间将会严重影响工作效率。
四：容错性
容错性是指计算机或系统在出现重大的事故或故障(如电力中断、硬件故障)时做出反应以确保数据不会丢失并且能够继续运行的能力
程序的容错性设计所谓容错性是指一个程序在用户不正确的操作或不正确输入的情况下有不中断程序的运行并能提供改正错误途径的机制
容错性测试包括两个方面的测试：
a.输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好的话，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。
b.灾难恢复性测试。通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失、系统和数据是否能很快恢复。
四、扩展性
可扩展性反映了软件适应“变化”的能力
质量属性：
正确性：正确性是指软件按照需求正确执行任务的能力
健壮性：健壮性是指在异常情况下，软件能够正常运行的能力
健壮性有两层含义：一是容错能力，二是恢复能力。
容错是指发生异常情况时系统不出错误的能力
恢复是指软件发生错误后（不论死活）重新运行时，能否恢复到没有发生错误前的状态的能力
正确性与健壮性的区别是：前者描述软件在需求范围之内的行为，而后者描述软件在需求范围之外的行为
可靠性：
软件可靠性问题通常是由于设计中没有料到的异常和测试中没有暴露的代码缺陷引起的。可靠性是一个与时间相关的属性，指的是在一定环境下，在一定的时间段内，程序不出现故障的概率，因此是一个统计量，通常用平均无故障时间（MTTF, mean-time to fault）来衡量。
易用性
易用性是指用户使用软件的容易程度。
清晰性
清晰意味着工作成果易读、易理解
安全性
这里的安全性是指信息安全，英文是Security而不是Safety。安全性是指防止系统被非法入侵的能力，既属于技术问题又属于管理问题
可扩展性
可扩展性反映了软件适应“变化”的能力
兼容性
兼容性是指两个或两个以上的软件相互交换信息的能力
可移植性
软件的可移植性指的是软件不经修改或稍加修改就可以运行于不同软硬件环境（CPU、OS和编译器）的能力，主要体现为代码的可移植性
（6） 设计约束：设计约束也称为“限制条件”或“补充规约”，通常是对解决方案的一些约束。
实践：
第一：利益共同体
这一实践中最有效的方法是隐喻，可以通过容易的引起共鸣的场景打动客户，博得共识
第二：共同目标：
通常目标就是业务需求，因此目标是构建在“项目发起人”的脑子里。即谁提出项目，谁就拥有对“业务需求”的最清晰的理解。
业务需求指反应组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求
需要考虑以下问题：
1、 思考企业运行中存在什么问题
2、 这些问题主要体现在哪些方面
3、 这些问题对企业造成什么影响
4、 认为可以如何解决
5、 希望达到什么样的效果
第三：框定问题
软件需求第一个和可能最重要的步骤是框定问题。即把问题的特定部分，以及部分间特定的关系放入一个特定的形式中，问题框定方法应使问题的细节适合一个简单连贯的框架。通常将新问题转换到有已知算法的问题上，也将更有效的实现复用。
归纳问题的基本要点。
第一是不要涉及内部的流程，别出现“如果输入不正确，就怎么怎么样”的句子，这些并不是正确的问题，正确的问题必须明确的，清晰的，如果可能的话全部按照“什么可以干什么”的格式来写。
第二是不要一开始就进入细节，包涵太多细节的问题将会是一个长长的清单，这种清单根本没什么用。尽量从最高一层分析，但也不要简单到“用户可以玩游戏”这种笼统的问题。总之一个原则是全面、清晰、明确。要做好问题域分析完全取决于设计师的水平与能力，这就不是可以简单的看看书能达到的了。
第四：系统的组织需求捕获
进行需求捕获之前，最好对业务进行建模，常用的方法包括术语表、域建模和领域知识培训，而采集的信息可以采用wiki这样的知识共享工具有机的共享
（注：域建模指：我们设计一个系统，总是希望它能解决一些问题，这些问题总是映射到现实问题和概念。很明显我们的系统依赖于这些问题，对这些问题进行归纳、分析的过程就是域建模（这个域，指的就是问题域）。
Wiki指的是一种网上共同协作的超文本系统,可由多人共同对网站内容进行维护和更新，Wiki系统可以帮助我们在一个社群内共同收集、创作某领域的知识，发布大家都关心和感兴趣的话题）
在需求捕获开始之前，应该重点解决三个方面的问题：
1） 应该搜集什么信息
细化的研究流程图，看看是否已经清楚的认识了每个环节和每个步骤。我们应该根据自己理解首先对每个流程的工作进行定义，写出时间流并且标识出疑问点，
2） 从哪里搜集这些信息
应从流程涉及到部门或岗位找信息，这点非常重要
3） 用什么机制来搜集
1、 用户访谈-最基本、最常见的技术
2、 用户调查-调查面最广的技术
3、 现场观摩-最生动的技术
4、 文档考古-最贴近现实的技术
5、 联合开发-最理想的技术
第五：基于用例对需求进行建模
需求建模的工作应该在“业务需求”充份理解，并且收集最本质的“用户需求”之后开始需求分析，但并不是等到需求捕获完全做完之后。而且应该采用的是交替进行的方式，首先把握住用户需求的主要部分，然后开始分析。在分析的基础上引入系统级的需求（即从系统的设计与实现角度进行考虑），并且根据分析的结果建立分析模型。这个模型将成为伴随整个需求过程的关键内容，并且成为开发人员之间、开发人员与客户之间达成共识的平台。
要有效地收集需求，您要做的第一步是建模，它包括创建体系结构的表示形式以捕获需求、就解决方案方法进行交流、以及分析所提出的系统设计。其目的是使用模型来表现系统中的关键方面。然后，您可以在形式化的分析、模拟和原型设计中使用这些模型，以研究预期的系统行为，并且可以在编写文档或总结时使用这些模型，以便就系统的性能和外观进行交流。
域建模
域建模 指的是，您对问题域创建相应的模型并且把它划分为若干个内聚组的过程。然后，您可以在抽象模型中捕获业务流程、规则和数据。
域模型是一种用于理解问题域的工具。您需要从信息系统之外的角度来理解这个域，这一点是很重要的。
要构造域模型，您必须完成下列工作：
- 标识并确定参与者（实体）及其操作（活动）的特征。
- 标识管理操作（规则）的策略。
- 收集有关实现这些操作、来自这些操作或者记录这些操作（构件/数据）的信息。
- 将相关的要素划分为子域。
- 确定结果域（核心的/通用的/外部的）以及它们之间交互的特征。
在这个过程中，一个有见地的架构师将学习到很多东西。结果域模型和相关的知识是实现您的角色（作为问题空间和解决方案空间之间的桥梁）的第一步。
用例建模
用例模型 描述了各种参与者（人和其他系统）和要分析的系统之间的主要交互。用例应该说明系统如何支持域和业务流程模型中的业务流程。
用例模型应该将系统放到上下文环境中，显示系统和外部参与者之间的边界，并描述系统和参与者之间的关键交互。用例建模可以描述利益相关者（例如，用户和维护人员）所看到的系统行为。
组件和服务建模
组件模型 为子系统、模块和组件的层次结构分配需求和职责。每个元素作为一个自包含的单元，以用于开发、部署和执行的目的。组件模型的元素由它们所提供和使用的接口来进行规定。在这里，没有考虑其中的内部细节。
服务模型 将应用程序定义为一组位于外部边界（用例）、架构层之间的抽象服务接口，并且提供了通用的应用程序和基础结构（安全、日志记录、配置等等）。支持应用程序需求的这组服务可以与现有的内部和外部提供的接口规范相匹配。所得到的分析结果可以确定预置策略，并将项目活动划分为特定类型的部分，这取决于给定的服务是否已经存在（内部或者外部的，并且其中每个服务都具有适当的活动）、存在但需要进行修改（定义一个新的接口，并规划其实现）、或者必须构建新的服务。
性能建模
您可以通过各种各样的方式来度量性能，最显而易见的方式是，应用程序执行其关键操作任务的速度。然而，作为一名架构师，您必须考虑性能建模 过程中其他的几个方面：
- 构建和部署应用程序的速度如何？
- 构建、维护和运行需要多少花费？
- 该应用程序能在多大程度上满足其需求？
- 对于必须使用该应用程序的人来说，需要为其付出多大的开销？
- 该应用程序会对其他应用程序和基础结构产生怎样的影响？
关于这些问题（和无数的其他问题，这取决于具体情况）的答案，对一个成功的应用程序来说是至关重要的，并且通常称其为应用程序在架构上的质量。对这些质量进行建模是很困难的，甚至比性能的标准质量更困难，后者通常解决处理和数据存储方面的需求。
您可以将其分为应用程序的质量属性，如：
- 执行时间
- 资源使用
- 开发复杂性
- 维护复杂性
第六：利用需求基线来控制节奏
在每次或每几次的迭代中，建立一个刚性的需求基线。
在分析的基础上将需求整合成为用例或功能项，并对其优先级和依赖性进行综合评估。然后将一部分优先级高的需求放入迭代的目标，周而复始，直到所有的需求都已经被实现为止。
第七：持续进行需求跟踪
建立一张映射表，将需求项和分析项、设计项和实现项建立清晰完整的对应关系，以便一目了然的获得所需的信息。
第八：为需求工作建立合适的过程