《软件工程》总结——第四章

本章的主要内容是需求工程。以小型图书资料管理系统为例总结

软件需求

            《IEEE》给出了软件需求如下定义:1. 用户解决问题或达到目标所需的条件和能力;2. 系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力;3. 一种反映上面 1 或 2 所描述的条件或能力的文档说明。

      业务需求

            通常,业务需求涵盖以下的内容:业务、客户、业务、特性、价值、优先级。比如:1.该系统使用计算机实现图书资料的日常管理,提高工作效率和日常管理;2. 该系统可以让用户在网络上查询和浏览一些电子资料,改变原有的借阅模式;3. 由于版权的限制,某些电子资料只能让用户浏览和打印而不能下载。

      用户需求

            “用户可以通过Internet随时查询图书信息和个人借阅情况,并可以快捷地查找和浏览所需要的电子资料。”这句话包含了三个不同的需求:1. 用户可以通过 Internet 随时查询图书信息;2. 用户可以通过 Internet 随时查询个人借阅情况;3. 用户可以通过 Internet 快捷地查找和浏览所需要的电子资料。

      功能需求和非功能需求

            1. 用户可以从图书资料库中查询或者选择其中的一个子集;2. 系统可以提供适当的浏览器供用户阅读馆藏文献;3. 用户每次借阅图书应该对应一个惟一的标识号,它被记录到用户的账户上。

      系统需求

            通常系统需求模型的描述有三种方法:1. 结构化英语(PDL);2. 可视化模型;3. 形式化方法。

需求过程分析

      需求获取

            主要工作内容包括:1. 聆听用户的需求;2. 分析和整理所获取的信息;3. 形成文档化描述。

      需求分析

            主要工作内容包括:1. 定义系统的边界;2. 建立软件模型;3. 分析需求可能性;4. 确定需求优先级;5. 建立需求分析模型;6. 创建数据字典。

      需求规格说明

            软件需求规格说明是需求开发的结果,它精确地阐述一个系统软件必须提供的功能和性能以及它所要考虑的限制条件。IEEE标准830—1998改写并扩充的模板比较正式

      需求验证

            需要验证:1. 正确性;2. 无二义性;3. 完整性;4. 可验证性;5. 一致性;6. 可修改性;7. 可跟踪性。

      需求管理

            1. 需求变更控制;2. 需求文档的版本控制;3. 需求跟踪;4. 需求管理工具。

需求获取技术

      面谈

            1. 事先准备一个合适的与背景无关的面谈,列出一些准备询问的问题,并将其记在笔记本上以便面谈时参考;2. 面谈前,需要研究一下要面谈的风险承担人或公司的背景资料,不要选择自己能回答的问题打扰被面谈人;3. 面谈过程中,应该参考事先准备的面谈模板,以保证提出的问题是正确的。同时,需要建立起和谐的氛围,并将答案记录下来;4. 面谈之后,分析总结面谈记录,找到主要的用户需求或产品特征。

      需求专题讨论会

            1. 专题讨论会的准备;2. 安排日程;3. 举行专题讨论会。

      观察用户工作流程

            1. 被动观察;2. 主动观察。

      原型化方法

            1. 抛弃式原型;2. 演化式原型。

      基于用例的方法

            1. 确定参与者;2. 确定用例;3. 描述用例。

案例:小型图书资料管理系统

      确定参与者

            普通读者、图书管理员和邮件系统。

      确定场景

            借书场景、还书场景等等。

      确定用例

            1. 与“图书管理员”有关的用例:管理图书、管理图书资料、管理书目、登记借书、登记还书;2. 与“普通读者”有关的用例:预定图书、取消预订;3. ”图书管理员“和“普通读者”作为系统的合法注册用户共同具有的用例。

      编写用例描述

            1. 目标;2. 事件流;3. 特殊需求;4. 前提条件;5. 后置条件。

原文地址:https://www.cnblogs.com/zchenjian/p/4293979.html