需求分析

要点提示： 软件开发生命周期是一个多阶段的过程，包括需求规范、分析、设计、实现、测试、部署和维护。 需求规范 　　是一个 规范化的过程，旨在理解软件要处理的问题，以及将软件系统需要做的详细记录到文档中。 系统分析 　　系统分析旨在分析数据流，并且确定系统的输入和输出。当进行分析的时候，首先确定输出，然后弄清楚需要什么样的输入从而产生结果是有帮助的。 系统设计 　　是一个从初入获得输出的过程。这个阶段涉及及使用多层的抽象，将问题分解为可管理的组成部分，并且设计执行每个组成部分的策略。可以将每个组成部分看做一个执行系统特定功能的子系统。系统分析和设计的本质是输入、处理和输出（IPO）。 实现 　　将系统设计翻译成程序。 测试 　　确保代码复核需求规范，并且排除错误。 部署 　　使得软件可以被使用。 维护 　　是对软件产品进行更新和改进。 来源： https://www.cnblogs.com/cglib/p/11947197.html

近来二次阅读苏杰著人人都是产品经理，还是很有收获，为了促进自己反思，特记录在此。 产品经理是关于事和人的匹配。事，对公式来说，梳理清晰的业务是根本，对个人那是具体的任务。人，要具备相应能力，知识，技能和态度。 项目经理是任务的执行人，不是提出者，需要执行，计划和控制能力。产品经理是任务的提出者，更需要创造力和项目管理能力。项目越做越确定，是个闭环，产品越做越大，开放式的。 产品经理要学会面对真正的问题，去追问本质，多问问为什么，目的是什么，这样才能更好的提供解决方案～产品。 只做一次的事情找可行解，反复做的事情最优解。 产品经理的成长过程，有输入也得有输出，需求收集调研，分析需求，方案设计，流程，线框，架构，开发，测试，验证，交付，运营，优化。 需求提出来，做出来，推出去。 提出来，就是业务痛点或者新需求，是要解决的一个或者一系列问题，据此提出解决方案，当然要反复推敲，调研，分析，并确定定位和目标，然后筛选出方案。 做出来，对应的是根据定的方案，制定设计出具体操作任务，涉及细节，并评估出需要的资源和时间计划，以及操作的流程和方法，并按照计划交付产品。 推出去，意思是将产品交给用户和客户，真正的解决业务问题，提现产品价值。在运营中发现不足，再提升优化。 让产品有用，可用，好用，有人用。 来源： https://www.cnblogs.com/uplove/p/11920609

需求工程 什么是需求分析? 1.软件工程的子领域 2.对系统应该提供的服务和所受到的约束进行理解、分析、建立文档、检验的过程 需求工程的重要性和意义 1.没有需求就没有软件 2.项目失败原因中，最突出两大原因，缺乏最终用户的参与以及完整的需求又是两大首要原因 需求工程困难性 应用领域的广泛性 非功能性需求建模技术的缺乏 沟通上的困难 需求分类 功能需求 对系统应该提供的服务、功能以及系统在特定条件下的行为的描述。它与软件系统的类型、使用系统的用户等相关，有时需要详细描述系统的功能、输入/输出、异常等，有时还需要申明系统不应该做什么。 领域需求 是由软件系统的应用领域所决定的特有的功能需求，或是对功能的约束。 需求分析的作用 定义软件的范围及必须满足的约束 确定软件的功能和性能及与其他系统成分的接口 建立数据模型、功能模型和行为模型 最终提供需求规格说明，并用于作为评估软件质量的依据 需求分析基本活动 获取需求：深入实际，在充分理解用户需求的基础上，获取系统需求 需求分析与建模：进行需求建模、对模型或原型进行分析 确认需求：确保需求说明准确、完整地表达系统的主要特性 进化需求：客户的需要总是不断（连续）增长的，进化需求是必要的 需求获取的要弄清的三个问题 明确需要获取的信息（What ） 明确所获取信息的来源和渠道（Where ） 怎样获取需求（How ） 需求获取方法 1.面谈法

首先说一下我还是喜欢做测试，目前发现自己的需求分析做的不是很好。 产品小白学习录： 1、在每次得到一个需求分析的说明时，知道它想要知道做什么东西的同时还要去构思它的整体架构（最好用思维导图画出来，比如需求页面里面需要显示的要素）这样和项目经理沟通的时候那你就知道你你哪块不懂或者哪一块的逻辑错误了。 2、一定一定在开始原型设计的时候把你的页面构思好，做成脑图可以先给项目负责人（如果她是开始做需求调研的那个人的话）看看你的流程和页面要素有没有问题。不然在后面你是一边做一边想那就很有可能是你做了一点发现流程偏了或者是还有哪一个要点漏了没有考虑进去，造成你要重新做or改很多版。一次性敲下你就少纠结很多东西，只剩页面布局问题。 3、做产品的一定要做好沟通，主要是和最能知道用户实际需求的人。（这个本来是产品要做的事，但目前我是个新人还不是很了解当前系统的用户的使用需求很多东西只能靠自己的想象这样不是很实际设计的东西不会贴合用户的实际使用情况。）这个对我来说是最痛苦的，我个性在不是很有安全感的环境下去放开自己去和其他人沟通，前期的时候老是被leader说你别老是默默做要多问一下，不然做出来的东西不对后面还要改这样很浪费时间和影响进度。所以沟通真的很重要，当然把握好那个问的度也很重要，怎么样问的让人觉得你有去理解需求深度、不会被认为过度的确认而导致其他人觉得你很烦这个也是要好好学习的

本次我们小组的项目是基于微信公众号的企业实习管理系统。我本次需求分析报告的撰写参考了两篇研究生的论文，这两篇论文给了我很大的帮助。让我对需求分析如何去写有了一定的了解。我们的项目总体来说，数据库的设计与实现一定是重中之重，因为要实现实习管理功能，企业，学生，老师和各种表格等信息的存储都必须到位，而且权限必须分开，所以我们需求分析里针对这些不同信息的管理提出了明确的要求，软件功能架构图也是如此。此外，我们应老师要求，还在最基础的实现信息管理的基础上，增加了招聘信息的表，并且在学生上传表格时，有时间提醒功能，如若预期未交，系统则会警告该学生。在其他方面，需求分析中对本系统的可维护性和可扩展性也提出了要求。下面是完整的软件架构图 总而言之，经过本次写完需求分析后，我对该项目的具体要求和功能实现才有了具体的认知，我们小组才有了明确的方向。这让我意识到了需求分析的重要性，同时也使我的能力成长很多，我懂得了需求分析的书写方式和要求，也对一个项目开发小组的开发流程有了深入的了解。之后还有很多工作要做，希望能和小组其他成员一起把该项目做好。 来源： https://www.cnblogs.com/tian-123/p/11785384.html

【Alpha阶段】第六周Scrum Meeting! 第六周任务内容： 本次会议为第六周第一次Scrum Meeting 会议。 本次会议在学生公寓225展开，全员参加。 队员 上周完成任务 本周要完成任务 王震 UI制作软件磨刀熟悉（完成） https://github.com/Qin-Hao/SoftwareEngineering/issues/6 使用墨刀制作UI界面 秦浩 需求分析文档设计（完成） https://github.com/Qin-Hao/SoftwareEngineering/issues/3 安卓程序代码学习 曲少伟 软件架构分析（完成） 完成软件架构文档 司呈令 参与需求分析文档设计（完成） 辅助各项事务 开会照片： 软件架构分析草图： 关于困难和收获： 王震：软件工程的设计方法太赞了，甚至可以用到其他诸如自己的学习方法上来，节约时间的同时效果也很好，不愧是这么多年这么多人这么多大公司累积出来的思路。 秦浩：需求分析文档对整个软件工程的作用是非常大的，所以会花很大的功夫去学习，借鉴和研究需求分析文档，有一定难度同时也是非常必要的。 曲少伟：软件工程的前期准备也不容易，需要花大功夫，考虑很多因素，而且对于需求分析来说一次讨论还不够，多讨论几次每次都会有新的需求点提出来。 司呈令：软件工程不同于普通的软件制作或程序编写，无疑是具有复杂性。需要耐心

第二部分 面向对象分析 2.1 面向对象分析(OOA)的定义？ 　　OOA——面向对象的分析，就是运用面向对象方法进行系统分析，对问题域(问题所涉及的范围)和系统责任(所开发的系统应具备的职能)进行分析与理解，找出描述问题及系统责任所需要对象，定义对象的属性、操作以及它们之间的关系。 2.2 面向对象分析(OOA)的优点？ 加强了了对问题域和系统责任的理解； 改进与分析有关的各类人员之间的交流； 对需求的变化具有较强的适应性； 支持软件复用。 2.3 面向对象工具——UML(Unified Modeling Language)统一建模语言 　　UML是对软件密集型系统中的制品(模型、源代码、测试用例等)进行可视化、详述、构造和文档化的语言。 （1）UML特点 统一的标准 面向对象 可视化、表示能力强大 独立于过程 概念明确，建模表示法简洁，图形结构清晰，容易掌握和使用 （2）UML的构成 　　UML中的3类主要元素是基本构造块、规则、公共机制 （3）UML中的视图 　　UML中的视图包括用例视图、逻辑视图、实现视图、进程视图、部署视图，被称为“4+1”视图 用例视图：用于表达系统的功能性需求 逻辑视图：用于表示系统的概念设计和子系统结构等 实现视图：用于说明代码的结构 进程视图：用于说明系统中并发执行和同步的情况 部署视图：用于定义硬件结点的物理结构 2.4 面向对象分析(OOA

本周我们的原型审核过关了，这也就意味着项目需求终于定下来了。这历时4周的需求分析，让我收获颇丰。 起初，我错误理解需求为功能，也就是这个项目要实现什么功能。我们和项目老师确定了功能后，便用墨刀开始创建项目原型。开始，我们不知道项目原型的重要性，还以为项目原型就是方便和老师交流需求的，而且墨刀我们使用不熟练，所以就只将功能展示了出来，字体，布局完全没考虑过。甚至项目原型出现了两个页面字体大小完全不同的情况。所以，虽然项目原型做出来了，但是非常不美观。这也是项目老师审核后的意见。期间，我们被告知需求太多，可能做不完，后来我们评估自己小组的开发水平，发现确实需求太多。于是我们和项目老师反映了这个情况，项目老师也允许我们减少需求。之后两周就是做项目原型了。历经了两周时间，每次和老师都从晚上9点谈到11点，我们的项目原型终于过关了。 这次的需求分析让我知道了需求原型的重要性，需求原型就是产品的样子。同时也让我了解到了公司项目的管理流程。需求分析人员在听完客户的需求后，做出项目原型，和客户讨论后，再交给开发人员实现。而且，它让我正确地理解了需求。需求不仅仅是功能，还有很多其他的。这四周也让我体验到了真实的项目开发过程。每次和老师讨论都有新的需求，就这样，我们的项目原型做了3次。这在真实的项目里也是会出现的，因为每次见面客户对自己的产品有了不同的想法或者觉得你做出来的项目原型和他的预想不一样

按照规范设计的方法，考虑数据库及其应用系统开发全过程，将数据库设计分为以下6个阶段 1.需求分析 2.概念结构设计 3.逻辑结构设计 4.物理结构设计 5.数据库实施 6.数据库的运行和维护 1.需求分析阶段（常用自顶向下） 进行数据库设计首先必须准确了解和分析用户需求（包括数据与处理）。需求分析是整个设计过程的基础，也是最困难，最耗时的一步。需求分析是否做得充分和准确，决定了在其上构建数据库大厦的速度与质量。需求分析做的不好，会导致整个数据库设计返工重做。 2.概念结构设计阶段（常用自底向上） 自顶向下。即首先定义全局概念结构的框架，再逐步细化。 自底向上。即首先定义各局部应用的概念结构，然后再将他们集成起来，得到全局概念结构。 逐步扩张。首先定义最重要的核心概念结构，然后向外扩张，以滚雪球的方式逐步生成其他的概念结构，直至总体概念结构。 混合策略。即自顶向下和自底向上相结合。 3.逻辑结构设计阶段（ E-Rͼ ） 4.物理设计阶段 首先要对运行的事务详细分析，获得选择物理数据库设计所需要的参数，其次，要充分了解所用的RDBMS的内部特征，特别是系统提供的存取方法和存储结构。 5.数据库实施阶段 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演讲答辩 叶泽林 制作类图 郑志强 制作界面原型 刘御帆 评分 许宏健 评分 侯熠珉 写功能验收标准