软件需求分析
可行性研究阶段：粗略了解用户的需求，提出一些可行方案。基本目的是以最小的代价在尽可能短的时间内确定问题是否存在可行的解法。而在软件需求分析阶段，需要对可行性研究的问题，进行准确的分析“系统必须做什么”。
软件需求分析是软件开发期的第一阶段，是软件生存周期最重要的一步，是关系到软件开发成败的关键步骤。在此阶段结束前，系统分析员要写出软件需求规格说明书，以书面的形式准确地描述软件需求。
软件需求分析的任务，还不能确定系统该怎么样完成它的工作，而仅仅是确定系统必须需要完成哪些工作，即对目标系统提出完整，准确，清晰而且具体的需求。
首先，把用户提出来的各种问题和要求（这些问题和要求往往是十分模糊的）归纳整理，分析和综合，弄清楚用户想要做什么，应当做什么，把这些作为要求和条件予以明确，这一步称为“用户意图分析”。
第二步，是在完全弄清用户对软件系统的确切需求的基础上，用“软件需求规格说明书”在此基础上建立分析模型，从逻辑上完整、严密地描述所要开发的系统，并保证它能满足上述要求和条件，这一步称为“规范化”。
需求分析阶段的具体任务：
.一，确定对系统的综合需求
分析员和用户双方确定对软件系统有下述几方面的综合要求。
.1）功能需求
指所开发软件系统必须提供的服务，划分出系统必须完成的所有功能，这是最重要的。
.2）性能要求
指所开发的软件的技术性能指标。通常包括存储容量、运行时间等限制。
.3）环境需求
指软件运行时所需要的软、硬件（如机型、外设、操作系统和数据库管理系统）的要求。
.4）接口要求
接口需求描述应用系统与它的环境通信的格式。常见的接口需求有用户接口需求、软件接口需求、意见接口需求和通信接口需求。
.5）用户界面需求
即指人机交互方式，输入输出数据格式等。
另外还有可靠性、安全性、保密性、约束、可移植性和可维护性等方面的需求
二，分析系统的数据需求
系统处理信息和产生信息，需要使用到分析的软件需求分析的任务。分析系统的数据要求通常用建立数据模型的方法。（例如实体联系图等）
三，建立软件的逻辑模型
通常用数据流图，数据字典及处理算法等来描述目标系统的逻辑模型。
四，编写软件需求规格说明书
目的：使用户和开发者能对未来软件有共同的理解，明确定义未来软件的需求，系统的构成及有关的接口。
需求说明时测试验收阶段对软件进行确认和验收的基准，是软件开发的基础。
需求说明应该具备以下几个特征（内容）：准确性和一致性；清晰性和唯一性；完整性和可检验性；运行维护阶段的可利用性（可维护性和可复用性）；
直观，易读和可修改性。
需求说明内容特点的要求：尽量在需求说明中采用标准的图形，表格和简单的符号来表示，尽量不用用户不易理解的专门术语，使不熟悉计算机的用户也能一目了然。
五，需求分析评审
评审的目的是发现需求分析的错误和缺陷，然后修改开发计划。因此，评审是对软件需求定义，软件功能及其接口进行全面仔细的审查，以确认“软件需求规格说明”，使其作为软件设计和实现的基础。
需求分析的步骤
要想产生符合要求的软件需求说明书之前，需要完成需求分析的4个步骤。
.1需求获取，调查研究
需求分析阶段要做充分的调查研究，对目标系统的运行环境，功能要和用户取得一致的意见。
补充另一本书内容：
获取需求的方法有多种，如问卷调查，访谈，实地操作，建立原型等。
1）问卷调查是采用让用户填写问卷的形式了解用户对系统的看法。
2）访谈是指开发人员与特定的用户代表座谈的需求获取方法。
3）如果开发人员能够以用户的身份参与到现有系统的使用过程中，那么在亲身实践的基础上，观察用户的工作过程，发现问题及时提问，开发人员就能直接体会到现有系统的弊端以及新系统应该解决的问题。
4）为了进一步挖掘需求，了解用户对目标系统的想法，开发人员有时还采用建立原型系统的方法
2.需求提炼：分析建模
需求提炼的主要任务是建立分析模型。把来自用户的信息加以分析，通过抽象建立起目标系统的分析模型。常用的模型包括数据流图，实体联系图，控制流图，状态转换图，用例图，类对象关系及其行为图等。在面向工程的软件工程中，主要采用数据流图建立目标系统的逻辑模型。
3.需求描述：编写SRS（软件需求规格说明书）
为了使需求描述具有统一的风格，可以采用已有的且可满足项目需要的模板，如在国际标准IEEE标准830—1998（IEEE—1998）中和中国国家推荐标准GB 9385中的描述的模板，也可以根据项目特点和软件开发小组的特点，对标准进行适当的改动，形成自己的SRS模板。
另一本书内容：
需求描述就是指编制需求分析阶段的文档。复杂的软件系统在需求阶段会产生3个文档：系统定义文档（用户需求报告），系统需求文档（系统需求规格说明书），软件需求文档（软件需求规格说明书）。
软件需求规格说明书主要描述软件部分的需求，它站在开发者的角度，描述开发系统的业务模型，功能模型，数据模型，行为模型等内容。
对大型软件项目，在需求分析阶段要完成多项文档，包括可行性研究报告，项目开发计划，软件需求说明，数据要求说明和测试计划。
对中型的软件项目，可行性研究报告和项目开发计划可以合并为项目开发计划，软件需求说明和数据要求说明可以合并为软件需求说明。
对小型的软件项目，一般只需而完成软件需求与开发计划即可。
4.需求验证
由分析员和用户一起对需求分析结果进行严格的审查、验证。有些看起来没有问题的SRS，但在实现时却出现需求不清、不一致等问题和二义性问题，所有这些都必须通过需求验证来改善，确保需求说明可作为软件设计和最终系统验收的依据。
在实际工作中，一般通过需求评审和需求测试工作来对需求进行验证。
另一本书补充的内容：
5.用户故事（User Story）
敏捷开发方法提倡使用“用户故事”替代传统需求描述。用户故事是从用户的角度来描述他所期望得到的功能。
As a <Role>，I want to <Activity>，so that <Business Value>.作为一个<角色>，我想要<活动>，以便于<商业价值>
其中：
（1）角色（user-role）：谁要使用这个功能。
（2）活动（activity）：需要完成什么样的功能。注意区分用户操作和产品功能之间的关系，因为产品功能可能也提供了用户所需的价值，但却极可能不便于操作。
（3）价值（business-value）：为什么需要这个功能，这个功能可以给用户带来什么价值或者好处。
需求分析的常用方法
常用方法：功能分解方法，结构化分析方法（SA），信息建模方法，，面向对象分析方法，面向数据结构的Jackson方法（简称JSD），用于建立动态模型的状态迁移或Petri图。（后两点是在另一本书上提到的）
方法共同点：采用图文结合的方式，可以直观地描述软件的逻辑模型。
（1）功能分解方法，
将一个系统看成由若干个功能构成的一个集合，每个功能又可划分若干个子功能（加工），一个子功能又进一步分解成若干个子功能（加工步骤）这样功能分解方法有功能，子功能和功能接口3个组成要素。
就是把软件需求当作一棵倒置的功能树，每个结点都是一项具体的功能，从树根往下，功能由粗到细，树根是总功能，树枝是子功能，树叶是子功能，整棵树就是一个信息系统的全部功能树。功能分解法体现了“自顶向下，逐步求精”的思想，本质上是用过程抽象的观点来看待需求，符合传统程序设计人员的思维特征，最后分解的结果一般已经是系统程序结构的一个雏形，实际它已经很难与软件设计明确分离。这种方法难以适应用户的需求变化。
（2）结构化分析方法
软件功能由数据流图表示，是结构化方法中重要的，被普遍采用的方法，它由数据流图和数据字典构成系统的逻辑模型。
（3）信息建模方法
信息建模方法的基本工具是实体联系图，由实体、属性和联系构成。
（4）面向对象方法
面向对象的分析是把实体联系图中的概念与面向对象程序设计语言中的概念结合在一起形成的一种分析方法。
需求的分类
软件需求的分类可以从多个维度上进行，它们可以彼此交叉。
1）按照软件需求修饰的对象的不同，可以将其分为以下需求。
① 软件产品需求。主要约束的是软件产品本身的属性。产品需求又可以细分以下两种。
● 功能性需求指代软件产品的功能特性。
● 非功能性需求是软件产品的质量属性，是在功能性需求满足情况下的进一步的要求。
② 软件过程需求。是修饰或者限制软件开发过程的要求。
2）按照软件需求面向对象的不同以及其抽象层次和详细程度的不同，可以将需求分为以下种类。
① 业务需求。主要是针对业务部门的分析人员的。
② 用户需求。针对客户方、承包方的管理人员、最终用户、客户工程师和系统架构师的。③ 系统需求。是由最终用户、客户工程师、系统架构师和承包方的程序员所关注的。
④ 软件设计规约。是由客户工程师参考系统架构师和承包方的程序员重点关注的。
3）系统需求明确待开发系统的特性，通常可分为以下种类。
①功能性需求。确定问题域内系统的预期行为及其产生的影响，这些需求通常描述了产品的主要特征。
② 非功能性需求。描述了不直接关联到系统行为系统的方方面面。
● 功能性（Functionality）：列出需要考虑的额外的功能需求，如安全性，就是要确保数据的完整性和对信息的访问授权。
● 可用性（Usability）：指的是易用性、美观性、一致性和文档化。
● 可靠性（Reliability）：指的是在特定操作环境下预期的系统故障频率、可恢复性、可预测性、准确性以及平均故障时间，是系统在给定时间内以及指定条件下完成其要求功能的能力。
● 性能（Performance）：指响应时间、效率、资源利用率和吞吐量。
● 可支持性（Supportability）：指可测试性、适应性、可维护性、兼容性、可配置性、可安装性、可扩展性和本地化。
“FURPS+”中“+”是指一些辅助性的和次要的因素，包括如下通用非功能性需求标识。
● 接口（Interface）：强加于外部系统接口之上的约束，包括合法系统和交互格式。
● 操作（Operation）：对其操作设置系统管理，即管理员和系统操作设定方面的约束。● 包装（Packaging）：是系统实际提交方面的约束，例如物流的包装盒。
● 授权（Legal）：是使用许可证、规则和认证等方面的问题。