团队项目第二周 - 需求规格说明书 - 天冷记得穿秋裤队

队员姓名	学号
陈俊旭（组长）	3116004630
夏瓦克提·木合塔尔	3116004658
张婷（副组长）	3216004672
周方源	3215004673

随着人民日益增长的资源获取需求与资源节点不足的矛盾日益增长，为了提高单机下载速度，我们团队打算实现一个具有离线下载功能的下载器，功能类似于百度云盘的离线下载。用户可以将下载链接添加进下载器中，下载器离线下载完毕后可以取回文件。以下是针对第一周的初步设计，给出的更进一步的详细的需求分析。

需求规格说明书

基本需求

支持单用户单文件的离线下载
支持删除离线文件
简单的命令行界面

面向用户分析：对于一款主打离线下载的下载器来说，最核心的功能就是离线下载。用户需要的是能够下载到文件，并且为了隐私可以删除掉文件

功能性分析：提供下载器最基本的功能，即下载。基本需求里面的支持下载功能可以将用户的下载链接上传到服务器，再将服务器下载的结果返回给用户；用户下载完毕后可以选择删除自己的离线记录；可以通过命令简单的控制整个下载流程，包括选择文件存取路径等等

技术需求：需要通过aiar2解决服务器与客户端之间文件的传输问题；需要支持简单的命令行输入控制

高级需求

支持单用户多文件的离线下载
支持查看文件离线下载进度
提供Chrome的扩展程序界面
支持文件上传

面向用户分析：很多情况下用户并不只是下载一个文件，他们还需要同时下载多个文件，并且需要知道自己的下载任务还有多久结束，因此希望有一个进度条和剩余时间方便管理下载。大多数用户并不会用命令行下载文件，这对于大多数人来说十分不友好，他们希望有一个轻量级的下载工具；有时候用户还希望通过下载器保存一些文件，因此需要用户上传

需求性分析：当用户多任务的离线下载是目前所有下载器支持的特性，而且对于下载器来说是刚需；更加友好的下载页面既可以方便用户下载，也可以方便用户对下载进行管理，是最直观的留存用户的手段

技术需求：需要解决多文件同时下载的并发问题；需要利用 js 和 css 开发一个 extension；需要对下载流进行额外的控制，如增加一个控制流告诉客户端下载信息

进阶需求

支持多用户多文件同时下载
对于离线的视频文件可以在线观看
更加严格的系统安全控制（如隔离有害文件等）
更加安全的文件保存策略（如多级备份等）

面向用户分析：用户在理想视频的过程中，相比于将视频下载后再在本地打开观看，更希望能够直接观看视频；而且用户对于文件下载的隐私非常在意，希望更好的保护自己的下载信息；用户还希望下载器能完全地保护他们的信息，而不被泄露或者遭受破坏

需求性分析：增加多用户支持符合当今下载器的现状，可以更加方便地对每个用户的下载文件进行管理和控制；对于服务器来说安全至关重要，因此不仅需要抵抗来自服务器外的侵略，还要隔离来自用户下载的有害文件的攻击

技术需求：需要解决多用户访问服务器的端口问题；需要对服务器的硬盘进行分区保护；需要支持简单的用户管理

系统进一步阐释

真实性
- 目前市场的同类软件有：迅雷，百度网盘下载等。每个网络用户都有文件下载和上传的需求。
可用性
- 我们团队的文件离线下载器力求在达到目前市场基本文件下载器功能的同时，达到文件下载管理和文件下载云存储等方面的友好使用程度。
- 作为一款轻量级的文件离线下载器，用户在拥有基本的上传和下载文件的基本功能的同时，能够不被服务端限制下载速度（比如迅雷下载的限速现象，普通用户只有在开通会员才能达到最大速度上传），而我们团队的项目致力于实现每个用户不进行限速，下速度只取决于用户的带宽，从而解决如今用户对现今市场下载软件诸如此类做法的不满。
价值性
- 对用户来说，可以极大提升下载体验；用户将下载任务上传至服务器端后，由服务器负责下载文件，用户可以关闭电脑或者进行其它作业，当服务器下载完毕后再拉下来，这样子可以充分利用用户宽带，因为传统的下载节点一般会限制下载速度，而我们的SmellyCat离线下载器并不会。
- 对提供下载的网站来说，可以分流下载流量，避免对服务器造成过大负载；在没有离线下载器之前，下载网站是与用户建立一对一的连接，需要给每个用户分配一定的下载资源，容易造成服务器负载过大。而当用户使用离线下载后，用户是从我们SmellyCat下载资源，我们再通过一定的策略集中访问下载网站，避免多个用户对于同一文件的多次下载。
- 对运营商来说，可以更有效地进行流量控制和拥塞控制；由于我们的SmellyCat集中处理了用户的下载请求，可以使得网络中下载的密集度降低，减轻了运营商的压力。
有情怀
- 我们实在是看透了某雷某度云盘的离线下载限制，因此很努力地想要开发一个真正为用户下载体验着想的离线下载器。我们希望将这个项目开源，不仅是为了集思广益，更是为了让社区用户知道我们的透明实现过程，而不是暗箱操作偷偷修改下载速度。
- 此外，我们开发完服务端离线版本后，将可能进一步开发客户端离线器，顾名思义就是用户可以选择贡献自己的宽带，以提高整个社区的下载速度。

项目相关

项目码云地址：SmellyCat

预期用户数量：由于下载器对服务器性能要求较高，因此第一个版本预期支持最多50

团队计划

issues列表

将团队的任务计划添加到码云的团队项目issues里面 (√)

原有安排

时间	任务进度
第6周	1.团队组队，团队博客（√）
	2.团队介绍、成员展示、角色分配、选题确定（√）
	3.制定团队计划安排，团队贡献分的规定（√）
第7周	1.需求规格说明书
	2.原型设计，队员估计任务难度并学习必要的技术
	3.编码规范完成、平台环境搭建完成、初步架构搭建
第8周	1.原型改进（给目标用户展现原型，并进一步理解需求）
	2.架构设计，WBS, 团队成员估计各自任务所需时间
	3.测试计划
第9周	1. 团队项目Alpha任务分配计划
	2. 连续7天的Alpha敏捷冲刺，7 篇每日Scrum Meeting博客+代码提交
第10周	1.用户反馈+测试计划改进
	2. 团队Alpha阶段个人总结
	3. 团队项目Alpha博客：发布说明、测试报告、展示博客、项目管理
第11周	1. 团队项目Alpha博客：事后分析
	2. 每个团队有一人必须离开，自己寻找下一个接纳自己的团队。团队发博客宣布离队和接纳的成员。
第12周	1. 团队项目Beta任务分配计划，介绍新成员
	2. 连续7天的Beta敏捷冲刺，7 篇每日Scrum Meeting博客+代码提交
第13周	1. 团队项目Beta博客：发布说明、测试报告、展示博客
	2. 团队Beta阶段个人总结
第14周	1. 团队项目Beta博客：事后分析，宣布每人的贡献分
第15周	1.团队整个阶段总结，分析用户数据，整理文档，保证以后的团队能接手。

校正后的安排

时间	任务进度
第6周	1.团队组队，团队博客（√）
	2.团队介绍、成员展示、角色分配、选题确定（√）
	3.制定团队计划安排，团队贡献分的规定（√）
第7周	1.需求规格说明书（√）
	2.原型设计，队员估计任务难度并学习必要的技术（√）
	3.编码规范完成、平台环境搭建完成、初步架构搭建（√）
第8周	1.原型改进（给目标用户展现原型，并进一步理解需求）
	2.架构设计，WBS, 团队成员估计各自任务所需时间
	3.测试计划
第9周	1. 团队项目Alpha任务分配计划
	2. 连续7天的Alpha敏捷冲刺，7 篇每日Scrum Meeting博客+代码提交
第10周	1.用户反馈+测试计划改进
	2. 团队Alpha阶段个人总结
	3. 团队项目Alpha博客：发布说明、测试报告、展示博客、项目管理
第11周	1. 团队项目Alpha博客：事后分析
	2. 每个团队有一人必须离开，自己寻找下一个接纳自己的团队。团队发博客宣布离队和接纳的成员。
第12周	1. 团队项目Beta任务分配计划，介绍新成员
	2. 连续7天的Beta敏捷冲刺，7 篇每日Scrum Meeting博客+代码提交
第13周	1. 团队项目Beta博客：发布说明、测试报告、展示博客
	2. 团队Beta阶段个人总结
第14周	1. 团队项目Beta博客：事后分析，宣布每人的贡献分
第15周	1.团队整个阶段总结，分析用户数据，整理文档，保证以后的团队能接手。

矫正计算方法

由于第六周和第七周给出有充足的时间进行系统设计和需求分析，这两周的小组成员都可以按照计划稳步推进，因此可以完成原有计划表给出的安排，本周暂时不需要对计划表进行矫正

其他

团队分工

队员姓名	分工
陈俊旭	开发服务端的下载模块，向前端提供文件下载和管理的接口
夏瓦克提·木合塔尔	测试前端插件是否符合用户习惯，是否能正常下载文件，并提交反馈报告
张婷	开发chrome插件模块，负责向用户提供管理界面，并且支持友好的交互体验
周方源	协助张婷同学进行前端开发，及时处理组员间的讨论纠纷

完成情况

队员姓名	完成情况
陈俊旭	初步完成需求分析
夏瓦克提·木合塔尔	初步完成需求分析
张婷	正在学习chrome插件开发知识
周方源	初步完成需求分析

感想

陈俊旭： 我们分析了整个项目应该如何下手，虽然过程中大家都有分歧，但是PM的带领下大家都能回到理智的讨论中，希望大家能进一步努力

夏瓦克提·木合塔尔：作为测试人员前期的工作不多，主要是参与需求的讨论，在讨论过程中能知道其他同学是怎么想的

张婷：在需求确定完成后我就开始着手学习相关知识，可以说明确的需求真的可以缩短学习的周期，因为更加清楚确定需要什么技术

周方源：认识到作为一名PM真的需要对项目有很好的把控, 一方面是避免小组成员无意义的讨论,另一方面是可以发散大家的思维, 做出大家都满意的产品