parnas-a-rational-design-process.rst: 融入吴逸嘉的翻译 (PDF page 8).

1 files changed, 9 insertions, 16 deletions

diff --git a/parnas-a-rational-design-process.rst b/parnas-a-rational-design-process.rst
index 15aa453..410052d 100644
--- a/parnas-a-rational-design-process.rst
+++ b/parnas-a-rational-design-process.rst
@@ -292,30 +292,23 @@ A.  建立并记录需求
 Page 8
 --------------------------------------------------------------------------
 
-(王如韵 翻)
+(王如韵 翻， 吴逸嘉 改)
 
-- 它可以解决争议; 我们不再需要成为应用程序专家或咨询应用程序专家。
+- 它可以用于平息争论; 我们不再需要成为或咨询应用程序专家。
 
-因为通常没有组织良好的信息来源， 确定详细的需求很可能是这个过程中最困
-难的部分。 理想情况下，需求文件应该由用户代表来写。 而实际上，它很可能
-是要软件设计者写，然后由用户代表同意。
+确定详细的需求可能是这个过程中最困难的部分，因为通常没有有条理的信息来源。理想情况下，需求文档应由未来用户代表来写。实际上，它可能将由软件设计者来产生，然后由用户代表们同意。
 
-2. 需求文件包含什么内容?
+2. 什么内容到需求文档中去?
 
-在理想化的设计过程中，需求文件内容的定义很简单: 它应该包含编写正确软件
-要知道的所有内容，不需要再多了。 当然，如果现有信息准确且组织良好，
-我们可以引用它们。 书写理想需求文件的一般规则有:
+在理想化的设计过程中，需求文档的内容定义是简单的: 它应该包含为编写正确软件你需要知道的所有事情，仅此而已。当然，如果现有信息准确且有条理，我们可以引用现有的信息。理想的需求文档的通用规则有:
 
-- 需求文件中每句话应对所有可被接受的产品有效， 不应依赖于实现决定。
+- 每个陈述应对所有可接受的产品有效，不应依赖实现决定。
 
-- 文件应是完整的。 如果产品符合文件中每一句话，则产品应是可以接受的。
+- 文档应该是完整的，从某种意义上说，如果产品满足文档中的每个陈述，则它应该是可以接受的。
 
-- 在开发之前，如果信息还没有，则指出缺失的地方，而非简单地略过。
+- 如开发必须开始前信息尚不具备，则指出不完整的地方，而非简单地省略。
 
-- 需求文件应该按照参考文件的结构来组织，而不是按照系统介绍来组织，因为
-  参考文件的形式是最有用的。 虽然写这样一份文件需要付出相当的努力，而且
-  比系统介绍更难于阅读，但从长远来看，它节省了人力，因为在这个阶段获得
-  的信息是以易于在整个项目中参考的形式记录下来的。
+- 需求文档应该是按照参考文件的结构组织，而不是对系统的介绍性叙述，因为参考文件是最有用的形式。虽然产生这样一份文档需要付出相当的努力，并且比介绍性文件更难读，但是从长远来看，它节省了人力，因为在这个阶段获得的信息是以易便于在整个项目中参考的形式记录下来的。