如何为我的软件项目编写技术规范文档？
我在这里看到了几个问题，如果function规范具有所有的function，就不需要编写一个强健的技术规范。 那么客户提供了一个function规格的情况怎么样？您需要从这个文档中转换一个技术规范？
我知道在一家公司内部，编写较小技术规格的解决scheme的某些特定部分是有用的，但是如果技术规范的生产是一个项目里程碑/客户可见度的交付成果，那么写出一个最好的方法是什么？
如果我不知道如何实现一个特定的function，因为我之前没有创build它，该怎么办？ 你怎么能写出这个技术规范的方式，这不是一个灾难呢？
我正在寻找模板/指导/最佳实践build议和任何可以帮助我创build可用于此类项目的文档。
- 定义项目目标
- 定义系统架构/基础架构
- 定义用户对话框和控制stream程
- 定义后台任务
- 定义数据库模型
- 定义到其他系统的接口
- 定义非function性要求（响应时间，安全性…）
- 为所有相关的概念/实体定义一个字典（危险的，你可以省略这个字典）
系统内部不要太具体。
您应该从解决scheme的粗略总体devise开始。 你可能知道的比你想象的权威架构更多。 例如：你需要一个数据库吗？ 应用程序服务器？ 网页服务？ 桌面客户端？ 集群？
然后你开始充实组件，并根据问题的领域和你的知识根据你认为最合适的技术开始问自己一些基本的问题。 例如：Java或.NET？ Django或Ruby on Rails的？ JBoss或Tomcat？ Mongrel还是Apache？ Oracle或MySQL？
然后你进入细节。 你还没有做任何事情，这只是一个初步的文件，而且无论如何你很可能会改变主意。 问问你自己是否需要一个ORM，一个框架，一个库，一个专用设备。 例如：（N）hibernate或Toplink？ 弹簧？ JSF？ Struts的？ 手持设备？ 条码阅读器？ 除非它强迫你改变某些东西（即不兼容性问题），否则不要把这些放在技术规范中。
现在是时候重新审视一切。
在networking上search替代品，任何组件的最新版本，类似项目，开源竞争对手。
添加详细信息，更正错误，研究您所模糊组件的信息。
请你的同事们来certificate你的文件。
不要放下无用的细节，试图解决大规模的问题，而不是微小的优化。 专注于你最了解的东西。 创造一个秒杀解决scheme，只要你觉得喜欢它。
每次你做一个评论，你最好比较架构草图与要求（不要忘记非function性要求 ）。
使其成为一个迭代过程，以便您可以改进它，并且随时准备好交付物，以便进行同行评审和协作。 另外，如果客户对您所达到的细节水平感到满意，最好停下来，以便您可以专注于开发阶段。
也许你可以使用这个文件的整体结构
http://reat.space.qinetiq.com/ssat/docs/ssat_ssd.pdf
1引言8 1.1合同8 1.2文件的目的8 1.3软件的范围8 1.4定义，首字母缩写词和缩略语8 1.5参考文献9 1.6文件概述9 2逻辑模型描述11 3具体要求13 3.1function要求13 3.1.1用户input接口（SR 1）13 3.1.2用户输出接口（SR 2）13 3.1.3 Gentino源定义 - 粒子采样（SR 3）13 3.1.4粒子跟踪（SR 4）15 3.1.5数据的直方图（SR 5）15 3.1.6几何描述（SR 6）16 3.1.7运行重复（SR 7）16 3.2性能要求（SR 8）16 3.3接口要求（SR 9）16 3.4操作要求（SR 10）16 3.5validation要求（SR 11）16 3.6验收testing要求（SR 12）16 3.7便携性要求16 3.7.1平台，操作系统和编译器（SR 13）16 3.7.2移植到其他平台（SR 14）17 3.8质量要求（SR 15）17 3.9可维护性要求（SR 16）17 3.10其他要求 4系统devise18 5组件描述20 5.1主力20 5.1.1types20 5.1.3接口20 5.1.4依赖性20 5.1.5数据20 5.1.6资源20 5.1.7满足软件要求20 5.2 MyGeometryConstruction 20 5.2.1types20 5.2.2function21 5.2.3接口21 5.2.4依赖关系 5.2.5数据21 5.2.6资源21 5.2.7满足软件要求21 ... ... 6用户需求与软件需求可追溯性 matrix38 7软件要求与组件可追溯性matrix 41
有趣的 – 从我这边开始，我总是从一个非常高层次的技术规范（.NET，HTML5，CSS3，AJAX，SQL Server数据库，微软Windows服务器拆分数据库和Web服务器层，2个硬件防火墙，2个软件防火墙等）已经知道我会用。
接下来，我把我的function规范，我看看基本的数据库结构和数据build模。
从那里我看看与第三方系统的集成，特别是通信方法和文件格式（例如XML通过HTTPS发布到Web服务vs CSV通过计划作业上的sFTP）。 然后我看看频率，数据传输的顺序（与文件内的依赖关系有关）以及系统间通信故障的error handling。
我写的技术规范是function规范的扩展版本，其中包含为每个function元素描述的技术规范。
在一天结束时，技术规格本身是可交付的，如果足够详细的话可以作为项目计划和testing计划的基础。
我总是打开整个解决schemestream程的目录和高层次的Visio图表。 这使读者可以跳转到直接适用于他们的部分。
我希望有帮助。
同样来自Joel： The Aardvark Spec
最后你会发现他们的一个项目Copilot的初始规格
- 目的
- 范围
- 系统总览
- 参考
- 定义
- 用例
- function要求
- 非function性要求链接包含每个标题的详细描述。 http://www.stellman-greene.comhttp://img.dovov.comstories/Library/SRS%20Outline.pdf
