·可靠性需求:各种软件在运行时,失效的影响各不相同。在需求分析时,应对所开发软件在投入运行后不发生故障的概率,按实际的运行环境提出要求,对于那些重要的软件,或是运行失效会造成严重后果的软件,应当提出较高的可靠性要求,以期在开发的过程中采取必要的措施,使软件能够高度可靠地稳定运行,避免因运行事故而带来的损失。
·安全保密要求:工作在不同环境的软件对其安全,保密的要求显然是不同的。应当把这方面的需求恰当地做出规定,以便对所开发的软件给予特殊的设计,使其在运行中其安全方面的性能得到必要的保证。
·用户界面需求:软件与用户界面的友好性是用户能够方便、有效、愉快地使用该软件的关键之一。从市场角度来看,具有友好用户界面的软件有很强的竞争力。因此,必须在需求分析时,为用户界面细致地规定达到的要求。
·资源使用需求:这是指所开发软件运行时所需的数据、软件、内存空间等各项资源外,软件开发时所需的人力、支撑软件、开发设备等则属于软件开发的资源,需要在需求分析时加以确定。
·软件成本消耗与开发进度需求:在软件项目立项后,要根据合同规定,对软件开发的进度和步骤的费用提出要求,作为开发管理的依据。
·预先估计以后系统可能达到的目标。这样,在开发过程中,可对系统将来可能扩充与修改做准备。一旦需要时,就比较容易进行补充和修改。
·功能性需求是人们普遍关注的,但常常忽视对非功能性需求的分析。其实非功能性需求并不是无关紧要的,它们涉及到的方面多而广,因而容易被忽略。如果在进行需求分析之前没有做过可行性分析,那么补充完成这部分工作往往是必要的。从问题定义和调查研究入手,与用户密切联系,详细了解问题提出的背景,弄清要解决什么问题。然后从软件系统特性和用户目标出发,做市场调查和现场考察。仔细收集信息之后进行数据分析和功能分析,建立系统的高层逻辑模型,再进一步做成本/效益分析。最后提交一份可行性分析报告,从技术、经济、社会效应等方面论证可行性,以确认软件开发的目标是否可行。
问题识别的另一项工作是建立分析所需要的通信途径,以保证能顺利地对问题进行分析。分析员必须与用户、软件开发机构的管理部门、软件开发组的人员建立联系。项目负责人在此过程中起协调人的作用。分析员通过这种通信途径与各方商讨,以便能满足用户的要求。
(2)分析与综合
需求分析的第二步工作是问题分析和方案的综合。分析员需从数据流和数据结构出发,逐步细化所有的软件功能,找出系统各元素之间的联系、接口特性和设计上的限制分析它们是否满足功能要求,是否合理。依据功能需求、性能需求、运行特性和设计上的限制分析它们是否满足功能要求,是否合理。依据功能需求、性能需求、运行环境需求等,剔除其不合理的部分,增加其需要的部分。最终综合成系统的解决方案,给出目标系统的详细逻辑模型。
在这个步骤中,分析和综合工作反复地进行。在对现行问题和期望的信息(输入和输出)进行分析的基础上,分析员开始综合出一个或几个解决方案,然后检查这些方案是否符合软件计划中规定的范围等等,再进行修改。总之,对问题进行分析和综合的过程将一直持续到分析员与用户双方都感到有把握正确地制定该软件的规格说明为止。
常用的分析方法有面向数据流的结构化分析方法(简称SA)、面向数据结构的Jackson方法(简称JSD)、面向对象的分析方法(简称OOA)等,以及用于建立动态、模型的状态迁移图或Petri网等。这些方法都采用图文结合的方式,可以直观地描述软件的逻辑模型。
(3)编制需求分析的文档
已经确定的需求应当得到清晰准确的描述。通常把描述需求的文档叫做软件需求规格说明书。同时,为了确切表达用户对软件的输入输出要求,还需要制定数据要求说明书及编写初步的用户手册,着重反映被开发软件的用户界面和用户使用的具体要求。
此外,依据在需求分析阶段对系统的进一步分析,从目标系统的精细模型出发,可以更确切地估计所开发项目的成本与进度,从而修改、完善与确定软件开发的实施计划。
(4)需求分析评审
作为需求分析阶段工作的复查手段,在需求分析的最后一步,应该对功能的正确性、完整性和清晰性,以及其他需求给予评价。评审的主要内容是:
·系统定义的目标是否与用户的要求一致;
·系统需求分析阶段提供的文档资料是否齐全;
·文档中的所有描述是否完整、清晰、准确所反映用户要求;
·与所在其他系统成分的重要接口是否都已经描述;
·所开发项目的数据流与数据结构是否足够、确定;
·所有图表是否清楚,在不补充说明时能否理解;
·主要功能是否已包括在规定的软件范围之内,是否都已充分说明;
·设计的约束条件或限制条件是否符合实际;
·开发的技术风险是什么;
·是否考虑过软件需求的其他方案;
·是否考虑过将来可能会提出的软件需求;
·是否详细制定了检验标准,它们能否对系统定义是否成功进行确认;
·有没有遗漏、重复或不一致的地方;
·用户是否审查了初步的用户手册;
·软件开发计划中的估算是否受到了影响。
为保证软件需求定义的质量,评审应以专门指定的人员负责,并按规程严格进行。评审结束应有评审负责人的结论意见及签字。除分析员之外,用户,开发部门的管理者,软件设计、实现、测试的人员都应当参加评审工作。通常,评审的结果都包括了一些修改意见,待修改完成后再经评审通过,才可进入设计阶段。
相关推荐:
北京 | 天津 | 上海 | 江苏 | 山东 |
安徽 | 浙江 | 江西 | 福建 | 深圳 |
广东 | 河北 | 湖南 | 广西 | 河南 |
海南 | 湖北 | 四川 | 重庆 | 云南 |
贵州 | 西藏 | 新疆 | 陕西 | 山西 |
宁夏 | 甘肃 | 青海 | 辽宁 | 吉林 |
黑龙江 | 内蒙古 |