2009年5月的需求规格书评论总结
今天翻以前写的资料，偶然看到一篇总结，觉得有点用，就贴出来供以后再系统性的整理。
项目需求分析总结——对某出版集团项目的需求规格说明书的修改意见总结
2009.5
本文以近期对某出版集团项目的需求规格说明书的修改情况为主，结合在其他项目了解到的情况，总结了一些常见问题和经验，供大家今后在需求分析和编写需求规格说明书时参考借鉴，有不对的地方请指出。
1. 需求规格说明书的用途概述
1.1. 常见问题
一些开发人员在编写需求规格说明书时，对需求规格说明书中各部分的用途不是很清楚，经常出现下列问题：
1） 为写而写，应付检查，尤其是在事后补CMM文档时容易发生；
2） 将需求书写成了用户使用说明书，出现大量最终界面，局限于已开发程序；
3） 忽视用户的期望，或者需求调研不够深入，开发人员自己假想出需求；
4） 从开发人员角度来写，用了很多技术术语，没考虑用户和领导能否理解；
1.2. 核心价值
编写需求规格说明书的关键不在于“写”，而在于“看”，即用于其他人阅读和检查。所以我们不需要在如何写得好看上面下很多功夫，但一定是要能让人看明白，理解上不会出现较严重的歧义，要用他们熟悉的话语表达，要考虑是给特定人看的。
其次，需求规格说明书是用于追求更少的需求变更，尽可能准确和完整的描述出需求，避免因需求不明确或错误给开发过程带来返工和浪费。
1.3. 读者关注点
编写需求规格说明书是要让人看的，有下列人员需要阅读和关注需求规格说明书：
a、用户领导
关注所能达到的宏观目标，这关系到上项目的意义和价值，所以如果我们明确写明项目目标就比较好，需要注意不要过多涉及细节；
关注项目范围，涉及到资金、周期、协调；
关注对现有部门的影响，决定是否需要部门调整和安排；
b、用户技术领导、项目负责人
除了关注用户领导的范围外，还关注如何实施、业务流程的合理性、软件效果等；
c、最终用户
一般不会阅读需求规格说明书。关注软件细节问题，如最终软件是否易用、合理，对软件存在的问题比较在意，对项目有评估权，没有决定权。
d、开发领导、产品经理
关注面较广，关注技术方案、项目需求是否合理、优先级等；
e、设计编码人员
关注需要实现哪些功能需求、需要注意的问题；
f、测试人员
关注如何测试、如何使用，需要理解功能需求；
2. 需求规格说明书的各部分用途及注意事项
2.1. 名词定义
用于描述需求规格说明书中容易混淆或不明白的名词术语。如果读者老是问一些词是什么意思，就该在名词定义部分说明，或者在第一次出现的地方说明。
这部分的常见问题是常常流于形式，写的多是大家都知道的。
2.2. 项目背景
用于提醒大家为什么要启动本次开发。
2.3. 项目目标
很重要，准确概括的描述出本次项目需要达到的目标，既要高度概括又要准确无误。用户领导和项目负责人很关注项目目标的内容。
描述项目目标需要注意下列问题：
1、避免使用模棱两可的话，不说大话，避免让人无限联想，防止引发出新的系统；
2、避免过分涉及技术细节，毕竟这部分还只是高层次目标（想想用户领导能否看懂）；
3、以用户期望的目标为主，不要把我们自己的设想单方面加进去；
2.4. 运行环境
描述出用户需要配备的设备、网络情况、是否需要设备采购和改造；
如果这部门写的比较准确的话，可供开发人员考虑是否符合实际运行环境。
需要注意网络情况、部署情况，例如物理位置分布情况、是否在同一局域网内、百兆网/千兆网/宽带连接/ADSL/VPN/共享宽带，这对我们系统的设计和实施至关重要。
2.5. 与其他系统的关系
实际上描述出了项目边界，需要把这部分内容提前到项目描述章节，以便用户领导和项目负责人等读者能结合项目目标一起很明显的看到项目范围和相互衔接情况。
这部分内容不能使用模棱两可的话，一定要准确清晰的描述。
这部分内容一定要很清晰的看出我们需要开发的系统是哪些部分。
与其他系统的衔接要明确出接口方式、衔接情况，明确责任，准确界定边界。
2.6. 客户现状分析
详细准确的列出客户目前的现状（文件资源、部门、网络、已有系统、协作单位、现有流程、目前问题等），这部分内容的用途是为准确进行系统分析提供充分的依据，也是系统能给用户带来哪些价值以及系统解决重点的分析材料。
2.7. 业务流程描述
这部分描述用户使用场景（业务流程、业务需求），具体描述了我们的系统实施后各个部门人员是如何工作的。这部分需要详细描述，用户从这里了解新系统是否符合使用流程，系统分析人员以此决定需要哪些功能来满足，开发人员可了解功能将在哪些环节使用。
如果没有这部分内容，直接就是一大堆功能点，就不能准确判断出提供的这些功能是否满足用户需要。
对于有多种使用情况的分别描述出使用场景。
描述业务流程需要注意的地方有：
1、采用用户能理解的语句表述，不使用专门技术术语，不涉及技术细节；
2、描述出哪些部门、哪些人员、什么时候、做什么事情、如何做、为什么做，描述出系统应提供的响应和责任；描述出涉及到的其他系统；
3、用户看不见的内部细节不描述；
2.8. 功能需求
这部分内容主要是给开发人员和测试人员阅读的，具体描述了需要提供哪些功能。如果已经没写业务需求的话，就只好从功能需求中看了，当然这是不好的。
功能需求需要注意的地方有：
1、描述出需要实现哪些功能、操作过程及要求，不要写成用户使用说明书。
2、不要插入大量实际用户界面，有界面也仅是界面示例，不能写成“功能如图所示”。
3、不能过分简单，新功能需要明确描述，已实现功能不用太详细，应详细程度一致；
2.9. 重点难点问题分析
需求规格说明书中出现的疑问都不应直接提出疑问，应当作为不明确待调研的问题，不要期望由用户来解答其中的问题。
如果是因为技术复杂等原因不方便列为本阶段的范围，就需要直接说明难点原因和对策，以便用户能理解现实局限性。
3. 需求调研需要注意的问题
准确详细的需求调研和分析是项目成功的关键，下面列出一些需要注意的地方：
1、准确了解用户期望和用户现状，不要想当然的开发；
2、不要过于局限于已有系统而忽视用户所需，不要先入为主；
3、如果是由开发人员进行需求调研，需要注意切换角色，根据情况切换到需求调研、系统分析、设计、编码、项目管理等角色；另外需要注意不要首先想到技术实现，首先要调查清楚需求，然后决定哪些人来决定技术实现问题；
4. 业务需求描述的改进实例
4.1. 实例：总体业务流程图
原来情况：
问题：
a． 这个图属于系统解决方案图或功能结构示意图，作为总体业务流程图则太细；
b． 要么将这个图放到功能需求部分中，要么改为简单直观的体现大的业务流程；
改进情况：
改进总结：
对于总体业务流程图，尽可能体现用户能看到的业务流程的总体情况，尽可能不涉及细节功能和存储技术。
整体系统的业务流程图可以不涉及用户角色，主要是表现有多少大的流程子系统。
4.2. 实例：图书库业务流程
原来情况：
问题：
a． 子系统的业务流程需要考虑有哪些部门参与、有哪些业务实体；
b． 子系统的业务流程图不需要涉及细节功能和内部技术；
改进情况：
改进总结：
业务流程图中要涉及到用户实体及数据来源（部门、已有系统、角色），在流程箭头上可写上特殊说明的操作方式或数据文件。
4.3. 实例：图书采集的业务流程描述
原来情况：
问题：
a． 业务流程图图标混淆、流程步骤太细、角色和流程环节不对应；不应体现内部分多少库；
b． 流程描述部分太粗，需要准确说明各种人员做什么事、先后顺序；
改进情况：
改进总结：
需要体现用户和系统分别需要作什么事，可以对较敏感的操作方式作出明确说明，例如：手工命名、自动入库、收集文件、通过xxx工具。
4.4. 实例：图书加工业务流程
原来情况：
问题：
1． 除了前一例的问题外，此处还有：不应体现具体用户界面；
改进情况：
4.5. 实例：图片库业务流程
原来情况：
问题：
改进情况：
4.6. 实例：音视频库业务流程
原来情况：
改进情况：
5. 功能需求描述的改进实例
这部分主要是给开发人员看到，各种注意事项暂时省略（要写出来可能要不少篇幅）。
6. 非功能描述
个人觉得最好把非功能描述分别写到用例中，这一部分只写全局性通用的非功能。
