关键技巧 3：定义系统
定义系统指的是解释涉众需求，并整理为对要构建系统的意义明确的说明。在系统定义初期，需要决定需求的构成、文档格式、语言规范、需求等级、请求优先级和预计工作量、技术和管理风险以及系统规模等。系统定义活动还可包括与最关键的涉众请求直接联系的初期原型和设计模型。
我们使用了“说明”这个词而没有用“文档”，是为了避免在后者常见的使用中发现的固有缺陷。说明可以是书面文档、电子文件、图像或用于表达除系统本身以外的系统需求的任何表示方式。
系统定义的结果是用自然语言和图解方式表达的系统说明。后面几节将介绍推荐使用的一些说明格式。
原则 55：在编写比较正式的模型前，先使用自然语言进行编写
在第一次编写正式模型时，往往要用自然语言描述模型，而不是直接得到解决方案系统。请考虑以下示例：
要打长途电话时，用户应该拿起电话。系统将回应拨号音。用户拨打号码“9”，系统回应一种特殊的拨号音...
系统有四种状态：空闲、拨号音、特殊拨号音和连接状态。要使系统从空闲状态转向拨号音状态，请拿起电话。要从拨号音状态转到特殊拨号音状态，请拨号码“9”。
注意在后一个例子中，文字未起任何帮助读者理解的作用。
- Alan M. Davis, 201 Principles of Software Development, 1995
关键技巧 4：管理系统规模
项目规模由分配给它的需求集定义。管理项目规模，使之适合可用资源(时间、人力和资金)，是成功管理项目的关键。管理规模是一个持续不断的活动，需要迭代式和递增式开发，这就将项目细分为更易于管理的若干个小部分。
使用需求属性(如优先级、工作量和风险)作为协商应包含需求的基础，对管理规模而言是相当有用的技巧。侧重于属性，而不是需求自身，将减少通常对敏感问题的争论。
这也有助于培养小组负责人的谈判技巧，还有助于在项目中为组织培养推介人，对于客户而言也是如此。产品/项目推介人应能够代表组织拒绝那些超出可用资源的规模变更，也应有相应能力扩展资源以适应扩大的规模。
关键技巧 5：改进系统定义
对高层系统定义达成一致并充分理解了系统初始规模后，投入资源改进系统定义不仅有可能，而且也是经济的。改进系统定义包括两个重要的考虑事项：制定更详细的高层系统说明和验证系统是否符合涉众需要，是否按说明运行。
说明通常是项目团队的重要参考材料。在制定说明时一定要考虑受众。人们常会犯一个错误，那就是用复杂定义表示构建起来很复杂的东西，尤其是在受众无法或不愿意耗费精力去思考某些重要的需要取得一致认识时候。这就难以向项目团队内外的人员解释系统目的。相反，你可能会发现需要为不同的受众编制不同类型的说明。本文介绍了详细自然语言、正式文字和图解说明推荐使用的格式。确定说明格式后，改进将持续贯穿整个项目生命周期。
关键技巧 6：管理变更的需求
不管您多么认真地定义需求，需求终将改变。实际上，一些变更是非常值得的!这意味着您的团队需要与涉众保持密切联系。能否适应变更需求是评测团队的涉众敏感度和运作灵活性的一个尺度 - 敏感度和灵活性都是对项目成功有贡献的团队特征。变更不是敌人，而没有管理的变更才是真正的敌人。
图 3 - 变更管理流程
需求变更表明多少需要耗费一些时间来实施某个特定的功能，而且对一个需求的变更对其他需求可能有影响。管理需求变更包括这样一些活动：设立基线、追踪每个需求的历史、确定哪些依赖关系值得追踪、在相关项之间建立可追踪关系以及维护版本控制等。如图 3 所示，建立变更控制或批准流程也很重要，它要求由指定的团队成员来复审所有提议的变更。有时候这一单一的变更控制渠道称为变更控制委员会 (CCB)。
文章来源于领测软件测试网 https://www.ltesting.net/
