软件需求分析(案例)
需求分析建模实验报告
需求分析建模实验报告1. 引言需求分析是软件开发生命周期中非常重要的一个阶段，通过需求分析可以明确系统的功能和性能要求，并为后续的开发、测试、部署等工作提供基础。
在需求分析过程中，采用合适的建模方法有助于准确描述系统的需求，识别并解决潜在的问题。
本实验旨在通过需求分析建模实践，提高对需求分析过程和技术的理解和应用能力。
2. 实验目的- 掌握需求分析建模的基本概念和方法；- 学习使用UML建模语言描述系统需求；- 提高对需求获取、分析和建模能力。
3. 实验环境- 操作系统：Windows 10- 工具软件：Visual Paradigm4. 实验内容本实验选择一个实际案例进行需求分析建模，详情如下：4.1 项目背景某在线购物平台开发团队决定对其系统进行升级，以提供更好的用户体验和功能。
升级后的系统将包括商品浏览、购物车管理、订单管理等模块。
4.2 需求获取通过与平台运营团队沟通和观察用户行为，获取以下需求：1. 用户可以通过平台浏览商品，包括商品的名称、价格、库存等信息；2. 用户可以将商品加入购物车，并对购物车中的商品进行管理（增删改查）；3. 用户可以对购物车中的商品进行结算，生成订单，并选择支付方式；4. 用户可以查看历史订单和订单详情。
4.3 需求分析建模在实验过程中，通过Visual Paradigm工具进行建模，选择了以下几个UML图形进行需求分析建模：1. 用例图：用于识别和描述系统的功能需求，并展示功能间的关系；2. 类图：用于描述系统中的类和类之间的关系，以及类的属性和方法；3. 活动图：用于描述系统的业务流程，展示各个活动的先后顺序和逻辑关系。
4.4 实验步骤1. 利用Visual Paradigm创建新项目，选择用例图模板；2. 根据需求获取的内容，识别系统的功能需求，并创建相应的用例图；3. 根据用例图创建类图，描述系统中的类和类之间的关系；4. 根据用例图创建活动图，描述系统的业务流程；5. 验证建模结果的正确性和完备性。
软件需求分析案例
图书馆管理信息系统的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确定安全目标首先需要明确软件系统的安全目标，这些目标应该与系统的实际应用场景相关联。
例如，银行系统的安全目标可能是保护客户的账户信息和交易记录不被未经授权的访问或篡改。
识别潜在威胁根据确定的安全目标，需要识别出可能对系统造成威胁的各种因素。
这些威胁可能来自外部的攻击者、内部的恶意用户或系统的自身漏洞等分析安全需求针对每一种潜在的威胁，都需要分析相应的安全需求。
这些需求包括对威胁的检测能力、防护能力、响应能力等制定安全策略根据分析的安全需求，需要制定相应的安全策略。
这些策略包括对用户的身份认证、访问控制、数据加密、日志记录等验证与测试制定安全策略后，需要对其实施效果进行验证和测试。
软件需求分析案例
业务主管：对于业务人员提出的业务系统问题和 EMAIL 建立问题，需要由 业务主管来审核。业务主管被授权审核一类或者多类问题。
3
软件学院教学实践案例
IT 主管：负责审核本 IT 部门报给其他 IT 部门的问题。并对问题单的处理进 行管理。
动作执行者： 问题提交人员
状态来源：已受理
发生的动作 通过确认
约束条件 状态流向 操作提醒. 已解决关闭 无.
未通过确认，驳回给问题 处理人员
关闭
已受理
问题处理人员.
信息反馈 问题处理人员、选择链条上的所 有下级 IT 部门、问题提交人员 无
描述：对于一些无意义的问题直接关闭掉，问题终结。
状态来源：请求关闭、待分配
动作执行者：各级 IT 部门的问题分配人员
状态来源：未提交、待审核、审核中（来至下不同级别的 IT 部门）、已受理
（来至不同级别的 IT 部门）
发生的动作
约束条件 状态流向
操作提醒.
信息反馈
关闭
关闭
无.
问题提交人员，可选择相关人员
未解决关闭
未解决关闭
无.
问题提交人员，可选择相关人员
指派
已受理
问题处理人员
分公司系统管理员：负责 IT 问题管理和知识管理系统的管理工作，主要负 责分公司一级公司用户角色的指定。组织机构的管理。
问题提交人员：问题提交人员是指提交业务系统问题、网络问题、EMAIL 问题和 EMAIL 建立问题的人员。根据规定，问题提交人员只能提交指定类别的 问题。
问题分配人员：问题分配人员是 IT 部门负责问题分配的角色，他/她将所有 的问题分配给相关的问题处理人员。问题分配人员被授权分配一类或者多类问 题。
软件需求分析报告实例
需求分析说明书1. 引言 (3)1.1 编写目的 (3)1.2 项目风险 (3)1.3 预期读者和阅读建议 (5)1.4 产品范围 (5)1.5 参考文献 (5)2. 系统总体概述 (6)2.1 目标 (6)2.2 用户类和特性 (7)2.3 运行环境 (7)2.3.1 硬件环境 (7)2.3.2 软件环境 (7)2.4 设计和实现上的限制 (7)2.5 假设和约束(依赖) (7)2.5.1 产品的SEO排名 (7)2.5.3系统的安全 (8)3. 外部接口需求 (8)3.1 用户界面 (8)3.2 硬件接口 (8)3.3 软件接口 (8)3.4 通讯接口 (8)4. 系统特性 (9)4.1 说明和优先级 (9)4.2 激励／响应序列 (9)4.3 功能需求 (9)4.4 功能详述 (11)4.4.1以使用软件的汽车用户为例： (11)5. 其它非功能需求 (12)5.1 性能需求 (12)5.2 安全措施需求 (12)5.3 安全性需求 (12)5.4 操作需求 (13)5.5 软件质量属性 (13)5.6 业务规则 (13)5.7 用户文档 (13)6. 词汇表 (13)6.1 SSH (13)6.2 JA VA (13)6.3 MYSQL (13)7. 待定问题列表 (14)1. 引言1.1 编写目的本需求分析说明书对本项目第一阶段的内容进行分析，对需求细节和实现方式进行了较为详细的阐述。
本需求说明书供业务和科技部门人员、软件需求提供人员、软件的概要设计人员、软件的开发人员、软件的测试人员使用，并作为产品验收确认的依据。
需求分析是在可行性研究的基础上，将用户对系统的描述，通过开发人员的分析概括，抽象为完整的需求定义，再形成一系列文档的过程。
可行性研究旨在评估目标系统是否值得去开发，问题是否能够解决，而需求分析旨在回答"系统做什么"的问题，确保将来开发出来的软件产品能够真正满足用户的需要。
软件工程第3章 软件需求分析(终)
第3章软件需求分析案例3: 图书馆图书信息管理系统“图书馆管理系统”是借助计算机来完成图书馆日常管理工作，能提供借书帐号注册、登录功能，基于图书标题、图书编号、作者、出版社的查询，也可以同时多个选项进行同时查询提供图书状态的查询，如可借和不可借，完成借书登记、还书的登记，能帮助管理人员完成图书信息的管理，如图书信息的修改、新图书的增加、旧图书的删除，图书分类工作，从而使图书馆的日常工作信息化、快捷化，减轻图书馆管理工作的困难。
因此，“图书馆管理系统”对于图书馆的日常管理工作和信息化到至关重要的作用。
【知识导入】通过对本章节内容的学习，掌握软件需求分析的基本内容，需求分析的特征及评审。
能够完成项目的需求分析，确立正确的项目开发思路。
软件需求是一个项目的开端，是整个软件项目开发的基础。
即表示该软件经过可行性分析后确立有此需求，而开发该项目。
因此，需求分析在整个项目建设过程中至关重要，是项目开发的基石，基石的牢固程度决定了后期项目的进展以及项目开发完工后的产品质量的优劣，可以说需求分析的好坏直接影响到软件项目开发的成败。
软件需求是指用户对目标软件系统在功能、性能、行为、设计约束等方面的期望。
IEEE （美国电气和电子工程师协会）是这样对需求分析做定义的：①用户解决问题或达到系统目标所需要的条件②为满足一个协议、标准、规格或其他正式制定的文档，系统或系统构建所需满足和具有的条件或能力③将需求要求条件进行文档化描述。
这个概念全方位阐述了需求的概念，较完整的表达了软件需求的内涵和外延，便于用户的全面理解。
而需求分析最终就是通过对应用问题及其环境的分析与理解采用一系列的分析方法和技术将用户的需求逐步精确化、完全化、一致化，最终形成需求规格说明文档的过程。
系统分析阶段产生的系统规格说明书和项目规划是软件需求分析的基础，分析人员需要从软件的角度对其进行检查和调整，并在此基础上展开需求分析。
需求分析阶段的成果主要是需求规格说明书，该成果又是软件设计、编码、测试直至维护的主要基础。
软件需求分析报告实例
需求分析说明书1. 引言 (3)1.1 编写目的 (3)1.2 项目风险 (3)1.3 预期读者和阅读建议 (5)1.4 产品范围 (5)1.5 参考文献 (5)2. 系统总体概述 (6)2.1 目标 (6)2.2 用户类和特性 (7)2.3 运行环境 (7)2.3.1 硬件环境 (7)2.3.2 软件环境 (7)2.4 设计和实现上的限制 (7)2.5 假设和约束(依赖) (7)2.5.1 产品的SEO排名 (7)2.5.3系统的安全 (8)3. 外部接口需求 (8)3.1 用户界面 (8)3.2 硬件接口 (8)3.3 软件接口 (8)3.4 通讯接口 (8)4. 系统特性 (9)4.1 说明和优先级 (9)4.2 激励／响应序列 (9)4.3 功能需求 (9)4.4 功能详述 (11)4.4.1以使用软件的汽车用户为例： (11)5. 其它非功能需求 (12)5.1 性能需求 (12)5.2 安全措施需求 (12)5.3 安全性需求 (12)5.4 操作需求 (13)5.5 软件质量属性 (13)5.6 业务规则 (13)5.7 用户文档 (13)6. 词汇表 (13)6.1 SSH (13)6.2 JA VA (13)6.3 MYSQL (13)7. 待定问题列表 (14)1. 引言1.1 编写目的本需求分析说明书对本项目第一阶段的内容进行分析，对需求细节和实现方式进行了较为详细的阐述。
本需求说明书供业务和科技部门人员、软件需求提供人员、软件的概要设计人员、软件的开发人员、软件的测试人员使用，并作为产品验收确认的依据。
需求分析是在可行性研究的基础上，将用户对系统的描述，通过开发人员的分析概括，抽象为完整的需求定义，再形成一系列文档的过程。
可行性研究旨在评估目标系统是否值得去开发，问题是否能够解决，而需求分析旨在回答"系统做什么"的问题，确保将来开发出来的软件产品能够真正满足用户的需要。
软件需求分析报告
软件需求分析报告软件需求分析报告1.引言软件需求分析是软件开发过程中的重要环节，对于软件的功能、性能和接口需求进行全面的分析和明确，为软件开发提供指导和依据。
本报告旨在对XXX软件的需求进行详细的分析和说明，以帮助开发团队更好地理解和实现该软件。
2.需求概述XXX软件是一款针对XXX行业的管理软件，旨在帮助用户更高效地进行任务管理、资源分配和团队协作等工作。
主要特点包括任务管理、团队协作、权限管理、数据备份和安全性等方面。
3.功能需求（1）任务管理该软件需要提供丰富的任务管理功能，包括任务创建、任务分配、任务进度追踪、任务优先级设置等。
用户可以根据自己的工作需要快速创建任务，并能够通过任务面板清晰地了解任务的执行情况。
（2）团队协作为了提高团队协作效率，该软件需要提供团队协作功能。
用户可以邀请团队成员加入，并能够共享任务、文件和日历等信息。
团队成员可以及时沟通交流，并能够对任务进行评论和反馈。
（3）权限管理为了保护数据安全和保密性，该软件需要提供灵活的权限管理功能。
管理员可以根据团队成员的角色和职责，设置不同的权限等级。
例如，管理员可以设置某些敏感信息只有部分人员可见，同时限制某些操作只能由特定人员执行。
（4）数据备份为了防止数据丢失和意外损坏，该软件需要提供数据备份功能。
软件可以定期自动备份数据，并支持手动备份和恢复操作。
数据备份的频率和方式可以根据用户的需求进行配置，以保障数据的完整性和可靠性。
（5）安全性数据安全对于企业来说至关重要，因此该软件需要重视安全性需求。
软件需要采用安全的登录和身份验证机制，保障用户信息和数据的安全。
同时，软件需要支持数据传输加密和防止恶意攻击的功能，确保用户数据的安全性和完整性。
4.性能需求（1）响应时间软件在用户操作时应能快速响应，并且操作过程中的延迟应尽量减少。
用户在使用软件过程中不应感到明显的卡顿或等待。
（2）并发处理能力该软件将会有大量的用户同时进行任务管理和团队协作等操作，因此需要具备较好的并发处理能力。
- 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）确定系统的初始范围第一步是考虑这个系统的大的范围。