李子佩说的都队需求文档编写心得
一．团队项目信息
项 目 名 称：基于遗忘曲线的英语词汇学习系统（纸云记单词小程序）
指 导 老 师：陈浩
开 发 小 组：李子佩说的都队
小 组 成 员：
李子佩、李锦浩、李倩茹、张中信、高伊格、李德忠
二．需求文档编写流程
- 小组讨论需求，与项目负责人开会确定需求
- 用墨刀制作需求原型
- 与项目负责人讨论原型改进方法
- 改进原型
- 小班讨论课验收项目原型
- 二次改进原型
- 根据原型总结需求文档要素
- 分工进行需求文档编写
- 汇总各部分需求文档，进行排版、美化
三．项目需求分析团队成员个人心得
1.李子佩
我负责的部分是文档和项目的概述、用户说明，以及项目总体用例图的绘制。
编写概述和用户说明需要对项目有一个全面的了解，并且站在各类用户的角度体会项目的作用。因此编写这部分的内容，进一步完善了我对项目的认识。
我负责的需求文档的部分的难点在于对用例图的绘制。之前只在课上见过老师用PowerDesigner绘制用例图，并没有跟着进行实操。到自己开始做的时候，在最初一段时间很难适应这个软件的操作。比如不能通过触控板直接放大缩小，不能自定义箭头的路径，还有一改变颜色就会将虚线变成实线，等等问题。不过熟悉之后可以发现，绘制用例图还是相对简单的，只需用到几个工具，也多亏了同组的成员慷慨伸出援手，一开始就为我单独演示了用例图的绘制方法，才让我能在比较短的时间内进入状态。要将项目所有的用例绘制出来，工作量会比较大，但是画出来的时候是很有成就感的。这也让我再一次感受到，面对一项任务不用一开始就感到畏惧。自信一点，用比较好的心态来学习它，万一就能顺利完成呢。
让我感到很好的一点还在于，由于用例图在功能需求中的每部分都要展示，所以组内几乎每位成员都接触了用例图的绘制，熟悉并掌握了用PowerDesigner制作用例图的方法。并且，全员都参与到了需求文档的编写中，没有人觉得应该把文档的编写交给某位应该负责文档的同学来做，而是一起分担文档的编写。
接下来的工作可能会很繁忙，希望我们组能一直都有这种不逃避不放弃的精神，而且要尽量保证充足的睡眠！
2.张中信
我负责撰写的部分：
需求文档中我负责的部分是学生部分的用例图，以及教师、家长、学生三种 对象的功能汇总。
在撰写需求文档过程中的收获：
·如何画用例图，只是在课堂上看到老师简单示范过，自己并未动手实践，所以这次撰写需求文档时才意识到自己好像并没有分清楚扩展和继承两个概念的区别。最后通过再浏览一遍老师上课的ppt解决了疑惑，完成了用例图；
·因为我们组的学生、教师、家长的需求功能是分到不同的成员分别撰写的，所以最后由我汇总的时候，发现负责家长部分的同学和我的文档模板以及功能划分模板基本一致，但是负责教师的G同学却与我们不太一致，所以最后 还是辛苦了G同学在她的基础上进行了修改。这让我们又得到了宝贵的经验：在细分到个人完成的需求文档部分时，应该要先商定好功能划分的模块 以及文档模板，这样就防止了在今后再花时间做修改。
·一开始我们小组和负责的学长并没有完全确定好需要实现哪些功能，第一次开会时讨论的是可以持续性地增加功能，不断完善小程序，但是随着项目的开展发现这其实是并不可行也不科学的。可以先确定一些功能需求，如果把 这些功能做得很好了，可以再在原基础上增加功能,否则需求文档以及后续数 据库的设计、编码的实现等都会遇到困难。
3.李德忠
这次团队项目是做基于记忆遗忘曲线的英语学习系统，在小组和项目负责的学长第一次接触探讨后，我初步了解到这次的项目是在一个微信小程序的基础上进行的，学长也向大家简单展示了一下这个项目最基本的功能性需求—智能笔单词听写，而我们的任务就是在这个基础功能上进行需求增加。根据项目要求，我们需要做出基于遗忘曲线的单词记忆，经过小组的讨论，我们确定下来增加以下需求：1.单词复习功能（基于记忆遗忘曲线）2.实现单词分类，导出错词功能；3.添加家长教师登录，查看学生学习进度功能；角色包括：家长、学生和教师。我在项目需求中主要负责功能需求分析里的学生视角和最后的文档汇总排版。
在进行有关学生视角功能需求分析编写时，我主要分为了学生注册、登录系统、单词听写、单词复习、导出错题、查看学习进度这六个部分进行的。每个部分按照基本流程、分支流程和数据需求三个模块来写的。三个模块我认为分支流程是最复杂的，在写这部分时需要仔细思考，因为你必须考虑到用户的所有可能的非正确操作，系统不仅要能对正确行为做出正确反应，对应错误操作也要能够给出提示信息给用户，不能直接出现卡机的现象，所以在编写代码之前就要考虑清楚，这些功能实现时会遇到哪些问题，然后根据不同问题对应有不同的分支流程进行解决，以保证最后各个功能能够流畅的实现。在编写这部分的时候，也要感谢一起合作的小组成员，因为我对那个图形建模语言的画法不熟悉，所以这部分UML图是由另一位合作的小组成员完成的，这也让我明白了团队的重要性，每个人都有自己擅长的和短板，只有互相取长补短才能达到最高的效率。关于最后文档排版还要感谢组长和其他成员提出的建议和做出的修改，因为个人完成时候肯定会有一些细微的错误，而且这些错误自己是很难发现的，包括打字错误、序号错误以及一些信息拼接时的不对应等等，经过小组成员的共同努力，最终成功按时完成了项目需求文档的编写。
这次项目需求文档，我最大的收获有二个，第一是学会了项目需求分析时的思路与流程，第二就是认识到团队协作的重要性。一个项目不是一个人就能完成的，小组的每个人都要付出互相协作，思想上积极交流，工作上认真负责，这个项目的完成才能更高效、更完美，而且在项目进展中，每个人也可以学习到许多新的知识，了解到好的方法，这对我们今后的就业或继续从事学术都有巨大帮助。
4.李倩茹
这次项目需求文档中我主要负责家长功能部分，包括家长注册，家长登录，修改密码，家长切换学生，家长添加学生，查看学习情况几个部分。编写初期，简单认为只需要将powerdesigner中的E-R图导出即可，没有考虑文案的必要性和重要性。
参考了别人的文档，发现需求文档不止是展示E-R图那么简单，还应该有我们具体功能的基本流程实现和分支流程内容。这样才是一个完整的需求分析，虽然图片简洁明了，但也不能只有图片，而忽略文字说明的重要性，这种分析思想的完整性是我需要在以后的学习中要贯彻和学习的。
比如家长注册的时候，可以直接用已有账号选择登录功能，也可以选择注册功能，但是选择注册的话就需要进行输入密码，确认密码，获取验证码等操作。这里在画图的时候，对于extend和include的理解更加深刻了。同时，对我们这门课“做中学”的宗旨也有了更深的理解与体会。
分析一个需求的时候，不仅要关注其流程和分支，也要关注数据，从哪来到哪去，因为我们最终的操作还是依托于数据的，因此在分析需求时要关注数据需求，这是我之前不会考虑到的东西，学习的内容还很多，路还长，要加油！
由于时间有限，不能亲自与客户使用者沟通了解业务需求，这就需要我们自己设身处地，利用已学过的需求获取的知识，对功能需求进行挖掘和分析。学以致用，在这门课程中贯穿始终。团队的目的不仅在于分工，还在于协作，集思广益能想出更完善具体的功能需求，为开发指明了方向。同时，需求文档也是后期开发和数据库设计的指导文件，千里之行始于足下，要重视开始的第一步，认真且不遗漏。
在编写需求文档的过程中，自己使用powerdesigner的水平和熟练度也有所提高，在完成一件事情的时候，总需要很多别的技能来辅助自己，要在这种磨练种，不断打磨自己，尽可能全面完善自己的能力与知识储备。期待更好的自己！
5.高伊格
需求获取与分析
需求的获取首要来自与客户的沟通。我们与项目负责人开 展会议，通过他的介绍和演示，了解了目前项目的进展，以及部分期望实 现的功能；由于需求的模糊性，我们也要向对方提出询问，明确该项目面向 的学生群体 属于哪些年级，部分功能需求想要实现的具体细节；此外，由于需求的隐蔽性，许多可扩展功能和非功能性需求需要我们站在用户的角度深入挖掘。例如，我们提出查看学习情况时，可以获得可视化的成绩图表，使学习情况更为直观。
项目界面原型
由于我们的项目是基于已有项目进行开发的，因此在设计界面原型时，要延续已有界面的风格，保证整个项目风格统一。虽然界面原型只是 概念展示，但是展示信息的内容必须要具有意义，以便用户针对其提出修改 要求，使得需求更贴近用户期望。
需求确认
在最终的需求文档形成前，需求分析各个阶段的成果都要和项目负责人反复确认，并根据负责人的意见和建议进行修改，以确保需求是完全符合项目要求的，这样的需求分析才达到目的。
形成需求文档
根据完善后的项目界面原型，对需求进行梳理、归纳和汇总，整理出用例列表，绘制用例图，并编写需求文档。内容包括项目概述、用例描述、系统需求等，其中主要对不同的用户进行分类，从用户的使用角度出发，构建详细、易于理解、体现用户与系统交互的用例描述。完成了需求分析后，需要对需求进行梳理、归纳和汇总，形成文档记录，作为将来验收项目的标准，同时 也是开发人员进行开发的指导依据。因此需求文档要规范化，各项指标要求 具体。其中较为主要的是用例描述，我们要从用户的使用角度出发，体现用户和系统的交互，并且易于理解，不涉及内部系统实现。
6.李锦浩
我负责编写了一下几个方面的内容：
(1)其他要求
在撰写需求文档的“其他要求”部分的时候，一开始是比较慌张的。之前没 有接触过有关微信小程序的开发和上线经验，对于具体的性能要求没办法给 出一个符合行业标准的要求。但在经过咨询相关经历人员和百度支持之后， 也对于基础的要求有了大概的理解并写出了以下暂定的标准
(2)界面要求
在目前小程序众多、英语单词学习软件盛行的情况下，界面的美化要求特别 重要。再参考了目前大热门的各类英语
界面需要交互友好，不能产生有歧义的操作指示，尽可能采用菜单、按钮驱 动的图形用户界面，各种功能都能通过点击屏幕的方式驱动，操作简单、形象直观、使用方便。
(3)系统性能、能耗
关于能耗方面，当时对于“程序包最大限制为2M”出现理解性错误，此处 的程序包应该为开发时调试的程序包大小限制为2M。能耗方面，耗电率应 该尽可能降低，且是对网络资源占用率较低的情况。
(4)数据正确性
数据的正确性将为该项目的最重要的点之一。如果学习时间数据出错，则会 导致数据经过模型处理之后错误，导致学习的时间不如预期。我们通过在后 端进行数据正确性的验证，以及日期在后端进行生成输入数据库，尽可能减 少前端的额外数据带来的潜在问题。并且需求中有可视化、以及积分兑换等 功能，所以数据的正确性和一致性十分重要。
(5)适用规模
本项目主要面向有学习英语、听写英文单词的需求的人群。可以个人为单位使用，也可以以班级为单位进行使用。不仅仅是正式学校里的行政班级，也包括课外班。
(6)系统响应时间
响应时间有一个“3-5-8”原则：如果用户发出一个请求后，这个请求在3s 之内得到响应，那么给客户的感觉是该系统性能十分优秀，5s之内请求得到 响应，用户会感觉还不错，但当请求响应时间超过8s甚至更长的时间之后，用户很有可能就失去信心，从此以后不再访问或者不再喜欢访问该网站、使用该程序。所以我们暂定我们小程序的加载时间为3s-5s之间，各项交互的 响应时间应该在6s以下。
(7)网络传输
设计的小程序出于方便考虑，应不限制网络环境。
(8)可维护性，可拓展性
鉴于本项目是一个商业项目，后续可能会根据用户需求加入更多的需求。所 以设计的小程序应该是低耦合的，具有可扩展性。
(9)代码可读性
该项目以后需要交付对应人员进行进一步的维护，所以代码中应该有良好的可读性。
(10)开发平台及环境
由于本课题是基于一个已有的项目上，增加需求，所以本部分的具体内容根据实际项目要求规范进行填写。
