项目需求分析

　　作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。 它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上所具有的选择限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能，多角度描述产品对用户和开发人员都极为重要。 　　需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。项目也有其它方面的需求，如开发环境需求或发布产品及移植到支撑环境的需求。尽管这些需求对项目成功也至关重要，但它们并非本书所要讨论的。 　　开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将会最终给系统带来极大损害的部分，而且以后再对它进行修改也极为困难。 　　不重视需求过程的项目队伍将自食其果。需求工程中的缺陷将给项目成功带来极大风险，这里的“成功”是指推出的产品能以合理的价格、及时地完成并在功能、质量上完全满足用户的期望。下面将讨论一些需求风险。第 5章将介绍怎样应用软件风险管理从而防止与需求有关的风险的出现和不适当的需求过程所引起的一些风险。 　　（1

对大多数人来说，若要建一幢数百万元的房子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根” (Leffingwell 1997) 。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟 ( 期望差异 ) —开发者开发的与用户所想得到的软件存在着巨大期望差异。 在软件工程中，所有的风险承担者 (stakeholder)( 这个词很有意思，原义是赌金保管者。我看过很多的翻译，有翻译成涉众的，也有的翻译成参与者的，但是我想他的主要意思就是和这个项目有密切相关利益的人 ) 都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员 ( 负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人 ) 、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础，所以所有风险承担者最好是采用有效的需求分析过程。软件需求的定义 IEEE 软件工程标准词汇表 (1997 年 )

组织过程资产库下面有组织级标准过程库， 这个库里一共有19各PA（就是标准过程啦） PA的英文是Process Area CM（配置管理过程，英文是Configuration Management） 项目研发和管理过程中会产生很多工作成果，例如文档、程序和数据等，它们都应当被管理起来，以便查阅和修改。鉴于用户的需求会发生变更，导致项目的相关产品也会随之变更，为了使项目的所有过程和产品保持一致性，并且便于跟踪控制，我们需要建立一套严格的配置管理流程 制定配置管理计划 配置库管理 版本控制 变更控制 配置审计 DAR（决策分析过程，英文是Decision Analysis And Resolution） 当项目出现重大问题的时候，为了降低问题所带来的风险，需要一套系统的方法来帮助项目选择一个解决方案 识别需要决策分析（DAR）的问题 组件决策委员会 建立评价准则和评分方法 提供候选方案 评价候选方案 选择最优解方案 跟踪解决方案 IPM（集成项目管理过程，英文是Intergrated Project Management） 集成项目管理的活动贯穿在项目定义、项目计划、项目开发和项目结束这四个项目阶段过程中 建立已定义过程 使用组织过程资源策划活动 建立工作环境 集成计划 使用集成计划进行管理 贡献组织过程资产 MA（度量和分析过程，英文是Measurement and Analysis

先说项目开发过程中团队人员的分工协作。 　　 一、人员安排 　　毕业至今的大部分项目都是独立完成，虽然也有和其他同事协作的时候，但自认为对团队协作的了解和认知都还有所欠缺。很清楚团队协作的重要性，但尚未有很好的机会在相对成熟的团队中锻炼实践。 　　先抛开 软件开发 团队中人员的具体安排不讲，单纯的看软件开发工作的分工。在上面设想的开发架构中，宏观上可将一个项目划分为前端、程序、 数据库 三个模块。由此可推导出团队中需要的成员：美工、程序员和项目经理。 　　认为理想的软件开发团队由四个专业技能过硬的成员组成：一个美工，熟悉UI的设计并具备将效果图转换成前端页面的能力，也就是得同时精通PhotoShop、HTML、CSS、jQuery等前端知识；一个程序员，熟练掌握代码的编写重构；一个项目经理，具备 需求分析 的能力、数据库设计维护的能力、架构设计的能力、程序编写的能力、前端样式脚本编写的能力，最重要的是对业务流程有精准的把握；一个部门经理，和前三位不一样，部门经理只具备领导能力即可，他是兼职，不需要把全部时间投入到团队中。 　　大部分中小型项目可以由这样的四人团队完成，可如果项目较大，已经大大超出了四个人可完成的工作量，可以再加一个前端开发人员。也就是说两个前端开发者，一个负责UI设计，做出完整的效果图，这个人的设计功底应该比较强；一个负责将效果图转换成页面，并完成样式、脚本等的编写

一、我们应当如何做需求分析？ 通过阅读《我们应当怎么做需求分析》我了解了需求分析需要进行的阶段，以及需要掌握的内容。 需要掌握的内容如下： （ 1 ）需求调研：其中包括如何与客户交流、建立良好的合作关系、通过研讨会与客户交流获得项目的原始需求并对需求进行研讨，并采用迭代的方式进行需求的不断完善。 （ 2 ）需求分析：分析用例、分析业务流程、构建用例说明、其他例如查询功能的分析、子用例及扩展用例的分析、行动图和状态图、业务领域分析、原文分析、非功能需求分析。 （ 3 ）需求确认：列出需求列表得到用户确认、利用快速原型法得到用户的确认、构建需求规格说明书。 一、需求调研 1 、与客户初识： 要树立良好的职业威信。不要在客户面前唯命是从，要适当地提出自己的见解，这样不但会让客户对自己有信心，而且自己也可以规范化客户的需求，不至于客户提出什么我们就按照客户说的做什么。 进行详细的角色分析，对号入座。客户方有很多的角色，每一个角色都有自己独特关注的地方，要合理地进行角色分析，让他们了解他们所希望了解的问题，对于需求的调研分析非常地重要。 从宏观上制定目标。在将角色进行分析后，要对每一个角色进行特定地分析，与各个角色进行详细地业务分析，详细了解业务的流程，对于需求的分析非常重要。 2 、拜访客户 需求分析需要与客户进行交流，与人交流就要处理好与他人的关系

说明： 《火球——UML大战需求分析》是我撰写的一本关于需求分析及UML方面的书，我将会在CSDN上为大家分享前面几章的内容，总字数在几万以上，图片有数十张。欢迎你按文章的序号顺序阅读，谢谢！本书已经在各大网上书城及书店销售，欢迎你的关注。 ------------------------------------------------------------------------------------------------------------------------------ 第2章 耗尽脑汁的需求分析工作 摘要 ：怎么又变了？当初就应该让客户书面签字 确认 ！你可能会经常发这样的牢骚，可是就算客户书面确认，客户还是会“赖账”的！ 软件 项目 的其中一项不变真理：人是会死的， 需求 是会变的！本章将会和你一起来体验软件 需求分析 工作的风风雨雨，找出需求分析工作的根本之道，了解 UML 如何帮助我们提升需求分析的水平。 2.2 持续进化的客户需求 你可能曾遇到过这样的情况：客户今天想要一个苹果，明天改变主意要一条香蕉，但后天突然又说还是苹果好，到最后他想要一个西瓜！遇到这样的情况，你会抱怨客户吗？你会后悔当初没有让客户签字 确认 吗？ 楚国有人坐船渡河时，不慎把剑掉入江中，他在舟上刻下记号，说：“这是我把剑掉下的地方。”当舟停驶时，他才沿着记号跳入河中找剑，遍寻不获

第2章 耗尽脑汁的需求分析工作 摘要 ：怎么又变了？当初就应该让客户书面签字 确认 ！你可能会经常发这样的牢骚，可是就算客户书面确认，客户还是会“赖账”的！ 软件 项目 的其中一项不变真理：人是会死的， 需求 是会变的！本章将会和你一起来体验软件 需求分析 工作的风风雨雨，找出需求分析工作的根本之道，了解 UML 如何帮助我们提升需求分析的水平。 2.3 给客户带来价值，需求分析之正路 手机短信订餐系统 接下来我将会介绍一个手机短信订餐系统的故事，这是一个由真实个案改编的故事，通过这个故事来体会 需求分析 工作背后的道理。 某IT公司规模不大，员工100来人。公司有一个简单的定餐系统，员工每天可以在公司内部网站上提交当天午餐定餐，前台汇总各人定餐后，将定餐汇总传真给餐厅，餐厅根据传真送餐。 可是有这样的问题：部分员工因为上午请假或者外出工作，无法再网站上提交订餐，以至于中午回到公司时没有饭吃。 于是老板想出了这样的办法：做一个手机短信定餐系统，不在公司的员工可通过手机短信定餐。 于是成立了手机短信定餐 项目 小组，购买了手机短信收发的硬件，解决了选餐单、定餐、取消定餐等技术问题。但这个系统一会灵一会不灵，问题是出在 软件 、硬件，还是中国移动都难以搞清楚！做项目做麻烦的事情之一就是遇到“幽灵问题”，时而出现时而正常，项目小组挥汗如雨地试图解决这些问题，可一直没有办法搞定。

摘要 ：怎么又变了？当初就应该让客户书面签字 确认 ！你可能会经常发这样的牢骚，可是就算客户书面确认，客户还是会“赖账”的！ 软件 项目 的其中一项不变真理：人是会死的， 需求 是会变的！本章将会和你一起来体验软件 需求分析 工作的风风雨雨，找出需求分析工作的根本之道，了解 UML 如何帮助我们提升需求分析的水平。 2.5 小结与练习 小结 本章最主要的目的其实就是帮你“洗脑”！ 需求分析 的工作其实很复杂，可以足够写一本书的内容。而我希望只通过一个章节能向你讲清楚 需求 分析工作的基本道理，让你认清需求分析工作的根本，并且明白到要做好需求分析工作并没有捷径，只有切实提高自身水平。下面我们一起来回顾一下本章的主要内容： 认识清楚需求分析工作中客户方和 软件 公司一方各种角色的特点，能帮助我们需求分析工作更有针对性。总体来说，客户方的倾向是花小钱办大事，而软件公司一方的倾向是多拿钱少办事。 “双赢”是我们应该追求的目标，软件只有对客户的工作真正有帮助，客户才算“赢”，而在客户能“赢”的基础上，我们软件公司才可能实现自己的“赢”。 不要抱怨客户变来变去，客户对需求的理解总是趋向上升的，而 项目 组也是一样。如果项目组对需求的认识落后于客户，就会陷于“被动”的局面，项目组应该努力提升水平，想办法让自己对需求的认识领先于客户。 需求分析工作是很复杂难度很高的工作，如果看不清楚客户的真正

摘要 ：怎么又变了？当初就应该让客户书面签字 确认 ！你可能会经常发这样的牢骚，可是就算客户书面确认，客户还是会“赖账”的！ 软件 项目的其中一项不变真理：人是会死的，需求是会变的！本章将会和你一起来体验软件 需求分析 工作的风风雨雨，找出需求分析工作的根本之道，了解 UML 如何帮助我们提升需求分析的水平。 （本书已经发售） 作者： 张传波 网名：Fireball（火球） www.umlonline.org 2.1 需求分析面面观 客户需要的是一把梯子，系统分析员了解到的是一张凳子，开发人员做出来的是一张桌子，测试人员以为是一张椅子……很多角色参与项目工作，每种角色会从自身角色出发来理解需求，以致各种角色对需求的理解会不太一样。下表对各种角色的特点进行了分析： 表 2.1 各种角色的特点 另外要说明的是： 客户一方的总倾向是：自己少花钱，让软件公司多做事情。 而软件公司一方的总倾向是：多拿客户的钱，尽量少做事情。 影响各人对需求理解的主要因素有两方面：一方面是角色的思考倾向，上表反应了这点；另外一方面是人的需求分析能力，能力越强的人越能把握需求，本书重点讲解的内容就是如何 活用UML 来提升需求分析能力。 而更“离谱”的是：每个人嘴巴上说的需求和心目中的需求总是有差异的，所谓的“词不达意”，受表达能力所限，不是每个人都能完整准确地表达自己的想法；有时候客户今天想要这个

摘要 ：怎么又变了？当初就应该让客户书面签字 确认 ！你可能会经常发这样的牢骚，可是就算客户书面确认，客户还是会“赖账”的！ 软件 项目的其中一项不变真理：人是会死的，需求是会变的！本章将会和你一起来体验软件 需求分析 工作的风风雨雨，找出需求分析工作的根本之道，了解 UML 如何帮助我们提升需求分析的水平。 作者： 张传波 www.umlonline.org www.umlonline.org/school/ 本文来自新书《活用UML——需求分析高手》的第二章。 第一章已经在博客园发布，文章名字叫：UML一篇文章就学通 文章链接： http://www.cnblogs.com/umlonline/archive/2011/07/12/2104626.html 以下是正文： 2.1 需求分析面面观 客户需要的是一把梯子，系统分析员了解到的是一张凳子，开发人员做出来的是一张桌子，测试人员以为是一张椅子……很多角色参与项目工作，每种角色会从自身角色出发来理解需求，以致各种角色对需求的理解会不太一样。下表对各种角色的特点进行了分析： 表 2.1 各种角色的特点 另外要说明的是： 客户一方的总倾向是：自己少花钱，让软件公司多做事情。 而软件公司一方的总倾向是：多拿客户的钱，尽量少做事情。 影响各人对需求理解的主要因素有两方面：一方面是角色的思考倾向，上表反应了这点