吉林大学《软件工程精品教学》软件工程第4章.pptVIP

chapher 4 SOFTWARE ENGINEERING 软件工程 Capturing the Requirements 需求获取 4.1 Capturing the requirements 需求获取 Requirement: a feature of the system or a description of something the system is capable of doing in order to fulfill the system’s purpose Why are requirements important ?需求为什么重要？ The causes of failed projects（项目失败的主要原因 1994 Standish ） 1. Incomplete requirements (13.1%) 2. Lack of user involvement (12.4%) 3. Lack of resources (10.6%) 4. Unrealistic expectations (9.9%) 5. Lack of executive support (9.3%) 6. Changing requirements and specifications (8.7%) 7. Lack of planning (8.1%) 8. System no longer needed (7.5%) 事实1 在软件生命周期中，一个错误发现得越晚，修复错误的费用越高 事实2 许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来 事实3 在需求过程中会产生很多错误 事实4 在需求阶段，代表性的错误为不明确、疏忽、不一致和二义性 事实5 需求错误是可以被检查出来的 由上面这些事实，能得出如下四点结论： 在需求过程中会产生很多错误（事实3和4） 许多错误并没有在早期被发现（事实2） 这样的错误是能够在产生的初期被检查出来的（事实5） 如果没有及时检查出来这些错误，软件费用会直线上升（事实1） 需求过程不仅是可能的而且也是值得的 “建造一个软件系统的最困难的部分是决定要建造什么……没有别的工作在做错时会如此影响最终系统，没有别的工作比以后矫正更困难。” Fred Brooks 必须理解并描述问题的信息域，根据这条准则应该建立数据模型；必须定义软件应完成的功能，这条准则要求建立功能模型；必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型；必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节. The process of determining the requirements for a software based system基于软件系统的需求定义过程 主要来源是新系统的各种系统相关者，即项目干系人。 主要考虑下面这些： 1.系统的用户，从两个方向来收集资料： 水平方向：在各分工协作部门中寻找物流、人力流、资金流、信息流、单据流、报表流、数据流等流程。 垂直方向：针对不同层次用户提取 业务操作用户：录入、修改、提交、处理、打印、界面、传输、通信、时间、速度等方面的需求 管理用户：业务管理、作业控制需求 主管（决策）用户：宏观上的统计、查询、决策需求 2.客户：项目小组要向客户汇报项目进展，项目预算 3.技术人员：技术、维护方面的需求 4.从各类系统相关者中识别出关键的人做领域专家 5.其他来源： 领域模型 当前的组织、系统、状态模型 现有文档 需求模板库、可重用需求库等 向用户发放需求调查表 召开需求调研会 深入重点岗位了解实际业务工作 边收集分析、边整理、边征求修改意见 定期向各用户层次分别汇报、演示 确定系统的边界 从多个角度考察待解决的问题 对确定需求优先级很有帮助：多个角度下都被建议的需求应该具有高优先级 把需求按必要程度分三类： Three kinds of requirements三类需求 those that absolutely must be met those that are highly desirable but not necessary those that are possible but could be eliminated “我知道你相信你已经理解了你认为我所说的内容，但是我并不能肯定你已经认识到你所听到的并不是我所想要的。” 需求获取的主要困难 Requirements documents需求文档 Requirements definition（ ）: com