若何前进软件需求剖析16600

若何前进软件需求剖析16600

ID:47577986

大小:108.00 KB

页数:19页

时间:2019-09-20

若何前进软件需求剖析16600_第1页
若何前进软件需求剖析16600_第2页
若何前进软件需求剖析16600_第3页
若何前进软件需求剖析16600_第4页
若何前进软件需求剖析16600_第5页
资源描述:

《若何前进软件需求剖析16600》由会员上传分享,免费在线阅读,更多相关内容在工程资料-天天文库

1、如何进行软件需求分析需求的定义包拈从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求。关键的问题是一定要编写需求文档。我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起。系统的分析人员说:“我们想与你谈谈你的需求。”客户的第一反应便是「'我已经将我的要求都告诉你们前任T,现在我要的就是给我编一个系统”。而实际上,需求并未编写成文档,因此新的分析人员不得不从头做起。所以如果只冇一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白用户的需求,那完全是口欺欺人。需求的另外一种定义认为需求是“用户所需要的并能触发一个程序或系统开发工作

2、的说明”。有些需求分析专家拓展了这个概念「'从系统外部能发现系统所具冇的满足于用户的特点、功能及屈性等”。这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的。而下面的定义则从用户需耍进一步转移到了系统特性:需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性,是在开发过程中对系统的约束。从上而这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的“需求”术语存在,真正的“需求”实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对。系统分析员和客户需要

3、确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识。任何文档形式的需求(例如如卜•将要描述的需求规格说明书)仅是一个模型,一种描述。2.需求分析的任务开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求,这包括所冇而向用户、而向机器和其它软件系统的接口。同时这也是一旦做错,将最终会给系统带來极大损害的部分,并且以后再对它进行修改也极为困难。目前,国内产品的庞杂,一家企业口J能右几个系统并立运行,它们之间接口是系统开发人员最头痛的问题。对于商业最终用户应用程序,企业信息系统和软件作为一个大系统的一部分的产品是显而易见的。但是对于我们开

4、发人员来说,并没冇编写出客户认可的需求文档,我们如何知道项目于何时结束?而如杲我们不知道什么对客户來说是重要的,那我们又如何能使客户感到满意呢?然而,即便并非出于商业口的的软件需求也是必须的。例如库、组件和工具这些供开发小组内部使用的软件。当然你可能偶尔勿需文档说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训止在国内的软件开发者身上发生。近来,我遇到i个开发小组开发包括代码编辑器在内的一•套内部使用的计算机辅助软件。不幸的是,当他们开发完这个工具后,发现这个工具不能打卬出源代码文件,使用者当然

5、希望冇这个功能。结果这个小组只好手工抄写源代码文档以供代码检杳。这说明那怕需求明确无谋并构思准确,如果我们没有编写文档,软件达不到期望廿标也只能是咎曲自取了。相反的情况,我曾见一个要集成到“错误跟踪系统”屮的简单界面写了一•页需求说明。而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竞是如此冇用。他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所冇必需功能,而且未发现任何错谋。事实上,需求文档在开发过程中一直起指导作用。2.需求分析过程可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适,如图4-1所示:图4-1需求工程域的层次分解示意图需求开发可进一步

6、分为:问题获取、分析、编写规格说明和验证四个阶段。这些了项包括软件类产品中需求收集、评价、编写文档等所有活动。需求开发活动包括以下几个方面:确定产品所期望的用户类别。获取每个用户类的需求。了解实际用户任务和口标以及这些任务所支持的业务需求。分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。将系统级的需求分为几个子系统,并将需求中的一部份分配给软件组件。了解相关质量属性的重要性。商讨实施优先级的划分。将所收集的用户需求编写成文档和模型。评审需求规格说明,确保对用户需求达到共同的理解与认识,并在整个开发小组接受说明Z前将问题都弄清楚。需求管理需

7、要“建立并维护在软件工程中同客户达成的合同”。这种合同都包含在编写的需求文档与模型屮。客户的接受仅是需求成功的一半,开发人员也必须能够接受他们,并真正把需求应用到产晶中。通常的需求管理活动包押h定义需求基线(迅速制定需求文档的主体)。评审提出的需求变更、评估每项变更的口J能影响从而决定是否实施它。以一种可控制的方式将需求变更融入到项目屮。使当前的项廿计划与需求一致。估计变更需求所产牛影响并在此基础上协商新的承诺,这种承诺具体体现在项目解决方案上。让每项需求都能与英对应

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。