项目管理-需求设计

需求阶段

    装修一套新房，屋主一般会告诉装修队伍房屋布局、各个部位的装修要求等，描述和要求越详细，满足期望值的可能性越高；地砖是深颜色的，屋主自以为装修队伍知道接缝线应该处理成黑色，所以没有明说，装修队伍却按惯例处理成白色，这产生了争执和返工。所以，需求做得全面和被深度挖掘，后头阶段的工作将开展得非常顺利。

    判断是否做好需求的标准是：清楚、完整、一致、可测试：

• 清楚：需求沟通和描述的用语要通俗化、生活化、简单化，宜用沟通双方都能理解的词汇。忌过多使用技术专用术语，忌模棱两可的说话或描述；“可能、也许、大概”等不确定的词语不要使用，这说明需求尚未明确或没弄明白。
• 完整：遗漏的需求或早或晚会被暴露，暴露时间越往后，组织付出的代价越大，项目经理和项目成员承受的压力越大；而且如果漏掉的需求属于关联性很强或基础部分的，那么改动量更大，项目经理就等着做恶梦了。
• 一致：需求包括业务需求、用户需求、功能需求（也包括非功能需求）这三个层次，要保证不同层次间表达的内容是一致的、和谐的、涵盖合同范围的，这也保证软件成品不会偏离实现目标。
• 可测试：需求是设计和测试案例的输入和参照，可测试性可以保证需求能被理性的验证和检查的，避免感性的表述。

2.1 需求说明书

    该文档根据《项目发起书》、《可行性报告》、《沟通计划》、《总体计划》进行调研编写而出，是项目后续阶段的基石，工作一定要做到位。项目经理整理审核《需求说明书》，召开组织内部评审会，会议内容是比对需求是否都涵盖合同要求、需求是否合理可行等。通过评审后，如果条件允许，项目经理到客户处做1-3次需求阐述会（超过3次，可能是双方沟通不畅或调研工作不到位），会上项目经理逐条讲解需求，听取客户反馈——是否有错误的需求理解、是否有漏掉的需求等。最后该文档发送给甲乙双方签署。

    常听到一些项目经理抱怨客户不肯签署文档，抱怨改变不了现状或对项目有帮助，必须跟客户充分交流找到原因，例如：

• 文档描述模糊不完整不清晰，客户没有胆量签署这样的文档（文档没有很好地整理审核过）。
• 客户理解不了文档内容，有些文档编写者会忽略读者群的知识背景，使用过多专业术语（没有给客户开需求阐述答疑会）。
• 客户对文档有异议，但软件公司的人给他放下文档后，再不露面、打电话或发邮件；一边他等着反映情况，一边项目组等着他签署文件。这明显是消极沟通带来的恶果。

    世界万物都有特质，除了那些身经百战做过很多项目的客户外，大部分客户容易改变想法或不断冒出新想法，这是需求阶段的特质之一，有些项目经理常常抱怨这点并期许“如果客户能一次拿定主意就好了”，这种想法只能说是美好的但不可行，正如突然要求素食者吃肉嗜肉者吃素一样，引入业内流行的一句话："没有不变的需求，世上的软件都改动过3次以上，唯一一个只改动过两次的软件的拥有者已经死了，死在去修改需求的路上。"。这阶段适宜跟客户保持高频度的沟通交流、保证沟通渠道的顺畅、主动帮助客户完善需求、积极给客户提供正确专业的建议等等。

    需求说明书定稿后，项目组据此编写《美工工作列表》，即美工要做出多少个UI页面，这些页面也要让客户审阅和签署的，设计阶段会说到。

3. 设计阶段

3.1 产品规格说明书

    当软件多次销售或多次使用时，需要这份文档面向一种以上的客户。它依据《需求说明书》而编写，主要是以非技术性的大众化的语言描述软件具备的功能，例如第一次用液晶电视，会根据《产品规格书》来调试频道而不是看电路板图。

3.2 美工UI页面

    美工根据《美工工作列表》做出UI页面，项目经理一般跟美工讨论、完善页面3-7次（如果次数过多，说明沟通出现误差）后定稿。UI页面很直观地展示系统外貌，用户有时会据此确定软件整体色系、整体页面布局是否符合客户使用习惯、指出误漏和能优化的地方，从而增加用户满意度、减少界面返工概率、减少开发时对界面布局的讨论等。

    UI页面一定要往细节做，除了客户原因外，做得细的UI页面能很好地满足开发需要，避免项目组成员花费太多无谓时间在界面讨论上；把项目同性质事情统一处理，这是有效省时的工作方式。

3.3 系统设计

    系统设计文档的内容主要有硬件网络图、软件技术架构、源代码文件夹结构、公共设置、模块设计、数据底层架构设计、数据库设计等：

• 硬件网络图：画出软件所处的硬件及其网络分布图。
• 软件技术架构：列出用到的技术，如果是多种技术，阐述技术间的工作方式和关联性；阐述技术的特性，尽量以图片表达。
• 源代码文件夹结构：树状结构列出存放代码的所有文件夹结构。
• 公共设置：所有公用的都放在这里，例如Web Server配置、数据库配置、Java公共类、Struts配置文件、XML文件等等。这部分的描述一定要尽量详细、深思熟虑、全面涵盖，因为它们的使用频率高而且影响范围广。
• 模块设计：先列出工作分解结构WBS和整体模块关联情况，再分模块描述其要完成的功能、特性、商业逻辑、页面要求（有美工UI页面的，列出）等等，尤其要给每个页面定义文件名，模块之间常有链接、调用、包含关系，定好文件名能提高工作效率，避免开发混乱。这部分建议全组参与，先由技术专业人员完成1-4个重要模块的商业逻辑和数据IPO（输入-处理-输出）描述后，剩下的由有相同技术背景的组员完成，这能让组员充分理解需求和提前理清开发整体思路。
• 数据底层架构设计：现在主流的开发语言设计模式会分出商业层和数据层，商业层跟需求有密切关系，数据层只关注数据存储和处理，跟需求无关；如果项目资源不够，这块可以邀请项目外技术专业人员协助完成，或者在需求初期就开始做这部分。主体数据底层架构出来后，接着完成1-4个典型模块的程序流向即可，剩下的照葫芦画瓢；当然，如果有时间，全部完成所有模块的是最好的。
• 数据库设计：DB数据表结构需要进行审核，以保证数据结构是最优化的。

 

3.4 测试案例

    软件测试常用白盒测试和黑盒测试，一般开发阶段做白盒测试，测试阶段做黑盒测试。这里的测试案例是为黑盒测试准备的，内容因各个项目而异，例如：

• 所有模块的可见页面是否齐全，是否《系统设计》、《需求说明书》（若有《产品规格说明书》一并参考）中列出的都有。 
• 可见页面的所有链接是否都工作正常。
• 可见页面的动态数据是否符合逻辑流程和商业要求。
• 表单提交页面是否能通过非常规测试。
• 可见页面是否满足美工UI页面，如果字体颜色不对、图标位置错误等等，都要予以纠正。
• ……

    项目组和客户各自写一份《测试测试》，彼此不能交换文档。一般项目组习惯侧重于功能、技术、逻辑等，客户侧重于界面、是否符合工作流程、是否满足需求等；如果互相交换文档，有时受先入为主的影响而局限测试案例的设计思想，有时项目时间过于紧张，文档编写人员会抄袭，这是不负责任的。

    文档格式例子见表5。

唯一标识符	测试案例编号	依存关系	类别/模块	测试区域	需求说明书编号	特征/功能	测试步骤	正确结果
1	1A		登录	档案系统	2.1	录入员正确登录	1) 打开IE窗口，访问http://192.168.1.88/login.jsp 2) 输入帐号ql1，密码1234	1) 显示登录页面 2) 进入index.jsp页面
2	1B		登录	档案系统	2.1	录入员错误登录	1) 打开IE窗口，访问http://192.168.1.88/login.jsp 2) 输入帐号fafadf，密码fadfadsf	1) 显示登录页面 2) 停留在登录页面，页面提示帐号或密码不正确
3	2A	1A	录入员主页	档案系统	2.2	录入员主页	1) 执行1A 2) 点击“档案管理” 3) 点击“档案类型”	1) 页面显示“档案管理”和“档案类型”两个链接 2) 转向3A 3) 转向4A

表 5