需求分析

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

团队项目-需求分析报告 一、博客链接 组长博客链接 二、组队后的团队项目的整体计划安排 编写需求说明书。 确定各功能模块分工。 完成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演讲答辩 叶泽林 制作类图 郑志强 制作界面原型 刘御帆 评分 许宏健 评分 侯熠珉 写功能验收标准

需求分析： 整体流程图： 需求提取 -> 需求分析 -> 需求评审 -> 更新后的测试需求跟踪xmind 分析流程： 1. 需求提取： 分析依据（包括：需求矩阵、产品交互图、需求说明书） 获取需求的纬度 客户价值 可以为客户带来哪些价值？ 可以解决哪些问题？ 根据以上问题定位功能是否合理 UI功能 - 展示功能 模块关联-历史模块 新功能模块关联 考虑是否关联？耦合部分是否需要支持？ 客户使用场景-部署方式 网络特性 客户使用服务器常见外设 性能参数-性能要求 网卡最低速率 硬件支持 输出（提取最原始的测试需求） 2. 需求分析： 分析依据（五维分析） 用户场景 功能是否和场景强关联 网络拓扑能否满足客户需求 和竞争对手比较差异 功能是否能满足客户实际应用场景 是否考虑了用户的实际操作 明确性 范围明确性（参数、类型长度范围） 清晰性限制等范畴 无法预知影响的需求提出进行确定，风险 二义性 概念模糊【大概念、第三方支持、与上个版本相同】 支持与不支持等范畴 一个需求描述能出现多种理解 完整性 需求一致性【用户需求、需求规格、需求矩阵三者是否同意】 需求完整【隐形需求】 关联性【与新老功能、与外置软件设备】 可测试性 实现测试需要的工具、方法【调试、接口命令】 定位方式【日志等形式观察】 复杂环境、容量边界、操作时过程不可见 输出 测试需求跟踪 缺陷预防bug 工具需求

转 https://www.cnblogs.com/syw20170419/p/8640609.html 案例 《挖掘管理价值：企业软件项目管理实战》一2.3　需求分析过程 1、什么是测试需求分析 需求分析：需求规格说明书的编写作者，在编写需求时进行的业务分析，依据于业务，来进行需求的编写 测试需求分析：1、分析需求的可行性 2、分析测试点：将需求分析拆分成一个个的功能点 拿到需求----测试需求分析-----编写测试计划/编写测试用例-----执行测试-----编写测试报告 2、测试需求分析点 1、功能需求： 占据系统80%左右的内容，软件主体。显性的需求分析点 2、业务需求： 隐性需求，直接看到的软件并没有将全部的业务显示出来，通过什么步骤进入到什么页面，什么页面显示什么样的内容，分析业务 　　　　　　 的重要性：实际的业务中每一个业务系统解决了什么问题，达到了什么目的，业务的表现在功能上，依托功能来表现业务。 3、性能需求：有明确性能的需求（显性需求），如淘宝0点8分到5点7分有500用户使用，没有性能需求（隐性需求） 4、环境需求：系统运行环境的需求分析 5、安全性需求：用户登录（权限）、密码加密、非敏感行业，隐性需求 6、界面需求：用户交互、UI 7、可靠性需求：运行过程中出错的风险，软件的数据准确性、流程完整性 3、测试需求分析技巧 1、熟悉需求，明确测试范围

本文属于转载文章，仅供参考，原文链接： https://www.cnblogs.com/tynam/p/9078274.html 一、测试的流程 　　测试贯彻在产品生命周期中的每一个环节，从需求提出开始到测试计划、测试设计以及测试用例设计与评审及执行，最后进行回归测试。产品发布上线后跟踪用户使用的反馈，周而循环直到产品不在维护。 　　1、参与需求的评审 　　　　评审内容主要分为功能性、准确性、完整性、可测性、优先级和约束性。当然还有其他的性能要求、安全、可补充性、易用性等 　　　　功能性指描述功能的规格说明、状态变化、界面格式的定义等表述合理；准确性指需求清晰完整，无歧义；完整性指需求可以满足用户的使用；可测性指需求是否可以被测试用例覆盖到；优先级指优先完成那部分；约束性指某些事件是否需要一定的前提条件。 　　2、测试计划 　　　　测试计划应该以文档的形式输出，主要包含的几个点为测试对象（根据需求分析测试对象的应测特性和不测特性，不测说明原因）、测试通过或失败的标准（主要为测试用例的覆盖率和问题的修复率）、测试任务安排（谁负责什么模块）以及工作量的估算。还有其他的一些资源统计、项目简介等。 　　3、测试设计 　　　　测试设计是对测试计划的细化。也是以文档的形式输出。主要内容有测试环境的描述、用例执行的顺序（一般都是功能性用例到易用性、兼容性再到安全性、异常行为等）、用例的设计规定

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

今日完成： 今天周末，任务完成的比较少， 做了配送端的需求分析和原型设计，把整体原型完善了一下， 看了看小程序制作的教程 明日计划： 制定一个小程序的编程方案，理清思路， 继续学习小程序制作的内容， 按照计划进行小程序的编程工作 今日小结： 需求分析和原型设计非常重要，老师说不实用的软件没有意义， 如果做不好需求分析就很难做出有用的软件， 所以一定先做好需求分析和原型设计， 所以还是要先把需求分析和原型设计做好。 来源： https://www.cnblogs.com/ysjzyy/p/11405987.html

今日完成： 今天做好了商家端的原型设计，完善了客户端的原型，进行了展示。 仔细思考了课上老师提出来的问题，明确解决方案。 明日计划： 先根据老师提出的问题和今天的构思，完善需求分析， 对配送方面进行全新的原型设计，增加配送方， 学习小程序制作的方法，复习以前学过的内容，准备开始编程工作。 今日总结: 今天在商家端的原型设计上遇到了一点小问题，不过也很快解决了， 原以为原型已经做的比较完整了，直到课上老师提出配送方面的问题， 才发觉自己在需求分析上就忽略了配送的问题，导致软件即使做出来，也并没有实用价值； 所以自己认真思考了这个问题，打算先把需求分析再理一遍， 把缺少的原型部分补充完整再开始下一阶段的任务。 来源： https://www.cnblogs.com/ysjzyy/p/11402530.html