任务详情
1.修改完善上周提交的需求规格说明书，并在博客中描述：上次的《需求规格说明书》初稿有哪些不足？修改需同时体现在Github的MarkDown文件与PDF中。
2.讨论制定团队的编码规范，讨论之前和讨论之后，队员阅读《构建之法》第四章内容，并讨论总结。将代码规范和编码原则发布在随笔上，并说说你们这么选择的理由。
3.通过Powerdesigner完成团队项目的数据库设计，并在随笔中提供相应ER图。
4.进行项目的后端架构设计，要与需求规格说明书中的界面原型设计相对应。
5.确定团队分工。请参考"分而治之(WBS - Work Breakdown Structure)"，提供下述内容：
- 利用象限法确定各个核心需求的优先级，依据需求优先级确定团队Alpha 版本需要实现的功能，在博客中叙述并给出相应的WBS图。
- 在团队管理软件中（比如Github的Issue，Leangoo等）将各个叶子结点的功能加入，并确定每个子功能的工作量，在博客中给出分配后的截图。值得注意的是，与学习技术相关的任务也需要考虑在工作量中，开发需要检验产出，学习同样要有结果。PM可以用小Demo演示或学习心得博客作为学习任务的检验。
- 给出团队各个成员（用学号代替姓名）认领的工作，列出当前团队的TODOList，并在最后给出燃尽图。
任务实践
1.修改完善上周提交的需求规格说明书，并在博客中描述：上次的《需求规格说明书》初稿有哪些不足？修改需同时体现在Github的MarkDown文件与PDF中。
1.清晰度和一致性
初版《需求规格说明书》清晰性、易读性不高，排版不够清晰，内容不够易读，且由于多人同时撰写，格式和风格未能遵循一致性，需要进行调整。
2. 完整度和互斥性
初版《需求规格说明书》各版块内容之间存在少量冲突，关联需求并未完成纳入其中，且版块也有遗漏和重复的内容，产生了不必要的工作麻烦和问题。
3. 明确度和合法性
初版《需求规格说明书》中有关功能的描述不够明确、是有一定歧义的，且不太符合特定的行业标准和规范，因此需求完善以防止误解和争议。
2.讨论制定团队的编码规范，讨论之前和讨论之后，队员阅读《构建之法》第四章内容，并讨论总结。将代码规范和编码原则发布在随笔上，并说说你们这么选择的理由。
3.通过Powerdesigner完成团队项目的数据库设计，并在随笔中提供相应ER图。
4.进行项目的后端架构设计，要与需求规格说明书中的界面原型设计相对应。
5.确定团队分工。请参考"分而治之(WBS - Work Breakdown Structure)"，提供下述内容：
- 利用象限法确定各个核心需求的优先级，依据需求优先级确定团队Alpha 版本需要实现的功能，在博客中叙述并给出相应的WBS图。
- 在团队管理软件中（比如Github的Issue，Leangoo等）将各个叶子结点的功能加入，并确定每个子功能的工作量，在博客中给出分配后的截图。值得注意的是，与学习技术相关的任务也需要考虑在工作量中，开发需要检验产出，学习同样要有结果。PM可以用小Demo演示或学习心得博客作为学习任务的检验。
- 给出团队各个成员（用学号代替姓名）认领的工作，列出当前团队的TODOList，并在最后给出燃尽图。