档案管理系统软件需求分析软件需求的定义使用缺乏统一定义的术语来描述软件开发工作是软件业一直存在的问题，痛一句话在不同的人看来含义不同。同一个需求可能会被各种各样的人理解为用户需求、软件需求、功能需求、系统需求、技术需求、商业需求或产品需求等。用户对需求的定义，在开发者看来可能是一个较高层次的产品概念；而开发人员对需求的定义，在客户看来可能是详细的接口设计。定义上的分歧导致了客户和开发者交流上存在诸多问题。IEEE软件工程标准词汇表中将需求定义为：用户解决问题或达到某种目的所需要的条件或权能。系统或系统组件要满足合同、标准、规范或其他正式规定的文档所需要的条件或权能。反映以上（1）或（2）中描述的条件或权能的文档说明。软件需求的层次软件爱你需求包括3个层次：业务需求、用户需求和功能需求。业务需求反映了组织机构或客户对系统高层次的目标要求。业务需求描述了为什么要实现这个系统，即该组织希望通过该系统的实现达到什么目标。业务需求可以记录在项目视图与范围文档里，有时也被称为项目合约或市场需求文档。用户需求描述了用户使用产品所能完成的任务。可以使用用例、事件——响应表，以及方案脚本来说明用户需求。因此用户需求定义了用户可以使用系统做什么。功能需求说明了软件的功能，用户使用这些功能以完成任务。系统要求描述包含多个子系统的产品的最高层的要求。软件需求个部分之间的逻辑关系如图10-1所示。约束条件系统需求软件需求说明书业务需求项目视图与范围文档用户需求用例文档质量属性非功能需求功能需求图10-1需求层次图功能需求将在软件需求说明中进行描述，软件需求说明书（RRS，SoftwareRequitrmentsSpecification）将会尽可能详细地描述整个系统的行为。除了功能需求以外，SRS还包括了非功能需求，例如性能要求和质量要求等。需求分析的任务与过程当前系统物理模型逻辑模型目标系统物理模型逻辑模型需求分析的任务是借助于当前系统的物理模型（待开发系统的系统元素）导出目标系统的逻辑模型（只描述系统要完成的功能和要处理的数据），解决目标系统“做什么”的问题。所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节。定义软件的其他有效性需求。通过逐步细化对软件的需求，描述软件要处理的数据，并给软件开发提供一种可以转化为数据设计、结构设计和过程设计的数据与功能表示。必须全面理解用户的各项要求，但不能全盘接受，只能接受合理的要求；对其中模糊地要求要进一步澄清，然后决定是否采纳；对于无法实现的要求要向用户进行充分的解释。最后将软件的需求准确地表达出来，形成软件需求说明书SRS。其实现步骤如图10-2所示。图10-2由当前系统建立目标系统模型获得当前系统的物理模型首先分析、理解当前系统是如何运行的，了解当前系统的组织机构、输入输出、资源利用情况和日常数据处理过程，并用了一个具体的模型来反映自己对当前系统的理解。此步骤也可以成为“业务建模”，其主要任务是对用户的组织机构或企业进行评估，理解他们的需要及未来系统要解决的问题，然后建立一个业务USECASE模型的业务对象模型。当然如果系统相对简单，也没必要大动干戈进行业务建模，只要做一些简单的业务分析即可。抽象出当前系统的逻辑模型在理解当前系统“怎么做”的基础上，取出非本质因素，抽取出“做什么”的本质。建立目标系统的逻辑模型明确目标系统要“做什么”。对逻辑模型的补充如用户界面、启动和结束、出错处理、系统输入输出、系统性能、其他限制等。需求分析各过程如下。问题识别解决目标系统做什么，做到什么程度。需求包括：功能、性能、环境、可靠性、安全性、保密性、用户界面、资源使用、成本、进度。同时建立需求调查分析所需的通信途径。分析与综合从数据流和数据结构出发，逐步细化所有的软件功能，找出各元素之间的联系、借口特性和设计上的限制，分析它们是否满足功能要求并剔除不合理部分，综合成系统解决方案，给出目标系统的详细逻辑模型。常用的分析方法有面向数据流的结构化分析方法SA（数据流图DFD、数据词典DD、加工逻辑说明）、描绘系统数据关系的实体关系图ERD、面向数据结构的Jackson方法JSD、面向对象分析方法OOA（主要使用UML）。对于有动态时序问题的软件可以采用形式化技术，包括有穷状态机FSM的状态迁移（装换）图STD、时序图、Petri网或Z。每一种分析建模方法都有其优势和局限性，可以兼而有之，以不同角度分析，避免在软件需求方法和模型中发生教条的思维模式。一般来说，结构化方法用于中小规模软件，面向对象方法用于大型软件。编制需求分析文档需求评审档案管理系统的需求分析一、系统功能需求档案管理系