柳阳

版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://liuyangsl.blogbus.com/logs/44575093.html

1. 需求之坑

（1）挖掘需求
需求往往隐藏在更深的层面，而且很难用文字表述清楚。
商业政策不应被硬性地写入需求，它们经常改变。
比如：“只有人事部们才能查看员工档案”，这是一个政策描述；
“只有授权用户才能查看员工档案”，这是一个需求描述。

需求应该着眼于用户做某件事情的原因，而不是做事情的方式。
“成为用户”，能更深入地了解需求。

（2）需求文档
系统的对外接口，对于用户来说更加重要，仔细考察用户的使用习惯。
UML用例图：用于捕获工作流。

（3）防止过度
需求文档应保持精确，但不要太过具体。

（4）使用抽象的描述，可以更好地适应未来的发展。
（5）防止细微地，渐进式的需求膨胀。
（6）维护一个项目词汇表。

---------------------------------------------------------------------------------

2. 解开不可能解开的迷题

关键是确定真正的约束，在这些约束中寻找突破。某些约束是绝对的，某些约束是主观片面的。
找出约束，也就确认了自由度。
列出所有可能的途径，哪怕是看似愚蠢的，分析每一种方法。
对约束划分优先级，从最严格的约束开始考虑。

---------------------------------------------------------------------------------

3. 等你准备好

当感到疑虑时，要停下来注视它。
培养判断能力和直觉。
当觉得无法入手时，构造一些原型，寻找灵感。

---------------------------------------------------------------------------------

4. 规范陷阱

程序规范就是把需求规约到程序员能够接管的程度，消除岐义。
但是规范并不能捕获系统中的所有细节，这涉及到各人的理解差异和书面文字的表述局限。
随着规范越来越详细，从中得到的回报也越来越低。

把需求搜集、设计、实现视为同一个过程，在实现中让需求更明确，而不要把每个步骤孤立进行。

---------------------------------------------------------------------------------

5. 圆圈与箭头

有各种开发方法，及其众多的追随者。
形式技术和方法有七优点，但是不要盲目采用。而且要注意它们的一些缺陷：
<a> 多采用图文结合来捕获需求，但是这种复杂的技术对于用户是很难理解的。
<b> 鼓励专门化：把工作严格区分，影响交流，浪费工作资源。
<c> 有些方法会影响程序本身的灵活性。

不要迷信某一种形式方法，从各种方法中汲取经验，形成自己的工作方式。