关键需求决定架构。关键需求横跨功能需求、质量属性，以及约束这三类需求。
其余需求用来验证架构。
1、确定关键质量
需要做如下三方面工作：
- 为了提高要开发软件系统受认可的程度，应着重提高哪些方面的质量属性要求。
- 充分考虑这些质量属性的相互制约或相互促进关系，以调整不同质量属性的要求标准。
- 同时，必须满足各种约束性需求。
确定关键质量时考虑质量属性之间的矛盾关系。采用质量属性关系矩阵（“+”表示行促进列，“-”表示行影响列，“ ”表示行列两种质量属性之间影响不明显。）
|
| 性能 | 安全性 | 持续可用性 | 可互操作性 | 可靠性 | 鲁棒性 | 易用性 | 可测试性 | 可重用性 | 可维护性 | 可扩展性 | 可移植性 |
|
| 性能 |
|
|
| - | - | - | - | - |
| - | - | - | 区域1 |
| 安全性 | - |
|
| - |
|
| - | - | - |
|
|
| |
| 持续可用性 |
|
|
|
| + | + |
|
|
|
|
|
| 区域2 |
| 可互操作性 | - | - |
|
|
|
|
|
|
|
| + | + | |
| 可靠性 | - |
| + |
|
| + | + | + |
| + | + |
| |
| 鲁棒性 | - |
| + |
| + |
| + |
|
|
|
|
| |
| 易用性 | - |
|
|
|
| + |
| - |
|
|
|
| |
| 可测试性 | - |
| + |
| + |
| + |
|
| + | + |
| 区域3 |
| 可重用性 | - | - |
|
| - |
|
| + |
| + | + | + | |
| 可维护性 | - |
|
|
|
|
|
| + |
|
| + |
| |
| 可扩展性 | - | - |
|
|
|
|
| + |
| + |
| + | |
| 可移植性 | - |
|
|
|
|
| - | + | + | - | + |
|
2、确定关键功能
- 核心功能：标志是业务层的接口要反映这些功能。
- 必做功能：《愿景与范围文档》中的“主要特征”往往应作为“必做功能”的备选项。对于业务系统来说，一般支持“运营”的功能比支持“管理”的功能优先级要高。
- 高风险功能：基于务实考虑。
- 独特功能：
最后
以上就是精明水壶最近收集整理的关于需求分析-7 关键需求的全部内容，更多相关需求分析-7内容请搜索靠谱客的其他文章。
本图文内容来源于网友提供，作为学习参考使用，或来自网络收集整理，版权属于原作者所有。
发表评论 取消回复