软件工程中需求分析的任务是什么?(具体点)
一。
确定对系统的综合要求1. 功能需求这方面的需求指定系统必须提供的服务。
通过需求分析应该划分出系统必须完成的所有功能。
2. 性能需求性能需求指定系统必须满足的定时约束或容量约束,通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。
3. 可靠性和可用性需求可靠性需求定量地指定系统的可靠性。
可用性与可靠性密切相关,它量化了用户可以使用系统的程度。
4. 出错处理需求这类需求说明系统对环境错误应该怎样响应。
例如,如果它接收到从另一个系统发来的违反协议格式的消息,应该做什么?注意,上述这类错误并不是由该应用系统本身造成的。
5. 接口需求接口需求描述应用系统与它的环境通信的格式。
常见的接口需求有:用户接口需求;硬件接口需求;软件接口需求;通信接口需求。
6. 约束设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。
在需求分析阶段提出这类需求,并不是要取代设计(或实现)过程,只是说明用户或环境强加给项目的限制条件。
常见的约束有:精度;工具和语言约束;设计约束;应该使用的标准;应该使用的硬件平台。
7. 逆向需求逆向需求说明软件系统不应该做什么。
理论上有无限多个逆向需求,我们应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。
8. 将来可能提出的要求应该明确地列出那些虽然不属于当前系统开发范畴,但是据分析将来很可能会提出来的要求。
注意:举例让学生理解:这样做的目的是,在设计过程中对系统将来可能的扩充和修改预做准备,以便一旦确实需要时能比较容易地进行这种扩充和修改。
二 。
分析系统的数据要求任何一个软件系统本质上都是信息处理系统,系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌,对软件设计有深远影响,因此,必须分析系统的数据要求,这是软件需求分析的一个重要任务。
分析系统的数据要求通常采用建立数据模型的方法(举例)。
三。
导出系统的逻辑模型综合上述两项分析的结果可以导出系统的详细的逻辑模型,通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。
四。
修正系统开发计划根据在分析过程中获得的对系统的更深入更具体的了解,可以比较准确地估计系统的成本和进度,修正以前制定的开发计划。
...
软件工程中需求分析的任务是什么?
1. 确定需求调研对象。
2. 制定需求调研计划,以一般会议记录的方式即可。
3. 分析用户需求。
显化用户需求与软件规格的差异(有些用户需求点能完全通过软件功能去满足,有些用户需求点只能通过软件功能部分地满足,有些用户需求点不通过软件功能去实现)对用户需求的优先级进行排序。
4. 制定用户需求规格说明书,系统需求规格说明书。
或者软件需求规格说明书。
5. 做好需求问题管理表(整个需求过程中,需跟进、协调的重要问题)。
在软件工程中什么是需求分析?
一。
确定对系统的综合要求1. 功能需求这方面的需求指定系统必须提供的服务。
通过需求分析应该划分出系统必须完成的所有功能。
2. 性能需求性能需求指定系统必须满足的定时约束或容量约束,通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。
3. 可靠性和可用性需求可靠性需求定量地指定系统的可靠性。
可用性与可靠性密切相关,它量化了用户可以使用系统的程度。
4. 出错处理需求这类需求说明系统对环境错误应该怎样响应。
例如,如果它接收到从另一个系统发来的违反协议格式的消息,应该做什么?注意,上述这类错误并不是由该应用系统本身造成的。
5. 接口需求接口需求描述应用系统与它的环境通信的格式。
常见的接口需求有:用户接口需求;硬件接口需求;软件接口需求;通信接口需求。
6. 约束设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。
在需求分析阶段提出这类需求,并不是要取代设计(或实现)过程,只是说明用户或环境强加给项目的限制条件。
常见的约束有:精度;工具和语言约束;设计约束;应该使用的标准;应该使用的硬件平台。
7. 逆向需求逆向需求说明软件系统不应该做什么。
理论上有无限多个逆向需求,我们应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。
8. 将来可能提出的要求应该明确地列出那些虽然不属于当前系统开发范畴,但是据分析将来很可能会提出来的要求。
注意:举例让学生理解:这样做的目的是,在设计过程中对系统将来可能的扩充和修改预做准备,以便一旦确实需要时能比较容易地进行这种扩充和修改。
二 。
分析系统的数据要求任何一个软件系统本质上都是信息处理系统,系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌,对软件设计有深远影响,因此,必须分析系统的数据要求,这是软件需求分析的一个重要任务。
分析系统的数据要求通常采用建立数据模型的方法(举例)。
三。
导出系统的逻辑模型综合上述两项分析的结果可以导出系统的详细的逻辑模型,通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。
四。
修正系统开发计划根据在分析过程中获得的对系统的更深入更具体的了解,可以比较准确地估计系统的成本和进度,修正以前制定的开发计划。
什么叫可行性分析,需求分析,软件工程的几个阶段的任务
1. 需求获取确定需求开发过程确定如何组织需求的收集、分析、细化并核实的步骤,并将它编写成文档。
2. 需求分析绘制关联图、创建开发原型、分析可行性、确定需求优先级、为需求建立模型、编写数据字典、应用质量功能调配。
3. 编写规格说明书项目视图和范围文档包含了业务需求,而使用实例文档则包含了用户需求4. 需求验证审查需求文档、依据需求编写测试用例、编写用户手册、确定合格的标准二、需求管理需求开发的结果应该有项目视图和范围文档、使用实例文档、软件需求规格说明及相关分析模型。
经评审批准,这些文档就定义了开发工作的需求基线。
软件需求分析在软件工程中的作用,有哪些软件需求分析的方法。
软件工程中包含需求、设计、编码和测试四个阶段,其中需求工程是软件工程第一个也是很重要的一个阶段,需求分析是要决定“做什么,不做什么”。
在一个软件项目中,软件需求包括三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求:业务需说明了提供给客户和产品开发商的新系统的最初利益,反映了组织机构或客户对系统、产品高层次的目标要求。
软件开发,能否获得成功,最重要的是需求分析的工作。
因此,软件需求分析能力和水平,对软件项目至关重要。
一般的分析方法和步骤如下:⑴首先调查组织机构情况 包括了解该组织的部门组成情况,各部门的职能等,为分析信息流程作准备。
⑵然后调查各部门的业务活动情况 包括了解各个部门输入和使用什么数据,如何加工处理这些数据,输出什么信息,输出到什么部门,输出结果的格式是什么。
⑶协助用户明确对新系统的各种要求 包括信息要求、处理要求、完全性与完整性要求。
⑷确定新系统的边界 确定哪些功能由计算机完成或将来准备让计算机完成,哪些活动由人工完成。
由计算机完成的功能就是新系统应该实现的功能。
常用的调查方法有: ⑴跟班作业 通过亲身参加业务工作来了解业务活动的情况。
这种方法可以比较准确地理解用户的需求,但比较耗费时间。
⑵开调查会 通过与用户座谈来了解业务活动情况及用户需求。
座谈时,参加者之间可以相互启发。
⑶请专人介绍。
⑷询问 对某些调查中的问题,可以找专人询问。
⑸设计调查表请用户填写 如果调查表设计得合理,这种方法是很有效,也很易于为用户接受的。
⑹查阅记录 即查阅与原系统有关的数据记录,包括原始单据、账簿、报表等。
通过调查了解了用户需求后,还需要进一步分析和表达用户的需求。
分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。
软件工程的软件需求
软件需求包括 3 个不同的层次――业务需求、用户需求和功能需求。
除此之外,每个系统还有各种非功能需求。
业务需求(Business requirement)表示组织或客户高层次的目标。
业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。
业务需求描述了组织为什么要开发一个系统,即组织希望达到的目标。
使用前景和范围( vision and scope )文档来记录业务需求,这份文档有时也被称作项目轮廓图或市场需求( project charter 或 market requirement )文档。
用户需求(user requirement)描述的是用户的目标,或用户要求系统必须能完成的任务。
用例、场景描述和事件――响应表都是表达用户需求的有效途径。
也就是说用户需求描述了用户能使用系统来做些什么。
功能需求(functional requirement)规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求。
功能需求有时也被称作行为需求( behavioral requirement ),因为习惯上总是用“应该”对其进行描述:“系统应该发送电子邮件来通知用户已接受其预定”。
功能需求描述是开发人员需要实现什么。
系统需求(system requirement)用于描述包含多个子系统的产品(即系统)的顶级需求。
系统可以只包含软件系统,也可以既包含软件又包含硬件子系统。
人也可以是系统的一部分,因此某些系统功能可能要由人来承担。
业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。
业务规划本身并非软件需求,因为它们不属于任何特定软件系统的范围。
然而,业务规则常常会限制谁能够执行某些特定用例,或者规定系统为符合相关规则必须实现某些特定功能。
有时,功能中特定的质量属性(通过功能实现)也源于业务规则。
所以,对某些功能需求进行追溯时,会发现其来源正是一条特定的业务规则。
功能需求记录在软件需求说明书( SRS )中。
SRS 完整地描述了软件系统的预期特性。
SRS 我们一般把它当作文档,其实, SRS 还可以是包含需求信息的数据库或电子表格;或者是存储在商业需求管理工具中的信息;而对于小型项目,甚至可能是一叠索引卡片。
开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS 。
除了功能需求外, SRS 中还包含非功能需求,包括性能指标和对质量属性的描述。
质量属性(quality attribute)对产品的功能描述作了补充,它从不同方面描述了产品的各种特性。
这些特性包括可用性、可移植性、完整性、效率和健壮性,它们对用户或开发人员都很重要。
其他的非功能需求包括系统与外部世界的外部界面,以及对设计与实现的约束。
约束(constraint)限制了开发人员设计和构建系统时的选择范围。
行业需求:企业在招聘软件测试人员时主要看中应聘者的项目经验、逻辑思维能力、一定的技术能力和综合素质,而对学历、年龄、性别、工作经验等的要求较低,相对于IT行业其他职位而言,软件测试的入行更加容易。
软件工程需求分析怎么写?
对商业用户来说,他们后面是成百上千个供应商,前面是成千上万个消费顾客。
怎样利用软件管理错综复杂的供应商和消费顾客,如何做好精细到一个小小调料包的进、销、调、存的商品流通工作,这些都是商业企业需要信息管理系统的理由。
软件开发的意义也就在于此。
而弄清商业用户如此复杂需求的真面目,正是软件开发成功的关键所在。
--- 经理:“我们要建立一套完整的商业管理软件系统,包括商品的进、销、调、存管理,是总部-门店的连锁经营模式。
通过通信手段门店自动订货,供应商自动结算,卖场通过扫条码实现销售,管理人员能够随时查询门店商品销售和库存情况。
另外,我们也得为政府部门提供关于商品营运的报告。
”-- -分析员:“我已经明白这个项目的大体结构框架,这非常重要,但在制定计划之前,我们必须收集一些需求。
”-- -经理觉得奇怪:“我不是刚告诉你我的需求了吗?”-- -分析员:“实际上,您只说明了整个项目的概念和目标。
这些高层次的业务需求不足以提供开发的内容和时间。
我需要与实际将要使用系统的业务人员进行讨论,然后才能真正明白达到业务目标所需功能和用户要求,了解清楚后,才可以发现哪些是现有组件即可实现的,哪些是需要开发的,这样可节省很多时间。
”-- -经理:“业务人员都在招商。
他们非常忙,没有时间与你们详细讨论各种细节。
你能不能说明一下你们现有的系统?”--- 分析员尽量解释从用户处收集需求的合理性:“如果我们只是凭空猜想用户的要求,结果不会令人满意。
我们只是软件开发人员,而不是采购专家、营运专家或是财务专家,我们并不真正明白您这个企业内部运营需要做些什么。
我曾经尝试过,未真正明白这些问题就开始编码,结果没有人对产品满意。
”--- 经理坚持道:“行了,行了,我们没有那么多的时间。
让我来告诉您我们的需求。
实际上我也很忙。
请马上开始开发,并随时将你们的进展情况告诉我。
”--- 风险躲在需求的迷雾之后- --以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。
在项目开发中,所有的项目风险承担者都对需求分析阶段备感兴趣。
这里所指的风险承担者包括客户方面的项目负责人和用户,开发方面的需求分析人员和项目管理者。
这部分工作做得到位,能开发出很优秀的软件产品,同时也会令客户满意。
若处理不好,则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。
因此可见——需求分析奠定了软件工程和项目管理的基础。
-- -拨开需求分析的迷雾--- 像这样的对话经常出现在软件开发的过程中。
客户项目经理的需求对分析人员来讲,像“雾里看花”般模糊并令开发者感到困惑。
那么,我们就拨开雾影,分析一下需求的具体内容:-- -·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求,通常在项目定义与范围文档中予以说明。
--- ·用户需求——描述了用户使用产品必须要完成的任务,这在使用实例或方案脚本中予以说明。
--- ·功能需求——定义了开发人员必须实现的软件功能,使用户利用系统能够完成他们的任务,从而满足了业务需求。
-- -·非功能性的需求——描述了系统展现给用户的行为和执行的操作等,它包括产品必须遵从的标准、规范和约束,操作界面的具体细节和构造上的限制。
--- ·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。
“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。
--- 前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容,为后继工作建立了一个指导性的框架。
其他任何说明都应遵循“业务需求”的规定,然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。
--- 下一层次需求——用户需求,必须从使用产品的用户处收集。
因此,这些用户构成了另一种软件客户,他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。
例如:程序的易用性、健壮性和可靠性,而这些特性将会使用户很好地接受具有该特点的软件产品。
--- 经理层有时试图代替实际用户说话,但通常他们无法准确说明“用户需求”。
用户需求来自产品的真正使用者,必须让实际用户参与到收集需求的过程中。
如果不这样做,产品很可能会因缺乏足够的信息而遗留不少隐患。
--- 在实际需求分析过程中,以上两种客户可能都觉得没有时间与需求分析人员讨论,有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。
除非遇到的需求极为简单;否则不能这样做。
如果您的组织希望软件成功,那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。
--- 优秀的软件产品建立在优秀的需求基础之上,而优秀的需求源于客户与开发人员之间有效的交流和合作。
只有双方参与者都明白自己需要什么、成功的合作需要什么时,才能建立起一种良好的合作关系。
--- 由于项目的压力与日俱增,所有项目风险承担者有着一个共同目标,那就是大家都想开发出一个既能实现商业价值又能满足用户要求,还能使开发者感到满足的优秀软件产品。
-- -客户的需求观-- -客户与开...
转载请注明出处51数据库 » 软件工程需求分析的任务