什么是软件需求?
软件需求实际就是“业务知识+问题列表+其他元素”。软件需求的三层次:业务需求、用户需求、软件需求。需求也有着三种类型:功能需求、非功能需求、设计约束。
软件需求的三层次
1业务需求 |
定义:反映企业/组织对软件系统的高层次目标要求,也就是软件系统的建设目标。 体现:
业务需求应该在项目立项的时候整理。 |
||||
2用户需求 |
定义:用户使用软件需要完成什么任务,怎么完成的需求。通常在业务需求定义的基础上进行用户的访谈,调查,对用户使用的场景进行整理,从而建立用户角度的需求。 特点:
|
||||
3 软件需求 |
需求分析与建模的产物 |
需求的三种类型
1功能需求 |
以系统→子系统→模块→子模块方式组织 |
|||||
2 非功能需求 |
常见的问题? 1、信息传递的无效性,如高可靠性,扩展性 2、忽略了非功能需求的局部性,如查询时间<10s |
|||||
3 设计约束
|
1非技术性因素决定的技术选型 2预期的软硬件环境和使用环境 实现技术受环境的影响如内存大小,海上使用 |
优秀需求的标准
1完整性 |
定义:需求没有遗漏,也就是说在需求变更中新需求都是因为外部环境的变化而产生的且所占量小 关键问题: (1)用户才是验证需求完整性的合适人选 为了保证需求的完整性,就必须从业务角度来组织各种需求项,让用户验证需求规格说明书中罗列的主题域、业务事件、业务活动、业务步骤、困难与障碍点是否完整,更具操作性。 (2)需求完整性存在不同层面 步骤:验证主题域-》中层-》操作层 |
||||
2不失真 |
1、正确性 2、无歧义性 |
||||
3有优先级 |
优先级有不同角度 必要性只是对优先级的补充 |
||||
4有技术早期介入 |
1、可行性;就是指需要让开发团队早期介入,对需求中描述的解决方案进行评价。重点在需求项及复杂的解决方案 2、可验证性;说明需求规格说明书应该能够指导测试活动,也提供了验证所需的信息。 |
诫语
- 业务需求是需求定义的产物,用户需求是需求捕获的产物,软件需求是需求分析与建模的产物
- 功能需求的要点在于如何组织
- 非功能需求的要点在于保证信息的有效传递和注意其局部性
- 业务导向的层次结构是保障完整性的关键
- 需求有时候会戴上“高优先级的面具”,实际上是担心你不去实现它