1. 文档介绍
1.1 文档目的
为了明确客户的基本需求，更好地完成对客户需求的了解，并量化和明晰本系统的工作量和工作进度，特编写此说明书。
1.2 文档范围
该文档包括产品售后服务系统项目的介绍、面向的用户群体、系统的功能性需求及非功能性需求。
1.3 读者对象
本手册适用于与客户进行需求的沟通与确认，及所有《产品售后服务跟踪系统》的设计开发人员。
2 系统介绍
2.1 背景
随着信息技术的日益发展，产品售后服务的信息化已成为产品售后服务跟踪系统的必然趋势。产品售后服务系统的核心部分是对客户进行回访问卷调查，以确定客户对产品的评价，服务的满意度。为了更详细的了解产品售后服务过程中各项管理业务，调研人员和最终用户进行了多次讨论，并提出了双方认可的解决方案。
2.2 系统说明
产品售后服务跟踪系统主要为公司解决售后服务管理的需求，协助回访工作人员对客户进行日常回访调查和客户管理，提高管理效率，降低运作成本，增强
企业长期竞争力
通过该系统，公司系统管理人员能实现对回访用户、客户的动态管理；系统管理人员能随时了解回访用户的回访情况；回访用户能记录客户的回访记录；3. 系统面向的用户群体
系统面向产品公司的售后服务管理员，回访用户。
3.1 用户的特征
用户大都具备以下特征：
? 有IE 使用经验
? 了解网络
? 了解办公自动化
3.2 用户环境
用户的计算机环境大致如下：
? Microsoft Windows XP
?Microsoft Internet Explorer 6 或更高版本
? MS Office 办公软件
? Outlook 或Foxmail 邮件管理
? Microsoft Windows .NET Framework 2.0
4. 系统的功能性需求
系统包含的功能概括如下表：
4.1 用户中心 4.1.1
用例
4.1.2
用例描述
用例名称：录入回访用户信息 用例简述：系统管理员录入回访用户信息 主参与者：系统管理员 主要场景：
1、 系统管理员输入回访用户信息
2、 系统管理员提交回访用户息
其他场景： 如果回访用户已存在，系统提示回访用户已存在 用例名称：修改回访用户信息
用例简述：系统管理员修改回访用户信息 主参与者：系统管理员
主要场景： 1 、系统管理员查询回访用户信息列表，选择需要修改的具体回访用户信息
2、系统管理员修改部门信息，提交修改信息
其他场景： 如果回访用户已存在，系统提示回访用户已存在
用户
删除用户信息
查看回访用户信息
修改回访用户信息
系统管理用户
用户中心
修改回访用户密码
回访用户
查看回访用户信息
录入回访用户信息
用例名称：查询回访用户信息用例简述：系统管理员查询回访用户信息主参与者：系统管理员主要场景：
1 、系统管理员输入查询条件
2 、系统管理员查询回访用户信息
用例名称：删除回访用户信息用例简述：系统管理员删除回访用户信息主参与者：系统管理员主要场景：
1 、系统管理员选择要删除的回访用户信息，删除回访用户信息
其他场景：如果回访用户还有客户未回访，系统提示因回访用户还有客户未回访删除失败
用例名称: 查看个人信息用例简述：回访用户查看回访用户个人信息主参与者：回访用户主要场景：
1、回访用户查看回访用户个人信息
用例名称：修改用户密码
用例简述：回访用户修改回访个人密码
主参与者：回访用户
主要场景：
1 、回访用户密码泄露或者安全性不高需要修改密码
4.2 客户资料中心
4.2.1 用例
4.2.2 用例描述
用例名称：添加客户信息用例简述：系统管理员录入客户信息主参与者：系统管理员主要场景： 1 、系统管理员输入客户信息
2 、有新客户购买产品需要录入信息用例名称：修改客户信息用例简述：系统管理员修改客户信息主参与者：系统管理员主要场景： 1 、客户信息有误需要修改客户信息
2、客户信息变更需要修改客户信息
用例名称：查询客户信息用例简述：系统管理员查询客户信息主参与者：系统管理员主要
场景： 1 、系统管理员选择查询条件查询客户信息用例名称：删除客户信息用例简述：系统管理员删除客户信息主参与者：系统管理员
主要场景： 1 、客户不配合回访用户售后服务
2、把售后服务已经过期的客户信息删除
3、客户填写不正确信息用例名称：查询回访情况用例简述：回访用户查询回访情况主参与者：回访用户
主要场景： 1 、回访用户选择查询条件
2、回访用户查询回访情况信息
4.3 问卷调查 4.3.1
用例
4.2.2
用例描述
用例名称 用例简述 主参与者 主要场景 ：录入问卷信息
：系统管理员录入问卷信息 ：系统管理员
： 1 、系统管理员输入问卷信息
2 、系统管理员提交问卷信息
用例名称
用例简述
主参与者
主要场景 ：修改问卷信息 ：系统管理员修改问卷信息 ：系统管理员 ： 1 、系统管理员查询问卷信息列表，选择需要修改的具体问卷信息
2、系统管理员修改问卷信息，提交修改信息
3、根据市场需求修改问卷信息
用例名称用例简述主参与者主要场景：查询问卷信息
：系统管理员查询问卷信息
：系统管理员
： 1 、系统管理员输入查询条件
2、系统管理员查询问卷信息
用例名称用例简述主参与者主要场景：删除问卷信息
：系统管理员删除问卷信息
：系统管理员
： 1 、系统管理员选择要删除的问卷信息，删除问卷信息
用例名称用例简述主参与者主要场景：提交问卷
：回访用户根据对的客户调查填写提交问卷：回访用户
： 1 、回访用户填写问卷信息
2 、回访用户提交问卷信息
用例名称用例简述主参与者主要场景：修改问卷提交信息：回访用户修改问卷提交信息：回访用户
： 1 、回访用户填写的问卷信息有误需要修改
用例名称
用例简述主参与者主要场景：查看问卷提交信息：回访用户查看提交的问卷信息：回访用户
： 1 、回访用户需要查看问卷的提交情况
4.4 客户数据分配
4.4.1 用例
4.2.2 用例描述
用例名称：查看自动分配信息用例简述：回访用户查看所分配的客户数主参与者：回访用户主要场景： 1 、回访用户需要知道自己分配的客户数及客户信息
4.5 报表统计
4.5.1 用例
4.2.2 用例描述
用例名称：查询回访情况统计信息
用例简述：系统管理员可以查询在一定时间内回访总数及各种情况数量
主参与者：系统管理员
主要场景： 1 、系统管理员输入查询条件查看回访情况统计信息用例名称：打印回访情况统计信息用例简述：系统管理员打印回访情况统计信息主参与者：系统管理员主要场景： 1 、系统管理员需要打印回访情况统计信息
5. 系统的非功能性需求
5.1 配置需求
系统提供如下两种浏览器兼容支持：
? Microsoft Internet Explorer 6.0 及其以上版本；
? Netscape Navigator 6.0 及其以上版本。
5.2 安全性需求
安全性需求通常分为四类：
? 用户认证需求：阐述系统表示用户和用户认证的方法。
? 授权：如果认证成功，根据用户的级别，允许其执行不同的系统功能。
? 数据完整性和隐私需求：确保数据完整，不会影响系统安全。
? 事务完整性和审计需求：确保用户无法清除自己的在系统中的活动。
记录活动相关的数据，使得系统管理员可以发现所有可能的危险行为。5.2.1 用户认证需求
系统使用一组用户ID 和密码来表示一个用户。
在用户登录20 分钟后，如果没有任何的动作，则自动退出登录。如果再次试图访问受保护页面，则自动显示登录页面
5.2.2 数据完整性和隐私需求
密码必须加密存储。用户帐号和密码必须通过SSL 进行传送。
5.2.3 授权需求
系统必须实现一定的页面访问限制。用户只能访问自己有权限操作的页面（具体可操作的部分详见系统的功能性需求中各模块的用例）。
5.3 可靠性需求
系统每天至少保持23 小时30 分的可用时间，每日凌晨3:30 到4:00 之
间进行日常系统
维护工作，如数据传输、交换等。临时的系统停机时间，每月合计必须少于3 小时。
5.4 并发性能需求
在多个并发用户更新同一账户信息时，第一个可以成功更新。随后的更新在
提交之前，显示错误信息“用户数据已经改变，是否需要刷新用户数据？” 。
1. 文档介绍 1.1 文档目的 为了明确客户的基本需求，更好地完成对客户需求的了解，并量化和明晰本系统的工作量和工作进度，特编写此说明书。 1.2 文档范围 该文档包括产品售后服务系统项目的介绍、面向的用户群体、系统的功能性需求及非功能性需求。 1.3 读者对象 本手册适用于与客户进行需求的沟通与确认，及所有《产品售后服务跟踪系统》的设计开发人员。 2 系统介绍 2.1 背景 随着信息技术的日益发展，产品售后服务的信息化已成为产品售后服务跟踪系统的必然趋势。产品售后服务系统的核心部分是对客户进行回访问卷调查，以确定客户对产品的评价，服务的满意度。为了更详细的了解产品售后服务过程中各项管理业务，调研人员和最终用户进行了多次讨论，并提出了双方认可的解决方案。 2.2 系统说明 产品售后服务跟踪系统主要为公司解决售后服务管理的需求，协助回访工作人员对客户进行日常回访调查和客户管理，提高管理效率，降低运作成本，增强 企业长期竞争力
通过该系统，公司系统管理人员能实现对回访用户、客户的动态管理；系统管理人员能随时了解回访用户的回访情况；回访用户能记录客户的回访记录；3. 系统面向的用户群体 系统面向产品公司的售后服务管理员，回访用户。 3.1 用户的特征 用户大都具备以下特征： ? 有IE 使用经验 ? 了解网络 ? 了解办公自动化 3.2 用户环境 用户的计算机环境大致如下： ? Microsoft Windows XP ?Microsoft Internet Explorer 6 或更高版本 ? MS Office 办公软件 ? Outlook 或Foxmail 邮件管理 ? Microsoft Windows .NET Framework 2.0 4. 系统的功能性需求 系统包含的功能概括如下表：
产品经理如何应对非功能性产品需求变 更 令人烦恼的非功能性需求变更 在软件开发中，大家都会遇到过这样的问题：客户的一个新想法，就推翻了之前与客户经过再三讨论而确认定下来的需求。如果是功能性需求变更还会让人容易接受一些，毕竟功能性需求不实现的话，是会大大影响到软件产品的质量。但现在我所负责的这个开发项目中遇到的都是一些非功能性的变更,而且许多是看起来无关痛痒的、鸡毛蒜皮的变更。 （1）什么是非功能性需求？ 在IEEE中，软件需求的定义是：用户解决问题或达到目标所需的条件或功能。一般包含业务需求、用户需求、功能需求、行业隐含需求和一些非功能性需求。业务需求反映了客户对系统、产品高层次的目标要求；功能需求定义了开发人员必须实现的软件功能。所谓非功能性需求，是指为满足用户业务需求而必须具有除功能需求以外的特性。包括系统性能、可靠性、可维护性、易用性和对技术和对业务适应性等。其中最常见的是软件界面、操作方便等一系列要求。 （2）非功能性需求变更的特点 让我们从客户角度和开发人员角度去看看非功能性需求的特点。首先，有些非功能性小需求从客户角度看起来工作量不大，但是实际上开发人员要耗费比较长的时间去完成这些小功能。其次，许多非功能性需求，如界面美观、操作方便等都是客户头脑一热、或领导一拍脑袋就部署下去的需求，往往是原来在需求分析阶段所没有注意的内容。
其实，非功能性需求是常常被轻视，甚至被忽视的。原因是非功能性需求描述很困难，它很难像功能性需求那样，可以通过结构化和量化的词语来描述清楚。在描述这类需求时候，我们经常采用软件性能要好、操作要方便、软件界面要美观大方等较模糊的描述词语。例如，易用性就同时涉及到美工和UI界面、人机工程、交互式设计、心理学、用户行为模式等内容。这类描述词语都是脱离了软件的执行环境，是对人和相关的场景的描述，因此很难体现到软件架构设计和具体的实现中。 为什么非功能性需求变更会频繁发生？ 为什么非功能性需求不能固定下来呢？或定下来后就不许变了呢？通常有许多人会问这样的问题。实际上，当他变成了客户时，他可能就不会问这个问题了。（1）非功能性需求容易产生理解分歧 在软件需求分析阶段，客户和开发人员对非功能性需求的理解呈现"大体上共识多，细节上差异多"的特点。一般跟分析员的知识、背景，还有客户表述的标准程度、双方的交流情况有关。即使通过反复沟通，但是以实践经验来看非功能性需求的描述还是永远不够清晰、不够明确的，主要是因为在这个阶段所谓的产品还只存在于大家的大脑构思中。 作为一个客户，大多数情况下是不懂技术的，但他所需要的软件在他的心里还是有一个印象的。他会想象出软件的样子和功能，然后通过口头或者笔头的方式告诉需求分析人员。简单的说，就是在这个阶段用户往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需，或者是他们想象出来的东西。结果是当客户向需求分析人员提出需求的时候，往往是通过自己的想法用自然语言来表达的，这样的表达结果对于真实的需求来
需求分析中需求规格SRS的非功能性需求的考虑因素 * 功能性质量因素：正确性，健壮性，可靠性 * 非功能性质量因素：性能，易用性，清晰性，安全性，可扩展性，兼容性，可移植性正确性 * 正确性是指软件按照需求正确执行任务的能力。“正确性”的语义涵盖了“精确性”。 * 正确性无疑是第一重要的软件质量属性。 * 技术评审和测试的第一关都是检查工作成果的正确性。 * 机器不会主动欺骗人，软件运行出错通常都是人造成的，所以不要找借口埋怨机器有毛病。 健壮性 * 健壮性是指在异常情况下，软件能够正常运行的能力。 * 正确性描述软件在需求范围之内的行为，而健壮性描述软件在需求范围之外的行为。 * 开发者往往把异常情况错当成正常情况而不作处理，结果降低了健壮性。 * 用户才不管正确性与健壮性的区别，反正软件出了差错都是开发方的错。所以提高软件的健壮性也是开发者的义务。 * 健壮性有两层含义：一是容错能力，二是恢复能力。 可靠性 * 可靠性是指在一定的环境下，在给定的时间内，系统不发生故障的概率。 * 可靠性本来是硬件领域的术语。比如某个电子设备在刚开始工作时挺好的，但由于器件在工作中其物理性质会发生变化（如发热），慢慢地系统的功能或性能就会失常。所以一个从设计到生产完全正确的硬件系统，在工作中未必就是可靠的。 * 软件在运行时不会发生物理性质的变化，人们常以为如果软件的某个功能是正确的，那么它一辈子都是正确的。可是我们无法对软件进行彻底地测试，无法根除软件中潜在的错误。平时软件运行得好好的，说不准哪一天就不正常了，如有千年等一回的“千年虫”问题，司空见惯的“内存泄露”问题、“误差累积”问题等等。 * 时隐时现的错误一般都属于可靠性问题，纠错的代价很高。 性能 * 性能通常是指软件的“时间-空间”效率，而不仅是指软件的运行速度。人们总希望软件的运行速度高些，并且占用资源少些。 * 性能优化的关键工作是找出限制性能的“瓶颈”
系统的功能需求分析 开发一个网上体育社区系统，首先需要确定社区要实现的功能是什么，也就是用户想要社区所能做的工作。用户使用社区是按照一定的流程来进行的：用户注册登录进入社区，浏览某个社区版块，通过发帖功能发布新的话题，通过回帖功能回复已有的话题，通过搜索查找已有的话题；管理员要管理社区，系统需要具有的功能有创建、编辑、删除社区的版块，管理注册的用户，管理帖子，设置社区基本参数。这样的功能就决定了社区所应具有的功能。 1.用户注册 进入社区主页面后，对于第一次登录的用户来说，首先需要注册，单击“立即注册”按钮即可进入注册界面,注册完成后返回登录界面。 2.用户登录 只有登录的用户才能进行取得权限，退出应释放权限。 3.分类浏览体育项目 用户可以根据各项运动的类型对社区版块进行详细的浏览。如：篮球、足球、乒乓球、游泳等。 4.用户发帖 已登录到社区主页面的用户可以查看用户的基本信息、更改密码、帖子查询、进入某个社区版块进行发帖。 5.用户回帖 已登录用户可以跟在其他人帖子后回复。 6.管理员功能 管理员成功登录到操作界面后可查看用户的信息、可增添或者删除社区版块、可注销已注册的用户、可查询和删除用户的帖子，可以对帖子置顶或指定精华帖。 7.查找功能 成功登录的用户和管理员能够根据帖子主题或者用户查找相关帖子。
体育社区系统包括以下主要功能模块： 1.注册登录功能模块：用户注册、登录以及修改个人注册信息； 2.浏览功能模块：用户浏览版块、查看帖子； 3.发帖回帖功能模块：用户发帖、回帖、编辑自己发布的帖子； 4.帖子管理功能模块：管理员编辑、删除、置顶和指定精华帖； 5.社区设置功能模块：管理员设置参数； 6.管理版块功能模块：管理员创建、修改和删除版块； 7.用户管理模块：管理员添加、删除和设置用户权限。 用户注册、登录以及修改个人的注册信息组合成注册登录模块；用户浏览版块、查看帖子组合成浏览版块；用户发帖回帖，编辑自己发布的帖子组合成发帖回帖模块；管理员编辑帖子、删除帖子、置顶帖子和指定精华帖组合成管理帖子模块。以上四个模块组成用户使用的基本功能模块。扩展功能模块都是与管理员相关的，设置社区参数单独为社区设置模块；创建、修改和删除版块为管理版块模块；添加、删除和设置权限为管理用户模块。
功能需求分析
项目名称：科学计算器 二○一四年八月二十二日
目录 1.引言 (1) 1.1 编写目的 (1) 1.2 背景 (1) 1.3 参考资料 (1) 2.任务概述 (1) 2.1 目标 (1) 2.2 用户特点 (1) 3.需求规定 (2) 3.1 功能需求 (2) 3.1.1 功能结构图 (2) 3.1.2 输入/输出需求 (2) 3.2 性能需求 (3) 3.2.1 响应时间 (3) 3.2.2 精度需求 (3) 3.3 运行环境需求 (3) 3.3.1 软件环境 (3) 3.3.2 硬件环境 (3) 4.小组成员 (4)
科学计算器项目功能需求分析 1.引言 1.1 编写目的 在日常生活中市民上有很多的计算器，但是功能不能满足个人的需求，并且价格昂贵，操作不便，所以能够通过自己的双手设计开发一个属于自己的计算器是非常有意义的。在Windows XP操作系统的环境下，采用Microsoft Visual C++ 6.0作为开发工具，实现运算操作的主要功能，包括加减乘除，开方，平方等运算功能；还要实现数据的输入，输出，计算，显示及程序退出等功能。另外还可以实现多种科学计算的功能，如：三角函数的计算，角度间的转换，二、十进制的转换等。 主要面向需要进行数据运算，角度转换，二、十进制的转换的用户。 1.2 背景 项目名称：科学计算器 项目设计人员：王洋，杜康，吴静娴，张少文 项目的用户：普通大众 2.任务概述 2.1 目标 开发这个软件是为了实现基本的科学计算器的功能，主要应用于普通的日常生活中遇到的一些问题。四则运算，开方，平方，阶乘，三角函数计算，角度间转换，二、十进制的转换。软件应该能够更好地完
非功能性需求 ) 什么是非功能性需求 非功能性需求是这样一种需求，它解决“如何使这个系统能在实际环境中运行”。 ) 重要吗？ 在设计解决方案的过程中满足功能性需求当然是很重要的。但是，如果没有考虑非功能性需求，那么这个解决方案则很难取得实效，因为用户可能难以甚至无法使用系统的功能。 很多非功能需求一般会在底层的基础技术平台去仔细设计和实现。 ) 非功能性需求要考虑那些方面 非功能性的特性一般有这些： 可靠性 只显示系统可以做某些事情是不够的。如果一个系统不能可靠地运行（例如，在加载时，或者在系统故障时，等等），则它就不能满足客户的需要。 有一些问题应该自问一下： * 即使硬件出现故障，系统也可以可靠运行吗？ * 复制和故障转移方案是什么？ * 需要手动干预，还是系统可以自动进行故障转移？ * 实现可靠性会对性能造成负面影响吗？ * 实现可靠性的成本有多高？ 可靠性需要考虑的一些具体方面是： 安全性：假设攻击者就在外面。如何知道系统用户就是他们所声称的，并只让他们访问经过授权的功能？如何保护我的系统不受攻击？考虑到网络攻击、机器攻击，甚至从您自己的系统内部发起的攻击。 事务性：如何设计系统来保存工作单元的属性？如果在设计中涉及多个独立的子系统（服务和就是这种情况），则这一点就显得特别重要。不要假设始终可以进行两阶段提交 ( )。 可用性 如果用户不能够从他们可用的渠道（例如）方便地访问您的产品，那么它的好处何在呢？这有时是作为功能性的一部分一起考虑（或者应该在理想的环境下）的，但是常常被忽视，以致于整个项目处于危险之中。这里需要考虑的一些问题是： * 您是否为用户带来不适当的负担（例如，需要特殊的浏览器版本）？ * 系统是否根据模型视图控制器 () 体系结构设计以使多用户界面成为可能？如果是这样，如何将它们绑定在一起？ * 是否界面本来就有状态而功能无状态（反之亦然）？ 有效性 如果没有有效地使用资源（例如处理器、内存和磁盘空间），功能性、可靠性和可用性再好的系统最后都会失败。我们经常发现将有效性划分成两个子范围是很有用的，这两个子范围都应该加
XXX村村民交流互动网站系统 设计小组成员：何成龙、陆承林 黄元勇、王永亮 胡荣启 引言： 在计算机技术飞速发展的今天，各类交流网站挤满了互联网，本设计立足于XXX村村民交流互动而设计一个交流网站，网站为村民提供交流服务，村民可以在网上通过发帖聊天交流生活琐事以及农事科技等。 第一章：功能性需求分析 一、在本次设计中，“远程教育网站系统”包括以下功能模块： 1、个人工作台 2、在线浏览 3、资料共享 4、系统管理 5、在线帮助 二、功能描述 1、个人工作台 用户可通过个人工作台对个人信息进行注册和修改。 1.1、用户注册/登陆模块 用户通过注册模块进行注册成为会员，登陆模块为会员完成用户登陆； 1.2、修改信息 在本模块用户可对已填信息进行完善和修改。 2、在线浏览 在线浏览为会员和非会员提供阅读材料以及视频文件，可在线点播及阅读。 3、资料共享 此功能仅为会员提供，非会员无权享受此功能。会员通过此模块可下载所需内容以及上传文
件。 4、系统管理 4.1、后台管理 专为网站管理员开设。网站管理员通过此模块可对网站进行维护和管理。 4.2、网站数据库 主动收集网站各类数据并及时更新。 4.3、信息管理系统 仅为信息管理员提供，可以通过此模块对会员上传的文件进行审核和删除，以及对注册会员进行管理。 5、在线帮助 5.1、联系我们 用户通过此模块就网站存在的问题进行反馈。 6.功能描述文档： 功能编号功能名称功能描述备注 01 注册用户可以通过注册功能进行信息注册成为网站会员 02 登录会员/信息管理员用户通过此登录进行登录网站，登录时会员选择“会员登录”进行登录，信息管理员选择“管理员”进行登录。 03 浏览网页非会员和会员享有的权力，非会员只能浏览不能留言 以及下载上传文件。 04 个人中心一、会员个人中心包含以下内容模块： 1.个人主页 会员在个人主页里可以根据自己喜好设置主页属性； 2.个人信息修改 个人信息修改包括密码修改和基本信息修改； 3.好友 好友模块包含对好友的添加和删除功能，也可以对好友进行喊话；
产品功能需求分析书 学生之家物流管理系统——基于android系统 目录 产品功能需求分析书学生之家物流管理系统——基于android系统 (1) 1. 产品大体框架 (2) 1.1学生下单功能 (2) 1.2接单、代签功能 (4) 1.3扫描入库功能 (6) 1.4学生签收功能 (8) 1
2. 产品实体以及实体功能分析表 (10) 1.产品大体框架 本产品现阶段主要的用途主要有： 1.1学生下单功能：学生可以通过关注学生之家的官方微信公众号实现学生之家帮其代拿快递的功能，通过在公 众号中点击具体的按钮，跳转到具体的页面，首先必须要注册，然后才能够做具体的操作；接着学生通过填写表单（表单内容具体包括学生姓名、联系方式、快件具体的快递公司），学生通过点击确认订单之后订单内容就会上传到服务器，学生还可以可以在工作人员未接单前将订单取消。（此处如果有必要可以实现在线支付功能，如果学生在工作人员未接单之前订单取消，支付金额将会以原金额返回到原处）。 2
3
1.2接单、代签功能：数据上传到服务器之后，学生之家员工通过已经注册分配到的账号密码登陆到本app，就 可以通过实现代签功能查看目前为止有多少学生下了订单，工作人员在每个订单条目中点击接收订单之后服务器可以向用户的微信发送一条信息告知订单已经接收，此时订单不可取消；接着工作人员就可以根据订单情况前往高场或者图书馆代收快件，工作人员通过查看自己已经接收的订单，开始通过手机摄像头扫描要代签的快件的条形码，扫描之后会自动得到快件单号，如果扫描不出，则可以手动输入，接着将该订单从工作人员的已接收订单界面移除，放置到已代签界面中，如果没有找到指定的快件，那么工作人员可以点击代签失败，并填写失败原因：快递公司没来或者是没有指定的快递存在，并且将该订单从从工作人员的已接收订单界面移除，放置到代签失败界面中，同时需要向用户的微信发送签收失败的信息。这个过程中还必须要有的就是撤销功能，当工作人员扫描了一件错误的快件之后错误点击了成功签收，那么就需要有一个撤回功能，将其从成功签收界面中移除，放置回去接收订单界面；在工作人员操作的同时，需要与服务器进行交互，工作人员成功签收或者签收失败都需要记录在服务器中有记录。 4
需求分析与测试的重要性 读《软件工程案例教程》有感 对于学习软件工程这门课程，我认为有许多东西要学习。其实在我看来学习这门课程的精髓是学习一种方法。是一个如何去分析和处理问题的过程，应该说其范畴已经远远不止局限于该门课程，成为了一个综合的一个能够解决问题的思想集合。读完软件工程案例教程这本书，我觉得自己受益匪浅。 整本书的内容逻辑很清晰明了，由浅入深循序渐进，首先我就大概描述下我们所学的内容，第一章是从整体分析软件工程这门学科的发展和所处的社会环境，接着后面的几章深入分析了软件开放过程和模式、软件项目管理、计算机工程、需求分析、结构化分析建模以及基于UML面向对象分析建模和测试等。对于这本书我主要对需求分析和测试比较感兴趣，在这我要着重的谈一些自己的心得体会以及自己的看法。 一．需求分析 1.1需求分析的重要性 一款成功的软件是建立在成功的需求分析之上的，而高质量的需求来源于用户与开发人员之间有效的沟通与合作。当用户有一个问题可以用计算机系统来解决，而开发人员开始帮助用户解决这个问题，沟通就开始了。由此我们可以看出需求分析的重要性。 需求获取可能是最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往有错误的认识：用户知道需求是什么，我们所要做的就是和他们交谈从他们那里得到需求，只要问用户系统的目标特征，什么是要完成的，什么样的系统能适合商业需要就可以了，但是实际上需求获取并不是想象的这样简单，这条沟通之路布满了荆棘。首先需求获取要定义问题范围，系统的边界往往是很难明确的，用户不了解技术实现的细节，这样造成了系统目标的混淆。 其次是对问题的理解，用户对计算机系统的能力和限制缺乏了解，任何一个系统都会有很多的用户或者不同类型的用户，每个用户只知道自己需要的系统，而不知道系统的整体情况，他们不知道系统作为一个整体怎么样工作效率更好，也不太清楚那些工作可以交给软件完成，他们不清楚需求是什么，或者说如何以一种精确的方式来描述需求，他们需要开发人员的协助和指导，但是用户与开发人员之间的交流很容易出现障碍，忽略了那些被认为是"很明显"的信息。最后是需求的确认，因为需求的不稳定性往往随着时间的推移产生变动，使之难以确认。为了克服以上的问题，必须有组织的执行需求的获取活动。 1.2需求分析的原则 （1）需求分析必须能够表达和理解问题的数据域和功能域。数据域包括数据流、数据内容和数据结构，而功能域反映上述3方面的控制信息。 （2）需求分析要把一个复杂问题按功能进行分解并逐层细化。通常，软件系统要处理的问题如果太大、太复杂就很难理解，若划分成几部分，并确定各部分间的接口，就可完成整体的功能。在需求分析过程中，软件系统的用户需求中的数据、功能和行为都应细化。 （3）需求建模。模型可以帮助系统分析人员更好地理解软件系统的数据、功能和行为，这些模型是软件工程中下一阶段进行系统设计的基础。 1.3需求分析的注意事项
释放办公激情，效能触手可及嘉为IT咨询培训0 非功能性需求——性能需求分析 软件的非功能性需求是衡量软件质量很重要的一个因素，同时也决定了功能相似的条件下不同软件的价格。比如，一个同时能处理一万用户请求的网站的技术要求和一个没考虑过这方面问题的网站相比就有天壤之别。然而实际工作中，非功能性需求却常常被忽略，或者制定得非常随意。那么非功能性需求应该怎么制定，又如何验收呢？ 下面我们以常见的非功能性需求——性能需求为例，介绍一下非功能性需求应该怎么制定和验证。 在许多网站开发项目中我们都会在合同或者招标说明中看到“本网站必须能同时满足多少用户的使用”，这就是一个针对性能的非功能性需求，不过这个需求定义的非常不专业。 首先，对于一个服务器系统来说同时在线的用户，或者并发用户数并不是一个清晰的概念。在线用户或者更具体的——和服务器保持连接的用户，如果不进行操作，那么除了占用一点服务器内存外没有任何开销。用户只有执行了向服务器发起请求在操作，服务器才需要消耗CPU、硬盘、网络和更多的内存资源来响应这些请求。因此性能指标应该使用每秒请求数来标定。虽然每秒请求数通常和并发用户数成正比，但由于应用不同、用户使用方式不同等原因。即使是同类型网站并发用户数和每秒请求数的比例也有很大的差别。具体的数字是多少就需要进一步的需求分析才能确定。 其次，这个需求没有限定系统响应时间。响应时间是性能需求中另一个重要指标。正确的性能需求是通常以一定平均响应时间条件下服务器的极限指标来描述的。 好了，我们知道制定性能需求需要每秒请求数和响应时间两个数值。那么这两个数值如何制定才合理呢？需要注意的是性能指标不是越高越好，高性能通常需要复杂的实现技术、更高的部署成本和更多的维护工时。因此制定性能需求绝对不能拍脑袋。 做性能需求分析通常有这么几个步骤： 1、确定参照系统 2、测量参照系统的性能指标 3、预测目标系统 4、计算目标系统性能指标 参照系统是一个和目标系统类似并且已经存在的系统。通常将要被目标系统替换的老系统就是一个很好的参照系统。需要注意的是如果新系统的业务或者技术基础变化很大，那么旧系统未必是一个好的参照系统。 测量参照系统的性能指标通常比较容易，比如对于IIS网站来说，打开日志记录至少一个业务周期（比如一周）或者几个典型时段的数据，然后可以使用各种专业工具进行分析。从这些日志我们很容易得到所谓的用户数和每秒请求数的关系，以及系统响应时间等参数。简单的统计有时甚至通过自行编写的程序来完成。 有了基本的参照数据，那么接下来拍脑袋决定的目标系统预测也会相对靠谱。最后计算目标系统的指标就是一些普通的算术问题了。
*功能需求和非功能需求* 软件产品的需求可以分为功能性需求和非功能性需求，其中非功能性需求是常常被轻视，甚至被忽视的一个重要方面。其实，软件产品非功能性定义不仅决定产品的质量，还在很大程度上影响产品的功能需求定义。如果事先缺乏很好的非功能性需求定义，结果往往是使产品在非功能性需求面前捉襟见肘，甚至淹没功能性需求给用户带来的价值。 所谓非功能性需求，是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。软件产品的非功能性需求包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。下面对其中的某些指标加以说明。 1．系统的完整性 系统的完整性指为完成业务需求和系统正常运行本身要求而必须具有的功能，这些功能往往是用户不能提出的，典型的功能包括联机帮助、数据管理、用户管理、软件发布管理和在线升级等。 并不是所有的系统都必须包括以上所有的功能，而是可以根据产品的使用环境和企业的产品发展决策进行挑选。例如，在线升级、软件发布管理适用于具有Internet或内网环境的软件产品；数据管理对于产生数据存储的产品则是必须的，设计人员不应假设用户同时是一个合格的DBA。而且系统所产生信息的分布和关系，也不是DBA所应该了解的内容。因此完整的系统应该包括数据备份、恢复、日志管理及垃圾数据清除等基本功能，哪怕这些功能的核心只是一条语句或命令；用户管理功能是另一项必不可少的功能，它定义哪些用户可以以什么样的功能使用系统。好的用户管理功能不仅可以有效控制用户对系统的使用，使系统处于一个安全且负载合理的运行状况，还能提高系统的应用适应性。 2．系统的可扩充性与可维护性 指系统对技术和业务需求变化的支持能力。当技术变化或业务变化时，不可避免将带来系统的改变。不仅要进行设计实现的修改，甚至要进行产品定义的修改。好的软件设计应在系统架构上考虑能以尽量少的代价适应这种变化，常用的技术有面向对象的分析与设计及设计模式。 3．技术适应性与应用适应性 系统的适应性与系统的可扩充性和可维护性的概念相似，也表现产品的一种应变能力，但适应性强调的是在不进行系统设计修改的前提下对技术与应用需求的适应能力，软件产品的适应性通常表现为产品的可配置能力。好的产品设计可能要考虑到运行条件的变化，包括技术条件（网络条件、硬件条件和软件系统平台条件等）的变化和应用方式的变化，如在具体应用中界面的变化、功能的剪裁、不同用户的职责分配和组合等。 对以上重要的非功能性需求进行逐一分析后，即可开始进行产品功能设计。实际上，非功能性需求定义将反映到系统的功能设计中，表现为系统的架构。
图书管理系统功能需求分析 在图书管理系统中，不外乎三个：读者、图书、管理人员。图书管理、借书、还书等是系统的基础业务。而图书馆网络管理系统可向读者提供图书查询和电子图书的服务等，用户则对图书的查询、借阅，电子图书网上阅读功能操作；管理员可对系统用户任意分配权限，控制图书的流通，它能使图书馆工作人员从繁重的工作中解脱出来，大大减轻了工作量，减少人为的工作失误，全面提高图书馆的管理效率及服务质量，从而使图书管理水平和业务跃上一个新的台阶。 图书管理系统应具备以下两个特点： 1、系统应用和系统管理相结合 在系统中，用户可以对图书进行查询、查阅、借和还等操作，管理员可以对用户和图书进行分配权限，控制图书的流通。 2、图书的管理和阅读相结合 图书管理系统应具备以下主要功能： 1、馆员管理 维护馆员信息，有查询、添加、修改、删除功能。馆员身份不同，分别对应不同的操作权限。超级管理员拥有系统维护、数据库维护的权限；一般管理员负责不同的日常工作模块；馆长拥有一切权限。馆员类别划分加强系统安全性。
2、码表维护 维护各种码表，包括：国家码表、语种码表、出版商码表、丛书码表、编辑类型码表、版本码表、图书大小码表。对码表可进行添加、修改、删除操作。 3、修改密码 输入当前馆员旧密码、新密码，检查输入完整性，如果旧密码输入不正确，则不能修改。密码录入时以符号（*）显示，密码加密后保存到数据库，以保证数据安全性。 4、编目设定 编目操作过程中，需要设定一定参数，以保证系统正常运行。可以选择设定里的"是否自动产生索书号、流通号"等，如果选择为真，则由系统按一定的算法得出索书号、流通号，并且保证数据唯一性；如果为假，则由操作馆员录入。虽然系统能自动判断号码的唯一性，但有可能进行多次修改才能保证不重复，增加了数据输入量。保留字段和加载默认值可以在录入信息时，自动加载某些数据，以减少人工录入的工作量。编目设定就是保留这些设定，并且在系统配置文件中保留最近一次设置，下次进入系统时自动加载各项设定。 5、编目管理 编目管理是系统最主要的组成部分之一，主要是维护书目基
〈项目名称〉业务需求-非功能性需求 版本 <1.0> 文档编号： 当前版本： 1.0 修改日期：
修订文档历史记录
目录 1.简介4 1.1目的4 1.2范围4 1.3定义、首字母缩写词和缩略语4 1.4参考资料4 2.性能4 2.1交易响应时间4 2.2用户数5 2.3吞吐量需求5 2.4数据存储容量6 3.可扩展性6 4.伸缩性6 5.安全性7 5.1应用安全性需求7 5.1.1认证与授权服务7 5.1.2资源访问控制服务7 5.1.3应用日志7 5.2基础级安全需求7 5.2.1防火墙保护7 5.2.2防病毒服务7 5.2.3数据安全7 5.2.4入侵检测及漏洞扫描7 5.2.5数据传输服务7 6.可用性7 7.易用性8 8.可靠性8 8.1计划维护服务时间8 8.2单点故障对系统的影响程度8 8.3可恢复性8 8.3.1停机恢复8 8.3.2程序和数据的备份8 8.3.3灾难恢复8 9.业务约束9 9.1<业务约束-001>业务组织架构9 9.2<业务约束-002>语言要求9 10.技术约束9 10.1<技术约束-001>客户端规范9 10.2<技术约束-002>服务器规范9 10.3<技术约束-003>网络环境规范10 10.4<技术约束-004>外设规范10 10.5<技术约束-005>开发规范10
[说明：文档模板中蓝字部分为模板说明和示例，黑字部分为内容要求。黑字部分不允许删除，对于对项目不适用的部分，在相应的章节中进行说明。] 1.简介 1.1目的 [阐明业务需求文档中，非功能性需求文档的目的。] 1.2范围 [包括所有的非功能性需求。] 1.3定义、首字母缩写词和缩略语 [本小节应提供正确理解此非功能性需求文档所需的全部术语、首字母缩写词和缩略语的定义。这 些信息可以通过引用项目词汇表来提供。] 1.4参考资料 [列出与本业务有关的一些参考资料，以备出现业务疑问时，可以方便地追根溯源。每个文档应标 有标题、报告号（如果适用），如需要，列出文档的日期和发布组织。列出可从中获取这些引用的来 源。这些信息可以通过引用附录或其他文档来提供。] 2.性能 [与性能有关的非功能需求由以下几个单独的子需求组成：] 2.1交易响应时间 [交易可以定义为：一个交易是指一个单一角色跨越系统边界触发一个事件并执行一定数量的处 理和数据库访问。交易响应时间指完成目标系统中的交互或批量处理所需的响应时间。 根据业务处理类型的不同，本规范把交易划分为三类：交互类业务、查询类业务和大数据量批 处理类业务，并根据交易类别分别给出响应时间要求的参考值，包括峰值响应时间、平均响应时间。] ●交互类业务 [交互类业务的响应需求。] ●查询类业务 [查询类业务的响应需求，可以包括一些对信息进行分析的需求。] ●大数据量、批处理业务
功能需求分析 STI5202方案 STi5202是高清晰音视屏解码芯片，内部包括视频解码器，音频解码器，数据输入，Gamma显示合成器，Gamma 2D图形处理器，视频显示处理器，显示输出，接口。比起其他音视频解码芯片其主要特点有： 1)视频解码器 a)支持H.264/AVC编码标准和MPEG-2标准 b)支持Flash视频、DivX和视频会议标准，以及中国最近确立的 AVS1-P2 基准档次4.0级(SD)视频解码标准。 c)多流解码器，解码速率为315000宏块/秒（等价于解码一个SD视 频流的7.78倍），可同时解码如下组合： i.五个SD流。四个用于主显示窗中显示，一个作为PIP或用于 VCR录像。 ii.一个HD和一个SD或2个HD流。一个HD流用于在主显示窗中显示，另一个HD流或SD流作为PIP显示或用于VCR录像（目 前版本的STi5202只能支持一个HD和一个SD流的解码或两个 SD流的解码）。 2)音频解码器 a)支持所有的音频广播标准 b)杜比数字,MPEG-1层I、II和III（MP3）,MPEG-2层II，MPEG-2 AAC c)六声道主音频数字输出 d)两声道辅助音频数字输出
e)S/PDIF输出 f)PCM混合和采样速率变换 3)数据输入 a)可同时接收五路视频压缩码流和两路音频压缩码流。 b)高清RGB/YCbCr数字输入 c)2个标清YCbCr数字输入 d)2个PCM音频输入 4)Gamma显示合成器 a)7通道数字混合器MIX1，用于主HDTV输出。7个显示平面包括： 一个背景平面；三个图形/视频层GDP1、GDP2和GDP3；两个视频 平面；一个光标平面 b)独立的2通道混合器MIX2，用于辅助TV显示或VCR c)硬件光标 d)视频捕捉流水线 e)Alpha平面附加 f)抖动处理器 5)Gamma 2D图形处理器 a)双源图形处理器，独立于CPU，加速图形处理 b)Alpha混合和逻辑操作 c)颜色空间和格式变换 d)快速颜色填充 e)高质量的滤波器，进行任意尺寸调整
B2C电子商务平台功能需求分析 1 网站后台管理基本需求 1.1 商品管理功能： 后台实现商品管理，前台商品展示。商品种类及商品属性可以自由定义，能满足产品行业特点。 1.1.1 商品列表：对添加的产品进行编辑、修改、删除、排序等操作。 1.1.2 添加新商品： 1.1.3 商品分类：采用多级分类，适用于食品等行业，可以把不同产品线的产品分类属性添加到系统中 1.1.4 用户评论：用以管理用户对每个单品的评论，可以进行删除、是否显示操作 1.1.5 商品品牌：对商品品牌进行设置 1.1.6 商品类型：商品的类型和商品信息的展示是整个商品浏览过程中最重要的模块。采用动态商品分类和特色分类相结合的方式，如下：所有分类将在后台设计独立的商品分类设置，后台分类编辑修改后，前台分类下的商品将实现自动更新。分类可以自定义多种特有属性，例如数码相机、笔记本电脑、台式机、存储设备、mp3/mp4等，该类商品会自动显示该属性，新建产品时可以复制已有产品基本内容（除无法复制产品编号），产品描述，产品特性。 1.1.7 商品回收站：商品删除后直接进入回收站，用户误删除的产品信息可由此恢复。 1.1.8 标签管理：利于搜索引擎收录和网站导航； 1.1.9 产品功能：可以设定热卖产品,促销产品,最新产品,缺货产品(缺货通知,)同时可以实现产品的关键字设定 1.2. 促销管理： 团购活动、优惠活动：数量折扣，捆绑销售，赠品等；拍卖活动； 1.3 订单管理功能： 顾客在前台提交了订单之后，可以在其会员口内查询订单的处理进程，网上商城系统的后台订单处理包括订单审核、财务处理、物流处理等内容。 1.3.1 订单列表：在此可以对订单进行操作，如查询、撤销、修改等
B2C 电子商务平台功能需求分析 1网站后台管理基本需求 1.1商品管理功能： 后台实现商品管理，前台商品展示。商品种类及商品属性可以自 由定义，能满足产品行业特点。 1.1.1商品列表：对添加的产品进行编辑、修改、删除、排序等操作。 1.1.2添加新商品： 1.1.3商品分类：采用多级分类，适用于食品等行业，可以把不同产品线的产品分类属性添加到系统中 1.1.4用户评论：用以管理用户对每个单品的评论，可以进行删除、是否显示操作 1.1.5商品品牌：对商品品牌进行设置 1.1.6商品类型：商品的类型和商品信息的展示是整个商品浏览过程中最重要的模块。采用动态商品分类和特色分类相结合的方式，如下：所有分类将在后台设计独立的商品分类设置，后台分类编辑修改后，前台分类下的商品将实现自动更新。分类可以自定义多种特有属性，例如数码相机、笔记本电脑、台式机、存储设备、mp3/mp4 等，该类商品会自动显示该属性，新建产品时可以复制已有产品基本内容（除无法复制产品编号），产品描述，产品特性。 1.1.7商品回收站：商品删除后直接进入回收站，用户误删除的产
品信息可由此恢复。 1.1.8标签管理：利于搜索引擎收录和网站导航； 1.1.9产品功能：可以设定热卖产品, 促销产品, 最新产品, 缺货产品（缺货通知,）同时可以实现产品的关键字设定1. 2. 促销管理： 团购活动、优惠活动：数量折扣，捆绑销售，赠品等；拍卖活动； 1.3订单管理功能： 顾客在前台提交了订单之后，可以在其会员口内查询订单的处理进程，网上商城系统的后台订单处理包括订单审核、财务处理、物流处理等内容。 1.3.1订单列表：在此可以对订单进行操作，如查询、撤销、修改等 1.3.2待发货订单 1.3.3订单日志 1.4 系统设置 1.4.1 网店设置：网站系统设置、基本信息设置、评价体系设置； 1.4.2支付方式：以插件形式支持会员整合，支持支付宝、余额支付、贝宝、财付通、货到付款、快钱、网银、银行汇款转账等多种支付方式. 1.4.3配送方式以插件形式支持会员整合，支持顺丰、申通、中通、圆通、EMS E邮宝、上门取货等配送方式 1.4.4地区列表：中国地区列表，为支付系统提供地区接口；
如何分析APP功能需求及结构 APP分析过程在项目管理体系PMBOK中归属于项目范围定义（Define Scope）过程。从PMBOK的角度来看，在完成需求收集（Collect Requirements）后，需要对项目和产品的详细范围进行描述，清晰完整的项目/产品范围说明书有利于制定出具有良好执行性的WBS（Work Breakdown Structure），但其更为重要的意义在于科学的构建了用户所需要的系统功能架构。 从业务演变到系统的角度来看，APP是业务在系统的具体呈现，APP的分析过程是将业务语言翻译为机器语言的表现。只不过这不是普通的翻译，是包含了智力和经验的过程。所以，对于计算机信息领域的技术专家来说，更需要去学习和掌握跨领域的业务语言，并在不同领域的交界处形成明确的定义，实现不同语言间的准确对应。 举个例子，假设在电子商务领域里有一个业务，我们称之为A：用户通过网站填写了一份购买汽车坐垫的订单，付款成功后可以通过连接电脑的打印机自动打印一份A4幅面标准格式的确认单。那么在信息系统的世界里，A被翻译为：1、用户通过web表单填写完订单内容后；2、在线支付。2.1、如果支付不成功，系统提示用户哪里出现错误，并引导用户修正错误。2.2、如果支付成功，系统提示用户：订单已经生效，系统即将打印确认单。3、系统传递打印控制信息，打印机负责打印出指定格式的文件。4、系统提示交易完成。 上面的例子说明了不同的领域有不同的表达标准，想要在不同领域都能准确表达同一个意思，将是非常困难的事情。 在计算机领域，信息系统的APP的设计过程非常的复杂，不只是纯粹的描述计算机处理流程那么简单，还包括了抽象过程（建模过程），设计过程（包括
非功能性需求 1) 什么是非功能性需求 非功能性需求是这样一种需求，它解决“如何使这个系统能在实际环境中运行”。 2) 重要吗？ 在设计解决方案的过程中满足功能性需求当然是很重要的。但是，如果没有考虑非功能性需求，那么这个解决方案则很难取得实效，因为用户可能难以甚至无法使用系统的功能。 很多非功能需求一般会在底层的基础技术平台去仔细设计和实现。 3) 非功能性需求要考虑那些方面 非功能性的特性一般有这些： 可靠性 只显示系统可以做某些事情是不够的。如果一个系统不能可靠地运行（例如，在加载时，或者在系统故障时，等等），则它就不能满足客户的需要。 有一些问题应该自问一下： * 即使硬件出现故障，系统也可以可靠运行吗？ * 复制和故障转移方案是什么？ * 需要手动干预，还是系统可以自动进行故障转移？ * 实现可靠性会对性能造成负面影响吗？ * 实现可靠性的成本有多高？ 可靠性需要考虑的一些具体方面是： 安全性：假设攻击者就在外面。如何知道系统用户就是他们所声称的，并只让他们访问经过授权的功能？如何保护我的系统不受攻击？考虑到网络攻击、机器攻击，甚至从您自己的系统内部发起的攻击。 事务性：如何设计系统来保存工作单元的 ACID 属性？如果在设计中涉及多个独立的子系统（Web 服务和 SOA 就是这种情况），则这一点就显得特别重要。不要假设始终可以进行两阶段提交 (two phase commit)。 可用性 如果用户不能够从他们可用的渠道（例如 Web）方便地访问您的产品，那么它的好处何在呢？这有时是作为功能性的一部分一起考虑（或者应该在理想的环境下）的，但是常常被忽视，以致于整个项目处于危险之中。这里需要考虑的一些问题是： * 您是否为用户带来不适当的负担（例如，需要特殊的浏览器版本）？ * 系统是否根据模型-视图-控制器 (Model-View-Controller) 体系结构设计以使多用户界面成为可能？如果是这样，如何将它们绑定在一起？ * 是否界面本来就有状态而功能无状态（反之亦然）？ 有效性 如果没有有效地使用资源（例如处理器、内存和磁盘空间），功能性、可靠性和可用性再好的系
需求分析与功能建模方法 (总分：40.00，做题时间：90分钟) 一、{{B}}选择题{{/B}}(总题数：40，分数：40.00) 1.软件开发人员开发软件产品的依据应该是______。 （分数：1.00） A.软件需求规格说明书√ B.可行性分析报告 C.标准说明书 D.项目合同 解析：[解析] 软件开发人员应该依据软件需求规格说明书开发软件产品，所以本题的答案为A。 2.在DFD建模方法中用平行四边形表示的基本对象是______。 （分数：1.00） A.数据源及数据终点√ B.数据流 C.数据存储 D.处理 解析：[解析] 数据源及数据终点表示当前系统的数据来源或数据去向，可以是某个人员、组织或其他系统，它处于当前系统范围之外，所以又称它为外部项，其图形符号用平行四边形表示，所以本题的答案为A。选项B数据流用标有名字的箭头表示，选项C数据存储分用指向或离开的箭头表示对存储数据的存取。选项D处理用矩形框表示。 3.在DFD建模方法中用矩形框表示______。 （分数：1.00） A.数据源及数据终点 B.数据流 C.数据存储 D.处理√ 解析：[解析] 在DFD建模方法中用矩形框表示的是处理。所以本题的答案为D。选项A数据源及数据终点用平行四边形表示，选项B数据流用标有名字的箭头表示，选项C数据存储分用指向或离开的箭头表示对存储数据的存取。 4.在需求分析阶段，结构化分析和建模方法是一种较为有效的需求分析方法，下列不属于结构化分析和建模方法优点的是______。 （分数：1.00） A.用图形化的模型能直观地表示系统功能 B.可避免过早陷入具体细节 C.图形对象不涉及太多技术术语，便于用户理解模型 D.从局部或子系统开始分析问题，便于建模人员了解业务模型√ 解析：[解析] 结构化分析及建模方法的主要优点是：①不过早陷入具体的细节。②从整体或宏观入手分析问题，如业务系统的总体结构，系统及子系统的关系。③通过图形化的模型对象直观地表示系统要做什么，完成什么功能。④图形化建模方法方便系统分析员理解和描述系统。⑤模型对象不涉及太多技术术语，便于用户理解模型。 5.评审委员会评审的依据应该是系统功能模型和______。 （分数：1.00） A.软件需求说明书√ B.可行性分析报告 C.标准说明书 D.项目合同 解析：[解析] 评审的依据主要是系统的功能模型和需求说明书中描述的内容，所以本题的答案为A。