如何进行软件需求分析
展开全部 1.概念需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求.关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起.系统的分析人员说:"我们想与你谈谈你的需求."客户的第一反应便是:"我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统".百事通而实际上,UGGs,需求并未编写成文档,因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白用户的需求,那完全是自欺欺人.需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明".有些需求分析专家拓展了这个概念:"从系统外部能发现系统所具有的满足于用户的特点、功能及属性等".这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性:需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性,是在开发过程中对系统的约束.从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的"需求"术语存在,真正的"需求"实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.任何文档形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述.2.需求分析的任务开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难.目前,国内产品的庞杂,一家企业可能有几个系统并立运行,它们之间接口是系统开发人员最头痛的问题.对于商业最终用户应用程序,企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说,并没有编写出客户认可的需求文档,我们如何知道项目于何时结束?而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢?然而,即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发生.近来,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是,当他们开发完这个工具后,发现这个工具不能打印出源代码文件,使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确,如果我们没有编写文档,软件达不到期望目标也只能是咎由自取了.相反的情况,我曾见一个要集成到"错误跟踪系统"中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误.事实上,需求文档在开发过程中一直起指导作用.3.需求分析过程可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适,如图4-1所示:图4-1 需求工程域的层次分解示意图需求开发可进一步分为:问题获取、分析、编写规格说明和验证四个阶段.这些子项包括软件类产品中需求收集、评价、编写文档等所有活动.需求开发活动包括以下几个方面:确定产品所期望的用户类别.获取每个用户类的需求.了解实际用户任务和目标以及这些任务所支持的业务需求.分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息.将系统级的需求分为几个子系统,并将需求中的一部份分配给软件组件.了解相关质量属性的重要性.商讨实施优先级的划分.将所收集的用户需求编写成文档和模型.评审需求规格说明,确保对用户需求达到共同的理解与认识,并在整个开发小组接受说明之前将问题都弄清楚.需求管理需要"建立并维护在软件工程中同客户达成的合同" .这种合同都包含在编写的需求文档与模型中.客户的接受仅是需求成功的一半,开发人员也必须能够接受他们,并真正把需求应用到产品中.通常的需求管理活动包括:定义需求基线(迅速制定需求文档的主体).评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它.以一种可控制的方式将需求变更融入到项目中.使当前的项目计划与需求一致.估计变更需求所产生影响并在此基础上协商新的承诺,这种承诺具体体现在项目解决方案上.让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪.在整个项目过程中跟踪需求状态及其变更情况.以...
怎样做软件的需求分析?
展开全部 软件需求的定义:(1)用户解决问题或达到目标所需的条件或能力。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。
实通俗的讲,“需求”就是用户的需要,它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件,它是一个程序或系统开发工作的说明,表现形式一般为文档形式。
需求工程的定义:需求分析的过程,也叫做需求工程和需求阶段,它包括了需求开发和需求管理两个部分。
需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动,分为四个阶段:情况获取、分析、制订规格说明和评审。
这四个阶段不一定是遵循线性顺序的,他们的活动是相互独立和反复的。
需求管理是软件项目开发过程中控制和维持需求约定的活动,它包括:变更控制、版本控制、需求跟踪、需求状态跟踪等工作。
需求开发与管理的一些方法:(1)绘制关联图:绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。
(2)可行性分析:在允许的成本、性能要求下,分析每项需求实施的可行性,提出需求实现相关风险,包括与其它需求的冲突,对外界因素的依赖和技术障碍。
(4)系统原型:当用户自身对有的需求不十分清楚时,我们可以建立一个系统原型,用户通过评价原型更好地理解所要解决的问题。
。
(5)图形分析模型:绘制图形分析模型是编制软件需求规格说明重要手段。
它们能帮助分析人员理清数据、业务模式、工作流程以及他们之间的关系,找出遗漏、冗余和不一致的需求。
这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
(6)数据字典:数据字典是对系统用到的所有数据项和结构的定义,以确保开发人员使用统一的数据定义。
在需求阶段,数据字典至少应定义客户数据项,确保客户与开发小组是使用一致的定义和术语。
需求管理的方法主要包括以下一些方面:1)确定需求变更控制过程。
制定一个选择、分析和决策需求变更的过程,所有的需求变更都需遵循此过程。
2)进行需求变更影响分析。
评估每项需求变更,以确定它对项目计划安排和其它需求的影响,明确与变更相关的任务并评估完成这些任务需要的工作量。
通过这些分析将有助于需求变更控制部门做出更好的决策。
3)建立需求基准版本和需求控制版本文档。
确定需求基准,这是项目各方对需求达成一致认识时刻的一个快照,之后的需求变更遵循变更控制过程即可。
每个版本的需求规格说明都必须是独立说明,以避免将底稿和基准或新旧版本相混淆。
4)维护需求变更的历史记录。
将需求变更情况写成文档,记录变更日期、原因、负责人、版本号等内容,及时通知到项目开发所涉及的人员。
为了尽量减少困惑、冲突、误传,应指定专人来负责更新需求。
5)跟踪每项需求的状态。
可以把每一项需求的状态属性(如已推荐的,已通过的,已实施的,或已验证的)保存在数据库中,这样可以在任何时候得到每个状态类的需求数量。
6)衡量需求稳定性。
可以定期把需求数量和需求变更(添加、修改、删除)数量进行比较。
过多的需求变更"是一个报警信号",意味着问题并未真正弄清楚。
4.需求分析评价标准(1)清晰:目前大多数的需求分析采用的仍然是自然语言,自然语言对需求分析最大的弊病就是它的二义性,所以开发人员需要对需求分析中采用的语言做某些限制。
例如尽量采用主语+动作的简单表达方式。
需求分析中的描述一定要简单,千万不要采用疑问句、修饰这些复杂的表达方式。
除了语言的二义性之外,注意不要使用行话,就是计算机术语。
需求分析最重要的是和用户沟通,可是用户多半不是计算机的专业人士,如果在需求分析中使用了行话,就会造成用户理解上的困难。
(2)完整:需求的完整性是非常重要的,如果有遗漏需求,则不得不返工,在软件开发过程中,最糟糕的事情莫过于在软件开发接近完成时发现遗漏了一项需求。
但实际情况是,需求的遗漏是常发生的事情,这不仅仅是开发人员的问题,更多发生在用户那里。
要做到需求的完整性是很艰难的一件事情,它涉及到需求分析过程的各个方面,贯穿整个过程,从最初的需求计划制定到最后的需求评审。
(3)一致:一致性是指用户需求必须和业务需求一致,功能需求必须和用户需求一致。
在需求过程中,开发人员需要把一致性关系进行细化,比如用户需求不能超出预前指定的范围。
严格的遵守不同层次间的一致性关系,就可以保证最后开发出来的软件系统不会偏离最初的实现目标。
(4)可测试:一个项目的测试从什么时候开始呢?有人说是从编码完成后开始,有人说是编码的时候同时进行单元测试,编码完成后进行系统测试,这些结论都不完全正确。
实际上,测试是从需求分析过程就开始了,因为需求是测试计划的输入和参照。
这就要求需求分析是可测试的,只有系统的所有需求都是可以被测试的,才能够保证软件始终围绕着用户的需要,保证软件系统是成功的。
如何做好软件需求捕获
首先,问题的根源是:需求不断变化很多人都有这样的经历,在捕获需求时,根据客户的阐述,做了记录,然后开发出了软件,客户却说很多地方不符合他们的意思,又要求修改我们分析一下捕获需求过程中存在的问题比如说,一个业务流程,从业务逻辑到能转化成软件实现很可能会有问题这就是所说的信息化过程中需要进行的业务改造,因为能输入计算机,并输出结果的一定是能进行形式化处理的内容,这也是很多企业员工抵制信息化的原因之一,因为信息化会导致人的因素会被相对削弱,他们的工作过程也会完全被透明化对于产品类的项目,你的客户不是一个,那么就要广泛的去征求意见,需求调查问卷通常对全面了解客户需求有一定的作用对于特定客户,需要和他们直接沟通交流和客户交流要注意方式方法,不能盲目约见,下面是一些行之有效的方法一 会面前做充分的准备通常会面前的问题列表准备时间要远远多于会面的时间通常客户在连续和你交谈2个小时之后,就会失去热情和耐心,这是大部分人的共同特点所以充分的准备工作很重要如果你去客户那捕获需求,通常客户会说,我需要做一个什么样的系统,然后我可以用它来做这个,那个,还有那个......,然后就不知道该说什么了这时,你一定要拿出事先准备的问题列表,针对每个大的功能的每一个功能点进行提问,一个都不能放过对非功能的需求也同样不能放过,如客户需要的系统至少连续运行多少小时不出问题,系统在若干数量的访问者访问时的响应时间范围等如果你在会面前没有对客户提供的资料,表格等进行全面研究,对客户需求就不可能调查全面,你可能需要反复去约见他,这样你会给客户留下工作效率低的印象,他对你会逐渐的感到厌烦,对你未来的工作表现会失去信心二让客户打开话匣子对客户进行提问,引导客户说出他们的需求,是非常关键的,这里面的学问也是很大的问恰当的问题,问能让客户打开话匣子的问题,你就胜利了对于你对某些功能的猜想和假设,也一定要问客户,是不是根本就不需要,客户有时会碍于情面不好意思说出你的想法是没有必要的或是错误的,这时你一定要足够敏感,并勇于否定自己,这样会减少不必要的开发工作,也会给客户留下你很尊重事实的良好印象三千万不要浪费客户的时间和客户面谈时特别要注意一点,就是千万不能浪费客户的时间,让他觉得非常无聊,这是捕获需求最大的忌讳一旦你犯了这样的错误,你再想约见他就难了,他很可能不愿意再和你会面了尤其是企业中的领导,他们通常是日理万机,能抽出时间和你会面,你应该感到很荣幸,因此要格外珍惜会面的时间四搞清能正确回答问题的人对于关乎全局的问题,操作级别的人员给出的答案通常是不权威的,即便他们回答了你,你也一定要去大干部那里确认一下,再开始开发工作,否则你会后悔的原型对于提高客户对软件的认知程度有很好的效果,他能使客户对软件有一个直观的认识,面对原型,他们可以更好地提出他们的想法和意见,尤其对那些对软件缺乏认识的客户对原型的修改,再确认,最后得到稳定的原型,这些工作会让需求更稳定,减少很多实施工作中的反复修改工作或者返工六充分利用需求确认会议需求确认会议通常由全体涉众(利益相关人)参加,这可是个确认需求的难得的机会,大家能聚在一起,这样的机会其实很难得,所以一定要珍惜在这种会议上,一定要先针对全局性的问题(与大家都相关的问题)进行交流,千万不要针对部分人感兴趣的问题讨论个没完没了,那样的话,不感兴趣的人会走开的,那样你再想征求与他们相关问题的意见时就找不到人了对于只跟个别部门或人员有关系的问题你可以单独找时间根他们讨论
怎么做需求分析(下)
Ivar Jacobson(1992)把这种看法系统地阐述成用例(用例)的方法进行需求获取和建模。
虽然用例来源于面向对象的开发环境,但是它也能应用在具有许多开发方法的项目中,因为用户并不关心你是怎样开发你的软件。
而最重要的,用例的观点和思维过程带给需求开发的改变比起是否画正式的用例图显得更为重要。
注意用户要利用系统做什么远远强于询问用户希望系统为他们做什么这一传统方法。
用例的重要功能是用画用例图的功能来鉴别和划分系统功能。
它把系统分成角色(actor)和用例(用例)。
角色(actor)表示系统用户能扮演的角色(role)。
这些用户可能是人,可能是其他的计算机一些硬件或者甚至是其它软件系统,唯一的标准是它们必须要在被划分进用例的系统部分以外。
它们必须能刺激系统部分并接收返回。
用例描述了当角色给系统特定的刺激时系统的活动。
这些活动被文本描述。
它描述了触发用例的刺激的本质,输入和输出到其他活动者,和转换输入到输出的活动。
用例文本通常也描述每一个活动在特殊的活动线时可能的错误和系统应采取的补救措施。
这样说可能会非常复杂,其实一个用例描述了系统和一个角色(actor)的交互顺序。
用例被定义成系统执行的一系列动作,动作执行的结果能被指定角色察觉到。
用例可以: 用例捕获某些用户可见的需求,实现一个具体的用户目标。
用例由角色激活,并提供确切的值给角色。
用例可大可小,但它必须是对一个具体的用户目标实现的完整描述。
在UML中,用例表示为一个椭圆。
角色是指用户在系统中所扮演的角色。
其图形化的表示是一个小人。
在某些组织中很可能有许多角色实例(例如有很多个销售员),但就该系统而言,他们均起着同一种作用,扮演着相同的角色,所以用一个角色表示。
一个用户也可以扮演多种角色。
例如,一个高级营销人员既可以是贸易经理,也可以是普通的营销人员;一个营销人员也可以是售货员。
在处理角色时,应考虑其作用,而不是人或工作名称,这一点是很重要的。
我们使用不带箭头的线段将角色与用例连接到一起,表示两者之间交换信息,称之为通信联系。
角色触发用例,并与用例进行信息交换。
单个角色可与多个用例联系;反过来,一个用例可与多个角色联系。
对同一个用例而言,不同角色有着不同的作用:他们可以从用例中取值,也可以参与到用例中。
需要注意的是角色在用例图中是用类似人的图形来表示,尽管执行的,但角色未必是人。
例如,角色也可以是一个外界系统,该外界系统可能需要从当前系统中获取信息,与当前系统有进行交互。
一个用例可能包括完成某项任务的许多逻辑相关任务和交互顺序。
因此,一个用例是相关的用法说明的集合,并且一个说明(scenario)是用例的实例。
这种关系就像是类和对象的关系。
在用例中,一个说明被视为事件的普通过程(normal course),也叫作主过程,基本过程,普通流,或“满意之路” (happy path)。
在描述普通过程时列出执行者和系统之间相互交互或对话的顺序。
当这种交互结束时,执行者也达到了预期的目的。
在用例中的其它说明可以描述为可选过程(alternative coruse)。
可选过程也可促进成功地完成任务,但它们代表了任务的细节或用于完成任务的途径的变化部分。
在交互序列中,普通过程可以在一些决策点上分解成可选过程,然后再重新汇成一个普通过程。
角色类和角色实例 软件产品最终是给一些用户来使用的,而用户之间的差异是非常大的。
造成差异的原因包括了对计算机的认知程度的不同,使用习惯的不同,在软件目标组织中所处的地位不同,地理位置不同,业务熟练程度不同。
不同的用户都有自己一系列的功能需求和非功能需求。
对电脑熟练程度不同的人可能就会有不同的要求,熟练程度低的用户可能希望有一个友好的界面,熟练程度高的用户可能更希望有快捷键或宏的操作以提高工作效率。
考虑到用户的差异性,将用户分类并研究用户类的行为特征是非常有必要的。
所以在做具体的需求之前,先将用户分局行为和特点进行分类,对于研究、收集用户的需求是非常有帮助的。
可以利用一个简单的表格列出一些原始的分类,然后不断的完善这个表格。
确认你的分类之间没有交集。
并充分描述用户分类的行为,目的,要求等。
在企业分析中,比较常见的分类可能包括,供应商,客户,部门等。
就像C++中的类和对象一样,我们把分析出的用户分类称为“角色类”,把实际的用户称为“角色实例”。
在得到用户分类之后,最重要的就是要选出用户代表,用户代表不仅仅是在需求阶段中参与项目,还必须对项目的全过程负责。
用户代表能够代表用户分类的需求。
抓住用户代表的需求就大致把握住了用户类的需求。
当然,需求分析还是需要在用户中做大规模的调查的,只是要把重点放在用户代表上。
确保和用户直接进行沟通!大家有没有玩过传话的游戏,可能看过。
一群人排成一列,一句话从排头挨个向后传,到最后,那句话已经是面目全非了。
所以,一定要保证项目组能够直接和用户接触。
对于和用户直接沟通这一点,一般的针对特定企业的应用系统当然是不成问题,可是如果是开...
怎么做好需求分析整理
需求分析是介于系统分析和软件设计阶段之间的重要桥梁。
一方面,需求分析以系统规格说明和项目规划作为分析活动的基本出发点,并从软件角度对它们进行检查与调整;另一方面,需求规格说明又是软件设计、实现、测试直至维护的主要基础。
良好的分析活动有助于避免或尽早剔除早期错误,从而提高软件生产率,降低开发成本,改进软件质量。
需求分析阶段的基本任务是深入描述软件的功能和性能,确定软件设计的限制和软件同其它系统元素的接口细节,定义软件其它有效的需求。
最主要的原因是对于开发小组的使用成员(包括用户)来说,需求确定是极具认知性和创造性的活动。
需求确定也许是仍在苦苦等待人工智能支持的最后领域之一。
具体表现如下:系统分析员对问题域的了解程度也是一大困难。
系统分析员感到需求确定很困难的另一个原因是问题域的动态性。
生活是动态的,公司也是。
项目团队成员之间的沟通也一直是需求确定的另一大困难。
每个问题域都有术语。
最后,需求确定过程还会受到其它因素的影响。
例如劳累、不舒服、开会时室内和窗外的干扰、团队成员的压力等等。
怎么做好一个需求分析师?
展开全部 看看下面这个故事吧,也许看完了你就能明白了。
。
先来看一个老掉牙的故事:福特说,我在设计汽车之前,到处去问人们“需要一个什么样的更好的交通工具?”,几乎所有人的答案都是 ── 一匹“更快的马”。
“更好的交通工具”代表用户的“需求”;“更快的”是用户对于解决这个“需求”的“期望值”;“马”是用户对于解决这个“需求”的自假设“功能”。
一个初级的设计者,被用户牵着鼻子走。
听到“更快的马”以后,会马上去设计一匹“马”。
这个时候,无论在“马”上如何做创新,思路已经框死,结果很难突破。
最终只能出来平庸的设计,很难长久很容易被模仿和超越,实现不了多大的商业价值。
一个合格的设计者,和用户一起走。
听到“更快的马”以后,会考虑“更快的”这个“期望值”,围绕着它突破“马”的局限,去做设计。
最终可能会出来很好的设计,但他们把“需求”本身抛到了脑后,最终只能简单的满足需求达到期望,而无法引导需求。
他们可以做出来成功的产品,但随着用户期望的增长,这样的产品很 难有取得用户的长久青睐,也很难取得商业上长久的成功。
一个卓越的设计者,自己会作为用户的一部分深入了解他们,并带着用户一起走。
听到“更快的马”以后,他们会先去考虑需求是“更好的交通”工具,然后再结合 “更快的”这个主要期望。
用对用户最有价值的方式在的满足需求超越期望(把“马”这件事抛到脑后),从而引导需求,并获取更丰厚更长久的商业利益,和用户双赢。
不可否认,史玉柱是一个商业的天才。
他发现了“送礼”这个大需求,并发现了送礼的期望在于“面子”而非“ 实用”。
于是他通过“广告”在推广的同时增加产品的“价值”,而非在产品质量上增加“价值”。
春节,杭州人告诉我:“我们春节送礼都是送保健品,广告播什么就买什么,因为有 知名度”。
但他忘记了,这样是否可以给用户带来真正的长期价值。
生活层次相对较高的行州人又告诉我“我们不买脑白金和黄金酒,那些都是骗人的档次低。
我们买灵芝、鹿茸、人参、...”。
他发现了“砍人”的需求,并发现了“花再多钱也要砍死他”这个期望,最终使用了“网游”这个功能,用最简单粗暴的商业设计获取暴利。
但他忘记了,这样做不能给人带来真正的价值,于是最后他在利用互联网社区引导需求的时候遇到了问题 ... 福特是一个商业的天才,更是产品的天才。
他可以发现人们需要“更好的交通工具”这个大需求,并肯定了这个需求的渴望程度会随着社会交往的扩大会越来越强。
同时他肯定了“更快的”这个用户的首要期望,结合这个期望开始思考。
然后,他又判断出汽车比火车有更低的成本,而且对于用户更有价值,会替代火车。
最后,他用“汽车”而不是“马”来满足需求、达到并超越期望, 同时引导用户往下的进一步需求和期望... 于是,他的商业回报自然而然的产生了。
用户的真正需求是什么? 》 用户的期望值是什么? 》 如何做才对用户最有价值,并让企业获利? 》 如何超越期望并引导需求,获取更高更长久的商业利益? 这是一个必然思考逻辑,违背这个逻辑出来的产品势必难以获取长久的成功。
从某种程度上来说,产品模式是“用户真正需要的是什么?”,产品设计是“主要满足什么期望值,给用户带去什么价值?”,商业模式是“用什么功能,如何赚钱?”,创新设计是“如何超越期望,获取更高更长久的利益?”。
所以,我在同意邵亦波所说“创业者更应该注重‘产品’”的同时,主张一个产品的主导者甚至是一个企业的领导者,更应该注重: 产品模式的设计:用户真正需要满足的需求是什么? 产品的设计:让用户达到什么样的期望?给他们带去什么价值? 创新设计:如何超越期望,获取更高更长久的成功? 至于单纯的商业模式设计,当你做好了产品模式的设计、产品的设计、创新的设计,会发现那其实只是“功能的设计”而已,可以找到更多的执行者去做。
软件需求分析的过程
软件需求分析所要做的工作是深入描述软件的功能和性能,确定软件设计的限制和软件同其它系统元素的接口细节,定义软件的其它有效性需求。
进行需求分析时,应注意一切信息与需求都是站在用户的角度上。
尽量避免分析员的主观想象,并尽量将分析进度提交给用户。
在不进行直接指导的前提下,让用户进行检查与评价。
从而达到需求分析的准确性。
分析员通过需求分析,逐步细化对软件的要求,描述软件要处理的数据域,并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据和功能表示。
在软件完成后,制定的软件规格说明还要为评价软件质量提供依据。
怎么做好需求分析
呵呵,你这个问题问得太大太宽泛了,需求分析在不同的项目,不同的业务领域采用的方法可能有很大的不同,比如有些领域是业务驱动的,有些领域是技术驱动,这样做需求分析时侧重点是有所不同的。
IT工程技术网这里有一篇关于如何做好需求分析的文章希望对你有所帮助,
转载请注明出处51数据库 » 如何做好软件需求分析