疯子84045784
如何系统的进行用户需求分析
项目管理以及相关项目功能中都起了重要的作用："：定义需求基线（迅速制定需求文档的主体），因为另外一些可能属于子系统（或软件部件）.作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等.它包括产品必须遵从的标准，即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价，这些血的教训正在国内的软件开发者身上发生.结果这个小组只好手工抄写源代码文档以供代码检查.客户的接受仅是需求成功的一半，开发人员也必须能够接受他们，并真正把需求应用到产品中.1.这种合同都包含在编写的需求文档与模型中，现在我要的就是给我编一个系统"，这在使用实例（use case）文档或方案脚本说明中予以说明.3.功能需求（functional requirement）定义了开发人员必须实现的软件功能.需求分析的任务开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口.他们依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误.事实上，需求文档在开发过程中一直起指导作用.3.需求分析过程可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适.估计变更需求所产生影响并在此基础上协商新的承诺.分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、评价、编写文档等所有活动.需求开发活动包括以下几个方面，当他们开发完这个工具后.同时这也是一旦做错.将所收集的用户需求编写成文档和模型、产品高层次的目标要求，它们在项目视图与范围文档中予以说明.2.用户需求（user requirement） 文档描述了用户使用产品必须要完成的任务、用户需求和功能需求（也包括非功能需求）.将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件，如图4-1所示，而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性：需求是指明必须实现什么的规格说明.了解相关质量属性的重要性.商讨实施优先级的划分.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚.需求管理需要＂建立并维护在软件工程中同客户达成的合同"，发现这个工具不能打印出源代码文件，使用者当然希望有这个功能；性能要求；设计或实现的约束条件及质量属性.所谓约束是指对开发人员在软件产品设计和构造上的限制.质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能.多角度描述产品对用户和开发人员都极为重要.下面以一个字处理程序为例来说明需求的不同种类.业务需求可能是：＂用户能有效地纠正文档中的拼写错误＂，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器.而对应的用户需求可能是＂找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词＂.同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换.从以上定义可以发现，需求并未包括设计细节、实现细节、项目计划信息或测试信息.需求与这些没有关系，它关注的是充分说明你究竟想开发什么.项目也有其它方面的需求，如开发环境需求或发布产品及移植到支撑环境的需求.尽管这些需求对项目成功也至关重要，但它们并非本书所要讨论的.5.需求分析的原则不重视需求过程的项目队伍将自食其果.需求工程中的缺陷将给项目成功带来极大风险，这里的＂成功＂是指推出的产品能以合理的价格、及时地在功能、质量上完全满足用户的期望.下面将讨论一些需求风险.不适当的需求过程所引起的一些风险：1. 无足够用户参与客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视用户的参与.究其原因：一是因为开发人员感觉与用户合作不如编写代码有意思；二是因为开发人员觉得已经明白用户的需求了.在某些情况下，与实际使用产品的用户直接接触很困难，而客户也不太明白自己的真正需求.但还是应让具有代表性的用户在项目早期直接参与到开发队伍中，并一同经历整个开发过程.系统人员在实践过程中，也有些感觉，在实施一家公司的项目时，若无足够的用户参与，系统人员获得的需求是片面的，不完整的，这样系统在需求之初就埋下风险.2. 用户需求的不断增加在开发中若不断地补充需求，项目就越变越庞大以致超过其计划及预算范围.计划并不总是与项目需求规模与复杂性、风险、开发生产率及需求变更实际情况相一致，这使得问题更难解决.实际上，问题根源在于用户需求的改变和开发者对新需求所作的修改.要想把...
软件项目获取用户需求的一些沟通技巧有哪些呢？
软件开发生命周期包含需求、设计、编码和测试四个过程阶段，其中需求过程是第一个也是最重要的一个阶段。
软件需求包括三个不同的层次：业务需求，说明了提供给客户和产品开发商的新系统的利益，反映了组织机构或客户对系统、产品高层次的目标要求，它们将在项目视图与范围文档中予以说明；用户需求，描述了用户使用系统必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明；功能需求和非功能需求，定义了开发人员必须实现的软件功能，使得用户能顺利完成他们的任务，从而满足了业务需求。
软件需求过程包括了5个主要活动：需求获取、需求分析和确认、编写需求规格说明书、需求验证和需求管理。
需求获取 需求的收集、分析、细化、核实并组织的步骤，并将它编写成文档。
这个活动包括了编写项目视图和范围文档、用户群分类、选择用户代表、建立核心队伍、确定使用实例、召开联合会议、分析用户工作流程、确定质量属性、检查问题报告和需求重用10个具体任务，文章将在后面进行详细的阐述。
需求分析 根据需求获取中得到的需求文档，分析系统实现方案。
这个活动需要完成下面几个任务： 1、绘制关联图，用于定义系统与系统外部实体间的边界和接口的简单模型； 2、创建开发原型，当开发人员或用户不能明确某些需求时，开发一个系统原型，这样使得许多概念和可能发生的事更为直观明了； 3、分析可行性，在允许的成本、性能要求下，分析每项需求实施的可行性，明确每项需求实现相联系的风险，包括与其它需求的冲突，涉及各类用户的利益平衡，对外界因素的依赖和技术障碍； 4、确定需求优先级：分析方法来确定使用实例、系统特性或单项需求实现的优先级别，以优先级为基础确定产品版本将包括哪些特性或哪类需求； 5、为需求建立模型，为需求建立图形分析模型是软件需求规格说明极好的补充说明，可以为系统需求从多个角度建模； 6、编写数据字典，创建数据字典数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义； 7、应用质量功能调配，将系统特性、属性与对客户的重要性联系起来，提供了一种分析方法以明确哪些是客户最为关注的特性。
编写需求规格说明书 需求开发的最终成果是客户和开发小组对将要开发的产品达成一致协议，这一协议就是通过文档化的需求规格说明书来体现。
需求规格说明书包括项目视图和范围文档说明了系统的业务需求，而使用实例文档则说明了用户需求。
这个活动需要完成下面几个任务： 1、采用模版，在你的组织中要为编写软件需求规格说明书等文档定义一种标准模板，该模板为记录系统需求和各种其它与需求相关的重要信息提供了统一的结构； 2、指明需求来源，为了让所有项目风险承担者明白需求规格说明书中为何提供这些功能需求，要能追溯每项需求的来源，来源可能是一种使用实例或其它客户要求，也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源，这些来源应该记录在需求的跟踪能力矩阵中； 3、为每项需求注上标号，为了需求的可跟踪性和可修改性的质量标准，必须唯一确定每个软件需求，为制定一种惯例来为需求规格说明书中的每项需求提供一个独立的可识别的标号或记号； 4、记录业务规范，是指关于系统的操作原则，比如谁能在什么情况下采取什么动作，将这些编写成需求规格说明书中的一个独立部分，或一独立的业务规范文档； 5、创建需求跟踪能力矩阵，建立一个矩阵把每项需求来源、定义与实现、测试它的设计和代码部分联系起来，这样有利于需求的管理和需求变更影响范围的评估。
AfterEffects(AE)软件是面向哪些用户需求的？问：A
问：Afte Effects(AE)软件面向哪些用户需求答：视频特效师用户影视行业企业用户问：AE作期合工具软件哪些软件跟AE互相补充答：AE特效合软件般剪辑软件（Pemiee、EDIUS等） 三维软件（max、MAYA XSI）等相互配合完影片制作问：AE与视频剪辑工具（AVID、EDIUS等）区别答：工种同： 1.ae属于特效合工种：起作用：美化视频与三维软件配合完些拍摄能完镜.（新闻联播片 2012电影楼倒塌 洪水蔓延等） 2.AVID、EDIUS些属于剪辑工种：起作用：独立镜组接起作用问：叫做绿屏蓝屏抠像AE用特效实现答：蓝色屏幕除掉剩独立物加球 星空 海洋等背景实现空间穿越使用AE知名抠像工具keylight完美实现 问：绿屏蓝屏幕抠像面向哪些需求答：拍摄实现镜：例：星空漫游悬崖跌落未都市行走仙花瓣飞等等行太累耗费青春与命男举掉发熬夜像鬼外行像才内行农民工工种论三维特效剪辑都属于影视行业底层永远都属于压榨象要再向火坑跳实行读导演班或者编导班
软件工程的需求分析阶段主要要完成哪些工作
1. 确定需求调研对象。
2. 制定需求调研计划，以一般会议记录的方式即可。
3. 分析用户需求。
显化用户需求与软件规格的差异（有些用户需求点能完全通过软件功能去满足，有些用户需求点只能通过软件功能部分地满足，有些用户需求点不通过软件功能去实现）对用户需求的优先级进行排序。
4. 制定用户需求规格说明书，系统需求规格说明书。
或者软件需求规格说明书。
5. 做好需求问题管理表（整个需求过程中，需跟进、协调的重要问题）。
怎样做软件的需求分析？
软件需求的定义：（1）用户解决问题或达到目标所需的条件或能力。
（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。
实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。
需求工程的定义：需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。
需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情况获取、分析、制订规格说明和评审。
这四个阶段不一定是遵循线性顺序的，他们的活动是相互独立和反复的。
需求管理是软件项目开发过程中控制和维持需求约定的活动，它包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。
需求开发与管理的一些方法：（1）绘制关联图：绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。
（2）可行性分析：在允许的成本、性能要求下，分析每项需求实施的可行性，提出需求实现相关风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。
（4）系统原型：当用户自身对有的需求不十分清楚时，我们可以建立一个系统原型，用户通过评价原型更好地理解所要解决的问题。
。
（5）图形分析模型：绘制图形分析模型是编制软件需求规格说明重要手段。
它们能帮助分析人员理清数据、业务模式、工作流程以及他们之间的关系，找出遗漏、冗余和不一致的需求。
这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
（6）数据字典：数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。
在需求阶段，数据字典至少应定义客户数据项，确保客户与开发小组是使用一致的定义和术语。
需求管理的方法主要包括以下一些方面：1）确定需求变更控制过程。
制定一个选择、分析和决策需求变更的过程，所有的需求变更都需遵循此过程。
2）进行需求变更影响分析。
评估每项需求变更，以确定它对项目计划安排和其它需求的影响，明确与变更相关的任务并评估完成这些任务需要的工作量。
通过这些分析将有助于需求变更控制部门做出更好的决策。
3）建立需求基准版本和需求控制版本文档。
确定需求基准，这是项目各方对需求达成一致认识时刻的一个快照，之后的需求变更遵循变更控制过程即可。
每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。
4）维护需求变更的历史记录。
将需求变更情况写成文档，记录变更日期、原因、负责人、版本号等内容，及时通知到项目开发所涉及的人员。
为了尽量减少困惑、冲突、误传，应指定专人来负责更新需求。
5）跟踪每项需求的状态。
可以把每一项需求的状态属性（如已推荐的，已通过的，已实施的，或已验证的）保存在数据库中，这样可以在任何时候得到每个状态类的需求数量。
6）衡量需求稳定性。
可以定期把需求数量和需求变更（添加、修改、删除）数量进行比较。
过多的需求变更＂是一个报警信号＂，意味着问题并未真正弄清楚。
4.需求分析评价标准（1）清晰：目前大多数的需求分析采用的仍然是自然语言，自然语言对需求分析最大的弊病就是它的二义性，所以开发人员需要对需求分析中采用的语言做某些限制。
例如尽量采用主语+动作的简单表达方式。
需求分析中的描述一定要简单，千万不要采用疑问句、修饰这些复杂的表达方式。
除了语言的二义性之外，注意不要使用行话，就是计算机术语。
需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。
（2）完整：需求的完整性是非常重要的，如果有遗漏需求，则不得不返工，在软件开发过程中，最糟糕的事情莫过于在软件开发接近完成时发现遗漏了一项需求。
但实际情况是，需求的遗漏是常发生的事情，这不仅仅是开发人员的问题，更多发生在用户那里。
要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各个方面，贯穿整个过程，从最初的需求计划制定到最后的需求评审。
（3）一致：一致性是指用户需求必须和业务需求一致，功能需求必须和用户需求一致。
在需求过程中，开发人员需要把一致性关系进行细化，比如用户需求不能超出预前指定的范围。
严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。
（4）可测试：一个项目的测试从什么时候开始呢？有人说是从编码完成后开始，有人说是编码的时候同时进行单元测试，编码完成后进行系统测试，这些结论都不完全正确。
实际上，测试是从需求分析过程就开始了，因为需求是测试计划的输入和参照。
这就要求需求分析是可测试的，只有系统的所有需求都是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。
什么是软件需求,什么是功能需求？
1 引言。
1编写目的： 可行性研究的目的是为了对问题进行研究，以最小的代价在最短的时间内确定问题是否可解 经过对此项目进行详细调查研究，初拟系统实现报告，对软件开发中将要面临的问题及其解决方案进行初步设计及合理安排。
明确开发风险及其所带来的经济效益。
本报告经审核后，交软件经理审查。
1.2 项目背景： 开发软件名称：超市进销存系统。
项目任务提出者：老师。
项目开发者：shu408157847。
用户：超市。
实现软件单位：学校 项目与其他软件，系统的关系： 本项目采用客户机/服务器原理，客户端的程序是建立在Windows NT 系统上以Microsoft Visual C++为开发软件的应用程序，服务器端采用Linux 为操作系统的工作站，是采用Oracle 8的为开发软件的数据库服务程序。
1.3 定义： [专门术语]： [缩写词]： 1.4 参考资料： 《软件工程导论》，张海藩，清华大学出版社。
《实用软件工程》，郑人杰等，清华大学出版社。
2.可行性研究的前提 2.1要求 主要功能： 性能要求： 对服务器上的数据必须进行及时正确的刷新。
输出要求：数据完整，详实。
输出要求：简捷，快速，实时。
安全与保密要求：权限不同 完成期限：预计六个月，即截止2007年12月8日。
2.2目标： 系统实现后，大大提高旅游局的机票预定服务效率超市的管理水平。
降低误差，减少开销 2.3条件，假定和限制 建议软件寿命：5年。
经费来源：。
硬件条件：服务器sun工作站，终端为pc机。
运行环境：Linux 数据库：Oracle8 投入运行最迟时间：2000/04/04 2.4可行性研究方法 2.5决定可行性的主要因素 1 经济可行性 成本/效益分析结果，短期-长期利益分析。
技术可行，现有技术可完全承担开发任务。
操作可行，软件能被原有工作人员快速接受。
3.技术可行性分析 3.1系统简要描述 3.2处理流程和数据流程 3.3环境可行性 3.4 人员可行性：操作宜学 3.5 效益分析 投资回收周期 2.3年 4.5敏感性分析 设计系统周期为五年， 估计最长可达10年 处理速度：一般查询速度关键数据查询速度： 5。
法律因素 6。
其他可供选择的方案 7.结论意见 由于投资效益比远大于100%， 技术、经济、操作都有可行性，可以进行开发. 以上为包含步骤，供你参考！！
软件系统中用户需求与系统功能推理过程怎么写
财务管理的各项记录 4.数据文件名：技术数据 简述.1.数据流名：反馈信息 来源， 处理信息 加工逻辑，读取修改 输出数据流，读取/修改的变量名称 流通量：公司内部账目及收支情况详表 技术管理数据库：公司所需各技术档案的详细记录（包括文档） 3；读取/修改->提高效率：利用软件进行管理. 数据概述数据流程图如下： 3：读取/修改标识；存储工作 输入数据流：输入修改信息 输出数据流：反馈信息 加工逻辑：系统判断部分 组成：系统各数据库的标识信息 流通量；加工逻辑词条描述： 1.加工名：检验 简要描述：****公司1：销售统计 简要描述：对销售数据库进行相应要求的操作，并与判断部分交互 输入数据流：处理信息， 处理信息 加工逻辑.2：判断用户要读取/：人事档案管理 简要描述：对人事数据库进行相应要求的操作，并与判断部分交互 输入数据流：处理信息，读取修改 输出数据流：系统判断部分 去向：各数据库处理部分 组成：人事数据 简述：存储人员信息 数据文件组成.加工名；反馈用户所需信息 4：判断用户的许可性 输入数据流：读取/修改标识，读取/修改内容 流通量： 用户每次输入流通一次<，避免人工管理的失误以及 延迟性：技术管理 简要描述：对技术统计数据库进行相应要求的操作，并与判断部分交互信息 输入数据流：处理信息.数据流名：读取修改 来源：判断用户要读取/.1项目委托单位：登录结果 来源：系统 去向： 1：判断用户的操作并进行相应的读取/.4 数据字典：源点及汇点词条描述： 名称. 任务概述2.1 目标.加工名，系统时间3，从而实现高效率的管理.2.2 运行环境.加工名.数据文件名： 1，各数据库所在位置，系统分析原始数据3.2 动态数据：包括各数据库内各项显示数据，用户登录信息；反馈用户所需信息人事功能： （1）能对公司内部的所有人员有关档案详细资料记录并保存。
（2）能对数据库内人事档案的数据进行查阅和修改。
（3）能按部门或姓名检索人员。
（4）当某员工的雇用期限达到整年时，按时提醒。
销售统计功能 （1）按日对公司的销售情况进行统计，包括销售额\销售数量\各地区销售比例\不同销售方式的销售量比例以及销售毛利润情况 （2）制定销售情况的月报表\季报表以及年报表对销售情况进行分析，对不同销售人员的业绩进行评定财务管理功能 （1）协助财务人员进行计算机管理，对库存情况\进货情况\销货进行登录和输出 （2） 根据预设的库存情况提醒进货 （3） 对收款情况进行统计，在应收帐款达到预设值时进行提示技术管理功能 （1）对技术资料进行登录 （2）对维修记录进行登录和统计，按不同型号的机器进行故障整体分析，并作出分析报告 （3）对维修配件的需求进行管理并及时提示备货5. 性能需求5.1 数据精确度：因为此数据为公司内部数据，所以要求不能有误差5.2 时间特性：当日销售统计要求有即时性，马上能反应出存货的问题；同时财务管理数据计算当前存货情况，并对进货情况进行估算5.3 适应性：此软件只在公司内部管理人员的机器上使用，因此不考虑适应性6. 运行需求6.1 用户界面： 屏幕格式： （1）要求有菜单及工具栏以方便操作 （2）各数据库信息可在屏幕上直接修改 （3）各数据统计结果可在屏幕上显示 （4）进行系统分析后的结果在另一窗口中显示 报表格式： （1）人事管理报表只要求有个人的普通数据 （2）销售统计报表要求可分别打印当日统计或之前的统计 （3）财务统计报表要求打印出存货及公司帐务详表 （4）技术管理报表要求可以分别打印技术档案总表和任一技术档案文档内容菜单格式：要求菜单项大致与WIN95标准相同，另外附加的功能做到新的单项中输入输出时间：年份以4位数字表示6.2 硬件接口：需要标准打印机接口进行报表打印6.3 软件接口：Windows标准接口7. 其他需求 可使用性：要求容易使用，界面友好 安全保密性：因本数据属于公司内部管理用关键数据，因此除公司管理人员外，其...
