文档模板库
如何做好需求收集[来自《程序员》第2期]
项目前期需求收集过程的效果好坏，会对软件产品的最终质量产生直接的影响。如何收集好需求，本文作者给出了一条行之有效的实际操作途径。
什么是需求收集？
需求收集，是确定和理解不同类别用户的需要和限制的过程，是需要高度协作的活动，是在问题及其最终解决方案之间架设桥梁的第一步，因此其重要性不言而喻。据调查显示50%以上产品在市场上失败的原因，是由于忽视了用户需求。
需求收集在需求开发活动中的示意图如图1：
如图1
需求收集为什么会困难？
困扰项目组需求收集活动的原因可能如下：
v 需求收集人员往往只关注用户反映的表面问题，而不能主动深入挖掘用户的真实需求；
v 需求收集人员考虑的问题时习惯干“以产品为中心”，而不是“以客户为中心”；
v 用户往往不清楚自己的真实需求是什么，或者不知道如何准确地描述出自己的需求—“我心里很清楚，但就是说不出来”；
v 没有从所有可能的渠道去收集需求，需求信息来源不完整；
v 收集的需求没有规范记录下来，造成原始信息丢失或失真，且无法回溯；等等。
怎么做好需求收集活动？
首先，需要建立需求收集机制。其次，使用统一的需求收集系统。最后，在需求收集时，采取一定的技术和方法。
建立需求收集机制
(1). 明确每个需求收集活动参与者的岗位职责
根据项目组可能的需求来源（需求来源可能包括：市场调研，竞争对手信息分析，标准和协议等等，视项目组的实际情况而定），指定每个需求来源的收集负责人。同时，对通过各个渠道收集的需求信息，指定专门的接口人进行汇总和审核。
(2). 建立需求预处理流程
对收集到的需求，除了指定专门的接口人进行汇总和审核以外，还要建立相应的预处理流程，在对需求进行预处理时，相关的讨论，决策可以通过“需求CCB会议”完成（需求CCB是指：专门用于需求讨论和决策的Change[...]
Read More »
软件需求分析文档
软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化，分析各种可能的解法，并且分配给各个软件元素。需求分析是软件定义阶段中的最后一步，是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。
软件需求分析的任务是：深入描述软件的功能和性能，确定软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求，借助于当前系统的逻辑模型导出目标系统逻辑模型，解决目标系统“做什么”的问题。
需求分析可分为需求提出、需求描述及需求评审三个阶段。
需求提出主要集中于描述系统目的。需求提出和分析仅仅集中在使用者对系统的观点上。用户、开发人员和用户确定一个问题领域，并定义一个描述该问题的系统。这样的定义称作系统规格说明，并且它在用户和开发人员之间充当合同。
在问题分析阶段分析人员的主要任务是：对用户的需求进行鉴别、综合和建模，清除用户需求的模糊性、歧义性和不一致性，分析系统的数据要求，为原始问题及目标软件建立逻辑模型。分析人员要将对原始问题的理解与软件开发经验结合起来，以便发现哪些要求是由于用户的片面性或短期行为所导致的不合理要求，哪些是用户尚未提出但具有真正价值的潜在需求。
在需求评审阶段，分析人员要在用户和软件设计人员的配合下对自己生成的需求规格说明和初步的用户手册进行复核，以确保软件需求的完整、准确、清晰、具体，并使用户和软件设计人员对需求规格说明和初步的用户手册的理解达成一致。一旦发现遗漏或模糊点，必须尽快更正，再行检查。
软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，[...]
Read More »
讨论一下怎么写需求文档
作者：iFire
先谈谈我的想法。
一、要讨论怎么写需求文档，首先就的搞清楚需求的构成，我是这么分的：
1、功能需求；
2、非功能需求或技术需求；
我一般把功能需求划分为几个部分：
a、业务过程；
b、业务规则；
c、业务数据；
非功能需求（技术需求）我就不多说了，大致就是可用性，可靠性，性能，可支持性等等。
二、弄清楚需求的构成后，我们就得考虑以什么样的文档结构来描述这些需求了，UP的做法是这样的：
1、用例规格说明描述业务过程；
2、业务规则文档描述业务规则；
3、术语表描述业务数据；
4、补充规格说明描述非功能需求（技术需求）；
UP的做法还是很有道理的。这体现了两个原则：
1、分离关注点（每个文档描述相对独立的领域）；
2、减少重复（很多用例都会引用相同的业务规则及业务数据）；
这样便能够尽可能的使文档结构清晰，易阅读，易理解。也便于跟踪和维护。
但另一方面由于将不同的领域分离到不同文件的做法也使得可阅读性有所降低。比如用例规格说明中的业务过程描述时常需要引用业务规则文档中的业务规则及术语表中的业务数据。由于不是很方便在各个文档之间导航，你可能需要打开多个文档进行交叉阅读。这是比较麻烦的，特别是对于用户来说。
而且UP中每个用例都单独作为一个文件存在，这可能是为了便于跟踪及管理的缘故吧。但正如上所述，文件多了看着就觉得不爽了。我觉得完全可以将用例合并到一个文档中。或者几个相对独立的文档中（比如根据子系统划分）。
至于交叉阅读，导航困难的问题是否有什么别的方法解决呢？html文档似乎不错。不过写起来似乎没word方便啊。
三、总结：
无论怎么写需求文档，最终的目的无外乎易阅读，易理解，易沟通，易确认，易跟踪，易测试，易验收。我想我们都应该以这个为目标来进行思考。
[...]
Read More »
如何编写优质的需求文档
作者: Job Vranish 来源: 伯乐在线 发布时间: 2012-03-21
英文原文：How to write good requirements
编写需求文档，在嵌入式开发领域是非常普遍的。需求文档被用来定义开发任务，协调大规模的研发计划。对于最终的产品，需求文档扮演着开发者行为和消费者行为之间沟通纽带的角色。当需求文档书写正确的时候，便可以发挥巨大的作用。然而，如果你在嵌入式开发领域工作的时间足够长，你就会很快发现，这个领域里不合格的需求文档实在是太多了。当你尝试对这些不合格的文档进行修复时，你又会很快发现，书写正确的需求文档绝非易事。在这里，我们提出一些建议，希望能将书写正确需求文档这件事情变得清晰一些。
从较高的层次来看，书写需求文档的目的就是要提供对所需行为的有效描述。该所需行为可用一个黑盒系统描述，并需要注意以下细节：
工程师可以根据系统所说进行实现
测试人员，在不与开发人员沟通的前提下，可以利用满足硬件要求的设备验证需求。
最终产生的成果满足终端用户的要求。
黑盒测试
书写优质的需求文档：
最基本的原则是：需求文档应当尽量简洁，用最易懂的描述来约束系统的预期行为。如果你遵循这个原则，剩下的那些重要因素（可测试性、避免过度设计等等）都将变得顺理成章。
列举一下更详细的规则，通常会更有帮助。下面是书写优质需求文档需要遵循的步骤：
1.[...]
Read More »
一个标准的软件开发流程步骤及文档
一个标准的软件开发流程需要有哪些步骤，写哪些文档？
1、先是需求调研，出《需求文档》；
2、 然后概要设计，出《概要设计文档》；
3、然后详细设计，出《详细设计文档》；
4、然后就是编码，出软件代码，最好能出单元测试文档；
5、然后就是联调，可能有多个部分，需要联合测试；
6、最后就是软件交付了，交付软件、代码、使用说明书
软件开发流程（Software[...]
Read More »
概要设计的格式模板及相关内容说明
概要设计的主要任务是把需求分析得到的DFD转换为软件结构和数据结构。
设计软件结构的具体任务是：将一个复杂系统按功能进行模块划分、建立模块的层次结构及调用关系、确定模块间的接口及人机界面等。
数据结构设计包括数据特征的描述、确定数据的结构特性、以及数据库的设计。显然，概要设计建立的是目标系统的逻辑模型，与计算机无关。
简述
概要设计有多种方法。在早期有模块化方法、功能分解方法；在60年代后期提出了面向数据流和面向数据结构的设计方法；近年来又提出面向对象的设计方法等。
概要设计的格式
概要设计的格式如下：
1引言[...]
Read More »