快而不完美的建模
有时需求分析师会遇到障碍。有时有些需求没有成型,或者用户不能解释这些需求,或者需求分析师不能理解它们。也许该产品非常具有创新性,没有人真正知道需求,或者人们需要看到更具体的东西,而不仅仅是文本化的需求。原型-原型的意图试想用户表达需求的一种模拟。场景一些创建的故事,用于完成特定部分工作所需的步骤。创建场景的方法:用户主导这项工作,他们向分析师展示工作是如何完成的,哪里会出现异常情况。当分析师完全理解工作后,他们使用场景来得到产品的需求,产品将辅助完成这部分的工作。编写需求系统开发的一个主要问题就是需求被误解。解决方法:为了避免误解,分析师必须以独一无二的、可测试的方式写下需求,同时确保提出需求的利益相关者理解并同意写下的需求,然后再传递给开发者。换言之,分析师编写需求是为了确保参与开发的各方对需要做的事达成一致的理解。需求规格说明模板项目驱动——描述项目的理由和动机1、项目目标——投资构建产品的理由以及这样做我们希望取得业务上的好处。2、客户、顾客和其他利益相关者——产品涉及他们的利益或对他们产生影响。3、产品的用户——预期的最终用户,以及他们对产品可用性的影响。项目限制条件——加在项目和产品上的约束条件4、需求限制条件——项目的局限性和产品设计的约束条件。5、命名标准和定义——项目的词汇表。6、相关事实和假定——对产品产生一定影响的外部因素,或开发者所做的假定。功能需求——产品的功能7、工作的范围——针对的业务领域8、产品的范围——定义预期产品的边界,以及它与相邻系统的连接情况。9、功能与数据需求——产品必须做的事情以及功能所操作的数据。非功能需求——产品的品质10、观感需求——预期的外观11、易用性和人性化需求——如果产品要让预期用户成功地使用,它必须是怎样的。12、执行需求——速度、大小、精度、人身安全性、可靠性、健壮性、可伸缩性、持久性和存量等需求。13、操作和环境需求——产品预期的操作环境。非功能需求——产品的品质14、可维护性和支持需求——产品的可改动性必须达到什么水平,以及需要怎样的支持。15、安全性需求——产品的信息安全性、保密性和完整性。16、文化与政策需求——人和社会的因素。17、法律需求——满足适用的法律。项目问题——这些适用于构建产品的项目18、开放式问题——那些尚未解决的问题,可能对项目的成功有影响。19、立即可用的解决方案——利用已有的组件而不是从头开发。20、新问题——引入新产品而带来的问题。21、任务——将产品投入使用必须要做的一些事情。22、迁移到新产品——从现存系统转换的任务。23、风险——项目最有可能面对的风险。24、费用——早期构建产品的成本或工作量的估计。25、用户文档——创建用户指南和文档计划。