The answer is - as has been stated - it depends. I'm sure lots of people will answer for Agile methodologies (which are a far more movable feast) so for completeness I'll go with what you'd have for a fairly standard waterfall methodology:
A scope document - very high level outlining what is and more importantly what is not in scope of the project and what assumptions are being made. The main purpose of this document is to set expectations of what will ultimately be delivered - you're not saying how things will work but you're trying to answer questions such as will there be reporting? Will it pass data to other systems? Will you have to write your own user management functionality or pull from AD? Where you can't get definite answers to these things then include an assumptions section and list what you're assuming will be the case so people can correct you if you're wrong. It should also include things like target implementation dates (not as a commitment but so people know what is anticipated and manage expectations accordingly).
A functional specification - What the application should do on a business level. This can be divided out into business requirements (the business processes it's automating and how they work) and functional requirements (what the system does and how it does it - screen navigation, how calculations are made and so on) but more commonly they're combined except for the largest systems. It should also include "non-functional" requirements such as performance, load, security and so on.
A technical specification - The most likely to be missed out. A detailed technical design including things such as object models, schema diagrams and information on how detailed technical problems are being addressed.
Test plans and test scripts - How the application is being tested with detailed test cases, data and expected results, covering all elements of the system.
User guide and Release Notes - How to install, configure and use the application.
The one I'd add to this is a support document - a short (less than 10 pages) crash course in what the app does and how it does it. Developers will often not read the full specifications (either because they don't have time or don't want to) so this document should be enough to allow them to understand what it does, how it works, the areas of the application which are most likely to be problematic and so on. It would be written a few weeks after go live by the team who built and implemented the system.
Of course depending on your methodology you may have none of these documents but if you're running a standard project in an old school structured, waterfall way, this would be pretty normal.
I'll use the typical consulting answer... 'It Depends'.
To start, methodology has an enourmous impact on the documentation artifacts (not to mention project success), and I would place waterfall-style project management on the same level as allowing my doctor to cover me with leeches to cure a broken leg.
That being said - I have seen folks use the Microsoft Solutions Framework, and here's a link where you can grab their templates:
In reality, I would strongly recommend any project to use Agile methodologies and engineering practices (at least, if you want it to have a much higher chance of success than a waterfall project).
测试 - 当用户对版本进行测试时，他们会根据之前提供的测试用例和测试场景来验证版本。发现的缺陷被记录下来并发送回开发团队。这些缺陷首先由 BA 进行验证，以确定所报告的缺陷是理解缺陷、功能需求失效还是技术错误。因此提供了解决方案。在此阶段，要注意确保所有测试用例均成功完成并解决所有错误。如果任何测试用例或错误要保留到下次运行，那么根据它将对功能产生的影响，开发团队和业务用户将就所涉及的风险进行联合呼吁。最后，业务用户准备测试签核文档，其中提及每个资源用于测试、观察和流程改进建议所花费的时间。
生产部署 - 这包括部署团队、服务器和数据库管理员执行部署的部署说明。
请随时提供您的建议。
In a typical production scenario, where the development is not carried out at the client location, generally waterfall model of SDLC is followed and documents pertaining to various stages of WFM are prepared:
Requirement gathering - Business Requirement Specification that details the complete requirement. This is functional in nature. This is accompanied by test case scenarios provided by users in which the users mention the testing and test cases that they would carryout on the desired functionality. This serves as a guideline to the development team as well to build the scope of the functionality and validations.
Requirement Analysis - During this phase, the BA associated with the project carried out the impact analysis and feasibility analysis. The limitations if any in the requirements, constraints, assumptions are documented, shared with the business users and signed-off to avoid any further surprises.
Development Approach - During this phase, the development team lead or the system analyst prepares an approach doc that defines the process flow, screen design, controls that will be placed on the screen, validations, attributes, database diagram, etc. This is then signed-off with the BA. If the development team foresee any technical constraint that will impact the desired functionality, same is shared with business team again and signed-off.
Testing - When the users carryout testing on the release, they validate the release based on the test cases and test scenarios provided earlier. The defects found are documented and sent back to the development team. The defects are first validated by the BA to ascertain whether the defect reported in understanding flaw, functional requirement lapse or technical bug. Accordingly resolution is provided. During this phase, care is taken that all the test cases are completed successfully and all the bugs are resolved. If any test case or bug is to be parked for next run, then basis the impact that it will have on the functionality, a joint call is taken by development team and business users on the risk involved. At the end, Business Users prepare testing sign-off document where they mention the time taken by each resource for testing, observations and process improvement suggestions.
Production Deployment - This includes the deployment instructions for the deployment team, server and database administrators to carryout deployment.
发布评论
评论（3）
答案是——正如已经说过的——这取决于情况。我相信很多人都会选择敏捷方法论（这是一场更具流动性的盛宴），因此为了完整起见，我将采用相当标准的瀑布方法论：
我要添加的内容是支持文档 - 一个简短的（不到 10 页）速成课程，介绍该应用程序的用途和操作方式。开发人员通常不会阅读完整的规范（因为他们没有时间或不想），因此此文档应该足以让他们了解它的用途、工作原理以及应用程序的领域最有可能出现问题等等。它将由构建和实施该系统的团队在上线几周后编写。
当然，根据您的方法，您可能没有这些文档，但如果您以老式结构的瀑布方式运行标准项目，这将是很正常的。
The answer is - as has been stated - it depends. I'm sure lots of people will answer for Agile methodologies (which are a far more movable feast) so for completeness I'll go with what you'd have for a fairly standard waterfall methodology:
The one I'd add to this is a support document - a short (less than 10 pages) crash course in what the app does and how it does it. Developers will often not read the full specifications (either because they don't have time or don't want to) so this document should be enough to allow them to understand what it does, how it works, the areas of the application which are most likely to be problematic and so on. It would be written a few weeks after go live by the team who built and implemented the system.
Of course depending on your methodology you may have none of these documents but if you're running a standard project in an old school structured, waterfall way, this would be pretty normal.
我将使用典型的咨询答案......“这取决于”。
首先，方法论对文档工件有巨大的影响（更不用说项目的成功），我将瀑布式项目管理置于同一水平，就像允许我的医生用水蛭覆盖我来治疗断腿一样。
话虽如此 - 我见过人们使用 Microsoft 解决方案框架，这里有一个链接，您可以在其中获取他们的模板：
http://www.microsoft.com/downloads/details.aspx?FamilyID=9D2016AD-6F8A-47F5-84FA-BEC389DB18C1& ;displaylang=en&displaylang=en
实际上，我强烈建议任何项目使用敏捷方法和工程实践（至少，如果您希望它比瀑布项目有更高的成功机会）。
http://www.agilealliance.com/ 有一些很好的读物，维基百科 http://en.wikipedia.org/wiki/Agile_software_development
祝你好运！
I'll use the typical consulting answer... 'It Depends'.
To start, methodology has an enourmous impact on the documentation artifacts (not to mention project success), and I would place waterfall-style project management on the same level as allowing my doctor to cover me with leeches to cure a broken leg.
That being said - I have seen folks use the Microsoft Solutions Framework, and here's a link where you can grab their templates:
http://www.microsoft.com/downloads/details.aspx?FamilyID=9D2016AD-6F8A-47F5-84FA-BEC389DB18C1&displaylang=en&displaylang=en
In reality, I would strongly recommend any project to use Agile methodologies and engineering practices (at least, if you want it to have a much higher chance of success than a waterfall project).
http://www.agilealliance.com/ has some good reading, as does wikipedia at http://en.wikipedia.org/wiki/Agile_software_development
Good luck!
在典型的生产场景中，开发不是在客户端进行的，通常遵循 SDLC 的瀑布模型，并准备与 WFM 各个阶段相关的文档：
需求收集 - 详细说明完整需求的业务需求规范。这本质上是功能性的。这伴随着用户提供的测试用例场景，其中用户提及他们将对所需功能执行的测试和测试用例。这可以作为开发团队构建功能和验证范围的指南。
需求分析 - 在此阶段，与项目相关的 BA 进行了影响分析和可行性分析。记录需求、约束、假设中的任何限制，与业务用户共享并签署，以避免任何进一步的意外。
请随时提供您的建议。
In a typical production scenario, where the development is not carried out at the client location, generally waterfall model of SDLC is followed and documents pertaining to various stages of WFM are prepared:
Requirement gathering - Business Requirement Specification that details the complete requirement. This is functional in nature. This is accompanied by test case scenarios provided by users in which the users mention the testing and test cases that they would carryout on the desired functionality. This serves as a guideline to the development team as well to build the scope of the functionality and validations.
Requirement Analysis - During this phase, the BA associated with the project carried out the impact analysis and feasibility analysis. The limitations if any in the requirements, constraints, assumptions are documented, shared with the business users and signed-off to avoid any further surprises.
Feel free to provide your suggestions.