软件工程需求分析--需求分析

软件工程需求分析--需求分析

ID:39846512

大小:1.67 MB

页数:131页

时间:2019-07-13

软件工程需求分析--需求分析_第1页
软件工程需求分析--需求分析_第2页
软件工程需求分析--需求分析_第3页
软件工程需求分析--需求分析_第4页
软件工程需求分析--需求分析_第5页
资源描述:

《软件工程需求分析--需求分析》由会员上传分享,免费在线阅读,更多相关内容在教育资源-天天文库

1、第5章需求分析可行性研究通过以后,下一步就要根据草拟的开发计划,展开详细的需求分析活动。软件需求分析,是详细分析需求,并建立需求分析模型的阶段2021/8/81第5章软件需求分析5.1需求分析概述5.2结构化分析方法5.3数据流图的绘制5.4编制数据字典5.5加工逻辑的分析与表达5.6需求验证与评审2021/8/825.1需求分析概述5.1.1需求分析的任务、特点、主要困难5.1.2人员组成5.1.3分析师的角色5.1.4需求分析的活动和原则2021/8/835.1.1需求分析的任务完成“分析建模”;拟定“确认测试”计划修订“开发计划”编写“需求规划说明书”需求评审2021/8/841.分

2、析建模针对用户要求实现的软件功能、性能等目标,与开发人员进一步澄清、达成共识、形成规约;准确讲,需求分析是发掘需求、分析求精、逻辑建模、形成规约的过程。2021/8/851.分析建模发掘需求——调查需求、挖掘潜在需求、预测未来可能的需求;需求求精——对模糊不清的用户需求明确、精化;逻辑建模——在现行系统逻辑模型的基础上,考虑新的用户需求、限制和约束的基础上导出新系统的逻辑模型;形成规约——将双方达成共识的需求文档化、模型化,这份文档被称为“需求规约”和“需求规格说明书”,它将是后需活动开发方努力实现的目标2021/8/862.拟定“确认测试”计划有了共同的需求约定以后,就可以制定“确认测试

3、”计划,它是用户验证软件是否满足需求的依据;这个计划到综合测试后期执行。2021/8/873.修订开发计划系统调查与可行性研究阶段的最后,草拟了初步的开发计划,当时由于需求尚不详细,现可有了详细的需求分析结果以后,应该使开发计划更准确一些。2021/8/884.编写“需求规划说明书”需求分析阶段的成果集中体现在“需求规格说明书”中,这是一个里程碑;有明确的格式和内容2021/8/895.需求评审需求评审是“质量保证活动”的内容;体现出瀑布模型的“文档驱动”特点由项目经理、用户、分析员、前一阶段(可行性研究)的主要人员和后一阶段(概要设计)的主要人员组成评审小组;2021/8/810阶段性成

4、果(主要文档)包括:需求规格说明书细化的项目计划确认测试计划2021/8/811主要特点:面向问题域(即用户业务领域)只关注“逻辑”,不考虑“物理”只研究应该“做什么?”,暂不考虑用什么手段、如何实现,即“怎么做”的问题;用数流据图、数据字典、加工描述等工具建立逻辑模型2021/8/812面临的主要困难需求分析活动面临的挑战:使用有效的软件工程方法克服复杂性建立分析员与用户的有效沟通使用有效的工具,克服需求表述的二义性2021/8/8135.1需求分析概述5.1.1需求分析的任务、特点、主要困难5.1.2人员组成5.1.3分析师的角色5.1.4需求分析的活动和原则2021/8/8145.1

5、.2人员组成如果是一个企业信息系统开发项目,那么项目团队成员应包括用户和开发人员;参与团队的用户包括:企业负责人、部门负责人、专业岗位上的员工;参开团队的开发人员包括:系统分析师、数据管理员;在需求评审时,还需要”可行性分析“和”系统设计“阶段的主要人员参与;2021/8/8155.1需求分析概述5.1.1需求分析的任务、特点、主要困难5.1.2人员组成5.1.3分析师的角色5.1.4需求分析的活动和原则2021/8/8165.1.3分析师的角色是用户与开发人员的桥梁;与项目经理合作,是开发团队的领军人物;具体业务主要集中在可行性研究和需求分析阶段;个人素质方面:具有领导才能,善于沟通;具

6、有实干作风;知识面宽,重在广度而不是深度;技术全面;有时分析师是一个团队,由若干人承担;2021/8/8175.1需求分析概述5.1.1需求分析的任务、特点、主要困难5.1.2人员组成5.1.3分析师的角色5.1.4需求分析的活动和原则2021/8/8185.1.4需求分析的活动和原则活动主要分为:需求获取;分析建模;需求评审2021/8/819需求获取的目标对用户需求进行鉴别、综合,清除用户需求的模糊性、歧义性和不一致性;把对原始问题的理解和软件开发经验结合起来,鉴别由于用户的片面性或短期行为所导致的不合理要求,发现用户尚未发现的但具有真正价值的潜在需求;2021/8/820需求获取中风

7、验需求获取隐藏着很大的风险因为任何错误的需求描述,都必然造成错误的设计、错误的编程和错误的软件结果,而实际情形是这种潜在的风险是客观存在的2021/8/821总的原则分析师关注的焦点是“做什么(What)”,而不是“怎么做How”,系统会产生和使用什么数据?系统必须完成什么功能?将定义什么界面?会遇到什么约束?等。这一阶段主要精力集中在获取和分析系统的逻辑功能上。不要把“用计算机如何实现”这样的物理因素牵扯进来,影响逻辑

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

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

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