CMS项目内容管理系统

手把手教程
Project
需求分析的任务
需求分析的任务就是解决“用户要做什么”的问题,就是 要全面地理解用户的各项要求,并准确地表达所接受的用户需 求 ，并且能够根据自己对用户需求的理解，劝说并诱导客户 剔除不合理的需求。
手把手教程 需求分析过程
Project
手把手教程
Project
需求开发过程域
法”和“建模分析法”。后者技术性比较强，写出来有学术味，故大多数软件工 程书籍都有论述。前者就是一些常识而已，虽然写不成文章，但是简单易用（保 你一学就会），很有实用价值。 “问答分析法”比较适合于用户需求调查阶段 “建模分析法”比较适合于产品需求定义阶段。
手把手教程
Project
问答分析方法
恰当地使用图形符号：
现代建模工具如Rose、Jude有非常丰富的图形符号和文字标注，能很好地表达模 型的细节。要注意的是：在建模时使用花样过多的图形符号或文字意味着模型表 示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱。
世上不存在一个包罗万象的图——它能完整地描述需求。需求建模不可能取代文 字描述。在需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用。 建议将模型存放在需求文档的附录中，便于正文引用。
档不能准确地反映用户真实的意愿，可以拒绝在需求文档上签字。 4. 如果用户想要变更需求，有权要求开发方对该变更将产生的影响作
出真实可信的评估，以便用户决定是否变更需求。
手把手教程
Project
用户在需求工程中的“义务”
用户在需求工程中的“义务”
1. 以积极友善的态度与开发方人员交流、协作，尽可能地为开发方人 员提供工作和生活上的便利。
“画蛇添足”要么是“锦上添花”。
“画蛇添足”显然是坏事，会导致开发人员多干一些吃力不讨好的工 作。所以要尽量剔除需求规格说明书中“画蛇添足”的那些需求。
手把手教程
Project
建模分析法
人们都有这样地感受：有些时候用语言描述某个问题特别费劲，而采用图形 则使人一目了然.
在需求开发过程中，对于某些类型的信息，用图形表示要比文本表示更加有 效。所以将图形与文本结合起来描述需求是很自然的方法。
需求建模就是指用图形符号来表示、刻画需求。
建模分析方法主要有两大类：“结构化分析法”和“面向对象分析法”。
手把手教程
Project
分析决策
当需求从四面八方收集来后，需求的冲突在所难免。对于那些难以达 成共识的需求而言，经常会发生“公说公有理，婆说婆有理”的现象。 那么需求分析员究竟应该听谁的呢？
如果一群人对需求有争议，并不是谁声音最响就听谁的。根据生活经验， 最保险的办法是：先听官儿大的或者威望高的，如果大家的职位和威望 都差不多，那么采用“少数服从大多数”的原则。
手把手教程
Project
什么是好的需求规格说明书
正确
需求规格说明书应当正确地反映用户的真实意图，“正确”是《产品需求规格说明书》 最重要的属性。如果“不正确”仅仅是由于错别字造成的，那么多检查几遍文档就能 解决问题。真正的困难是开发者和用户自己都不明白用户究竟“想要什么”和“不要 什么”。为确保需求是正确的，开发方和用户必须对《需求规格说明书》进行确认。
如果一个产品可以卖给几类客户，但是各类客户都要求产品按照他们的 喜好来开发。此时对需求的决策应当以商业利益为导向， 即哪一类客 户出钱最多就先满足他们的需求，以后再做那些获利相对较少的需求。
当开发者想象中的产品与客户所提的需求有冲突时，一般应当尊重客户 的观点。但是不要陷入“客户总是对的”陷阱里，需求分析员应当纠正 明显不合理的客户需求。如果产品很复杂，双方都不太明白需求，此时 最好请开发人员快速构造软件的原型，双方看着软件原型再分析需求
手把手教程
需求没有做好的后果

Project
手把手教程
Project
如何准备调查需求
需求分析员应当确定需求调查的方式，例如：
与用户负责人交谈，向用户提问题。 同未来此软件的目标用户交谈，了解他们的目前的工作状况. 参观用户的工作流程，观察用户的操作。 与同行、专家交谈，听取他们的意见。 分析已经存在的同类软件产品，提取需求。 从行业标准、规则中提取需求。
手把手教程
Project
合作关系
如果需求分析员不能与用户建立良好的合作关系，那么他们在需求开发过程 中会很疲惫。
倘若用户不能很好地配合需求分析员，那并不表示他是个坏蛋。因为用户有 他自己的想法：
我回答了你们的问题，讲了该讲的。我们付钱给你们，难道还要我伺候你们不成？ 我还要干自己的事情，别打扰我了。你们自己想办法把活干好吧 ……。
开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中 的权利与义务”，即以协议的方式确定合作关系。“好话”和“丑话”都说 在前头，这样能减少今后的摩擦。如果条件允许的话，开发方最好为用户举 办关于需求工程的培训，这样的培训将使用户明白需求的重要性以及忽视需 求的危害性，从而促使他们积极友善地参加需求工程中的各项活动。
用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不是 绝症，是人们可以设法解决的。可悲的是开发人员把这些问题当成了 借口，不愿主动攻克问题，导致需求问题扩散到整个软件开发过程， 产生太多的后患。
软件企业的领导应当给具有错误观念的开发人员们洗脑：需求分析员 的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到 就是失职，不要找借口。
手把手教程
Project
需求管理过程域
需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护 需求与其它工作成果的一致性，并控制需求的变更。
需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达 成共识后作出书面承诺，使需求文档具有商业合同效果。
需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建 立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。
如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，以便加 深读者的理解。
追究“是什么”和“为什么”的目的是获得正确、清楚的需求。
其它常见的问题有：
需求存在二义性吗？ 需求文档的上下文有矛盾吗？ 需求完备吗？ 需求是必要的吗？ 需求可实现吗？ 需求可验证吗？ 需求的优先级确定了吗？
手把手教程
Project
用户在需求工程中的“权利”
用户在需求工程中的“权利”
1. 有权要求开发方派遣资质合格的需求分析员和相关人员。 2. 有权要求开发方采用用户熟悉的语言来描述需求，即开发方必须提
供用户看得懂得需求文档。 3. 有权审查需求文档，并对有争议的需求作出决策。如果认为需求文
手把手教程
Project
CMS项目
内容管理系统 Content Management System
手把手教程
学习内容
WEB项目开发一般流程 CMS项目流程wk.baidu.com解
Project
手把手教程
WEB项目开发的一般流程—总纲
1. 需求分析的确定 2. 架构与设计
① 架构分析与设计 ② 业务逻辑分析 ③ 业务逻辑设计 ④ 界面设计 3. 开发环境搭建 4. 开发-测试-开发-测试 5. 培训文档编写
为了使需求无二义性，人们在写《产品需求规格说明书》时措词应当准确，切勿模棱 两可。
手把手教程
Project
什么是好的需求规格说明书
一致
“一致”（Consistent）是指《产品需求规格说明书》中各个需求之 间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。
必要
《产品需求规格说明书》中的各项需求对用户而言应当都是必要的。 可以把“必要”比喻为“雪中送炭”。“必要”往前一步，要么是
Project
手把手教程
Project
开发的一般流程—需求分析
为什么需求分析 需求分析是指理解用户需求，就软件功能与客户达成一致，
估计软件风险和评估项目代价，最终形成开发计划的一个复 杂过程，在这个过程中，用户的确是处在主导地位，需求分 析工程师和项目经理要负责整理用户需求，为之后的软件设 计打下基础。需求分析阶段结束后，要求得到相关的需求文 档， 需求分析之所以重要,就因为他具有决策性,方向性,策略 性的作用,他在软件开发的过程中具有举足轻重的地位.大家一 定要对需求分析具有足够的重视.在一个大型软件系统的开发 中,他的作用要远远大于程序设计.
问答分析方法 问答分析方法很简单：刨根究底地问，如果问题都被解答了，那么需求也就 分析清楚了。一个人可以“自问自答”地分析需求，几个人分析需求则称为 “研讨”。 问答分析最重要的问题是：“是什么”,”做什么”和“为什么”。
每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明 “不是什么”。
清楚
清楚的需求让人易读易懂。清楚的反义词是“难读”、“难理解”。你可以采用反问 的方式来判断需求文档是否清楚：
文档的结构、段落是否乱七八糟？上下文是否不连贯？ 文档的语句是否含糊其词、罗里罗嗦？ 看了半天是否还不明白需求究竟是什么？
无二义性
“无二义性” 是指每个需求只有唯一的含义。如果一个人说的话，不同的人可能有不 同的理解，那么这句话就有二义性。如果需求存在二义性，将会导致人们误解需求而 开发出偏离需求的产品。
需求分析员不是销售人员，他们不可能象销售人员那样通过某些手段笼络住 用户就能成功。出色的需求分析员不仅要有过硬的专业知识，还要具备较强 的交流、沟通能力。
开发方与用户的合作关系对需求开发而言是至关重要的。对于重大的、复杂 的项目，我们不能完全期望双方能够自发地建立起良好地合作关系，这样风 险太大。
2. 乐意接受需求分析员的采访，在不泄漏机密的前提下尽可能地回答 需求分析员的问题。
3. 在不泄漏机密的前提下，尽可能地向需求分析员提供与需求相关的 材料。
4. 与需求分析员共同评审需求文档，确保需求文档准确地反映用户真 实的意愿。
5. 对专业性太深入的知识领域，用户有义务组织开发人员进行简单的 培训。
否则他很难与用户交流。如果可能的话，开发方最好请既懂软件又懂应 用域知识的行家来帮忙。
手把手教程
Project
需求开发过程中困难
态度问题
相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折 时，他们会发牢骚，找出一堆用户的毛病。很多开发人员错误地以为：
需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户 不该告诉我们应当开发什么吗？如果用户说不清楚需求，或者经常变更 需求，这类问题是用户产生的，应当由他们自己负责。
手把手教程
Project
如何做好需求分析
为了得到用户的金钱，企业不得不鼓吹：用户就是上帝，用户永远是正确的。 谁都知道这不是真的。事实上，很多时候用户说不清楚需求、会说错需求或者提
出一些无法实现的需求。 需求分析是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误
和弥补不足，确保需求文档正确地反映用户的真实意图。 需求分析是需求开发过程中最费脑子的工作。分析方法大体有两类：“问答分析
需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。
需求调查的目的是通过各种途径获取用户的需求信息（原始材料）， 产生《用户需求说明书》。
需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。 常见的需求分析方法有“问答分析法”和“建模分析法”两类。
需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确 无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依 据《产品需求规格说明书》开展系统设计工作。
需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程 处理需求的变更，防止需求变更失去控制而导致项目发生混乱
手把手教程
Project
需求开发过程中困难
知识技能问题
行业知识是无边无际的。俗话说“隔行如隔山”，需求分析员可能是 某一领域的专家，但当他接手陌生的业务时，他该怎么办？
首先他要有勇气做事，否则连实践的机会都没有。 其次他应当赶紧补习这一领域知识，不论是通过自学还是培训的方式，