如何做软件项目的需求分析

求分析 (KPAs)的框架(KPA的概念在讨论CMM的书中有详细的概念说明)。关键过程区域构了自动和半自动的支持。这些辅助工具就称为CASE。需求分析都包括了哪些方法呢？这里列举出在《需求分析》一书中推荐的一些方法，1)绘制系统关联图，这种关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。2)创建用户接口原型，当开发人员或用户不能确定需求时，开发一个用户接口原型—冲突之处。3)分析需求可行性，在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。4)确定需求的优先级别，应用分析方法来确定使用实例、产品特性或单项需求实现的优先定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。5)为需求建立模型，需求的图形分析模型是软件需求规格说明极好的补充说明。它们模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。6)创建数据字典，数据字典是对系统用到的所有数据项和结构的定义，以确保开发人组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。7)使用质量功能调配，(QFD)是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。QFD将1996)。如，采用SRS模板、指明需求的来源、为每项需求注上标号、记录业务规范、创建需求跟模过业务建模，比如你了解企业的运作模式就?是一种你脑海中的业务建模。但是大多数人都没有科学的、系统的、文档化的做过业务建模。业务建模的目的在于：了解目标组织(将要在其中部署系统的组织)的结构及机制。了解目标组织中当前存在的问题并确定改进的可能性。确保客户、最终用户和开发人员就目标组织达成共识。导出支持目标组织所需的业务需求。上面的话是不是很抽象呢，其实没有什么复杂的：人和电脑是完全不同的思想(思维方式)。所以，原先适合人的业务流程对于计算机来说可不一定合适的，为了最大限度的利用计算机，必须要了解原先的业务流程并对此加易改造(流程自动化)，当然这些动作需要得到用户的许可。有些人认为说只有ERP这种大系统才需要对业务流程进行重组，但是实际所不同的只是改造的程度。业务建模很重要的一点是在分析企业流程的同时分析出基础企业对象(CommonBusinessObject)(这个词我翻译的不好，如果大家有更好的翻译，请告诉我)。任何企业都有最基础的一些元素，例如银行的CBO就有帐户，制造业的CBO就有订单等。有一次我研究多年的朋友告诉我一个秘诀，他说，企业的CBO无非是4个：客户、员工、产品和供应商(银行的供应商应该称为同业)。其他的所有CBO都是在这四个CBO的基础上发展起来的。比如说CBO中客户和产品是多对多的关系，根据关系数据CBO的组合，不同的关系，能够形成企业运作的许许多多的CBO。CBO是做业务建模的基础，在此基础上，通过评估业务状态，说明当前业务，确定业发领域模型等一系列在RUP中定义的工作流程实现业务建模的目标。ation集中在用户任务上—而不是集中在用户接口上—有助于防止开发组由于草率处理设计问题提供的信息(需求获取)。同时，你将处理这些信息以理解它们，并把它们分成不同的类别，还要把客户需求同可能的软件需求相联系(分析)。然后，你可以使客户信息结构化，并编写成文档和示意图(说明)。下一步，就可以让客户代表评审文档并纠正存在的错误(验集中处理并设定优先级?，以避免一个不能带来任何益处的无限大的项目。 (open-ended)的问题有助于你更好地理解用户目前的业务过程并且知道新系统如何帮助或改进他们的工作。调查用户任务可能遇到的变更，或者用户需要使用系统其它可能的方式。求的开发和利用。是如何想的？询问问题时，以“还有什么能”,”当?时，将会发生什么”“你有没有曾经想过”,“有没有人曾经”为开头。记下每一个需求的来源，这样向下跟踪直到发现特定的客户。客户的开始谈论业务，而你，就在一边仔细的聆听吧。这一招就叫做“抛砖引玉”。item谈讨论是需求集和分析以消除任何冲突或不一致性。确客户没有表达清楚但又想加入的特性或特征。Gause和Weinberg(1989)提出使用“上下客户对这些问题的回答诸如“产品要求怎样的精确度”或“你能帮我解释一下你为什么不同意某人的回答吗？”这些回答可以更直接地认识问题，而这是封闭(close-end)问题所不能做到的。多的交流方式(KielandCarmel1995)。与单个客户或潜在的用户组一起座谈，对于业务软件包或信息管理系统(MIS)的应用来说是一种传统的需求来源。直接聘请用户进行获取需求的过程是为项目获得支持和买入(buy-in)的一种方式。并提取出潜在的逻辑关系。流程图和决策树是描述这些逻辑决策途径的好方法。在需求获取的过程中，你可能会发现对项目范围的定义存在误差，不是太大就是太小。需求主要是关于系统做什么，而解决方案如何实现是属于设计的范围。这样说虽然很简洁，不能代表绝大多数用户的需要。最?好的权衡在于选择一些授权为他们的用户类发言的产品提示将会暗示你在需求获取的过程中的返回点。1.如果用户不能想出更多的使用实例，也许你就完成了收集需求的工作。用户总是按其重要性的顺序来确定使用实例的。2.如果用户提出新的使用实例，但你可以从其它使用实例的相关功能需求中获得这些复原先讨论过的问题，此时，也许你就完成了收集需求的工作。4.如果所提出的新需求比你已确定的需求的优先级都低时，也许你就完成了收集需求的工作。5.如果用户提出对将来产品的要求，而不是现在我们讨论的特定产品，也许你就完成了收集需求的工作。成功的。化原型法进行软件项目需求分析前言：需求分析阶段是管理信息系统(MIS)开发最重要的阶段。MIS开发的需求阶段首先Jackson向别MIS力MIS开发的公司。但作者在长期的MIS需求分析过程中，发现原型法有以下缺陷：1)原型的设计和修改工作量大，增加了系统的开发成本；2)由于用户不关心或不理解原型的概念和实现，而且存在较大期望，使得与实际系统不能反映实际系统的全貌；3)软件需求主要包括：功能需求、界面需求、性能需求、环境需求、可靠性需求、安型难以表达软件的后七项需求；4)原型法强调用户和开发人员不断对原型进行不断修改和补充，直到用户感到满意为MIS项目中，这种情况实际难以保证，特别是在用户单位和开发单位距离较远时。管理信息系统项目实施的实践，提出一种新的需求分析方法-简化原型法。这统原型。管理信息系统属于数据库应用。数据库应用需求分析应该围绕数据，而不是功能展开，即5培训安排协议培训安排和技术服务承诺。系统的边界规定系统覆盖的作业范围，主要有地理边界(规定系统运行的部门、分支单位等)、操作员范围(规定操作系统的所有操作员身份、分布和大致权限)和业务范围(规定系统处理的业务，对于不处理的边沿业务特别明确指出)。细，可以对应实际系统中的一个模块。如：电力MIS中输电设施管理子系统中的线路设备管理，不详细描述线路设备管理中的所有功能。由开发方完成，还是由开发方协助第三方完成。工程的进度控制规定工程的开始、结束日期和具体工程项目的名称、完成时间、地点、备具体项目完成提供的文件名称和要求，如：网络布线验收报告和硬件设备验收报告等。需求调查分析训包括操作员和系统维护人员的培训。培训安排包括每种培训的人员数量、培训内容、平。阶段解决"做什么"的问题。主要工作有需求调查准备、到用户单位进行需求调查分析和进行需求评审。需求调查准备据和详细流程(处理岗位、处理方式和审核细节等)。需求分析文档原型是根据技术协议编计。owerBuilderPBDelphi型的主要设计要求有：1)充分考虑系统的设计与实现，不得与实际系统脱节；2)尽量仿真实际系统的操作界面，与实际系统的操作过程完全相同；3)可以单机安装运行，不与实际数据库连接；4)演示数据的存储可以通过文本文件、单机的数据库或PB外部数据源的数据窗口；5)对于界面中容易误解或难以理解的操作，在功能帮助按钮中给出说明；6)界面中难以实现或工作量很大的功能，以标注方式详细说明；7)运行稳定，并比实际系统对硬件要求低。书上签字。最终系统简化原型和源代码留在用户现场，便于系统的操作员进一步理解分析，于开发人员及时修改系统的设计和编码。进行需求评审方负责人签字，以需求分析说明书附件的形式存在，同样指导下一步的系统设计工作。1)、此方法适合各种MIS工程的需求分析，特别适合致力于某一领域MIS开发的软件公司。采用此方法，开发同类项目越多，需求分析工作的效率越高。2)、在需求分析过程中，由于需要设计系统简化原型和文档原型，并充分考虑到系统中，一般由资深的软件分析和设计人员进行。3)、此方法不仅适合MIS软件工程，同样适合其它大型软件工程。4)、由于需求分析工作本身的难度和重要性，此方法同样要求用户单位和需求分析人时进行；所有工作步骤不得应负或疏忽。MIS大提高了需求分析的工作效率。实践证明，简化原型