《探索需求》——阅读笔记三

属性

按照下列步骤细化属性集合：

经过头脑风暴获得可能的属性列表。

从属性细节中分类挑选属性。将全部的细节填到属性列表中，以及由全部的属性按时的其余细节也填到列表中。

将每一个属性分配到适合的功能或功能组。

将全部的属性分类到必须（M），须要（W）和忽略（I）。

为下一步处理证实M和W属性。

约束条件

在制定约束列表的时候，遵守下列过程：

1.生成基于M类型属性的约束列表。

2.检测约束的正确性和完备性。

3.寻找可能会生成更小或更大的潜在解决方案控件的相互关联的约束。

4.在约束边界的内部和外部边缘的地方仔细地检测过紧约束。

5.尽量地为了获得较大的解决方案控件而进行协调工做，单是不要试图让它过度大。

偏好

按照下述周期性步骤进行：

1.制定一个偏好的范围很广的列表。

2.女里将每条偏好都转变为可量化的偏好，一遍设计者确切地知道如何衡量如何他们作得更好，和时作得更差。然而，要小心，不要在度量的问题上陷入困境。

3.从新考虑你的约束列表，看看他们是不是真的偏好。只要可能的话，都试图将约束缩减为偏好，多是受约束的偏好，以便为设计者提供更加广阔的解决方案控件用于搜索。

4.为了帮助清晰地设定偏好，开发价值图，用于帮助解决语句含混性问题，尤为是约束和偏好之间的混淆问题。

指望

为了提出并记录指望和限制，遵循下列循环步骤：

1.从有表明性的用户处得到专门的指望列表。

2.处理该列表，理解并产生每条指望，

3.经过协商将指望限制到一个合理的水平，微系统未来的修改留下公开的机会，可是坚定地去掉任何不能合理地指望获得的东西。

4.设置一条设置时，确信几下限制的来源，由于今天的权限就多是明天的机会。

第五篇——极大提升成功的可能

含混性度量

按照下述步骤进行投票：

1.召集一组人，让其回到关于要测量含混性的文档的问题。

2.却行不存在压力要求答案一致，或者不存在一个或其余参与者的任何类型的影响。

3.提出一组问题，每个问题都鞥够用数字进行回答。

4.经过比较熟知最高和最低的答案估计含混性。

5.访问给出最高和最低值的估计者，帮助肯定含混性的来源。

技术复审

1.有不少能够挑选的复审规则。都试一下，而后让他们知足你特别的需求。

2.容许学习的时间，对你本身的笨拙要有耐心。

3.开发反馈系统，以便于你在早期复审中学到的东西可以用于改进未来的复审。这样作得最简单的方法就是发展一个通过培训的复审领导团队。

衡量满意度

1.位你本身的项目监理一个用户满意度测试。使用咱们的表格或者他们合适你的组织机构文化的形式。在此基础上，必定要让用户包含在此过程当中。

2.如允诺的那样，周期性地管理测试。

3.吧每类或整体的满意度评价制成表格，而后看看变化。追踪这些变化，找出他们后面隐藏的东西。

4.对任何评论都要基于特别的表格，尤为当它们表达了强烈的愿望时。毫不要忘记感受就是事实，是关于你首先建立系统的对象的重要的事实。

5.不管你是否使用用户满意度测试，不要忘记使用全部来自其余来源的全部用户满意度的信息。

测试用例

需求的黑箱测试过程遵循下述循环步骤：

1.经过想象产品已经制造出来，构造一系列的测试用例，而且为“假设”问题。

2.回答这些测试用例，而且与全部感兴趣的团体讨论这些答案，争取取得一致意见。

3.试图获得对答案的认同一般会致使其余“假设”问题。将它们加入到列表中而且回答，重复这个过程知道列表稳定下来。

4.一旦列表或多或少稳定下来，一一个包括设计者和专业记录员的小组仔细检查它。这个小组专门搜集过度约束的答复，而后修改它们以给出最大可能的设计——可是不要再添加问题。

5.当完成了修改，将用例记录下来，做为开始构建系统和接受测试的其实的基础。

学习已存在的产品

1.比较产品，提出一份在新需求中可能遗漏的功能列表。

2.访谈一些旧产品的使用者，提出一份当前系统中不见了的功能列表。

3.比较旧产品和其原始的需求，准备一份新产品开发中的潜在问题的列表。尤为要注意那些没有别实现的或是实现了以后又被丢弃的需求。

4.避免由于每一个旧产品而把产品作成一把瑞士军刀的诱惑。不要让那些不隶属这个需求系统的特征悄悄混进来。

达成协议

1.记录下每一个假设；

2.跟踪每一个假设的源头：是选择、强迫接受仍是协议。

3.是假设加上其来源信息。

4.请参与者在每一个书面文档上签名。

5.寻找能够下降由假设所带来风险的行为的时机。