1　问题识别

　　首先系统分析人员要研究计划阶段产生的可行性分析报告和软件项目实施计划。主要是从系统的角度理解软件并评审用于产生计划估算的软件范围是否恰当,确定对目标系统的综合要求,即软件的需求;并提出这些需求的实现条件,以及需求应达到的标准,也就

　　是解决要求所开发软件做什么,做到什么程度。这些需求包括:

　　(1)功能需求:列举出所开发软件在功能上应做什么,这是最主要的需求。

　　(2)性能需求:给出所开发软件的技术性能指标,包括存储容量限制、运行时间限制、安全保密性等。

　　(3)环境需求:这是对软件系统运行时所处环境的要求。例如,在硬件方面,采用什么机型、有什么外部设备、数据通信接口等等;在软件方面,采用什么支持系统运行的系

　　(4)可靠性需求:各种软件在运行时,失效的影响各不相同。在需求分析时,应对所开发软件在投入运行后不发生故障的概率,按实际的运行环境提出要求。对于那些重要的软件,或是运行失效会造成严重后果的软件,应当提出较高的可靠性要求,以期在开发的过程中采取必要的措施,是软件产品能够高度可靠地稳定运行,避免因运行事故而带来的损失。

　　(5)安全保密工作需求:工作在不同环境的软件对其安全、保密的要求显然是不同的。应当把这方面的需求恰当地作出规定,以便对所开发的软件给予特殊的设计,使其在运行中其安全保密方面的性能能得到必要的保证。

　　(6)用户界面需求:软件与用户界面的友好性是用户能够方便有效地使用软件的关键之一,从市场角度来看,具有友好用户界面的软件有较强的市场竞争力。因此,必须在需求分析时,为用户界面细致地规定达到的要求。

　　(7)资源使用需求:这是指所开发软件运行时所需的数据、软件、内存、空间等各项资源。另外,软件开发时所需的人力、支撑软件、开发设备等属于软件开发的资源,需要在需求分析时加以确定。

　　(8)软件成本消耗与开发进度需求:在软件项目立项后,要根据合同规定,对软件开发的进度和各步骤的费用提出要求,作为开发管理的依据。

　　(9)预先估计以后系统可能达到的目标。这样,在开发过程中,可对系统将来可能的扩充与修改做准备,一旦需要时,就比较容易进行补充和修改。

　　功能性需求是人们普遍关注的,但对非功能性需求的分析常常被忽视。其实非功能性需求并不是无关紧要的,它们的主要特点涉及到的方面多而广,却容易被忽略。下页表1简要列举了一些在软件需求分析时应当考虑到的非功能性需求。很显然,任何一个软件的非功能性需求都要根据其类型和工作环境来确定。

　　问题识别的另一项工作是建立分析所需要的通信途径,以保证能顺利地对问题进行分析。分析员必须与用户、软件开发机构的管理部门、软件开发组的人员建立联系。项目负责人在此过程中起协调人的作用。分析员通过这种通信途径与各方面商讨,以便能按照用户的要求去识别问题的基本内容。

　　此外,如果在进行需求分析之前没有做过可行性分析,那么补充完成这部分工作往往是必要的,从问题定义和调查研究入手,与用户密切联系,详细了解问题提出的背景、弄清要解决什么问题,然后从软件系统特性和用户目标出发,做市场调查和现场考察。

　　仔细收集信息之后进行数据分析和功能分析,建立系统的高层逻辑模型,再进一步做成本/效益分析。最后提交一份可行性分析报告,从技术、经济、社会效应等方面论证可行性,以确认软件开发的目标是否可行。

　　2　分析与综合

　　需求分析的第二步工作是问题分析和方案的综合。分析员需从数据流和数据结构出发,逐步细化所有软件功能,找出系统各元素之间的联系、接口特性和设计上的限制,分析它们是否满足功能要求,是否合理。依据功能需求、性能需求和运行环境需求等,剔除其不合理的部分,增加其需要部分。最终综合成系统的解决方案,给出目标系统的详细逻辑模型。

　　在这个步骤中,分析和综合工作反复地进行。在对现行问题和期望的信息(输入和输出)进行分析的基础上,分析员开始综合出一个或几个解决方案,然后检查它的工作是否符合软件计划中规定的范围等等,再进行修改。总之,对问题进行分析和综合的过程将一直持续到分析员与用户双方都感到有把握正确地制定该软件的规格说明为止。

　　常用的需求分析方法有面向数据流的结构化分析方法(简称SA)、面向数据结构的Jackson方法(简称JSD)、面向对象的分析方法(简称OOA)等,以及用于建立动态模型的状态迁移图或Petri网等。

　　3　编制需求分析的文档

　　在软件开发的瀑布模型中,每个阶段形成的最终文档是阶段完成的里程碑,因而,需求分析阶段编制文档以备下步评审,也是此阶段的重要任务之一。以上已经确定的需求应当得到清晰准确的描述。通常把描述需求的文档叫做软件需求规格说明书。同时,为了确切表达用户对软件的输入输出要求,还需要制定数据要求说明书及编写初步的用户手册,

　　着重反映被开发软件的用户界面和用户使用的具体要求。此外,根据在需求分析阶段对系统的进一步分析,从目标系统的精细模型出发,可以更准确地估计所开发项目的成本与进度,从而修改、完善与确定软件开发实施计划。

　　4　需求分析评审

　　作为需求分析阶段工作的复查手段,在需求分析的最后一步,应该对功能的正确性、完整性和清晰性,以及其他需求给予评价。评审的主要内容是:

　　(1)系统定义的目标是否与用户的要求一致;

　　(2)系统需求分析阶段提供的文档资料是否齐全;

　　(3)文档中的所有描述是否完整、清晰,是否准确地反映用户的要求;

　　(4)与所有其他系统成分的重要接口是否都已经描述;

　　(5)所开发项目的数据流与数据结构是否足够、确定;

　　(6)所有图表是否清楚,在不补充说明时能否理解;

　　(7)主要功能是否已包括在规定的软件范围之内,是否都能充分说明;

　　(8)设计的约束条件或限制条件是否符合实际;

　　(9)开发的技术风险是什么;

　　(10)是否考虑过软件需求的其他方案;

　　(11)是否考虑过将来可能会提出的软件要求;

　　(12)是否详细制定了检验标准,它们能否对系统定义成功地进行确认;

　　(13)有没有遗漏、重复或不一致的地方;

　　(14)用户是否审查了初步的用户手册;

　　(15)软件开发设计计划的估算是否受到了影响等。