软件测试需求分析与定义方法

第一篇：软件测试需求分析与定义方法

软件测试需求分析与定义方法

如何确定测试工作的范围？

对于一个存在生命周期的软件产品来说，它的开发和测试往往都不是一次性的，因为随着新的需求的出现，以及对原有版本的改进，新的版本会不断的发布（即使对于一些以客户定制方式运作的项目，在开发过程中以及发布后的维护期内，也会产生众多的内部版本）。随着版本的迭代，我们的测试工作也会一直继续下去。而在每一次迭代时，可能在整个工作阶段的开始就受到一些因素的影响，比如市场需求、既定的发布时间、并发的工作导致的资源紧张等等，使我们不得不考虑对软件质量要求的适度，最终使得我们在每个阶段的测试工作的要求或者说所涉及到的内容有可能是不同的。这种变化，最终将会影响到测试需求的确定。那么到底该如何确定每次迭代是测试工作的范围呢？在笔者的实践中，通常把测试工作范围的确定，等价的认为是软件需求的确定。

不过现在有一个很实际的问题是这样：软件需求在开发过程中不断发生变化，有时候到了后期还会有新的需求添加进来，还有些需求在交付内部测试版本之后又发现原来的需求本身就存在缺陷，之后再次返工，在软件最终发布之前，怎么可能确定的下来呢。啊，这些都是让我们的开发人员和测试人员极其头痛的事情。到底应该怎样在频繁变更的需求中确定哪些部分是我们在某个阶段要测试的内容呢？或者说通过什么样的方法可以改善我们上面提到的那些问题呢？一个实际的做法就是实现软件需求的版本化控制。（用软件需求的版本化控制来解决软件需求的频繁变更）既然说到了这里，就不免要说些题外话。笔者一直都认为软件需求是开发工作和测试工作在制定计划、开展工作时所共同参照的源头和依据，而我们只有在源头上控制好，才能保证下面工作的平稳开展。如果希望某个阶段工作的进度和内容可以明确的定义下来，就必须要考虑软件需求的版本化控制。这里所提到的“软件需求的版本化控制”，是指在一个软件产品的生命周期中，当要进行一个新版本的迭代时，要尽早的确定这个版本中将要实现的需求，并同上个版本做出比较，哪些内容是新增的，哪些内容是被调整过的。在该阶段工作开始之初的工作会议上，明确的向所有需要了解软件需求的涉众传达这部分信息。而如果在该版本的开发过程中不断的出现需求变更的情况，则应该根据市场策略、已公布的发布时间、客户需求、实现的代价、难易程度以及对现有工作的影响等方面，对需求进行适度划分，严格定义当前版本中需要实现的需求，而其他部分，则作为未来版本的软件需求进行考虑。如果有的朋友认为上面的内容还是太理论化，需要一个更实际的、可操作的方法。那么只能说，对于需求的变更，以及因为需求变更而引起的设计的变更，必须要早发现，早讨论，早决定，早调整。这可能更多的要依靠一个团队中相关负责人员的主动工作来保证，而不是依靠一个明确的方法。注意，这里的一个关键是，对于软件需求，同样需要严格按照版本进行管理，或者说使用“基线”进行管理。如何整理测试需求？一旦当前阶段测试工作的范围确定下来，我们就可以开始考虑测试需求的整理——也就是明确的定义现阶段要“测什么”。测试需求的确定将为我们制定进度时间表、分配资源以及如何确定某个阶段测试工作是否完成提供一个可供衡量的标准。当然，还有更重要的一点，已被确定的测试需求是我们进行测试用例设计和考虑测试覆盖的依据。整理测试需求的第一步，就是要“测试需求”。测试需求？对，不知道您是否想到，这里的“测试需求”中的“测试”是一个动词，指的是对软件需求本身的检查。

啊？这不是已经超出了测试工作的范围了吗？测试人员不是应该只关心软件的实现同需求是否相符吗？这样对测试人员要求未免太高了。——这是笔者过去同一些朋友谈到测试人员必须对需求进行检查时听到的一些不同的声音。在这里，首先要明确一个问题，就是软件测试的工作到底做什么？

在《软件测试》（Ron Patton〔美〕，中文版由机械工业出版社出版，这本书是测试新手入门的经典教材）一书的第10页，有一个明确而简洁的定义：软件测试员的目标是找到软件缺陷，尽可能早一些，并确保其得以修复。

瞧！这里说要“尽可能早”的“找到软件缺陷”。那这“尽可能早”要早到什么时候呢？

不知道大家对《软件工程》这本书还有什么印象。至少在笔者看过的多个不同版本的软件工程方面的书中，对于软件缺陷都会有一段类似的描述：缺陷发现的越早，则修复这个缺陷的代价就越小，在需求、设计、编码、测试、发布等不同的阶段，发现缺陷后修复的代价都会比在前一个阶段修复的代价提高10倍（参见下图）。这样看来，上面问题的答案自然就变成了“秃子头上的虱子”：从需求阶段开始！从“测试需求”开始！

注意，笔者这里的观点并不是说可以取消团队中的“需求评审会议”，这里并不存在冲突。笔者所希望讲述的，是测试人员应该如何看待软件需求，而并不是把“需求评审会议”所承担的责任揽到自己身上。?在论坛上也偶尔看到有的朋友问：如何测试需求呢？每次看到这样的提问，笔者内心就禁不住的一阵激动，因为一直以来，讨论这方面问题的朋友的确少之又少。

在笔者的实际工作中，对软件需求的检查包括两个方面的内容。

一是对软件需求正确性的检查，也就是要保证需求文档中所描述的内容是真实可靠的。在进行这部分工作时，不要迷信所谓的“都是用户提出的真实的需求”，因为我们必须考虑，提出这些需求的涉众，是否真的可以正确的描述自己的需求？我们的需求人员是否真的可以正确的理解用户的需求？有没有一些被用户认为在业务处理上是理所当然、极其平常的事情，而没有作为需求提出来？有没有一些被用户认为他们过去使用的软件已经提供了相应的功能，所以认为我们也应当提供，而没有提出来的？关于这个问题，也曾经有朋友提过不同的看法，认为这样对测试人员的要求太高了——既要熟悉需求人员的工作，又要熟悉软件所涉及的行业的业务。但笔者还是固执的认为，作为测试人员，还是需要对软件产品所涉及的行业的业务有一个全面的、深入的了解——当然，这不是对一个刚刚入门的测试者的要求，但是如果想称为一个优秀的测试者，是难免要付出这部分努力的。

二是要保证软件需求的可测试性。对于“可测试性”，笔者的概念是：对于一条软件需求或者一个需要实现的特性，必须存在一个可以明确预知的结果，并且可以通过设计一个可以重复的过程来对这个明确的结果进行验证。说的具体一点，就是要保证所有的需要实现的需求都是可以用某种方法来明确的判断是否符合需求文档中的描述。如果对于某条需求或某个特性，无法通过一个明确的方法来进行验证，或者无法预知它的结果，那么就意味着这条需求的描述存在缺陷，应该请需求人员对需求文档进行修改或补充——我们有理由相信，如果作为测试人员对需求无法产生准确的理解，那么开发人员也同样无法对同一条需求产生准确的理解。对于一条确定的软件需求理解的二义性，是在不规范的开发过程中导致返工的一个主要原因。如果认为有必要，那应该在“需求评审会议”上确认所有涉众对需求的理解是一致的。当然，对于如何提高软件需求的质量，在网络上或者已经出版的书刊中都已经有了很多更加具体、实用的方法，如果有兴趣，大家也可以找来参考。不过，如果您是一位测试者，那么上面这部分内容对您仍然是非常有用的。相信您只要在工作中进行尝试，慢慢的体会，一定会发现这种方法给您带来的好处。?现在当前的测试工作范围已经确定，相应版本的软件需求也通过了评审，我们就可以在这个已经确定的范围内进行测试需求的整理。我们手头上可以参考的东西，通常会有软件需求规约（以下简称SRS）和用例（以下简称UC）——当然，也可能是一份包含UC的SRS。通过对SRS和UC的阅读，我们可以从文档对特性和业务流程的描述中获得对软件所涉及的业务的一个基本的认识。比如用户在处理实际业务时都要作些什么，多个业务之间的先后顺序是怎样的，用户在处理业务是对于哪些地方有特别的要求，等等。这部分规则，将成为我们的测试需求中最基本的一部分。

至于测试需求的表现形式，笔者认为大家都可以根据自己的需要进行设计，而没有必要把思路限制在到底使用表格方式还是使用文本方式，只要把握一个原则就行了：在一条测试需求中，用容易理解的自然语言，明确的描述一项需要测试的内容。对于多项测试内容，应尽可能的剥离开来，保证一条测试需求只包含一项测试内容。

另外，大家也可能注意到了，在软件开发过程的这个阶段，通常是没有用户界面（以下简称UI）可供参考的——虽然RUP中对于需求阶段的工作描述包括了UI设计的部分，但很多时候在这个阶段还是无法提供一个确定的UI的——也就是说我们这时获得的测试需求，将是完全基于业务的，而并不包括基于UI的那部分规则，是同软件的最终具体实现相独立的。

随着开发工作的继续，开发部门的架构设计文档和详细设计文档也将陆续提交，这时候，我们可以根据设计文档来对已有的测试需求进行增补。注意，这里我们对于设计文档中提到的内容要有选择的采用，只有同SRS或UC中已经定义的部分相符的内容，才可以用来调整我们的测试需求。而同软件需求不相符的部分，则需要同设计人员和需求人员一起讨论，确定下以哪一方作为基准，决定是否需要调整软件需求，然后对测试需求进行相应的增补或者调整。比如对于一些算法，需要考虑设计文档中定义的，同系统实现相关的那些计算公式，是否同软件需求中描述的算法表达的是否是同一个意思？而对于一些约束或者业务规则，设计文档中描述的是否同需求中的相应部分一致？呵呵，看完上面这部分内容，恐怕又有一部分朋友晕倒在地了，而没有晕倒的那部分朋友也要提出异议：啊？！你这不是又包含了对开发人员所作的设计工作的检查吗？！刚刚让我们检查需求，现在又让我们检查设计，真的把我们当成全才了！没办法，为了让软件交到我们手上的时候只包含尽量少的缺陷，大家只能再辛苦一下了。我们的工作不应当仅仅限制在软件交付后尽力找到存在的缺陷，而更应该努力及早发现软件缺陷出现的苗头，尽量预防缺陷的出现。虽然并不是说在所有的团队中都应该由测试人员承担“测试需求”和“测试设计”的工作，但是测试人员对这些工作起到的作用，是其他团队中的其他角色所无法替代的。开发部门完成编码实现工作，提交供内部测试的应用程序时，测试人员手头上应该已经准备好了绝大部分测试用例和测试数据，测试部门将开始执行测试。通常在我们执行测试的过程中，即使我们已经从“通过测试”和“失败测试”两个不同的角度准备了非常充分的测试用例和测试数据，但总是有些缺陷的出现是出乎我们意料的，或者说是已有的测试需求和测试用例未能覆盖的。那么，对于这部分缺陷，也应当添加到测试需求中，并设计相应的测试用例，以便于下次版本迭代时进行参考。OK，相信说到这里，各位看客也应该可以理解我的观点了：对于一个长期发展的团队或者持续开发的产品，它的所有东西都是要不断积累的、不断迭代的。无论对于软件需求还是测试需求，不仅仅是在一个版本的开发过程中，在不同的阶段进行迭代，在产品的整个生命周期中的不同版本间，也是不断迭代和积累的。

第二篇：需求分析方法探讨

需求分析方法探讨[1]

一、概述

据权威部门统计，目前软件的成功率约为25%，75%的软件是失败的。在这75%的失败中，约有50%以上的软件是由于需求的原因造成的。作为软件的设计和开发人员常抱怨用户需求不明确，需求常处于变更状态。新的需求往往在开发阶段才被用户提出。造成软件的完成日期不断的迟后。

一般的软件企业，往往只口头上注重用户需求。但由于没有科学的管理方法，实际上他们描述的用户需求是杂乱无章的，只言片语的。不能有效地和系统设计、开发保持同步最后开发出来的软件产品和实际有很大的差异。导致软件的失败。有证据表明，在需求阶段修正错误的工作量，是在系统设计阶段修正错误的1/10；是在开发阶段修正错误的1/100，是在发布产品阶段修正错误的1/1000。当然这是对大型系统而言，对于不同的系统，随系统的复杂程度这个比率会有所不同。

用户的需求的增加具有渐进的、增量的特点。随着需求分析人员和用户逐渐深入的交流，用户在不断地整理、规范自己的需求。需求分析人员须牢记的是用户不可能一下子给出一个完整、清晰、规范的用户需求。需求分析人员需从与用户的交流中，不断地挖掘，并加以整理，才能得到想要的需求。

需求分析一般来说需要有一个需求分析的团队，如用户代表、系统分析人员、开发人员、需求管理人员等，他们的分工不同各有侧重点。对于小型或中型项目人员可以兼任。

基于上述原因，需要从理论上规范用户需求的收集和整理。本文结合系统建模，给出了需求分析的一般性方法。它如下的包含了两个方面:

1、技术层面

给出需求分析的系统框架，它包含了需求的项目、参与需求分析的用户、用户对于需求的可操作权限（安全性）等。

2、操作层面

给出了需求收集、整理、分析的一般性方法。其中介绍了系统建模和需求分析间的相互关系，最后介绍了目前几种流行的需求分析产品及它们的特点。

二、需求分析的基本概念

需求分析的目的是完整、准确地描述用户的需求，跟踪用户需求的变化，将用户的需求准确地反映到系统的分析和设计中，并使系统的分析、设计和用户的需求保持一致。

第三篇：软件测试方法总结

软件测试方法总结

（一）发布时间: 2008-12-12 17:07作者: lxm_lxm来源: 51Testing论坛

软件测试方法的总结，是lxm_lxm根据个人所做过的项目整理的，提供给新来的的朋友们。软件测试方法总结

一、界面

● 界面测试

（1）测试界面设计是否合理、简洁、美观，操作是否方便

（2）功能键、数据项信息是否齐全

（3）确认系统中同一功能抌名称是否统一

（4）设计样式、风格（查询条件样式；输入风格（点选/手输入）；）是否与系统其它模块统一

（5）确认页面内所有字段名称显示风格是否统一（居中、左对齐、右对齐，一般采用居中显示风格）

1、新增页面及功能测试

● 字段

在开始测试时应该保证数据的正确性，然后再从系统中找出各种Bug

（1）各字段输入正确的信息值保存，确认系统是否可以正确完成新增操作。

（2）进入添加界面不输入任何信息值，单击“保存”功能按钮，系统应该给出某个不允许为空字段的提示信息（属于边界测试）

（3）建议不允许为空的字段前面加上„*‟作为标记（统一性，方便性问题）

（4）编码/编号字段不允许输入中文及特殊字符，否则系统应该给出相应的提示信息

（5）测试编码/编号字段不允许重复，否则系统应该给出相应的提示信息

（6）确认字段是否已做长度限制，如果输入值超出长度范围，那么在保存时系统应该给出提示信息

（7）非法测试，如：校验数值型字段输入非数值，保存时系统是否给出相应的提示信息（根据实际需要确定数值型字段是否能够接受负数）

（8）边界测试，如：确认数值型字段的边界值（如：有效值为„0-100‟整数，那么输入-1或101保存时系统应该给出相应的提示信息；输入值为0、100系统应该能正确保存信息值；输入0到100内的整数值系统应该正确保存信息值）

（9）精确值测试，测试小数位数是否在定义的长度内

（10）字段精确值是否正确（四舍五入否）。

（11）根据实际情况测试名称字段是否具有唯一性，（一般情况下名称是不允许重复的，具体问题具体分析），否则系统应该给出相应的提示信息

（12）确认各字段名称书写是否正确（注意：要求编辑界面、住息列表中、错误提示信息、查询条件中的字段名称完全相同）

（13）确认特殊格式的字段是否已做标准格式的限制（如：电子邮件、邮编等）

（14）测试上级信息字段（如：上级XXX名称、上级XXX编号）的信息值是否根据所选择的上级XXX名称系统自动生成（注意：编号生成值一定是维护界面的编号，而不应该是相应表的那个主键编码）

（15）测试如果某字段信息值是从另一个模块中选择输入的，那么需要确认其它相关联字段的信息值是否也相应的正确的自动带入，并且这些字段应该都是只读的（16）创建人/编辑人、发布人、创建时间、创建人字段应该设为只读的，而且此类字段值应该默认当前操作人的姓名

（17）如果某个字段可以点选输入多个信息值，那么测试该字段是否接受，并保存了点选输入的多个信息值

（18）对于多选字段，测试是否具有记忆上次选择值并已验重

（19）测试字符型字段是否可以接受空格（统一性问题，建议不要接受空格）

（20）引用其它模块的字段信息值的字段长度是否与被引用模块相应字段长度一致

软件测试方法总结

（二）发布时间: 2008-12-12 17:13作者: lxm_lxm来源: 51Testing论坛

关键字：软件测试方法

6、常用功能键的功能测试

（1）保存---所有编辑页面如果未输入任何信息值而单击“保存”，系统应该给出“XXX字段不允许为空”的提示信息

（2）保存---如果某字段输入值有错误或超出长度范围，那么单击“保存”按钮时，系统应该给出相应的提示信息

（3）保存---输入相关信息单击“保存”后，建议系统给出“保存成功”提示信息

（4）保存---测试新增/修改信息保存后，信息列表是否自动刷新

（5）下一步---单击此按钮，如果有非空字段为空，系统应该给出相应提示信息；如果有字段输入非法值，单击此按钮系统应该给出相应提示信息；正常情况下单击此功能按钮，系统进入到下一个编辑/操作界面

（6）上一步---单击此功能按钮，系统应该正确返回到上一个编辑/操作界面

（7）浏览---测试该功能键功能是否已经正确实现，单击此按钮系统应该弹出文件选择页面，并且可以选择输入相关附件

（8）上传附件---测试上传功能已经正确实现，确认上传的附件在界面相应位置是否显示

（9）下载---测试下载功能已经正确实现（可以将上传到服务器的附件下载的本地相应位置）

（10）重新上传---保存操作后上传功能按钮名称应该自动变为“重新上传”，并且可以重新上传附件

（11）发布---测试该功能键功能已经正确实现，单击些功能按钮系统完成发布操作，相应的信息状态变为“已发布”，发布人、发布时间系统自动生成或已经正确保存（注意：已经发布的信息是不允许再进行修改操作的）（根据系统需求及设计测试，有些系统只有信息修改页面才有此功能）

（12）取消发布---测试该功能键功能是否已经正确实现，单击此功能按钮系统完成取消发布功能，相应信息状态变为“未发布”（根据系统需求及设计测试，有些系统只有信息修改页面才有此功能）

（13）关闭---单击此功能按钮系统将关闭当前页面，建议当单击此功能按钮时系统弹出“确认离开此页面提示信息”

（14）查询---单击查询功能按钮，系统按钮输入查询条件进行模糊查询；查询条件输入非法值进行查询操作，系统应该查询0记录

（15）删除----未勾选待删除记录单击此按钮系统弹出相应提示信息；正常情况下系统删除所选记录

（16）选择---勾选待选记录，单击此按钮系统完成选择操作；单击选择超链接功能按钮系统完成选择操作

（17）取消选择---单击此功能按钮，系统完成取消选择操作（清除所有选择信息）

软件测试方法总结

（三）发布时间: 2008-12-12 17:14作者: lxm_lxm来源: 51Testing论坛

关键字：软件测试方法

11、对用户名、密码的有效性测试

（1）密码信息有效性测试：特殊字符、正常字符、空字符（不输入）、空格

（2）登陆名是否区分大小写

（3）登陆名是否允许重名

（4）用户名字和密码都为最大长度（边界值分析，取上点）

（5）用户名字和密码都为最小长度（边界值分析，取上点）

（6）用户名字和密码都是非最大和最小长度的数据（边界值分析，取内点）

（7）用户名长度大于要求1位（边界值分析，取离点）

（8）用户名长度小于要求1位（边界值分析，取离点）

（9）密码长度大于要求1位（边界值分析，取离点）

（10）密码长度小于要求1位（边界值分析，取离点）

（11）是否记住上次登陆名

（12）密码信息有效性测试：字母数字混排、数字、符号数字、字母符号、数字符号、空字符（不输入）、空格、ASCII字符、字符串在有空格、串在有半角空格

（13）口令锁定：即输入口令次数的限制

（14）密码显示是否以星号或者别的符号显示

（15）看是否支持tap和enter键等

（16）密码是否可以复制粘贴

密码修改测试方法

（1）不输入旧密码，直接改密码

（2）输入错误旧密码

（3）不输入确认新密码

（4）不输入新密码

（5）新密码和确认新密码不一致

（6）新密码中有空格

（7）新密码长度有效性测试方法同上

（8）新密码为非允许字符（如有的密码要求必须是英文和数字组成，那么要试汉字和符号等）

（9）测试密码是否区分大小写，新密码中英文小写，确认密码中英文大写

（10）新密码与旧密码一样能否修改成功

软件测试方法总结

（四）发布时间: 2008-12-12 17:17作者: lxm_lxm来源: 51Testing论坛

关键字：软件测试方法

四、权限测试

1、业务权限

按需求测试用户业务权限分配是否正确，业务权限主要控制功能模块、功能菜单的展示，没有相应业务权限的不展示其功能模块能功能菜单。

2、操作权限

（1）权限组：按组用户来分配操作权限。（组内所有人员都具有所分配的操作权限）

（2）测试已分配操作权限的功能按钮是可见的（3）测试已分配操作权限的功能按钮是否可用；是否可以正确完成相应功能操作

（4）通常不分配调看操作权限是无法进行修改操作

五、算法

1、测试前需要充分了解算法的整个计算过程及结果值的精度

2、算法测试之前需要准备充足，而且是准确无误的测试实例

3、根据输入值确认系统计算输出结果是否与预期结果完全一致

4、如果计算公式中含有引用其它模块的数据，需要先确认数据提取是否对应的正确

5、先用等价划分法、边界值测试方法测试输入数据是否在需求范围内

6、严格按照测试用例执行测试，确认计算结果是否正确无误，注意结果的精度。

第四篇：软件需求-案例分析

1、问题描述

许多医院存在高峰期挂号排队时间长，就诊等待时间长，倒号现象频发的问题。因此，构建一个网上预约挂号系统，通过推荐患者使用该系统进行出诊信息查询和医生预约，可以缓解就诊压力、节约患者的时间，并且可以在一定程度上保证预约者和就诊者一致，有利于提高医院的服务质量。为了更好的设计并实现这一系统，对系统进行需求建模和分析是十分必要的。

2、情景描述的主要成分

2.1、该系统所涉及的用户

本系统的用户包含患者、医生以及管理员三类。而且该三类用户各自的特征和所要面对的情景也是截然不同的。

对于患者来说，他们在年龄、计算机使用能力等方面存在较大差异，但面对的情景都一样，就是要预约挂号，挂号成功过后就诊。

对于医生来说，普遍具备较高的学历，在医疗方面具备专业知识，有一定的计算机使用能力。所面对的情景有查看挂号信息，确定要就诊的病人。

对于管理员来说，他们负责对出诊信息进行管理，是医院工作的安排者，具备较强的计算机使用能力。

不同的用户，对系统的要求也不相同。患者希望通过完成注册和登录后能够进行挂号预约，查询医生的出诊信息和个人预约信息，并且能够在规定的时间内完成挂号预约或者取消已有的预约；医生则希望能够在登录系统后可以查看病人的预约情况；而管理员希望可以修改出诊信息和调整预约挂号。这些都是功能性的需求。

同时对于所有用户都希望该系统是易用的，而且能够对自己的信息起到保护即系统安全性的要求，还有比如说系统的性能比较高效，能够及时处理自己的预约申请。当然开发系统的成本如果也能较低就更好了。这些都是非功能需求。

2.2、情景描述的主要成分

 目标和关键成功因素

预约挂号情景的目标是“让患者能够及时的挂号，并能顺利的就诊”，而可能的子目标包括：患者能够注册账号，患者能够登录账号，患者能够查询预约记录，患者能够取消已有预约，患者能够查询出诊信息。关键成功因素，要保证系统能够24小时正常稳定的运行，系统里的信息要是实时变化的，即可以预约的医生要和实际在值班的医生要匹配，不能出现挂上号了却没有医生就诊的情况。

 物理上下文和逻辑上下文 物理上下文：医院用于挂号的计算机可以正常的使用，情景中的可以被预约的医生应该是在医院值班的；而对于患者可以选择在医院进行预约，也可选择在家中进行预约，只要在预约时间内能到达医院就可。逻辑上下文：事件发生的条件是患者在系统中进行了预约，然后管理员会根据现有的资源（可以预约的医生）对预约进行处理，如果同意，下一步就是医生就诊；如果没有可以预约的医生或合适的时间，患者的预约就不成功，患者需要重新选择医生或时间进行预约。

 组成情景的主要事件和活动 主要事件：患者预约挂号，管理员对预约挂号的处理，医生就诊。主要活动：患者注册、登录系统，患者在系统中查询可以预约的医生和时间，患者取消已有预约，患者进行就诊；管理员接受或拒绝预约，管理员分配医生；医生查询预约信息。

 涉及的执行者和其他参与者

执行者：医院的医生，预约挂号系统的管理员。其他参与者：医院的相关人员，比如患者，前台咨询员等。

 要使用的信息和资源 要使用的信息和资源包括，可以预约的医生数量，所在科室等，医院中的设备，病房等。 要考虑的约束条件和要使用的规则 约束条件：同一医生同一时间段内只能接受一名患者的预约，根据医疗设备的属性决定是否要排他性的使用。

3、情景需求分析的步骤

需求规格说明输入过程需求目标列表1.目标分析系统模型目标,目的使用情景用户问题实例2.输入事件分析初始系统模型用户,环境事件情景脚本4.输出需求分析3.刻画系统输出情景结构模型系统输出类型信息需求5.社会影响分析Agent目标6.涉众分析需求规格说明

3.1 目标分析

在第2部分情景描述的主要成分中已经对目标进行了分析，即：预约挂号情景的目标是“让患者能够及时的挂号，并能顺利的就诊”，而可能的子目标包括：患者能够注册账号，患者能够登录账号，患者能够查询预约记录，患者能够取消已有预约，患者能够查询出诊信息。3.2 输入事件分析

对于该系统的输入事件可能会包括如下情况：初始使用该系统的用户需要先注册，而对于已经注册的用户在使用系统预约挂号时首先要登录系统。这是最基本的两个输入事件。3.3 刻画系统输出

对于系统输出我们要考虑系统输出的形式，比如消息显示，对话框等形式。不如用户在登录系统是输入的用户名和密码不匹配的时候要给出对应的提示信息，比如用户名未注册或密码不对等。在提交预约挂号申请后系统也应给出预约成功与否的提示。3.4输出需求分析

对于输出需求要根据用户的输入给出对应的输出。比如用户输入查询请求，那么系统应该能够给出详细的信息。系统只给出对应的输出还不够，同时要考虑输出的信息是否合适。比如用户要查询眼科医生的资料，系统的输出就应该只是眼科医生的信息，而没有必要把所有医生的信息都输出。3.5 社会影响分析

在进行社会影响分析时要同时考虑到积极和消极两个方面的问题。系统是否可以提高效率，减少人员的工作量。同时也要考虑过多的自动化是否会削弱人对整个系统的意识，导致人对意外处理的能力降低，比如系统临时出现问题，是否有一套应急措施使医院日常工作能够正常的进行。

4、需求说明文档

基于之前构建的模型，并参照IEEE 830-1998标准模板，撰写的系统需求说明文档如下。

4.1 引言

引言部分将对本文档的编写目的、系统的开发目的、名词定义以及参考资料进行说明，并对文档的后续内容进行概述。4.1.1 编写目的

网上预约挂号系统是基于Web开发技术完成的网站。为了更好的设计并实现这一系统，对系统进行需求建模和分析是十分必要的。因此，基于之前构建的各类模型，撰写系统的需求说明文档，并将其作为后续项目设计、项目开发和项目测试的指导。

本文档连同之前构建的模型，可用来与客户进一步明确需求，同时可供项目经理、设计人员、开发人员参考。4.1.2 系统目的

许多医院存在高峰期挂号排队时间长，就诊等待时间长，倒号现象频发的问题。因此，构建一个网上预约挂号系统，通过推荐患者使用该系统进行出诊信息查询和医生预约，可以缓解就诊压力、节约患者的时间，并且可以在一定程度上保证预约者和就诊者一致，有利于提高医院的服务质量。4.1.3 名词定义  患者预约系统

网上预约挂号系统的子系统，主要用于为患者提供预约挂号、信息查询等功能。 医生工作查询系统

网上预约挂号系统的子系统，主要用于为医生提供各时段预约患者的信息。 医务管理系统

网上预约挂号系统的子系统，主要用于为管理员提供出诊信息修改、预约挂号调整等功能。 账号控制系统

网上预约挂号系统的子系统，主要用于用户账号的注册及登录控制。 安全保障系统

网上预约挂号系统的子系统，主要用于保障系统的程序、网络及数据库安全。4.1.4 参考资料

[1]Objectiver: A KAOS tutorial.Respect-It(2004)[2]吴双兵,刘伟.网上预约挂号系统设计与实现[J].医学信息学杂志, 2015, 36(1):36-39.4.1.5 文档概述

需求说明文档主要分为三个部分。本节属于引言部分，主要用于对文档本身进行定义和描述。文档的第二部分为系统的整体描述，包括系统的预期目标、限制条件以及用户的需求、特征。文档的第三部分是需求说明，包含对系统需求的明确定义。

4.2 整体描述

本节将对系统预期、用户需求、用户特征、条件与限制、假定与依赖以及需求分配进行说明。

4.2.1 系统预期

为了方便用户在不需安装任何软件的情况下使用系统，本系统整体采用B/S结构，用户可以通过浏览器对其进行访问。4.2.2 用户需求

参照之前完成的目标模型，对用户的需求进行整理和定义。由于系统整体较为复杂，因此本小节只包含已构建目标模型的功能性需求和非功能性需求。 功能性需求

1.患者进行预约选择

为了实现患者进行预约选择的目标，系统应完成的需求如下。（1）系统拥有患者预约页面以及预约按钮：

系统的预约页面可以显示未来1至3天的出诊医生及其所有可被预约的出诊时段。其中，尚未被预约的时段拥有预约按钮；已被预约的时段无法被其他患者预约，因此无预约按钮。（2）系统接收到预约请求：

当患者点击预约按钮，系统可以接收到预约请求。（3）患者被告知预约选择结果：

系统可以对患者是否预约成功进行判定，如果成功则跳转至信息确认页面，否则弹出对话框给予患者相应提示。2.患者确认预约信息

为了实现患者确认预约信息的目标，系统应完成的需求如下。（1）系统拥有预约信息确认页面以及预约提交按钮：

系统的预约信息确认页面会显示预约的医生和时段，患者的个人信息，以及预约提交按钮，患者可以在提交预约前核对这些信息。（2）系统接收到预约提交请求：

当患者点击提交按钮，系统可以接收到预约提交请求。（3）患者被告知预约提交结果：

系统可以对预约是否提交成功进行判定，并弹出对话框给予患者相应提示。 非功能性需求 1.安全的系统

为了保证预约挂号系统的安全性，系统应完成的需求如下。（1）用户程序安全：

系统应明确区分不同类别用户的权限。并且在用户登录时，输入的密码不可见、不可复制。（2）系统网络安全：

系统应采取安全的网络传输协议，网络数据在被传输前应进行加密。（3）数据库安全：

数据库中存储的数据应具备完整性，且密码应在加密后被存储到数据库中。此外，数据库中的数据应该可以被备份和恢复。2.低成本的系统 为了保证预约挂号系统的低成本，系统应完成的需求如下。（1）系统开发成本低：

开发团队应具备合理的项目管理，且在开发前应尽可能明确系统的需求。（2）系统运营成本低：

系统在运行过程中，应该尽可能少的占用资源。（3）系统维护成本低：

系统应该健壮可靠，出现问题后应该易于修复，且系统的功能应该易于扩展。考虑到系统健壮可靠与系统开发成本低存在一定的冲突，因此需要进行一定的权衡。4.2.3 用户特征

本系统的用户包含患者、医生以及管理员三类，其特征如下。 患者

个体间在年龄、计算机使用能力等方面存在较大差异。 医生

普遍具备较高的学历，在医疗方面具备专业知识，有一定的计算机使用能力。 管理员

负责对出诊信息进行管理，是医院工作的安排者，具备较强的计算机使用能力。4.2.4 条件与限制

为了保证系统的可移植性和可扩展性，本系统应使用Java语言进行开发。4.2.5 假定与依赖

本系统假定提供的大、中、小三种字体大小可以满足不同患者的需求，并且患者可以在系统的引导和提示下正常使用系统。4.2.6 需求分配

由于文档中并未列出系统的全部需求，因此无法对所有需求进行优先级排序。但已经列出的均为系统较为核心的功能性需求和非功能性需求，应具有高优先级。

4.3 需求说明

需求说明部分将参照之前完成的模型，对系统结构、对象模型以及操作过程模型进行详细描述。

4.3.1 系统结构

本部分将主要参照图 3-1所示的责任模型，根据主体对需求进行划分。考虑到系统较为复杂，因此只列出主体“患者预约系统”的相关需求。 患者预约系统

系统拥有患者预约页面以及预约按钮。

系统接收到预约请求。

患者被告知预约选择结果。

系统拥有预约信息确认页面及预约提交按钮。

系统接收到预约提交请求。

患者被告知预约提交的结果。4.3.2 对象模型

本部分将主要对图 4-1所示的对象模型的结构进行解释。

网上预约挂号系统可以被详细划分为患者预约系统、医生工作查询系统、医务管理系统、账号控制系统、安全保障系统等五个子系统。患者预约系统、医生工作查询系统、医务管理系统的使用者分别为患者、医生和管理员，这些用户通过系统提供的页面与系统进行交互。

对象模型中所涉及的名词在4.1.3小节中有具体解释。4.3.3 操作过程模型

本部分将主要对图 5-1，图 5-3和图 5-4所示的操作过程模型进行说明，并以表格的形式列出各操作过程的参与主体及对应需求。 患者进行预约选择

患者点击预约按钮后，患者预约系统会收到患者的预约请求，并触发预约验证操作，得到预约验证结果。接下来，患者预约系统会以得出的预约结果为基础，进行预约结果判定，进而执行页面跳转或消息框弹出操作。 患者确认预约信息

患者点击提交按钮后，患者预约系统会收到患者的预约提交请求，并触发预约提交操作。接下来，患者预约系统会根据提交结果弹出包含相应信息的提示框。

以上部分涉及到的操作过程及与之对应的主体、需求如下表所示。

以上部分涉及到的操作过程及与之对应的主体、需求如表 4-1所示。

操作 预约验证 参与主体

对应需求

患者预约系统 系统接收到预约请求，患者被告知预约选择结果

预约结果判定 患者预约系统 患者被告知预约选择结果 预约提交 患者预约系统 系统接收到预约提交请求，患者被告知预约提交结果

第五篇：软件需求分析报告

软件需求分析

软件需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。进行需求分析时，应注意一切信息与需求都是站在用户的角度上。尽量避免分析员的主观想象，并尽量将分析进度提交给用户。在不进行直接指导的前提下，让用户进行检查与评价。从而达到需求分析的准确性。分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据和功能表示。在软件完成后，制定的软件规格说明还要为评价软件质量提供依据。

需求分析的任务

开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。目前，国内产品的庞杂，一家企业可能有几个系统并立运行，它们之间接口是系统开发人员最头痛的问题。对于商业最终用户应用程序，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的。但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道项目于何时结束？而如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？然而，即便并非出于商业目的的软件需求也是必须的。例如库、组件和工具这些供开发小组内部使用的软件。当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价，这些血的教训正在国内的软件开发者身上发生。近来，我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件。不幸的是，当他们开发完这个工具后，发现这个工具不能打印出源代码文件，使用者当然希望有这个功能。结果这个小组只好手工抄写源代码文档以供代码检查。这说明那怕需求明确无误并构思准确，如果我们没有编写文档，软件达不到期望目标也只能是咎由自取了。相反的情况，我曾见一个要集成到“错误跟踪系统”中的简单界面写了一页需求说明。而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用。他们依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误。事实上，需求文档在开发过程中一直起指导作用。需求的类型

下面这些定义是需求工程领域中常见术语的定义。软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。1．业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。2．用户需求(user requirement)文档描述了用户使用产品必须要完成的任务，这在使用实例（usecase）文档或方案脚本说明中予以说明。3．功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。在软件需求规格说明书（SRS）中说明的功能需求充分描述了软件系统所应具有的外部行为。软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对一个大型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统（或软件部件）。作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反

映产品功能。多角度描述产品对用户和开发人员都极为重要。下面以一个字处理程序为例来说明需求的不同种类。业务需求可能是：“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。从以上定义可以发现，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。项目也有其它方面的需求，如开发环境需求或发布产品及移植到支撑环境的需求。