软件工程需求分析案例
软件工程案例分析
一、阅读下列系统需求陈述，回答问题1、问题2、问题3和问题4。
某银行准备开发一个网上信用卡管理系统CCMS，该系统的基本功能为：（1）信用卡申请。
非信用卡客户填写信用卡申请表，说明所要申请的信用卡类型及申请者的基本信息，提交CCMS登录。
如果信用卡申请被银行接受，客户会收到银行的确认函，并告知用户信用卡的有效期及信贷限额；否则银行会发送一封拒绝函给该客户。
客户收到确认函后，需再次登录CCMS ，用信用卡号和密码激活该信用卡。
激活操作结束后，CCMS将激活通知发送给客户，告知客户其信用卡是否被成功地激活。
（2）月报表生成。
在每个月第一天的零点，CCMS为每个信用卡客户创建一份月报表，对该客户上月的信用卡交易情况及交易额进行统计。
信用卡客户可以登录CCMS查看月报表，也可以要求CCMS提供打印出的月报表。
（3）信用卡客户信息管理。
信用卡客户的个人信息可以在 CCMS中进行在线的管理。
每个信用卡客户可以在线查询其个人信息。
（4）信用卡交易记录。
信用卡客户使用信息卡进行的每一笔交易都会记录在CCMS中。
（5）交易信息查询。
信用卡客户可以登录CCMS查询并核实其信用卡交易记录及交易额。
在系统的需求分析阶段，使用用例对系统需求建模。
表1—1和表1—2给出了其中两个用例的概要描述。
［问题1］）将表1—1和表1—2中的（1）~（10）填充完整。
［问题2］除了表1—1和表1—2给出的用例外，从上述系统陈述中还可以获取哪些由信用卡客户发起的用例？（给出用例名称即可）［问题3］用400字以内文字，简要说明用例获取的基本步骤。
［问题4］用例除了使用表1—1和表1—2所示的形式描述外，还可以使用UML的用例图来表示。
分别用50字以内文字，解释UML用例图中扩展用例和抽象用例的内涵。
二、阅读以下关于工作流系统性能分析的叙述，回答问题1、问题2和问题3。
某企业正在创建一个工作流管理系统，目前正处于过程定义阶段，即创建工作流模型阶段。
软件工程师经典案例解析
软件工程师经典案例解析软件工程师是现代社会中一种重要的职业，他们在软件开发和维护方面扮演着至关重要的角色。
在软件工程师的职业生涯中，经典案例的解析对于新手和经验丰富的人来说都是有益的。
本文将通过分析几个软件工程师的经典案例，来说明他们在面对问题时的解决方法和技巧。
案例一：系统故障排查某公司的信息管理系统在某天突然出现了故障，导致系统无法正常运行。
作为软件工程师，需要快速定位故障的原因，并提供解决方案。
初步排查后发现，故障出现在数据库连接上。
为了进一步确认问题，工程师查阅了系统的日志文件，并发现了一个新的警告信息。
通过对警告信息的分析，他发现是数据库连接的配置有误，导致系统无法正常访问数据库。
解决该问题的方案是修改数据库连接的配置文件，并重新启动系统。
在修改配置文件之前，工程师做好了备份工作，以避免修改过程中出现意外。
最终，系统成功地恢复正常运行。
这个经典案例告诉我们，在系统故障排查过程中，仔细分析日志文件是一种常见而有效的方法。
同时，备份工作也是至关重要的，以防止在解决问题的过程中造成更大的损失。
案例二：性能优化某电商网站的订单处理系统在高峰期出现了明显的性能问题。
作为软件工程师，需要找出性能瓶颈，并提供优化方案。
经过对系统进行监控和性能测试，工程师发现数据库查询操作是主要的性能瓶颈。
为了降低数据库查询的耗时，他采取了以下措施：1. 对查询语句进行优化：通过重新评估查询逻辑和使用索引等方法，提高了查询的效率。
2. 数据库缓存：使用缓存技术，将频繁查询的数据缓存到内存中，减少了数据库的压力。
3. 并发控制优化：通过合理的并发控制策略，避免了数据库锁等问题。
经过优化后，系统的性能得到了明显的提升，可以更好地应对高峰期的访问需求。
这个案例告诉我们，在面对性能问题时，需要全面分析系统的各个环节，并采取有针对性的措施。
同时，对关键操作进行优化和缓存可以有效提高系统的响应速度。
案例三：需求变更管理在软件开发过程中，需求变更是常见的。
软件工程案例_结构化方法的需求分析
案例—结构化方法的需求分析一、约定1．假定校园卡只对学生发行。
2．校园卡本身不保存除“卡号”以外的信息，卡号由系统按照序列号自动生成。
3．假定使用校园卡的场合只有食堂、商店及图书馆，而且，不允许透支消费。
4．系统功能从简，包括：不考虑校园卡的加密问题，不考虑诸如修改密码、挂失等配套功能，与特约商户按照POS机号逐日汇总后对帐，等等。
二、软件功能1．校园卡发行2．帐户管理2.1、充值2.2、取款2.3、注销2.4、查询帐户收支记录3．刷卡消费4．身份验证5．统计报表5.1、打印收支情况统计表5.2、打印特约商户对帐表三、数据流图1．顶层（图1）学习提示：▲顶层数据流图的基本意图是什么？2．第1层（图2）学习提示：▲自顶向下、逐层细化原则的运用▲下层数据流图的边界与上层数据流图保持一致▲关于数据存储▲关于数据字典3．第2层（图3、图4）学习提示：▲对数据流图的细化到什么程度为止。
四、数据字典1．数据流与数据存储的数据结构学习提示：▲规范描述每种数据流、每种数据存储的数据元素构成。
▲用词的规范，语法与语义的一致，同一数据结构（或数据元素）使用同一名称、不同数据结构（或元素）使用不同的名称。
2．数据元素对上述数据结构中出现每个数据项，逐个作出定义。
本案例省略具体内容，只对如下数据元素作出说明。
学习提示：▲哪些内容属于“数据元素”。
▲对于数据元素，需要定义哪些内容。
▲关于“元数据”的概念▲数据分析要求清楚描述每种业务单据之间的关联每个数据元素值的“来龙去脉”五、功能说明以“功能2.2—取款”为例说明▲功能简介（略）▲录入数据：取款单▲界面原型（略）▲前置条件《校园卡基本档案》存在与《取款单》中“卡号”相对应的记录。
▲对录入数据的约束规则●该档案记录的“密码”与《取款单》输入值一致。
●该档案记录的“当前状态”为“正常”。
●该档案记录的“帐户余额”值大于或者等于《取款单》的“取款金额”。
▲系统处理●新增《存取款记录》。
软件工程师经典案例分析
软件工程师经典案例分析在当今信息技术高速发展的时代，软件工程师作为一个热门职业，扮演着至关重要的角色。
他们的主要职责是设计、开发和维护计算机软件，为各行各业提供高效的解决方案。
在这篇文章中，我们将分析两个软件工程师的经典案例，展示他们在不同领域的卓越成就。
案例一：金融领域中的软件工程师张小明是一名在金融领域工作的软件工程师。
他的公司是一家顶尖的投资银行，为客户提供高效的金融服务。
在这个行业中，数据安全和交易速度非常重要。
张小明和他的团队负责开发和维护一种高速交易系统。
这个系统能够在毫秒级别处理巨大量的交易，并确保每一笔交易都是准确、安全的。
为了优化系统性能，张小明采用了多线程和高吞吐量的设计方案。
他还使用了各种技术工具来监测交易流程中的潜在问题，确保系统的可靠性和稳定性。
在一次重大交易中，张小明的系统无法处理大量的交易请求，导致交易延误。
面对这个严峻的挑战，他紧急修复了系统中的一个缺陷，并引入了负载均衡技术来提高系统的稳定性。
最终，他成功地解决了问题，并使系统在交易高峰期保持高效运行。
张小明的成功案例不仅体现了他出色的技术能力，还彰显了他在解决问题时的沟通和领导能力。
他和团队成员紧密合作，及时沟通，并采取必要的措施来解决问题。
这一优秀的案例成为金融行业中软件工程师的经典典范。
案例二：医疗领域中的软件工程师李华是一名在医疗领域工作的软件工程师。
他的公司专注于开发医疗信息管理系统，为医院提供全面的电子化解决方案。
在这个行业中，安全性和数据准确性是至关重要的。
李华负责设计和实施一种医疗信息管理系统，以提高病人信息的存储和访问效率。
他充分了解医疗行业的需求和规范，并从医院的角度出发，设计了一个安全、易用、可靠的系统。
在系统的实施过程中，李华面临一个复杂的挑战。
医院的各个部门和系统之间需要高效地共享数据，但数据源和数据格式千差万别。
为了解决这个问题，李华开发了一个强大的数据接口，能够将不同系统中的数据进行整合和转换，实现数据的无缝对接。
软件需求分析案例
业务主管：对于业务人员提出的业务系统问题和 EMAIL 建立问题，需要由 业务主管来审核。业务主管被授权审核一类或者多类问题。
3
软件学院教学实践案例
IT 主管：负责审核本 IT 部门报给其他 IT 部门的问题。并对问题单的处理进 行管理。
动作执行者： 问题提交人员
状态来源：已受理
发生的动作 通过确认
约束条件 状态流向 操作提醒. 已解决关闭 无.
未通过确认，驳回给问题 处理人员
关闭
已受理
问题处理人员.
信息反馈 问题处理人员、选择链条上的所 有下级 IT 部门、问题提交人员 无
描述：对于一些无意义的问题直接关闭掉，问题终结。
状态来源：请求关闭、待分配
动作执行者：各级 IT 部门的问题分配人员
状态来源：未提交、待审核、审核中（来至下不同级别的 IT 部门）、已受理
（来至不同级别的 IT 部门）
发生的动作
约束条件 状态流向
操作提醒.
信息反馈
关闭
关闭
无.
问题提交人员，可选择相关人员
未解决关闭
未解决关闭
无.
问题提交人员，可选择相关人员
指派
已受理
问题处理人员
分公司系统管理员：负责 IT 问题管理和知识管理系统的管理工作，主要负 责分公司一级公司用户角色的指定。组织机构的管理。
问题提交人员：问题提交人员是指提交业务系统问题、网络问题、EMAIL 问题和 EMAIL 建立问题的人员。根据规定，问题提交人员只能提交指定类别的 问题。
问题分配人员：问题分配人员是 IT 部门负责问题分配的角色，他/她将所有 的问题分配给相关的问题处理人员。问题分配人员被授权分配一类或者多类问 题。
软件工程师中的软件工程项目案例分析
软件工程师中的软件工程项目案例分析在当今信息技术高速发展的时代，软件工程项目扮演着日益重要的角色。
软件工程师不仅需要具备技术能力，还要善于分析各种项目，合理规划和管理软件开发过程。
本文将通过分析几个软件工程项目案例，探讨软件工程师在项目中的角色以及项目管理中的挑战和应对之策。
案例一：在线购物平台的开发某电商公司决定开发一款全新的在线购物平台，旨在吸引更多用户并提升销售额。
软件工程师在该项目中的角色主要有需求分析、系统设计、开发和测试。
首先，软件工程师需要与产品经理和业务团队紧密合作，全面了解用户需求，明确功能和技术要求。
其次，在需求分析的基础上，软件工程师应进行系统设计，包括数据库设计、模块划分和接口设计等。
在开发阶段，软件工程师需要根据系统设计开发出相应的功能模块，并进行功能测试和性能优化。
最后，软件工程师还需要协同测试团队对系统进行全面的测试，确保系统的稳定性和可靠性。
然而，在该项目中，软件工程师面临如下挑战：1.需求变更：由于市场竞争激烈，需求常常会发生变化，软件工程师需要及时响应变更并做好相应调整。
2.项目进度压力：开发一个功能完备的在线购物平台需要克服技术难题和人员协作问题，软件工程师需要有效地调度资源和时间，确保项目进度。
采用敏捷开发方法，灵活应对需求变更，将开发过程划分为多个迭代，迅速验证和调整需求。
2.团队协作：建立高效的团队协作机制，确保各成员间的沟通和协调。
3.项目管理工具：借助项目管理工具，合理规划和跟踪项目进度，及时发现和解决问题。
案例二：医疗信息管理系统的升级某医院决定对其现有的医疗信息管理系统进行升级，以提升医疗服务质量和工作效率。
软件工程师在该项目中的角色主要有系统需求分析、升级规划、开发和部署。
首先，软件工程师需要与医院管理部门和医务人员沟通，明确医疗信息管理系统的需求和改进方向。
其次，软件工程师需要对系统进行全面的需求分析，确定升级方案，并制定详细的规划计划。
在开发阶段，软件工程师需要针对升级需求进行代码编写和功能模块开发，并进行单元测试和综合测试。
软件工程师实战案例分析
软件工程师实战案例分析在软件工程领域，工程师们经常面临各种挑战和问题。
为了更好地理解软件工程实践中的实际情况，本文将通过分析一些具体的案例来探索软件工程师在实战中遇到的问题以及解决方案。
以下是两个典型案例的分析。
案例一：项目延期的风险管理背景：某公司开发了一个新的软件项目，计划在六个月内完成。
然而，在项目进行的过程中，出现了一系列的问题和挑战，导致项目面临延期的风险。
问题描述：1. 进度管理：项目进展缓慢，无法按时完成。
开发团队需要对项目进度进行有效管理，及时发现并解决潜在的延期风险。
2. 需求变更：项目初期需求未充分沟通和明确，导致在开发过程中频繁出现需求变更请求。
这增加了项目的复杂性和风险。
3. 资源调配：在项目进行过程中，缺乏充足的资源，导致开发团队无法按计划推进工作。
解决方案：1. 进度管理：使用敏捷开发方法，采用迭代式开发，将项目分解成小的任务，每个迭代取得一个可交付成果。
同时，使用项目管理工具进行进度跟踪和风险管理，及时识别潜在的延期风险并采取相应的措施。
2. 需求管理：在项目初期，与项目干系人充分沟通，明确和确认需求，确保需求准确无误。
在开发过程中，采用变更管理机制，严格控制需求变更，并根据变更的具体情况评估影响和风险，并及时与项目干系人沟通和协商。
3. 资源调配：通过合理的资源规划和调配，确保项目组有足够的资源来支持开发工作。
同时，建立良好的沟通渠道，在项目组内部以及与其他部门之间保持紧密合作，共同解决资源不足的问题。
案例二：团队协作和沟通的问题背景：某公司组建了一个软件开发团队，其中成员来自不同的背景和文化。
然而，在项目开展的过程中，团队成员之间存在团队协作和沟通的问题，导致项目进展受阻。
问题描述：1. 文化差异：团队成员来自不同的文化背景，导致彼此理解和沟通存在障碍。
2. 团队合作：团队成员之间合作不紧密，缺乏交流和协作。
3. 沟通方式：团队成员在沟通方式和习惯上存在差异，导致信息传递不畅，沟通效果不佳。
软件工程需求分析报告案例范文
软件工程需求分析报告案例范文1. 引言本文档是针对某公司新开发的在线购物平台项目的需求分析报告案例。
本报告的目的是明确项目的需求，并提供给开发团队和其他相关利益相关方，以便准确地开发和交付满足客户需求的产品。
2. 项目背景某公司计划开发一个在线购物平台，该平台旨在为用户提供一个方便、安全、友好的购物体验。
用户可以在平台上浏览和购买各种商品，并通过多种支付方式完成购买。
3. 需求概述3.1 用户需求平台主要面向普通用户，用户需求包括但不限于以下几点： - 用户可以浏览商品目录，包括商品名称、价格、描述等信息。
- 用户可以搜索商品，根据关键字或类别进行搜索。
- 用户可以添加商品到购物车，并在购物车中编辑商品数量、删除商品等操作。
- 用户可以选择合适的支付方式，如银行卡支付、支付宝支付等。
- 用户可以查看订单信息，包括订单编号、商品信息、订单状态等。
- 用户可以评价已购买的商品，并参与商品的评分和评论。
3.2 管理员需求除了用户需求外，平台还需要满足管理员的需求，以方便系统管理和运营。
管理员需求包括但不限于以下几点： - 管理员可以添加、编辑和删除商品，包括商品名称、价格、描述等信息。
- 管理员可以查看和处理用户的订单，包括确认订单、发货、取消订单等操作。
- 管理员可以管理用户账号信息，包括添加、编辑和删除用户信息。
- 管理员可以查看和统计销售数据、用户活跃度等信息。
4. 功能需求基于上述需求概述，我们将详细列出平台的功能需求，包括用户功能和管理员功能。
4.1 用户功能需求1.用户注册和登录：–用户需要提供有效的邮箱和密码进行注册，注册后可以登录平台。
–用户可以通过第三方账号（如微信、支付宝）登录。
2.商品浏览和搜索：–用户可以浏览商品目录，按照不同的分类进行查看。
–用户可以使用关键字搜索商品，系统将返回相关的商品结果。
3.购物车管理：–用户可以将商品添加到购物车，并随时查看购物车中的商品。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
11.假设你在一所职业高中工作，负责该校信息系统的建设与维护。
财务科长请你研究用学校拥有的微型计算机生成工资明细表和各种财务报表的可能性。
请详细描述你用结构化分析方法分析上述问题的过程。
答：通常，结构化分析过程包括问题定义、可行性研究和需求分析3个阶段。
下面分别叙述这3个阶段的分析过程。
（1）问题定义从何处着手解决财务科长提出的问呢？立即开始考虑实现工资支付系统的详细方案并动手编写程序，对技术人员无疑是很有吸引力的。
但是，在这样的早期阶段就考虑具体的技术问题，却很可能会是我们迷失前进的方向。
会计部门（用户）并没有要求在学校自己的计算机上实现工资支付系统，仅仅要求研究这样的可能性。
后者是和前者很不相同的问题，它实际上是问，这样做预期将获得的经济效益能超过开发这个系统的成本吗？换句话说，这样做值得吗？优秀的系统分析员还应该进一步考虑，用户面临的问题究竟是什么。
财务科长为什么想研究在自己的计算机上实现工资支付系统的可能性呢？询问财务科长后得知，该校一直由会计人工计算工资并编制财务报表，随着学校规模扩大工作量也越来越大。
目前每个月都需要两名会计紧张工作半个月才能完成，不仅效率低而且成本高。
今后学校规模将进一步扩大，人工计算的成本还会进一步提高。
因此，目标是寻找一种比较便宜的生成工资明细表和各种财务报表的办法，并不一定必须在学校自己的计算机上实现工资支付系统。
财务科长提出的要求，实际上并没有描述应该解决的问题，而是在建议一种解决问题的方案。
这种解决方案可能是一个好办法，分析员当然应该认真研究它，但是也还应该考虑其他可能的解决方案，以便选出最好的方案。
良好的问题定义应该明确地描述实际问题，而不是隐含的描述解决问题的方案。
分析员应该考虑的另一个关键问题，是预期的项目规模。
为了改进工资支付系统最多可以花多少钱？虽然没人明确提出来，但是肯定会有某个限度。
应该考虑下述3个基本数字：目前计算工资所花费的成本，新系统的开发成本和运行费用。
新系统的运行费用必须低于目前的成本，而且节省的费用应该能使学校在一个合理的期限内收回开发新系统时的投资。
目前，每个月有两名会计用半个月时间计算工资和编制报表，一名会计每个月的工资和岗位津贴共约2000元，因此，每年为此项工作花费的人工费约2.4万元。
显然，任何新系统的运行费用也不可能减少到小于零，因此，新系统每年最多可能获得的经济效益是2.4万元。
为了每年能节省2.4万元，投资多少钱是可以接受的呢？绝大多数单位都希望在3年内收回投资，因此，7.2万元可能是投资额的一个合理的上限值。
虽然这是一个很粗略的数字，但是它确实能使用户对项目规模有一些了解。
为了请客户（会计科和学校校长）检验分析员对需要解决的问题和项目规模的认识是否正确，以便在双方达成共识的基础上开发出确实能满足用户实际需要的新系统，典型地，分析员用一份简短的书面备忘录表达他对问题的认识，这份文档称为“关于系统规模和目标的报告书”（见表2.1）。
表2.1关于工资支付系统规模和目标的报告书关于系统规模和目标的报告书2002.12.26项目名称：工资支付。
问题：目前计算工资和编制报表的费用太高。
项目目标：研究开发费用较低的新工资支付系统的可能性。
项目规模：开发成本应该不超过7.2万元（±50%）。
初步设想：用学校自己的计算机系统生成工资明细表和财务报表。
可行性研究：为了更全面地研究工资支付项目的可能性，建议进行大约历时两周的可行性研究。
这个研究的成本不超过4000元。
校长和财务科经过研究同意了上述报告书，可以对工资支付项目进行更仔细的研究了。
（2）可行性研究可行性研究是抽象和简化了的系统分析和设计的全过程，它的目标是用最小代价尽快确定问题是否能够解决，以避免盲目投资带来的巨大浪费。
本项目的可行性研究过程由下述步聚组成。
①澄清系统规模和目标为了确保从一个正确的出发点着手进行可行性研究，首先通过访问财务科长和校长进一步验证上一阶段写出的“关于工资支付系统规模和目标的报告书”的正确性。
通过访问分析员对人工计算工资存在的弊端有了更具体的认识，并且了解到工资总数应该记入分类日记帐，显然，新工资支付系统不能忽略与分类帐系统的联系。
②研究现有的系统了解任何应用领域的最快速有效的方法，可能都是研究现有的系统。
通过访问具体处理工资事务的两名会计，可以知道处理工资事务的大致过程。
开始时把工资支付系统先看作一个黑盒子，图2.11所示的系统流程图描绘了处理工资事务的大致过程。
图2.11处理工资事务的大致过程处理工资事务的大致过程是，每月月末教师把他们当月实际授课时数登记在课时表上，由各系汇总后交给财务科，职工把他们当月完成承包任务的情况登记在任务表上，汇总后交给财务科。
两名会计根据这些原始数据计算每名教职工的工资，编制工资表、工资明细表和财务报表。
然后，把记有每名教工工资总额的工资表报送银行，由银行把钱打到每名教工的工资存折上，同时把工资明细表发给每名教职工。
接下来应该搞清楚图2.12中黑盒子（工资支付系统）的内容。
通过反复询问财务人员，可以知道现有的人工系统计算工资和编制报表的流程如下：接到课时表和任务表之后，首先审核这些数据，然后把审核后的数据按教职工编号排序并抄到专用的表格上，该表格预先印有教职工编号、姓名、职务、职称、基本工资、生活补贴、书报费、交通费、洗理费等数据。
接下来根据当月课时数或完成承包任务情况，计算课时费或岗位津贴。
算出每个人的工资总额之后，再计算应该扣除的个人所得税，应交纳的住房公积金和保险费，最后算出每个人当月的实发工资数。
把算出的上述各项数据登记到前述的专用表格上，就得到了工资明细表。
然后对数据进行汇总，编制出各种财务报表，而工资表不过是简化的工资明细表，它只包含工资明细表中的教职工编号、姓名和实发工资这3项内容。
图2.12所示的系统流程图描绘了现有的人工工资支付系统的工资流程。
必须请有关人员仔细审查图2.12所示的系统流程图，有错误就应该及时纠正，有遗漏就应该及时补充。
③导出高层逻辑模型系统流程图很好的描绘了具体的系统，但是，在这样的图中把“做什么”和“怎样做”这两类不同范畴的知识混在一起了。
我们的目标不是一成不变地复制现有的人工系统，而是开发一个能完成同样功能的新系统，因此，应该着重描绘系统的逻辑功能。
的数据排序教师课时表审核数据审核后职工任务表计算计算个人所得税计算工资总额课时费计算专用表格岗位津贴计算住房公积金计算保险费计算实发工资工资表报表编制报表工资明细表更新分类账教师职工分类账会计图2.12现有的工资支付系统删除图2.12中表示的有关具体实现方法的信息，把它抽象成图2.13。
在这张数据流程图中用“事务数据”代表课时表和任务表中包含的数据，用“加工事务数据”笼统地代表计算课时费、岗位津贴、工资总额、个人所得税、住房公积金、保险费、实发工资等一系列功能。
这张数据流图描绘的是系统高层逻辑模型，在可行性研究阶段还不需要考虑完成“加工事务数据”功能的具体算法，因此，没必要把它分解成一系列更具体的数据处理功能。
在图2.13中的处理框“更新分类账”虽然不属于本系统应完成的功能，但是，工资支付系统至少必须和“更新分类账”所在的系统通信，因此，搞清楚它门之间的接口要点是很重要的。
在数据流图上直接注明关键的定时假设很有必要。
在以后的系统设计过程中这些假设将起重要作用。
清楚地注明这些假设也可以增加及时发现和纠正误解的可能性。
④进一步确定系统规模和目标银行D3 D4现在，分析员再次访问会计和财务科长，讨论的焦点集中在图 2.13 所示的 数据流图，它代表了到现在为止分析员所要开发的系统认识。
通过仔细分析和 讨论数据流图，能够及时发现并纠正分析员对系统的误解，补充被他忽视了的 内容。
分析员现在对工资支付系统的认识已经比问题定义阶段深入多了，根据现 在的认识，可以更准确地确定系统规模和目标。
如果系统规模有较大变化，则 应及时报告给客户，以便做出新的决策。
可行性研究的上述 4 个步聚可以看作是一个循环。
分析员定义问题，分析这个 问题，导出试探性的逻辑模型，在此基础上再次定义问题······重复这 个循环直至得出准确的逻辑模型为止，然后分析员开始考虑实现这个系统的方案。
D1事务数据教师 1 收集 2 审核 3 加工事务 职工数据数据数据D2工资表 工资明细表 报表银行 定时假设4 分发工资 明细表5 更新 分类账处理 1 运行频率 每日一次 会计2 3 4 5每日一次 每日一次 每日一次 每日一次教师 职工图 2.13工资支付系统的数据流图⑤导出供选择的解法现在分析员对用户的问题已经有了比较深入的理解，但是，问题有行得通的解决方法吗？回答这个问题的唯一方法是，导出一些供选择的解决方法，并且分析这些解决的可行性。
导出共选择的解法的一个常用的简单方法是从数据流图出发，设想几个划分自动化边界的模式，并且为每种模式设想一个系统。
在分析供选择的解法时，首先考虑的是技术上的可行性。
显然，从技术角度看不可能实现的方案是没有意义的。
但是，技术可行性只是必须考虑的一个方面，还必须能同时通过其他检验，一种方案才是可行的。
接下来考虑操作可行性。
例如，在对学生开放的公共计算机房内运行工资支付程序显然是不合适的。
这样做不仅不安全而且会暴露教职工的个人隐私。
因此，必须为工资支付系统单独购置一台计算机及必要的外部设备，并且挡在一间专用房间里。
最后，必须考虑经济可行性问题，即“效益大于成本吗？”因此，分析员必须对已经通过技术可行性和操作可行性检验的解决方案再进行成本/效益分析。
为了给客户提供在一定范围内进行选择的余地，分析员应该至少提供3种类型的供选择的方案：低成本系统，中等成本系统和高成本系统。
如果把每月发一次工资改为每两个月发一次工资，则人工计算工资的成本大约可减少一半，即每年可节省1.2万元。
除了已经进行的可行性研究的费用外，不再需要新的投资，这是一个诱人的低成本方案。
当然，也必须充分认识上述低成本方案的缺点：违反常规；教职工反对；不能解决根本问题，随着学校规模扩大，人工处理工资事务费用也将成比例的增加。
作为中等成本的解决方案，建议基本上复制现有系统的功能：课时表和任务表交到处理工资事务的专用机房。
操作员把这些数据通过终端送入计算机，数据收集程序接收并校核这些事务数据，把它们存储在磁盘上。
然后运行工资支付程序，这个程序从磁盘中读取事务数据，计算工资，打印出工资表，工资明细表和财务报表。
图2.14所示的系统流程图描绘了上述系统。
图2.14中等成本方案的系统流程图上述中等成本方案看起来比较现实，因此对它进行了完整的成本/效益分析，分析结果列在表2.2中。