需求分类
业务需求：
客户对于系统的高层次目标要求(high-level objectives) ，定义了项目的远景和范畴(vision and scope)。
· 业务：属于哪类业务范畴？应完成什么功能？为何目的？
· 客户：软件为谁服务？目标客户是谁？
· 特性：区别于其他竞争产品的特性是什么？
· 价值：价值体现在哪些方面？
· 优先级：功能特性的优先级次序是什么？
[例]“图书资料管理系统”的业务需求
该系统使用计算机实现图书资料的日常管理，提高工作效率和服务质量。
该系统可让用户在网络上查询与浏览电子资料，改变原有借阅模式。
由于版权的限制，某些电子资料只能浏览/打印，但不能下载。
用户需求(User Requirements)：
从用户角度描述的系统功能需求与非功能需求，通常只涉及系统的外部行为而不涉及内部特性。
[例]用户可以通过Internet随时查询图书信息和个人借阅情况，并可以快速查找和浏览需要的电子资料：
[功能需求]用户通过Internet查询图书信息。
[功能需求]用户通过Internet浏览个人借阅情况。
[功能需求]用户通过Internet查找和浏览电子资料。
[非功能需求]随时、快速。
业务需求与用户需求的对比
业务需求
· 由于实行学分制管理，学校领导希望用计算机管理学生选课。
· 课程信息维护、选课管理、课程成绩登记和查询等业务全部由手工方式改为计算机应用。
用户需求
· 教务管理员希望能够增加、修改和删除学校的课程目录，并且设置各学期课程的开设信息。
· 学生希望能够在学期开始之前查询所有开设课程的详细信息，并能够通过校园网进行选课。
· 学生希望在选课期间系统能够24小时使用，系统使用方便快捷。
功能需求(Functional Requirements, FR)：
系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，不考虑系统内部的实现细节。
[例]：
· 用户可从图书资料库中查询或者选择其中一个子集。
· 系统可提供适当的浏览器供用户阅读馆藏文献。
· 用户每次借阅图书应对应一个唯一的标识号，它被记录到用户的账户上。
非功能需求(Non-Functional Requirements, NFR)：
从各个角度对系统的约束和限制，反映了客户对软件系统质量和性能(quality and performance)的额外要求，如响应时间、数据精度、可靠性等。
[例]：
· 系统在20秒内响应所有的请求。
· 系统应该每周7天、每天24小时都可使用。
· 对一个没有经验的用户而言，经过2小时培训即可使用系统的所有功能。
注意：非功能需求隐含了对可选设计方案的一些关键影响。
· 体系结构设计(e.g., 体系结构风格选择)。
· 算法设计(e.g., 排序策略的选择)。
非功能需求的度量
NFR：检验起来非常困难，一般采用一些可度量的特性进行描述：
约束条件(Constraints)：
系统设计和实现时必须满足的限制条件，对其进行权衡或调整是相当困难的，甚至是不可能的。
例如：
· 系统必须用C++或其他面向对象语言编写。
· 系统用户接口需要采用图形化界面。
· 一个特定应用所消耗的可用计算能力平均不超过50%。
· 系统开发过程和交付文档需遵循GB/T 8567-2006标准。
· 通讯接口必须符合ISO七层架构。
业务规则(Business Rule)：
对某些功能的可执行性或内部执行逻辑的一些限定条件。
通常表达为“如果…，那么…”的形式。
通常是一些容易发生变化的功能。
例如：
· 如果借书卡类型为“教师”，那么一次借阅的最大数量为8本。
· 如果订单金额大于10000元，那么该订单的折扣为10%。
· 如果采购单金额在10万到50万之间，那么需要总经理审批。
· 如果开具了药品A，并且病人年龄在65岁以上或12岁以下，其总剂量不能超过20片。
· 如果开具了药品B，那么不能同时开具药品C或D。
· 如果开具了检查项目M和N，那么就无需开具检查项目P。
· 同一处方中不能开具5种以上的药物或3项以上的检查。
外部接口需求(External Interface Requirement)：
描述系统与其所处的外部环境之间如何进行交互，包括：
用户接口需求(UI)，硬件接口需求，软件接口需求，通信接口需求。
例如：
· “从<某些设备>读取信号”
· “给<其它系统>发送消息”
· “以<某种格式>读取文件”
· “能控制<某些硬件>”
· “采用<某种类型的>用户界面”
好的需求应具备的特征：
完整性：每一项需求都必须将所要实现的功能描述清楚。
正确性：每一项需求都必须准确地陈述其要开发的功能。
可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
必要性：每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。
划分优先级：给每项需求、特性或使用实例分配一个实施优先级以指 明它在特定产品中所占的分量。
无二义性：对所有需求说明的读者都只能有一个明确统一的解释。
可验证性：检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现。
需求获取例子：
用户的想法：（1）现在每个人都在使用多个社交网络服务（SNS-Society Net Service）（电话、短信、微博、微信、QQ、人人、LinkedIn 等等），它们均可帮助在人与人之间建立同步或异步的联系；但是每个人使用这些服务的习惯不同，通过哪个 SNS 能在特定时刻最方便的联系到某个朋友？（2）如果能够有一个软件，可以根据用户与朋友们的历史社交记录，统计分析出每个朋友对 SNS 的使用习惯，从而在该用户试图与某个朋友交互时，自动推荐最可能实时联络到该朋友的社交网络服务，就最好不过了。
要求：你扮演需求获取人员，请你的同学（或者你自己）扮演用户，模拟上述访问用户的过程，最终形成需求清单：业务需求、功能需求、非功能需求、约束条件、接口需求等。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
