需求提供者经常不大了解系统应该包含哪些内容,因此他们可能会提出不恰当的需求。需要通过系统边界定义初步剔除那些明显在系统范围之外的需求,以免这些需求干扰后续的分析过程。
检查每项原始需求,将它们区分为系统需求、过程需求和应该拒绝的需求。考虑如下问题:
对于问题1和问题2可以判断是否为过程需求,如果是过程需求,则要求系统的操作者提供这些信息,否则需要复审系统应该处理的数据。
对于问题3和问题4可以判断是否是系统边界以外的需求。如果是,则它可能是不必要的,也可能是无法实现的需求。
对于于操作过程相关的需求和系统边界之外的需求,必须准备一些技术的和经济的论据,说明这些需求被拒绝的理由。这些论据应该是基于这个组织已定义的业务目标或者系统可行性研究的结果。
系统边界的定义和需求的检验都需要通过需求的复审来进行,需求的复审之前可以定义适当的分析检验表,如:
检验表项 | 检验内容的描述 |
草率设计 | 该需求是否包含不成熟的设计或实现信息? |
组合需求 | 是单独的需求还是可以细分为几个不同的需求? |
多余需求 | 只是系统的装饰而不是真正必须的吗? |
使用非标准硬件 | 该需求必须使用非标准的硬件还是软件? |
符合业务目标 | 该需求是否符合已定义的业务目标? |
需求多义性 | 该需求对不同的人是否可能有不同的理解? |
需求可实现性 | 根据现有的实现技术,是否可以实现该需求? |
需求可测试性 | 测试工程师是否可以从需求的表述中导出测试已判断系统是否符合需求? |