《信息系统分析与设计 教学课件 ppt 作者 姜同强 CH04系统分析概述》由会员分享，可在线阅读，更多相关《信息系统分析与设计 教学课件 ppt 作者 姜同强 CH04系统分析概述（119页珍藏版）》请在金锄头文库上搜索。
1、2019/5/25,3.1,第 4 章,系统分析概述,2019/5/25,3.2,学习完本章后，你应该具备以下能力： 了解系统分析的任务； 解释什么是需求？什么是好的需求？ 解释需求开发的步骤及每个步骤的工作内容；,LEARNING OBJECTIVES,2019/5/25,3.3,系统分析(system analysis) 是指运用一定的方法，对问题域和系统责任进行分析和理解，对其中的事物和它们之间的关系产生正确的认识，并产生一个符合用户需求，并能够直接反映问题域和系统责任的模型及其详细说明。,4.1 系统分析的基本任务,2019/5/25,3.4,可行性研究(feasibility stu
2、dy)从经济、技术和其它几个方面的因素考察所开发的系统是否是可能的和必要的。,4.1 系统分析的基本任务,2019/5/25,3.5,探索需求设计前的质量,4.2 需求分析,2019/5/25,3.6,What is requirement? Why are requirements important? What is good requirement? Requirement process How to identify requirements? How to analysis requirements? How to document requirements? How to ver
3、ify requirements?,4.2 需求分析,2019/5/25,3.7,IEEE软件工程标准词汇表（1997年）中将需求定义为： （1）用户解决问题或达到目标所需的条件或能力（Capability）。 （2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。 （3）一种反映上面（1）或（2）所描述的条件或能力的文档说明。 该定义从用户角度（系统的外部行为）和开发者角度（一些内部特性）来阐述了需求的含义。,4.2.1 什么是需求?,2019/5/25,3.8,需求是人们的期望。 探索需求是寻找人们的期望的过程。 开发就是把人们的期望转化成一种能够满足其期望的产
4、品的过程。,4.2.1 什么是需求?,2019/5/25,3.9,“用户所需要的并能触发一个程序或系统开发工作的说明”（Jones 1994）。该定义强调的是产品是什么样的，而并非产品是怎样设计、构造的。 需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。 需求(Requirement)是指用户要求软件系统必须满足的所有功能和限制。需求包括：功能要求、性能要求、可靠性要求、安全保密性要求以及开发费用和开发周期、可使用资源等方面的限制。其中功能需求是最基本的,包括数据要求和加工要求。,4.2.1 什么是需求?,2019/5/25,3.10,软件需求包括
5、三个不同的层次：业务需求、用户需求、功能需求和非功能需求。 业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。 用户需求(user requirement)文档描述了用户使用产品必须要完成的任务，这在用例（use case）文档或方案脚本（scenario）说明中予以说明。,4.2.1 什么是需求?,2019/5/25,3.11,功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求。A functional requiremen
6、t is a description of activities and services requirements are frequently identified in terms of inputs, outputs, processes, and stored data.,4.2.1 什么是需求?,2019/5/25,3.12,例子字处理程序 业务需求：“用户能有效地纠正文档中的拼写错误。” 用户需求：“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。 功能需求：“找出拼写错误的词并高亮度显示；显示提供替换词的对话框；实现整个文档范围的替换。”,4.2.1 什么
7、是需求?,2019/5/25,3.13,4.2.1 什么是需求?,2019/5/25,3.14,作为功能需求的补充，软件需求规格说明还应包括非功能需求。它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节、性能要求；设计或实现的约束条件及质量属性。 非功能需求：性能要求、可靠性要求、安全保密性要求以及开发费用和开发周期、可使用资源等方面的限制。,4.2.1 什么是需求?,2019/5/25,3.15,A nonfunctional requirement is a description of other features, characteri
8、stics, and constraints that define a satisfactory system. Examples include performance (throughput and response time), ease of learning and use, budgets, costs, and cost savings, time tables and deadline, documentation and training need, quality management, and security and internal auditing control
9、s.,4.2.1 什么是需求?,2019/5/25,3.16,PIECES模型首先是由James Wetherbe首先提出的一种需求分析框架。该框架将所要识别的非功能需求划分为六个方面-性能(Performance)、信息(Information)、经济(Economy)、控制(Control)、效率(Efficiency)和服务(Service)。,4.2.1 什么是需求?,2019/5/25,3.17,Types of Nonfunctional Requirements,Economy,2019/5/25,3.18,Types of Nonfunctional Requirements
10、(concluded),2019/5/25,3.19,需求的特点,需求是隐性的。即连用户都不清楚自己的需求。 需求是变化的。 大师说：“没有不变的需求，世上的软件都改动过3次以上，唯一一个只改动过两次的软件的拥有者已经死了，死在去修改需求的路上。” 我付了钱，但这不是我想要的“，没有用户愿意这么说。,2019/5/25,3.20,4.2.2 Why Are Requirements Important?,Frederick Brooks在1987年的经典的文章“No Silver Bullet：Essence and Accidents of Software Engineering”中充分说
11、明了需求过程在软件项目中扮演的重要作用：开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时一旦做错，将最终会给系统带来极大损失，并且以后再对它进行修改也极为困难。,2019/5/25,3.21,1994, Standish Group surveyed over 350 companies about their over 8000 software projects to find out how well they were faring. 1/3-cancelled before they w
12、ere completed; 9%-delivered on time and cost that they were budgeted(Large companies); 16%-met those criteria in small companies,4.2.2 Why Are Requirements Important?,2019/5/25,3.22,The causes of the failed projects: Incomplete requirements (13.1%) Lack of user involvement (12.4%) Lack of resources
13、(10.6%) Unrealistic expectations (9.9%) Lack of executive support (9.3%) Changing requirements and specifications (8.7%) Lack of planning(8.1%) System no longer needed (7.5%),4.2.2 Why Are Requirements Important?,2019/5/25,3.23,Results of Incorrect Requirements,The system may cost more than projecte
14、d. The system may be delivered later than promised. The system may not meet the users expectations and that dissatisfaction may cause them not to use it. Once in production, the costs of maintaining and enhancing the system may be excessively high. The system may be unreliable and prone to errors an
15、d downtime. The reputation of the IT staff on the team is tarnished because any failure, regardless of who is at fault, will be perceived as a mistake by the team.,2019/5/25,3.24,Relative Cost to Fix an Error,2019/5/25,北京工商大学信息工程学院姜同强,25,表 CHAOS报告项目成功十要素 STANDISH 95, 99,2019/5/25,北京工商大学信息工程学院姜同强,26,
16、事实1：在软件生命周期中，1个错误发现的越晚，修复错误的费用越高。 事实2：许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来. Boehm：TRW公司，54%的错误是在编码和单元测试阶段以后发现的，但实际上，这些错误的一半是属于需求和设计阶段的，而编码阶段的错误只有9%。 事实3：在需求过程中会产生很多错误 事实4：需求错误是可以被检查出来的,关于需求的几个事实,2019/5/25,3.27,4.2.3 Criteria to Define System Requirements,Consistent: the requirements are not conflicting or ambiguous.对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。 example The system will make corrections to the record w
