育才学习网1.软件的需求分析怎么写啊
1. 引言1.1 编写目的：编写此文档的目的是进一步定制软件开发的细节问题，便于用户与开发商协调工作.本文档面向的读者主要是项目委托单位的管理人员.希望能使本软件开发工作更具体.1.2 项目背景1.2.1项目委托单位：****公司1.2.2开发单位：***公司1.3 定义1.4 参考资料2. 任务概述2.1 目标：<1> 决策支持：根据公司的要求及时提供所需报表及文件，并在适当时候对各部门领导给予销售及进货等方面的提示<2>提高效率：利用软件进行管理，避免人工管理的失误以及 延迟性，从而实现高效率的管理.2.2 运行环境：<1> 硬件方面：Pentium级处理芯片 1兆显存的兼容显卡 256色，800*600的兼容显示器 标准兼容打印机<2>软件方面： WIN95操作系统2.3 条件与限制： 编程用计算机一台 完成期限2000/7/1 无资金供给3. 数据概述 数据流程图如下： 3.1 静态数据：包括系统登录密码，各数据库所在位置，系统分析原始数据3.2 动态数据：包括各数据库内各项显示数据，用户登录信息，系统时间3.3 数据库描述： 人事管理数据库：公司内人员的个人详细信息，包括档案信息 销售管理数据库：当日销售记录及以前的销售统计，用于销售分析 财务管理数据库：公司内部账目及收支情况详表 技术管理数据库：公司所需各技术档案的详细记录（包括文档） 3.4 数据字典：<1>数据流词条描述： 1.数据流名：登录信息 来源：用户的输入 去向：系统内部检验部分 组成：用户名，密码 流通量：每次登录输入一次 2.数据流名：登录结果 来源：系统 去向：用户 组成：返回信息 流通量：每次登录返回一次 3.数据流名：输入修改信息 来源：用户 去向：系统判断部分 组成：根据各数据库内容而不同 流通量：依用户输入而定 4.数据流名：反馈信息 来源：系统判断部分 去向：用户 组成：系统经判断后发回的字符数据 流通量： 依系统当前信息而定 5.数据流名：识别信息 来源：系统内部检验部分 去向：系统判断部分 组成：系统各数据库的标识信息 流通量：用户每次输入流通一次 6.数据流名：处理信息 来源：系统判断部分 去向：各数据库处理部分 组成：读取/修改标识，读取/修改的变量名称 流通量：用户每次输入流通一次 7.数据流名：读取修改 来源：系统判断部分 去向：系统各数据库 组成：读取/修改标识，读取/修改内容 流通量： 用户每次输入流通一次<2>数据文件词条描述： 1.数据文件名：人事数据 简述：存储人员信息 数据文件组成：人员的各项信息（以CString类型为主） 2.数据文件名：销售数据 简述：存储当日及从前的销售记录 数据文件组成：销售的各项信息 3.数据文件名：财务数据 简述：存储财务管理信息 数据文件组成：财务管理的各项记录 4.数据文件名：技术数据 简述：存储公司内部使用的技术档案信息 数据文件组成：技术档案名称，内容<3>加工逻辑词条描述： 1.加工名：检验 简要描述：判断用户的许可性 输入数据流：登录信息 输出数据流：登录结果 加工逻辑：判断是否与系统内部用户信息相符合 2.加工名：判断 简要描述：判断用户的操作并进行相应的读取/存储工作 输入数据流：输入修改信息 输出数据流：反馈信息 加工逻辑：判断用户的操作->调用数据库->读取/修改->反馈 3.加工名：人事档案管理 简要描述：对人事数据库进行相应要求的操作，并与判断部分交互 输入数据流：处理信息，读取修改 输出数据流： 读取修改， 处理信息 加工逻辑：判断用户要读取/修改的内容->反馈用户所需信息 4.加工名：销售统计 简要描述：对销售数据库进行相应要求的操作，并与判断部分交互 输入数据流：处理信息，读取修改 输出数据流： 读取修改， 处理信息 加工逻辑：判断用户要读取/修改的内容->反馈用户所需信息 5.加工名：财务统计 简要描述：对财务数据库进行相应要求的操作，并与判断部分交互 输入数据流：处理信息，读取修改 输出数据流： 读取修改， 处理信息 加工逻辑：判断用户要读取/修改的内容->反馈用户所需信息 6.加工名：技术管理 简要描述：对技术统计数据库进行相应要求的操作，并与判断部分交互信息 输入数据流：处理信息，读取修改 输出数据流： 读取修改， 处理信息 加工逻辑：判断用户要读取/修改的内容->反馈用户所需信息<4>源点及汇点词条描述： 名称：用户 简要描述：既是源点又是汇点，发出动作信息给"检验"和"判断"加工，通过交互界面接受反馈信息有关数据流：登录结果，登录信息，输入修改信息，反馈信息 数目：一个4. 功能需求4.1 功能划分 可细分为四部分：人事管理，销售管理，财务管理，技术档案管理4.2 功能描述<1>人事功能： （1）能对公司内部的所有人员有关档案详细资料记录并保存。
（2）能对数据库内人事档案的数据进行查阅和修改。 （3）能按部门或姓名检索人员。
（4）当某员工的雇用期限达到整年时，按时提醒。<2>销售统计功能 （1）按日对公司的销售情况进行统计，包括销售额\销售数量\各地区销售比例\不同销售方式的销售量比例以及销售毛利润情况 （2）制定销售情况的月报表\季报表以及年报表对销售情况进行分析，对不同销售人员的业绩进行评定<3>财务管理。
2.软件可行性分析报告怎么写
我国的软件技术行业也在不断的发展和提升的，华经纵横咨询相关专家通过对几年来全国主要地市及重点经销企业软件价格实地调研，在对行业内重点企业调查结果和咨询相关专家的基础上，系统整理归纳出了软件产品的应用策略，包括软件新产品开发策略、优化组合策略、生命周期策略、市场推广策略、品牌策略等，对拟进入软件行业和已经入软件行业的企业具有非常重要的参考价值。以及软件销售专业人士，同时结合相关行业协会提供的二手权威资料以及工具分析模型，对软件价格走势及影响因素进行了深度研究并最终形成了本报告。
在软件国内外发展历程、当前产业政策、行业一般特征（如产业生命周期、市场竞争程度）方面，采用期刊杂志等二手权威资料，结合静态和动态研究方法；在软件产量统计、地域产出结构、企业市场集中度、产品生产成本及构成、软件项目投资建设情况方面，主要根据行业协会、公司数据库等一手数据资料，采用的定量和定性研究方法；
在软件消费量，价格走势下游消费群体构成及消费特点，消费的区域性，品牌满意度调研以及渠道调查方面，主要采用实地调研获取一手资料并通过模型工具得出结论；
在软件进口市场、出口市场及进出口政策方面，通过对海关二手权威资料的整理分析，得出软件进出口产品结构、地域格局及金额，采用的定量和定性研究方法；
在软件重点企业产品产销、发展规划、产品投放区域格局方面，主要采用实地调研获取一手资料方法；在北京、上海、深圳、西安四个重点区域城市的软件市场调查方面，根据公司历年监测资料对各城市的软件品牌结构、消费渠道、价格变化、产品满意度作了统计分析和比较分析；
在软件细分市场产品的应用特点、市场容量、消费模式、发展趋势方面，进行了实证分析和规范分析，主要采用期刊杂志、行业协会、网站等二手权威资料；产业链关联研究；方便客户重点把握，同时就软件的行业主要问题提出了华经独家策略建议。
3.软件可行性分析报告
原发布者：胡园软件可行性分析报告文档名称：理财系统可行性分析报告项目名称：理财系统软件标识：项目负责人：编写人：校 对：审 核：批 准：开发单位：BL开发小组理财系统可行性分析报告家庭理财系统常言道：你不理财，财不理你。
一年多以来，“理财”成为平民百姓常挂在嘴边的一个词。它时不时地出现在我们身边：报纸上升息、升值等消息直接影响到每个家庭的储蓄收益；电视中股评家每天推荐的股票里，没准就埋伏着可能让你快速盈利的黑马；银行殷勤地的发来手机短信，告诉你新推出的外汇理财产品收益丰厚；世界各个国家今天开个小峰会讨论下经济问题，明天又出台各种经济刺激计划……家庭理财系统，可以帮你更好的理财，从而使自己的收入更完美，支出更合理，回报更丰厚。
本项目系统主要用于家庭理财，分为家庭单个人的理财与家庭整体账务管理。性能方面，本系统允许的最大家庭成员账户数目理论上没有限制，但考虑到用户空间的限制故暂时定为15个。
当今时代是经济主宰一切的时代，对财务的管理尤为重要。并且个人理财助手或软件在计算机界目前接近于空白，没有什么知名的软件，所以进行该方面的投资具有一定的必要性，一方面推出自己的专利，一方面占领该领域市场。
·对设备的影响V=(300+2800*k%)*N。
4.急需一份软件的市场计划书
软件开发商业计划书 摘要 本文主要对软件开发项目计划书的格式及主要内容的编写要点进行说明，对一些内容进行了举例说明。
关键词 项目、计划书、格式、编写说明 正文 一、项目计划书格式 根据《GB8567-88计算机软件产品开发文件编制指南》中项目开发计划的要求，结合实际情况调整后的《项目计划书》内容索引如下 1 引言 1.1 编写目的 1.2 背景 1.3 定义 1.4 参考资料 1.5 标准、条约和约定 2 项目概述 2.1项目目标 2.2产品目标与范围 2.3假设与约束 2.4 项目工作范围 2.5 应交付成果 2.5.1 需完成的软件 2.5.2 需提交用户的文档 2.5.3 须提交内部的文档 2.5.4 应当提供的服务 2.6 项目开发环境 2.7 项目验收方式与依据 3 项目团队组织 3.1 组织结构 3.2 人员分工 3.3 协作与沟通 3.3.1 内部协作 3.3.2 外部沟通 4 实施计划 4.1 风险评估及对策 4.2 工作流程 4.3 总体进度计划 4.4 项目监控 4.4.1 质量控制计划 4.4.2 进度监控计划 4.4.3 预算监控计划 4.4.4 配置管理计划 5 支持条件 5.1 内部支持（可选） 5.2 客户支持（对项目而言） 5.3 外包（可选） 6 预算（可选） 6.1 人员成本 6.2 设备成本 6.3 其它经费预算 6.4 项目合计经费预算 7 关键问题 8专题计划要点 二、项目计划书的编写说明 1 引言 1.1 编写目的 说明编写这份项目计划的目的，并指出预期的读者。 作用本节是为了说明编制“项目计划书”亦即本文档的意图和希望达到的效果。
注意这里的“目的”不是“项目目标”，而是为了说明本文档的目的与作用。“项目目标”在2.1中说明。
意义使项目成员和项目干系人了解项目开发计划书的作用、希望达到的效果。开发计划书的作用一般都是“项目成员以及项目干系人之间的共识与约定，项目生命周期所有活动的行动基础，以便项目团队根据本计划书开展和检查项目工作。”
例如可以这么写为了保证项目团队按时保质地完成项目目标，便于项目团队成员更好地了解项目情况，使项目工作开展的各个过程合理有序，因此以文件化的形式，把对于在项目生命周期内的工作任务范围、各项工作的任务分解、项目团队组织结构、各团队成员的工作责任、团队内外沟通协作方式、开发进度、经费预算、项目内外环境条件、风险对策等内容做出的安排以书面的方式，作为项目团队成员以及项目干系人之间的共识与约定，项目生命周期内的所有项目活动的行动基础，项目团队开展和检查项目工作的依据。 常见的问题把项目本身的“项目目标”误作编制项目开发计划的目的。
1.2 背景 主要说明项目的来历，一些需要项目团队成员知道的相关情况。主要有以下内容 项目的名称经过与客户商定或经过立项手续统一确定的项目名称，一般与所待开发的软件系统名称有较大的关系，如针对“XX系统”开发的项目名称是“XX系统开发”。
项目的委托单位如果是根据合同进行的软件开发项目，项目的委托单位就是合同中的甲方；如果是自行研发的软件产品，项目的委托单位就是本企业。 项目的用户（单位）软件或网络的使用单位，可以泛指某个用户群。
注意项目的用户或单位有时与项目的委托单位是同一个，有时是不一样的。如海关的报关软件、税务的报税软件，委托单位是海关或税务机关，但使用的用户或单位不仅有海关或税务机关，还包括需要报关、报税的企业单位。
项目的任务提出者本企业内部提出需要完成此项目的人员，一般是领导或商务人员；注意项目的任务提出者一般不同于项目的委托单位，前者一般是企业内部的人员。如果是内部开发项目，则两者的区别在于前者指人，后者指单位。
项目的主要承担部门有些企业根据行业方向或工作性质的不同把软件开发分成不同的部门（也有的分为不同事业部）。项目的特点就是其矩阵式组织，一般一个项目的项目成员可能由不同的部门组成，甚至可能由研发部门、开发部门、测试部门、集成部门、服务部门等等其中几个组成。
需要根据项目所涉及的范围确定本项目的主要承担部门。 项目建设背景从政治环境上、业务环境上说明项目建设背景，说明项目的大环境、来龙去脉。
这有利于项目成员更好地理解项目目标和各项任务。 例句根据《某部关于某建设工作的实施意见》精神，为了保障某建设工作的正常实施，必须加强监督考核，建立督查通报制度，某市某建设工作小组办公室把此项建设工作实施列入督查的重要内容，及时掌握进度，相关部门建立市某建设工作简报制度，及时反映全市某建设工作动态。
目前对于某建设工作的工作主要采用计划部门手工编制年度计划、建设工作主管部门和建设工作实施单位联合手动编制进度计划，某建设工作单位手工上报建设工作进度情况的方式，而全市的建设工作有数百个，加上前期建设工作的数量和今后某市建设发展的趋势，建设工作的数量将越来越多，原来的工作模式已经越来越无法适应市委市政府的要求。因此，充分利用现代信息化、因特网的优势，建立“某市某建设工作信息报送反馈系统”，提高某建设工作信息报送反馈工作效率，提高信息的及时性、减轻各级相关工作人员的劳动强度是非常有必要和紧迫的任务。
软件系统与其他系统的关系说明与本系统有关的其他系统，说明它们之间的相。
5.软件工程的需求分析该怎么写
首先你要找那些让你提交这些报告的人，问明白他们说的这些报告究竟需要涉及什么内容，给什么人看，格式和文档的风格要求是什么。如果他们不能告诉你一个满意的答案，就没有必要给他们一个他们自己都不知道想不想要的东西。
而实际上需求分析报告可以说是文档体系中最没有必要存在的。当然我不是说需求分析不重要，而是说需求分析太重要，是一个报告所不能容纳的，而是要有一个包括数个不同内容体系的文档系统。而如果你的项目根本就没有那么多的资金和资源，你一般就不要动用这样一个庞大的系统。你在这个时候只需要随时记录你的想法，列出你的关注点和解决的想法。而当然这个系统虽然庞大，但是还有很多线索要你去掌握它们的建造。首先这个系统需要有一个业务目标分析，也就你的这个系统要达到的业务目标，要结合具体的企业环境进行系统分析和论证，这个文档的阅读者基本上属于最高级次的决策者。还要有一个技术目标分析，也就是你的这个项目将解决什么具体的技术问题，这个部分也十分的复杂，基本上需要行业专家认真地分析，这个文档的阅读者属于管理者。还要有一个技术实现的报告，也就是你需要为完成这个项目动用什么技术，主要是你必须说出在这个项目的几种可使用技术方案中你为什么要选择你目前的这种，这个文档的阅读者基本上就是相关的技术人员。而同时你还需要一个风险分析的报告，把这个文档要针对业务/技术/实现这三个层次的问题中要遇到的各种风险进行分析。这属于基本的需求分析的基础文档系统。
然后你还需要面对你的具体的情况进行具体的项目的规划分析。首先如果你的项目是一个开发型的项目，你就有必要对你的业务目标和技术目标的实现进行一种设计。这个工作需要大量的市场和人类学知识。其次你还需要对你上面这个需求的设计进行分析，以把其转化为开发者可以接受的文档格式。然后你还需要对这些需求进行具体的粒度化的划分，将其细化为一些原子态的互相联系的部分。在此基础上你还需要对这些具体的技术实现进行规划，找出最重要的和最有难度的部分。同时这个层次的风险分析也需要有一个单独的文档说明。
最后你还需要对实现中具体的细节问题组织你的需求分析文档。这些问题包括，你使用的具体技术需要什么要求的人员和设备等等资源。你的需求需要如果进行测试，以保证你的这些需求能够被真正的贯彻。你的系统需要如何部署在你的业务环节中。你的人员培训需要采用什么措施。这些问题都需要有专门的文档，而且也都是需求分析方面的。
基本上这样一个系统要有10份以上的文档，而关键在于不同的问题应该在不同的文档中说明，同时你还必要在这些文档的相互关系中做出一种标注。这样一个工程，基本上需要一个团队来专门的进行协调和维护。至于书写则是一个文档就要一个小组，同时还必须有一个系统的管理小组。在这样一个文档系统中，基本上可以保证你所有的关注都在你的文档中体现了。
当然这样的文档系统我估计你在国内根本就看不到，国外也难找。而国内常见的情况是，这些文档和垃圾的地位一样，基本上都是人为的制造的无用的浪费时间的和精力的废纸。
还是回到最初的问题，你最好还是先去问问需要这些文档的人，他们究竟是要什么，有什么具体的要求，肯为这些文档出什么价钱。如果他们不能告诉你，你就只需要为自己建立一个文档，当然有的时候你会觉得自己不需要任何文档，那么你不需要好了。没有任何文档也不说明什么，到处都是文档倒是肯定的说明这个组织水准和开发能力十分的低劣
6.如何写市场分析报告 详细
既然要分析一项事情，就存在三个要素，一是目标，也可以讲标准或要达到的目标，二是现状，即目前的情况如何，要找出离目标的差距，三是原因，既然现状和目标有差距，就肯定有其原因。
有了以上三要素，再加上为达到目标所需的对策，一份不错的分析报告就这样出炉了。 明确目标：如经营分析，年初应制定过年度预算，其中包含营业额、利润等各种指标，这就是目标。
再比如，设备故障分析，设备的设计性能、运转率就是目标。这们所有的工作，都是为了达到目标而进行的。
现状：对现状要进行把握，要准确，比如说目前的营业额达到了多少，利润是多少，设备故障次数是多少，都是什么类型的故障，只有对现状把握准确了，才能进行有效的分析。 原因：找出了差距，寻找原因是最为关键的，也是最困难的。
分析者的水平差异也就是在这里体现了出来。分析问题要全面，要从人、财、物、设备、时间、方法、地理位置、环境等全方位的进行分析，在国际上也流行“4M1E”,4M:man-人，machine-机器，material-材料，method-方法，1E:Environment)。
7.如何进行软件需求分析
1.概念 需求的定义包括从用户角度（系统的外部行为），以及从开发者角度（一些内部特性）来阐述需求. 关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者，客户被迫与新的需求分析者坐到一起.系统的分析人员说："我们想与你谈谈你的需求."客户的第一反应便是："我已经将我的要求都告诉你们前任了，现在我要的就是给我编一个系统". 百事通 而实际上，UGGs，需求并未编写成文档，因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话，你就确信你已明白用户的需求，那完全是自欺欺人. 需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明".有些需求分析专家拓展了这个概念："从系统外部能发现系统所具有的满足于用户的特点、功能及属性等".这些定义强调的是产品是什么样的，而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性： 需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性，是在开发过程中对系统的约束. 从上面这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的"需求"术语存在，真正的"需求"实际上在人们的脑海中，这个人们主要是指客户，但一般情况下，用户并不能描述自己的需要，只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识. 任何文档形式的需求（例如如下将要描述的需求规格说明书）仅是一个模型，一种描述. 2.需求分析的任务 开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难. 目前，国内产品的庞杂，一家企业可能有几个系统并立运行，它们之间接口是系统开发人员最头痛的问题. 对于商业最终用户应用程序，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道项目于何时结束？而如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？ 然而，即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价，这些血的教训正在国内的软件开发者身上发生. 近来，我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是，当他们开发完这个工具后，发现这个工具不能打印出源代码文件，使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确，如果我们没有编写文档，软件达不到期望目标也只能是咎由自取了. 相反的情况，我曾见一个要集成到"错误跟踪系统"中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误. 事实上，需求文档在开发过程中一直起指导作用. 3.需求分析过程 可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适，如图4-1所示： 图4-1 需求工程域的层次分解示意图 需求开发可进一步分为：问题获取、分析、编写规格说明和验证四个阶段.这些子项包括软件类产品中需求收集、评价、编写文档等所有活动.需求开发活动包括以下几个方面： 确定产品所期望的用户类别. 获取每个用户类的需求. 了解实际用户任务和目标以及这些任务所支持的业务需求. 分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息. 将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件. 了解相关质量属性的重要性. 商讨实施优先级的划分. 将所收集的用户需求编写成文档和模型. 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚. 需求管理需要"建立并维护在软件工程中同客户达成的合同" .这种合同都包含在编写的需求文档与模型中.客户的接受仅是需求成功的一半，开发人员也必须能够接受他们，并真正把需求应用到产品中.通常的需求管理活动包括： 定义需求基线（迅速制定需求文档的主体）. 评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它. 以一种可控制的方式将需求变更融入到项目中. 使当前的项目计划与需求一致. 估计变更需求所产生影响并在此基础上协商新的承诺，这种承诺具体体现在项目解决方案上. 让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪. 在整个项目过程中跟踪需求状态及其。