属性
按照下列步骤细化属性集合：
通过头脑风暴得到可能的属性列表。
从属性细节中分类挑选属性。将所有的细节填到属性列表中，以及由所有的属性按时的其他细节也填到列表中。
将每个属性分配到适合的功能或功能组。
将所有的属性分类到必须（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.寻找可以降低由假设所带来风险的行为的时机。