软件要求定义

软件要求定义学习内容可行性研究项目开发计划软件需求分析第2页,共34页，2024年2月25日，星期天项目来源合同：为别人做；立项：为自己做；失败：无盈利－》赔钱－》声誉影响－》官司失败：尽赔钱－》公司倒闭－》东山再起难！学到的远比失去的多！

第3页,共34页，2024年2月25日，星期天可行性研究（

FeasibilityStudy）

可行性研究的目的就是用最小的代价在尽可能短的时间内确定该软件项目是否能够开发，是否值得开发，最后给决策者提供做与不做的依据。可行性研究实质上是要进行一次简化、压缩了的需求分析和设计过程，要在较高层次上以抽象的方式进行需求分析和设计过程。第4页,共34页，2024年2月25日，星期天可行性研究的任务

首先需要进行概要的分析研究，初步确定项目的规模和目标，确定项目的约束和限制。

然后进行简要的需求分析，抽象出该项目的逻辑结构，建立逻辑模型。

最后从逻辑模型出发，经过压缩的设计，探索出若干种可供选择的主要解决办法，对每种解决方法都要从以下三方面研究它的可行性。技术可行性经济可行性社会可行性第5页,共34页，2024年2月25日，星期天技术可行性在现有资源条件下，项目能否实现，风险有多大（技术、资源是否成熟）。社会可行性是否存在侵权、软件操作方式是否适合用户所在组织、现有管理制度、人员素质是否可行？第6页,共34页，2024年2月25日，星期天经济可行性（成本—效益分析）

成本—效益分析首先是估算将要开发的系统的开发成本，然后与可能取得的效益进行比较和权衡。效益分有形效益和无形效益。有形效益可以用货币的时间价值、投资回收期和纯收入等指标进行度量；无形效益主要从性质上、心理上进行衡量，很难直接进行量的比较。货币的时间价值：通常用利率表示。

F=P·(1+n·i)不计复利投资回收期：就是使累计的经济效益等于最初的投资费用所需的时间。纯收入：就是在整个生存周期之内的累计经济效益（折合成现在值）与投资之差。第7页,共34页，2024年2月25日，星期天提示不是解决问题，而是确定是否可解\值得解所以不要花过多精力，占总成本的510%例：实践性大作业——3方面考虑：

技术上----2～3学生,7周,电脑,开发经验，决心，风险（影响其它课程）......

社会上----产品有没有人用

经济上----预算,盈利,...…第8页,共34页，2024年2月25日，星期天可行性研究的具体步骤1、确定项目规模和目标，明确限制和约束。我们认为用户要的用户要的2、研究老系统

解决老系统问题老系统功能新增功能

注：

注意了解与其它系统的接口。

新系统效益老系统效益第9页,共34页，2024年2月25日，星期天可行性研究的具体步骤3、导出高层逻辑模型(conceptualdesign)…………抽象实现改进老系统模型新模型新系统应该告诉用户“What”而不是“How”第10页,共34页，2024年2月25日，星期天系统流程图（事务图）高层逻辑模型第11页,共34页，2024年2月25日，星期天可行性研究的具体步骤

3、逻辑模型4、复查和重新定义1、复查定义注：此时合同未签，应考虑成本，不宜反复太多次。5、导出和评价多种解法进度表经济上合算技术上可行操作上可行技术上不可行用户不可能操作不合算第12页,共34页，2024年2月25日，星期天可行性研究的具体步骤6、推荐行动方针YesorNo?NoYesWhy?Whichoneisthebest?Why?(cost/benefit)8、审查、存档7、编写可行性报告（开发计划）

任务分解，确定负责人

大致进度规划

财务预算

风险分析及对策粗略第13页,共34页，2024年2月25日，星期天文档：可行性报告参考GB8567－88中的可行性研究报告，进行适当裁剪。第14页,共34页，2024年2月25日，星期天项目开发计划

是对开发项目的费用、时间、进度、人员组织、硬件设备的配置、软件开发环境和运行环境的配置等进行说明和规划。是项目管理人员对项目进行管理的依据，据此对项目的费用、进度和资源进行控制和管理。工具：Project第15页,共34页，2024年2月25日，星期天第16页,共34页，2024年2月25日，星期天注意事项标书：我国对软件成本认识不足人月不能互换：需求的变更、人员的流动、环境的变化；困难：就是缺乏数据估计，导致估计不科学；估算项目复杂度（熟悉程度）、规模

第17页,共34页，2024年2月25日，星期天软件需求分析：“做什么？”

需求分析的过程是开发人员与用户共同协商，明确系统的全部功能、性能以及运行规格，并且使用软件开发人员和用户都能理解的语言准确地表达出来，即完成需求规格说明的过程。第18页,共34页，2024年2月25日，星期天软件需求重要性例子

☻“喂，是Jack吗？我是人力资源部的Tom,我们在使用你编写的职员系统时遇到一个问题，一个职员想把她的名字改成SparkleStarlight,而系统不允许，你能帮帮忙吗？”

“她嫁给了一个姓Starlight的人吗？”Jack问道。☻“不，她没有结婚，而仅仅是要更改她的名字，”Tom回答，“就是这问题，好象我们只能在婚姻状况改变时才能更改姓名。”

“当然这样，我从没想到谁会莫名其妙地更改姓名，我也不记得你曾告诉我系统需要处理这样的事情。”Jack说。☻

Tom说：“我想你当然知道每个人只要愿意都可以随时合法更改其姓名。但不管怎样，你在本周五之前解决这问题，否则Sparkle不能支付她的帐单。”

“这不是我的错！我现在正忙着做一个新的系统，还要做一些别的需求变更请求。很抱歉，只能下周才能修改。”……

第19页,共34页，2024年2月25日，星期天故事带给我们的启示……

影响：作为客户，很恼火，因为软件系统不能进行一项基本的操作。哪怕开发者给其解决了，也不会感谢他。作为开发者，也很烦人，迫使你增加了当前的工作，又要你优先处理。原因：由于收集、编写、协商、修改需求过程的手续或方法失误带来的。这里是非正式信息的收集、未确定或不明确的功能、未发现或未经交流的假设、不完善的需求文档，以及突发的需求变更过程所造成的。解决办法：重视需求分析，派经验丰富的人员做，最大程度的减少类似情况发生。第20页,共34页，2024年2月25日，星期天定值整定原则1：按与相邻接地距离保护配合整定；原则2：按相邻零序电流保护配合整定；1231与2配；1与3配；方案1：原则－>相邻线方案2：相邻线－>原则第21页,共34页，2024年2月25日，星期天需求分析的特点老问题：☻问题的复杂性☻交流障碍（讲究技巧和原则）☻不完备性和不一致性☻需求易变性（动态性）派经验丰富的人去干！系统分析员第22页,共34页，2024年2月25日，星期天软件需求的任务

——理解、分解、表达、评审whf:划分系统所有1.问题识别：双方确定问题的综合需求。☻功能需求：系统必须做什么？

☻性能需求 ：做得怎样？例：responsetime,memory,back-upmemory,……☻环境需求 ：运行环境、软硬件配置等。☻用户界面需求☻可靠性、安全性、保密性、可移植性和可维护性等方面的需求。☻将来可能提出的要求共同理解！第23页,共34页，2024年2月25日，星期天软件需求的任务2.分析与综合:导出软件的逻辑模型。对获取的需求进行一致性的分析检查，在分析、综合中逐步细化软件功能，划分成各个子功能。也对数据域进行分解，分配到各个子功能上，并用图文结合的形式，建立起新系统的逻辑模型。第24页,共34页，2024年2月25日，星期天软件需求的任务3.编写文档：☻编写需求说明书

☻编写初步用户使用手册☻编写确认测试计划

☻修改完善项目开发计划第25页,共34页，2024年2月25日，星期天需求文档用户需求报告需求规格说明书对外的，验收依据对内的，设计依据是合同的产物是立项建议书的产物由用户需求报告可产生需求规格说明书当前系统，目标系统目标系统（数据字典，算法分析）第26页,共34页，2024年2月25日，星期天软件需求的任务验证需求的一致性验证需求的完整性验证需求的现实性验证需求的有效性方法：

人工审查

开发原型系统－探索型

使用软件工具

——完整性、一致性基线4.技术审查和管理复审第27页,共34页，2024年2月25日，星期天需求分析的方法结构化分析方法：由数据流和数据字典构成，适于数据处理领域问题。但该方法的一个难点是确定数据流之间的变换，而且数据字典的规模也是一个问题，对数据结构的强调很少。功能分解法：系统＝功能＋子功能＋功能接口。过程抽象观点，很难与软件设计明确分离。基点放在功能上，不稳定，难以适用需求的变化。第28页,共34页，2024年2月25日，星期天需求分析的方法信息建模方法：从数据角度来对现实世界建模。基本工具是E-R图，数据不封闭，每个实体和它的属性的处理需求不是组合在同一实体中，没有继承性和消息传递机制来支持模型。是面向对象分析的基础。面向对象的分析：采用了实体、关系和属性等信息模型分析中的概念，同时采用了封闭、类结构和继承性等面向对象程序设计语言中的概念。第29页,共34页，2024年2月25日，星期天ER模型（Entity-RelationshipApproach）实体：客观世界中存在且可相互区分的事物。用矩形框代表。联系：事物间是有联系的。(1:1、1:N、M:N)

用连接相关实体的菱形框表示。属性：实体或联系所具有的性质。用椭圆形或圆角矩形表示。教师学生课程教学学号职称成绩学分1NNM第30页,共34页，2024年2月25日，星期天注意事项在需求分析时要注意用户对软件开发的了解程度。避免造成两种极端认识。需求的变动或新增是一个极为普遍的问题，既然普遍，所以软件开发人员不仅应该在心理上接受这种变动，还应该在需求分析时积极的发掘需求。需求人员与用户广泛交流，从深度和广度挖掘可能的需求，并应形成规范的需求文档，经用户确认。如果为写文档而写文档，不进行及时更新，甚至准备在软件开发完成后再补文档，这是绝对错误的观点。第31页,共34页，2024年2月25日，星期天可能错误没有足够用户从参与（类型、数量）开发方与用户沟通可能处于劣势不要