查看文章 |
可行性分析是要决定“做还是不做”。 需求分析是要决定“做什么，不做什么”。 即使可行性分析是客观的、科学的，但决策仍有可能是错误的。因为决策者是人，人会冲动，有赌博心态。如果可行性分析表明做某件事的成功率是10%，失败率是90%，倘若该事情的意义非常大，决策者也许会一拍脑袋：“豁出去，干！”于是这世界就多了一份极喜与极悲。4.1节讲述可行性分析的四大要素：经济、技术、社会环境和人。
·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。 ·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。 ·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。 ·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。 下一层次需求——用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。 软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。 业务需求、用户需求、功能需求，这三者之间，并不是完全并列的关系，而是在逻辑上有着从外到内、从整体到细节的深入和细化的关系。 软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。
值得注意的一点是，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。 需求分析与定义 1. 软件需求： 3. 需求分析 需求分析通常包括七个方面： 4. 需求分析方法 5. 面向对象需求分析（OOA） 那么我们在实际开发中到底怎么做呢？ 1）建立域模型 III. 合并需求获得的用例 3）要想做好需求分析光上面的用例是不够的还有写建模技术也要有如：协作图、顺序图和状态图 什么是优秀的需求 讨论软件需求的文章有很多，对于需求的标准也不尽相同，这里我想用NASA的软件开发过程中的概念，软件需求过程的标准是：清楚(Clear)、完整(Complete)、一致(Consistent)、可测试(Testable)，此外还有其他的概念，如可跟踪的、可修改的等等。 清楚：目前大多数的需求分析采用的仍然是自然语言（因为如果采用形式化语言的话，和用户的沟通将成为一个大问题，这意味着客户在开发软件之前必须先进行形式化语言培训，这是不现实的）。自然语言对需求分析最大的弊病就是它的二义性。所以我们不得不对需求分析中采用的语言做某些限制。例如尽量采用主语＋动作的简单表达方式。说白了，需求分析中的描述让人看上去像是刚学习写作的小孩子就对了，千万不要采用疑问句、修饰这些华丽的表达方式。 除了语言的二义性之外，主意不要使用行话，就是计算机术语。需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。 打个比方，如果你要做一个银行的信用卡系统，你就可以这样描述软件需求：银行的卡部管理信用卡，每张信用卡只属于一个帐户。信用卡有卡号、余额。一张信用卡有多笔的交易记录。 完整：再也没有什么比软件开发接近完成是发现遗漏了一项需求更糟的事情了。需求的完整性是非常非常重要的，想象一下遗漏需求而不得不返工，这简直就是恶梦。可是令人遗憾的是，需求的遗漏是很经常发生的事情，不仅仅是你的问题，更多的问题发生在用户那里，他们不知道该做些什么。要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各方各面，贯穿了整个过程，从最初的计划制定到最后的需求评审。至于完整性的详细讨论，我们会在下面的章节中讨论，现在你只需要拼命的想象缺乏完整性的坏处，直到你出了一身的冷汗。出了吗？好，那我们继续。 一致：一致性也是一个比较大的概念，很难用几句话讲清楚。还记得我们在开始的时候提到的需求的层次吗？简单的来说，就是用户需求必须和业务需求一致，功能需求必须和用户需求一致。严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。在实现过程中，我们还必须把一致性关系细化。比如说用户需求不能超出先前指定的范围。 可测试：大家觉得一个项目的测试从什么时候开始呢？有人说从编码完成后开始。更清楚一点的说是编码的时候同时进行单元测试，编码完成后进行系统测试。这些都没有错。但是实际上测试是从需求分析过程就开始了。需求分析是测试计划的输入和参照。这就要求需求分析是可测试的。什么是可测试呢？“我们要用新的系统完成报表自动化处理”，你觉得这个需求是可测试的吗？当然不是，报表包括哪些？自动化处理的标准是什么？这些在需求中都没有说明。因此这项需求是无法测试的，就是不具有可测试性。说到这里，大家可能就会明白之前的需求的几项标准都是为了保证需求的可测试性的。事实就是这样，只有系统的所有需求是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。大家真正在应用一些科学的方法的时候也应该记住，任何的方法都是为了保证软件的成功，不要偏离这个目标，千万不要走火入魔了，呵呵，很容易的。 需求分析是对用户需求的真正明确，是对要解决的问题的彻底理解。在解决问题之前要理解问题，只有真正的理解问题才能更好的解决问题。需求分析就是给系统分析、设计人员一个和用户交流来理解问题的机会—了解用户究竟需要什么。 在按照模版进行需求分析撰写的时候， 发现有很多模版条目的要求是在需求分析的最初阶段是无法给出确切的答案的。有的条目要经过概要设计，详细设计之后才能对文档内容进行修改和填充。同时 对其他同行撰写的需求分析文档进行研究发现，一个优秀的需求分析说明说并不是按照规定模版条目不变的照搬。其实有些冗余的项目完全可以不必关心。毕竟撰写需求分析的真正目的，是让系统设计人员知道用户的需求。其他的不必过多强求。 需求分析文档规范 1、 用好的结构化和自然语言编写文本型文档； 2、 建立图形化模型，这些模型可以描绘转换过程、系统状态、和它们之间的变化、数据关系、逻辑流或对象类和他们的关系； 3、 编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。 多种编写方法可在同一个文档使用，根据需要选择，或互为补充，以能够把需求说明白为目的。 B、应有成果 1、 各业务手工办理流程文字说明； 2、 各业务手工办理流程图； 3、 各业务手工办理各环节输入输出表单、数据来源； 4、 目标软件系统功能划分（示意图及文字说明）； 5、 目标软件系统中各业务办理流程文字说明； 6、 目标软件系统中各业务办理流程图（模型）； 7、 目标软件系统中各业务办理各环节数据、数据采集方式、数据间的内在联系分析。 8、 目标软件系统用户界面图、各式系统逻辑模型图及说明 C、文档工具推荐 1、 调研结果《需求分析说明书》格式参照开发文档模板； 2、 单位组织结构图、功能模块分解图用VISIO绘制，或直接用WORD中的画图工具； 3、 业务流程图用VISIO中的FLOWCHART模板绘制； 4、 系统逻辑模型使用ROSE绘制活用VISIO中的UML模板绘制； 5、 软件用户界面用VISIO中的WIN95 USER INTERFACE模板绘制； 6、 数据物理模型用POWERDESINER绘制； D、需求文档编写原则 1、 句子简短完整，具有正确的语法、拼写和标点； 2、 使用的术语与词汇表中所定义的一致； 3、 需求陈述应该有一致的样式，例如“系统必须..”或者“用户必须..”，并紧跟一个行为动作和可观察的结果。； 4、 避免使用模糊、主观的术语，减少不确定性，如“界面友好、操作方便”； 5、 避免使用比较性词语，如“提高”，应定量说明提高程度 需求分析 一、需求分析的任务 需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么？”这个问题。需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。 通常软件开发项目是要实现目标系统的物理模型，即确定待开发软件系统的系统元素，并将功能和数据结构分配到这些系统元素中。它是软件实现的基础。 需求分析的任务不是确定系统如何完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。在这个阶段结束时交出的文档中应该包括详细的数据流图（DFD），数据字典（DD）和一组简明的算法描述。 需求分析阶段的任务包括下述几方面。 1．确定对系统的综合需求 2．分析系统的数据需求 分析系统的数据需求是由系统的信息流归纳抽象出数据元素组成、数据的逻辑关系、数据字典格式和数据模型。并以输入/处理/输出（IPO）的结构方式表示。因此，必须分析系统的数据需求，这是软件需求分析的一个重要任务。 3．导出系统的逻辑模型 就是在理解当前系统“怎样做”的基础上，抽取其“做什么”的本质。 4．修正系统开发计划 5．开发原型系统 二、需求分析的步骤 结构化分析方法（简称SA方法）就是面向数据流自顶向下逐步求精进行需求分析的方法。需求分析的步骤如下。 1． 调查研究 2．分析与综合 应注意下述两条原则：第一，在分层细化时必须保持信息连续性，也就是说细化前后对应功能的输入／输出数据必须相同；第二，当进一步细化将涉及如何具体地实现一个功能时，也就是当把一个功能进一步分解成子功能后，并将考虑为了完成这些子功能而写出其程序代码时，就不应该再分解了。 3．书写文档 在这个阶段应该完成下述四种文档资料： （1）系统规格说明。 （2）数据要求。 （3）用户系统描述。 （4）修正的开发计划。 4．需求分析评审 三、需求分析的原则 1．必须能够表达和理解问题的数据域和功能域 2．按自顶向下、逐层分解问题 3．要给出系统的逻辑视图和物理视图 四、需求分析方法 大多数的需求分析方法是由数据驱动的，数据域具有三种属性：数据流、数据内容和数据结构。通常，一种需求分析方法总要利用一种或几种属性。 需求分析方法具有以下的共性。 1．支持数据域分析的机制 2．功能表示的方法 3．接口的定义 4．问题分解的机制以及对抽象的支持 5．逻辑视图和物理视图 6．系统抽象模型 五、面向数据流的需求分析方法 结构化分析方法是面向数据流进行需求分析的方法。 结构化分析方法使用数据流图DFD与数据字典DD来描述，面向数据流问题的需求分析适合于数据处理类型软件的需求描述。其核心思想是分解化简问题，将物理与逻辑表示分开，对系统进行数据与逻辑的抽象。 六、数据流图 数据流图是描述数据处理过程的工具。 1．数据流图的含义 数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的传输变换过程。数据流图是结构化系统分析的主要工具，它表示了系统内部信息的流向，并表示了系统的逻辑处理的功能。 2．数据流图的特性 （1）抽象性 （2）概括性 （3）层次性 3. 数据流图基本符号 （1）数据流图中的主要图形元素 数据流图的基本图形元素有4种， 数据流图基本图形符号 （2）数据流与加工之间的关系 其中星号“*”表示相邻的一对数据流同时出现，? 则表示相邻的两数据流只取其一。 （3）分层的数据流图 数据流图加工关系 4.数据流图的用途 数据流图的作用主要有以下几条： (1) 系统分析员用这种工具可以自顶向下分析系统信息流程。 (2) 可在图上画出需要计算机处理的部分。 (3) 根据数据存贮，进一步作数据分析，向数据库设计过渡。 (4) 根据数据流向，定出存取方式。 (5) 对应一个处理过程，用相应的语言、判定表等工具表达处理方法。 5．数据流图的优缺点 (1) 总体概念强，每一层都明确强调“干什么”，“需要什么”，“给出什么”。 (2) 可以反映出数据的流向和处理过程。 (3) 由于自顶向下分析，容易及早发现系统各部分的逻辑错误，也容易修正。 (4) 容易与计算机处理相对照。 (5) 不直观，一般都要在作业流程分析的基础上加以概括、抽象、修正来得到。 (6) 如果没有计算机系统帮助的话，人工绘制太麻烦，工作量较大。 6．数据流图画法 (1) 画数据流图的一般原则 画数据流图的基本步骤概括地说，就是自外向内，自顶向下，逐层细化，完善求精。具体步骤如下。 (2) 数据流图的分层方法 (3) 分层法绘制流程图的几个问题 7．数据流图的绘制与其它流程图的差别 (1) 数据流图与系统流程图的区别 (2) 数据流与程序流程 Software 需求分析文档格式 软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解， 使之成为整个开发工作的基础。编制软件需求说明书的内容要求如下： 一、需求开发 需求开发又分为需求获取、需求分析、编写规格说明书和需求验证。以下列出和讲解分析常规的步骤，当然应按照项目的大小和特点等实际情况我们应该自己确定合适的步骤 1． 需求获取 确定需求开发过程确定如何组织需求的收集、分析、细化并核实的步骤，并将它编写成文档。 2． 需求分析 绘制关联图、创建开发原型、分析可行性、确定需求优先级、为需求建立模型、编写数据字典、应用质量功能调配。 3． 编写规格说明书 项目视图和范围文档包含了业务需求，而使用实例文档则包含了用户需求 4． 需求验证 审查需求文档、依据需求编写测试用例、编写用户手册、确定合格的标准 二、需求管理 需求开发的结果应该有项目视图和范围文档、使用实例文档、软件需求规格说明及相关分析模型。经评审批准，这些文档就定义了开发工作的需求基线。 一、综述 软件工程中包含需求、设计、编码和测试四个阶段,其中需求工程是软件工程第一个也是很重要的一个阶段，本文以医院管理系统为例详细介绍了需求工程的构成和进行方法。 《网站功能描述书》必须包含以下内容：
2、 网站用户界面（初步） 3、 网站运行的软硬件环境 4、 网站系统性能定义 5、 网站系统的软件和硬件接口 6、 确定网站维护的要求 7、 确定网站系统空间租赁要求 8、 网站页面总体风格及美工效果。 9、 主页面及次页面大概数量。 10、管理及内容录入任务分配。 11、各种页面特殊效果及其数量。 12、项目完成时间及进度（根据合同） 13、明确项目完成后的维护责任。 1.什么是需求 需求简单的说就是“做什么”而不是“怎么做”。但这种简单的描述并不足以限定需求的界限。 比如： 用户需要的功能是做什么---------怎么实现功能则是怎么做 一个函数的功能是做什么---------怎么实现函数则是怎么做 写一个for循环是做什么 -----------怎么敲键盘是怎么做 左边的这三项，显然在做软件时，是处于不同阶段的。因此说“需求”二个字是有上下文的。通常，我们说的需求是指用户的需求即“用户想要系统做什么”。 当然“需求”这两个字也会在其它的语境中出现，比如：你要你的下属为你做一个界面，你的下属会问你：“把界面需求给我”。这里的“需求”，就是特指“要做一个什么样的界面”。 按照上述关点，在软件中是处处有需求的，但是我们关注的是用户的需求。它是软件产生的根源，是贯穿软件的主线。 由用户需求，可以导出软件的需求，它描述了软件从用户的角度的确切样子。软件的需求有一个易忽略的意思，就是软件的性能、可靠性等、统称为非功能需求。 2. 需求怎样获得取 需求来源于用户，但是由于用户并不懂得如何用记算机解决问题，也有可能，用户本身并不很明确所面对的问题，因此需要和分析员共同明确用户的原始需求。这一步可以称为“需求调研”。 进行需求调研需懂得一点建模的方法。我比较喜欢用例图。在和用户交流时一定要用简单易懂的工具。 3 .需求分析 当获得了原始需求后，需要进行的工作就是“需求分析”。需求分析的方法很多，不同的方法使用不同的步骤，测重点也不同，实质上都是为了驱动设计和软件的开发。我所使用的方法自成一格（不是我发明的），简单实用，没有用看不懂的话来指导分析和设计。 方法的核心思想是：做软件是为了用户，用户需求是软件的根本，软件的一切都是由用户需求推导面来，是贯穿于分析和设计的主线，需求分析和设计的划分要适用于交流和团队开发，不拘泥于某种建模方法，但提出主要的三种模型和建模顺序来完成需求和设计的推演。 需求分析的结果是需求分析文档，文档的目的是要澄清用户的原始需求，明确用户需求模糊的部分，理解问题域，设计解决方案。这时通常要用到用例图进行分析。通过用例可以捕获软件的功能需求。分析时还要确定对软件的约束。当切底理解了问题域以后，就要设计解决方案。解决方案是指明软件的功能需求、非功能需求、界面。 为了理解问题域，通常需要明确问题域中的概念，对现实世界进行分类，挖掘新的概念。 需求分析最后的效果是，当拿到这样的一份文档以后，就可以了解到软件开发出来以后的全貌以及实现上存在的约束条件。同时可以包括对设计的一些建义，比如使用什么开源组件，设计的核心思想等。 这里的需求分析，建议的就只有一个用例图，用来捕获用户需求。其它的建模原素只要是有利于理解问题域的就可以使用。 这和一些经典的OOA 方法不同，它们强调类图是需求分析的核心产物。但我觉得，无明确目的找类，是不能证明所找到的类是有用的。就是说，找类的动作是没有用户需求驱动的，这时找到的类是不能证明对用户需求是有用的。因此说，这里描述的方法的核心是用户的需求，而不是领域模型。有些OOA方法，把界需设计的动作方到了OOD的过程中。我觉得，这不太合适，因为界面是用户最真接体验的软件部分，应该先确定下来，并与用户讨论。有利于用户对软件系统的理解，并可以提出意见。 需求分析，需要经过认真的评审，需要用户的参与。 由于认为用户是最重要的，因此怎样实现软件或者说怎样设计软件，则处于次要的地位。 但不要误会我的意思，我的意思不是设计不重要，只是说从用户的体验来讲，设计的好坏不起决定作用。
4. 设计 设计的最终目的是找到一组类，并明确类的职责，通过类的协作完成软件需求分析时所确定的需求。最后应形成设计文档，程序员根据设计文档可以进行软件的编写。 一、画顺序图 通过需求分析阶段确定的用例可以确定系统的主要的外部事件。设计的第一步是用顺序图描述最主要的外部事件所激发的类协作。这里有个问题，类从何处而来？类为需要面来，就是说为了实现某一个外部事件，需要某个类的出现，则在顺序图中将它画出来。这里隐含了一个意思，现实世界中的对象是画顺序图时提取对象的一个源泉。另外一些模式也为应用什么类来实现外部事件提供了指南，比如：通常使用的控制器模式。 这里注意： 外部事件是由用户需求而来，顺序图是由外部事件而来，所以找到的类必然是为用户需求所服务的。 第一个顺序图应该确定软件的主要公共类。主要公共类是软件中的必然成份，负责一个独立的功能。 接下来继续画顺序图描述其它的外部事件在主要公共类间的协作关系。当所有的外部事件的顺序图都画完了以后，则所需的主要的类和类的公共方法都可以确定下来了。 有些公共类内部的协作过程如果还不明确则应针对这个类的公共方法再画出顺序图，以发现更细致的协作过程和和更小的类。 画顺序图的过程是找到了类，并为类分配职责的过程。最初通过外部事件，找到主要的公共类，并为它们分配职责，然后为了实现公共类的职责，继续发现一些细小的类，最终细化到可实现的级别。 注意：设计的指导思想是，越简单越好。 二、画类图 通过上一步，找到了系统内需要的类对象。现在可以用类图将这些类画出来，根据顺序图、类的职责、现实世界可以确定类之间的关系。通过顺序图可以确定类的公有方法，根据公有方法和类的职责，可以确定类所需要的属性。 三、用文字详细说明每一个类的职责、功能、属性、方法，以备程序员根据设计文档实现软件。 上面叙述了软件设计的一般过程，但光知到这些，并不足以做出优秀的设计。还需要理解面向对象方法的本质原理，学习设计模式，架构模式，重构等内容，还需要实践，实践应该是最重要的。如果是初学，我想先学设计模式好点。 我觉得设计没有对错之分，只有好坏之别。好的设计的特点是：第一、设计要简单易懂，易于修改、扩充，它是第一位的，第二是有适当的灵活性。坏的设计的特点是：设计复杂、不易理解、不易修改和扩充。 现在介绍一下面象对象方法的本质原理。首先说对象，对象是面向对象方法的核心原素。对象可以表示现实世界中的一切。对象本质上就是：数据+方法，这种组合在软件中到底有什么好处呢？软件所解决的问题，实质上都是客观事界中的问题。一个问题，必然由一些事物、概念和这些事物及概念的运动所组成。如果要在计算机中解决先实世界中的问题，必然需要在软件中表示出现实世界中的事物和概念，才能进行运算。比如：一个下定单的系统中不可能不包括对定单的表示和操作。可以说，软件世界，是现实世界的一个映射，类恰好是完成这个映射的恰当工具。因此可以说，相同需求下，不同人做的不同设计本质上是等效的。 用面向对象方法写的软件，比较好理解。因为它比较接近现实世界。 用面向对象方法编写的软件是比较稳定的。因它软件中包含了现实世界的映射，而先实事界，通常是稳定的，变化通常是在局部的。因此对应的软件也只需要局部的调整。 软件世界中的对象是现实世界的映射但又不完全相同。原因是为了实现需求，必须为现实世界中的事物或概念添加行为。比如：一个定单对象，它很可能包含一个amountTo操作来合计定单总额，现实世界中的定单是没有这个能力的。那为什么，不把amountTo方法分配给其它的类，进行总额的计算呢，这样是不是就符合现实世界了呢？这个问题，不能单纯从符合现实世界来考虑。前面说过，软件设计简单易懂，是根本。这样作明显会引入一个新类，当用到定单的地方，就有可能需要进行amoutTo计算，则在这个地方又必须使用那个引入的类，结果是明显增加了软件的复杂度。为定单对象增加amoutTo操作，对于它对先实世界的模拟是无害的，却可以简化软件设计，为什么不这样做呢？因此，如果以后要增加对定单的操作也应该加到定单对象中（对应这个意思有一个模式叫做“信息专家”可以参考《uml与模式应用》一书) 面向对象中的继承基本上是为了实现复用，但多态是借着继承来实现的，我觉得多态才是继承的真正好处。它使得一些精巧的设计模式成为可能，可以增加软件的灵活动性。 开发过程通常分为两大阶段： 1， 正确地确定问题：软件做什么？ 2， 为问题寻找合适的解答：软件怎么做？ 需求分析和规格说明阶段的目的：澄清用户的各种需求 用户需求：软件系统必须满足的所有性质和限制：功能要求（数据要求和加工要求），性能要求，可靠性要求，安全保密要求，以及开发费用，开发周期，可使用的资源等方面的限制；
作为验收的依据，作为选取测试用例和进行验证的依据； 需求说明书应该完整，一致，精确，无二义； 经济 一、成本——收益分析 如果是为客户做软件项目，那么收益就写在合同中。如果是做自己的软件产品，那么收益就是销售额。 人们在预估产品销售额时常常过分乐观而犯下大错。那些对你的产品说恭维话的人并不见得就是要买货的人，俗话说“嫌货才是买货人”。当你没碰到一个挑刺的人而感觉这产品好得会让你发大财时，就要做好会破产的心理准备。
层次1. 客观描述与记录（objective description and record）——忠实、精确、全面地搜集与记录客户的需求或相关的业务、数据；
1. 需求分析及变更管理 2. 项目模型及业务流程分析 3. 系统分析及软件建模 4. 界面设计、交互设计及程序开发 5. 系统测试和文档编写 6. 客户培训、技术支持和售后服务 需要说明的是，这些阶段虽然具有一定的延续性，但是并非完全隔断的，例如需求变更管理和测试工作、文档编写都是贯穿整个项目过程的，许多工作时交叉进行或同时进行的。 项目经理、系统分析员、开发经理、交互设计师、测试人员、文档人员包括客户代表都应该看需求分析，并进行共同的讨论，达成一致的意见。 我们经常会遇到业务人员辛辛苦苦谈下来的项目，对开发人员来说却是难以实现的，而技术人员设计的产品却常常得不到客户的认可，甚至发生纠纷，因此参与项目开发的人员都应该对这份需求有统一清晰的认识，并根据自己的工作对需求提出意见，通过与客户的沟通修订，最终确定项目实现的目标。 例如： 项目经理通过需求分析才能组建所需要的团队包括配置工作环境，制定开发周期。 开发周期的限制和功能上的要求可能会影响到程序员采用什么样的语言和工具进行编写； 操作用户的技能水平将影响到交互设计师进行前台设计时做到什么样的精度； 界面设计人员根据项目的性质和定位确定表现方式。 测试人员了解测试环境和条件后才能对项目质量进行跟踪和检测； 将需求进行分析，确认可操作的系统模型； 利用最自然的语言将系统进行描述，使每个开发人员不会产生歧意； 迅速确定网站的用户角色； 比如访客、会员、重要客户、前台管理员、网站管理员、业务员等； 分析确定每个角色的权限及可操作的功能； 比如会员可以查看特别信息、修改个人信息、退出登陆等； 前台管理员能够登录管理系统，能够发布编辑修改信息，能够审查会员资格等； 网站管理员可以更改栏目、修改网站界面等； 制作流程图和示意图将需求表现出来； 让客户参与到示意图的设计中，及时正确的反应出需求变更。 制作需求变更日志，保留升级版本，通过版本控制进行需求管理； 通过需求《管理计划书》使每个参与人员看到共同的努力目标。 |
