团队作业三需求分析与计划

Posted 都行可以随它去

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了团队作业三需求分析与计划相关的知识，希望对你有一定的参考价值。

需求分析

软件的最终目的是用来解决用户的某些问题，需求分析就是要理解要解决的问题，真正明确用户需求。

1.访问软件项目的真实用户（至少10个），确保软件真正体现用户的需求，为软件最终可用奠定基础。

我们在问卷网上做了一份问卷调查，总共10道选择题，外加一道用户建议题

用户问卷调查统计对比：

截止目前为止，一共有89人完成了问卷，其中男女比例2:3，学生占了78人，我们从以下几个主要的方面来调查，结果如下

记账习惯

选择习惯

是否有消费计划

比较学生和从事其他行业的用户的需求

学生用户的需求

其他行业的用户的需求

现用的记账APP或小程序不足之处

用户担心的问题

对于记账APP或小程序的意见：

用户期望和建议

2. 参考《软件需求规格说明书》国标规范文本，撰写对应项目的软件需求规格说明书。提供《需求规格说明书》的Git链接。

  • 除形式上满足规范文本要求外，整体内容必须围绕项目实质展开，对所要开发的项目确保尽力做到清晰完整准确。
  • 使用一致的图形符号和文字描述内容。
  • 所有的缩写须事先定义。
  • 需要有一个目录，word排版样式规范美观，图文并茂，通篇文档有一个统一的样式风格。
  • 将自己置于读者的立场——如果对软件项目不熟悉的人员，通过阅读这份文档，能否完全读懂软件要做什么。

git链接入口

3.NABCD 写作，视频

  • 请同学们把自己项目的NABCD 都写出来。
  • 列成详细的条目，用具体的事实和分析说明。
  • 请分析自己项目的杀手功能是什么？参考教材的第8章：功能分析的四个象限
    把这些要点都组合成为一段话 -- 当你要向别人兜售你的项目的时候， 你通常只有很短的时间 （电梯演说），能否自然而有条理地把项目说清楚？ 请用你产品中实际的元素代替 <> 中的抽象概念。
    各位领导/投资人/用户/合作伙伴：我们的产品 是为了解决 <目标用户> 的痛苦, 他们需要 ，但是现有的方案并没有很好地解决这些需求，我们有独特的办法 ，它能给用户带来好处 ，远远超过目前市场上的竞争对手 。 同时，我们有高效率的 方法，能很快地让大部分用户知道我们的产品，并进一步传播。
    [附加题]把上面的这段话录制为视频，上传到视频网站，并把链接发到团队博客上。
  • N（Need)
    - 我们团队的项目是基于微信开发的记账小程序，满足了用户不依赖app，就可以在手机上轻松记录日常开销收支的需求，即开即用，用完就走，无需占用内存，影响桌面美观。
    - 从需求量来看，在我们的调查问卷结果上可以明确看出，相对于传统的记账方式，超过一半的人选择使用较为简便的记账小程序。
    - 从用户对曾经使用的记账方式的痛苦,最主要的原因是数据表达不直观问题，其次是程序繁琐，界面美观和分类细节也占有一部分。
    - 从用户对小程序要求统计数据来看，数据分析及统计和数据更改都是最基本的，同步账本和提醒功能虽比重不大，但也是我们项目的一个发展趋势。
    - 综上总结了记账小程序最本质的开发需求是：以简为本，在基本记账功能之上进行分类细则的数据分析与界面美化。
  • A（Approach）
    向微信方申请搭建一个个人性质的微信小程序。用户通过微信搜索我们的小程序后直接使用微信注册绑定使用。
    完成基本的基础记账的功能后，就可以推出去给客户试用一下，看看用户有什么反馈的要求，或者改进的地方，好的方面及时商讨改进，方便后续更多功能的推进，若固步自封地做，全部完成后反而不满足客户需求，很难倒回头改进。
    小程序初版后端使用java+SQL数据库，前端使用html + javascript+css。小程序风格以简洁为主。前期主要将基础功能做好做强大，后期再不断迭代更新。
  • B(Benefit)
    成本低：我们的微记账小程序是一种无需下载安装即可使用的应用，能以最低成本触达用户，减少用户成本，释放手机内存量。
    灵活性高：替代传统麻烦的手工记账，实现记账简单化、方便化、数据化。
  • C(competitors)
    1)其他小组带来的竞争
    2)其他微信记账小程序开发者带来的竞争
    优势：我们团队人员积极合作，而且大家住在一起可以第一时间了解项目进度，并及时修改或更新。
    劣势：都是大学生，项目经验不足，能力稍有欠缺。
    优势：通过简单调查，目前同类型的微信小程序功能大都不齐全不完善，不存在已经很强大健全的记账小程序，开发空间还是很大的。
    劣势：记账app可以不用网络就可记账，而我们的记账小程序必须连接网络登录微信才能使用。
  • D(delivery)
    微信小程序本就自带推广，大大减轻了我们的推广工作量；并且小程序特点之一就是只要使用过即是用户，只要在微信内搜索过记账小程序并进入我们的微记账，就会产生用户，随着时间，我们会产生固定用户，继而有了大的流量产生，我们的微记账也会在用户搜素记账小程序是排名越来越靠前，交付推广就更容易简单了。

杀手功能

相较于其他同类的记账小程序：
我们增加了数据导出备份的功能，这样即使用户清除了历史账目记录，也可以通过备份再次查到，减少用户丢失数据的损失；
还增加了账单添加的功能，例如：默认账单可以记录用户个人所有支出消费结余等，生意账单可以记录用户公有的财务支出收入等，还有旅游账单…….

一段话

各位用户朋友们：我们的产品<微记账小程序> 是为了解决手工记账和APP记账用户的痛苦, 他们在现有的记账工具中不能明确的了解自身的收支状况且清除记录后无法找到数据，易造成损失；但是现有的方案并没有很好地解决这些需求，我们有独特的办法，首先我们增加了数据备份这项功能，并且也增加了收支状况的分类统计图表、对比统计图表、趋势统计图表，它能让用户清晰快速的了解自己的收支状况并且加以对比和估算，也大大的减少了数据丢失所造成的的重大损失，远远超过目前市场上的竞争对手（同类型记账小程序）。 同时，我们有高效率的推广方法（利用微信自身海量用户的优势），能很快地让大部分用户知道我们的产品，并进一步传播。

视频链接入口

4.团队协作，加强分工，需要描述每个成员的具体分工及占整个文档任务的工作量比例。

参考

原型设计

原型设计能够在表现层将设计合成一个逻辑整体，用户能和你一起看到未来交互的软件蓝图、功能和效果，获得较真实的感受，在不断讨论的基础上完善未来的设计思想。因此，原型设计能起到有效沟通的作用，漂亮，直观的原型图更是让人赏心悦目。

1.不要等到所有代码写好之后再去验证需求，请用设计工具描述用户界面和需求。
2.原型设计不仅要考虑主要功能的页面排布，同时也要考虑用户实际操作中的问题，提前为用户考虑得当并征求用户意见
3.系统是必须可运行的，可实际使用的——请抱着这样的同理心去考虑系统。
4.给目标用户展现原型，与目标用户进一步沟通理解需求。

场景：用户使用产品的过程中
痛点：刚开始想要要点击图标按钮，但实际上点击按钮下面的小字才能实现功能的切换。
这会使刚接触使用的人不能较好适应。以至于一直点击图标却没有反应。调研拍摄图片如下：

用户体验界面

初始界面（记账、显示当月收支及预算）

报表界面（根据预算值显示总收入支出及结余）

账单界面（设置月预算及关键字搜索记录）

账本界面（新建账本及查看当前账本总额记录）

登录界面（通过邮箱记账提醒及导出数据到邮箱）

调研拍摄

原型工具参考

如果是设计原型，采用专门的原型设计工具，能够事半功倍，工具参考：

  • 移动应用原型与线框工具-墨刀
  • 原型设计界的PS -Axure RP，Axure
  • 网页和移动端的设计sketch
  • 一款简洁高效的原型图设计工具mockplus
  • 致力于高保真原型制作工具Justinmind
  • 一款免费的带有手绘涂鸦风格的原型设计软件balsamiq mockups
  • 更多选择，请参考：https://www.zhihu.com/question/19592829

作业参考
原型设计界面简洁，用户体验极佳。分工比例部分的泳道图十分清楚地展示了各个同学的工作任务，Github上数十次Commit也展示了他们和谐的团队协作。

原型设计链接

任务分解WBS

一个团队项目要在一段时间内完成诸多任务，满足用户需求，实现团队目标，从哪里入手？
WBS（Work Breakdown Structure）即工作分解结构，是根据项目目标把工作分解成许多层次分明的、可交付成果的工作任务，然后用逻辑图形或树形结构表示出来。

1.请给出团队项目的WBS

2.团队成员估计各自任务所需时间

成员 负责模块 估计时间
顾芷菱 丁蓉 报表模块 210h
林羽晴 洪亚文 账单模块 210h
秦贞一 齐畅 用户模块 200h

3.参考：http://www.cnblogs.com/zhengrui0452/p/6653964.html

编码规范

根据结对编程的经验，大家已经意识到编码规范的重要性。

讨论制定团队的编码规范，满足代码风格规范和代码设计规范（参考书第4章4.1-4.3内容）
http://www.cnblogs.com/xinz/archive/2011/11/20/2255971.html

  • 代码风格规范
    • 基本间距：
      • 缩进：4个空格
      • 行宽：100字符
    • 条件执行块：
      • 条件表达式：在复杂的条件表达式中增加括号增强逻辑性，如if ( (A||B) & ( (A&B) || (A||B) ) )
      • 格式：断行与空白的{ }行，
        如:
        if ( condition)
        {
        DoSomething();
        }
        else
        {
        DoSomethingElse();
        }
    • 分行：
      • 变量定义:将不同的变量分别分行定义
        如：
        Foo foo1, foo2; （错）
        Foo foo1；
        Foo foo2； （对）
      • 多行语句：分行放
        如：
        a = 1; b = 2; （错）
        a = 1;
        b = 2; （对）
        if (fFoo) Bar(); （错）
        if (fFoo)
        Bar(); （对）
    • 变量名称：
      • 命名：匈牙利命名法，可以直观看出变量的类型或存在的意义
      • 下划线：分隔变量名字中的作用域标注和变量的语义，如：people结构体中的student为p_student
      • 大小写问题：所有变量及函数的名称均使用camel式，每个单词首字母大写，如：StuInfo，GetInfo()
    • 注释
      • 内容：注释的内容仅为程序的用途和原因
      • 符号：源程序和注释都使用ASCII字符
      • 函数头注释解释函数的参数类型，若程序说明则省去
  • 代码设计规范
    • 函数：只实现一个功能
    • goto：使用goto语句实现无条件转移，增强程序的逻辑性
    • 参数的处理：对传递过来的参数进行验证
      • 断言：参数百分百正确，直接Assert
      • 错误处理：设置条件语句的判定，对不同的判定做不同的处理
    • 类的使用：
      • 在必要的时候才使用，数据的封装用结构体就行，减小开销
      • 成员变量：用下划线指明所属域
      • 修饰词：按照public、protected、private的次序来说明类中的成员
      • 构造函数：只用来简单初始化数据成员，不能有返回错误的操作
      • 运算符：简单运算情况下直接使用不要重新定义，复杂操作才定义成函数进行运算
      • 异常
        • 不要用异常作为逻辑控制来处理程序的主要流程
        • 使用时需要明确数据被清理的地方

系统设计

在设计阶段，我们要清楚：软件是怎么解决这些需求的？
一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。

1.如何才能最大限度地实现这些需求，这就是架构设计要解决的问题。请给出系统的架构设计

（1）微信小程序主要由3个全局的文件和一些与页面相关的文件组成

文件 作用及说明
app.js 逻辑部分，用于编写全局的事件
app.json 用于配置微信小程序
app.wxss 公共样式表，用于设置可以使用的样式

（2）系统结构简单描述

  • 前端设计：
    前端是直接提供给用户的，属于视图层面的，是最直观的，需要保证界面的美观，可以给人用的，而且还要保证易上手，满足大多数人的使用习惯。

  • 后台开发：
    后台是为了在各个不通的界面中，实现不同的功能。如果只有良好的界面，没有后台的支持，那这个产品也只是一个空壳。假设用户通过点击某一个功能按钮，为达到其效果，就需要从后台调取数据，根据不同的需求呈现给用户，而这些是属于逻辑层面的

  • 搭建服务器，提供数据服务：
    我们做的是基于微信平台的记账小程序，需要保存用户大量的数据，而且还要保持数据的同步，我们将采用mysql，优点是易操作，我们还需要搭建web服务器，为用户提供http service

（3）系统结构图:

2.完成团队项目的数据库设计，并在随笔中提供相应ER图（如果必要）

E-R图说明：

  • 一个用户的微信名是唯一的，我们可以通过存储微信名的方式直接找到昵称和微信头像，用户绑定邮箱可有可无，用于导出账单数据和提醒用户记账
  • 一个用户可以拥有多个账单，账单的每个数据项包含账单编号（自增），账单类型编号，时间，备注，消费类型，金额（+为入，-为出）
  • 一个用户有多个月预算，账单类型和年月作为主键，保证唯一
  • 消费类型表，比如生活用品，服装，饮食，车费等等，用户还能自定义类型
  • 账单类型表，比如生意账单，生活消费账单等等，用户同样也能添加自定义类型

参考

团队个人总结

  • 林羽晴
    本周主要任务完成需求分析与计划，我们开了一个小会，安排了各个成员的任务
    完成情况：在第一版本的基础上，对需求分析说明书进行了修改和补充，调整格式，增加模式图等，根据问卷调查的结果进行展示，完成任务分解和系统结构设计，了解整个项目的构架。
    感想：这两周都是在为后面的开发做准备，需求分析做得好坏会影响软件的质量，我们的团队也特别重视，但是涉及的用户多数是学生，有一定的局限性。我们接下来要开始小程序界面的设计，云服务器的准备，前后台的交互，数据库等等。虽然会面临很多的挑战，但是我们准备好了！
  • 顾芷菱
    本周博客我和本组成员丁蓉负责的是用户需求分析模块，包括NABCD编写与视频、用户需求分析调查及《软件规格说明书》编写等。
    ①关于用户需求调查，我们采用调查问卷的方式，收集了90人左右的调查结果。通过结果了解了用户的需求及痛点，找到今后项目开发的侧重点，满足用户需求
    ②在编写软件规格说明书的时候遇到了一些麻烦，从网上搜索得来的模版看起来很正式很高档，一开始甚至有写专业名词都看不懂，写起来比较一头雾水。当然，从编写的过程中也得到了编写规范文档的经验与方法。
    ③NABCD编写是参照老师给的一些参考链接结合自己项目的实际情况写的，印象深刻的是宣传视频的制作，我们俩采用的是幽默诙谐的方式，希望能给我们的项目起到正面积极的宣传作用。
    今后大家也一起继续加油吧~
  • 丁蓉
    本周博客用户需求分析模块是由我和顾芷菱负责，包括用户调查，编写《软件需求规格说明书》以及编写NABCD和拍视频。 软件需求规格说明书那边真的是有点难写，看了很多模版，大多都是写了四五十页，我们经验不足不太清楚具体怎么写，所以用了很久的时间，也才初步完成，然后又修改了一遍，最后组长羽晴又再次修改了一遍，足以说明这个真的不好写，然后我们很认真哈哈。还有就是我和我的搭档顾芷菱的视频啦，很有意思？！希望大家可以用一种放松的心情来了解我们的产品。相信我们会越做越好的。
  • 洪亚文
    本周我主要负责的是熟悉微信小程序后端的编程开发为后面做好编程准备，本周博客部分由于内容较多，我负责的是整个编码规范的部分，经过讨论之后发现很多由于不同编码风格会影响了代码的可读性比较差，因此代码规范一系列还是特别有必要达到一致性的。
    其次是我觉得这个项目在初始阶段做这些准备工作，比如需求分析,代码规范等，都是在为后续工作打基础，但是我觉得如果在后续编程工作中还要继续完成量大的博客任务可能有点吃力，特别是冲刺阶段两天一篇博客，希望老师可以酌情分配任务，留更多的时间在开发之上
  • 秦贞一
    本周我主要负责原型设计这一块，所用的工具是墨刀，在确定了软件的功能便开始着手设计，一开始的时候没有什么头绪，不知道如何将功能如何很好的分块并实现在不同的界面中，后来便参考了其他的记账的软件，再结合我们的记账软件的具体需求，设计界面也是水到渠成。
    但是墨刀设计的局限性，很多功能够做了简便化的处理，如报表那一块，并没有图标的实例，只能在设计完成后和组员说明情况。经过这一周的设计，相信在接下来的时间里，我们会做的更好。
  • 齐畅
    这周我和我主要负责原型设计中的用户调查关于痛点的问题，并拍了视频图片。以及和队友们在朋友圈微信广撒网，积累了大量的问卷调查的数据，有较强的说服力。完成了基本的市场需求分析。开了两次会，就功能实现展开激烈的讨论，并最终形成了整个项目的构架。
    感想：下面两周就是冲刺周了。我们也准备买云服务器，为数据库实现做准备。基本上可以想象每天的日常除了上课，吃饭睡觉，剩下的时间可能都是跟五个队友一起吧。虽然有点残忍，易审美疲劳，但一想到如果坚持到两周后，看到基本成型的小程序，那再痛苦也是值得的！

以上是关于团队作业三需求分析与计划的主要内容，如果未能解决你的问题，请参考以下文章

团队作业3——需求分析与设计

软工网络15团队作业3——需求分析与设计

《JUST DO IT!》团队作业4-基于原型的团队项目需求调研与分析

《Spring_four》团队作业4—基于原型的团队项目需求调研与分析

团队项目-需求分析报告

团队项目-需求分析报告