如何编写参赛作品的介绍文档  （大赛组委会老师个人建议）

本人声明：这里所写的内容只是我个人的观点，不代表大赛官方，仅供选手参考。这个不是标准模板， 大赛介绍文档没有模板，自己的文档应该怎么写比较好是你们自己考虑的事情，事后不能以此文档的建 议作为评价标准来要求。 

参赛作品提交要求： 1. 介绍文档：综合描述作品和团队情况，内容应包括但不限于小程序说明、应用场景、解决的实际问 题、技术开发方案（包括小程序端和后台服务器端）、团队组成与分工等，如果引用非团队成员的开 发成果，务必在文档中说明。文档要求提交PDF格式，文件大小在10M以内。 2. 演示视频：演示参赛作品的主要使用流程并配上讲解，时长限在3分钟内。 3. 小程序appid。 

很多学生一直在问到底如何写介绍文档，我这里将之前在群里的讨论交流归纳整理如下几点建议， 选手可以参考，但不要局限于此。 

（一）介绍文档有什么用？让评委老师更好地了解你的作品！ 

虽然开发团队对自己的作品很熟悉，但是评委并不清楚这个小程序，包括应用背景、内部技术、作 品特色以及未来运维等等，这些内容也无法通过直接试用而全面了解，所以团队需要在文档中清楚地展 现这些内容。 

（二）介绍文档主要应该写什么？简单地说，就是针对作品评分标准，写清楚相关的内容。下面所列部 分只是一个引导，选手根据自己的产品进行删减和补充，不要全部照搬。 

1. 产品定位 （1） 应该说清楚这是一个什么小程序，具体的应用场景是什么以及解决什么实际问题？建议直接了 当，突出重点，应用场景和实际问题要有一定的调查材料支撑，注意不能是网上随便抄来的。 这部分是让评委大概了解这个小程序是干什么用的以及为什么要开发。 （2） 提出现实问题之后，建议简单地阐述一下自己的产品方案，这里的方案不是技术方案，而是自 己打算做一个什么样的产品来解决现实的问题。 2. 需求分析 虽然参赛的介绍文档中没有明确说明要做需求分析，但是产品定位的评分中要求有明确的目标用户 和使用场景，所以比较好的做法是进行用户和需求分析。 

（1） 在用户和需求分析方面，大家可以采用自己学过的一些方法和技术，原则就是用户分析到位， 系统需求应该包括功能需求和非功能需求，不论是哪方面的需求，都应该是紧密结合自己要开 发的系统，而不是泛泛地抄一些类似教科书上面的内容。 （2） 举例：参观清华的非功能需求就是根据系统的实际要求，提出了关键的三个内容：一是性能， 给出具体的量化指标；二是安全性，诸如身份证敏感信息等；三是可靠性，包括停电和断网问 题、游客快速进入的问题等。 3. 交互设计 交互设计部分应展现整个系统的信息结构，说明配色和整体设计原则，把系统核心功能的交互设计 图展现出来，然后选择自己认为可以突出亮点的几个关键设计进行说明。 4. 技术方案 技术方案部分应给出系统的总体框架设计图，并做相应的说明，然后给出系统的技术选型、开发环 境，包括所采用的框架、第三方组件等。总体框架介绍清楚之后，应该着重介绍系统开发方面自己的突 出贡献部分或者亮点部分，这个需要根据自己开发的系统进行归纳，选择核心重点或技术难点部分来说 明相应的技术实现。 5. 系统测试 这个部分是可选的，为了说明自己系统的最终效果，可以考虑写一下功能测试和性能测试，说明测 试方案和测试结果，要注意清楚而且有实际的真实测试结果，不要乱写乱编。 如果自己开发的系统非常简单，而且没有特别的性能要求，可以忽略这部分。 6. 系统上线与运维 对于一些需要自己运营的作品，这部分也是非常重要的，需要说明如何上线以及未来的运营和维护 方案，特别是一些需要特殊资质的作品，更要说清楚这一点。 

（三）其他 

也许同学们认为评委只要体验小程序就应该可以了解整个作品，实际上小程序本身呈现的更多是从 用户角度的使用，对于小程序的应用背景、交互设计思路、所用开发技术的复杂度和难度以及系统实现 水平等，很难从简单的试用了解清楚，因此需要开发团队在文档中写清楚，以便评委更好地了解你们的 作品。但是，需要特别强调的是要阐述清楚和突出重点，切忌胡抄乱写，也不建议套用所谓某些软件工 程文档模板而长篇大论，太长的文档是很难读的。