需求分析两种方法

⑴ 需求分析有哪三种方法2，什么是面向数据结构方法

它首先用结构化分析（SA）对软件进行需求分析，然后用结构化设计（SD）方法进行总体设计，最后是结构化编程（SP）。它给出了两类典型的软件结构（变换型和事务型）使软件开发的成功率大大提高。

三种基本的结构形式就是顺序、选择和重复。三种数据结构可以进行组合，形成复杂的结构体系。这一方法从目标系统的输入、输出数据结构入手，导出程序框架结构，再补充其它细节，就可得到完整的程序结构图。这一方法对输入、输出数据结构明确的中小型系统特别有效，如商业应用中的文件表格处理。该方法也可与其它方法结合，用于模块的详细设计。

⑵ 如何正确的理解和分析用户需求

3、两种需求分析方法
1.HMW：how might we=我们可以如何=怎么办（Designhackthon）
流程
问题：明确用户场景问题（问题需要聚焦及开放）
例1:公司想要冲刺业绩/清理库存，如何促销？
例2:用户购后评价率低于8%应该怎么办？
手段：HMW方法分解问题
拆解问题
积极：如何让用户自发资源的解决问题？
转移：怎样让其他人帮助解决这个问题？
脑洞：怎样想些脑洞大开，平常不敢想的方案？
分解：把大的问题分解成几个小的步骤？
否定：想什么办法能让用户放弃这个想法？
方案：脑暴
全部都要想要解决的方案，全部穷举
优先级：分类排序
MVP：流程与原型设计
分析需求
步骤
澄清问题
原始需求是什么层次？（方案级还是问题级？）
想要解决谁的、什么问题？
用户遇到现在的问题会采取什么样的解决方案？
这个问题中有需要进一步细化和明确的概念吗？
了解背景
场景（功能）
该需求谁使用？什么时候使用？具体怎么做？
术语（数据）
有需要澄清的业务术语吗？它们的格式是什么？
环境（质量）
不做谁生气？多久生气一次？为什么？多久用一次？
建议并确定解决方案
要解决这个问题有哪些可行的解决方案
这些方案的实现成本分别有多少？
你觉得哪种最合适？（解决问题/成本合适）
该解决方案对用户而言有什么优缺点？
有其他需要挖掘的需求吗？

⑶ 需求分析的主要方法是

目前，软件需求的分析与设计方法较多，一些大同小异，而有的则基本思路相差很大。从开发过程及特点出发，软件开发一般采用软件生存周期的开发方法，有时采用开发原型以帮助了解用户需求。在软件分析与设计时，自上而下由全局出发全面规划分析，然后逐步设计实现。
从系统分析出发，可将需求分析方法大致分为功能分解方法、结构化分析方法、信息建模法和面向对象的分析方法。
(1)功能分解方法。
将新系统作为多功能模块的组合。各功能义可分解为若干子功能及接口，子功能再继续分解。便可得到系统的雏形，即功能分解——功能、子功能、功能接口。
(2)结构化分析方法。
结构化分析方法是一种从问题空间到某种表示的映射方法，是结构化方法中重要且被普遍接受的表示系统，由数据流图和数据词典构成并表示。此分析法又称为数据流法。其基本策略是跟踪数据流，即研究问题域中数据流动方式及在各个环节上所进行的处理，从而发现数据流和加工。结构化分析可定义为数据流、数据处理或加工、数据存储、端点、处理说明和数据字典。
(3)信息建模方法。
它从数据角度对现实世界建立模型。大型软件较复杂；很难直接对其分析和设计，常借助模型。模型是开发中常用工具，系统包括数据处理、事务管理和决策支持。实质上，也可看成由一系列有序模型构成，其有序模型通常为功能模型、信息模型、数据模型、控制模型和决策模型。有序是指这些模型是分别在系统的不同开发阶段及开发层次一同建立的。建立系统常用的基本工具是E—R图。经过改进后称为信息建模法，后来又发展为语义数据建模方法，并引入了许多面向对象的特点。
信息建模可定义为实体或对象、属性、关系、父类型/子类型和关联对象。此方法的核心概念是实体和关系，基本工具是E-R图，其基本要素由实体、属性和联系构成。该方法的基本策略是从现实中找出实体，然后再用属性进行描述。
(4)面向对象的分析方法。
面向对象的分析方法的关键是识别问题域内的对象，分析它们之间的关系，并建立三类模型，即对象模型、动态模型和功能模型。面向对象主要考虑类或对象、结构与连接、继承和封装、消息通信，只表示面向对象的分析中几项最重要特征。类的对象是对问题域中事物的完整映射，包括事物的数据特征(即属性)和行为特征(即服务)

⑷ 需求分析方法有哪些

问题一：需求分析有哪些方法 三种需求分析的方法：结构化分析方法、面向对象的分析方法、面向问题域的分析方法。
结构化的分析方法是传统的分析法，它的好处是在需求阶段可以不需要精确地定义系统，只需要根据业务框架确定系统的功能范围，以及每个功能的处理逻辑和业务规则，功能需求规格书等。因为不需要精确描述，因此描述系统的方式比较灵活多样，可以采用图表、示例图、文字等等方式来描述系统。在系统开发以前，一般还可以采用更为直观的原型系统方式和最终用户进行交流和确认，因此对业务需求的要求会低一些，业或冲务需求阶段的周期相对容易控制；通过业务全景图，最终用户也能了解系统的功能；通过功能活动图和业务规则的描述，也可以相对精确地描述业务系统；因为没有严格的标记语言，可以采用适当的篇幅描述适当的系统。当然，这种方法的缺点也是明显的，分析人员和业务人员之间可能缺乏共同语言，机器不能识别业务需求书，在设计阶段还需要继续和用户确认一部分功能。
面向对象的分析方法陪团如的最大好处是在需求阶段，就能够非常精确地描述一个系统，采用程序语言的方式和最终用户交流（最终用户必须要熟悉这种语言），能够在项目一开始就发现很多问题，避免在开发的过程中出现需求的反复，而且在系统设计和开发阶段不需要最终用户参与。在实施上，一般可以采用场景、业务功能等方式来描述，比较适合于业务流程环节多的系统，或者软件产品的开发。但是，我们也要看到，在现实中，绝大多数的应用系统都很难在需求阶段就可以被精确地抽象化定义，所以这种方法的缺芦启点和困难也是显而易见的：首先，用户要非常清楚地知道最终的业务系统应该是什么样，或者采用一种抽象的方式能够确定最终的应用系统；其次，因为最终用户不需要参与设计和开发阶段的工作，所以双方确定业务需求的过程也会比较长；同时，因为是精确描述，因此描述系统的语言是非常逻辑化的，一般通过某种方式可以使机器识别业务需求，采用这种方式写的业务需求是非常格式化的，一方面描述一个系统需要的信息非常多，可能使需求说明的篇幅非常长，不便于理解和阅读；另外由于通过抽象的方式来推演最终系统的运行方式，对业务人骸的要求非常高。

问题二：项目需求分析的分析方法 需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论.原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发.原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。进化型属于这种策略.

问题三：如何做好需求分析，需求调研 转载以下资料供参考
从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上理解需求分析指需求的分析、定义过程。
原因
需求分析就是分析软件用户的需求是什么。如果投入大量的人力，物力、财力、时间，开发出的软件却没人要，那所有的投入都是徒劳。如果费了很大的精力，开发一个软件，最后却不满足用户的要求，从而要重新开发过，这种返工是让人痛心疾首的(相信大家都有体会)。比如：用户需要一个for linux的软件，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题，而想当然的认为是开发for windows的软件。当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不得找块豆腐一头撞死。
需求分析之所以重要，就因为他具有决策性、方向性、策略性的作用，他在软件开发的过程中具有举足轻重的地位，大家一定要对需求分析具有足够的重视。在一个大型软件系统的开发中，他的作用要远远大于程序设计。
任务
简言之，需求分析的任务就是解决“做什么的问题，就是要全面地理解用户的各项要求，并准确地表达所接受的用户需求。
过程
需求分析阶段的工作,可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。
问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、操作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。
分析与综合： 逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。
制订规格说明书： 即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。
评审： 对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。
方法
需求分析的方法有很多，这里只强调原型化方法，其它的方法如：结构化方法、动态分析法等，从来没用过这些方法在此不讨论。
原型化方法是十分重要的，原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能。
原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能。但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性、技术的可行性或考察是否满足用户的需求等。如：为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型。以后的目标系统就在原型系统的基础上开发。
原型主要有三种类型：探索型、实验型、进化型。
探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。
实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。
进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。
在使用原型化方法时有两种不同的策略：废弃策略、追加策略。
废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成......>>

问题四：请问常用的需求分析方法有哪些？ 结构分析方法和面向对象分析法

问题五：培训需求分析的方法有哪几种 组织资源分析
如果没有确定可被利用的人力、物力和财力资源，就难以确立培训目标。组织资源分析包括对组织的金钱、时间、人力等资源的描述。一般情况下，通过对下面问题的分析，就可了解一个组织资源的大致情况。
组织特质与环境分析
组织特质与环境对培训的成功与否也起重要的影响作用。因为，当培训规划和组织的价值不一致时，培训的效果则很难保证。组织特质与环境分析主要是对组织的系统结构、文化、资讯传播情况的了解。主要包括如下内容：
系统特质指组织的输入、运作、输出、次级系统互动以及与外界环境间的交流特质，使管理者能够系统地面对组织，避免组织分析中以偏概全的缺失。
文化特质。指组织的软硬体设施、规章、制度、组织经营运作的方式、组织成员待人处事的特殊风格，使管理者能够深入了解组织，而非仅仅停留在表面。
资讯传播特质。指组织部门和成员收集、分析和传递信息的分工与运作，促使管理者了解组织信息传递和沟通的特性。

问题六：在需求分析阶段常用的图形工具有哪三种 1. 需求分析是准确的理解用的需求将其转换成需求定义，然后由需求定义转换成形式化的功能规约。需求分析的困难表现在问题的复杂性、交流的障碍、不完备和不一致性、需求易变性。 2. 结构化分析方法是采用自顶向下逐层分解的分析策略把一个复杂的系统分解成若干小问题然后分别解决 3. 数据流即数据通过一个系统时的变化方式。输入数据首先转换成中间数据，然后转换成输出结果数据。在此期间可以从已有的数据存储（如磁盘文件或内存缓冲区）中引入附加数据。对数据进行转换是程序中应有的功能或子功能。两个转换功能之间的数据传递就确定了功能间的接口。 4. 把一个功能分解成几个子功能，并确定这些子功能与父功能的接口，就属于横向分解。 5. 把一个功能分解成几个子功能，并确定这些子功能与父功能的接口，就属于横向分解。但如果继续分解，把某些子功能又分解为小的子功能，某个小的子功能又分解为更小的子功能，这就属于纵向分解了。 6. 数据流图是用来表示系统的功能的工具它表示系统的逻辑模型描述了数据流在系统中流动的情况它是一种功能模型。

问题七：如何做需求分析 随着技术的不断发展和用户对网站功能性的需求不断提高，如今网站项目的设计已经不能再仅仅简单地利用静态Html文件来实现，与前几年网站设计由一两名网页设计师自由的创作相比，网站项目的设计和开发越来越像一个软件工程，也越来越复杂，网站项目的设计和开发进入了需要强调流程和分工的时代，建立规范的、有效的、健壮的开发机制，才能适应用户不断变化的需要，达到预期的计划目标。
网站项目管理（WPM）的含义为Web-based Project Management，即以Web 应用程序为主要表现方式的架构来进行的项目设计及管理，这样的架构中包含了浏览器、网络和Web
服务器等关键主体，主要体现在网站设计、以浏览器为客户端的Web应用程序开发（例如信息类网站、网上商店、虚拟邮局、客户关系管理。）等项目管理中。
按照笔者的经验，网站项目管理可以分为以下l六个阶段进行控制：
1. 需求分析及变更管理
2. 项目模型及业务流程分析
3. 系统分析及软件建模
4. 界面设计、交互设计及程序开发
5. 系统测试和文档编写
6. 客户培训、技术支持和售后服务
需要说明的是，这些阶段虽然具有一定的延续性，但是并非完全隔断的，例如需求变更管理和测试工作、文档编写都是贯穿整个项目过程的，许多工作时交叉进行或同时进行的。
（一）如何做好需求分析及变更管理？
业务员与客户进行的沟通，撰写需求分析报告是项目展开的基础。项目是以客户的需求为中心，而不是为技术而迁就需求。
一：让客户畅所欲言，罗列出所有的需求
让用户将所有的想法尽可能的阐述清楚，并把所有的要求罗列出来，不要遗漏。这时候不应该害怕“勾引”起客户的潜在需求而增加设计开发的工作量，从而被今后客户无止境的变更拖入泥潭，直接明白地跟客户把问题和要求一条条地列出来，把条理、归纳、分析先都扔到一边去，将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作。
很明显，假如客户的需求做的都不完整，随时可能会产生意想之外的变更，甚至这个变更会破坏已经做的模型及结构，那么这个项目从开始就注定了会失败；比如站点所有的功能都实现了，本地测试起来也没有什么问题了，但是你却不知道客户的系统是要承受每天100万独立IP的访问，而你原来想当然的以为了不起就是1万独立IP访问的访问流量，稍微有经验的开发人员都会明白这样的设计是个灾难，无论是应用服务器、数据库还是程序全部要重新开发！
二：透过现象分析潜在的需求
很多情况下客户并非专业人士，在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关，这需要我们去为客户进行分析、归纳和整理，尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。
客户往往对需求的概念是非常模糊的，大多时候给出的需求都是笼统而且尺度难以控制的，这就要求业务人员在倾听了客户的详细说明以后，帮助客户进行整理和分析，同时预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。
比如在为客户设计办公自动化系统的时候，也许就要为客户预留将来与他们的业务单位进行交互的通道；在设计邮件系统的时候要考虑可能会需要广告管理服务器；设计网络电子商店时今后增加库存产品进销存统计分析等等；限于时间财力的考虑，客户通常能够接受分阶段实施的开发过程，在需求分析时，提早为客户设想到今后的需求变更除了使项目开发更加顺利以外，也为今后业务的进一步深入打下......>>

问题八：软件需求分析的方法和工具有哪些内容 1. 问卷调查法， 开发方就用户需求中的一些个性化的、需要进一步明确的需求，通过采用向用户发问卷调查表的方式，达到彻底弄清项目需求的一种需求获取方法。这种方法适合于开发方和用户方都清楚项目需求的情况。因为开发方和建设方都清楚项目的需求，则需要双方进一步沟通的需求就比较少，通过采用这种简单的问卷调查方法就能使问题得到较好的解决
2. 会议讨论法 ，开发方和用户方召开若干次需求讨论会议，达到彻底弄清项目需求的一种需求获取方法，这种方法适合于开发方不清楚项目需求（一般开发方是刚开始做这种业务类型的工程项目）但用户方清楚项目需求的情况。因为用户清楚项目的需求，则用户能准确地表达出他们的需求，而开发方有专业的软件开发经验，对用户提供的需求一般都能准确地描述和把握
3. 界面原型法 ，开发方根据自己所了解的用户需求，描画出应用系统的功能界面后与用户进行交流和沟通，通过“界面原型”这一载体，达到双方逐步明确项目需求的一种需求获取的方法。这种方法比较适合于开发方和用户方都不清楚项目需求的情况。因为开发方和用户方都不清楚项目需求，因此此时就更需要借助于一定的“载体”来加快对需求的挖掘和双方对需求理解。这种情况下，采用“可视化”的界面原型法比较可取

⑸ 如何做需求分析

你这个问题问的有点太大了，不知道怎么回答，需求的工作存在很多灵活性，很难整理出一个流程性的东西，我也是正在学习，最近在学习徐峰老师的《软件需求实践》，把我知道的拿出来分享，错了的话请大家纠正，但是不要喷我啊！妹子心里素质不行，嘿嘿
1、需求是有层次的，分为业务需求、用户需求以及系统需求，所以在进行需求分析时肯定是要根据不同层次阶段进行不同方式、内容以及侧重点的需求调研。
1）业务需求，一般是公司的高层提出的，就是我们这个系统的指导需求，这个需求比较空，但是却是整个系统需求的指导思想，在做需求时经常想想这个知道思想，可以防止需求跑偏。

2）用户需求，一般是公司的中层和操作层提出的需求。中层突出流程，就是整个框架，而操作层提出具体的细节性需求。就是往中层的框架里面添加需求细节。

3）系统需求，就是针对前两种需求调研之后得结果进行需求分析和业务建模之后，得到了系统开发的需求。

2、需求的步骤分为：需求定义（对应上面的业务需求）、需求捕获（对应上面的用户需求）、需求分析与需求建模（对应上面的系统需求）、需求验证、需求跟踪、需求管理。

3、做需求工程中可以使用的工具：AXURE（用来制作原型，让用户更直观的了解即将做成什么状态的系统，便于需求确认）、EA（是建模工具，用来绘制UML图，“一图抵千言”为了更好的表达需求和沟通需求）、word、Excel、Visio等工具。

⑹ 项目需求分析的分析方法

需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论.
原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.
原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发.
原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。
在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。
追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。进化型属于这种策略.

⑺ 需求分析的建模分析方法有哪两种

数据库设计需求
1. 需求概述
建立完善的数据库结构管理设备的基本参数、运行状态和各种工作计划。

数据库的框架和结构必须根据设备和运行状态而设计，方便提供强大的录入、查询、统计、分析和报表等各种功能操作，较好的反映平台业务的基本情况和运行状况，满足平台的基本要求。

2. 外部设计需求
2.1 标识符和状态

数据库表前缀：根据模块名定义（如用户模块：sys_）

用户名：root

密码：待定

权限：全部

有效时间：开发阶段

说明：系统正式发布后，可能更改数据库用户/密码。

2.2 使用它的程序

本系统主要利用java作为后端的应用开发工具，使用MySQL作为后台的数据库， Linux或Windows均可作为系统平台。

2.3 约定

所有命名一定要具有描述性，杜绝一切拼音、或拼音英文混杂的命名方式。
字符集采用 UTF-8，请注意字符的转换。
所有数据表第一个字段都是系统内部使用主键列，自增字段，不可空，名称为：id，确保不把此字段暴露给最终用户。
除特别说明外，所有日期格式都采用date格式。
除特别说明外，所有字段默认都设置不充许为空， 需要设置默认值。
所有普通缩影的命名都是表名加设置缩影的字段名组合，例如用户表User中name字段设置普通所以，则缩影名称命名方式为user_name_index。
2.4 专门指导

对本系统的开发者、使用这、测试员和维护人员，提出以下参考意见：

在使用数据库时，首先要参考上面的约定内容，做好软件的安装以及表格的建立。
数据库的输入统一采用键盘。对于数据库的使用权限，请参考本系统其他相关文档。
数据库的后台管理员没用等级差异，可根据实际情况添加删除管理员。
2.5 支持软件

操作系统： Linux / Windows

数据库系统：MySQL

查询浏览工具：Navicat Premium

命令行工具：mysql

注意：mysql 命令行环境下对中文支持不好，可能无法书写带有中文的 SQL 语句。

3. 结构设计需求
3.1 概念结构设计需求

概念数据库的设计是进行具体数据库设计的第一步，概念数据库设计的好坏直接影响到逻辑数据库的设计，影响到整个数据库的好坏。

我们已经得到了系统的数据流程图和数据字典，现在就是要结合数据规范化的理论，用一种模型将用户的数据要求明确地表示出来。

概念数据库的设计应该极易于转换为逻辑数据库模式，又容易被用户所理解。概念数据库设计中最主要的就是采用“实体-关系数据”模型来确定数据库的结构。

数据是表达信息的一种重要的量化符号，是信息存在的一种重要形式。数据模型则是数据特征的一种抽象。它描述的是数据的共性，而不是描述个别的数据。一般来说，数据模型包含两方面内容：

数据的静态特性：主要包括数据的基本结构、数据间的关系和数据之间的相互约束等特性。
数据的动态特性：主要包括对数据进行操作的方法。
在数据库系统设计中，建立反映客观信息的数据模型，是设计中最为重要的，也最基本的步骤之一。

数据模型是连接客观信息世界和数据库系统数据逻辑组织的桥梁，也是数据库设计人员与用户之间进行交流的共同基础。概念数据库中采用的实体-关系模型，与传统的数据模型有所不同。“实体-关系”模型是面向现实世界，而不是面向实现方法的，它主要是用使用方便，因而在数据库系统应用的设计中，得到了广泛应用。“实体-关系”模型可以用来说明数据库中实体的等级和属性。

以下是实体-关系模型中的重要标识：

在数据库中存在的实体；
实体的属性；
实体之间的关系；
3.2 逻辑结构设计需求
物理结构设计需求

1）定义数据库、表及字段的命名规范：

数据库、表及字段的命名要遵守可读性原则。
数据库、表及字段的命名要遵守表意性原则。
数据库、表及字段的命名要遵守长名原则。
2）选择合适的存储引擎：
3）为表中的字段选择合适的数据类型。

4）建立数据库结构

4. 运用设计需求
4.1 表名的命名规范

表名以英文单词、单词缩写、简写、下划线构成，总长度要求小于30位。

4.2 表字段的命名规范

字段名以英文单词、单词缩写、简写、下划线构成，总长度要求不超过30位。
字段名以名词或名词短语，字段采用单数形式。若表名由多个单词组成，则取各个单词的缩写组成，单词缩写间使用下划线作为分隔。
若某个字段是引用某个表的外键，则字段名应尽量与源表的字段名保持一致，一面混淆。
5. 安全保密设计需求
5.1 防止用户直接操作数据库的方法

通过把关键应用服务器和数据库服务器进行分离，防止用户对数据库服务器的直接操作，保证数据库安全。

5.2 应用系统的用户口令进行加密

在软件系统中，对于数据的保护、业务操作的许可是通过识别用户身份和权限来完成的。用户口令相比较，相同的话系统将该用户的操作权限分配给用户，用户再根据所分配的权限对系统进行操作。

由以上过程可知，用户口令在传输过程中容易被窃取泄漏，另外如果数据库被非法进入则其中保存的口令能够被非法查看。因此，在传输过程中和数据库中的口令记录字段不应使用明文传递和保存，应该在口令被传递前对其明文口令使用有效的主流技术，对传输数据进行加密部分描述的加密算法进行加密，在加密后传输到系统。系统将用户提交的经过加密的口令数据保存的加密口令进行比较，相一致则进行后续操作。

⑻ 产品需求和需求分析

1.需要 VS 需求
需要：用户要解决的问题或者要满足的欲望，我们定义为需要。
需求：为解决用户的问题或者满足用户欲望而产生的产品或功能，我们称之为需求
上面这个故事中，客户孙拍想要更短的时间到达目的地，这是需要；想要一匹更快的马，这是需求。再比如，想听歌是人们的需要，想要一个随身听设备是需求。所以往往人们所表达出来的需求，不一定能更好的满足人们的需要。好的产品经理一定深谙其道，所以福特去造车，乔布斯做ipod。
2.用户的解决方案 VS 产品解决方案
在没有汽车之前，用户能想到的更快到达远方的工具是日行千里夜行八百的千里马。想要一匹千里马，这是用户提出的解决方案。福特制造汽车来更好的满足用户需求，这是产品解决方案，这里注意用词“更好的满足”。解决方案没有唯一性，先有汽车，后有飞机高铁，没有最好只有更好。用户提出的解决方案不一定不可取，也不一定不能满足用户的需要。在没有汽车飞机高铁之前，或许马匹就是最合适的解决方案。
用户的解决方案：用户自己思考要满足自己需要或欲望而想出来的办法，不同的用户对于相同的问题往往提供的解决方法不一样，和用户的知识、经验、紧迫程度有关。

产品的解决方案：通过一系列的功能、内容或者服务的组合，满足用户需要的手段。产品是功能、内容或者服务的聚合。

3.需求分类
在产品战略层（《用户体验要素》），要回答两个问题：a.我们要通过这个产品得到什么？b.用户能通过这个产品得到什么？
前者是公司的业务目标，是商业属性；后者是用户体验目标。因此，我们将需求分为业务需求和用户需求两类。
a.业务需求=业务目的+业务目标
业务目的是我们为什么要做这块业务，社会或市场存在的问题是什么。业务目标时做了这个产品后，希望得到什么成果。
比如小米做最好性价比的智能手机，因为智能手机要么很贵如苹果三星，要么质量或者用户体验不太好，所以小米的定位要做一款性价比高的手机产品。
那小米想通过这个产品得到什么呢？小米公布的2018年财报，硬件税后净利率小于1%，手机和其他硬件产品都是小米的现金流抓手。商业嘛，最终都是要挣钱的，可能这款产品不直接挣钱或者持续烧钱，但它在战略中承担某一环节的作用，为整体生态提供养分。正如小米这种生态型公司，每款产品的商业目的（定位）都不一样，结合起来就是一张完整版图。
所以，我们去分析一个产品的业务需求时，不要只看到产品的点，要向上看一看，看到公司布局看到战略，这样可以更好的帮产品经理理解业务需求。
b.用户需求=目标用户+场景+行为+用户体验目标
不要脱离使用主题（目标用户）谈产品解决方案则模羡，也不能脱离用户的使用场景（场景有很自然的存在，如开车听歌；也可以营造，比如双11），用户行为和场景是关联的，这些连贯起来就是什么人在什么场景下做出什么行为，想要达成什么目标。产品的解决方案是要把这些做到自然连贯，把用户需求和业务需求更好码歼地融合起来。
这里的重点是，任何产品都是人在用，产品的目标是解决人的问题。脱离人这个主体谈需求、谈方案，那就是空谈。我们常常战术上很勤奋，为什么会改了一版又一版？决策者把大把时间花在竞争对手的产品功能研究上，想借鉴别人的解决方案来解决自己的问题，就是不愿意花时间调研自己的用户，基于冥想，而不是基于真实。
几乎所有的成功产品都做到了“用户体验第一”，他们的产品有超高的粘性，源于对用户的尊重，为用户打造极致的满足感，而不是去堆砌功能。
什么是场景？
梁宁的解释是：要把场景拆开，场和景。
“场”是时间和空间的概念，一个场就是时间加空间。用户愿意在某个时间段在这个空间里停留和消费，如果一个人不能在某个空间去停留、消费，这个场就是不存在的。
“景”是情景和互动。当用户停留在这个空间的时间里，要有情景和互动让用户的情绪触发，并且裹挟用户的意见，这就是场景。
按照这个定义，在电商或者零售中常说的人货场，这个场绝不仅仅是指卖东西的地方，更多的可以理解为场景。除了空间，它还有时间、有用户的心情、有当下的交互体验。如果服务没法与人紧密连接，那它一定是冰冷的，没有粘性的服务，最终只会有损于商业目标。

需求采集的方法
被动获取：
a.用户反馈,含产品内反馈、服务评价、app评分、网络留言（如微博）、投诉等
b.同事或朋友的反馈
c.竞争对手，含产品功能、市场动态等
d.市场和监管，含政策性要求，如滴滴车内录像录音
e.领导输出

主动发现
主动发现分为定量和定性两种方法。
定性：判断是什么叫定性，定性分析一般用于趋势判断
定量：判断有什么叫定量，定量分析一般用于量化定性结论
举例：下雨天外卖订单会增长，这个是定性，表明下雨这个外因和外卖单量的增长存在关系；下雨天外卖订单会增长40%，这个是定量，有具体的数据可以量化下雨和外卖单量增长的关系。

1.需求分析的方法
需求分析是一个针对采集到的需求，通过合理性评估，筛选过滤伪需求、提炼归纳合并真需求，并评估优先级的过程。总结就是去伪求真，把留下的真需求排定一个实现的优先级的过程。需求采集后，面对一堆杂乱无章的，各式各样的，不同目的的需求，先明确需求合理性评估原则
1）合规（法律、政策、行业规范等），企业不能违法，不能做不符合法律法规、道德要求的产品。明令禁止的不可打擦边球。
2）战略协同（符合公司愿景或阶段性战略目标）战略类需求基本上是自上而下的指令
，产品经理需要与高层沟通清楚，不要出现理解偏差、执行偏差，要A给B，要A给a，执行不到位。
比如，某电商目前是纯自营B2C,管理层决定做个开放平台，让其他商家也接入平台，共享数据、渠道等资源，从单一商家的B2C发展成多商户平台型电商，这个转型就是战略需求。再比如，去年创业公司的营收是1个亿，净亏损2000万，今年的目标是扭亏为盈，这是公司发展战略。公司的一些战略常常会反应在比较细的产品需求之中。如DAU提升a%，转化率提升b%deng，这类属于自上而下产生的KPI分解到产品路径上产生的需求。
3）需求真伪的评估首先不要站在自己角度理解用户需求。如果不是基于用户的真实需要，真实的使用场景来判断需求，不靠谱的概率会很大。
4）价值成本评估主要是2个方面的评估：
a.给企业带来什么价值，给用户带来什么价值。很多电商都做会员做积分，企业的需要是用户粘性，是留存。对于用户来说，积分可以兑换礼品，或当钱花，做得好就是一个双赢的需求决策。
b.实现要付出多少成本。这里的成本不仅是研发的人力投入、时间周期的费用。达成目标的方法可能很多，为什么是A而不是B，AB方案的差异、优劣、价值和成本需要对比，只要能达成目标，方案越简单越好。
5）技术可行性评估。理论上技术可行性更多是时间周期的问题。需要设计人员了解一些技术，否则容易导致返工。
在完成需求合理评估后，剩下的需求应都是合理的、真实的、有目标的、可实现的需求了。我们对这些需求再进一步分组归类，用于更好的帮我们理解需求。

需求分析方法1：卡诺模型

*注意：
1）五种需要像阶梯一样从低到高，按层级逐级递升，但这样的次序不是完全固定的，可以变化。
2）需求层次理论有两个基本出发点，一是人人都有需要，某层需求获得满足后，另一层需要才出现；二是在多种需求未获满足前，首先满足迫切需要；该需要满足后，后面的需要才显示出其激励作用。
3）一般来说，某一层次的需要相对满足了，就会向高一层次发展，追求更好一层次的需要就称为驱使行为的动力。相应的，获得基本满足的需要就不再是一股激励力量。
4）五中需要可以分为两级，其中生理上的需要、安全上的需要和感情上的需要都属于低一级的需要，这些需要通过外部条件可以满足；而尊重的需要和自我实现的需要是高级需要，他们是通过内部因素才能满足的，而且一个人对尊重和自我实现的需要是无止境的。
面对杂乱无序的各类需求，设计者首先要做的是重建需求秩序，就像手里抓了一把杂粮，先把小米、大米、麦子分开归类、这样我们才能更好的观察、研究这些需求的本质意义。

2.优先级评估方法
优先级评估方法1：需求分级法
卡诺模型、马斯诺模型等已经对需求做了大概分组，可按层级逐步满足用户。对于卡诺模型，先满足基本型需求，在满足期望型需求，最后是兴奋型需求；对于马斯诺模型，先满足低层次的需求。

2）用户基本需求没有满足，紧急重要
3）产品的核心指标不满足，影响公司营收和成本，目标导向型需求，紧急重要。如为提高注册激活率而优化注册流程，为提高DAU而做的每日签到抽奖。
4）战略型需求，可能是紧急重要，也可能是重要但不紧急。看需求目标是什么，狙击竞争对手的一般都是紧急；公司已处于行业领先地位，且需进一步加深护城河的，一般都重要，但没那么着急。
5）业务痛点问题，不解决难以做事，效率低下。一般2B类产品居中，需求偏管理、流程。企业内部的运作效率都很重要，是否紧急要看具体需求。

优先级评估方法3：威格斯公式。在《软件需求》一书中，作者介绍了一种需求优先级量化的办法，这里简单介绍一下。
优先级=价值%/（成本%+风险%）
收益：实现需求带来的收益
损失：不实现需求有什么损失
成本：实现需求要花费的成本
风险：实现需求要承担的风险
举例：对R1-R4四个需求要排定优先级
计算步骤：
1、设置相对收益的权重为2，相对损失的权重为1，相对成本的权重为1，相对风险的权重为0.5。这个权重可以根据公司的实际情况来设定，如刚起步的创业项目，没有太多业绩包袱，成本和风险相对较小，无非就是时间、几个人员投入、一点点钱，但是做成功的话收益就会很好，所以相对收益就设置大一些。对于成熟的项目，业务体量可能很大了，做任何需求可能获得的相对收益都小，而风险可能会大一些。
2、录入R1-R4的相对收益、相对损失、相对风险，并在表中对R1-R4的各项指标求和。这里的值都是相对的，可以以R1为基准，或找一个已经实现的需求R0当参考，用R1-R4与R0对比。表中是以一个已经实现的需求R0为参照。
3.计算总价值和相对价值占比（价值%）。R1总价值=R1相对收益 相对收益权重+R1的相对损失 相对损失权重=2 2+4 1=8。R2-R4同理。然后求总价值∑R=R1的总价值+R2总价值+...Rn总价值。Rn价值%=Rn总价值/∑R
4.计算各需求的相对成本占比（成本%）、相对风险占比（风险%）
5.计算优先级系数a=价值%/（成本%+风险%），最终得出优先级结论R2>R1>R4>R3

威格斯公式法的好处是量化了需求优先级，从价值、损失、成本、风险四个维度综合评估需求，相对来说比四象限法更理性一些。但从实际工作中情况看，决定需求优先级的因素很多，以上办法能帮设计者更好的理解需求价值，弱化噪音干扰，更聚焦需求本身。

完全照搬方法亦不可取，市场瞬息万变，善用数据，把握时机更重要