软件需求分析考试资料

第一篇：软件需求分析考试资料

1、需求分析的最终结果是需求规格说明书。

2、需求分析中开发人员要从用户那里解决的最重要的问题是让软件做什么。

3、需求规格说明书中的内容不应该包括对算法的详细过程的描述。

4、需求规格说明书的作用不应包括软件可行性研究的依据。

5、关于面向对象方法中消息的叙述，不正确的是操作系统不断向应用程序发送消息，但应

用程序不能向操作系统发送消息。

6、面向对象技术中，对象是类的实例，对象有三种成分标识、属性、方法（或操作）

7、软件需求分析阶段的工作，可以分成以下四个方面对问题的识别、分析与综合、制定规

格说明以及需求分析评审。

8、软件需求规格说明书的内容不应该包括对算法的详细过程的描述。

9、产品特性可以称为质量属性，在众多质量属性，对于开发人员来说重要的属性有哪些？

可维护性、可移植性、可重用性、可测试性

10、求包括11个方面的内容，其中网络和操作系统的要求属于环境需求，如何隔离用户之间的数据属于安全保密需求，执行速度、相应时间及吞吐量属于性能需求，规定系统平均出错时间属于质量保证。

11、需求分析过程应该建立3中模型，他们分别是数据模型、功能模型、行为模型，以下几种图形中，数据流图（DFD）属于功能模型，实体-联系图（ERD）属于数据模型，状态转换图（STD）属于行为模型。

12、常用的需求分析方法有：面向数据流的结构化分析方法（SA），面向对象的分析的分析方法（OOA），下列(D)不是结构化分析方法的图形工具。

A 决策树B 数据流图C数据字典D快速原型

13、软件开发中，原型是软件的一个早期可运行的版本，它反映最终系统的部分重要特性，其中，探索型和实验型用完可以丢弃，而进化型围绕原型修改、增加。

14、数据流图用于描述数据的处理过程。

15、DFD 的基本符号不包括下列哪种？（A）。

A 数据字典B 加工C 外部实体D 数据流E 数据存储文件

16、DD的主要字典条目包括以下哪种（E）

A 数据流B文件C 数据项D加工E以上都是

17、常用的动态分析方法不包括以下哪种（B）

A 状态迁移图B 层次方框图C 时序图D Petri网

18、需求分析阶段的文档包括以下哪些（E）

A 软件需求规格说明书B 数据要求说明书C 初步的用户手册D 修改、完善与确定开发实施计划E 以上都是

19、需求验证应该从下述几个方面进行验证：（C）

A 可靠性、可用性、易用性、重用性B 可维护性、可移植性、可重用性、可测试性

C 一致性、现实性、完整性、有效性 D 功能性、非功能性

20、风险管理的要素包括哪些（D）

A 风险评价B 风险避免C 风险控制D 以上都是

21、下列描述中错误的是（D）

A 每一个集成的需求变更必须能跟踪控制到一个经核准的变更请求。

B 变更过程应该做成文档，尽可能简单，当然首要的是有效性。

C 所有需求变更必须遵循过程，按照此过程，如果一个变更需求未被采纳，则其后过程不再予以考虑。

D 可以从数据库中删除或修改变更请求的原始文档。

二、填空题

1、需求分析阶段产生的最重要的文档是（需求分析说明书）。

2、需求分析的主要任务是（要回答“软件必须做什么？”）。

3、需求分析阶段，分析人员要确定对问题的综合需求，其中最主要的是(功能需求)需求。

4、需求分析阶段研究的对象是软件项目的(用户要求)。

5、软件生命周期：问题分析、可行性研究、需求分析、总体设计、详细设计、编码和单元测试、综合测试、软件维护。

6、信息系统必须实现的功能，或者说信息系统必须具备的属性和质量称为（系统需求（需求））

7、（模型）是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述通常，由一组图形符号和组织这些符号的规则组成。

8、软件需求分析阶段的目的是澄清用户的要求，并把双方共同的理解明确地表达成一份书面文档——（软件需求规格说明书。

9、软件需求分类，分为（功能性）需求和（非功能性）需求。

10、需求分析的步骤包括（需求获取）、（分析建模）、文档编写。。

三、名词解释

第一、二空缺。

3、需求工程：整个软件需求范围内所进行的活动称为需求过程，需求工程包括需求开发和需求管理两部分，需求开发包括问题获取、分析、编写规格说明和验证。

4、业务模型：业务模型是理解是理解一个组织业务过程的技术，可以用业务用例模型和业务对象模型来表达业务模型，业务用例模型分别是分别从与业务过程和客户对应的业务用例和业务参与者的角度来描述企业的业务过程；业务对象模型描述了如何由一组工作人员使用一些业务实体和工作单元来实现每个业务用例。

5、原型开发方法：一个软件原型是所提出的新产品的部分市县，使用原型有三个主要目的：

1）明确并完善需求，2）探索设计选择方案，3）发展成为最终的产品，建立原型的主要原因是为了解决在产品开发的早期阶段不确定的问题，原型可分为抛弃型原型和进化型原型。

6、数据字典：一个定义应用程序中使用的所有数据元素和结构的含义、类型、数据大小、格式、度量单位、精度以及允许取值范围的共享仓库。

四、简答题

1、生命周期模型是什么？常见的生命周期模型有哪几种？

答：对软件开发流程的一种描述：为解决问题所定义的策略；对典型开发活动的抽象。常见的生命周期模型：Waterfall，Prototyping，Phased，Spiral（瀑布模型、快速原型模型、增量模型,螺旋模型）

2、为什么要使用生命周期模型？

答：帮助开发组了解他们在开发项目的活动、资源和限制；帮助项目了解在开发过程中的不一致，丢失，冗余等情况，把注意力集中在开发最终产品上；帮助项目组剪裁开发过程——没有基础就无从剪裁。

3、waterfall的优势是什么？

答：具有良好定义的里程碑，利于向不熟悉软件开发的客户讲解流程；帮助开发人员理解需要做的事情；清楚地描述下阶段开始前需要的中间产品；是很多其他LC模型的基础。

4、需求分析阶段的基本人物是什么？

答：需求分析阶段的基本任务是：

（1）问题识别：双方对问题的综合需求；a.功能需求 b.性能需求c.环境需求d.用户界面

需求。

（2）分析与综合，到处软件的逻辑模型。

（3）编写文档。

五、问答题

1、软件过程的概念及分类，基本过程包含些什么及每个过程的具体内容。

答：软件过程也称为软件生存周期过程或软件过程组，是指软件生存周期中的一系列相关过程，过程就是过程的集合，活动是任务的集合，人物则起到把输入加工成输出的作用。活动的执行可以是顺序的、迭代的（重复的）、并行的、嵌套的或是有条件引发的。

软件过程可以分为三类：基本过程、支持过程和组织过程。

基本过程包括：

1）获取过程：（项目委托方）确定需求；招标；签订合同；对供应方的监督；验收完成。

2）供应过程：（项目承包方）理解需求；投标；签订合同；计划；实施；控制；评审评

价；交付。

3）开发过程：（软件开发人员）过程实施准备；系统需求分析；系统结构设计；软件需

求分析；软件体系结构设计；软件详细设计；软件编码测试；软件集成；软件合格测试；系统集成；系统合格测试；软件安装；验收支持。

4）运行过程：（用户）运行准备；运行测试；产品转移；运行；运行支持；运行评价。

5）维护过程：（维护人员）过程实施准备；问题分析和修改设计；修改实施；对维护的评审和验收；软件移植；软件退役。

2、简述软件需求工程分为哪几类？其中需求获取和需求规约的目的和任务。

答：软件需求工程细分为：需求获取、需求分析与协商、系统建模、需求规约、需求验证和需求管理六个阶段。

需求获取：系统分析人员通过与用户的交流，对现有系统的观察及任务进行分析，确定系统或产品范围的限制性描述、与系统或产品有关的人员及特征列表、系统的技术环境的描述、系统功能的列表及应用于每个需求的领域限制、一组描述不同运行条件下系统或产品使用状况的应用场景以及为更好地定义需求而开发的任意原型。

需求规约：软件需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标的各种要求。需求规约作为用户和开发组之间的一个协议，在之后的软件工程各个阶段发挥重要作用。

3、简述软件体系结构的概念及基于B/S体系结构的实现方式。

答：软件体系结构：软件体系结构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件，处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把体系结构的不同部分组合连接起来。

B/S结构：浏览器（客户机）—WEB服务器—数据库服务器

B/S体系结构的实现方式：B/S模式下的客户机只需安装浏览器软件，无须开发前端应用程序；中间层的WEB应用服务器，主要的数据计算和应用都在此完成，因此对中间层服务器的要求较高；后台数据库服务器主要完成数据的管理。

4、用户界面设计三个的任务和目的答：用户界面设计在工作流程上分为结构设计、交互设计、视觉设计三个部分。

1)结构设计：结构设计也称概念设计，是界面设计的骨架，通过用户研究和任务分析，制定出产品的整体架构，基于纸质的低保真原型可提供用户测试并进行完善，在结

构设计中，目录体系的逻辑分类和语词定义是用户易于理解和操作的重要前提。

2)交互设计：交互设计的目的是使产品让用户能简单使用，任何产品功能的实现都是

通过人和机器的交互来完成的。因此，人的因素应作为设计的核心被体现出来。

3)视觉设计：在结构设计的基础上，参照目标群体的心理模型和任务达成进行视觉设

计，包括色彩、字体、页面等，视觉设计要达到用户愉悦使用的目的。

5、需求规格说明文档的作者及表现手段

答：作者：

项目管理者：组织安排、提供条件。

需求工程师：负责人、主导人。

文档写作人员：有时会采用，节省需求工程师的时间

涉众（用户）：验证人

表现手段：

非形式化：自然语言、限制性文本

半形式化：结构化文本（伪码/结构化英语）、模型语言（图、表）

形式化：形式化语言（数学语言：BNF）

6、数据库设计的内容及常用方法

答：数据库设计包括数据库的结构设计和数据库的行为设计。

1）数据库的结构设计

数据库的结构设计指是根据给定的应用环境，进行数据库的模式或子模式的设计。它包括数据库的概念设计、逻辑设计和物理设计，数据库模式是各应用程序共享的结构，是静态的、稳定的，一经形成后通常情况下是不容易改变的，所以结构设计又称为静态模型设计。

2）数据库的行为设计

数据库的行为设计是指确定数据库用户的行为和动作，而在数据库系统中，用户的行为和动作指用户对数据库的操纵，这些要通过应用程序来实现，所以数据库的行为设计就是应用程序的设计。用户的行为总是使数据库的内容发生变化，所以行为设计是动态的，行为设计又称为动态模型设计。

数据库常用设计方法：直观设计法、规范设计法、计算机辅助设计法、自动化设计法。

7、如何正确看待客户？

答：即使最终用户不是上帝，也算是上帝的亲戚，同样怠慢不得

如果项目规模比较大，那么开发方与最终用户的来往就比较多。如从最终用户那里获取详细的需求，请最终用户试验软件，对最终用户进行培训等等。

8、概括说明如何进行需求分析？

答：（1）需求分析是指需求开发过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图。

（2）分析方法大体有两类：“回答分析法”和“建模分析法”。

第一：问答分析方法很简单：刨根究底地问，如果问题都被解答了，那么需求也就分析清楚了，一个人可以“自问自答”地分析需求，几个人分析需求则称为“研讨”，问答分析最重要的问题是：“是什么”和“为什么”，其它常见的问题有：需求存在二义性吗？需求文档的上下文有矛盾吗？需求完备吗?需求是必要的吗？需求可实现吗？需求可验证吗？需求的优先级确定了吗？

第二：建模分析法：在需求开发过程中，对于某些类型的信息，用图形表示要比文本表示更加有效，所以将图形与文本结合起来描述需求是很自然的方法。需求建模就是指用图形符号来表示、刻画需求，需求建模不可能取代文字描述。在需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用、建议将模型存放在需求文档的附录中，便于正文引用。建模分析方法主要有两大类：“结构化分析法“和”面向对象分析方法“。

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

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）中说明的功能需求充分描述了软件系统所应具有的外部行为。软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对一个大型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统（或软件部件）。作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反

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

第四篇：软件项目需求分析总结

软件项目需求分析总结

我们做的需求只解决了我们能做出这样的项目，但是没有解决这样的项目是不是真就是客户想要的。造成这种状况的原因主要是下面几个情况：

客户本身说不清楚

文物网是这样，中彰国际更是这样，但是这不能怪客户，毕竟客户在软件方面的知识要少的多，也没有相关的经验，可能心里只有一个想要的软件的轮廓，于是可能会要求我们去替他们来完整这个轮廓的细节，而我们的能力、我们能否真正站在客户角度去搜集和整理这些需求，就决定了这个需求的完整性和有效性。

需求自身经常变动

随着客户对这个项目越来越深刻的理解，那么可能他的需求也会随之改变，这些变化的可能性越大项目风险就会越大，我们在需求分析的时候就要充分考虑到哪些需求是相对固定的需求，哪些可能会是产生变动的需求，考虑到他的可变性，这样设计功能和数据库的时候不致因为后面的变动而影响整个工程。分析人员或客户理解有误

毕竟，不是每个分析人员都是专业而合格的，为避免这种情况的发生，需求分析必须要有审核制度，公司自己内部要审核一遍，客户再审一遍，提出意见，修改后双方共同评审签字，确认。

由此出现的问题：

a)需求分析过于笼统，只关注到面上，没有关注到点上，开发出来的东西在具体的细节上和客户的理解有误差，并且无法严格界定是否属于需求变更。中彰的方案就是这样的。

b)需求报告只求我们这方评审通过，不去关心客户的评审，认为只要客户签字认可就行。虽然签字认可能够给日后出现问题时划清我们的责任，但是不能保证使项目实施成功。

c)需求分析中含有技术实施上有难度的功能，一味的求全和盲目按照客户的设想，受客户影响过大，毕竟，很多时候，客户的想法在实际实施过程中是不现实的，或者可以有更为简便的方法来替代的。如中彰国际的在线交易功能，后台大批量邮件群发功能。

d)对双方已经确定的需求，实现以后并不适合客户使用，需要按照变更手续执行的时候，客户可能会纠缠，提出“你们是专业人士，你们应该事先能提醒我们可能会出现这种问题”并以此来把责任推给我们，而我们又不好完全按照变更手续执行，因为可能激化双方的矛盾，比如508的批量处理功能，因为属于人事

管理比较专业的细节问题，需求分析师开始没有对客户业务熟悉到如此细致的地步，而客户也没有过多关注这些细节，导致软件的某些功能不合用，较为繁琐，而重新按着客户的意见修改的话工作量比较大，导致成本增加、工期延长。e)项目的成熟度受客户预算的限制。大部分客户在项目投入上都是有预算的，在成本有上限的前提下，项目的功能设计(软件的成熟度)方面必然受一定影响，毕竟功能越多越完善，相应的开发成本就越高。这种功能上的不完善需要事先告知客户并得到理解。

f)此项工作的反复造成思想上的倦怠，使需求分析最后虎头蛇尾。需求分析是一项繁琐枯燥的工作，需要和客户之间不断的商讨、确认和反复，另外由于大部分的客户虽然安排专人负责这项工作，但是该人并不只做这项工作，特别当他被很多其他的事情缠身的时候，而无心细看提交过去的需求报告的时候，他很可能会给你一个错觉，让你认为他已经真正的理解并认可了你的设计。结论

a)需求分析是整个项目管理中需要重点控制的几个关键节点之一，首先思想上一定要重视。

b)需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能。对于说不清楚需求的客户，要善于问关键问题，引导客户提出自己的需求。可以采取的措施是事先编制一个问卷调查之类的文档，详细列举需要客户回答的问题，以便防止遗漏。

c)需求报告的编写者要能够对客户需求进行深入分析，区别出哪些需求存在日后变更的可能，哪些需求属于相对固定的，哪些需求能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。

d)需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生

e)需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。

f)需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题g)帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解

h)最后，需求分析报告一定要双方共同签字确认

第五篇：软件项目需求分析总结

软件项目需求分析总结

需求分析是项目开发的基础，基础打的牢不牢直接关系到后面所有的工作，是项目实施成败的关键 总体上说，我们的需求分析是做了，但是做得很不够，我们做的需求只解决了我们能做出这样的项目，但是没有解决这样的项目是不是真就是客户想要的。造成这种状况的原因主要是下面几个情况： 客户本身说不清楚 文物网是这样，中彰国际更是这样，但是这不能怪客户，毕竟客户在软件方面的知识要少的多，也没有相关的经验，可能心里只有一个想要的软件的轮廓，于是可能会要求我们去替他们来完整这个轮廓的细节，而我们的能力、我们能否真正站在客户角度去搜集和整理这些需求，就决定了这个需求的完整性和有效性。需求自身经常变动 随着客户对这个项目越来越深刻的理解，那么可能他的需求也会随之改变，这些变化的可能性越大项目风险就会越大，我们在需求分析的时候就要充分考虑到哪些需求是相对固定的需求，哪些可能会是产生变动的需求，考虑到他的可变性，这样设计功能和数据库的时候不致因为后面的变动而影响整个工程。分析人员或客户理解有误 毕竟，不是每个分析人员都是专业而合格的，为避免这种情况的发生，需求分析必须要有审核制度，公司自己内部要审核一遍，客户再审一遍，提出意见，修改后双方共同评审签字，确认。由此出现的问题： a)需求分析过于笼统，只关注到面上，没有关注到点上，开发出来的东西在具体的细节上和客户的理解有误差，并且无法严格界定是否属于需求变更。中彰的方案就是这样的。b)需求报告只求我们这方评审通过，不去关心客户的评审，认为只要客户签字认可就行。虽然签字认可能够给日后出现问题时划清我们的责任，但是不能保证使项目实施成功。c)需求分析中含有技术实施上有难度的功能，一味的求全和盲目按照客户的设想，受客户影响过大，毕竟，很多时候，客户的想法在实际实施过程中是不现实的，或者可以有更为简便的方法来替代的。如中彰国际的在线交易功能，后台大批量邮件群发功能。d)对双方已经确定的需求，实现以后并不适合客户使用，需要按照变更手续执行的时候，客户可能会纠缠，提出“你们是专业人士，你们应该事先能提醒我们可能会出现这种问题”并以此来把责任推给我们，而我们又不好完全按照变更手续执行，因为可能激化双方的矛盾，比如508的批量处理功能，因为属于人事管理比较专业的细节问题，需求分析师开始没有对客户业务熟悉到如此细致的地步，而客户也没有过多关注这些细节，导致软件的某些功能不合用，较为繁琐，而重新按着客户的意见修改的话工作量比较大，导致成本增加、工期延长。e)项目的成熟度受客户预算的限制。大部分客户在项目投入上都是有预算的，在成本有上限的前提下，项目的功能设计（软件的成熟度）方面必然受一定影响，毕竟功能越多越完善，相应的开发成本就越高。这种功能上的不完善需要事先告知客户并得到理解。f)此项工作的反复造成思想上的倦怠，使需求分析最后虎头蛇尾。需求分析是一项繁琐枯燥的工作，需要和客户之间不断的商讨、确认和反复，另外由于大部分的客户虽然安排专人负责这项工作，但是该人并不只做这项工作，特别当他被很多其他的事情缠身的时候，而无心细看提交过去的需求报告的时候，他很可能会给你一个错觉，让你认为他已经真正的理解并认可了你的设计。结论 a)需求分析是整个项目管理中需要重点控制的几个关键节点之一，首先思想上一定要重视。b)需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能。对于说不清楚需求的客户，要善于问关键问题，引导客户提出自己的需求。可以采取的措施是事先编制一个问卷调查之类的文档，详细列举需要客户回答的问题，以便防止遗漏。c)需求报告的编写者要能够对客户需求进行深入分析，区别出哪些需求存在日后变更的可能，哪些需求属于相对固定的，哪些需求能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。d)需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生 e)需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。f)需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题 g)帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解 h)最后，需求分析报告一定要双方共同签字确认。