软件工程第三章需求工程

1、软软 件件 工工 程程第第3讲：讲：软件需求本讲主题本讲主题 什么是软件需求？客户要你为他开发一个什么样的软件。 需求分析过程 如何启动需求分析过程软件需求软件需求 功能需求：描述系统预期提供的功能或服务对系统应提供的服务如何对输入做出反应系统在特定条件下的行为 非功能需求：指那些不直接与系统具体功能相关的一类需求产品需求机构需求外部需求 领域需求：源于系统的应用领域需求功能需求功能需求 软件系统的功能需求描述可以有许多方式：文字描述图表表示 功能需求可以以不同的详细程度反复编写和细化 功能需求描述应该完整而且一致和准确完整性意味着用户所需的所有的服务应该全部给出描述一致性意味着需求描述不能前

2、后矛盾准确性是指需求不能出现模糊和二义性的地方功能需求描述：出卷系统 教师能够根据自己的要求手动或自动出一份试卷； 教师可以修改试卷中不合适的题目，并能自动生成各种样式的试卷； 教师可以对试题中的题目进行更新。非功能需求非功能需求 非功能需求主要与系统的总体特征相关，是一些限制性要求，是对实际使用环境所做的要求性能要求可靠性要求安全性要求可用性要求移植性要求 非功能需求关心的是系统整体特征而不是个别的系统的特征，比功能需求对系统更关键。 非功能需求却很难检验 非功能需求与功能需求有时会发生冲突，它们之间存在着相互作用关系非功能需求举例非功能需求举例 一个POS系统所需的存储因为成本原因有所限制

3、，而商品的描述和价目表的信息量很大。 如果采用远程服务器，提供商品描述和价目表信息，那必然需要网络通信，而这需要网络技术。 当POS机数量多时必然引起服务器处理瓶颈问题。领域需求领域需求 领域需求反映应用领域的基本问题，直接影响到系统的可用性。 例如：图书馆系统的功能需求基于标准用户界面将一些文档输出到本地打印机或网络打印机上，但因为版权限制，这些文档打印之后应立即删除。领域需求示例：短信系统 如果短信经过终端无线模块发送之前必须经过短消息协议标准编码才能发送出去。 要对短信编码，必须要对由ESTI制订的SMS规范有所了解。技术实现(含编码方式)GSM 03.38、GSM 03.40SMS的D

4、TE-DCE接口标准(AT命令集)：GSM 07.05 三种方式来发送和接收SMS信息：Block ModeText Mode：纯文本方式，可使用不同的字符集，也可用于发送中文短消息，主要用于欧美地区。PDU Mode：PDU Mode被所有手机支持，可以使用任何字符集，这也是手机默认的编码方式软件需求管理过程 需求获取 需求定义 需求分析编写需求规格说明书 需求验证 需求变更控制获取需求 项目合同项目中对项目的范围、主要功能性能指标进行规定 行业规范和相关政策例如中国移动BOOS规范，中国银联直联POS终端规范，全国银行IC卡密钥管理规则，全国教育信息化建设安全技术体系规划等。 市场分析报告

5、由市场部或专门的部门提供的市场分析数据和用户特征分析报告（IDC、Gartner、赛迪顾问(CCID)、计世资讯 ） 咨询公司由咨询公司提供业务分析报告 需求调研市场需求调研直接用户的需求调研需求定义 对获取的需求进行整理 需求识别需求分配需求范围划分识别真实需求 需求文档化 需求确定提交需求确定表给客户客户对需求进行确定，依次作为需求分析的依据需求分析 构建分析模型（对需求的理解）数据模型（E-R实体关系图）、业务流程模型（数据流图）、过程控制模型（活动状态图） 创建开发原型 （原型生命周期） 分析需求的可行性 确定需求优先级 编写数据字典 （数据库设计） 应用质量功能调配 将系统特性、属性

6、与对客户的重要性联系起来，提供了一种分析方法以明确哪些是客户最为关注的特性 编写需求规格说明书 采用模版 在你的组织中要为编写软件需求规格说明书等文档定义一种标准模板 指明需求来源 了让所有项目风险承担者明白需求规格说明书中为何提供这些功能需求，要能追溯每项需求的来源 为每项需求注上标号 记录业务规范 关于系统的操作原则，比如谁能在什么情况下采取什么动作,将这些编写成需求规格说明书中的一个独立部分，或一独立的业务规范文档 创建需求跟踪矩阵 建立一个矩阵把每项需求来源、定义与实现、测试它的设计和代码部分联系起来,这样有利于需求的管理和需求变更影响范围的评估 需求验证 审查需求文档 组织一个由不同

7、代表（如用户，分析人员，设计人员，测试人员）组成的小组，对需求规格说明书及相关模型进行仔细的检查和评审 依据需求编写测试用例 根据用户需求所要求的产品特性写出系统的功能测试用例作为系统测试依据 编写用户手册 描述每项功能是如何对应实际的业务过程 确定合格的标准 描述什么样的产品才算满足用户的要求和适合他们使用的 需求变更控制 确定变更控制过程 确定一个选择、分析和决策需求变更的过程,所有的需求变更都需遵循此流程 建立软件变更控制委员会(SCCB，Software Change Control Board)组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来评估和确定需求变更 进行变更

8、影响分析 跟踪变更影响的产品 当进行某项需求变更时，参照需求跟踪矩阵找到相关的其它需求、设计文档、源代码和测试用例 建立基准和控制版本 维护变更的历史记录 跟踪每项需求的状态 包括确定、已实现、暂缓、新增、变更等 衡量需求稳定性 记录需求的数量和每周或每月的变更（添加、修改、删除）数量 启动分析过程启动分析过程 确定共利益者：直接或间接从正在开发的系统中获益的人。例如，POS机系统中的共利益者有：收银员，售货员，顾客，公司，经理，支付授权服务，帐务系统和库存系统等 识别视点：从不同的视角看待该系统。比如，收银员关心准确、快速生成一次销售，且没有支付错误；售货员关注销售提成 协同工作：共利益者之

9、间的协作 用户调研：集中于客户和其他共利益、整体目标、收益等 导出功能：从视点导出系统功能。客户调研 直接客户调研客户现有业务系统调查分析客户手工业务流程和规则调查客户业务文档调查分析客户历史业务资料调查分析业务情景调查分析客户调研会，客户自己描述业务需求客户访谈客户其他沟通形式客户调研的原则与步骤 原则深入浅出充分准备，文档化以业务流程为主线 步骤了解需要调研客户的组织结构和与项目相干的部门和决策领导。了解相干部门分别对应系统的相应功能模块。该部门对该项功能的目标和期望调研每个子系统所需的工作流程、功能与处理规则，收集单据、报表、帐本等原始资料，分析物流、资金流、信息流三者的关系 对调研的内

10、容事先准备,针对不同管理层次的用户询问不同的问题，列出问题清单。将操作层、管理层、决策层的需求既联系又区分开来 对与用户沟通的情况及时总结归纳,整理调研结果,找出新的疑点，初步构成需求描述文档把调研形成的需求描述文档分别给相关客户进行确定，得到客户认可。 需求整理与表达的方法 需求整理在整理时可以多种手段共用，如组织结构图、业务流程图、UML语言、多叉树、关系矩阵、文字叙述( 对其他描述手段的一种补充)、表格(单据调查表,帐本调查表,业务调查表,报表调查表等)、图形等多种手段。 需求表达组织结构与岗位定义 业务流程 处理规则 数据项 功能 以及上述5个方面的关系 客户调研的注意事项 要找对人：

11、懂的人、实际用户、能说得算的人。 要建立官方的沟通渠道。不能道听途说、小道消息或私下之言 事先必须有充足的准备，调研前应该向客户提供需要进行调研的内容和人员、时间安排的正式文档 调研是引导客户说出自己真实的想法，而不是向客户灌输自己的想法，调研主要是倾听 调研过程最好一个人与客户进行直接交谈，其他人做详细记录，尽量保持原汁原味，不要以自己的观点来描述客户的想法 注意沟通技巧，尽可能多的记住用户的姓名、职务、爱好等 ，要用客户能够明白的语言进行交流 态度谦逊并诚恳，多赞许客户，不要直接反驳客户的想法和要求。在用户讲解时,不要中断用户,使对方有充分的演说机会。 实例分析：出卷系统实例分析：出卷系统

12、 用户：教师：关注如何出一份合理的试卷，并能根据样式打印与输出。学生：关注如何通过生成一些模拟试题，并在线学习和检查学习结果。题库维护人员：关注试题的添加、更新和删除等工作。 视点：教师关注自动出卷、手工出卷、试卷编辑和试卷输出。学生关注随时抽卷、联系试卷和评价分析。题库维护人员关注试题管理。出卷系统的功能需求 自动出卷：系统根据教师的要求自动生成一份合理的试卷。 手动出卷：教师手动从候选的试题中挑选题目。 随机抽卷：系统随机抽取试题生产一份试卷。 在线练习：学生可以在线做练习和查看答案。 在线评价：系统在线评价学生练习的情况。 试题管理：管理人员维护题库中的试题。 试卷编辑：更新试题。 试卷输出：根据某个样式输出试卷。实例分析：图书馆系统实例分析：图书馆系统 图书馆系统的共利益者与视点有：图书流通管理：负责图书借还工作。用户：希望快速得到借书，还书服务，能够续借、预约图书，以及查询个人和图书信息。编目管理员：负责图书的管理、用户管理和处理罚金等。图书馆系统的主要功能需求 图书借出：管理员完成一次借书过程