游戏制作需要哪些人？_软件运维

1：美工编辑，制作视频，音频，图片等信息。

2：工程编程，处理地图层次和任务立体效果。

3：游戏策划，处理游戏玩家主路线，故事发展背景。

4：游戏推广员，负责游戏专门推广宣传。

5：游戏管理员，处理线上互动活动。

6：游戏客服，处理玩家建议，问题，投诉等。

7：游戏服务机房维护，维护游戏服务器内数据及检修更新。

8：游戏编程，最主要的人员，负责游戏内部程序编程，BUG修复等

游戏制作流程

一、计划阶段

1、创意管理：第一步，是召开个会议，在会议中最常见的方法就是采取“头脑风暴法”。每个人都必须拿出自己的建议和想法，之后大家一起进行讨论。另外在会场内，会有专人进行会议记录。而在项目开发的前期则会有市场调查。

2、撰写草案：第二步，撰写策划草案，也叫意向书。撰写策划草案的目的在于，使得小组内每个成员对即将开发的项目有一个大体的认识，并且对目标进行明确。

3、市场分析：第三步，市场分析。

1）、目标客户：最重要的一点是确定目标客户。即该游戏是面向核心玩家，还是普通的大众玩家。如果是面向核心玩家所开发的游戏，则需要游戏的难度更大一些；反之，如果是面向大众玩家开发的游戏，则需要游戏的难度简单一些。最好的方法是允许玩家自定义游戏的难度。

2）、成本估算：以网游为例，包括以下几个方面

①服务器：运行网络游戏所需花费的硬件方面的成本。成本中的大头。大约占到总成本的40％左右。

②客服：属于人力成本的范畴。网络游戏不同于单机游戏的部分在于，其不同于单机游戏的“售后不理”的销售模式。用户在玩这个游戏之后，运营商需要不断的提供更新和各种在线服务。

③开发团队：人力成本，这方面花费的真正大头在核心成员和天才制作人的薪资上。

④管理：管理方面花费的成本，这方面成本较少。

⑤用户帐号管理：发行成本的一部分，但也属于运营的范畴。至于成本几乎可以忽略不计。

⑥办公室、电脑、家具：这方面是大头，不过这次花费之后，开发下部游戏时基本上花费就不需要或者很少花费了。

⑦带宽：发行成本的一部分，但也属于运营的范畴。成本也是极高的，当然各地可能都不一样。

⑧宣传、广告和推广的费用：属于运营成本。应该说最好的宣传方法就是广告，但各种广告在花费上都不尽相同，这个就不细说了。

⑨客户端：制作游戏客户端、点卡、充值卡、印制游戏说明书、游戏包装、游戏赠品一类的成本。

⑩其他花费。

4、需求分析：第四步，撰写需求分析书。这包括以下三个方面：

1）、美工需求：撰写美工需求分析书，内容包括需求图、工作量等。其中工作量需要以天来计。内容具体如下：

①场景：包括游戏地图、小场景等方面。

②人物：包括玩家角色、重要NPC（玩家队友、提供任务的NPC、主线剧情NPC等）、次要NPC（路人、村民等）、怪物、BOSS等。

③动画：动画方面估计每个公司的需求都不尽相同。如果公司能力有限，动画的制作可以考虑外包的方式。

④道具：主要需要考虑是否采取纸娃娃系统。

⑤全身像：人物的全身像方面。

⑥静画&ampCG：游戏中可能出现的静画和CG的需求。没有则不需要写。

⑦人物头像：人物的头像制作需求，其中包括人物的表情方面，包括喜、怒、哀、乐、悲等多种表情。

⑧界面：界面的需求，包括主界面、各项子界面、屏幕界面、开头界面、END界面、保存和载入界面等方面。

⑨动态物件：包括游戏中可能出现的火把、光影等方面。

⑩卷轴：又称为滚动条。根据游戏的情况来定具体的需求。

⑪招式图：根据游戏开发的具体情况决定是否有此需求。

⑫编辑器图素：各种编辑器的图素需求，例如关卡编辑器、地图编辑器等方面。

⑬粒子特效：3D粒子特效的需求。

⑭宣传画；包括游戏的宣传画、海报等方面的制作需求。

⑮游戏包装：游戏客户端的封面包装的制作。

⑯说明书插图：游戏说明书内附插图的制作需求。

⑰盘片图鉴：游戏客户端盘片上的图鉴的制作需求。

⑱官方网站：游戏官方网站的制作需求。

2）、程序需求：撰写程序需求分析书，内容具体如下：

①地图编辑器：包括编辑器的功能需求、各种数据的需求等。

②粒子编辑器：关于粒子编辑器的需求。

③内镶小游戏：包括游戏内部各种小游戏的需求。

④功能函数：包括游戏中可能会出现的各种程序功能、技术参数、数据、碰撞检测、AI等方面的需求。

⑤系统需求：包括升级系统、道具系统、招式系统等系统导入器的需求。

3）、策划需求

①策划的分工：包括剧本、数值、界面、执行等方面。

②进度控制：要时刻注意时间和开发进度的控制，需要写一个专门的项目进度表。

③例会：项目会以里程碑的形式呈现。当完成一个里程碑后，或者到达固定日期时，需要召开例行会议，除了成员彼此交流外，还需讨论开发中遇到的困难，进度是否有拖延等问题。

二、组织阶段：其次，是项目组织阶段。

1、确定日程：确定游戏开发的日程和进度安排。包括以下几个方面：

1）Demo版本阶段

①前期策划：前期策划和项目的规划。

②关卡设计：关卡设计阶段。

③前期美工：前期的美工制作。

④后期美工：后期的美工制作。

⑤程序实现：程序的实现，包括编码等。

2）Alpha版本阶段

内部测试：主要是测试和完善各项功能，看一看是否有重大BUG。

3）Beta版本阶段

·外部测试：进一步测试和完善各项功能，并预备游戏的发行。

4）Release版本阶段

·游戏发行：项目完成阶段，开始正式的发行游戏。

5）Gold Release版本阶段

1、开发补丁：开发游戏的补丁包、升级版本，以及各种官方插件等。

2、确定人员：确定各个项目所需的人员。包括策划、程序、美工、测试、音乐、运营等方面。

3、分配任务：分配各个人员的具体的开发任务。

4、撰写策划书：正式撰写游戏策划书。

三、开发阶段：其三，是项目开发阶段。

此阶段主要需做到同各方面保持顺畅的沟通，并处理各种游戏制作中的突发事件。其中需要做到与同事的沟通、同主管的沟通、同领导和老板的沟通等。

四、控制阶段：最后，是项目控制阶段。

1、时间

1）、成本控制：需要注意到开发成本的控制，包括服务器、客服、场租、人工（社区关系专员、开发团队、管理）、设备（办公室、电脑、家具等）、带宽、网管、宣传、广告和推广的费用等方面。

2）、市场变化：需要注意市场的因素。

①发行档期：需要注意发行档期，要赶在暑假和寒假之前发行。

②盗版因素：必须时刻注意盗版、私服等因素对游戏发行的影响。

3）、竞争对手的因素：需要时刻注意竞争对手的情况。毕竟，知己知彼，才能百战不殆。

2、品质

由于开发人员的水平大都参差不齐，所以必须根据制作人员的总体水平，决定作品的品质。既不能要求太高，亦不能要求太低，需要折中考虑。

问题一：什么是需求分析，其目标是什么？《软件工程》需求分析就是了解、判断用户需要什么、想最终达到工么目的、怎么实现，为你们提 *** 品、服务、项目等提供目标和检验标准

问题二：如何系统的进行用户需求分析 1.概念

需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求.

关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起.系统的分析人员说:我们想与你谈谈你的需求.客户的第一反应便是:我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统.

百事通

而实际上,UGGs,需求并未编写成文档,因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白用户的需求,那完全是自欺欺人.

需求的另外一种定义认为需求是用户所需要的并能触发一个程序或系统开发工作的说明.有些需求分析专家拓展了这个概念:从系统外部能发现系统所具有的满足于用户的特点、功能及属性等.这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性:

需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性,是在开发过程中对系统的约束.

从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的需求术语存在,真正的需求实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.

任何文档形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述.

2.需求分析的任务

开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难.

目前,国内产品的庞杂,一家企业可能有几个系统并立运行,它们之间接口是系统开发人员最头痛的问题.

对于商业最终用户应用程序,企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说,并没有编写出客户认可的需求文档,我们如何知道项目于何时结束?而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢?

然而,即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发生.

近来,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是,当他们开发完这个工具后,发现这个工具不能打印出源代码文件,使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确,如果我们没有编写文档,软件达不到期望目标也只能是咎由自取了.

相反的情况,我曾见一个要集成到错误跟踪系统中的简单界面写了一页需求说明.而 *** 作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误.

事实上,需求文档在开发过程中一直起指导作用.

3.需求分析过程

可把整个软件需求工程......>>

问题三：需求分析解决的问题是系统必须做什么你好

解决的问题是做什么的问题

如果您对我的回答有不满意的地方，请您继续追问；

答题不易，互相理解~

问题四：需求分析的作用及如何进行需求分析通过对应问题及其环境的理解与分析，为问题涉及的信息、功能及系统行为建立模型，将用户需求精确化、完全化，最终形成需求规格说明，这一系列的活动即构成软件开发生命周期的需求分析阶段。

需求分析是介于系统分析和软件设计阶段之间的桥梁。一方面，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。

需求工程是随着计算机的发展而发展的，在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，需求分析很少受到重视。后来软件开发引入了生命周期的概念，需求分析成为其第一阶段。随着软件系统规模的扩大，需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。80年代中期，形成了软件工程的子领域――需求工程(requirementengineering,RE)。进入90年代以来，需求工程成为研究的热点之一。从1993年起每两年举办一次需求工程国际研讨会(ISRE)，自1994年起每两年举办一次需求工程国际会议(ICRE)，在1996年Springer-Verlag发行了一新的刊物――《RequirementsEngineering》。一些关于需求工程的工作小组也相继成立，如欧洲的RENOIR(RequirementsEngineeringNetworkofInternationalCooperatingResearchGroups)，并开始开展工作。需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。RE可分为系统需求工程（如果是针对由软硬件共同组成的整个系统）和软件需求工程（如果仅是专门针对纯软件部分）。软件需求工程是一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数。

需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。80年代，HerbKrasner定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理。近来，MatthiasJarke和KlausPohl提出了三阶段周期的说法：获取、表示和验证。

综合了几种观点，可以把需求工程的活动划分为以下5个独立的阶段：

（1）需求获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求；

（2）需求建模：为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义；

（3）形成需求规格：生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约；

（4）需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性；

（5）需求管理：支持系统的需求演进，如需求变化和可跟踪性问题。...>>

问题五：什么是软件需求，什么是功能需求？我们的软件产品或者项目，其需求都有三个层级和三个方面。一、我们首先看需求的三个层次软件需求包括3个不同的层次DD业务需求、用户需求和功能需求。业务需求（Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件DD响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。注意：用户需求不总是被转变成功能需求。产品特性，所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。系统需求（system requirement）用于描述包含有多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。业务规则包括企业方针、 *** 条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。功能需求记录在软件需求规格说明（SRS）中。SRS完整地描述了软件系统的预期特性。SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS。除此之外，对于需求层次，我们还有其它的分法：组织级需求->业务需求->用户需求->功能需求（有时也叫行为需求）。组织级需求：一般代表着组织的愿景和目标。对于大的公司，一般是通过资深的咨询顾问和咨询公司得出的，呈现的方式是咨询报告。比如在ITSM或者企业信息化这方面。典型的组织级的需求是：降低成本、减少库存成本、提升IT服务部门在企业中的价值、通过ISO20000、提高IT服务的效率、提高员工的满意度等。业务需求：是要完组织的使命，达成组织的愿景的各个业务流程和业务单元具有的需求。业务需求服从于组织需求。用户需求：用户级的需求，是在业务级的需求下，各个岗......>>

问题六：如何写系统需求分析学生选课系统需求分析第一部分需求分析 1．系统功能模块基本划分本系统划分为三个子系统：系统管理系统：系统维护学生选课系统：学生选课 *** 作教师查询系统：学生选课情况查询 2．系统维护 2 1 2． 1 ． 1 ．学生基本资料维护目标：针对学生的基本资料进行添加、删除、更新、查询。 2． 1 ． 2．学生基本资料维护概述：前提条件：管理员要对学生基本资料进行添加、删除、更新或查询。角色：各级别的系统管理员输入：学生基本属性（学号、姓名、系部、班级、密码、选课总学分）。基本流程：登录管理员系统→验证当前用户权限→选择“学生基本资料维护” →管理员添加、删除或修改更新→验证输入或修改的数据→验证通过：更新数据库，验证不通过：给出提示信息要求用户重新输入。输出：学生基本资料报表。 2 2 2． 2． 1 ．教师基本资料维护目标：针对教师的基本资料进行添加、删除、更新、查询。 2． 2． 2．教师基本资料维护概述：前提条件：管理员要对教师基本资料进行添加、删除、更新或查询。角色：各级别的系统管理员输入：教师基本资料（工号、姓名、系部、密码、相关资料）基本流程：登录管理员系统→验证当前用户权限→选择“教师基本资料维护” →管理员添加、删除或修改更新→验证输入或修改的数据→验证通过：更新数据库，验证不通过：给出提示信息要求用户重新输入。输出：教师基本资料报表。 2 3 2． 3． 1 ．课程基本资料维护目标：针对课程的基本资料进行添加、删除、更新、查询。 2． 3． 2．课程基本资料维护概述：前提条件：管理员要对课程基本资料进行添加、删除、更新或查询。角色：二级系统管理员输入：课程基本资料（课程号、课程名、课程简介、上课时间、上课地点、学时、学分、人数上线、当前人数、教师号）基本流程：登录管理员系统→验证当前用户权限→选择“课程基本资料维护” →管理员添加、删除或修改更新→验证输入或修改的数据→验证通过：更新数据库，验证不通过：给出提示信息要求用户重新输入。输出：课程详细资料。 2 4 2． 4． 1 ．系部资料维护目标：针对系部资料进行添加、删除、更新、查询。 2． 4． 2．系部维护概述：前提条件：管理员要对系部资料进行添加、删除、更新或查询。角色：一级系统管理员输入：系部资料（系号、系名称）基本流程：登录管理员系统→验证当前用户权限→选择“系部资料维护” →管理员添加、删除或修改更新→验证输入或修改的数据→验证通过：更新数据库，验证不通过：给出提示信息要求用户重新输入。输出：无 2 5 2． 5． 1 ．管理员维护目标：设置各级管理员权限 2． 5． 2．管理员维护概述：前提条件：角色：一级管理员输入：管理员权限基本流程：登录系统→验证权限→设置管理员权限→验证设置→成功更新或失败返回输出： 2 6 2． 6． 1 ．修改密码目标：正确的修改管理员登录密码 2． 6． 2．修改密码概述：前提条件：用旧密码正确登录角色：各级管理员输入：旧密码、新密码、验证密码基本流程：登录选课系统→验证权限→输入旧密码、新密码、验证密码提交→验证旧密码是否正确、新密码和验证密码是否相同→成功或失败（一天内不能超过3 次）输出：成功或失败信息 2 7 2． 7． 1 ．系统设置目标：通过系统设置来修改系统环境变量 2 ． 7 ． 2 ．系统设置 ......>>

问题七：系统设计和需求分析的关系是什么？？急求 2012-4-27 12:19 满意回答网络规划与需求分析需求分析从字面上的意思来理解就是找出需和求的关系,从当前业务中找出最需要重视的方面,从已经运行的网络中找出最需要改进的地方,满足客户提出的各种合理要求,依据客户要求修改已经成形的方案.本章重点2.1需求分析的类型2.2如何获得需求2.3可行性论证2.4工程招标与投标2.2.1应用背景分析应用背景需求分析概括了当前网络应用的技术背景,介绍了行业应用的方向和技术趋势,说明本企业网络信息化的必然性. 应用背景需求分析要回答一些为什么要实施网络集成的问题.(1) 国外同行业的信息化程度以及取得哪些成效 (2) 国内同行业的信息化趋势如何 (3) 本企业信息化的目的是什么 (4) 本企业拟采用的信息化步骤如何需求分析的类型P332.2.1应用背景分析应用背景需求分析要回答一些为什么要实施网络集成的问题.(1) 国外同行业的信息化程度以及取得哪些成效 (2) 国内同行业的信息化趋势如何 (3) 本企业信息化的目的是什么 (4) 本企业拟采用的信息化步骤如何需求分析的类型P332.2.2业务需求业务需求分析的目标是明确企业的业务类型,应用系统软件种类,以及它们对网络功能指标(如带宽,服务质量QoS)的要求.业务需求是企业建网中首要的环节,是进行网络规划与设计的基本依据. 需求分析的类型P332.2.2业务需求通过业务需求分析要为以下方面提供决策依据:(1) 需实现或改进的企业网络功能有那些(2) 需要集成的企业应用有哪些 (3) 需要电子邮件服务吗 (4) 需要Web服务吗 (5) 需要上网吗带宽是多少 (6) 需要视频服务吗 (7) 需要什么样的数据共享模式 (8) 需要多大的带宽范围 (9) 计划投入的资金规模是多少需求分析的类型P332.2.3管理需求网络的管理是企业建网不可或缺的方面,网络是否按照设计目标提供稳定的服务主要依靠有效的网络管理.高效的管理策略能提高网络的运营效率,建网之初就应该重视这些策略.需求分析的类型P342.2.3管理需求网络管理的需求分析要回答以下类似的问题:是否需要对网络进行远程管理,远程管理可以帮助网络管理员利用远程控制软件管理网络设备,使网管工作更方便,更高效.谁来负责网络管理需要哪些管理功能,如需不需要计费,是否要为网络建立域,选择什么样的域模式等需求分析的类型P342.2.3管理需求选择哪个供应商的网管软件,是否有详细的评估选择哪个供应商的网络设备,其可管理性如何需不需要跟踪和分析处理网络运行信息将网管控制台配置在何处是否采用了易于管理的设备和布线方式需求分析的类型P342.2.4安全性需求企业安全性需求分析要明确以下几点:企业的敏感性数据的安全级别及其分布情况网络用户的安全级别及其权限可能存在的安全漏洞,这些漏洞对本系统的影响程度如何网络设备的安全功能要求需求分析的类型P342.2.4安全性需求网络系统软件的安全评估应用系统安全要求采用什么样的杀毒软件采用什么样的防火墙技术方案安全软件系统的评估网络遵循的安全规范和达到的安全级别.需求分析的类型P342.2.5通信量需求通信量需求是从网络应用出发,对当前技术条件下可以提供的网络带宽做出评估.需求分析的

问题八：解决方案和需求分析还有系统设计有什么区别方案是整体的说明

需求是系统要做什么

系统设计是说要怎么做

问题九：软件需求分析的需求类型下面这些定义是需求工程领域中常见术语的定义。软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。1．业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。2．用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例（usecase）文档或方案脚本说明中予以说明。3．功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。在软件需求规格说明书（SRS）中说明的功能需求充分描述了软件系统所应具有的外部行为。软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对一个大型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统（或软件部件）。作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的 *** 作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。下面以一个子处理程序为例来说明需求的不同种类。业务需求可能是：“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的 *** 作；显示提供替换词的对话框以及实现整个文档范围的替换。从以上定义可以发现，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。项目也有其它方面的需求，如开发环境需求或发布产品及移植到支撑环境的需求。尽管这些需求对项目成功也至关重要，但它们并非本书所要讨论的。

《老版本希赛视频》百度网盘资源免费下载

链接:https://pan.baidu.com/s/1DW9M-8FhSfGEx2HskMt6_g

提取码:stuv

欢迎分享，转载请注明来源：内存溢出

原文地址: http://outofmemory.cn/yw/12056290.html

游戏制作需要哪些人？

发表评论

评论列表（0条）