需求文档

1.格式描述 姓名 学号 所属课程 https://edu.cnblogs.com/campus/xnsy/2019autumnsystemanalysisanddesign 作业要求 https://www.cnblogs.com/harry240/p/11524252.html 作业目标 总结回顾 整理资料文档 团队名称 七剑下天山 GitHub地址 https://github.com/BigTent0/HappyReading.git 2.团队成员 姓名 学号 博客地址 张鹏 201731062524（组长） https://www.cnblogs.com/BigTent/ 陈超 201731062510 http://home.cnblogs.com/u/kotofight/ 王慧 201731062504 https://www.cnblogs.com/lazy-bear/ 李邦国 201731062513 https://www.cnblogs.com/iron-man6/ 沈梓琳 201731062501 https://www.cnblogs.com/LIn000 何鑫懿 201731062122 https://www.cnblogs.com/hxywxy521 侯思其 201731062124 https://www.cnblogs.com/siqihou 3

无论我们做什么事都讲究方式方法，写 产品需求文档 (以下称 PRD文档 )也是如此，之前我通过四篇文章分享了自己写 PRD文档 的一些方法，而这一篇文章主要是对之前四篇文章进行整体的摘要介绍，帮助大家快速了解写作流程。 产品需求文档(PRD)的写作 四篇章： 1、写前准备(信息结构图) 2、梳理需求(产品结构图和用户流程图) 3、原型设计(手绘原型,灰模原型,交互原型) 4、撰写文档(PRD文档) 5、用例文档(UML用例图、流程图) 1、写前准备(信息结构图)： http://tangjie.me/blog/52.html 在写PRD文档之前，我们需要先罗列出产品功能的信息内容，这一步是将想法逐渐清晰的第一步，也是帮助我们接下来规划功能的辅助信息，同时也可以辅助服务端技术人员创建数据库。因为这是第一步，所以我们不需要罗列的很详细，在之后的步骤里，我们会逐步改进和完善信息内容。 例如一篇文章的信息内容主要有：文章标题、文章正文、文章作者、发布时间、所属分类。初始的功能需求只有这些信息内容，但是在之后的功能规划中逐渐更加细致的考虑时，可能会增加或者删减，因此第一步我们不用刻意的追求信息的全面。 罗列信息内容的方式有很多种，文本形式、思维导图形式等等都可以，最主要的是能够清晰易懂，我最常用的方法就是思维导图，因此我称这一步为信息结构图。 2、梳理需求(产品结构图和用户流程图)：

软件工程个人总结 一、引言 1.1 项目介绍——社团管理系统 1.1.1 项目背景 在当代大学生的日常生活中，社团是必不可少的一个部分。如果仅仅是通过纸质文档进行管理的话，不但需要耗费大量的人力和资源，也会给管理造成不便。为了提升社团组织者对社团管理的便利性，我们小组选择社团管理这一主题，开发一款便于社团管理的系统。 1.1.2 系统简介 社团管理系统的操作角色分为游客、学生、管理员三种类型，集成了社团浏览、活动浏览、社团申请、活动创建、活动审批、入社申请审批、社团内部事务管理等功能模块，为社团管理者与学生提供一个方便的数字化管理平台。 1.2 相关文档汇总 社团管理系统需求分析 社团管理系统设计图 社团管理系统原型阶段 社团管理系统接口文档 github前后端代码 二、项目制作过程——个人分工 2.1 起步 2.1.1 需求分析 参与组内讨论，根据学生、普通社员、社长、管理员4种角色来提出需求 2.1.2 墨刀原型 两项简易墨刀原型 web端原型 app端原型 2.2 设计图 详见 设计图文档 2.2.1 用例图 全部用例图 2.2.2 顺序图 仅参与确认 2.2.3 类图 整个类图的绘制与类图说明 2.3 技术选型 2.3.1 查阅与学习 由于组内成员没有相关项目开发经验，如前端框架、路由、接口信息接受发送，后端框架、信息接受与发送。因此学习、试错花费大量时间。 查找资料

1.软件测试基础 软件测试工程师：查找错误和缺陷，然后要求开发人员进行修改，保证软件质量。 漏洞（360安全漏洞）：硬件，软件，协议的具体实现或系统安全策略存在缺陷，从而可以使攻击者在未授权的情况下破坏系统。 千年虫问题：年份存2年，超过百年会出现bug。1900→2000 开发和测试的比例：4:1→10:1 手工测试、功能自动化测试、性能自动化测试、白盒测试 1-3-5年规划：手工测试工程师，功能自动化测试工程师，性能测试工程师 需要的技术：计算机操作系统，软件开发技术、软件测试技术、自动化工具 1.1 Windows操作系统及网络基础 　　熟悉windows操作系统和计算机基础知识，能够搭建软件测试环境，熟悉网络协议。 什么是软件：软件=程序+文档 什么是软件缺陷： 软件未出现说明书要求的功能 软件出现了说明书指明不应该出现的错误　 软件出现了说明书未提到的功能 软件未实现说明书虽未明确提及但应该实现的功能 软件难以理解，不易使用，运行缓慢或者从测试员角度看，最终用户会认为不好。　 什么是软件测试：在现有软件中寻找缺陷的过程 软件测试的历史：defect（缺陷），bug(臭虫)，debug（调试） 计算机层次：计算机硬件，操作系统，应用软件　 裸机包含软件：BIOS(Basic input/output system 基本输入输出系统) 常见操作系统：Windows

•　　产品说明 　　–　　包含： 　　　　　 　•　产品信息结构 　　　　　　　　–　　信息结构图是只按照产品经理思路中的产品表现来整理产品的一种示意图（后面会举例） 　　　　　　　　　　»　　信息结构能帮助我们整理产品结构， 同时是研发人员建立数据库的参考 　　　 　　　•　　产品结构图 　　　　　　　　–　　产品结构图是按照产品的逻辑与表现方式，结构化的表现产品构造的一种示意图 　　　　　　　　　　»　　通过这个产品结构图，我们大致就能将之前抽象的逻辑形象化的表现出来，也便于文档 　　　　　　　　　　　　阅读理解我们的产品思路 　 　　　　　•　　用户使用流程图 　　　　　　　　–　　用户使用流程图用于表述用户在使用产品过称中的行为走向 　　　　　　　　　　»　　通过用户行为串联信息结构与产品结构，阅读者通过用户使用流程，能更好的理解产品经理设计 　　　　　　　　　　　　的用户行为。 　　　　　　　　 ①产品信息结构图 　　 ②产品结构图 ③产品的用户使用流程图 PS: 一份国外数据分析，样本数据30万份，其中71.3%的人左手持手机左手拇指进行操作，82.6%的人在iPad上右手操作，平放在腿上时用拇指， 　　双手握时用右拇指 　　•　　是不是和我们想象很不一样？ 　　•　　做产品，有时候需要感觉，有时候需要数据 来源： https://www.cnblogs.com

•　　深刻理解三大文档的写作目的与应用场景 •　　理解并掌握PRD文档的用途与作用 •　　理解并掌握PRD文档： 　 　 –　写作思路 　　–　写作方法 　　–　写作格式 ♦　　产品需求文档（Product Requirement Document,　PRD）的英文简称 　 　–　　PRD文档向上是对MRD内容的继承与发展，向下则是要把MRD文档里面的各种理论要求 　　　　技术化，向研发部门与设计部门说明产品的功能和性能要求。 　　–　　PRD文档是产品文档中最底层最细致的文档，所以写作的时候，需要细致耐心。 --------------------------------------------------------------- 再看下这三个文档的区别 •　　BRD-这么做有什么好处，并说明好处在哪里 　 　–　　举例：唐僧出发前，参见唐黄，告诉唐黄西去取经的重要意义与大兴佛法的好处，唐黄答应，并发放免签 　　　　护照，于是唐僧带着任务出发了。 •　　MRD- 通过BRD明确了这个事情值得一做后，描述应该怎么做，并说明这么做的原因 　 　–　　举例：唐僧上路了，但是他需要选择走哪条路线，带几个人，为什么这么走，为什么带这些人，要说清楚 　　 　　 •　　A路线：妖怪多 　　　　•　　B路线：神仙多 　　　　•　　C路线：美女多 　　　　•　　经过分析，唐三藏决定C路线 •　

♦1.0　　产品说明 　　– 1.1　　产品定位 　　 　　•　　产品有越做越复杂的可能，但在一定时间内，定位决定了产品的一切 　　　　•　　产品定位与市场定位是有区别的，但经常容易混淆 　　　　　　 　–　　市场定位：我们对用户或者用户市场的选择，例如：手机发烧友，白领，或者移动通讯设备市场 　　　　　　　–　　产品定位：我们用什么样的产品满足用户或用户市场。例如： 　　　　　　　 　»　　陌陌，一款基于地理位置的移动社交工具 　　　　　　　　»　　抖音，短视频分享平台 　　　　　　　　»　　哔哩哔哩，专注于二次元社区，提供动漫，周边的平台 　　　　 　　　 –　　用户定位的描述： 　　　　　　　 　»　　针对什么目标群体，做什么事情，用最本质的，无修饰的语言表态 　　 –1.2　　产品核心目标（产品本身要达到什么，一个目标） 　　　 　–　　互联网产品的核心目标，往往表现为要解决目标市场（目标用户）一个什么问题 　　　　 　　•　　这个问题分析的越透彻，产品的核心目标也就越准确 　　　　　　•　　确立好核心目标，不会使我们产品推进过程中迷失 　　　　　　•　　例如： 　　　　　　　 　–　　360安全卫士：解决用户使用电脑的安全问题 　　　　　　　　–　　微信：在最早的阶段，微信的核心目标是工具类的，为用户提供流畅的移动应用 　　 　　　　•　　通常来说

一、工具集合 ①　　Microsoft Office 　 　–　　Excel (数据统计，数据分析，数据报表，数据图例制作，进度控制，神器) 　　　 　 •　　Excel 文档结构（版式设计，逻辑结构表现，色彩） 　　　　•　　简单的函数计算 　　　　•　　数据组织 　　　　•　　图标制作（饼状图、柱状图、条形图、折线图） 　　–　　PowerPoint(演示利器) 　　–　　Word（文档） ②　　Microsoft Visio 　 　–　　流程图利器 　　–　　信息结构例图 　　（例图，学完补充） ③　　Axure 　 　–　　简易流程图 　　–　　原型利器 　　 　注意 　　 　　•　　Axure虽好，谨记它只是工具，不要被他所左右 　　　　•　　不要陷入到超级写实中去 　　　（例图，学完补充） ④　　Balsamiq Mockups 　 　–　　原型图草图利器 　　 　　•　　可以快递构建你想要的东西 　　　　•　　很好的支持移动性能 　　　　•　　元素丰富 　　　　•　　不容易干扰UI设计 　　　　（例图，学完补充） ⑤　　Mindmanager 　　–　　思维导图 　　–　　收集，归纳，整理想法与思路 　　（暂时未找到破解版，尝试用Xmind代替） 　　（例图，学完补充） ⑥　　二笔铅笔（包括各种笔） 　　•　　高速 　　•　　简介 　　•　　灵敏 　　•　

武汉大学教务管理系统需求分析需求文档 项目组长:杨乾成 张陈杰 成员:林朝阳 梁翘楚 孟苏 李景怡 叶沛玟 1 引言 1.1 编写目的 本文档是武汉大学计算机学院17级大型软件设计课程小组今天吃啥APP项目的初步需求，主要面向开发人员、管理人员、测试人员和用户，使之能够更好的理解系统功能。本说明书不仅是整个软件开发的依据，也对以后的维护性工作起着指导性的作用，同时也是设计说明书和测试计划的编写依据。 预期读者：开发人员、管理人员、用户代表、测试人员等。 1.2项目背景 每日有三问：早饭吃什么 午饭吃什么 晚饭吃什么  今天吃什么往往是困扰许多人的一个难题。即使是已经大三的我们，也常常陷入不知道吃什么的困境之中。由于武大校园面积大、校园内食堂与附近餐饮店铺众多，我们每天在决定吃什么的时候，可选择的店铺不在少数。然而由于不同食堂窗口、商家提供的菜品质量、口味不同等原因，许多学生在进行选择时会出现选择犹豫症，尝试新的窗口怕踩雷，而总在一个窗口时间久了却又觉得厌烦。 因此，我们想到了开发一款可以每天为你规划一日三餐的APP，可以根据用户以往的习惯、身体状况、天气状况为用户指定食谱，同时还结合了市面上美食APP的一些功能，让用户可以自行寻找感兴趣的食堂窗口或商家。 a. 待开发的软件系统名称: b. 本项目提出者：武汉大学计科青鸟开发小组 c. 开发者：武汉大学计科青鸟开发小组 d. 用户

1、需求是什么 通常意义下，软件行业对需求的定义可能是由“需求方”以文字，口头，示意图 或者其他途径提出的“关于功能要怎么做”的表述。 2、需求有什么问题 往往软件开发行业陷入了一个困局，明明是按照需求方提出的需求，逐条实现的，为什么需求方往往不满意，做完又马上提出一堆变更，搞得双方都一肚子意见 3、真正的需求是什么，应该怎么分析 真正的需求应该把握这几个要点，“目的”，“方式”，“测试”，“结果” 逐条解释一下， 目的： 需求的本质，这个需求是要做什么，这个在很多关于需求的分析中都讲得非常清晰了，即分析用户提需求的动机，是要实现什么。拿个经典的马车与汽车的例子，需求是要更快的马车，但是实际上如果给出汽车方案更符合需求。软件开发过程中这样的例子很常见，比如说客户要在某个位置增加一个表单，以实现浏览到这个页面的同时，顺便能提交一个什么东西，实际上如果针对这个需求给出新增一个功能模块，单独放在首页入口，或者是一个专题页面，这样从推广，还是从页面美观性更合理。 总结一下就是：分析目的，从而导出多种实现方式，择优。 （因为往往提的需求本身等价于某一种实现方式，需要追溯到原始节点，然后发现有多种路径） 方式： 和目的环环相扣，目的导出方式，而方式决定了后面的结果是否满足目的。 测试： 为什么会有个测试呢？这里的测试是指验证需求分析。 给需求方确认的东西以往都是文档，一堆设计图。