软件需求分析(案例)

软件需求分析(案例)内容摘要：

软件需求分析(案例) 案例 学管理系统（用例驱动的交互式需求获取）以一个教学管理系统 分析与设计作为示例，说明用例驱动技术在软件项目开发中的应用。 高等学校的教学管理内容十分丰富，工作繁多。 作为一个示例，规定开发教学管理系统 处理每学期的课程选修注册和学生的成绩管理。 教学管理系统 用户是学校的学生、教师和教学管理员。 学生使用 统查询新学期将开设的课程和授课教师的情况，选择自己要学习的课程，并进行登记注册。 学生还可以使用 统查询自己的课程成绩。 教师使用 统查询新学期将开设的课程、参加听课的学生情况，以及学生的考试成绩。 教学管理员使用 统进行教学管理，包括新学期的课程选课注册管理和学生成绩管理。 教学管理系统 求提供两个方面的服务:(1)选课管理，负责新学期的课程选课注册工作;(2)成绩管理，负责学生成绩管理。 在选课管理方面应填写的用户需求描述如下。 (1)录入与生成新学期课程表教学管理员在新学期开始前录入新学期课程，打印将开设的课程目录表，供师生参考选择。 若某课程的实际选课学生少于 10 人，则停开该课程，把该课程从课程目录表中删除;若某课程的选课学生多于 30 人，则停止选课。 (2)学生选课注册新学期开始前一周为选课注册时间，在此期间学生可以选课注册，并且允许改变或取消注册申请。 每个学生选课不超过 4 门课程。 每门课程最多允许 30 名学生选课注册。 学生可以在图书馆、各系资料室、学生宿舍等处的计算机上联网进行选课注册。 在选课注册结束后，教学管理员打印学生选课注册名单和开课通知书，送交有关部门和授课教师。 (3)查询可以查询课程信息、学生选课信息和学生、教师信息。 学生、教师、教学管理员可以查询课程表，获得课程信息。 查询的关键词以是:课程名，授课教师名，学分。 教师、教学管理员可以查询学生选课情况。 查询的关键词可以是:学生名、程名，授课教师名，学分。 学生只允许查询自己的选课信息，不允许查询别人选课信息。 学生、教师、教学管理员可以查询学生或教师的信息。 查询的关键词可以是学生名、教师名，性别、班级、职称。 (4)选课注册信息的统计与报表生成。 教学管理员对学生的选课注册信息进行统计(按课程，按学生，按班级 )，印汇总统计报表。 在成绩管理方面应填写的用户需求描述如下:(1)成绩录入:教学管理员录入学生考试成绩。 (2)成绩查询:教师、教学管理员可以查询学生考试成绩。 查询的关键词可以是:学生名、课程名、授课教师名、学分名、学生只允许查询自己的考试成绩，不允许查询别人的考试成绩。 (3)成绩统计与报表生成教学管理员进行成绩统计(按课程、学生、按班级 )，打印成绩汇总统计报表。 为保存数据，需建立教学管理数据库。 可以采用关系数据库，建立下列数据库表:学生表、教师表、课程表、选课表、任课表、成绩表。 教学管理系统的直接用户有学生、教师和教学管理员。 教学管理员有权操纵数据库的数据，进行添加、更新、删除等操作。 学生和教师一般只查询信息，只允许对自己有关的数据进行添加，更新、删除等操作。 教学管理系统 相关系统有财务系统。 统需要把学生选课注册信息传送给财务系统，以供财务系统计算学生应交纳的费用，但是不要求财务系统回馈学生应交纳的费用信息。 假定在学校的计算中心有功能强大的工作站机器，在各系、各部门、图书馆、学生宿舍都有台式 ，学校的全部计算机已经连网。 教学管理系统 采用客户机/ 服务器结构建立，统的应用服务器和数据库服务器设置在学校计算中心的工作站。 学生、教师和教学管理员可以在各系、各部门、图书馆、学生宿舍的台式 上使用 统。 学管理系统 于新学期课程的选课注册管理和学生的成绩管理。 凡是这两方面的教学管理内容都是 统的职责范围，其他的教学管理内容，如安排教学计划、排课、实习、实验、考试等都不属于 统的职责范围。 至于学校的其他管理工作，如科研、人事、财务、资产等管理不属于 统的职责范围。 统与财务系统存在系统边界，财务系统将从 统得到学生选课注册信息。 统与学校的其他信息管理系统没有直接的联系，但是可以从学校的全局数据库中共享学生、教师、教学计划等必要的数据。 统用户需求描述可以确定 4 个参与者:学生、老师、教学管理员和财务系统。 对于每一个参与者，应当明确其业务活动的内容、对系统的服务要求。 “学生”参与者使用 统查询新学期开设的课程信息和教师开课信息，选课并登记注册课程，查询自己的课程成绩信息。 “老师”参与者使用 统查询新学期开设的课程信息、学生选课信息和学生成绩信息。 “教学管理员”参与者使用 统管理学期开设的课程的选课注册和学生的考试成绩。 管理工作包括课程与成绩数据的录入、维护、统计、报表打印等，并且负责把学生的选课注册信息发送给财务系统，作为计算学生应付费用的依据。 “教学管理员”要求能够方便地查询课程信息、学生选课信息、学生信息、教师信息和成绩信息。 “财务系统”参与者是外部系统参与者，从 统接受学生的课程注册信息。 4. 获取每一个 是一个参与者与系统在交互中执行的有关事务序列。 应当根据用户需求描述，找出全部的 从参与者的角度给出事件流，当 行时系统应提供给参与者的服务。 从 用户需求描述分析可的有以下用例存在 :(1)查询课程信息:学生、教师或教学管理员查询课程表，获得课程信息。 (2)选课注册:学生登录进行选课注册。 (3)管理开设课程:教学管理员登录系统产生选课信息，按照要求进行分类统计，生成选课注册报表。 (4)管理学生信息:教学管理员对学生数据进行录入、修改、删除等操作。 (5)管理老师信息:教学管理员对教师数据进行录入、修改、删除等操作。 (6)管理课程信息:教学管理员对课程数据进行录入、修改、删除等操作。 (7)查询学生成绩:学生、教师查询学生成绩。 (8)查询课程成绩:学生、教师查询课程成绩。 (9)学生成绩管理:教学管理员对学生考试成绩数据进行录入，修改、删除等操作。 (10)成绩统计: 教学管理员对学生的考试成绩数据进行分类统计，生成成绩报表。 ）（2）（3 ）（4）（5）（6 ）（7 ）东省水利厅办公业务资源系统广东省水利厅办公业务资源系统是一个面向 300 多用户以及 10 多个部门日常业务流程的项目, 由于系统牵涉的用户面和业务范围较广, 系统的各种功能与用户的日常工作息息相关,因此做好系统需求分析显得至关重要。 项目需求调研阶段,始终坚持“以用户为中心”,采取了有效、多样的方式与用户沟通, 充分重视用户提出的每一项需求,并根据实际情况采用各种技术手段与用户进行沟通以最大限度获得需求。 (1)系统功能和性能需求分析分析总结旧系统功能和性能方面存在的问题和缺陷对于获取新系统的需求具有很大参考价值。 经过研究分析,水利厅原有办公自动化系统存在几个突出的问题: 技术手段比较落后。 如采用 C/S 的模式一方面随着用户量增加导致服务器负载过高,服务器性能明显下降;另一方面系统管理员的维护工作量很大,系统版本更新后需要重新更新各客户端程序;系统的跨平台性和移植性差。 旧系统是基于 台开发,未来想移植到 者 作系统上困难很大；工作流固化用户实际流程与默认流程不符时需手工重新配置流程,导致系统推广应用难度大;可供办公使用的信息资源少。 基于以上分析,可得出新系统的功能和性能方面基本要求如下:功能主要包括公文处理子系统、内部电子邮件、机关事务管理子系统、业务资源库等。 性能及约束条件方面要求主要包括跨平台性、易维护性、稳定性、响应速度等。 技术方面要求采用 台和关系型数据库 (现,基于 B/S 的三层体系结构进行设计。 (2)需求信息来源分析通过对需求信息的来源进行分析,得出如下需求捕获计划(见表 1)。 (3)需求分析技术的选用用户调查。 在直接与用户进行面对面交流前,先对旧系统用户作一个书面调查,收集他们对旧系统的使用体会以及对新系统最关心的功能需求,目的是在面对面进行用户访谈时提高需求分析人员提问的针对性和引导作用。 需求调研表涉及的主要内容包括:用户使用频度最高的功能、旧系统设计存在的主要不足、对系统改进的建议等,调查对象为全体用户。 通过收集用户的信息反馈表并进行归纳总结,得出以下几个结论:用户使用频率最高的模块主要是公文收发处理、内部电子邮件、公告发布;旧系统最大的不足主要集中在系统界面不够友好、系统响应速度越来越慢、流程设计不灵活、系统可供办公参考的资料较少等几个方面。 用户访谈。 经过用户调查后,通过组织用户进行面对面访谈来达到细化系统需求的目的。 访谈的对象主要是典型业务处室代表,如办公室负责文件收发的秘书、关键业务部门、技术部门的代表。 进行访谈前要根据用户调查的结果设计一些有针对性和引导作用的问题,如:公文收发的流程是怎样的(办公室代表回答 )?在业务处室内部处理的流程是怎样的(业务处室代表回答)?系统界面的人性化方面有哪些要求(全体代表回答)? 系统管理方面的需求是什么(技术部门代表回答)? 参观考察。 为了吸取兄弟单位同类项目的先进经验,开拓思路,组织用户到一些有成功案例和良好口碑的单位进行参观考察。 通过参观考察,博取众长,将各单位有价值的好的经验和做法吸纳到本系统的建设需求中来。 (4)几种需求分析技术对比用户调查覆盖的面较广(涉及到本单位 300 多用户),不需要占用被访用户太多工作时间,容易被用户接受。 但是由于某些用户对用户调查的重视程度不够,导致所反馈的信息不全面,参考价值有限 ,只能作为需求分析技术的一种参考和补充手段。 用户访谈对于本系统需求分析是一种收效较好的技术手段。 但是这种技术的使用对于需求分析人员来说有较高要求,如谈话技巧、领域的知识面等;另一方面寻找一个各关键被访对象均有空的时间较难。 在条件允许的情况下,应尽量采用这种技术。 参观考察对系统需求获取可以起到画龙点睛、开阔用户思路、取长补短的效果。 案例 3：学院房产管理系统1. 开发背景：行政学院房地产管理系统是在金融体制改革的形势下，由行政学院信息技术部承担开发的，在成都市范围内进行房产投资和管理的应用系统。 系统的应用范围包括跟踪资本的分配和划拨、所产生的资产现金流和这些现金流的来源，以及计算所有投资的回报情况的能力。 该系统不仅使这些资产可以像管理固定收入有价证券组合一样被管理，也为学校领导层提供了监控资金流量与流向并及时做出相应决策的现代化手段。 2. 使用用例驱动获取需求：（1 ） 确定系统的初始范围第一步是考虑这个系统的大的范围。 通过与项目有关人员（主要是用户）的大量交流沟通，以及组织多次访谈会，首先根据系统的作用，用户的最基本要求确定了系统的初始范围，如图 18 所示。 （2 ） 确定参与者确定了三个参与者：经营经理、房产经理和外部合作伙伴。 1）经营经理：负责数据录入和数据维护。 经营经理创建报表，以提供有关房产的管理信息，并保证考虑到房产的日常问题。 2）房产经理：负责管理自己掌握的资金用于房地产投资。 房产经理要确定准备投资的各种类型的房地产项目。 这种参与者主要关注投资所需的资本和投入的资本与所产生的回报的比较。 3）外部合作伙伴：外部合作伙伴与房产经理起类似的作用，不过是在机构的外部。 外部合作伙伴参与房产，但是在很多方面可以斟酌决定。 外部合作伙伴的主要责任是保证投资产生回报，还需要向房产经理定期提供信息，包括现金流、对帐单和回报信息。 （3 ） 获取用户需求与关键项目的相关人员一起，经过大量的分析讨论，确定了两个基本用例。 用例 1 管。