如何编写软件需求规格书（7）
How to write a software requirements specification
如何编写软件需求规格书
by Robert Japenga
__________________________________________________________________________________________
Is this do-able? Won’t we miss our deadlines if we take the time to do this?
具有可操作性吗？花过多时间在软件需求上，项目是否会因此而延期？
This is a great question. There is no question that there is balance in this process. We have seen companies and individuals go overboard on documenting software that does not need to be documented, such as a temporary utility. We have also seen customers kill good products by spending too much time specifying it.
这个问题非常好，毫无疑问，这是一个需要平衡的过程。我们看到一些公司和个人花过多的文档精力在不需要文档的软件身上，例如临时的实用工具。我们也看到过客户花过多的时间在规格书上，反而将一个不错的产品扼杀了。
However, the bigger problem is at the other end of the spectrum. We have found that taking the time up front pays dividends down stream. If you do not have time to specify it up front, you probably do not have the time to do the project.
然而，更大的问题是另一个方面，我们发现在规格书上花的时间越来越少，如果你开始的时候没有时间写规格书，那么你很可能也没有时间开发项目。
Here are some of our guidelines:
- Spend time specifying and documenting well software that you plan to keep.
- Keep documentation to a minimum when the software will only be used for a short time or has a limited number of users.
- Have separate individuals write the specifications (not the individual who will write the code).
- The person to write the specification should have good communication skills.
- Pretty diagrams can help but often tables and charts are easier to maintain and can communicate the same requirements.
- Take your time with complicated requirements. Vagueness in those areas will come back to bite you later.
- Conversely, watch out for over-documenting those functions that are well understood by many people but for which you can create some great requirements.
- Keep the SRS up to date as you make changes.
- Approximately 20-25% of the project time should be allocated to requirements definition.
- Keep 5% of the project time for updating the requirements after the design has begun.
- Test the requirements document by using it as the basis for writing the test plan.
这里是一些指导性的建议：
- 当软件使用的时间不长，或者用户数量不多，那么文档要尽量的简短
- 要有专人来写规格书（而不是编写代码的人员）
- 编写规格书的人需要良好的沟通技能
- 漂亮的Diagram是有帮助的，但是通常表格和Chart更容易维护，并且可以作为交流需求的一种媒介
- 留意复杂的需求，这些需求的含糊不清将会导致后续返工
- 相反，不要在大多数人都能理解的需求上过多的进行描述，将精力放在其他重要的需求上边吧
- 保证SRS及时更新
- 需求定义占整个项目过程几乎20~25%的时间
- 在进入设计阶段之后，要保证有5%的项目时间来更新需求
- 通过基于需求文档编写测试计划来测试需求文档
如何编写软件需求规格书（1）
如何编写软件需求规格书（2）
如何编写软件需求规格书（3）
如何编写软件需求规格书（4）
如何编写软件需求规格书（5）
如何编写软件需求规格书（6）
如何编写软件需求规格书（7）