软件需求分析(案例)
软件工程师经典案例解析

软件工程师经典案例解析软件工程师是现代社会中一种重要的职业,他们在软件开发和维护方面扮演着至关重要的角色。
在软件工程师的职业生涯中,经典案例的解析对于新手和经验丰富的人来说都是有益的。
本文将通过分析几个软件工程师的经典案例,来说明他们在面对问题时的解决方法和技巧。
案例一:系统故障排查某公司的信息管理系统在某天突然出现了故障,导致系统无法正常运行。
作为软件工程师,需要快速定位故障的原因,并提供解决方案。
初步排查后发现,故障出现在数据库连接上。
为了进一步确认问题,工程师查阅了系统的日志文件,并发现了一个新的警告信息。
通过对警告信息的分析,他发现是数据库连接的配置有误,导致系统无法正常访问数据库。
解决该问题的方案是修改数据库连接的配置文件,并重新启动系统。
在修改配置文件之前,工程师做好了备份工作,以避免修改过程中出现意外。
最终,系统成功地恢复正常运行。
这个经典案例告诉我们,在系统故障排查过程中,仔细分析日志文件是一种常见而有效的方法。
同时,备份工作也是至关重要的,以防止在解决问题的过程中造成更大的损失。
案例二:性能优化某电商网站的订单处理系统在高峰期出现了明显的性能问题。
作为软件工程师,需要找出性能瓶颈,并提供优化方案。
经过对系统进行监控和性能测试,工程师发现数据库查询操作是主要的性能瓶颈。
为了降低数据库查询的耗时,他采取了以下措施:1. 对查询语句进行优化:通过重新评估查询逻辑和使用索引等方法,提高了查询的效率。
2. 数据库缓存:使用缓存技术,将频繁查询的数据缓存到内存中,减少了数据库的压力。
3. 并发控制优化:通过合理的并发控制策略,避免了数据库锁等问题。
经过优化后,系统的性能得到了明显的提升,可以更好地应对高峰期的访问需求。
这个案例告诉我们,在面对性能问题时,需要全面分析系统的各个环节,并采取有针对性的措施。
同时,对关键操作进行优化和缓存可以有效提高系统的响应速度。
案例三:需求变更管理在软件开发过程中,需求变更是常见的。
软件需求分析案例

图书馆管理信息系统的2层数据流程图有: 图书馆管理信息系统的 层数据流程图有:图书 层数据流程图有 采编系统数据流程图、图书借阅系统数据流程图、 采编系统数据流程图、图书借阅系统数据流程图、 图书查询系统数据流程图、 图书查询系统数据流程图、图书预定系统数据流 程图、读者留言系统数据流程图、 程图、读者留言系统数据流程图、图书维护系统 数据流程图、 数据流程图、读者管理系统数据流程图和电子读 物系统数据流程图。 物系统数据流程图。
3
n
有指定的图书馆工作人员来帮助顾客像使用一般 书目索引一样使用基于电脑的工具。 书目索引一样使用基于电脑的工具。图书馆也必 须联网到其他的图书馆,以满足馆际互借的要求。 须联网到其他的图书馆,以满足馆际互借的要求。 这些相互连接的图书馆允许顾客可以直接访问它 们的馆藏。 们的馆藏。 图书馆工作人员的最后职责是获取和淘汰馆 藏图书。在获取新书的过程中, 藏图书。在获取新书的过程中,他们试图在满足 顾客的要求和达到广泛的收集之间取得平衡。 顾客的要求和达到广泛的收集之间取得平衡。当 图书的内容已经过时并且没有历史价值时, 图书的内容已经过时并且没有历史价值时,这本 图书将被淘汰。理想情况下,当一本书过时后, 图书将被淘汰。理想情况下,当一本书过时后, 它只有在一本内容更新的书在馆藏中代替它时才 会被淘汰。 会被淘汰。
19
n
n n n n n n
n
数据项组成: 借阅日期)+ 数据项组成:OrderDate (借阅日期)+ BookName(书名)+ )+RederID(读者账号)+ (书名)+ (读者账号)+ ReaderName(读者姓名)+ )+O_Quantity(借阅 (读者姓名)+ ( 数量) 数量) 数据流量: 数据流量:1000部/日 部日 高峰流量: 高峰流量:5000部/日 部日 数据流编号: 数据流编号:D03 数据流名称: 数据流名称:填写借阅记录 简述: 简述:填入借阅表的记录 数据流来源: 数据流来源:P2_13 检查合格的借阅图书信息录人 到借阅库中 数据流去向: 数据流去向:借阅库
软件安全需求分析

《软件安全需求分析》xx年xx月xx日CATALOGUE目录•软件安全需求概述•识别安全需求•分析安全需求•验证安全需求•管理安全需求•实践案例分析01软件安全需求概述软件安全需求是关于软件系统在面对潜在的威胁或攻击时,为确保系统的机密性、完整性和可用性而提出的一系列要求。
这些要求包括对系统进行安全防护、检测和响应的能力。
重要性随着信息技术的快速发展和广泛应用,软件系统面临着越来越多的安全威胁。
确保软件系统的安全性已经成为信息安全领域的重要任务之一。
软件安全需求分析是确保软件系统安全性的关键步骤之一,它能够识别潜在的安全威胁,提出相应的安全措施,降低或消除潜在的安全风险。
定义定义与重要性VS安全需求与功能需求的关系安全需求是功能需求的一部分安全需求是软件系统在功能方面的一种表现,它与功能需求密切相关。
一个安全的软件系统需要满足一系列的安全标准或规范,而这些标准或规范可以转化为具体的功能需求。
安全需求与功能需求的区别虽然安全需求与功能需求有密切的联系,但它们之间也存在一些区别。
功能需求关注的是系统应该做什么,而安全需求关注的是系统如何保护自己和用户的信息不受攻击或损害。
在软件开发过程中,需要将安全需求与功能需求结合起来考虑,以确保软件系统的安全性和可用性。
0102确定安全目标首先需要明确软件系统的安全目标,这些目标应该与系统的实际应用场景相关联。
例如,银行系统的安全目标可能是保护客户的账户信息和交易记录不被未经授权的访问或篡改。
识别潜在威胁根据确定的安全目标,需要识别出可能对系统造成威胁的各种因素。
这些威胁可能来自外部的攻击者、内部的恶意用户或系统的自身漏洞等分析安全需求针对每一种潜在的威胁,都需要分析相应的安全需求。
这些需求包括对威胁的检测能力、防护能力、响应能力等制定安全策略根据分析的安全需求,需要制定相应的安全策略。
这些策略包括对用户的身份认证、访问控制、数据加密、日志记录等验证与测试制定安全策略后,需要对其实施效果进行验证和测试。
系统软件需求和需求分析说明书模板(用例图+界面+文档)

1系统需求和需求分析说明书模板Mohit系统需求和需求分析说明书模板第一部分概述1.项目名称及背景➢项目名称➢开发背景2.文档说明第二部分任务说明1.功能概述2.用户环境浏览器(如IE 6以上版本)+网络开发(生产)环境:第三部分需求分析1.实现功能➢系统用例图用户业务逻辑如下图所示:95➢管理员功能清单功能编号功能名称文中标题编号备注101 人事管理101001 机构管理101002 部门管理101003 员工管理➢普通用户功能清单2.用例说明➢ [用例1] ●用例图●描述●参与者➢[用例2] ●用例图●描述●参与者➢[用例3] ●用例图●描述●参与者➢[用例4] ●用例图●描述●参与者➢[用例5] ●用例图●描述●参与者➢[用例6 ●用例图●描述●参与者➢[用例7] ●用例图●描述●参与者➢ [用例8]●用例图●描述●参与者➢ [用例9]●描述文件搜索功能:可以按条件查询需要的文件。
●参与者//*参与者,参与用例的对象*// ➢[用例10]●用例图发送消息消息管理管理消息●描述消息管理主要包括:创建消息、修改消息、删除消息、发布消息。
●参与者//*参与者,参与用例的对象*// ➢[用例11]●用例图●描述●参与者➢[用例12] ●用例图●描述●参与者➢[用例13] ●用例图●描述●参与者➢[用例14]●用例图●描述●参与者3.用例关系附1.2 系统设计说明书模板系统设计说明书版本历史第一部分概述1.文档说明2.系统需求概述第二部分系统总体结构第三部分系统设计类图//*系统中主要的、关键实体类图,参考图如下*//➢[用例1]实现●时序图//用例1的时序图,参考图如下*//●描述界面设计1.公共模块界面设计说明:页面设计要求尽量使用div布局完成。
所有的GridView要求实现分页功能。
图1.1用户登陆首页用户登陆首页要求:只有当用户名、密码都正确时才能通过验证。
107图1.2 管理员登录后看到的主界面管理员登录后的主页面要求:显示个人便签信息,左侧显示系统菜单和个人基本信息,上标栏有“主页”、“重新登录”、“修改密码”、显示当前时间功能。
软件需求分析案例

业务主管:对于业务人员提出的业务系统问题和 EMAIL 建立问题,需要由 业务主管来审核。业务主管被授权审核一类或者多类问题。
3
软件学院教学实践案例
IT 主管:负责审核本 IT 部门报给其他 IT 部门的问题。并对问题单的处理进 行管理。
动作执行者: 问题提交人员
状态来源:已受理
发生的动作 通过确认
约束条件 状态流向 操作提醒. 已解决关闭 无.
未通过确认,驳回给问题 处理人员
关闭
已受理
问题处理人员.
信息反馈 问题处理人员、选择链条上的所 有下级 IT 部门、问题提交人员 无
描述:对于一些无意义的问题直接关闭掉,问题终结。
状态来源:请求关闭、待分配
动作执行者:各级 IT 部门的问题分配人员
状态来源:未提交、待审核、审核中(来至下不同级别的 IT 部门)、已受理
(来至不同级别的 IT 部门)
发生的动作
约束条件 状态流向
操作提醒.
信息反馈
关闭
关闭
无.
问题提交人员,可选择相关人员
未解决关闭
未解决关闭
无.
问题提交人员,可选择相关人员
指派
已受理
问题处理人员
分公司系统管理员:负责 IT 问题管理和知识管理系统的管理工作,主要负 责分公司一级公司用户角色的指定。组织机构的管理。
问题提交人员:问题提交人员是指提交业务系统问题、网络问题、EMAIL 问题和 EMAIL 建立问题的人员。根据规定,问题提交人员只能提交指定类别的 问题。
问题分配人员:问题分配人员是 IT 部门负责问题分配的角色,他/她将所有 的问题分配给相关的问题处理人员。问题分配人员被授权分配一类或者多类问 题。
软件需求追踪(案例)

软件需求追踪(案例)1. 引言本文档旨在追踪和记录软件项目的需求,以确保项目开发过程中的需求管理和控制。
通过有效的需求追踪,可以提高软件开发项目的质量和效率,以满足客户的需求和期望。
2. 案例背景本案例涉及一家电子商务公司,他们计划开发一个新的在线购物平台。
该平台旨在提供用户友好的界面,方便用户搜索和购买商品。
为了实现这一目标,公司决定采用软件需求追踪来管理他们的项目。
3. 需求追踪过程需求追踪过程包括以下几个关键步骤:3.1 需求识别在需求识别阶段,团队与客户沟通并确定项目的关键需求。
这些需求可能包括用户界面设计、产品功能、性能要求等。
3.2 需求分析和规范在需求分析和规范阶段,团队详细分析需求,并将其规范化为可量化和可测量的要求。
这些要求将用于后续的需求验证和测试。
3.3 需求验证在需求验证阶段,团队使用合适的方法和工具验证需求的正确性和完整性。
这可以通过原型、模型、用户反馈等方式进行。
3.4 需求跟踪在需求跟踪阶段,团队追踪和记录每个需求的状态和实现情况。
这有助于确保项目在开发过程中满足客户的需求,并及时进行调整和优化。
4. 工具支持为了更好地实施需求追踪过程,团队可以使用专门的软件工具来辅助需求管理。
常见的工具包括需求管理系统、跟踪表格和项目管理软件。
5. 结论软件需求追踪在项目开发中起到至关重要的作用。
通过识别、分析、验证和跟踪需求,可以确保项目按时交付、符合客户的期望,并提高项目的质量和可靠性。
电子商务公司应该充分利用需求追踪来管理他们的在线购物平台项目,以实现成功的软件开发。
软件需求分析报告(模板)

软件需求分析报告—(模板)目录1. 范围 02。
总体要求 02。
1总体功能要求 02。
2软件开发平台要求 02。
3软件项目的开发实施过程管理要求 (1)2.3.1 软件项目实施过程总体要求 (1)2.3.2 软件项目实施变更要求 (1)2。
3.3 软件项目实施里程碑控制 (1)3. 软件开发 (2)3.1软件的需求分析 (2)3.1。
1 需求分析 (2)3.1.2 需求分析报告的编制者 (3)3.1。
3 需求报告评审 (3)3.1。
4 需求报告格式 (3)3.2软件的概要设计 (3)3。
2。
1 概要设计 (3)3。
2。
2 编写概要设计的要求 (3)3.2.3 概要设计报告的编写者 (3)3。
2.4 概要设计和需求分析、详细设计之间的关系和区别 (3)3。
2.5 概要设计的评审 (3)3.2.6 概要设计格式 (3)3.3软件的详细设计 (4)3。
3。
1 详细设计 (4)3.3.2 特例 (4)3。
3。
3 详细设计的要求 (4)3.3.4 数据库设计 (4)3。
3.5 详细设计的评审 (4)3。
3。
6 详细设计格式 (4)3.4软件的编码 (4)3。
4。
1 软件编码 (4)3。
4.2 软件编码的要求 (4)3.4.3 编码的评审 (5)3.4。
4 编程规范及要求 (5)3.5软件的测试 (5)3.5.1 软件测试 (5)3。
5。
2 测试计划 (5)3.6软件的交付准备 (5)3。
6。
1 交付清单 (5)3.7软件的鉴定验收 (6)3。
7.1 软件的鉴定验收 (6)3.7。
2 验收人员 (6)3.7。
3 验收具体内容 (6)3。
7。
4 软件验收测试大纲 (6)3.8培训 (6)3。
8。
1 系统应用培训 (6)3.8.2 系统管理的培训(可选) (7)附录A 软件需求分析报告文档模板 (9)附录B 软件概要设计报告文档模板 (21)附录C 软件详细设计报告文档模板 (33)附录D 软件数据库设计报告文档模板 (43)附录E 软件测试(验收)大纲.................................................................... 错误!未定义书签。
软件工程第3章 软件需求分析(终)

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