”需求规格说明书“最关键的是什么？

What's the big deal about 'requirements'?
One of the most reliable methods of ensuring problems, or failure, in a large, complex software project is to have poorly documented requirements specifications. Requirements are the details describing an application's externally-perceived functionality and properties. Requirements should be clear, complete, reasonably detailed, cohesive, attainable, and testable. A non-testable requirement would be, for example, 'user-friendly' (too subjective). A testable requirement would be something like 'the user must enter their previously-assigned password to access the application'. Determining and organizing requirements details in a useful and efficient way can be a difficult effort; different methods are available depending on the particular project. Many books are available that describe various approaches to this task.

Care should be taken to involve ALL of a project's significant 'customers' in the requirements process. 'Customers' could be in-house personnel or out, and could include end-users, customer acceptance testers, customer contract officers, customer management, future software maintenance engineers, salespeople, etc. Anyone who could later derail the project if their expectations aren't met should be included if possible.

Organizations vary considerably in their handling of requirements specifications. Ideally, the requirements are spelled out in a document with statements such as 'The product shall.....'. 'Design' specifications should not be confused with 'requirements'; design specifications should be traceable back to the requirements.

In some organizations requirements may end up in high level project plans, functional specification documents, in design documents, or in other documents at various levels of detail. No matter what they are called, some type of documentation with detailed requirements will be needed by testers in order to properly plan and execute tests. Without such documentation, there will be no clear-cut way to determine if a software application is performing correctly.

'Agile' methods such as XP use methods requiring close interaction and cooperation between programmers and customers/end-users to iteratively develop requirements. In the XP 'test first' approach developmers create automated unit testing code before the application code, and these automated unit tests essentially embody the requirements.

”需求规格说明书“最关键的是什么？

是分析问题或项目失败的最可靠的方法之一，如一个复杂的软件项目的需求规格说明书却很简单。需求是详细地描述一个应用程序的外在的功能和特性。需求应该是清晰的、完整的、详略得当、紧密的、可获得的和可测试的。而一条不可测的需求可能是这样描述“用户界面友好”（太简单的）。一条可测试的需求象这样描述，“用户必须输入他们被分配的密码才能访问程序。”以有用的和有效的方式决定和组织一条详细地需求描述往往是付出很大的努力。；特定的项目应该采取不同的方法。在如何编写需求方面有很多书可以参考。

在描述需求过程中需要涉及到一个项目中所有与“用户”相关的各个方面。“用户”包括公司内部和外部的职员以及最终的用户、用户可接受测试人员、用户的合同签订者，用户管理员、软件维护工程师、销售人员等。涉及到项目最后是否与他们设想的一致的所有可能的相关人员。

项目组织中想当然的改变需求规格说明书。实际上，在文档中需求可能这样描述“产品将...”。设计人员才不会对“需求”产生迷惑；设计说明书将能够可追溯到需求规格说明书。

在一些公司中的项目计划中没有需求规格说明书了，而以功能需求文档，设计文档或者以其他不同形式描述需求。不管他们被称作什么名称，为了写测试计划和执行测试，这些带有详细描述项目的文档还是必需的。没有这些文档，就不能判断一个软件应用程序是否正确的实现了。

“敏捷”模式中，例如XP模式，强调程序开发人员和客户/用户之间密切地合作以达到需求的迭代。在XP模式中，强调“测试优先”，也就是在开发人员编写代码之前先创建自动单元测试代码，这些自动测试的代码中包含着软件需求。