需求分析报告

需求分析报告。

通常来讲，有付出就会有收获，毕业踏上工作岗位以后，我们会经常使用到报告。我们在写报告的时候需要注意哪些呢？下文将为您介绍关于“需求分析报告”的详细信息，请将此页收藏以便您下次访问！

需求分析报告【篇1】

软件需求 需求工程 分析建模 需求管理 本章小结 学习目标

本章介绍需求分析的意义概念和方法了解结构化分析方法和需求管理的关键活动要求学会运用实体关系图数据流图和状态控制图进行结构化分析建模能够编写软件需求规格说明 学习方法

正确理解需求工程涉及的基本概念结合具体实例运用结构化分析技术从而达到理论学习及在实际项目中应用的目的 难重点

本章的学习重点在于理解软件需求的概念和重要性熟悉需求开发和需求管理的基本思想和主要活动掌握结构化的分析方法难点是怎样在实际的软件项目中灵活运用这些思想和方法 课前思考 软件需求存在什么问题 什么是软件需求 什么是需求工程 常见的需求分析方法是什么 需求分析的结果可以验证吗 需求规格说明有什么质量要求

本节知识点 软件需求的定义 需求的层次 导致需求缺陷的原因

随着计算机技术的飞速发展软件已经成为人们生活中不可缺少的一部分人们在使用软件的过程中常常会抱怨它无法执行某些基本操作但对于软件开发人员而言用户不断提出新的要求是一件多么烦人的事

其实在软件开发过程中遇到的许多问题都是由于收集编写协商修改软件需求过程中的失误带来的诸如信息收集不全功能不明确交流不充分文档不完善需求发生变化等可以这样说软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”

开发软件系统最为困难的部分就是准确说明开发什么最为困难的概念性工作便是编写详细的技术需求包括所有面向用户面向机器和其它软件系统的接口

IEEE软件工程标准词汇表将需求定义为

1用户解决问题或达到目标所需的条件或能力

2系统或系统部件要满足合同标准规范或其它正式规定文档所需具有的条件或能力

3一种反映上面1或2所描述的条件或能力的文档说明

下面列出其他几种关于需求的定义 需求是用户所需要的并能触发一个程序或系统开发工作的说明 需求是从系统外部能发现系统所具有的满足于用户的特点功能及属性等 需求是指明必须实现什么的规格说明它描述了系统的行为特性或属性是在开发过程中对系统的约束

软件需求包括四个不同的层次即业务需求用户需求和功能需求另外还有非功能需求

软件需求各组成部分之间的关系如下图所示

业务需求 反映了组织机构或客户对系统或产品高层次的目标要求它们在项目视图与范围文档中予以说明

用户需求

描述了用户使用产品必须要完成的任务可以在用例模型或方案脚本中予以说明

功能需求

定义了开发人员必须实现的软件功能使得用户能完成他们的任务从而满足了业务需求 非功能需求

是从各个角度对系统的约束和限制反映了应用对软件系统质量和特性的额外要求

非功能需求包括过程需求产品需求和外部需求三类其中过程需求有交付实现方法和标准等需求产品需求包含性能可用性实用性可靠性可移植性安全保密性容错性等方面的需求外部需求有法规成本操作性等需求

需求工程中的缺陷将给项目的成功带来极大风险导致缺陷的原因主要包括以下方面 缺乏足够的用户参与

客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫开发人员可能也不重视用户的参与究其原因一是因为与用户合作不如编写代码有意思二是因为开发人员觉得已经明白用户的需求了在某些情况下与实际使用产品的用户直接接触很困难而客户也不太明白自己的真正需求然而在项目的早期让具有代表性的用户直接参与到开发队伍中并一同经历整个开发过程很重要

用户需求不断增加

在开发过程中用户需求经常发生变化但是不断的变更会使其整体结构越来越乱整个程序也难以理解和维护如果要减少需求变更的影响范围就必须在项目的开始对项目视图范围目标约束限制和成功标准给予明确说明并将此说明作为评价需求变更和新特性的参照框架

需求模棱两可

模棱两可是需求规格说明中最严重的问题它意味着不同的人对需求说明产生了不同的理解或者是同一个人能用不止一个方式来解释某项需求说明模棱两可的需求带来的后果便是返工--重做一些你认为已做好的事情返工会耗费开发总费用的40而70～85的重做是由于需求方面的错误引起的添加不必要的特性

有时候开发人员力图增加一些“用户欣赏”但需求规格说明中并未涉及的新功能然而常常是用户并不认为这些功能性很有用开发人员应当为客户构思方案并为他们提供一些具有创新意识的思路具体提供哪些功能要在客户的需要和允许时限内的技术可行性之间求得平衡

规格说明过于简单

客户往往不明白需求分析的重要性只是提供一份十分简略的规格说明仅涉及产品概念上的内容然后让开发人员在项目进展中去完善从而导致开发人员先建立产品结构再完成需求说明

忽略了用户分类

大多数产品是由不同的人使用其不同的特性使用频繁程度也有所差异使用者受教育程度和经验水平也不尽相同如果你不能在项目早期就针对所有这些主要用户进行分类的话必然导致有的用户对产品感到失望

总体来说导致需求缺陷的原因主要体现在三个方面 需求的沟通与理解 需求的变化与控制 需求说明的明确与完整 需求工程中的缺陷将给项目成功带来极大风险如产品的成本过高产品的功能和质量无法完全满足用户的期望等等即使一个项目团队的人员和配备都很不错但不重视需求过程也会付出惨痛的代价

本节知识点 需求工程的内容 需求获取 需求分析 编写需求文档 需求验证

需求工程是指应用已证实有效的原理和方法系统地描述出待开发系统及其行为特征和相关约束

通常需求工程由一些过程组成可分为需求开发和需求管理两部分

需求开发的主要活动 确定产品所期望的用户类 获取每个用户类的需求 了解实际用户任务和目标以及这些任务所支持的业务需求 分析源于用户的信息以区别用户任务需求功能需求业务规则质量属性建议解决方法和附加信息

将系统级的需求分为几个子系统并将需求中的一部份分配给软件组件 了解相关质量属性的重要性 商讨实施优先级的划分 将所收集的用户需求编写成规格说明和模型 评审需求规格说明确保对用户需求达到共同的理解与认识并在整个开发小组接受说明之前将问题都弄清楚

需求管理的主要活动 定义需求基线 评审提出的需求变更评估每项变更的可能影响从而决定是否实施它 以一种可控制的方式将需求变更融入到项目中 使当前的项目计划与需求一致 估计变更需求所产生影响并在此基础上协商新的承诺 让每项需求都能与其对应的设计源代码和测试用例联系起来以实现跟踪 在整个项目过程中跟踪需求状态及其变更情况

今天我们引入“需求工程”的概念强调用工程化的方法进行需求开发和需求管理其中需求开发是采用有效方法获得高质量需求的过程而需求管理则是在需求说明形成之后有效地控制其变更的过程二者缺一不可

一工作内容 聆听用户的需求 分析和整理所获取的信息 形成文档化的描述 二基于用例的方法

随着面向对象技术的发展基于用例的方法在需求获取和建模方面应用得越来越普遍这种方法是以任务为中心和以用户为中心的比起使用以功能为中心的方法它可以使用户更清楚地认识到新系统允许他们做什么

用例模型以用户和任务为中心将整个工作的焦点集中在从用户的角度说明系统能够干什么完全不考虑具体的实现细节从而达到准确地理解客户需求的目的在用例模型中角色和用例是两个基本概念分别代表着系统外部的执行者和系统应包含的功能因此建立用例模型的主要工作是确定角色确定用例和描述用例 A确定角色

角色代表着与系统交互的人或事通过确认系统功能使用者和维护者以及与系统接口的其他系统或硬件设备等可以有效地识别出系统角色 B确定用例

一个完整的系统包含若干个用例每个用例具体说明应完成的功能识别用例首先要确定系统所能反映的外部事件并把这些事件与参与的执行者和特定的使用实例联系起来最终绘制出用例图 C描述用例

单纯地使用用例图不能提供用例所具有的全部信息因此需要使用文字描述那些不能反映在图形上的信息用例描述实际上是关于角色与系统如何交互的规格说明要求清晰明确没有二义性

建立用例模型是一种需求获取的有效方法其简洁清晰的描述方式容易被软件人员和用户共同理解和接受这种方法已经在许多大型系统的开发中取得成效实践证明它能有效地解决用户参与的问题

需求分析主要是对收集到的需求进行提炼分析和仔细审查以确保所有的风险承担者都明白其含义并找出其中的错误遗漏或其它不足的地方形成完整的分析模型分析的目的在于开发出高质量的和具体的需求从而支持项目的估算和软件的设计开发和测试

需求分析的主要活动包括 绘制系统关联图 创建用户接口原型 分析需求可行性 确定需求的优先级别 创建数据字典 为需求建立模型

绘制系统关联图

这种关联图用于定义系统与系统外部实体间的界限和接口的简单模型

创建用户接口原型

当开发人员或用户不能确定需求时开发一个用户接口原型可以使许多概念和可能发生的事更为直观明了用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题同时找出需求文档与原型之间所有的冲突之处 分析需求可行性

在允许的成本和性能要求下分析每项需求实施的可行性明确与每项需求实现相联系的风险包括与其它需求的冲突对外界因素的依赖和技术障碍

确定需求的优先级别

应用分析方法来确定用例产品特性或单项需求实现的优先级别以优先级为基础确定产品版本将包括哪些特性或哪类需求当允许需求变更时在特定的版本中加入每一项变更并在那个版本计划中作出需要的变更 为需求建立模型

需求的图形分析模型是软件需求规格说明极好的补充说明它们能提供不同的信息与关系以帮助找到不正确的不一致的遗漏的和冗余的需求这些模型包括数据流图实体关系图状态变换图对话框图对象类及交互作用图等 创建数据字典

数据字典是对系统用到的所有数据项和结构的定义以确保开发人员使用统一的数据定义在需求阶段数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语

分析建模的方法有很多其中最重要的两种方法是结构化分析和面向对象分析 结构化分析方法提供实体关系图数据流图和状态转换图三种图形模型分别进行数据建模功能建模和动态建模

人们习惯于用自然语言来描述软件需求但这会产生许多意想不到的问题如不精确二义性等因此需要采用适当的方法形成一致的完备的和无二义性的软件需求规格说明

通常编写软件需求规格说明有三种方法 将结构化语言与自然语言结合编写文本型文档 建立可视化的模型 采用形式化的方法进行需求规格说明

软件需求规格说明是需求开发的最终结果它精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件软件需求规格说明不仅是系统测试和用户文档的基础也是所有子系列项目规划设计和编码的基础

软件需求规格说明是用户分析人员和设计人员之间进行理解和交流的手段 测试人员可以根据软件需求规格说明中对产品行为的描述制定测试计划测试用例和测试过程 文档人员根据软件需求规格说明和用户界面设计编写用户手册等 软件需求规格说明指导着整个系统的开发过程评审过的需求规格说明需要进行变更控制

a 引言

概要叙述软件需求规格说明便于读者理解文档如何编写以及如何阅读和解释

在软件项目中开发组织应该采用一种标准的软件需求规格说明的模板现在有许多软件需求规格说明模板可以使用这里介绍其中的一种 a1 目的

对产品进行定义在该文档中详尽说明了这个产品的软件需求包括修正或发行版本号如果这个软件需求规格说明只与整个系统的一部分有关系那么就只定义文档中说明的部分或子系统 a2 文档约定

描述编写文档时所采用的标准或排版约定包括正文风格提示区或重要符号

a3 预期的读者和阅读建议

列举了软件需求规格说明所针对的不同读者例如开发人员项目经理营销人员用户测试人员或文档的编写人员描述了文档中剩余部分的内容及其组织结构提出了最适合于每一类型读者阅读文档的建议 a4 产品范围

提供了对指定的软件及其目的的简短描述包括利益和目标 a5 参考文献

列举了编写软件需求规格说明时所参考的资料或其它资源可能包括用户界面风格指导合同标准系统需求规格说明使用实例文档或相关产品的软件需求规格说明在这里应该给出详细的信息包括标题名称作者版本号日期出版单位或资料来源以方便读者查阅这些文献 b 综合描述

这一部分概述了正在定义的产品以及它所运行的环境使用产品的用户和已知的限制假设和依赖 b1 产品的前景

描述了软件需求规格说明中所定义的产品的背景和起源说明了该产品是否是产品系列中的下一成员是否是成熟产品所改进的下一代产品是否是现有应用程序的替代品或者是否是一个新型的自含型产品如果软件需求规格说明定义了大系统的一个组成部分那么就要说明这部分软件是怎样与整个系统相关联的并且要定义出两者之间的接口 b2 产品的功能

概述了产品所具有的主要功能其详细内容将在d中描述所以在此只需要概略地总结例如用列表的方法给出很好地组织产品的功能使每个读者都易于理解用图形表示主要的需求分组以及它们之间的联系例如数据流程图的顶层图或类图都是有用的 b3 用户类和特征

确定你觉得可能使用该产品的不同用户类并描述它们相关的特征有一些需求可能只与特定的用户类相关将该产品的重要用户类与那些不太重要的用户类区分开 b4 运行环境

描述了软件的运行环境包括硬件平台操作系统和版本还有其它的软件组件或与其共存的应用程序 b5 设计和实现上的限制

确定影响开发人员自由选择的问题并说明这些问题为什么成为一种限制可能的限制包括如下内容

必须使用或者避免的特定技术工具编程语言和数据库 所要求的开发规范或标准 企业策略政府法规或工业标准 硬件限制例如定时需求或存储器限制 数据转换格式标准 b6 假设和依赖

列举出在对软件需求规格说明中影响需求陈述的假设因素以及项目对外部因素存在的依赖 c 外部接口需求

利用本节来确定可以保证新产品与外部组件正确连接的需求 c1 用户界面

陈述所需要的用户界面的软件组件描述每个用户界面的逻辑特征以下是可能要包括的一些特征

将要采用的图形用户界面 G U I标准或产品系列的风格 屏幕布局或解决方案的限制 将出现在每个屏幕的标准按钮功能或导航链接例如一个帮助按钮 快捷键 错误信息显示标准

c2 硬件接口

描述系统中软件和硬件每一接口的特征这种描述可能包括支持的硬件类型软硬件之间交流的数据和控制信息的性质以及所使用的通信协议 c3 软件接口

描述该产品与其它外部组件由名字和版本识别的连接包括数据库操作系统工具库和集成的商业组件明确并描述在软件组件之间交换数据或消息的目的描述所需要的服务及内部组件通信的性质确定将在组件之间共享的数据 c4 通信接口

描述与产品所使用的通信功能相关的需求包括电子邮件Web浏览器网络通信标准或协议及电子表格等等定义了相关的消息格式规定通信安全或加密问题数据传输速率和同步通信机制 d 系统特性 d1 说明和优先级

简短说明该系统的特性并指出该特性的优先级是高中还是低另外还可以包括对特定优先级部分的评价例如利益损失费用和风险 d2 激励响应序列

列出输入激励用户动作来自外部设备的信号或其它触发器和定义这一特性行为的系统响应序列 d3 功能需求

详列出与该特性相关的详细功能需求这些是必须提交给用户的软件功能使用户可以使用所提供的特性执行服务或者使用所指定的使用实例执行任务 e 其他非功能需求 e1 性能需求

阐述了不同的应用领域对产品性能的需求并解释它们的原理以帮助开发人员作出合理的设计选择确定相互合作的用户数或者所支持的操作响应时间以及与实时系统的时间关系 e2 安全设施需求

详尽陈述与产品使用过程中可能发生的损失破坏或危害相关的需求定义必须采取的安全保护或动作还有那些预防的潜在的危险动作明确产品必须遵从的安全标准策略或规则 e3 安全性需求

详尽陈述与系统安全性完整性或私人问题相关的需求这些问题将会影响到产品的使用和产品所创建或使用的数据的保护定义用户身份确认或授权需求明确产品必须满足的安全性或保密性策略 e4 软件质量属性

详尽陈述与客户或开发人员至关重要的其它产品质量特性这些特性必须是确定定量的并在可能时是可验证的 e5 业务规则

列举出有关产品的所有操作规则例如什么人在特定环境下可以进行何种操作这些本身不是功能需求但它们可以暗示某些功能需求执行这些规则 e6 用户文档

列举出将与软件一同发行的用户文档部分例如用户手册在线帮助和教程明确所有已知的用户文档的交付格式或标准 f 其他需求

定义在软件需求规格说明的其它部分未出现的需求例如国际化需求或法律上的需求你还可以增加有关操作管理和维护部分来完善产品安装配置启动和关闭修复和容错以及登录和监控操作等方面的需求这一部分可以省略

需求验证是为了确保需求说明准确完整地表达必要的质量特点当你阅读软件需求规格说明时可能觉得需求是对的但实现时却很可能会出现问题当以需求说明为依据编写测试用例时你可能会发现说明中的二义性而所有这些都必须改善因为需求说明要作为设计和最终系统验证的依据

正确性 完整性 可验证性 无二义性 可修改性 可跟踪性 一致性

审查需求文档

对需求文档进行正式审查是保证软件质量的有效方法组织一个由不同代表如分析人员客户设计人员测试人员组成的小组对SRS及相关模型进行仔细的检查

以需求为依据编写测试用例

根据用户需求所要求的产品特性写出黑盒功能测试用例客户通过使用测试用例以确认是否达到了期望的要求从测试用例追溯回功能需求以确保没有需求被疏忽并且确保所有测试结果与测试用例相一致同时要使用测试用例来验证需求模型的正确性如对话框图和原型等

编写用户手册

在需求开发早期即可起草一份用户手册用它作为需求规格说明的参考并辅助需求分析 确定合格的标准

让用户描述什么样的产品才算满足他们的要求和适合他们使用的将合格的测试建立在使用情景描述或用例的基础之上

需求验证包括需求评审和需求测试两个部分需求评审又包括正式的和非正式的两种形式

需求评审是一种有效的需求验证手段通常以用例模型为基础编写测试用例进行检验虽然没有在运行系统上执行测试用例但是设计测试用例的过程可以解释需求的许多问题

本节知识点 分析模型--实体关系图数据流图状态转换图 数据字典 结构化分析过程

多年来人们提出了许多分析建模的方法其中占主导地位的两种方法是传统的“结构化分析”方法和当今流行的“面向对象的分析”方法本节重点介绍结构化分析方法面向对象的分析方法在后面章节介绍

需求分析产生的模型使人们可以更好地理解将要建造的系统它有助于系统分析员理解系统的信息功能和行为成为确定需求规格说明完整性一致性和精确性的重要依据奠定了软件设计的基础

结构化分析导出的分析模型包括数据模型功能模型和行为模型该模型以数据字典为核心描述了软件使用的所有数据对象围绕这个核心的是实体关系图数据流图和状态转换图具体形式如下图所示 实体关系图ER数据建模的基础描述数据对象及其关系 数据流图DF功能建模的基础描述数据怎样转换以及转换的功能 状态转换图ST行为建模的基础表示系统的各种行为状态以及状态间的转换方式 数据模型包括三种基本元素 数据对象 属性 关系 它们对理解问题的信息域提供了基础

两个数据对象之间有以下三种关联ER在数据对象之间的连线上用数字或字母表示

一对一11对象 A的一个实例只能关联到对象B的一个实例对象 B的一个实例也只能关联到对象A的一个实例如一个丈夫只能有一个妻子一个妻子也只能有一个丈夫

一对多1N对象 A的一个实例可以关联到对象B的一个或多哥实例而对象 B的一个实例只能关联到对象A的一个实例如一个母亲可以有多个孩子而一个孩子只能有一个母亲

多对多MN对象 A的一个实例可以关联到对象B的一个或多个实例同时对象 B的一个实例也可以关联到对象A的一个或多个实例如一个叔叔可以有多个侄子一个侄子也可以有多个叔叔

数据建模的其他图形工具层次方框图

层次方框图通过树型结构的一系列多层次的矩形框描述复杂数据的层次结构树型结构顶端的矩形框只有一个用于代表完整的数据结构下面各层的矩形框是对完整数据结构的逐步分解和细化得到的数据子集底层的矩形框代表组成该数据结构的基本元素是数据的最小单位不可再分割

数据建模的其他图形工具层次方框图 层次方框图非常适合描述自顶向下的需求分析方法中数据的层次关系系统分析员可以从对顶层信息的分类开始沿着层次图中的每条路径逐步细化直到确定了数据结构的全部细节为止

例如某单位职工的实发工资由应发工资和扣款两部分组成每部分又可进一步细分如应发工资又可分为基本工资和奖金基本工资又可分为国家工资津贴补贴奖金也可分为出勤奖和业绩奖津贴和补贴还可以再进一步地细分 实发工资的层次方框图如下图所示

数据流图是结构化分析的基本工具它描述了信息流和数据转换通过对加工进行分解可以得到数据流图

DF有四种元素其基本符号如下图所示

外部实体与系统进行交互但系统不对其进行加工和处理的实体用带标记的矩形表示 加工对数据进行的变换和处理用带标记的圆圈表示 数据流在数据加工之间或数据存储和数据加工之间进行流动的数据用带标记的箭头表示 数据存储在系统中需要存储的实体用带标记的双实线表示

第0层DF称为基本系统模型可以将整个软件系统表示为一个具有输入和输出的黑匣子用一个圆圈表示上一层DF中的每一个圆圈可以进一步扩展成一个独立的数据流图以揭示系统中程序的细节部分

这种循序渐进的细化过程可以继续进行直到最低层的图仅描述原子过程操作为止每一层数据流图必须与它上一层数据流图保持平衡和一致因此子图的所有输入输出流要与其父图相匹配

状态转换图通过描述状态以及导致系统改变状态的事件来表示系统的行为它没有表示出系统所执行的处理只表示了处理结果可能的状态转换

ST用带标记的圆圈或矩形表示状态用箭头表示从一种状态到另一种状态的变换箭头上的文本标记表示引起变换的条件 例如在操作系统中当存在多个申请占用CPU运行的进程 进程是分配CPU的最小处理单位 时系统将按照某种调度策略为各个进程分配CPU此时进程的状态可能有三种就绪运行和等待 就绪等待分配CPU 运行占用CPU进行相应的处理 挂起

name=baidusnap1>

放弃CPU的使用

数据流图是结构化分析的基本工具体现了自顶向下逐步求精的分析过程确定了系统的任务流和数据流 实体关系图描述了系统的数据关系从而帮助开发人员分析和理解系统数据的组成并为系统设计阶段定义系统数据库的物理结构打下基础 状态转换图描述了系统状态之间的变化过程它对于实时系统和控制系统尤为重要

数据字典描述数据流图的数据存储数据加工 最底层加工和数据流它记录的主要内容有 基本信息名字别名描述 定义数据长度数据类型数据结构 使用特点取值范围使用频率使用方式等 控制信息来源用户引用程序读写权限等 其他说明

在数据字典中数据元素的定义可以是基本元素及其组合数据进行自顶向下地分解直到不需要进一步解释且参与人员都清楚其含义为止

数据组合有三种方式

顺序以确定的次序连接多个数据项

选择从多个数据项中选取一个

重复将某个数据项重复多次 为了能够对数据流中的各组成成分进行准确的定义在数据字典中使用了多种具有特定意义的符号如下

结构化分析过程实质上就是创建数据模型功能模型和行为模型其中数据建模的工具是实体关系图功能建模的工具是数据流图行为建模的工具是状态转换图另外使用数据字典定义系统的所有数据项

为了理解和学会使用这些建模工具我们结合一个学生成绩管理系统的实例讲解整个分析过程并给出部分实体关系图数据流图状态转换图和数据字典

下面列出用户对学生成绩管理系统的要求 教务人员录入学生信息课程信息和成绩信息 学生可以随时查询自己所选课程的成绩 由于学生成绩属于敏感信息系统必须提供必要的安全措施以防非法存取

在需求收集的过程中要求客户列出应用软件或业务过程涉及到的“事物”将其演化成数据对象 一次考虑一个对象分析员和客户定义这个对象和其他对象之间是否存在连接 如果存在连接应创建一个或多个关系

对每一个关系确定其关联类型

重复步骤2到步骤4直到定义了所有关系

定义每个实体的属性

形式化并复审实体关系图 重复步骤1到7直到数据建模完成

实例分析 学生成绩管理系统 实体学生课程成绩 实体属性定义

学生学号姓名性别出生日期入学年月

课程课程编号课程名称课程学分课程描述

成绩学号课程编号分数考核日期

显然学生课程和成绩都是系统的实体并且可以初步定义它们的属性

教务人员虽然是系统的用户但其信息与系统处理无关因此不用作为实体 由于成绩信息包含了选课信息因此选课信息不用单独记录

因此系统的实体是学生课程和成绩

我们分析这些实体之间的关联关系从实际情况得知一个学生可以选多门课程一门课程也可以有多个学生选修但每个学生选一门课程必须有一个成绩根据上述分析我们得到如图所示的实体关系图

实体关系图

通常数据流图是分层绘制的整个过程反映了自顶向下进行功能分解和细化的分析过程 顶层也称第0层DF用于表示系统的开发范围以及该系统与周围环境的数据交换关系 最底层DF代表了那些不可进一步分解的原子加工 中间层DF是对上一层父图的细化其中的每一个加工可以继续细化中间层次的多少由系统的复杂程度决定

第0层DF将整个系统表示成一个加工 2 确定并标记主要的输入和输出 分离出下一层中的加工数据对象和存储 并对其进行细化一次细化一个加工 4 标记所有加工和箭头 重复步骤3和4直到所有的加工 只执行一个简单的操作可以很容易地用 程序实现

绘制第0层DF的时候将整个系统看成一个加工然后找出作用于该加工的外部实体以及相应的数据输入和输出

绘制下一层数据流图时细化第0层的加工从而描述系统的主要功能 继续进行分解直到所有的加工只执行一个简单的操作为止

实例分析 学生成绩管理系统 第0层DF图

1教务人员维护学生信息和课程信息并登录学生的选课成绩 2学生查询自己的成绩单

对于学生成绩管理系统而言整个系统就是一个加工学生成绩管理

教务人员是数据的源点学生是数据的终点 教务人员需要录入学生信息课程信息和成绩说明学生信息课程信息和成绩是数据流同样查询请求和查询结果也是数据流 根据上述分析得到如图所示的第0层DF图

第1层DF图

对第0层DF图中的加工学生成绩管理 展开得知学生信息是教务人员需要录入的一个信息因此加入一个加工录入学生信息同样得到录入课程信息登记成绩两个加工另外数据流查询请求和查询结果应该由加工查询成绩来完成

这样我们用录入学生信息录入课程信息登记学生成绩和查询学生成绩四个加工代替第0层的学生成绩管理同时增加这些数据流对应的数据存储即学生课程和成绩最后得到如图所示的第1层DF图

第2层DF图

为了继续进行分解我们分析第1层DF中的加工查询学生成绩

学生查询成绩时需要提供合法性检查因此查询学生成绩可以分解为合法性检查和查询成绩两个处理步骤从而形成第2层DF如下图所示

根据以上实例和经验绘制数据流图应当遵循以下原则 1 分层时子图的输入输出数据流必须和父图中相应加工的输入输出数据流一致 加工的编号应该唯一且具有层次性 加工不应该只有输入或只有输出通常既有输入又有输出 4 数据流图不应反映处理的顺序 加工之间应通过数据存储进行通信避免从一个加工直接流到另一个加工 数据应通过加工进行流动避免从一个数据存储直接流到另一个数据存储 数据流图中所有元素的命名应当对客户有意义且与业务相关 8 不要在一个图中绘制7个以上的加工否则难于绘制和理解

数据字典

以下列出“学生成绩管理系统”的部分数据字典条目

4331 创建实体关系图 第四章 软件需求分析与建模 4331 创建实体关系图 第四章 软件需求分析与建模 4331 创建实体关系图 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 在系统功能扩充时可能增加定义项 其他说明 随时但经常在新生入学时期 峰值 10000左右 数据量 学号 姓名 性别 出生日期 入学年月 定义 无 别名 包括学生的主要信息 描述 学生 数据项名 4332 创建数据流模型 第四章 软件需求分析与建模 学号不能重复 其他说明 6位字符 长度 字符串 类型 无 别名 唯一标识学生的编号 描述 学号 数据流名 4332 创建数据流模型 第四章 软件需求分析与建模 在系统功能扩充时可能增加种类 其他说明 随时但经常在学期开学 峰值 10000次左右 频率 无 别名 系统处理的一个命令 描述 学生成绩查询 数据流名 4333 创建行为模型 第四章 软件需求分析与建模

通常来说行为建模用于实时系统 实时系统中可能存在许多脚本很多实体需要进行状态划分和描述状态转换图 在事务系统中系统行为相对简单只有某些行为较复杂的实体才需要建立其状态转换图 4333 创建行为模型 第四章 软件需求分析与建模 1 分析外部事件所谓外部事件是指外部实体与系统的一次交互 分析事件的响应者该响应者为了响应该事件要进行怎样的活动这种活动又会激发哪些事件等 根据事件和活动划分实体的状态考虑发生怎样的事件使该实体进入这个状态怎样的事件使该实体从这个状态转换到另一状态等 4333 创建行为模型 第四章 软件需求分析与建模 实例分析学生成绩管理系统

在学生成绩管理系统中学生成绩信息必须采取安全措施我们采取登录方法避免非法使用系统这样该系统存在登录正常和出错等状态的转换如下图所示 4333 创建行为模型 第四章 软件需求分析与建模 431 分析模型 第四章 软件需求分析与建模 431 分析模型 第四章 软件需求分析与建模 4311 实体关系图 第四章 软件需求分析与建模

数据对象表示具有不同属性的事物ER用带有标记的矩形来表示 关系表示数据对象之间的相互连接ER用直线连接相关联的数据对象并在直线上用带标记的菱形框来表示关系 属性也称性质指数据对象某一方面的特征 ER用带有标记的椭圆来表示 4311 实体关系图 第四章 软件需求分析与建模 属性 ER图中的基本符号 连接 4311 实体关系图 第四章 软件需求分析与建模 4311 实体关系图 第四章 软件需求分析与建模 4311 实体关系图 第四章 软件需求分析与建模 4311 实体关系图 第四章 软件需求分析与建模 学生选课ER图 4311 实体关系图 第四章 软件需求分析与建模 工资计算系统ER图 4311 实体关系图 第四章 软件需求分析与建模 4311 实体关系图 第四章 软件需求分析与建模 4311 实体关系图 第四章 软件需求分析与建模 4311 实体关系图 第四章 软件需求分析与建模 4312 数据流图 第四章 软件需求分析与建模 4312 数据流图 第四章 软件需求分析与建模 4312 数据流图 第四章 软件需求分析与建模 工资计算系统的顶层 0层 数据流图 4312 数据流图 第四章 软件需求分析与建模 4312 数据流图 第四章 软件需求分析与建模 4313 状态转换图 第四章 软件需求分析与建模 4313 状态转换图 第四章 软件需求分析与建模 4313 状态转换图 第四章 软件需求分析与建模 431 分析模型 第四章 软件需求分析与建模 432 数据字典 第四章 软件需求分析与建模 432 数据字典 第四章 软件需求分析与建模 432 数据字典 第四章 软件需求分析与建模 432 数据字典 第四章 软件需求分析与建模 符 号 含 义 说 明 表示定义为 用于对 左边的条目进行确切的定义 表示与关系 X ab表示X由a和b共同构成 [ ] [ ] 表示或关系 X [ab]与X [ab]等价表示X由a或b组成 表示可选项 X a 表示a可以在X中出现也可以不出现 表示重复 大括号中的内容重复0到多次 m n 表示规定次数的重复 重复的次数最少m次最多n次 表示基本数据元素 中的内容是基本数据元素不可再分 连接符 month 112表示month可取1～12中的任意值 表示注释 两个星号之间的内容为注释信息 433 结构化分析过程 第四章 软件需求分析与建模 433 结构化分析过程 第四章 软件需求分析与建模 433 结构化分析过程 第四章 软件需求分析与建模 4331 创建实体关系图 第四章 软件需求分析与建模 4331 创建实体关系图 第四章 软件需求分析与建模 4331 创建实体关系图 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 425 需求验证 第四章 软件需求分析与建模 4251 需求说明的质量特性 第四章 软件需求分析与建模 需求规格说明对系统功能行为性能等的描述必须与用户的期望相吻合代表了用户的真正需求 需求规格说明应该包括软件要完成的全部任务不能遗漏任何必要的需求信息注重用户的任务而不是系统的功能将有助于你避免不完整性 需求规格说明对各种需求的描述不能存在矛盾如术语使用冲突功能和行为特性方面的矛盾以及时序上的不一致等 需求规格说明中的描述对所有人都只能有一种明确统一的解释由于自然语言极易导致二义性所以尽量把每项需求用简洁明了的用户性的语言表达出来 需求规格说明的格式和组织方式应保证后续的修改能够比较容易和协调一致我们可以使用软件工具或者使用目录表索引和相互参照列表等方法使软件需求规格说明更容易修改 可跟踪性意味着每项需求都能与其对应的来源设计源代码和测试用例联系起来 需求规格说明中描述的需求都可以运用一些可行的手段对其进行验证和确认 4252 需求验证的方法 第四章 软件需求分析与建模 4252 需求验证的方法 第四章 软件需求分析与建模 4252 需求验证的方法 第四章 软件需求分析与建模 4252 需求验证的方法 第四章 软件需求分析与建模 43 分析建模 第四章 软件需求分析与建模 43 分析建模 第四章 软件需求分析与建模 431 分析模型 第四章 软件需求分析与建模 431 分析模型 第四章 软件需求分析与建模 42 需求工程 第四章 软件需求分析与建模 需求开发又可分为问题获取分析编写规格说明和验证四个阶段如图所示 421 需求工程的内容 第四章 软件需求分析与建模 421 需求工程的内容 第四章 软件需求分析与建模 421 需求工程的内容 第四章 软件需求分析与建模 421 需求工程的内容 第四章 软件需求分析与建模 421 需求工程的内容 第四章 软件需求分析与建模 422 需求获取 第四章 软件需求分析与建模 分析人员应该与各种层次的客户进行充分的交流和沟通包括决策领导使用部门的领导具体使用人员系统维护人员等尽量清楚地理解用户的问题和要求 对于用户提供的各种问题和要求分析人员需要对其进行归纳和整理借助一些工具和方法从用户一般性的陈述里面提取用户的真正需求并由此确定软件的功能性能接口关系约束条件等 不论是用户的提出问题还是最终获取的需求都应该形成文档化的描述这种描述需要各种人员的一致理解和认同 422 需求获取 第四章 软件需求分析与建模 422 需求获取 第四章 软件需求分析与建模 422 需求获取 第四章 软件需求分析与建模 422 需求获取 第四章 软件需求分析与建模 422 需求获取 第四章 软件需求分析与建模 422 需求获取 第四章 软件需求分析与建模 423 需求分析 第四章 软件需求分析与建模 423 需求分析 第四章 软件需求分析与建模 423 需求分析 第四章 软件需求分析与建模 423 需求分析 第四章 软件需求分析与建模 423 需求分析 第四章 软件需求分析与建模 423 需求分析 第四章 软件需求分析与建模 423 需求分析 第四章 软件需求分析与建模 423 需求分析 第四章 软件需求分析与建模 423 需求分析 第四章 软件需求分析与建模 424 编写需求文档 第四章 软件需求分析与建模 424 编写需求文档 第四章 软件需求分析与建模 4241 软件需求规格说明 第四章 软件需求分析与建模 4241 软件需求规格说明 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 4242 模板 第四章 软件需求分析与建模 第四章 软件需求分析与建模 第四章 软件需求分析与建模 第四章 软件需求分析与建模 第四章 软件需求分析与建模 第四章 软件需求分析与建模 41 软件需求 第四章 软件需求分析与建模 41 软件需求 第四章 软件需求分析与建模 41 软件需求 第四章 软件需求分析与建模 41 软件需求 第四章 软件需求分析与建模 411 软件需求的定义 第四章 软件需求分析与建模 411 软件需求的定义 第四章 软件需求分析与建模 412 需求的层次 第四章 软件需求分析与建模 412 需求的层次 第四章 软件需求分析与建模 412 需求的层次 第四章 软件需求分析与建模 412 需求的层次 第四章 软件需求分析与建模 412 需求的层次 第四章 软件需求分析与建模 412 需求的层次 第四章 软件需求分析与建模 412 需求的层次 第四章 软件需求分析与建模 413 需求错误的原因 第四章 软件需求分析与建模 413 需求错误的原因 第四章 软件需求分析与建模 413 需求错误的原因 第四章 软件需求分析与建模 413 需求错误的原因 第四章 软件需求分析与建模 413 需求错误的原因 第四章 软件需求分析与建模 413 需求错误的原因 第四章 软件需求分析与建模 413 需求错误的原因 第四章 软件需求分析与建模 413 需求错误的原因 第四章 软件需求分析与建模 413 需求错误的原因 第四章 软件需求分析与建模 42 需求工程 第四章 软件需求分析与建模 42 需求工程 第四章 软件需求分析与建模

需求分析报告【篇2】

需求分析报告

综合要求

一、功能需求

1.1 功能划分

（1）“衣”子系统

（2）“食”子系统

（3）“住”子系统 （4）“行”子系统

1.2 功能描述

（1）“衣”子系统

实现功能：

1）用户服装信息的管理

2）通过当时外界环境和现有服装进行实时推荐

（2）“食”子系统

实现功能：

1）根据用户地理位置（家or餐馆）推送用户当前应摄入的健康食物 。

（3）“住”子系统

实现功能：

1）自动调整屋内温度、湿度、光线和家具（沙发、床）的软硬程度

2）通过无线遥控对各智能终端进一步调节 （4）“行”子系统

实现功能：

有车用户：结合用户对于出行成本的选择（最省时，最省油，折中），给出最优的出行路线。

无车用户：

1）链接打车软件

2）通过连接“车来了”等软件给用户提供建议

1.3系统功能

（1）设计不同用户的操作权限和登录方法。

（2）通过传感器获得周围环境的温度，湿度并将其录入数据库。

（3）通过网络信息抓取以及卫星定位获得必要信息（车流量）并将其录入数据库。 （4）实时获得用户身体健康系数及其饮食喜好并将其录入数据库。 （5）获得附近餐馆和菜品的信息并将其录入数据库。

（6）根据车载传感器获得车距和能见度等信息，并将其录入数据库。 （7）实现语音录入当前用户的代办适宜。 （8）通过消息推送，实现智能办公。

二、性能需求

2.1 数据精确度 该系统对精度要求高，确保数据一致性，确保数据转换的及时准确，确保更新数据的及时准确。

2.2 系统特性

·系统的高速性，稳定性，安全性。

·移动端（安卓／ios 内存2Ｇ 容量16Ｇ 分辨率320*480） ·反映时间：10ms – 100ms ·信息量速率：500bit/s或bps ·数据库容量：500Ｔ

三、可靠性和可用性需求

3.1 稳定性

·对于用户比较繁忙的时候，系统信息就会存在数百甚至数千上万的并发量，系统对于高并发应有相应的负载均衡机制，对所有请求进行优先排队，满足高运行情况下的稳定性和可靠性。

3.2可靠性

·对于遭受网络攻击，或者服务器硬件异常等意外情况，要有意外处理机制，需要系 统能够保证定时备份数据信息，保证在服务器异常的情况下能及时启动应急机制。保证系统的正常访问。

3.3 安全性

·提高安全保密机制，保证数据可靠安全

·对不同用户分配不同的权限

·用户只能操作相应权限的信息，如查看，删除信息等

·要保证用户信息的安全性，保证管理员和开发者不能够随意的查阅改动用户信息

3.4完整性

·提高数据完整性，参照完整性等

3.5 易用性

·提高使用性，便于用户操作，提高用户满意度。

3.6可复用性

·保证代码可复用，方便操作

3.7 可维护性

·提高程序健壮性，保证程序的后期可维护性

3.8 可移植性

·提高代码使用次数，提高利用率，保证代码可移植性

3.9 可测试性

·保证程序可测试，便于后期操作

四。出错处理需求

4.1格式要求

·给每一个信息的格式都要注意其形式。格式不对的自动重新测试，以及自动把情况反馈给管理员。

4.2信息保存

·对于外来攻击导致系统崩溃情况，需要及时保留用户当前所有的信息。

五、接口需求

5.1 用户接口

·把用户提交的账号密码，在数据库中进行搜索查询进行验证。

5.2硬件接口

·温度传感器接口，空气湿度传感器接口

5.3 软件接口

·实现衣食住行模块和数据库之间相互传输信息

5.4 通信需求接口

·实现卫星以及车载传感器把测的数据进行传输。

六、约束

6.1精度

·对于温度，湿度要求精确到小数点后两位。对于能见度等问题需要精确到误差在3米之内

6.2语言约束

·英语和汉语结合。

6.3设计约束

·全部过程需要从整体，平衡出发。不要仅仅开发完一个在区开发另外一个。

6.4使用标准

·全部的标准使用国际标准。

6.5硬件平台

·台式机为xp/win7系统。移动端为android/ios。

七、逆向需求

基于互联网的“懒人系统”目前能够完成生活许多方面的推荐以及收集测试信息等。但是尚且不能人性化的代替拥护进行决定。

八．系统用例图

服装推荐传感器食物推荐用户家居调节因特网出行推荐登陆

九．系统数据需求分析

9.1系统的E-R图

服装餐厅服装推荐食物推荐用户家居调节出行推荐家居用品道路

9.2数据需求

（1）穿衣子系统

（衣橱统计，气象监控，期刊统计，用户喜好） 说明：

衣橱统计：记录用户当前拥有的服饰，需要用户自行更新。

气象监控：记录实时的天气情况，从互联网获取当前温度气象信息。

期刊统计：统计当前时尚期刊中出现频率较高的服饰搭配信息，以便向用户推送。 用户喜好：统计用户的穿衣习惯，找出并记录用户喜欢的搭配风格，以便系统进行比较。 （2）饮食子系统

（饮食记录，饮食统计，饭店信息） 说明：

饮食记录：记录用户日常的一日三餐情况。 饮食统计：根据饮食记录中的信息，分析出用户偏好并记录。

饭店信息：储存用户周边饮食信息，根据系统分析，为用户推荐适合的餐饮建议。 （3）住宿子系统 （家具信息统计） 说明：

此系统主要负责管理用户生活起居，所含数据包括： 室内温度，家电状态（如电视开闭，空调开闭），照明系统，窗帘控制 （4）出行子系统

（地图信息，公交信息，票务信息，记事本） 说明：

地图信息：主要供导航软件调用，并按时进行更新。

公交信息：储存用户周边的公共交通信息，方便用户乘坐公交车。

十．系统逻辑模型

10.1数据流图 衣： 1层：

温度传感器温度日期因特网流行服装信息流行服装信息用户浏览习惯信息用户浏览习惯信息温度日期日期温度1采集信息服装推荐子系统的信息流行服装信息用户浏览习惯信息服装推荐子系统的信息服装推荐子系统的信息现有服装信息出席场合信息用户2执行服装推荐算法推荐的服装信息3输出推荐的服装推荐的服装信息推荐的服装信息推荐的服装信息 2层： 温度传感器因特网温度日期流行服装用户浏览信息习惯信息用户浏览习惯信息用户浏览习惯信息1.6接收用户浏览习惯信息温度日期流行服装信息温度日期流行服装信息1.5接收流行服装信息1.3温度1.4接收日期温度日期流行服装信息用户浏览习惯信息采集信息服装需求信息1.1接收服装需求信息现有服装信息1.2接收现有服装信息现有服装信息服装需求信息用户

服装推荐子系统服装推荐子系统的信息的信息2.1整理信息正确格式的信息2.2“标签”算法推荐的服装推荐的服装

食： 1层：

传感器身体状况信息身体状况信息身体状况信息因特网餐厅菜品信息餐厅菜品信息餐厅菜品信息食物推荐子系统的信息1采集信息食物推荐子系统的信息食物推荐子系统的信息饮食喜好用户2执行食物推荐算法推荐的菜品信息3输出推荐的菜品信息推荐的菜品信息推荐的菜品信息推荐的菜品信息 2层：

传感器因特网身体状况信息餐厅菜品信息身体状况信息餐厅菜品信息身体状况信息1.2接受身体状况信息餐厅菜品信息1.3餐厅菜品信息身体状况信息餐厅菜品信息采集信息饮食需求信息1.1接收饮食喜好信息饮食喜好信息用户 食物推荐子系统食物推荐子系统的信息的信息2.1整理信息正确格式的信息2.2“标签”算法推荐的菜品推荐的菜品

住： 1层：

传感器用户体征信息温度信息光线信息用户体征信息用户体征信息温度信息温度信息湿度信息湿度信息湿度信息家居调节子系统的信息家居调节子系统的信息家居调节子系统的信息光线信息光线信息1采集信息用户习惯的环境信息用户3执行调节方案2执行家居调节算法调节方案调节方案调节方案温度湿度信息信息亮度信息窗帘位置信息空调电灯窗帘

2层：

传感器温度信息光线信息湿度信息温度信息温度信息1.2接收温度信息光线信息光线信息1.3接收光线信息湿度信息湿度信息1.4接收湿度信息温度信息光线信息湿度信息采集信息用户习惯的环境信息1.1接收用户习惯的环境信息用户习惯的环境信息用户 家居调节子系统家居调节子系统的信息的信息2.1整理信息正确格式的信息2.2“选路”算法调节方案调节方案

调解方案温度信息湿度信息亮度信息窗帘位置信息3.1发送温度信息3.2发送湿度信息3.3发送亮度信息3.4发送位置信息温度信息湿度信息亮度信息位置信息空调电灯窗帘

行： 1层：

传感器用户位置信息用户位置信息因特网道路信息道路信息出行推荐子系统的信息用户位置信息道路信息出行推荐子系统的信息出行推荐子系统的信息1采集信息时间金钱需求信息目的地信息用户2执行出行推荐算法推荐方案推荐方案推荐方案3输出推荐方案推荐方案

2层： 传感器用户位置信息用户位置信息用户位置信息2.3接收用户位置信息道路信息道路信息2.4接收道路信息道路信息因特网用户位置信息道路信息采集信息时间金钱需求信息2.1接收时间金钱需求信息目的地信息2.2接收目的地信息时间金钱需求信息目的地信息用户

出行推荐子系统出行推荐子系统的信息的信息2.1整理信息正确格式的信息2.2“标签”算法出行方案出行方案

10.2相应的数据字典 衣： 数据流 数据流名：出席场合信息 说明：用户希望服装推荐系统针对不同的场合帮助其选择合适的服装，服装推荐系统会在用户已有衣服的基础上提供给用户合适的服装搭配方案 数据流来源：用户

数据流去向：采集信息

定义：出席的场合={学校，办公室，聚会，典礼}

数据流名：温度

说明：记录室内外温度，帮助用户选择合适厚度的衣服 数据流来源：温度传感器 数据流去向：采集信息 定义：温度=-40.。40

数据流名：现有服装信息 说明：记录用户已有服装，服装推荐系统在已有服装基础上提供给用户合适的服装搭配方案

数据流来源：用户

数据流去向：采集信息 定义：已有服装信息=服装编号+服装名称+品牌+尺寸+颜色+款式+材质+服装图片索引

数据流名：日期

说明：记录当前日期，帮助用户选择合适季节的衣服 数据流来源：因特网

数据流去向：采集信息（数据存储） 定义：日期=年＋月＋日

数据流名：流行服装信息

说明：获得当下的流行风尚，帮助服装推荐系统和已有服装进行对比，从而给出符合当下流行的服装搭配 数据流来源：互联网

数据流去向：采集信息（数据存储） 定义：流行服装信息=服装编号+服装名称+品牌+尺寸+颜色+款式+材质+服装图片索引

数据流名：用户浏览习惯信息

说明：记录用户经常浏览的服装，将信息发送给服装推荐系统，服装推荐系统由此分析用户的穿衣喜好，从而推荐给用户符合其穿衣品味的服装 数据流来源：互联网

数据流去向：采集信息（数据存储） 定义：服装编号+浏览次数

数据流名：推荐的服装 说明：服装推荐系统根据对采集的参数进行智能处理，最后得到合适的服装搭配信息

数据流来源：智能服装推荐程序

数据流去向：推荐的服装信息（数据存储） 定义：推荐的服装=服装编号+服装图片索引 数据加工

加工名：采集信息 加工编号：1 简要描述：采集服装推荐算法需要的信息

输入数据流：出席场合信息，温度，现有服装信息，日期，流行服装信息，用户喜好信息

输出数据流：服装推荐算法的信息

加工逻辑：采集出席场合信息，传感器信息，因特网信息。

加工名：执行服装推荐算法 加工编号：2 简要描述：处理正确格式的信息，把信息与数据库中的解决方案相匹配，得到解决方案。

输入数据流：服装推荐子系统的信息 输出数据流：推荐的服装 加工逻辑：“标签”算法的本质是专家系统，数据库有1万条用户在各种情况下的解决方案（1万条记录），用户在界面上选择的标签会变成另一张二维表中的记录，“标签”算法会将用户的选择（记录）和数据库1万条记录比照，匹配项最多的记录的解决方案会成为最后的推荐方案。 加工名：输出推荐的服装 加工编号：3 简要描述：显示推荐的服装信息 输入数据流：推荐的服装信息 输出数据流：推荐的服装信息 加工逻辑：显示推荐的服装信息

数据文件名：温度

简述：存放的是温度信息 输入数据：温度 输出数据：温度

数据文件组成：温度

数据存储

数据文件名：现有服装信息 简述：存放已有服装信息

输入数据：服装编号，颜色，尺码，类型，条形码 输出数据：服装编号

数据文件组成：服装编号，颜色，尺码，类型，条形码

数据文件名：日期 简述：存放当前的日期 输入数据：年+月+日 输出数据：年+月+日 数据文件组成：年+月+日

数据文件名：流行服装信息 简述：存放当时流行的服装款式

输入数据：颜色，尺码，类型，条形码 输出数据：条形码

数据文件组成：颜色，尺码，类型，条形码

数据文件名：用户浏览习惯信息

简述：存放用户在各大网站查询的服装信息 输入数据：用户浏览习惯信息 输出数据：用户浏览习惯信息

数据文件组成：服装编号，浏览次数

食： 数据流

数据流名：饮食喜好

说明：用户希望饮食推荐系统推荐一些餐饮信息，以供选择，饮食推荐系统会根据用户的饮食习惯，偏好，营养均衡等多种因素结合为用户推荐健康可口的食物。 数据流来源：用户

数据流去向：采集信息 定义：饮食喜好={甜，咸}

数据流名：身体状况信息

说明：系统通过记录或探测，用户的基本生命体征如心率，血压，血糖等，为推荐饮食提供参考信息。

数据流来源：传感器，因特网 数据流去向：采集信息

定义：身体状况信息=心率+血压+血糖

数据流名：餐厅菜品信息

说明：系统通过存储并及时更新餐厅菜单，为推荐饮食提供参考信息。 数据流来源：因特网 数据流去向：采集信息

定义：餐厅菜品信息=餐厅名+餐厅编号+菜名名+菜品编号+菜品营养+菜品口味、

数据流名：推荐的菜品信息

说明：食物推荐算法处理食物推荐子系统信息产生的结果。 数据流来源：执行食物推荐算法 数据流去向：输出推荐的菜品信息

定义：餐厅菜品信息=餐厅名+餐厅编号+菜名名+菜品编号+菜品营养+菜品口味、 数据加工：

加工名:采集信息 加工编号：1 简要描述：采集食物推荐子系统所需数据

输入数据流：身体状况信息，餐厅菜品信息，饮食喜好 输出数据流：食物推荐子系统的信息

加工逻辑：从互联网，用户输入，传感器接受信息

加工名：执行食物推荐算法 加工编号：2 简要描述：处理正确格式的信息，把信息与数据库中的解决方案相匹配，得到解决方案。

输入数据流：食物推荐子系统的信息 输出数据流：推荐的菜品 加工逻辑：“标签”算法的本质是专家系统，数据库有1万条用户在各种情况下的解决方案（1万条记录），用户在界面上选择的标签会变成另一张二维表中的记录，“标签”算法会将用户的选择（记录）和数据库1万条记录比照，匹配项最多的记录的解决方案会成为最后的推荐方案。

加工名：输出推荐的菜品 加工编号：3 简要描述：显示推荐的菜品信息 输入数据流：推荐的菜品信息 输出数据流：推荐的菜品信息 加工逻辑：显示推荐的菜品信息

数据存储：

数据文件名：身体状况信息

简述：存放身体状况信息，如体重，血压，心率等 输入数据：身体状况信息 输出数据：身体状况信息

数据文件组成：体重，血压，心率

数据文件名：餐厅菜品信息 简述：存放餐厅菜单 输入数据：餐厅菜品信息 输出数据：餐厅菜品信息

数据文件组成：餐厅名，餐厅编号，菜名名，菜品编号，菜品营养，菜品口味、

数据文件名：推荐的菜品信息 简述：存放推荐的菜品信息 输入数据：推荐的菜品信息 输出数据：推荐的菜品信息

数据文件组成：餐厅名，餐厅编号，菜名名，菜品编号，菜品营养，菜品口味、

住： 数据流

数据流名：温度信息 说明：采集室内的温度信息，反馈给用户，或者系统根据温度自动采取相应措施，调节室内温度。

数据流来源：温度传感器

数据流去向：采集家居控制系统的参数 定义：温度=-40-40摄氏度

数据流名：光线信息 说明：采集室内的光线信息，反馈给用户，或者系统根据温度自动采取相应措施，调节室内光照强度。 数据流来源：光敏传感器

数据流去向：采集家居控制系统的参数 定义：光照强度=0-180流明

数据流名：湿度信息 说明：采集室内的湿度信息，反馈给用户，或者系统根据温度自动采取相应措施，调节室内湿度。

数据流来源：湿度传感器

数据流去向：采集家居控制系统的参数 定义：湿度=10%-80%

数据流名：用户习惯的环境信息

说明：采集用户习惯的温度信息，光线信息，湿度信息 数据流来源：用户

数据流去向：采集信息

定义：用户习惯的环境信息=温度+光线+湿度

数据加工

加工名：采集信息 加工编号：1 简要描述：采集智能控制系统需要的参数

输入数据流：温度，湿度，光照强度，温度请求，湿度请求，光照请求 输出数据流：智能家居控制系统的参数

加工逻辑：从各个传感器接受信息，并与用户设置进行对比，得出相应操作发送给控制器实施。

加工名：执行家居调节算法 加工编号：2 简要描述：处理正确格式的信息，把信息与数据库中的解决方案相匹配，得到解决方案。

输入数据流：家居调节子系统的信息 输出数据流：调解方案 加工逻辑：“选路”算法本质是基于条件判断的数据处理系统。该处理系统自身包含多个IF语句对用户需求进行判断分支执行。从而得到最后的推荐方案。

加工名：执行调节方案 加工编号：3 简要描述：把温度，湿度，亮度，窗帘的位置信息传递给空调，电灯，窗帘 输入数据流：调节方案

输出数据流：温度，湿度，亮度，窗帘的位置信息 加工逻辑：对传感器传递信息

数据存储

数据文件名：温度信息 简述：存放的是温度信息 输入数据：温度信息 输出数据：温度信息 数据文件组成：温度

数据文件名：湿度信息 简述：存放的是湿度信息 输入数据：湿度信息 输出数据：湿度信息 数据文件组成：湿度

数据文件名：亮度信息

简述：存放的是光照强度信息 输入数据：亮度信息 输出数据：亮度信息 数据文件组成：亮度信息

行： 数据流

数据流名：用户位置信息 说明：借助通信运营商来获取用户详细位置，出行管理系统会利用该位置信息提供导航，或叫车服务。 数据流来源：通信运营商

数据流去向：采集出行管理系统的参数 定义：用户位置信息=经度+纬度

数据流名：道路信息

说明：将街道信息储存到客户端，，并定期进行更新，出行管理系统会利用该道路信息提供导航服务。 数据流来源：互联网

数据流去向：采集出行管理系统的参数 定义：道路信息={繁忙，畅通}

数据流名：目的地信息

说明：用户想要到达的目的地信息 数据流来源：用户

数据流去向：采集信息

定义：目的地信息=目的地信息

数据流名：时间金钱需求信息 说明：用户对于时间，金钱的要求 数据流来源：用户

数据流去向：采集信息

定义：时间金钱需求信息=时间+金钱

数据加工

加工名：采集信息 加工编号：1 简要描述：采集出行推荐子系统需要的信息

输入数据流：用户位置信息，道路信息，目的地信息，时间金钱需求信息 输出数据流：出行推荐子系统的信息 加工逻辑：从用户和互联网接收信息。

加工名：执行出行推荐算法 加工编号：2 简要描述：处理正确格式的信息，把信息与数据库中的解决方案相匹配，得到解决方案。

输入数据流：出行推荐子系统的信息 输出数据流：推荐方案 加工逻辑：“标签”算法的本质是专家系统，数据库有1万条用户在各种情况下的解决方案（1万条记录），用户在界面上选择的标签会变成另一张二维表中的记录，“标签”算法会将用户的选择（记录）和数据库1万条记录比照，匹配项最多的记录的解决方案会成为最后的推荐方案。

加工名：输出推荐方案 加工编号：3 简要描述：显示推荐方案信息 输入数据流：推荐方案 输出数据流：推荐方案

加工逻辑：显示推荐方案信息

数据存储 数据文件名：用户位置信息 简述：存放用户的经纬坐标 输入数据：用户位置信息 输出数据：用户位置信息 数据文件组成：经度，纬度

数据文件名：道路信息

简述：存放道路的繁忙情况信息 输入数据：道路信息 输出数据：道路信息

数据文件组成：道路繁忙情况信息

数据文件名：推荐方案

简述：存放推荐的出行方案信息 输入数据：推荐方案 输出数据：推荐方案

数据文件组成：出行方式，路线

需求分析报告【篇3】

我生性是比较胆小的。对于安全，特别是生产安全，估计得从我参加工作的那年说起。xx年一毕业，我便被分配到位于甘肃山沟里面的一个水电站做施工。在这里，平生第一次深刻知道安全对于生产，对于自身，对于内心的重要性。

记得美国犹太裔人本主义心理学家亚伯拉罕·马斯洛（AbrahamMaslow）就提出，人对于安全的需求在需求层次理论金字塔中是先于生理需求（身体基本需求）社交需求（社会关系的需求）自我实现需求及尊重需求，属于最基本的需求。是的，人工作是为了活着，或是为了养家糊口，或是为了十几年的教育能够学有所用，或是为了实现自己的社会价值，但所有的所有的目的，都是在自身安全的前提下实现的。

由于我的生性胆小，所以第一次接触这种立体式庞杂的施工现场时，我是以一个初入者的身段带着强大的融入式需求来接受目前这份工作的，虽然在繁杂立体式的施工现场有很多对自身安全造成困扰的问题，但是我得面对。因为我来自农村，又学了工程测量这门专业，除此之外，作为一个刚毕业的学生，我还能干吗？第一次在下面悬空的钢筋网上走自己还是很害怕的，第一次背着仪器箱子在垂直的几十米高简易爬梯上上下内心也是颤抖的，第一次在全无遮护的布着钢轨仅能容下双脚宽的20多米高的吊车预制梁上走过内心是带着与命运抗衡的决心的，我记得从那上面走过后，我觉得这辈子我都不再从类似这样的地方走过，对我来说这简直是在高空走钢丝绳，即使我们有年长的前辈在上面如履平地。恐惧跟大意绝对是安全生产事故中最危险的两种心态。这两种心态在心态中处于两个极端，也许我处于这端，而我的那位前辈处于那端。而从哲学讲，两种似乎都不可取。要讲究适度原则，也就是说，我得有着适度的心态去衡量这件“高空走钢丝”事件。那段时间里，我有种特种兵接受三月集训的感觉，挑战我的空间作业极限，还有心理极限。当然这确实是我必须面对的，由于作业环境限制，我们通常不得不在很近的平面距离里背负仪器利用简易且有限的条件及工具通过上下攀爬的方式来抵达目的地。哪怕平面距离只有几米远。而我得慢慢调整我的心态来适应，得调整我的身体敏捷程度来适应。因为再复杂的施工现场，安全的投入往往是繁琐的，可能是循环往复的，成本昂贵且占用大量时间的，在工期紧张的时段里，这些有时会显得铺张。要与之适应的，则是自身身体的灵活性以及心态的正常适度性。所以，那个时候的我，从很大一部分，只能增加自身的适应能力，而无能迁就于其他形式。而我就是如此慢慢适应过来的，在复杂的环境中，有了眼疾手快，心态坦然，泰山崩于前面不改色的气度了。这大概就是为了适应常规生产，自身心态适应中回归理性的过程吧。

后面的几年时光里，我确实被历练的坦然地多。对于安全防范的意识也是越来越提高了。那些不安全的地方我是坚决不去的。但是身边并不因为我的适应性而不出现些安全事故了。在我从业的几年了，身边的安全事故出了好多起。高空坠落的，溺水的，为了生活付出生命代价的比比皆是。生产是存在安全隐患的，从远古时期到今。从部族协作狩猎开始，从生产石器开始，我们的祖先就不得不面对生产中存在的安全隐患及问题。在战争中，我们也在为保存自身实力而进行着各种安全方面的考虑与措施。

而对安全问题的诠释，最具具体化，最让人好理解的无外乎便是举例说明了。这在我们安全培训教育及安全教育视频中也无不比比皆是。而所以的事故中大意似乎是其发生的大多数原因。我遇到的第一次人身伤亡事故还是在我所在的工地，一名的工人在8米高的泄流冲砂闸上游胸墙上拆卸模板的过程中，因为安全绳脱钩造成自身连同模板坠落，在送往医院后因伤势过重抢救无效身亡。这起事故中，安全意识淡薄，钩挂安全绳仅仅用来应付项目部安全监察，留于形式，是事故发生的主要原因。也有人因醉酒在靠近水库的公路步行跌入已经蓄水的水库溺水身亡的，这种事故原因无异于酒驾了，只是威胁的仅是自身安全罢了。在后面的项目中，也有在施工现场雨后攀高导致盆骨骨折的，也有晚上夜行无意堕入水池溺亡的。所有这些，无外乎大意。看来我这小心翼翼的心态，胆小的生性还是能够让人无时无刻绷紧安全的神经的。这一点我还是比较庆幸。

单位还是经常举办安全知识培训的，项目部及现场还是在醒目地段及危险地段有安全标示的。在新的安全生产法颁布后，单位从上到下以严谨的态度还组织了我们学习，考试，竞答，用各种方式将安全生产理念，方法植入每个职工的每一根神经与血管中。宣传方式也从刚开始的严禁式转换到后来的提醒式，甚至还有戏谑式。最典型的就是比如从标语写“禁止酒驾”，“禁止不带安全帽”，“禁止私拉乱接电源”等变成了“高高兴兴上班，安安全全回家”的温馨提醒式再到网络上贴出“为了防止别人娶你老婆，打你孩子，花你抚恤金，请注意安全”的戏谑式安全标语，说明安全的形式正以多样化的形式深入到社会中，在这社会发展中是好事。

再完善的标语，在完善的生产教育和法律都得靠我们自身每天每时每刻的践行，不然都无异于空谈。还是那句话：工作，不管是为了活着，或是为了养家糊口，或是为了十几年的教育能够学有所用，或是为了实现自己的社会价值，但所有的所有目的，都是在自身安全的前提下实现的。

需求分析报告【篇4】

一、系统概述

“博客”一词是从英文单词Blog音译（不是翻译）而来。Blog是Weblog的简称，而Weblog则是由Web和Log两个英文单词组合而成。博客最初的名称是Weblog，由web和log两个单词组成，按字面意思就为网络日记，后来喜欢新名词的人把这个词的发音故意改了一下，读成weblog，由此，blog这个词被创造出来。中文意思即网志或网络日志，不过，在中国大陆有人往往也将Blog本身和blogger（即博客作者）均音译为“博客”。

博客，又译为网络日志、部落格或部落阁等，是一种通常由个人管理、不定期张贴新的文章的网站。博客上的文章通常根据张贴时间，以倒序方式由新到旧排列。许多博客专注在特定的课题上提供评论或新闻，其他则被作为比较个人的日记。一个典型的博客结合了文字、图像、其他博客或网站的链接、及其它与主题相关的媒体。能够让读者以互动的方式留下意见，是许多博客的重要要素。博客是社会媒体网络的一部分。博客系统，是指使用计算机语言编写，并便于用户安装和使用，在互联网上建立个人博客的一整套系统。个人博客现在已经成为很多人生活中必不可少的一个部分，方便了人与人之间的沟通和交流。

二、需求分析

博客系统是一个多用户、多界面的系统，主要包括以下几个模块组成。

1、匿名用户模块

本模块主要由浏览博客、评论2个部分组成。匿名用户可以对其他用户的博客内容时行浏览、评论。也可以通过注册后登录博客系统，申请一个属于自己的博客。

2、注册用户模块

本模块主要由个人信息管理、评论管理、好友管理、相册管理、文章管理5个部分组成。这些功能可以对用户个人博客中的个人信息、好友、评论、相册和文章进行设置。

3、系统管理模块

本模块主要由用户管理、评论审核管理、相册审核管理、文章审核管理、链接管理5部分组成。这是为了对注册用户的博客内容与个人信息进行管理，并对博客中的评论、相册、文章进行审核，审核通过后才能发表。

三、系统实现目标概述

基于个人博客以上的特点，本系统要实现个人博客的主要基本功能有主界面，博客用户登录发表文章（心情、日志），用户登录/退出，游客发表评论，分页浏览文章和评论等。这里其中比较主要的是区分了个人博客用户和游客。博客用户可以在任何时候写下自己的主张，记录下自己的点点滴滴。

而游客主要的权限是阅读博客所有注册用户写的文章，阅读后可以发表评论和留言，还可以分页浏览所有注册用户上传的图片。以上是个人博客的系统功能目标，当然由于个人博客的网络流行特点以及个人个性的展示，还适当要求界面比较漂亮轻快，直观便捷，操作方式简单以及人性化。

需求分析报告【篇5】

引言是对这份软件产品需求分析报告的概览，是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档

1.1编写目的：

本需求分析报告的目的是规范化本软件的编写，旨在于提高软件开发过程中的能见度，便于对软件开发过程中的控制与管理，同时提出了本学校排课系统的软件开发过程，便于程序员与客户之间的交流、协作，并作为工作成果的原始依据，同时也表明了本软件的共性，以期能够获得更大范围的应用，同时它也是进行项目策划、概要设计和详细设计的基础，是维护人员进行内部维护，信息更新，验收和测试的依据。

本产品是针对电脑进行排课的'需求设计的，可以完成：基本数据录入与维护、课程表编排、课表冲突分析报告、课表输出、可以直接或导出至Excel打印总课表、教师课表、()班级课表、场地课表、系统管理。

学校排课系统软件：学校排课系统软件是为了帮助学校老师对学校的排课更加方便和快速制作处课程表及其管理学校的课程的软件。

二、项目描述：

使用改程序后，学校的排课可以很轻松的安排好，而却可以尽量避免平时排课时出现的排课冲突，还可以临时加补课等功能。

2.1软件开发的目标：

改善目前有些学校人工排课是常常出现的冲突以及浪费的大量时间。同时也通过实践来提高自己的动手能力。

2.2应用范围：

理论上能实现中小学排课，职业中学排课。

2.3子集说明：

软件主要分为两个模块，一个基本信息的录入，一个是进行排课的管理。

2.4软件功能描述：

内部功能：基本信息的录入、固定课的设置、科目的录入、年级的录入、任课老师的录入、场地限制的录入和课表的查看；排课操作、调课操作、场地调课操作、老师课表及学生课表生成。

软件的操作人员要求具有一定的电脑常识，并且具有排课的初步常识。

在进行向数据库录入数据时，要求数据记录准确。

程序排课响应时间：由于生成课表是需要看电脑的配置，所有时间可能会不一样，有时候需要等上几分钟

本软件由于自身的能力限制，所有只限现在所有的功能。

由于软件运行数据放在数据库中，所以参数不容易被错改、破坏，万一参数受到破坏，可以从新录入信息进行更正

本软件利用数据库进行编程，系统结构由程序基本确定，大量的参数及文本内容全部放于数据库中。修改、更新数据只要在数据库进行修改添加，而不需要对系统结构进行修改，这样系统维护性十分方便。

由于尚未测试，故无法对兼容性进行评析。

需求分析报告【篇6】

一、总 则

第一条 为进一步规范和加强教职工请假管理工作，根据《事业单位人事管理条例》、《女职工劳动保护特别规定》等国家和广东省的有关政策规定，结合学校的实际情况，特制定本规定。

第二条 本规定适用对象为中山大学教职员工。

第三条 本规定适用的教职工请假类型主要包括：病假、事假、婚假、产假和计划生育假、陪产假、探亲假、丧假等。

二、请假程序

第四条 教职工在国家规定的各种假期以外，因病、因事请假，必须严格执行相应的请假申报和销假制度。

第五条 凡需报学校审批的请假，申请人必须填写《中山大学教职工请假申请表》、申请续假的必须填写《中山大学教职工续假申请表》、假期结束后申请销假的必须填写《中山大学教职工销假申请表》，经所在单位同意后报人力资源管理处审批。

第六条 副处级及以上的干部，连续请假超过7天的，除提交人力资源管理处审批外，还须报组织部备案。

三、请假类型

第七条 病假

(一)教职工请病假必须持有我校校区门诊部或三甲医院出具的诊断证明书和病假单(国内异地就诊或急诊除外)，如无相关证明则按事假处理。特殊情况未能及时请病假的，可委托他人代请假，病愈后10个工作日内补办请假手续。其中参加职工医疗保险的教职工如请假在2个月以内，除上述指定的医疗机构外，还可以提供所在地医保部门指定的医疗机构证明;超过2个月的须提供三甲医院的证明。

(二)教职工请病假7天以内的，由所在单位领导审批并按月报人力资源管理处备案;连续超过7天的，所在单位同意并签署意见后，报人力资源管理处审批。

(三)参照国家关于医疗期的管理规定，患特殊疾病(如癌症、精神病、瘫痪等)在24个月内尚不能痊愈的，须提交三甲医院的疾病诊断证明，并由人力资源管理处、公费医疗办公室组织专家审定，可以适当延长医疗期。

(四)工作人员病愈后要求恢复工作的，经三甲医院证明身体确已康复方可恢复工作。恢复工作后，因工作过于劳累旧病复发，或另患其他疾病需要休养的，其病假时间可以重新计算。

(五)新录用人员在试用期间休病假的，其试用期相应延长，原则上休病假的时间不得超过国家规定的医疗期。

(六)经广东省人力资源社会保障厅劳动能力鉴定部门鉴定，因病完全丧失工作能力，并符合有关规定者，可申请办理病退。

第八条 事假

(一)教职工在工作期间，因特殊情况需请事假，应由本人向所在单位提交书面申请。

(二)教职工请事假7天以内的，由所在单位领导审批并按月报人力资源管理处备案;连续超过7天的，由所在单位领导同意并签署意见后，报人力资源管理处审批;1个月以上的，由所在单位领导和人力资源管理处提出意见后，报主管校领导审批。原则上1年内累计的事假期限最长不得超过50天。

第九条 婚假

(一)教职工本人经法定程序办理了结婚手续的，可申请休婚假5天。

(二)所在单位结合工作情况，由单位按照国家文件予以审批婚假。

第十条 产假和计划生育假

(一)女教职工休产假和计划生育假，应由本人提出申请、所在单位签署意见，报人力资源管理处审批。

(二)符合国家法律、法规规定生育子女的，产假为98天，并可享受30天的奖励假，其中产前可休假15天。

(三)怀孕女职工在工作时间内进行产前检查，所需时间计入工作时间。

(四)生育时因难产而剖腹等符合规定情况出现者，可增加产假30天;吸引产、钳产等符合规定情况出现者，增加产假15天(前两项不能相加计算)。生育多胞胎的，每多生育1个婴儿，增加产假15天。

(五)女教职工符合计划生育怀孕未满4个月流产的，享受15天产假;怀孕满4个月流产的，享受42天产假。

(六)根据国家相关规定，女专任教师产假期间若正值寒暑假，其休假时间可顺延。

(七)女教职工产假期满后，可按规定给予每天1小时哺乳时间至婴儿一周岁，生育多胞胎的，每多哺乳一个婴儿，每天增加1小时哺乳时间。

(八)符合计划生育规定的女教职工产假期满后抚育婴儿有实际困难，经本人申请，所在单位同意并签署意见，报人力资源管理处审批同意，可请哺乳假全休至婴儿一周岁。

(九)接受节育手术者，凭医院证明，享受国家规定的计划生育假期：①放置宫内节育器的，休息3天，手术后7日不从事重体力劳动;②按规定取出宫内节育器的，休息2天;③输精管结扎的，休息10天;输卵管结扎的，休息30天;符合再生育条件，施行输卵(精)管复通术的，休息14天;④施行皮下埋植术的，休息3天;⑤怀孕2个月以下人工流产的，休息15天;怀孕2个月以上4个月以下人工流产，休息30天;怀孕4个月以上引产的，休息45天。同时施行两种节育手术的，合并计算假期。

第十一条 陪产假

符合国家法律、法规规定生育子女的夫妻，男教职工可享受15天陪产假。申请陪产假的男教职工须由本人提出申请、所在单位签署意见，报人力资源管理处审批。

第十二条 探亲假

(一)根据国务院关于职工探亲待遇的规定，学校实行寒暑假制度，教职工探亲假应安排在寒暑假内。如按国家相关规定实行年休假制度的，由所在单位根据工作的具体情况统筹安排，按相应的聘任合同或劳动合同及岗位要求执行。

(二)已婚职工探望配偶的，每年给予报销往返路费1次;探望父母的，每4年给予报销往返路费1次。未婚职工探望父母的，每年给予报销往返路费1次。具体报销标准按照国家政策和学校相关规定执行。

(三)归侨、侨眷、台胞教职工出境探亲根据国家有关规定执行。

(四)各单位人事秘书根据以上探亲假规定，于寒暑假后的一个月内及时将本单位可享受且已享受探亲假的教职工名单提供人力资源管理处备案。路费报销当年有效，过期不予办理。

(五)在国家规定的各种假期、寒暑假外，因私申请出国探亲的人员均按事假办理。

第十三条 丧假

(一)直系亲属(父母、配偶和子女)及配偶父母去世的，经所在单位批准，可申请5天丧假。

(二)符合探亲条件，并在父母或配偶去世的当年未曾享受过探亲假待遇的教职工，请假办理丧事时，可享受探亲假关于路费报销的待遇。

(三)教职工需去外地料理丧事的，可根据实际情况给予路程假，路费自理。

(四)丧假由各单位按照本文件规定予以审批。

四、附 则

第十四条 本文件中涉及的请假的天数为连续计算，如1月1日起请假30天，则销假日期为1月30日。但婚假、丧假期间的公休假日和法定节假日不作为计算假期的天数。

第十五条 各类请假期间的薪酬待遇按国家、地方、学校的有关规定执行。

第十六条 寒暑假期间，学校教职工按相应的聘任合同、劳动合同及聘任单位的岗位要求休假。

第十七条 各单位应当严格执行各类请假的规定，如发现弄虚作假、瞒报、隐报，由学校追究相关单位的责任人，按相关规定对主管负责人及其经办人进行处理。

第十八条 教职工在请假期间违反国家、地方法律法规及学校相关规章制度的，按照相应的规定处理。

第十九条 教职工未经请假擅自离岗或请假逾期不归者，按旷工处理。连续旷工或累计旷工时间超过规定的时间，按国家规定或合同约定，解除合同。

第二十条 关于教师学术假的有关制度，学校另行制定。

第二十一条 各附属医院可结合实际情况重新制定或参照执行。

第二十二条 本规定依据国家、地方和学校有关规定、政策制定。如相关规定、政策发生调整，按新规定、政策执行。此前有关规定与本规定不一致的，以本规定为准。

第二十三条 本规定自公布之日起执行，原《中山大学关于教职工请假的若干规定》(人事〔2005〕46号)同时废止。

第二十四条 本规定由人力资源管理处负责解释。

需求分析报告【篇7】

2、地点：繁华路段，沿街门面、行政机关单位、事业单位、陌生拦截等处选择样本

家庭人数：

文化程度：大专以上12人 中学（含高中、初中、中专）40人 其他16人

从图中可以看出，客户对房型结构的选择中，三房两厅的占到高达40%的份额，加上18%的四房两厅和18%的三房一厅，合计占到76%的份额，只有不占1/4的人选择两房或其他户型。

从图中可以看出，客户选择110―130平方米的比例占到35%，与上图中三房两厅40%的比例类似；90―150平方米的比例合计占到81%，加上150平方米以上13%，全部占到总份量的94%，90平方米以下的仅占到6%。

注：以上数据引自郑州深蓝咨询机构《项目全程营销策划报告》，以下数据是展示接待中心接待来访客户情况的数据统计分析

户型面积 A130.302 B135.767 C122.9 E138.59 F129.31 H141.61 K150.45 其他 合计

数量（组） 30 12 55 61 66 51 45 51 371

客户在提示作用下，除14%的客户选择其他户型外，86%的客户都能在120―150平方米之间选到满意的户型。

户型面积 A130.302 B135.767 C122.9 E138.59 F129.31 H141.61 K150.45 四房 其他 合计

数量（组） 24 20 49 32 41 20 16 43 61 306

客户在提示作用下，选择120平方米以上的占到80%，在其他20%的客户中，除部分选择复式户型的以外，选择其他户型的只有不足20%。

户型面积 90O 110O 120-130O 130-150O 复式及150以上 无具体意向 合计

需要130―150平方米的客户超过40%，而120―130平方米客户占30%，两者合计占到70%左右，是县城购房的主力目标客户群体。复式楼的.需求量也在13%，是县城高端购房人群之一。90―110平方米的人群占到9%左右，可以看作县城购房群体的补充目标人群。

结论：

综上所述，在豫北某县购房群体中，最少有60%以上的客户选择120―150平方米的房子，最高达到86%左右的比例。另有10―20%的客户选择150平方米以上的户型。只有不到10%的少量客户需求面积在90平方米左右或以下。

如果公务员小区的房型面积不能按照市场需求状况供应，将产生以下几点影响：

第一，单套面积较小的商品房非主流市场需求产品，一旦供应，()将只有极少数的目标人群购买，项目开发不可能达到预期的社会效益和经济效益；

第二，由于单套面积较小的房到成本增加，在销售价格不变的情况下，投资回报率降低；同时，在市场需求有限的环境下，将直接影响到开发企业的开发积极性；

第三，由于市场缺乏满足客户需求的产品，将造成市场供应产品的结构极度不平衡，对于目前市场上供应的大户型产品有着较大利好，将有可能进一步抬升房价，造成更多的客户买不起房；

第四，客户选不到适合自己的商品房，将取消或推迟自己的购房计划、或者选择其他的住宅获取途径来解决居住问题，无论对于政府税收、经济发展、扩大内需都有着较大的冲击；

第五，市场供应的商品房都是偏小面积，客户需求都是稍大或较大面积，开发商虽然知道消费者需求，但由于政府限制，不能按市场规律供应满足市场需求的产品，将形成各方均无法满意的局面，将破坏掉构建和谐社会的基础，间接影响到豫北某经济的快速稳定持续发展。

需求分析报告【篇8】

在美食类APP用户需求分析中，主要需要针对消费者、商家等用户进行分析，其中消费者主要是从地理位置、刚需、人群特点等需求方面分析，商家主要是从引流、老会员维系、服务升级等方面需求进行分析。

消费者需求分析

1、地理位置，追求便利：美食类APP出现，其很大的原因是因为其满足了用户追求便利消费的原则，为此在产品设计中通过位置定位技术，为用户提供周边消费服务。

2、吃饱：吃饱是美食类产品的用户需求中最强烈和最刚性的需求，为此在设计中应满足用户吃的需求。

3、价格：一般来说人们希望实现物美价廉的消费，特别是对于价格敏感型人群。

4、人群分析：公司上班族、娱乐消费者、品质追求者、

公司上班族：这类人群的需求特点很简单，在午餐时间主要是会选择里公司较近的餐饮消费场所进行解决吃饭问题。在其选择过程中地利的因素占比较大，其次是饭菜经营的品类。

娱乐消费者：这类消费者主要为年轻人，通常会在闲暇时间外出娱乐逛街消遣，其消费时间以及场所是不固定的，对服务特点、地理位置、环境的要求较高。而价格因素在这一人群的影响较小。

品质追求者：这类用户对于菜品的本身要求不是非常突出，反而对于饭馆的环境、品质和品牌要求较高。

餐饮商家需求分析

1、引流

借助美食类APP实现引流，一个是线上营销思想和思维；而是互联网推广；第三个是基于地理位置的移动互联网推广，由于移动设备的便携性，相对与传统互联网，其营销效果见效快。

2、老会员维系

餐饮领域用户是因为吃饭刚需被聚集起来，为此缺乏话题、优惠券和促销提升推动不了用户活跃度的，为此APP对考会员维系的作用，一方面是降低信息通路成本，通过关注让企业和用户可直接联系。二是方便沟通互动，增加用户活跃度和粘性，线上用户参与话题互动，能够进一步提升用户粘性。

3、服务升级

传统餐饮企业对于顾客的服务内容已经不仅仅满足于在店内就餐的基本需求，而是需要向移动互联网、在线支付等方面进行扩展。为此美食类APP成为传统餐饮企业转型升级的标志，以及服务升级的重要环节，才能够参与移动市场的竞争。

需求分析报告【篇9】

一、项目介绍

1.1编写目的：

本需求分析报告的目的是规范化本软件的编写，旨在于提高软件开发过程中的能见度，便于对软件开发过程中的控制与管理，同时提出了本学校排课系统的软件开发过程，便于程序员与客户之间的交流、协作，并作为工作成果的原始依据，同时也表明了本软件的共性，以期能够获得更大范围的应用，同时它也是进行项目策划、概要设计和详细设计的基础，是维护人员进行内部维护，信息更新，验收和测试的依据。

1.2背景及范围

本项目的名称：学校排课系统。

本项目的任务提出者及开发者是：计算机应用三班张哲，用户是学校。

本产品是针对电脑进行排课的需求设计的，可以完成：基本数据录入与维护、课程表编排、课表冲突分析报告、课表输出、可以直接或导出至Excel打印总课表、教师课表、班级课表、场地课表、系统管理。

1.3定义缩写词

学校排课系统软件：学校排课系统软件是为了帮助学校老师对学校的排课更加方便和快速制作处课程表及其管理学校的课程的软件。

二、项目描述：

使用改程序后，学校的排课可以很轻松的安排好，而却可以尽量避免平时排课时出现的排课冲突，还可以临时加补课等功能。

2.1软件开发的目标：

改善目前有些学校人工排课是常常出现的冲突以及浪费的大量时间。同时也通过实践来提高自己的动手能力。

2.2应用范围：

理论上能实现中小学排课，职业中学排课。

2.3子集说明：

软件主要分为两个模块，一个基本信息的录入，一个是进行排课的管理。

2.4软件功能描述：

外部功能：实现了可视化窗口，排课，调课。

内部功能：基本信息的录入、固定课的设置、科目的录入、年级的录入、任课老师的录入、场地限制的录入和课表的查看；排课操作、调课操作、场地调课操作、老师课表及学生课表生成。

2.5软件操作人员的要求

软件的操作人员要求具有一定的电脑常识，并且具有排课的初步常识。

三、软件结构化描述

自己添加一些

四、环境要求：

4.1数据录入精度需求

在进行向数据库录入数据时，要求数据记录准确。

4.2软件自身时间特性需求

程序排课响应时间：由于生成课表是需要看电脑的配置，所有时间可能会不一样，有时候需要等上几分钟

五、软件属性

5.1可用性

本软件由于自身的能力限制，所有只限现在所有的功能。

5.2安全性

由于软件运行数据放在数据库中，所以参数不容易被错改、破坏，万一参数受到破坏，可以从新录入信息进行更正

5.3可维护性

本软件利用数据库进行编程，系统结构由程序基本确定，大量的参数及文本内容全部放于数据库中。修改、更新数据只要在数据库进行修改添加，而不需要对系统结构进行修改，这样系统维护性十分方便。

5.4兼容性

由于尚未测试，故无法对兼容性进行评析。

需求分析报告【篇10】

需求分析报告

版本：1.0.0

编者年月日 审核年月日 批准年月日

XXX

二〇一四年五月

一、引言

1.1 编写目的对产品或项目进行定义，包括修正或发行版本号。如果这个软件需求规格说明只与整个系统的一部分有关系，那么只定义文档中要说明的部分或子系统。

1.2 背景说明

说明项目或模块开发背景。

1.3 预期读者和阅读建议

列举软件需求规格说明书所针对的不同读者，如用户、设计人员、编程人员、测试人员、项目经理、市场人员等。指出最适合于每一类型读者阅读文档的建议。

1.4 术语定义

解释需求说明书中的术语、名词、简称及缩写等等。

1.5 参考文献

列出所有参考资料、参照的软件名称，包括标题名称、作者、版本号、日期、出版单位或资料来源，以方便读者查阅这些文献。

二、任务概述

2.1 目标

描述项目或业务模块要达到的目标。

2.2 用户特点

描述主要的用户及其特点（教育水平、经验、计算机水平等）。确定可能使用该产品的不同用户类别并描述它们的特征。有些需求可能只与特定的用户类相关。将该产品的重要用户类与那些不太重要的用户类区分开。

2.3 假定和约束

一般约束、假设及对用户的要求。

三、业务功能概要描述

3.1 现有系统分析

对现有系统（包括自动或人工的）进行简要分析。

3.2 业务描述

描述实际业务的过程和特点，即业务建模。

3.3 系统角色

画出系统中的角色，并用文字进行说明。

3.4 主题描述（或：系统用例视图）

画出主题图，描述主题内的业务和主题间的业务。

或用UML语言描绘系统总的用例视图。

3.5 业务流程图

用UML的活动图描绘系统总的业务流程。

3.6 业务接口

3.6.1 外部业务接口

描述与其它项目或业务模块的功能接口。例如：工资模块与考勤、考核、任免、职称等模块的功能接口描述。

3.6.2 内部业务接口

描述各个主题之间的业务接口。

四、业务功能详细描述

用语言和图对每个子系统、主题或业务模块要完成的功能进行完整详细的描述。即功能建模。

4.1 子系统（模块一）

4.1.1 业务功能描述

用文字语言描述子系统、主题或业务模块要完成的功能。

4.1.2 业务流程图

用UML的活动图描绘子系统或业务模块的业务流程，在活动图中标注用到的或输入输出的表格、资料。注意，这里的活动图描述的是该子模块的业务流程。

4.1.3 主题描述及用例视图

若主题下面还含有子主题，则画出主题图，描述主题内的业务和主题间的业务；并且接着画出子系统或业务模块的详细用例视图。

若主题下面不含子主题，则直接画出子系统或业务模块的详细用例视图。

4.1.4 用例描述

对全部用例或主要的用例用文字进行详细描述。

4.1.4.1 用例名称一

【用例功能说明】

用文字详细描述该用例的目的、功能。

【操作描述】

用文字描述子系统或业务模块中主要用例的操作流程和要求。

【活动图、顺序图或协同图】 （可选内容） 用UML的顺序图或协同图描述该用例的操作流程。

【界面原型】 （可选内容）

描绘用户所希望的图形用户界面标准或风格，包括大致的屏幕布局、功能菜单、标准按钮、快捷键、出错信息显示标准等。

4.1.4.2 用例名称二

【用例功能说明】

用文字详细描述该用例的目的、功能。

【操作描述】

用文字描述子系统或业务模块中主要用例的操作流程和要求。

【活动图、顺序图或协同图】 （可选内容） 用UML的顺序图或协同图描述该用例的操作流程。

【界面原型】（可选内容）

描绘用户所希望的图形用户界面标准或风格，包括大致的屏幕布局、功能菜单、标准按钮、快捷键、出错信息显示标准等。

4.1.4.3 用例名称三

。.。 。.。4.1.5 信息项描述

采集子系统或业务模块中用到的信息项，对于非国标、部标的指标项要给予具体解释和规范建议。

推荐描述形式如下：

信息集名称：********

4.2 子系统（模块二）

4.3 子系统（模块三）

五、性能要求

5.1 用户数要求

5.2 业务方面的并发要求

5.3 正常和极端情况下的时间要求

5.4 容错要求

5.5 权限要求

5.6 灵活性要求

当需求发生变化时的适应能力要求。

5.7 使用频度要求

日常使用或定期使用等的描述。

六、其它需求

详细描述本产品/项目必需满足的法令法规、行业规范、合同/标书中的其它要求、以往类似设计中的适用信息以及本公司对此项目附加的其它需求等。

七、附录

对本需求有说明意义的资料：文档、数据、表格、样张等等。

附注：

用例视图、活动图（业务流程图）、主题图、对象图、状态图采用UML标准符号绘制。推荐使用CASE工具如：Ritional Rose画好后再粘贴到Word文档中。

如果时间充裕的话，应在辅助工具中进行业务建模，将非功能需求以及资料部分做为单独文档连接到模型中。

需求分析报告【篇11】

对产品或项目进行定义，包括修正或发行版本号。如果这个软件需求规格说明只与整个系统的一部分有关系，那么只定义文档中要说明的部分或子系统。

说明项目或模块开发背景。

列举软件需求规格说明书所针对的不同读者，如用户、设计人员、编程人员、测试人员、项目经理、市场人员等。指出最适合于每一类型读者阅读文档的建议。

解释需求说明书中的术语、名词、简称及缩写等等。

列出所有参考资料、参照的软件名称，包括标题名称、作者、版本号、日期、出版单位或资料来源，以方便读者查阅这些文献。

描述主要的用户及其特点（教育水平、经验、计算机水平等）。确定可能使用该产品的不同用户类别并描述它们的特征。有些需求可能只与特定的用户类相关。将该产品的重要用户类与那些不太重要的用户类区分开。

一般约束、假设及对用户的要求。

对现有系统（包括自动或人工的）进行简要分析。

描述实际业务的过程和特点，即业务建模。

画出系统中的角色，并用文字进行说明。

画出主题图，描述主题内的业务和主题间的业务。

或用UML语言描绘系统总的用例视图。

用UML的活动图描绘系统总的业务流程。

描述与其它项目或业务模块的功能接口。例如：工资模块与考勤、考核、任免、职称等模块的功能接口描述。

用语言和图对每个子系统、主题或业务模块要完成的功能进行完整详细的描述。即功能建模。

用文字语言描述子系统、主题或业务模块要完成的功能。

用UML的活动图描绘子系统或业务模块的'业务流程，在活动图中标注用到的或输入输出的表格、资料。注意，这里的活动图描述的是该子模块的业务流程。

若主题下面还含有子主题，则画出主题图，描述主题内的业务和主题间的业务；并且接着画出子系统或业务模块的详细用例视图。

若主题下面不含子主题，则直接画出子系统或业务模块的详细用例视图。

对全部用例或主要的用例用文字进行详细描述。

【用例功能说明】 用文字详细描述该用例的目的、功能。

【操作描述】 用文字描述子系统或业务模块中主要用例的操作流程和要求。

用UML的顺序图或协同图描述该用例的操作流程。

描绘用户所希望的图形用户界面标准或风格，包括大致的屏幕布局、功能菜单、标准按钮、快捷键、出错信息显示标准等。

【用例功能说明】 用文字详细描述该用例的目的、功能。

【操作描述】 用文字描述子系统或业务模块中主要用例的操作流程和要求。

用UML的顺序图或协同图描述该用例的操作流程。

描绘用户所希望的图形用户界面标准或风格，包括大致的屏幕布局、功能菜单、标准按钮、快捷键、出错信息显示标准等。

采集子系统或业务模块中用到的信息项，对于非国标、部标的指标项要给予具体解释和规范建议。

推荐描述形式如下：

当需求发生变化时的适应能力要求。

详细描述本产品/项目必需满足的法令法规、行业规范、合同/标书中的其它要求、以往类似设计中的适用信息以及本公司对此项目附加的其它需求等。

附注：

用例视图、活动图（业务流程图）、主题图、对象图、状态图采用UML标准符号绘制。推荐使用CASE工具如：Ritional Rose画好后再粘贴到Word文档中。

需求分析报告模板，将非功能需求以及资料部分做为单独文档连接到模型中。

需求分析报告【篇12】

（一）一、那些人应该参与网站开发项目的需求分析活动

需求分析活动其实本来就是一个和客户交流，正确引导客户能够将自己的实际需求用较为适当的技术语言进行表达（或者由相关技术人员帮助表达）以明确项目目的的过程。这个过程中也同时包含了对要建立的网站基本功能和模块的确立和策划活动。所以项目小组每个成员、客户甚至是开发方的部门经理（根据项目大小而定）的参与是必要的。而项目的管理者在需求分析中的职责有如下几个方面：

1、负责组织相关开发人员与用户一起进行需求分析。

2、组织美术和技术骨干代表或者全部成员（与用户讨论）编写《网站功能描述书（初稿）》文档。

3、组织相关人员对《网站功能描述书（初稿）》进行反复讨论和修改，确定《网站功能描述书》正式文档。

4、如果用户有这方面的能力或者用户提出要求，项目管理者也可以指派项目成员参与，而由用户编写和确定《网站功能描述书》文档。

5、如果项目比较大的话，最好能够有部门经理或者他授权的人员参与到《网站功能描述书》的确定过程中来。

二、完整的需求调查文档记录体系

在整个需求分析的过程中，将按照一定规范的编写需求分析的相关文档不但可以帮助

目成员将需求分析结果更加明确化，也为以后开发过程中做到了现实文本形式的备忘，并且有助于公司日后的开发项目提供有益的借鉴和模范，成为公司在项目开发中积累的符合自身特点的经验财富。

需求分析中需要编写的文档主要是《网站功能描述书》，他基本上是整个需求分析活动的结果性文档，也是开发工程中项目成员主要可供参考的文档。为了更加清楚的描述《网站功能描述书》往往还需要编写《用户调查报告》和《市场调研报告》文档来辅助说明。各种文档最好有一定的规范和固定格式，以便增加其可阅读性和方便阅读者快速理解文档内容，相关规定将在本文后面讨论。

三、向用户调查些什么

在需求分析的工程中，往往有很多不明确的用户需求，这个时候项目负责人需要调查用户的实际情况，明确用户需求。一个比较理想化的用户调查活动需要用户的充分配合，而且还有可能需要对调查对象进行必要的培训。所以调查的计划安排：时间、地点、参加人员、调查内容，都需要项目负责人和用户的共同认可。调查的形式可以是：发需求调查表、开需求调查座谈会或者现场调研。调查的内容主要如下：

1、网站当前以及日后可能出现的功能需求。

2、客户对网站的性能（如访问速度）的要求和可靠性的要求。

3、确定网站维护的要求。

4、网站的实际运行环境。

5、网站页面总体风格以及美工效果（必要的时候用户可以提供参考站点或者由公司向用户提供）。

6、主页面和次级页面数量，是否需要多种语言版本等

7、内容管理及录入任务的分配。

8、各种页面特殊效果及其数量（js,flash等）

9、项目完成时间及进度（可以根据合同）

10、明确项目完成后的维护责任。

调查结束以后，需要编写《用户调查报告》，《报告》的要点是：

1、调查概要说明：网站项目的名称；用户单位；参与调查人员；调查开始终止的时间；调查的工作安排。

2、调查内容说明：用户的基本情况；用户的主要业务；信息化建设现状；网站当前和将来潜在的功能需求、性能需求、可靠性需求、实际运行环境；用户对新网站的期望等。

3、调查资料汇编：将调查得到的资料分类汇总（如调查问卷，会议记录等等）

四、市场调研活动内容

通过市场调研活动，清晰的分析相似网站的性能和运行情况。可以帮助项目负责人更加清楚的构想出自己开发的网站的大体架构和模样，在总结同类网站优势和缺点的同时项目开发人员可以博采众长开发出更加优秀的网站。

但是由于实际中时间、经费、公司能力所限，市场调研覆盖的范围有一定的局限性，在调研市场同类网站的时候，应尽可能调研到所有比较出名和优秀的同类网站。应该了解同类网站的使用环境与用户的诧异点、类似点，同类产品所定义的用户详细需求（需要公司或者项目负责人有一定的关系）。市场调研的重点应该放在主要竞争对手的作品或类似网站作品的有关信息上。市场调研可以包括下列内容：

1、市场中同类网站作品的确定。

2、调研作品的使用范围和访问人群。

3、调研产品的功能设计（主要模块构成，特色功能，性能情况等等）

4、简单评价所调研的网站情况。

调研的目的是明确并且引导用户需求。

对市场同类产品调研结束后，应该撰写《市场调研报告》主要包括一下要点：

1、调研概要说明：调研计划；网站项目名称、调研单位、参与调研、调研开始终止时间。

2、调研内容说明：调研的同类网站作品名称、网址、设计公司、网站相关说明、开发背景、主要适用访问对象、功能描述、评价等

3、可采用借鉴的调研网站的功能设计：功能描述、用户界面、性能需求、可采用的原因。

4、不可采用借鉴的调研网站的功能设计：功能描述、用户界面、性能需求、不可采用的原因。

5、分析同类网站作品和主要竞争对手产品的弱点和缺陷以及本公司产品在这些方面的优势。

6、调研资料汇编：将调研得到的资料进行分类汇总。

五、清晰的需求分析输出——《网站功能描述书》：

在拥有前期公司和客户签订的合同或者是标书的约束之下，通过较为详细具体的用户调查和市场调研活动，借鉴其输出的《用户调查报告》和《市场调研报告》文档，项目负责人应该对整个需求分析活动进行认真的总结，将分析前期不明确的需求逐一明确清晰化，并输出一份详细清晰的总结性文档――《网站功能描述书（最终版）》以供作为日后项目开发过程中的依据。

《网站功能描述书》必须包含以下内容：

1、网站功能

2、网站用户界面（初步）

3、网站运行的软硬件环境

4、网站系统性能定义

5、网站系统的软件和硬件接口

6、确定网站维护的要求

7、确定网站系统空间租赁要求

8、网站页面总体风格及美工效果。

9、主页面及次页面大概数量。

10、管理及内容录入任务分配。

11、各种页面特殊效果及其数量。

12、项目完成时间及进度（根据合同）

13、明确项目完成后的维护责任。

综上所述，在网站项目的需求分析中主要是由项目负责人来确定对用户需求的理解程度，而用户调查和市场调研等需求分析活动的目的就是帮助项目负责人加深对用户需求的理解和对前期不明确的地方进行明确化，以便于日后在项目开发过程中作为开发成员的依据和借鉴。

（二）一、首次调研面积及户型选择意向分析

1、时间：2006年4月5日

2、地点：繁华路段，沿街门面、行政机关单位、事业单位、陌生拦截等处选择样本

3、调研方式：问卷填写、深度访谈

4、发出问卷：80份，有效问卷68份

5、样本人群基本情况

家庭人数：

文化程度：大专以上12人 中学（含高中、初中、中专）40人 其他16人

工作单位：经商或个体户36 事业或行政单位20 其他1

2收入状况：

6、户型结构选择

从图中可以看出，客户对房型结构的选择中，三房两厅的占到高达40%的份额，加上18%的四房两厅和18%的三房一厅，合计占到76%的份额，只有不占1/4的人选择两房或其他户型。

7、户型面积选择

从图中可以看出，客户选择110—130平方米的比例占到35%，与上图中三房两厅40%的比例类似；90—150平方米的比例合计占到81%，加上150平方米以上13%，全部占到总份量的94%，90平方米以下的仅占到6%。

注：以上数据引自郑州深蓝咨询机构《项目全程营销策划报告》，以下数据是展示接待中心接待来访客户情况的数据统计分析

二、2006年5月份客户面积选择意向分析

户型面积 A130.302 B135.767 C122.9 E138.59 F129.31 H141.61 K150.45 其他 合计

数量（组）30 12 55 61 66 51 45 51 37

1客户在提示作用下，除14%的客户选择其他户型外，86%的客户都能在120—150平方米之间选到满意的户型。

三、2006年6月份客户面积选择意向分析

户型面积 A130.302 B135.767 C122.9 E138.59 F129.31 H141.61 K150.45 四房 其他 合计

数量（组）24 20 49 32 41 20 16 43 61 306

客户在提示作用下，选择120平方米以上的占到80%，在其他20%的客户中，除部分选择复式户型的以外，选择其他户型的只有不足20%。

四、2006年7月客户对户型面积的意向分析

户型面积 90㎡ 110㎡ 120-130㎡ 130-150㎡ 复式及150以上 无具体意向 合计

客户量 5 6 34 47 15 8 11

5需要130—150平方米的客户超过40%，而120—130平方米客户占30%，两者合计占到70%左右，是县城购房的主力目标客户群体。复式楼的需求量也在13%，是县城高端购房人群之一。90—110平方米的人群占到9%左右，可以看作县城购房群体的补充目标人群。

结论：

综上所述，在豫北某县购房群体中，最少有60%以上的客户选择120—150平方米的房子，最高达到86%左右的比例。另有10—20%的客户选择150平方米以上的户型。只有不到10%的少量客户需求面积在90平方米左右或以下。

如果公务员小区的房型面积不能按照市场需求状况供应，将产生以下几点影响：

第一，单套面积较小的商品房非主流市场需求产品，一旦供应，()将只有极少数的目标人群购买，项目开发不可能达到预期的社会效益和经济效益；

第二，由于单套面积较小的房到成本增加，在销售价格不变的情况下，投资回报率降低；同时，在市场需求有限的环境下，将直接影响到开发企业的开发积极性；

第三，由于市场缺乏满足客户需求的产品，将造成市场供应产品的结构极度不平衡，对于目前市场上供应的大户型产品有着较大利好，将有可能进一步抬升房价，造成更多的客户买不起房；

第四，客户选不到适合自己的商品房，将取消或推迟自己的购房计划、或者选择其他的住宅获取途径来解决居住问题，无论对于政府税收、经济发展、扩大内需都有着较大的冲击；

第五，市场供应的商品房都是偏小面积，客户需求都是稍大或较大面积，开发商虽然知道消费者需求，但由于政府限制，不能按市场规律供应满足市场需求的产品，将形成各方均无法满意的局面，将破坏掉构建和谐社会的基础，间接影响到豫北某经济的快速稳定持续发展。

（三）相关资料数据以广州为例分析其人才需求状况，供广大求职者和有兴趣的朋友参考。

一、招聘热度 分析

自金融危机以后我国服装产量的持续低增幅，企业对产量增长的谨慎态度。近来欧盟纺织品服装市场需求低迷、部分市场向竞争对手国转移造成了国内服装企业的发展困境。就今年上半年而言，服装行业的人才需求并不十分给力，反映出服装行业整体发展缓慢。

从上图看，广州服装行业招聘职位数浮动不明显，6月低谷期后，7月略有所回升。业内人士分析认为，外贸形势短期内难有明显起色，但是随着欧美服装消费旺季的来临，第三季度服装出口或将有所回升。预计其人才需求也会有所增加。

二、招聘职位分析

据百才招聘网数据统计，7月份广州服装行业发布职位超过一万，仅次于上海。其中，美术/设计/创意类职位占29.01%，其次是销售类、经营管理类职位，占比分别为12.40%、11.78%。招聘职位中，以服装设计师、设计助理招聘职位数最多，占比均超过了15%。

三、招聘要求分析

根据分析，目前服装行业的人才学历要求较其他行业要略低，就广州招聘职位而言，其高中及以下学历占比达28.83%，本科仅占12.42%。从经验要求分析，0——2年、3——5年工作经验者需求量持平，均超40%。可以看出在服装行业人才对经验的要求较学历而言更严格。

四、行业薪酬 分析

根据数据显示，广州服装业整体薪酬水平居中，高薪占比比较小。薪资2000——3999元/月占比最大，达51.20%，万元及以上的月薪仅占比9.63%。这可能与服装行业整体产业性质相关，服装企业工厂员工占比较大，行业整体薪酬分布应该不会有太大的浮动。

感谢您阅读“幼儿教师教育网”的《需求分析报告》一文，希望能解决您找不到幼师资料时遇到的问题和疑惑，同时，yjs21.com编辑还为您精选准备了需求分析报告专题，希望您能喜欢！