软件需求设计评审之八项注意[2]

　　4 、是否每个需求都在项目的范围内?

　　划分项目范围和区分系统边界同样是需求说明书的一个任务，不要对需求书作出超范围的论述和延伸，要知道需求书不是分析师卖弄概念、展示时尚的场所，它是 软件工程的一个重要环节。

　　5、 是否每个需求都没有内容和语法上的错误?

　　 按照传统的需求列表方式，需求像菜单一样被一条条列出来，构成需求项的主要栏位包括：需求ID、 需求描述、优先级、来源和状态等。 通常需求首先要经过“拼写检查”，保证没有拼写上的问题，然后通过逐行浏览修改那些在内容或行文上出现问题的需求。

　　6 、在现有的 资源内, 是否能实现所有的需求?

　　需求规格说明要考虑可行性的问题。事实上，分析师的关注层面是价值驱动和成本驱动方面。分析师应该明白不是所有的需求都要去实现，一些看上去很明显与涉及用户有冲突的、费力不讨好的需求应该果断地舍弃。国内有专家提出，搞需求也要讲“和谐”即是此中道理。

　　举例而言，企业中的用户可分为三种类型：决策层用户、管理层用户、操作层用户。每种用户所代表的价值取向是不同的，决策和管理层希望系统处理业务是业务安全优先的，而 操作系统用户则是更多地考虑方便性的。国内某电子贸易公司，从自身业务安全考虑，规定了系统不允许“借货”,意即代理商的产品直接发到客户根本不经过本贸易公司的物流部门。如果操作层用户提出了这样的“借货”需求,倒是可以方便他的日常处理,但却违背了公司的根本利益。很显然，这样的需求肯定是有所不为的。

　　7、 每一条特定的错误信息，是否都是唯一的和具有含义的?

　　不要忽视错误信息的定义, 它必须具有唯一性。如果过于笼统地定义错误信息则和没有定义的效果是一样的。

　　二、 注意对需求规格说明的实践性进行评审

　　所谓实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度,而非源于分析师们经验主义的臆测。实践性是判断需求规格说明是不是理论联系实践、密切和用户联系的一个关键性指标。如果需求规格说明和用户实践脱离,即使看上去写得再天花乱坠,也会使需求说明如同无根之树、无源之水,会大大减低用户对需求报告本身的信任度。

　　有经验的 系统分析师通常会迷信自己的经验,把从前的经验嫁接到目前的企业需求分析中。也许由于行业性质相同,但如果不经过当前的实践调研则给出需求，仍然会无法体现出企业自身的特征。因而不能为企业带来真正的价值,也会造成与用户需求的鸿沟。

　　笔者也曾经“轻实践重抽象”，我认为系统分析师的工作特点是站在具体案例上的深度抽象，前提是必须获得本企业的一手具体业务背景、流程和规则。

　　我们在分析比如“任务跟踪”之类的系统时，由于系统的抽象模型是已知的(通过大量同类软件的分析得知)，但还是需要分析师把抽象模型演绎到企业当前业务现状。这样的需求分析才会有“实话实说”之效,才能引发评审者的共鸣。否则，在需求评审中评审者是很难读懂你的意图，自然不会立即通过你的需求报告，导致需要重新返工撰写需求报告。

　　这使我想到毛主席当年倡导“理论联系实际”的深刻内涵。任何时刻,我们都要记住一个原则，即密切联系用户。诚然，需求分析需要方法也要理论支持,但最关键点仍然在于它本身是一种实践,需求分析实践直接来源于和用户的直接 沟通和互动。

原文转自：http://www.ltesting.net