1 files changed, 23 insertions, 8 deletions
diff --git a/parnas-a-rational-design-process.rst b/parnas-a-rational-design-process.rst
index ef486e6..741a4a9 100644
--- a/parnas-a-rational-design-process.rst
+++ b/parnas-a-rational-design-process.rst
@@ -276,16 +276,31 @@ A. 建立并记录需求
 Page 8
 --------------------------------------------------------------------------
 
-王如韵
+王如韵 OK
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
--它可以用来解决争议;我们不再需要成为或咨询应用程序专家。
-确定详细的需求很可能是这个过程中最困难的部分，因为通常没有组织良好的信息来源。理想情况下，它应该由未来使用它的用户来制作。事实上，它很可能是由软件设计师来设计的，而他们的想法必须得到用户的认可。
-2.需求文档中包含了什么?在理想化的设计过程中，需求文档内容的定义很简单:它应该包含编写正确软件所需的所有内容，仅此而已。当然，如果现有信息准确且组织良好，当然，我们可能会引用。好的需求文件的一般规则包括:
--每一项陈述声明应适用于所有可被接受的产品本身;而不应该依赖于可实现的决策。
--文件应是完整的，就是说如果产品符合每一项陈述，则该文件应是可接受的。
--在必须开始开发之前，如果没有可用的信息，则指出不完整的地方，而不是简单地省略。
--该产品应该是由参考文件组织，而不是介绍系统，因为这是最有用的形式。虽然编写这样一份文件需要付出相当大的努力，而且比介绍系统更难于阅读，但从长远来看，它节省了人力，因为在这个阶段获得的信息是以一种便于在整个项目中引用的形式记录下来的。
+- 它可以解决争议; 我们不再需要成为应用程序专家或咨询应用程序专家。
+
+因为通常没有组织良好的信息来源， 确定详细的需求很可能是这个过程中最困
+难的部分。 理想情况下，需求文件应该由用户代表来写。 而实际上，它很可能
+是要软件设计者写，然后由用户代表同意。
+
+2. 需求文件包含什么内容?
+
+在理想化的设计过程中，需求文件内容的定义很简单: 它应该包含编写正确软件
+要知道的所有内容，不需要再多了。 当然，如果现有信息准确且组织良好，
+我们可以引用它们。 书写理想需求文件的一般规则有:
+
+- 需求文件中每句话应对所有可被接受的产品有效， 不应依赖于实现决定。
+
+- 文件应是完整的。 如果产品符合文件中每一句话，则产品应是可以接受的。
+
+- 在开发之前，如果信息还没有，则指出缺失的地方，而非简单地略过。
+
+- 需求文件应该按照参考文件的结构来组织，而不是按照系统介绍来组织，因为
+  参考文件的形式是最有用的。 虽然写这样一份文件需要付出相当的努力，而且
+  比系统介绍更难于阅读，但从长远来看，它节省了人力，因为在这个阶段获得
+  的信息是以易于在整个项目中参考的形式记录下来的。