srcmini本文概述
需求工程(RE)是指在工程设计过程中定义, 记录和维护需求的过程。需求工程提供适当的机制, 以了解客户的需求, 分析需求和评估可行性, 谈判合理的解决方案, 明确指定解决方案, 验证规格并在将需求转换为工作系统时对其进行管理。因此, 需求工程是经过实践证明的原理, 方法, 工具和符号的规范应用, 用于描述拟议系统的预期行为及其相关约束。
需求工程流程
这是一个四步过程, 其中包括-
- 可行性研究
- 需求启发与分析
- 软件需求规范
- 软件需求验证
- 软件需求管理
1.可行性研究：
可行性研究的目的是为开发用户可以接受, 更改灵活且符合既定标准的软件提供理由。
可行性类型：
- 技术可行性-技术可行性评估在时间和预算范围内满足客户要求所需的当前技术。
- 操作可行性-操作可行性评估了所需软件执行一系列级别以解决业务问题和客户要求的范围。
- 经济可行性-经济可行性决定了必要的软件是否可以为组织带来财务收益。
2.需求启发与分析：
这也称为需求收集。在这里, 可以在客户和现有系统流程的帮助下(如果可用)识别需求。
需求分析始于需求启发。对需求进行分析以识别不一致, 缺陷, 遗漏等。我们根据关系描述需求, 并解决冲突(如果有)。
启发与分析问题
- 让所有合适的人参与进来。
- 利益相关者通常不知道他们想要什么
- 利益相关者表达了他们的要求。
- 利益相关者可能有相互矛盾的要求。
- 分析过程中的需求变更。
- 组织和政治因素可能会影响系统要求。
3.软件需求规范：
软件需求规范是一种文档, 由软件分析人员根据从各种来源收集的需求(由客户以普通语言写成的需求)创建而成。分析人员的工作是用技术语言编写需求, 以便开发团队可以理解需求并从中受益。
此阶段使用的模型包括ER图, 数据流程图(DFD), 功能分解图(FDD), 数据字典等。
- 数据流程图：数据流程图(DFD)被广泛用于对需求进行建模。 DFD显示通过系统的数据流。该系统可以是公司, 组织, 一组过程, 计算机硬件系统, 软件系统或前述的任意组合。 DFD也称为数据流程图或气泡图。
- 数据字典：数据字典只是用于存储有关DFD中定义的所有数据项的信息的存储库。在需求阶段, 数据字典至少应定义客户数据项, 以确保客户和开发人员使用相同的定义和术语。
- 实体关系图：需求规范的另一种工具是实体关系图, 通常称为” E-R图”。它是组织数据的详细逻辑表示形式, 并使用三个主要结构, 即数据实体, 关系及其相关属性。
4.软件需求验证：
制定需求规范后, 将验证本文档中讨论的需求。用户可能要求非法, 不可能的解决方案, 或者专家可能会误解需求。可以根据以下条件检查需求：
- 如果他们可以实际实施
- 如果它们是正确的, 并且按照功能(尤其是软件)
- 如果有任何歧义
- 如果吃饱了
- 如果他们能形容
需求验证技术
- 需求评审/检查：对需求进行系统的手动分析。
- 原型制作：使用系统的可执行模型检查需求。
- 测试用例生成：针对需求进行测试以检查可测试性。
- 自动一致性分析：检查结构化需求描述的一致性。
软件需求管理：
需求管理是在需求工程过程和系统开发过程中管理变化的需求的过程。
随着业务需求的变化, 在流程中出现了新的需求, 并且对系统有了更好的了解。
从不同角度来看, 需求的优先级在开发过程中会发生变化。
在开发过程中, 系统的业务和技术环境会发生变化。
软件要求的前提条件
收集软件需求是整个软件开发项目的基础。因此, 它们应该清晰, 正确且定义明确。
完整的软件需求规范应为：
- 明确
- 正确
- 一致的
- 相干
- 可理解的
- 可修改的
- 可验证的
- 优先
- 明确的
- 可追溯的
- 可靠来源
软件需求：大部分软件需求必须分为两类：
功能需求：功能需求定义了一个功能, 系统或系统元素必须具有执行该功能的能力, 并且必须以不同的形式进行记录。功能需求描述了与系统功能相关的系统行为。
非功能性要求：这可能是必需的, 用于指定可用于决定操作的标准, 而不是系统的特定行为。
非功能性需求分为两个主要类别：
- 在运行时可以观察到的执行质量, 例如安全性和可用性。
- 演化质量, 如可测试性, 可维护性, 可扩展性和可伸缩性, 体现在软件系统的静态结构中。
评论前必须登录！
注册