面向对象分析和设计-需求.ppt

面向对象分析和设计,需求,内容,公开课需求分析用例分析设计,内容,需求概述 10.1.1 需求定义 需求中的问题 10.1.3 解决办法 10.1.4 需求与错误 10.1.5 需求的作用 需求的层次,10.1.1 需求定义,什么是软件需求?1.软件需求就是为了解决现实世界中的特定问题必须展现的属性。,2.可行性研究的基本目的是用较小的成本在较短的 时间内确定是否存在可行解，因此许多细节被 忽略了。3.然而在最终的系统中却不能遗漏任何一个微小的 细节，所以可行性研究并不能代替需求分析，它 实际上并没有准确回答“系统必须做什么？”这个 问题。,需求与设计,Do the right things,Do the things right,需求阶段的主要目标,1.建立项目的软件范围和边界条件，包括一个操作“前景”，“接 受准则”和产品中包含什么，不包含什么。2.确定核心的用例，这是系统运行的主要场景，它将决定 系统设计的方案3.针对主要的场景，确定或者演示至少一个备选的系统结构对整个项目估计总成本和计划(更详细的估计将安排在细化阶段中)。4.估计可能的风险(不可预计性的来源）5.为项目准备支持环境,教学信息采集系统案例-系统需求（1）,该软件是老师组织教学的工具，是学生学习的信息环境，是师生教学活动的纽带；是向家长和用人单位汇报和展示教学成果的平台。组织教与学活动包括这样一些事情：1.1 发布教学资源推荐的阅读材料、学生作品（按照“目标需求、概要设计、详细设计、测试计划、测试记录、使用说明书、课程总结、项目过程改进意见、项目开发计划、软件作品展示”10部分分类提供）、推荐网站、推荐文献1.2 发布课程信息向任课老师提供发布课程信息的平台，主要包括如下信息：当前课程的教学大纲、教学方案、课程的PPT（教学录像）、课表、日历、学生名单当前学生的分组情况1.3 组织教学活动老师布置教学活动，包括：作业、实验、考勤、老师考评等学生参与教学活动，包括：提交作业、提交实验报告、签到、小组长考评等课程讨论，包括：常规的讨论栏目，以及发起议题、跟帖讨论等等,教学信息采集系统案例,教学信息,教学资源，教学成果，教学活动,系统管理，接口,教学信息采集系统案例,1.核心案例：教学信息发布2.核心业务场景：教师发布教学教学资源信息，决定了系统的信息交互机制和安全机制，b/s 架构作为初步的备选架构3.教师、教学管理人员、学生都可以发布教学信息，决定系统具有另一个核心机制，错误和异常处理机制。4.核心对象：教学信息5.主要风险:对众多教学信息的高效组织和管理,需求中的问题,没有充分考虑用户的需要裁剪用户需求需求确定缓慢界面设计不利于用户使用从用户角度考虑不足设计上不合理需求书写不规范内容条理不足考虑不全面软件环境硬件环境需求不准确细致应当尽可能准确细致的描述,教学信息采集系统案例,1.需求不准确细致“谁在什么时候在什么地方干什么”的“谁”没有交代清楚，如：“推荐的阅读材料、学生作品”2.没有充分考虑用户的需要 例：“是向家长和用人单位汇报和展示教学成果的平台”，中“教学成果”，一般是指教学方法、教学质量研究方面的创新，出书获奖等方面的内容，而下文没有这方面的内容。3.需求书写不规范 没有范围，术语等方面的信息。4.考虑不全面 硬件环境没有介绍，在互联网上，还是在局域网上，手机 行不行，软件环境没有介绍，如资源的大小，类型没有约束.,10.1.3 解决办法,与用户深入讨论确定需求界面设计应多从用户角度出发原型系统用户测试规范需求文档遵循室需求规范需求书写尽可能考虑全面，描述准确,涉及到谁?,客户（Client）为开发付钱的人，将来是产品的拥有者顾客（Customer）买商品化软件的人，或者将来有发言权确定是否产品可以接受（开发产品）。可能与客户是同样的人涉众 任何对系统的需求有直接或者间接影响的人,教学信息采集系统案例,客户：某大学顾客：教学管理人员，教师，学生，家长，社会大众涉众：招生办，就业指导处，校领导，上级主管部门，学生就业的著名企业,10.1.4 需求与错误,1.在软件生命周期中，一个错误发现得越晚，修复错误的费用越高B o e h m（1 9 8 1）发现要改正在产品付诸应用后所发现的一个需求方面的缺陷比在需求阶段改正这个错误要多付出6 8倍的成本。2.许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来，而这错误的45%属于需求和设计错误，编码阶段的错误仅占9%,10.1.5 需求的作用,（1）需求分析不到位或不彻底，导致开发者反复多次地进行需求分析，致使设计、编码、测试无法顺利进行；要么客户配合不好，导致客户对需求不确认，或客户需求不断变化，同样致使设计、编码、测试无法顺利进行.,（2）需求分析的输出文档是用户需求报告，它既是软件生存周期中的第一个里程碑，又是客户、软件开发人员和项目管理人员三者必须遵守的一根基线,10.1.5 需求的作用,3）需求分析要占用整个软件开发时间或工作量的30%左右。（4）需求获取中的错误，属于软件开发中的早期错误，它会在后续的设计和实现中进行发散式的传播。,需求的层次,软件需求包括三个不同的层次1）业务需求 业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求2）用户需求用户使用产品必须要完成的任务，3）功能需求也包括非功能需求开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求,教学信息采集系统案例,1.项目目标：（要准确反映主要领导的想法)该软件系统是老师组织教学的工具，是学生学习的信息环境，是师生教学活动的纽带；是向家长和用人单位汇报和展示教学成果的平台 2.用户需求(用户对系统应完成任务的直观要求）发布教学资源，发布课程信息，组织教学活动 3.功能需求 1.老师布置教学活动，包括：作业、实验、考勤、老师考评,10.2.2 需求元素,分类,系统功能,系统属性,需求,需求就是系统必须符合的条件或具备的功能分类功能性 特性集能力安全性可支持性可测试性 可扩展性 可适应性 可维护性 兼容性 可配置性 可服务性 可安装性是否可本地化（国际化）,性能速度 效率 可用性 准确性 吞吐量 响应时间 恢复时间资源用途其它：设计约束 实施需求 接口需求物理需求,可用性(Usability)Human factors美观用户界面的一致性在线和联机帮助向导(wizard)和代理用户文档培训材料可靠性故障的频率严重性可恢复性可预见性准确性平均故障间隔时间（MTBF）性能,教学信息采集系统案例,1.缺少约束设计 如学生提交作业，是纸质还是电子，有无模版，有无说明条目，电子提交后要不要批改，要不要下发等2.缺少对外接口设计 要不要和学生成绩管理系统接口，要不要教务管理系统接口等3.缺少物理拓扑结构4.缺少安全方面的要求，如怎样防止学生把垃圾上传5.缺少性能、界面方面的要求,功能分类,1.明显的功能2.隐含的功能3.可选的功能,例：老师布置教学活动，包括：作业、实验、考勤、老师考评等明显功能：提交教学活动信息可选功能：提交作业、实验、考勤、老师考评（扩展）隐含的功能：提交教学活动的查询、修改、删除、归档等,教学信息采集系统案例,需求与业务过程,业务过程：为了保证企业正常运转要做的事情。业务过程用用例来描述用例非面向对象模型关注角色和责任,教学信息采集系统案例,教学信息采集系统案例,概念模型（核心分析类）,信息平台,教学信息,使用人员,教学信息采集系统案例,需求管理,需求管理是一种系统化的方法：获取，记载、组织和跟踪系统的需求为客户和项目团队之间针对不断变化的需求建立和维护协议,需求的管理属性,状态：已提出，已批准，已并入利益：关键，重要，有用，工作量风险稳定性目标发布版责任分配原因：需求来源,需求与其他元素的关系,需求规格,用例（高+扩展）,用例图,领域模型,术语,调查报告,原型,预算、进度计划,10.2.3 需求采集步骤,（1）通过调查研究，获取用户的需求。软件开发人员通过认真细致的调查研究，获得进行系统分析的原始资料。需求信息的获取可来源于阅读描述系统需求的用户文档；对相关软件、技术的市场调查；对管理部门、用户的访问咨询；对工作现场的实际考察等。(2)去除非本质因素，确定系统的真正需求。对于获取的原始需求，运 用抽象的逻辑思维，找出需求间的内在联系和矛盾，去除需求中不合理和非本质的部分。(3)描述需求，建立系统的逻辑模型。建立软件需求模型是需求分析的核心工作，它通过建立需求的 多种视图，揭示出需求的不正确、不一致、遗漏和冗余等更深的问题。,10.2.3 需求采集步骤,(4)书写需求说明书，进行需求复审。需求阶段应提交的主要文档包括需求规格说明书、初步的用户手册和修正后的开发计划。为了保证软件开发的质量，对软件需求阶段的工作要按照严格的规范进行复审，从不同的技术角度对该阶段工作做出综合性的评价。复审即要有用户参加，也要有管理部门和软件开发人员参加。,“图书管理系统”需求分析报告（实例）,10.3.需求概述10.3.1 目标“图书管理系统”主要提供图书信息和读者基本信息的维护以及借阅等功能。该系统针对的用户是单个中小型图书室，藏书的种类和数量较少，系统需要操作方便，方便管理员对整个系统管理和学生借阅书的方便。10.3.2 用户类和特征 最终的用户是图书管理员和读者，图书管理员需要进行用户的创建、修改和删除等工作，要求具备计算机知识，如权限管理等。读者是普通用户，具备一定的计算机操作知识即可。10.3.3 运行环境参见2.3 可行性分析报告的运行环境。,“图书管理系统”需求分析报告（实例）,.功能需求本系统相应的需求有：（1）能够存储一定数量的图书信息,并方便有效的进行相应的书籍数据操作和管理，这主要包括：图书信息的录入、删除及修改。图书信息的多关键字检索查询。图书的出借、返还和资料统计。（2）能够对一定数量的读者进行相应的信息存储与管理，这其中包括：读者信息的登记、删除及修改。读者资料的统计与查询。能够提供一定的安全机制，提供数据信息授权访问。,“图书管理系统”需求分析报告（实例）,需求补充说明：（1）数据保存：需要长期保存在数据库的数据有：图书信息：图书的基本信息；读者信息：读者的基本信息；借阅信息：图书的借阅信息；帐号信息：图书管理员和读者的登录帐号；（2）系统用户：图书管理员、读者。图书管理员：对图书和读者数据可执行添加、修改、删除以及查询等操作。读者：可查询图书以及查询与本人相关的借阅信息。,“图书管理系统”需求分析报告（实例）,确定执行者 执行者是与系统交互的外部实体，它既可以是人员也可以是外部系统或硬件设备。确定执行者可以通过提出以下问题得到：谁使用系统的主要功能？谁需要系统的支持以完成日常工作任务？谁从系统获取信息？谁负责维护和管理系统以保证其正常运行？系统需要应付（处理）哪些外部硬件设备？系统需要和哪些外部系统交互？在本例中，可以确定“图书管理员”和“读者”为系统的执行者。“图书管理员”负责使用系统的主要功能，“读者”从系统中获取所需的信息。,“图书管理系统”需求分析报告（实例）,确定用例用例描述了一个完整的系统事件流程，其重点在于执行者与系统之间的交互而不是内在的系统活动，并对执行者产生有价值的可观测结果。确定用例可以通过提出以下问题得到：参与者需要从系统中获得什么功能？参与者需要做什么？参与者读取、产生、删除、修改或存储系统的某些信息吗？系统中发生事件需要通知参与者吗？参与者需要通知系统某件事情吗？系统的输入/输出信息是什么？这些信息从哪儿来到哪儿去？采用什么实现方法满足某些特殊要求？本例中我们通过一定的调研和分析得到的“图书管理系统”的用例图，如图3.1所示。,“图书管理系统”需求分析报告（实例）,图3.1 用例图,“图书管理系统”需求分析报告（实例）,编写用例文档用例图不能提供用例所具有的全部信息，因此需要使用文字描述那些不能放映在图形上的信息。用例文档是关于执行者与系统如何交互的规格说明，要求清晰明确，没有二义性。在描述用例时，应该只注重外部能力，不涉及内部细节。下面给出本例中的用例文档。,“图书管理系统”需求分析报告（实例）,1.图书信息的维护用例用例名：图书信息的维护参与执行者：图书管理员入口条件：图书管理员已经登陆到该系统中。,“图书管理系统”需求分析报告（实例）,事件流：当有新书入库时，图书管理员在录入页面输入书的信息，点击提交按钮，系统将书的信息保存到数据库中；当某一本图书的信息需要修改时，图书管理员通过输入查询条件，搜索出该书时，点击修改按钮，系统在可编辑状态显示图书的当前信息，图书管理员修改具体信息，点击保存按钮，系统将更新数据库中该书的信息；当需要删除一个或多个图书时，图书管理员查找到需要删除的图书记录，点击删除按钮，系统提示“确实要删除？”对话框，当管理员选择“是”，系统将删除数据库中相应图书的信息，反之，则不进行任何操作。,“图书管理系统”需求分析报告（实例）,出口条件：系统将数据库中的信息进行相应的操作：添加图书信息时，将新的图书信息保存在数据库中；修改图书信息时，将数据库中该图书的信息做相应的更新操作；删除图书信息时，则删除数据库中的相应图书记录。异常事件：在图书进行修改和删除时，先查出需要进行处理的图书记录，如果数据库中不错在符合条件的记录，查询无结果时，则无法进行修改和删除操作。,“图书管理系统”需求分析报告（实例）,2.读者信息的维护用例用例名：读者信息的维护参与执行者：图书管理员入口条件：图书管理员已经登陆到该系统中。,“图书管理系统”需求分析报告（实例）,事件流：当有新的读者时，图书管理员在录入页面输入读者的信息，点击提交按钮，系统将读者的信息保存到数据库中；当某一本读者的信息需要修改时，读者管理员通过输入查询条件，搜索出该读者信息时，点击修改按钮，系统在可编辑状态显示读者的当前信息，读者管理员修改具体信息，点击保存按钮，系统将更新数据库中该读者的信息；当需要删除一个或多个读者时，图书管理员查找到需要删除的读者记录，点击删除按钮，系统提示“确实要删除？”对话框，当管理员选择“是”，系统将删除数据库中该图书的信息，反之，则不进行任何操作。,“图书管理系统”需求分析报告（实例）,出口条件：系统将数据库中的读者信息进行相应的操作：添加读者信息时，将新的读者信息保存在数据库中；修改读者信息时，将数据库中该读者的信息做相应的更新操作；删除读者信息时，则删除数据库中的相应读者记录。异常事件：在进行修改和删除读者信息时，先查出需要进行处理的读者记录，如果数据库中不错在符合条件的记录，查询无结果时，则无法进行修改和删除操作。,“图书管理系统”需求分析报告（实例）,3.图书信息的查询用例用例名：图书信息的查询参与执行者：图书管理员、读者入口条件：无事件流：通过交互界面输入查询条件(如书名，作者名等)搜索图书记录。出口条件：若有符合条件的课程信息，则系统显示这些图书信息。否则系统提示用户重新输入查询条件。,“图书管理系统”需求分析报告（实例）,4.读者信息的查询用例用例名：读者信息的查询参与执行者：图书管理员入口条件：用户已经登陆到该系统中。事件流：通过查询界面输入查询条件(如读者证，读者姓名等)搜索待读者记录。出口条件：若有符合条件的读者信息，则系统显示读者信息。否则系统提示用户重新输入查询条件。,“图书管理系统”需求分析报告（实例）,5.查询个人基本信息用例用例名：查询个人基本信息参与执行者：读者入口条件：用户已经登陆到该系统中。事件流：点击查询个人基本信息按钮。出口条件：系统显示读者本人信息。,“图书管理系统”需求分析报告（实例）,6.查询个人借阅信息用例用例名：查询个人借阅信息参与执行者：读者入口条件：用户已经登陆到该系统中。事件流：点击查询个人借阅信息按钮。出口条件：系统显示读者的借阅信息。,“图书管理系统”需求分析报告（实例）,7.借书用例用例名：借书参与执行者：图书管理员、读者入口条件：图书管理员已经登陆到该系统中。事件流：图书管理员在借书页面，输入图书编号和读者证号，点击保存。出口条件：系统将这条借书记录保存到数据库中。异常事件：如果该图书未入库，数据库中不存在该图书编号，提示“该书未入库”；如果数据库中不存在该读者证号，也相应的做出提示。,“图书管理系统”需求分析报告（实例）,8.还书用例用例名：还书参与执行者：图书管理员、读者入口条件：图书管理员已经登陆到该系统中。事件流：图书管理员在还书页面，输入图书编号，点击还书。出口条件：系统将删除数据库中这条借书记录。异常事件：如果数据库中不存在这本书的借阅记录，提示“非本馆借出的图书”,如果该书已过期，也相应的做出提示。,“图书管理系统”需求分析报告（实例）,9.口令管理用例用例名：口令管理参与执行者：图书管理员、读者入口条件：用户已经登陆到该系统中。事件流：用户点击“修改密码”按钮，在口令修改页面输入新的密码，点击保存按钮。出口条件：数据库中的密码被修改成最新的密码。,“图书管理系统”需求分析报告（实例）,4.非功能需求4.1 性能需求 图书管理系统的使用者是图书管理员和在校学生。对于图书管理员的管理工作，性能要求不是很严格，但需要方便图书入库等操作。对于学生的图书借阅、查询等功能，对性能要求较高，一般需要达到并发数200以上。4.2 安全性需求 由于图书管理系统的图书量会非常大，所有在对这些图书导入和查询时要保证速度。在图书借阅过程中又要保证事务的完整性。对于整个系统，需要完整的权限控制，防止某些人恶意的攻击系统，修改原始记录。同时对于数据库中的数据需要定时备份，防止系统数据丢失。此外，系统要求用户在登陆时需要身份验证。,“图书管理系统”需求分析报告（实例）,5.故障处理在正常情况下，应不出错。一旦发生意外，比如掉电、网络不通等，应保证系统数据不会丢失。6.外部接口需求,