Typhoon-Team 实验六 团队作业3：团队项目需求调研与原型开发

项目	内容
课程班级博客链接	2022年春软件工程课程班（2019级计算机科学与技术）
团队名称	Typhoon-Team
团队成员分工描述	1. 张圆圆：博客撰写、背包知识社区系统部分页面原型设计，问卷调研及线上访问 2. 孙得弘:申请表的填写，背包社区论坛部分的设计 3. 姜婷:背包论坛编译练习部分原型设计，问卷调研报告书写，进行个人访谈，博客撰写
作业要求链接	实验六 团队作业3：团队项目需求调研与原型开发
团队的课程学习目标	1. 软件项目需求调研。 2. 学习使用软件原型开发工具。 3. 掌握软件原型开发技术。
这个作业在哪些方面帮助团队实现学习目标	1. 通过阅读《现代软件工程—构建之法》内容，对团队软件项目流程（TSP）、软件项目团队的角色分工，软件项目经理的职责有了深入的了解及学习，并且掌握了敏捷流程原则及相关概念。 2. 通过软件案例分析，对CSDN有了一定程度的学习和了解。
团队博客链接	Typhoon-Team
团队项目Github仓库地址链接	Prototype-development

任务一：团队协作学习《现代软件工程—构建之法》第8章需求分析

一、 《构建之法》第八章 需求分析

8.1 软件需求

1. 获取和引导需求
   软件团队需要找到软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出真实的需求。很多时候用户并不知道自己的确切需求，或者不愿意表达完整的需求，软件团队需要设身处地替用户着想，引导出需求。
   需求不仅来自外界，还可以来自软件企业本身。企业需要一个能维持它生存和发展的商业模式。
   需求还可以来自技术团队本身。
2. 分析和定义需求
   这是指对从各个方面获取的需求进行规整，定义需求的内涵，从各个角度将需求量化:需求实现的最后期限，实现需求大致所需的时间和资源成本，各个不同需求的优先级，需求带来的收益，等等。
3. 验证需求
   软件团队要跟利益相关者沟通，通过分析报告、技术原型、用户调查或演示等形式向他们验证软件团队对于这些需求的认知。
4. 在软件产品的生命周期中管理需求(Management )
   在软件的生命周期中，需求在发生变化，技术在发展，团队成员的能力也在提高。原来认为重要的事情可能不再重要，有些功能原来技术上很难实现，现在出现了捷径，一些相关的法规会发生变化，外部的合作伙伴突然发生变化，这些都要求我们不断对需求进行重新审核并做出相应的调整。
5. 软件需求的划分

项目	内容
对产品功能性的需求	要求产品必须实现某些功能。例如，学校的选课软件只允许有学生身份的用户浏览并选择课程，同时要求学生选择某一门课时必须要满足“先修课”的要求，等等。
对产品开发过程的需求	要求软件的开发流程必须满足某些约束条件，例如，开发过程必须产生某种类型的文档，必须在某个时间点达到某个状态，必须对源代码施以某种约束(安全性核查、代码版权核查、代码规范和支持文档的核查)。
非功能性的需求	这也叫“服务质量需求”( Quality of Service Requirement )，例如，股票交易系统必须在一定时间内返回用户查询结果(它对时间的要求比“科技文献检索”网站要高)，火车票购票系统、大学选课软件必须能支持一定数量的用户同时访问，等等。
综合需求	有些需求并不是单单一个软件模块就能满足，例如，“购物网站必须在24小时内把货物发送到用户手中”，这个需求牵涉到软件系统、货物派送系统、送货部门、监控系统等不同部门的功能和执行能力。

8.2 软件产品的利益相关者

用户：直接使用软件系统的人。
顾客：购买这个软件或者根据合同或规定接受软件的人。这些人不一定是软件的直接用户，但是他们的利益和软件直接相连。
市场分析者:代表“典型用户”的需求，他们或者是市场部门的成员，或者是独立的市场分析人士。
监管机构:在一些行业，软件必须符合许多行业和政策规定（如银行、公共交通、通信、矿产资源等)。
系统/应用集成商:在复杂软件的开发和应用过程中，系统/应用集成商负责给客户提供咨询、服务、集成等工作。有些系统集成商会把客户总的需求分解，并交付给下一级的服务团队来完成。
软件团队:具体完成某一个特定软件或特定功能的团队。
软件工程师:工程师也是软件需求阶段的一个重要角色，软件的各种约束、特性会影响到他
们工作的效率、开发难度和软件维护的难度。他们应积极参与到软件需求阶段中来。
软件开发不可能一次满足所有利益相关者的要求，但是我们一定要让相关角色在这个阶段有机会提出他们的需求和意见，同时，要弄清楚“他们想从软件中得到什么”。

8.3 获取用户需求——用户调研

方法	内容
焦点小组	找到一群目标用户的代表，加上项目的利益相关者来讨论用户想要什么，用户对软件的评价等等。
深入面谈	通过详细的面谈，广泛而深入地了解用户的背景、心理、需求等。这通常是一对一的采访。
卡片分类	在收集这类反馈时我们可以利用“卡片分类”的办法,把各种需求做成便于规整的小卡片，然后反复进行下列活动：讨论→明晰定义→归类→排序
用户调查问卷	这种方法是向用户提供事先设计好的问题,让用户回答。用户调查问卷看似容易，其实大有门道，下面是调查者一些常见的错误： a.问题定义不准确。 b.使用含糊不清的形容词、副词描述时间、数量、频率、价格等。 c.让用户花额外的努力来回答问题。 d.问题带有引导性的倾向。 e.问题涉及用户隐私、用户所在公司的商业机密或细节等。
用户日志研究	这一调研方式要求用户记录自己日常工作或生活中与所用软件相关的行为，供软件团队分析。
人类学调查	这种方法听起来学术味很浓，其实可以解释为——和目标用户“同吃同住同劳动”。
眼动跟踪模式	一些研究发现了F模式：用户通常浏览通栏标题，然后目光沿着左侧下行，再平行浏览下面的子标题。
快速原型调研	拿模型，让用户去使用,得到反馈。这也是用户参与式设计的一个例子。
A/B测试	A/B测试是一种新兴的网页优化方法，可以用于增加转化率注册率等网页指标。AB测试本质上是个分离式组间实验，以前进行AB测试的技术成本和资源成本相对较高，但一系列专业的可视化实验工具的出现，AB测试已越来越成为网站优化常用的方法。

8.4 功能的定位和优先级

我们可以考虑用四个象限来划分产品功能的特点，以便更准确地、理性地了解我们产品的核心价值,从而优化投资策略。
要把用户从竞争对手那里吸引过来，团队自己的产品要有一个差异化的焦点，在这个焦点上，我们的团队能做得比别人好10倍，高一个数量级。这种功能又叫杀手功能，其他功能也很重要，但是它们都是（相对来说）外围的。产品也许有很多功能，但是应该只有一两个功能是杀手级的。于是我们有了两种不同类型的功能:
杀手功能(Core )/外围功能（ Context )。除此之外，我们的竞争对手和用户已经决定了一些此类产品必须要满足的需求，不能满足这些需求，产品就入不了用户和评论员的法眼，当然，还有许多功能是辅助性的。我们又得到另一种划分:
必要需求（Mission Critical )/辅助需求(Enabling )

8.5 计划和估计

8.5.1 目标、估计和决心

项目	内容及举例
目标	表明一个希望达到的状态。例如，软件“五一”之前要投放市场!在建校一百周年之时把我校建成世界一流大学!不论这类目标如何重要，它们未必能够实现。
估计	以当前了解的情况和掌握的资源，要花费多少人力物力时间才能实现某事。
决心	保证在某个时间之前完成预先规定的功能和质量例如，我们跑步前进，全民炼钢，两年超英赶美!

8.5.2 找出估计后面的假设

我们其实并不是不会估计，我们真正不会的，是把估计后面藏着的种种假设全部列举出来。
可以考虑通过Wideband Delphi方法来做到快速沟通并达到意见的一致。这个方法看起来复杂，其实挺简单的:

1. 找到一个主持人（ Facilitator/Moderator )
2. 主持几轮讨论，先确定大家对目标有统一的理解。然后每一轮统计大家对时间的估计，并且询问大家估计值的前提假设是什么，找到合理的假设，然后继续。Wideband Delphi估计法的目的不是比谁的第一轮估计猜得准，而是在较短的时间内让团队充分沟通，交换意见。在这个练习中,很重要的一点是要估计团队自身的能力。

8.5.3 提高估计能力的招数

提高估计情况的方法：

1. 参考前人的经验。
2. 快速原型法——用一两个先锋去探路。

软件工程师在长期的实践中，摸索出一套经验公式:实际时间花费主要取决于两个因素—对某件事的估计时间X，以及他做过类似开发工作的次数N。

Y=X±X÷N //注:Y是实际时间花费。中间的±表示加上或减去。

N值不断增加，估计变化的范围会越来越小，准确度则越来越高。如果把这个公式展开一下，项目的复杂程度将由下面两个因素决定:

1. 需求的复杂程度:程序员是第几次实现类似的需求?有些外行看起来很复杂难懂的需求
   (如银行业务流程)，如果一个程序员已经做过多次相关的银行项目，其实不像外人看的那么难。
2. 技术的复杂程度:程序员是第几次用这个技术实现?

软件成本分析的经典模型COCOMO全面描述了影响软件成本的各种因素：

因素	内容
产品的因素	1.希望产品达到什么样的可靠性标准。平均每天重启一次能接受么?还是需要一年99.999%的时间内都能运行? 2.产品的数据量有多大。图书馆管理系统有多少本书?每天有多少事务发生? 3.产品的复杂程度。是一个单页面展现信息的网站，还是一个需要实时处理火车票交易的网站? 4.对模块重用的要求。所有模块都可以重新写，还是必须要重用原来系统的某些老的模块? 5.文档的需求。需要完备的文档,还是“有什么事就问我”?
平台的因素	1.执行时间的约束。是一个实时系统么? 2.存储的约束。数据如何保存,恢复的策略是怎样的? 3.平台变动的约束。编程语言和工具每半年会发生大变化么，还是非常稳定?
人员的因素	1.分析师和程序员的能力。 2.做此类应用的经验，使用开发平台、编程语言和工具的经验，约等于上文公式提到的“类似开发经历”。 3.人员流动性（项目做到一半小伙伴会突然不见了么?)
项目的因素	1.使用项目管理工具的情况。是偶尔口头交流进度和依赖关系，还是全部用熟悉的项目管理工具? 2.工作区。团队成员都在一个办公区工作么，还是全球各大洲都有人? 3.项目进度安排。交付时间紧迫么?有缓冲区么?对于可能的变化有预案么?

8.6 分而治之

WBS通常从最终的产品开始，一层一层往下，把大型交付件（ Deliverable)分割为小型、具体的交付件。这样的分割可以持续下去，直到WBS的使用者（开发团队、接收方)达到共识。从数据结构方面来看，WBS分割的结果是一棵树。所有子节点都最终有一个根节点。每个节点描述的是要交付的产品或文档，而不是开发团队的努力或花费(各个叶节点的成本可以作为次节点的属性展现出来)。
做好WBS的几个要点:

1. 保证所有子节点覆盖了全部父节点包含的内容。
2. 保证各个子节点不要相互覆盖。
3. 叶子节点要保证足够小，能在一个里程碑中完成。在通常的软件项目中，叶节点的成
   本最好不要超过两周。如果团队成员从常理出发，认为叶节点不宜再分下去，那就可以停止。
4. 从结果( Outcome)出发构建 WBS,而不是从团队的活动(Action)出发。

二、采用NABCD法，对项目可行性进行团队合议

企业微信会议进行团队合议

图1-1 团队进行团队合议截图

图1-2 团队进行团队合议截图

NABCD模型

项目	内容
N（Need，需求）	1. 功能性需求，对各方面背包问题的求解。背包问题的具体应用。利用背包问题实现具体问题求解。 2. 开发过程需求，开发过程中必须有问题文档，以免同样的错误多次发生。以及开发周期设计文档，对未在计划周期内完成的任务做出说明。对代码做安全性核查，要有代码规范和支持文档。 3. 非功能性需求，整个页面简单干净，须在第一时间回应用户反馈。 4. 综合需求，不断获取最新文献更新，相关行业实际问题解决时用到的背包问题。
A（Approach，做法)	1. 不断更新最新文献动态，呈现有关背包问题的最新研究结论，丰富背包问题的实际维度，让用户了解更加深层次的背包问题。 2. 撰写简单易懂的博客，利用计算机相关知识，与其他实际问题相结合，学科交叉，撰写简单易懂的博客实现背包问题拓展，更大范围的与用户探讨。
B（Benefit，好处)	1. 专一的解决用户单一的需求——类似背包问题的实际问题求解。 2. 方便获取背包问题相关最新研究结果。 3. 对相关实际问题有所了解，拓宽思维，联想实际问题解决方法。 4. 通过简单易懂的博客入门深层次的背包问题。
C ( Competitors，竞争)	先进入市场的产品，如CSDN、博客园、中国知网、超星等网站都可以获取背包问题相关求解知识，并用户基数大且用户覆盖面广，思维活泼，交流频繁。而本论坛是对各网站研究成果的汇总，减少用户在信息搜集方面的成本，专注于背包问题，进行深层次的探讨。
D( Delivery，推广)	CSDN、博客园中撰写推广博客引导对背包问题感兴趣的用户进入本社区进行探索。向周围相关专业的用户推荐传播，利用朋友圈进行传播。

任务二：实施项目软件用户调研，依据结果填写《学生“创新能力提升计划”项目申请表》

1. 线上访谈调研用户需求

• 介绍所访问用户的背景
  背景：理工科学生，编程小白，初步了解背包问题，对解决背包问题算法不熟悉
• 访问用户的聊天记录照片
  
  图2-1 聊天记录截图
• 介绍所访问用户的背景
  背景：计算机专业学生，了解背包问题，对解决背包问题的基本算法了解且熟悉
• 访问用户的聊天记录照片
  
  
  
  
  图2-2 聊天记录截图
  
• 结论
  从线上访谈中可以看出，背包问题知识社区是一个偏向于专业化的社区。越是专业化那对内容方面的要求更高。并且在访谈过程中了解到用户希望有一个更干净更专业化的知识平台。也可以看出，社区类网站最吸引用户的是其中的内容，所以未来这个社区应着重再内容的创作以及更多优秀创作者的吸引。

2. 以问卷方式调研用户需求

3. 用户需求调研活动的佐证材料

• 线上访谈调研
  （线上访问用户聊天记录截图如下所示）
  
  图2-3 聊天记录截图
• 问卷调查
  • 问卷链接： 背包问题知识社区系统问卷调查
  • 问卷详情
    
    图2-4 问卷详细信息
  • 问卷收集详情
    
    图2-5 问卷收集详情

4. 填写并上传《学生“创新能力提升计划”项目申请表》

• 《学生“创新能力提升计划”项目申请表》预览
  （点击可放大查看图片奥）
  
  
  
  
  图2-6 《学生“创新能力提升计划”项目申请表》预览
  
  
  
  
  
  
  图2-7 《学生“创新能力提升计划”项目申请表》预览
  
• 上传至团队仓库

图2-8 上传至团队仓库

任务三：团队协作学习《现代软件工程—构建之法》第10章，以团队协作学习方式学习掌握墨刀原型设计工具软件操作方法

一、《构建之法》第十章 典型用户和场景

10.1 典型用户和典型场景

光看用户的表面语言或行动还是不够的。我们还要找到用户语言或行动背后的动机!不能光根据用户的语言就匆忙做决定。

典型用户价值

在设计软件的过程中，我们（设计/开发者)往往会以自己使用产品的习惯和对软件行业的熟悉程度出发设计，忘记了我们的软件是给千千万万个不那么会用电脑的人使用的。在这种情况下，搞一个“典型用户”会强迫我们在考虑问题时从用户的角度出发。

10.1.3 怎样定义典型用户

典型用户的模板可以包括以下内容:

1.名字(越自然越好)
2.年龄和收入（不同年龄和收入的用户有不同的需求)
3.代表的用户在市场上的比例和重要性(比例大不等同于重要性高，如付费的用户比例
较少,但是影响大，所以更重要)
4.使用这个软件的典型场景
5．使用本软件/服务的环境（在办公室/家里/沙发Ⅰ床上/公共汽车/地铁……)6.生活/工作情况
7．知识层次和能力（教育程度,对电脑、互联网的熟悉程度)8.用户的动机、目的和困难（困难=需要解决的问题)
9.用户的偏好

定义了最初的典型用户之后，是不是就可以开始写程序了?不，典型用户只是我们的设想，这些都是纸上谈兵，我们还要和这些典型用户的代表交流，理解用户，理解他们的工作方式和需要。然后再修改，细化典型用户。当我们完善了典型用户的定义后，就要讲一些他们的故事，进入到“创立场景”阶段——创立场景就是我们深入理解用户需求的过程。

10.1.4 从典型用户到场景

有了典型用户之后，我们还得决定每一个典型用户的目标——他/她使用系统想要达到什么目的(如:购物、卖产品、滥发广告……)。对于每一个目标，列出达到目标所必须经历的过程，这就是场景，也可以叫故事( Story)。注意，有些场景描述了成功的结果，有些场景描述了失败的结果。用户和系统有成百上千种可能的交互情况，写场景时要有针对性。

10.1.5 从场景到任务

有了场景，下面就由架构设计师和各个模块的负责人一起，沿着子系统/模块的所属关系把场景划分开。不同的任务将会把一个场景编织起来，虽然有多个开发者参与这项工作，但是应该有一个开发者对整个场景负责。得到开发任务后，我们就可以创建和分配测试任务。

10.2 用例

和典型人物、典型场景的方法类似，用例(Use Case )也是很常用的需求分析工具。用例有这样一些基本元素:

标题:描述这个用例要达到的目标
角色（Actor) :和软件系统交互的角色，例如用户，其他实体，甚至时间（在描述一
些和时间相关的场景时有用)
主要成功场景(Main Success Scenario) :一系列步骤描述角色是怎样和系统交互，
从而达到目标的。
步骤（Step):描述每一步的交互（例如一套正常的ATM取款流程)
扩展场景（Extension) :描述一些扩展的交互，例如一些意外情况（例如取款时账户
余额不足，或者ATM机器的现金不足)。

用例的原则

1.通过讲简单的故事来传递信息
2.保持对全系统的理解
3.关注用户的价值
4.逐步构建整个系统,一次完成一个用例
5.增量开发,逐步构建整个系统
6.适应团队不断变化的需求

10.3 功能说明书

10.3.1功能说明书

功能说明书从用户的角度描述软件产品的功能、输人、输出、界面、功能的边界问题、功能的效率（对用户而言)、国际化、本地化、异常情况等，不涉及软件内部的实现细节。

第一，定义好相关的概念。
第二，规范好一些假设( Assumptions ) 。
第三，避免一些误解,界定一些边界条件。
第四，描述主流的用户/软件交互步骤。
第五，一些好的功能还会有副作用。
第六，服务质量的说明。

Spec的另一个敌人是时间。几乎在Spec写好的那一瞬间，Spec就开始过时了。容颜易老，Spec尤甚，怎么办?

1.记录版本修订的时间和负责人——这样出了问题好去找人。
2．在Spec中要说明如何验证关于功能的描述，从Spec的描述中就能知道单元测试该怎么写，最好把测试用例也链接上。

3. 把 Spec和测试用例、项目任务等放在一起（例如放到TFS上)，相互链接。
   4．变化是一定会发生的，与其在Spec中有意忽略这一点，不如主动挑明哪些部分是容易发生变化的，提前做好预案。说明哪些部分如果发生改变，会有何种连锁反应。
   5．在做任何改动的时候，一定要事先参考Spec，事后更新Spec，团队领导人不应该在没有Spec的情况下做拍脑袋的决定。

10.3.2 功能说明书的模板

盲目地套用最全面的模板,对项目有大的副作用。
模板：

1. Spec 的目标是什么，Spec的目标不包括什么?
2. Spec的用户和典型场景是什么?
3. Spec用到了哪些术语，它们的定义是什么?
   4．用户是如何使用软件的功能的?
   5．各种边界条件是什么，软件功能应该怎样随之变化——这些边界条件多了去了:用户数量的变化,输人内容的上限下限，不同国家/地区/文化/语言/硬件/软件版本/环境参数……
   6.功能有什么副作用,对于其他功能有什么显性或隐性的依赖关系?7．什么叫“好”，什么叫“这个功能测试完了，可以交付了”?
   8．软件发布出去之后，有哪些和项目目标相关的数据可以收集，怎么在实现阶段就能把数据收集的工作准备好?

10.3.3 技术说明书

技术说明书又叫设计文档，它用于描述开发者如何去实现某一功能，或相互联系的一组功能。软件的功能多种多样，放之四海而皆准的模板是不太实用的，但是软件的设计总是要遵循一些规律，不遵循这些规律，工程师们往往在实现后面软件的演化中吃苦头。设计文档应该说明工程师的设计是如何体现下列原则的：

• 抽象（ Abstraction)
• 内聚/耦合/模块化(Cohesion, Coupling, Modularization)
• 信息隐藏和封装（ Information Hiding,Encapsulation)
• 界面和实现的分离（Separation of Interface and Implementation )
• 如何处理错误情况（Error Handling)
• 程序模块对于运行环境、相关模块、输入输出参数有什么假设?这些假设和相关的人员验证过么?
• 应对变化的灵活性（ Adapt to Change)软件如何应对变化，是软件设计最重要的一个方面。
• 对大量数据的处理能力（ Scalability )如果数据量增大，程序还能保持高效率么?

10.4 功能驱动的设计

功能驱动的设计(Feature Driven Design，FDD）由下面几个步骤构成:

• 第一步:构造总体模型(Develop an Overall Model )

进入条件:团队已经选好了问题领域专家、主程序员、架构师。
任务1:决定建模小组成员,一般团队成员可以轮流参与。
任务2:问题领域专家概要介绍问题领域知识。大家学习已有的参考资料(已有的
建模文件、数据模型、功能需求、用户文档等)。
任务3:以不超过3人的小团队构建子问题领域的模型，并在适当的时候补充总体
模型。
任务4:记录模型的信息并保存为文档。
验证:―和团队内部或外部的利益相关者验证模型以及它们对用户和业务活动的影响。
出口条件:总体模型已经建好;各个实体（类）的关系也已经表达清楚，各个实体的属性和函数有初步定义;数据流、事件流程等说明文档已经完备。

二、以团队成员姓名命名的墨刀安装界面截图

（点击图片可放大查看奥）

图3-1 张圆圆的墨刀安装界面截图

图3-2 姜婷的墨刀安装界面截图

图3-3 孙得弘的墨刀安装界面截图

三、墨刀原型设计工具简介

• 简介
     墨刀是一款在线原型设计与协同工具，借助墨刀，产品经理、设计师、开发、销售、运营及创业者等用户群体，能够搭建为产品原型，演示项目效果。墨刀同时也是协作平台，项目成员可以协作编辑、审阅，不管是产品想法展示，还是向客户收集产品反馈，向投资人进行Demo展示，或是在团队内部协作沟通、项目管理，都可以很好的演示项目的预期效果。
• 适用平台
     浏览器注册使用， Windows、Mac 桌面客户端，同时支持 iOS、Android 端预览。
• 用户群体
     用户群体包括：产品经理、设计、研发、运营销售、创业者等。
• 功能介绍
  操作简单，简单拖拽和设置，即可将想法、创意变成产品原型，具体介绍如下所示：

功能	具体介绍
演示	真机设备边框、沉浸感全屏、离线模式等多种演示模式，项目演示效果逼真。
团队协作	与同事共同编辑原型，效率提升；一键分享发送给别人，分享便捷；还可在原型上打点、评论，收集反馈意见，高效协作。
页面跳转	简单拖拽就可实现页面跳转，还可通过交互面板实现复杂交互，多种手势和转场效果，可以实现一个媲美真实产品体验的原型。
自动标注及切图	将 Sketch 设计稿墨刀插件上传至墨刀，将项目链接分享给开发人员，无需登录可直接获取到每个元素宽高、间距、字体颜色等信息，支持一键下载多倍率切图。
素材库	内置丰富的行业素材库，也可创建自己的素材库、共享团队组件库，高频素材直接复用。

四、团队协作学习墨刀的会议截图

（点击图片可放大查看奥）

图3-4 学习墨刀的团队会议截图

图3-5 学习墨刀的团队会议截图

图3-6 学习墨刀的团队会议截图

任务四：利用墨刀设计实验项目软件原型

1. 团队项目软件原型系统V1.0

• 进入界面
     用户点击进入Knapsack，首先会进入该界面，点击任意点击屏幕任何一处，即可进入Knapsack内部。

图4-1 进入界面

• 注册界面

  • 个人账号注册
       若用户从未使用过Knapsack，可利用自己的手机号和邮箱号进行账号注册，成为Knapsack的用户，用户也可自主选择第三方软件进行信息注册。
  
  图4-2 个人账号注册
  • 基本信息填写
       当成为Knapsack的用户时，需要完善个人信息，根据如下图所示提示信息，选择个人信息的填写，完成点击下一步即可。
  
  图4-3 基本信息填写
  • 博主推荐关注
       在用户进入Knapsack使用时，可自主选择感兴趣的博主，从而系统会根据用户所感兴趣内容进行文章的推送。
  
  图4-4 博主推荐关注

• 登录界面

  • 用户登录
       用户可根据原先已有的注册账号与密码进行登录，当输入正确的账号和密码后，点击登录即可进入Knapsack主页。
  
  图4-5 用户登录

  • 验证码登录
       若用户想采用验证码登录，在如下所示界面，输入账号，点击获取验证码，账号与验证码相匹配后，即可完成登录。

    
    图4-6 验证码登录

  • 忘记密码
       若用户忘记了密码，在如下所示界面，输入账号，重新设置密码，点击获取验证码，所输入账号与验证码均正确后，即可完成密码的修改。

    
    图4-7 忘记密码

  • QQ登录
       用户在登录时，除了以上所述登录方式，还可以采用第三方软件QQ账号进行登录，如下图所示：

    
    图4-8 QQ登录

  • 微信登录
       用户也可以采用第三方软件微信账号进行登录，如下图所示：

图4-9 微信登录

• 主页

  • 推荐界面
       用户进入Knapsack，在主页推荐中，系统根据用户所感兴趣的文章内容进行推送，在查看文章时，用户可自主选择文章是小图模式展示还是大图模式展示，如下图所示：

    
    图4-10 推荐界面小图模式
    
    图4-11 推荐界面大图模式

  • 关注界面
       在关注界面，系统对用户推送其所关注博主的相关文章，用户可进行点赞，评论，查看和收藏，在页面下滑即可查看更多的文章内容，如下图所示：

    
    图4-12 关注界面

  • 热榜信息界面
       在热榜信息界面，系统根据用户的浏览量，评论量，点赞数等进行分析，生成了不同的话题榜单，用户可根据不同话题进行查看。

    
    图4-13 热榜信息界面

  • 发布想法界面
       用户若想要发表自己的意见和看法，用户可在发布想法界面，输入自己所要表达的文字，也可选择图片，或者位置等信息，编辑完成后，点击发送按钮即可发布文章。

    
    图4-14 发布想法界面

• 论坛界面
     在论坛界面，用户可根据自己需求查看多个文章，具体如下所示：

  
  图4-15 论坛界面

  • 论坛视频查看
       在论坛内，用户可根据自己的兴趣选择查看相应的视频，还可以对其进行评价，点赞，分享，具体如下所示：

    
    图4-16 论坛视频查看

  • 收藏夹

    
    图4-17 收藏夹

  • 上传文件

图4-18 上传文件

• 消息

  • 消息列表
       用户点击按钮进入消息界面，可查看与该用户有关的点赞，评论等信息，用户所收到的系统信息和其他用户的聊天信息也可在此页面进行查看，具体如下所示：

    
    图4-19 消息列表

  • 聊天界面
       在消息列表里，选择某一具体消息，即可跳转至聊天界面，用户可与其他用户进行交流。

图4-20 聊天界面

• 个人中心

  • 个人中心主界面
       在个人中心主界面包括多个功能，如查看个人信息，学习记录，查看自己所发布文章，查看自己的错题集，整理自己的学习资料等，具体如下图所示：

    
    图4-21 个人中心主界面

  • 个人信息界面
       用户可查看自己的个人具体资料，具体如下所示：

图4-22 个人信息界面

• 文章正文界面
     在Knapsack中，每位用户所发布的文章在页面中具体显示时，如下图所示，其中包括文章主体内容，用户浏览及评论记录等。

图4-23 文章正文界面

• 天天练
     在Knapsack中，用户可以通过练习相关习题检测个人学习效果，输入代码编译运行后测试结构是否为正确答案。

图4-24 天天练

2. 将系统上传到团队项目仓库

（点击图片可放大查看奥）

图4-24 将团队项目软件原型系统上传至仓库

任务五：完成《实验六 团队作业3：团队项目需求调研与原型开发》博文作业

• 已发布完成博客作业
  （点击图片可放大查看奥）

图5-1 发布完成博客作业

记录完成《实验六 团队作业3：团队项目需求调研与原型开发》各项任务实际花费的时间

任务内容	计划共完成的时间(min)	实际完成时间(min)
团队讨论协作阅读学习《现代软件工程—构建之法》第8章内容	60	70
采用NABCD法，从五个视角对实验软件项目可行性进行团队合议	50	60
通过线上访谈调研真实用户	120	110
通过问卷形式进行用户需求调研	140	160
收集整理用户需求调研素材	150	170
依据调研结果填写《学生“创新能力提升计划”项目申请表》	240	260
团队安装并学习墨刀原型设计工具	90	100
利用墨刀设计实验项目软件原型	530	550
团队博客编写	310	350
本次作业反思及总结	35	40

本次作业的感受和体会

团队成员	本次作业的感受和体会
张圆圆	在此次团队作业中，以团队协作学习方式，学习了《现代软件工程—构建之法》第8，10章内容，理解并掌握了NABCD模型、学习并理解了典型用户和场景；本团队通过实施问卷调查，线上访问等方式调研用户需求，对团队项目需求调研过程有了深入的学习及了解，在这过程中，也知道了在进行软件项目开发之前，对用户需求进行调研对于后期软件开发有很大的好处；团队之间通过共同学习墨刀原型工具，设计完成了背包知识社区系统原型设计，在设计过程中，对墨刀工具有了更深入的学习和了解，以团队协作学习方式掌握了该软件操作方法，并且知道了软件原型设计的重要性，相信在以后的学习中，我们团队会更加注重用户需求，在以后的编程项目过程中，会更加深入地从用户的角度出发，通过原型设计考虑项目所要实现的功能效果，可使得软件项目更加完善。
姜婷	在本次实验中学习使用了磨刀，了解到了项目开始之前的原型设计过程，通过先模仿优秀的原型设计自己的模型，从而达到项目的初步设计。也学习了利用多种手段获得用户需求的方法，不择手段挖掘用户需求。团队成员之间分工合作，从而达到项目过程的完美结束。
孙得弘	在本次的合作项目中我学习到了很多新的知识，并且体验了到了团队合作开发项目的乐趣。同时学习了如何使用墨刀进行团队的软件项目开发，我负责的是社交论坛部分的开发，在这过程中遇到了许多的困难和问题，非常感谢我的队友的帮助，在她们的帮助下我成功完成了这部分的项目开发，让我受益匪浅