项目需求分析

团队项目-需求分析报告 一、博客链接 组长博客链接 二、组队后的团队项目的整体计划安排 编写需求说明书。 确定各功能模块分工。 完成UI设计，完成基础功能算法，制定测试计划。 完成Alpha版本，编码+测试+项目管理同步推进。 收集用户的试用反馈 完成Beta版本，以反馈为基础进行改良。 编写用户手册。 正式版本发布，进行后续维护和支持。 三、团队分工 姓名 分工 陈明磊 任务分配，撰写需求分析说明书引言部分，PPT 陈思涵 博客 林镕炜 需求说明书非功能需求和验收验证标准部分 实体关系图 韩洪威 原型设计，需求分析说明书原型部分， 状态图 杨润秋 需求分析说明书项目总体描述部分， 状态图 李欣凯 logo设计，需求说明书非功能需求和验收验证标准部分，活动图 陈舒洋 答辩，实体关系图 陈锦杰 需求说明书非功能需求和验收验证标准部分，类图，思维导图，评审表，小组评分，实体关系图 陈振旺 需求说明书非功能需求和验收验证标准部分，用例图 钟伟颀 需求分析说明书项目总体描述部分， 用例图 陈锦鸿 需求分析说明书项目总体描述部分， 用例图 胡浩楠 需求说明书非功能需求和验收验证标准部分， 活动图 四、思维导图 五、评估团队中每个人对本次作业的贡献比例 姓名 贡献度 陈明磊 9% 陈思涵 7% 林镕炜 8% 韩洪威 9% 杨润秋 8% 李欣凯 8% 陈舒洋 8% 陈锦杰 11% 陈振旺 8%

一、组长作业博客链接 梅恒权 二 、团队项目的整体计划安排 设计一款简洁实用、功能齐全、为福大学子们量身定做的基于移动设备的线上任务交易平台APP——“福大帮帮”。在平台上，福大校园里的同学可以发布任务及酬劳，能提供帮助的同学可以领取任务给与帮助，这不仅帮助任务发布者以高效方便地寻求帮助并解决问题，也让任务领取者在帮助了他人的同时也获取相应酬劳，两全其美；同时在平台上，同学间也可进行二手物件交易，尤其是二手书交易。 三、团队分工 队员姓名 队内身份 主要任务 梅恒权 团队项目管理员 （队长） 规划项目进程、答辩 组织会议、分配任务 维护及网页宣传 参与文档拟写 王瑞卿 产品经理 产品设计 团队报告 PPT 参与文档拟写 杨欢 前端工程师 全栈 参与文档拟写 汪倍民 前端工程师 负责前端的开发 参与文档拟写 关文涛 后端工程师 负责后端的开发 参与文档拟写 黄奕颂 后端工程师 负责后端的开发 参与文档拟写 陈梦雪 美工 负责 app 的 ui 设计 参与文档拟写 朱庆章 美工 负责 app 的 ui 设计 参与文档拟写 黄宇航 数据测试 团队报告 博客撰写 后期数据测试 参与文档拟写 胡康 数据测试 团队报告 博客撰写 后期数据测试 参与文档拟写 四、思维导图 五 、评估团队中每个人对本次作业的贡献比例 组员 分工 贡献比 梅恒权（组长） 需求分析报告、评审 6% 王瑞卿

一、组长博客链接 组长博客 二、舍得APP的logo 三、团队项目的整体计划安排 阶段 主要计划 计划时间 内容 1 项目选题 2019.09.27-2019.10.19 确定选题，书写商业计划书，并进行NABCD分析，完成项目的市场调研和竞争对手分析 2 需求分析 2019.10.19-2019.10.28 对项目进行市场需求分析及调研，对产品功能有详细的分析计划，制作思维导图和UML，确定接下来alpha版本的团队分工 3 编码规范 2019.10.28-2019.11.04 完成接口规定、编码规范、编码搭建 4 Alpha冲刺 2019.11.04-2019.11.20 完成项目的核心功能开发、前后端的对接 5 改进总结调整 2019.11.20.2019.11.25 对项目进行完善、测试用户的试用反馈、测试计划的改进 6 Beta冲刺 2019.11.25.2019.12.08 根据用户反馈进一步改进，对项目管理的进一步推进 7 项目后期 2019.12.08-2020.01.01 对APP进行维护，不断迭代更新软件的内容并且修复潜在bug，完成产品的附加功能 四、团队分工 组员 主要任务 童景霖（组长） 评分、思维导图、需求分配（需求分析报告第三部分） 黄永福 PPT演讲答辩 叶泽林 制作类图 郑志强 制作界面原型 刘御帆 评分 许宏健 评分 侯熠珉 写功能验收标准

这个作业属于哪个课程 2019秋福大软件工程实践Z班 这个作业要求在哪里 团队作业第二次—需求规格说明书 团队名称 T-MAX 这个作业的目标 撰写项目需求规格说明书，介绍团队分工 作业正文 T-MAX——项目需求分析 logo： logo说明：首先里面的两个显眼的F是福大app一脉相承的特色，这两个F-word分别是fine（美好的）和food（食物），表明我们产品的主要宗旨是让用户得到更好的饮食体验。颜色采用了温暖的的淡黄色，温和近人。 两个F的布局呈现投影的形式，所有食物（Food）在我们app的投影下，一定是令人满意的（Fine）。 工作流程 ： 本次文档任务的负责人和组员分工 ： 小组组成人员共10人，分组如下： 任务 成员 原型设计 徐美佳，陆志阳，贾懿，涂峥嵘 撰写需求规格说明书 蔡智伟，陈功贤，林生枝 撰写PPT 陈友昆，李爱军 负责评分样式表 陈功贤 撰写博客 洛桑平措 本次文档任务的负责人 陈功贤 本次文档任务的组员工作量比例 ： 成员 贡献度（百分比） 陈功贤 13% 陈友昆 13% 李爱军 6% 徐美佳 8% 涂峥嵘 6% 贾懿 12% 陆志阳 12% 洛桑平措 8% 蔡智伟 10% 林生枝 12% 说明：本次作业，贡献度的分配，首先十人均分，后按照成员所分配任务的重要性和个人完成度，还有平时讨论或者集体进行作业时积极度，进行加减，最终进行统计。

这个作业属于哪个课程 课程 这个作业要求在哪里 作业要求 团队名称 软工C#造梦厂 这个作业的目标 实现需求分析，完善分工任务，设计项目原型 1、项目人员 姓名 学号 张旭（组长） 201731024123 周成杰 201731024136 邹扬锋 201731024134 赵俊安 201731024121 黄涛 201731024119 陈欣 201731024102 马芸慧 201731024104 马昊妍 201731024107 2、项目简介   黄金点小游戏：黄金点游戏规则：N（大于等于10）个玩家进行游戏，每名玩家从0到100（不能选0和100）之间选择一个有理数，将所有玩家的数值求平均值G，将G乘以0.618，即黄金分割比例，得出S值（黄金点），离S值最近的玩家得N分，最远的玩家得-2分，其余玩家不得分；每名玩家的初始分值定位一百分。重复N轮游戏，得分最高的玩家获胜。 #### 3、典型用户   作为一个益智类小游戏，需求人群是十分广大的，可以说老少咸宜，不过我们认为主要需求人群还是以学生、上班族等压力较大的人群为主 4、主要功能   此次项目是我们从作业推荐项目中选择的一个小游戏项目，我们想把它开发成为一种益智类小游戏，益智类游戏具有即时性、趣味性、智力性等特点，通过这个游戏达到锻炼思维、释放压力等目的。 5、原型模型 利用墨刀开发工具设计系统原型 6

0. 题型 0.1 内容要求 摘要字数在 400 字以内，可以分条叙述，但不允许有图、表和流程图。 正文字数为 2000 字至 3000 字，文中可以分条叙述，但不要全部用分条叙述的方式。 0.2 题目 第一题 介绍主题相关的项目 可以包含以下内容 开发背景 总体需求 采用的技术体制 （使用该技术/方法的、该项目的）动机与期望 介绍担任的主要工作 第二题 理论描述，因主题而异 第三题 如何应用到项目中的，比如用到里理论中提到的哪些概念，又是如何实现的，实施效果又如何。 遇到了哪些问题，又是怎么解决的，实施效果又怎么样？ 0.3 注意 细心审题，问的是什么 备考阶段要专心于自己最熟悉、最复杂、最高级的系统或项目，因此这个系统或项目中自己不熟悉的部分就不要准备了，免得到时候瞎扯。所以后面这种都加上了 删除线 。 1. 软件架构（体系结构）设计 2018，论软件体系结构的演化 软件体系结构的演化是在构件开发过程中或软件开发完毕投入运行后，由于用户需求发生变化，就必须相应地修改原有软件体系结构，以满足新的变化了的软件需求的过程。体系结构的演化是一个复杂的、难以管理的问题。 概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。 软件体系结构的演化是使用系统演化步骤去修改系统，以满足新的需求。简要论述系统演化的6个步骤。

来源：https://blog.csdn.net/Rong_Toa/article/details/80771976 第一章 软件工程概论 1．什么是软件危机？ 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题表现在以下几个方面： (1)用户对开发出的软件很难满意。 (2)软件产品的质量往往靠不住。 (3)一般软件很难维护。 (4)软件生产效率很低。 (5)软件开发成本越来越大。 (6)软件成本与开发进度难以估计。 (7)软件技术的发展远远满足不了计算机应用的普及与深入的需要。 2．为什么会产生软件危机？ (1)开发人员方面，对软件产品缺乏正确认识，没有真正理解软件产品是一个完整的配置组成。造成开发中制定计划盲目、编程草率，不考虑维护工作的必要性。 (2)软件本身方面，对于计算机系统来说，软件是逻辑部件，软件开发过程没有统一的、公认的方法论和规范指导，造成软件维护困难。 (3)尤其是随着软件规模越来越大,复杂程度越来越高,原有软件开发方式效率不高、质量不能保证、成本过高、研制周期不易估计、维护困难等一系列问题更为突出，技术的发展已经远远不能适应社会需求。 3．怎样克服软件危机？ (1)充分吸收和借鉴人类长期以来从事各种工程项目中积累的行之有效的有效原理、概念、技术与方法，特别是吸取几十年来人类从事计算机硬件研究和开发的经验教训

ISDM定义 ISDM不仅只是—种如何开发信息系统的方法／过程模型。ISDM是—套整体方法，包含： —个通过分析方法、工具和技术操作的分析框架。描述系统开发中分析问题与解决问题的行为特征。主要指，面向过程、面向数据、面向对象。 支持分析框架的过程模型(process-model , 指开发活动的次序和持续时间）。描述系统开发随时间变化而呈现的阶段特征和项目管理与组织上的特征。有些类似SDLC, 如，瀑布模型、原型法、螺旋模型、敏捷软件开发等。 从技术上来讲， mis开发是系统阶段特征和行为特征的结合。因此， ISDM可视为包含开发信息系统用到的所有方法、操作和过程的框架。 完整的ISDM包含SDLC与开发方法、开发技术、开发工具及环境三层。 • SDLC ：ISDM开发方法的过程模型可能混用多种SDLC 以适用不同项目需求。 • 开发方法：主要指面向过程、面向数据、面向对象。是—个通过分析方法、工具和开发技术操作的分析框架。 • 开发技术：中间件、可视化、软件复用等 • 开发环境和工具： CASE 、SDE 、SEE 、IPSE等 ISDM 中的这四项内容彼此相互联系、相互支持、相互制约。 • 开发环境／工具位于最底层，说明其他层面均需要开发环境／工具的支持 • 开发技术是组成开发方法的基本成分，例如，结构化开发方法是由结构化分析技术、结构化设计技术、结构化程序设计技术组成

1.今天完成：MockingBot企业版中创建项目，将小组成员加入同一项目中；开始参照墨刀中的产品需求模板写需求分析；用ProcessOn完成思维导图，对产品需求有进一步的认识。 2.明日计划：需求分析文档完善，写完功能介绍和产品逻辑，开始原型设计。有时间的话看看关于微信小程序开发的文档和网课。 来源： https://www.cnblogs.com/Jane165/p/11385428.html

一、瀑布模型 1.1 什么是瀑布模型 1970年温斯顿.罗伊斯提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型 瀑布模型将 软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动 ，并且规定了它们 自上而下、相互衔接 的固定次序，如同瀑布流水，逐级下落 瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动 从本质来讲，它是一个软件开发架构 ，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生 循环反馈 ，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来 对于经常变化的项目而言，瀑布模型毫无价值 1.2 特点 1、阶段间具有顺序性和依赖性 该阶段具有两重含义 必须等前一阶段的工作完成后，才能开始后一阶段的工作 前一阶段的输出文档就是后一阶段的输入文档，因此只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果 2、推迟实现的观点 对于规模较大的软件项目来说，往往编码开始的越早，最终完成开发所需时间越长