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>财务管理功能 (1)协助财务人员进行计算机管理,对库存情况\进。
2. 项目需求分析怎么写
项目需求分析的概念 需求分析是指理解用户需求,就软件功能与客户达成一致,估计软件风险和评估项目代价,最终形成开发计划的一个复杂过程。
(这个和我在微软体验到的又不太一样,微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度,这一点也可以理解,因为公司的性质有根本差别)在这个过程中,用户的确是处在主导地位,需求分析工程师和项目经理要负责整理用户需求,为之后的软件设计打下基础。需求分析阶段结束后,要求得到:1.SRS文档(System Requirement Specification); 2.DRM 文档;3.Acceptance Plan. 从广义上理解:需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上理解:需求分析指需求的分析、定义过程。 一、为什么要需求分析 需求分析就是分析软件用户的需求是什么.如果投入大量的人力,物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死. 需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型软件系统的开发中,他的作用要远远大于程序设计. 二、需求分析的任务 简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求.三、需求分析的过程 需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审. 问题识别 就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括:功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率),安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标. 分析与综合 逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型). 制订规格说明书 即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交. 评审 对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。
四、需求分析的方法 需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论. 原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能. 原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发. 原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。 在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统,针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。
追加策略:先构造一个功能简单而且质量要求不高的模型系统,作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求,发展成为最终系统。进化型属于这种策略.。
3. 需求分析具体要怎么写
方法 ⑴首先调查组织机构情况 包括了解该组织的部门组成情况,各部门的职能等,为分析信息流程作准备。
⑵然后调查各部门的业务活动情况 包括了解各个部门输入和使用什么数据,如何加工处理这些数据,输出什么信息,输出到什么部门,输出结果的格式是什么。 ⑶协助用户明确对新系统的各种要求 包括信息要求、处理要求、完全性与完整性要求。
⑷确定新系统的边界 确定哪些功能由计算机完成或将来准备让计算机完成,哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。
常用的调查方法有: ⑴跟班作业 通过亲身参加业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求,但比较耗费时间。
⑵开调查会 通过与用户座谈来了解业务活动情况及用户需求。座谈时,参加者之间可以相互启发。
⑶请专人介绍。 ⑷询问 对某些调查中的问题,可以找专人询问。
⑸设计调查表请用户填写 如果调查表设计得合理,这种方法是很有效,也很易于为用户接受的。 ⑹查阅记录 即查阅与原系统有关的数据记录,包括原始单据、账簿、报表等。
通过调查了解了用户需求后,还需要进一步分析和表达用户的需求。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。
4. 需求分析如何写啊
在软件工程中,需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新系统的目的、范围和定义时所要做的所有的工作。需求分析是软件工程中的一个关键过程。在这个过程中,系统分析员和软件工程师确定顾客的需要。只有在确定了这些需要后他们才能够分析和寻求新系统的解决方法。
在软件工程的历史中,很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤,但在过去十年中越来越多的人认识到它是整个过程中最关键的一个过程。假如在需求分析时分析者们未能正确地认识到顾客的需要的话,那么最后的软件实际上不可能达到顾客的需要,或者软件无法在规定的时间里完工。
5. 软件需求分析怎么写
首先你要清楚自己能够给客户提供哪些产品 选定项目时要进行(SWOT)分析 strengths(优势) weaknesses(劣势) opportunities(机会) threats(威胁) 再针对目标客户运用整合营销组合(4C) 顾客需要什么customer needs and wants 顾客愿意花费的价格costs to customer 多跟顾客沟通communication 多给顾客方便conveniet 祝你成功。
检举回答完毕,希望对你的提问有帮助,如果满意请采纳o(∩_∩)o。哈哈。
6. 如何做需求分析
随着技术的不断发展和用户对网站功能性的需求不断提高,如今网站项目的设计已经不能再仅仅简单地利用静态Html文件来实现,与前几年网站设计由一两名网页设计师自由的创作相比,网站项目的设计和开发越来越像一个软件工程,也越来越复杂,网站项目的设计和开发进入了需要强调流程和分工的时代,建立规范的、有效的、健壮的开发机制,才能适应用户不断变化的需要,达到预期的计划目标。
网站项目管理(WPM)的含义为Web-based Project Management,即以Web 应用程序为主要表现方式的架构来进行的项目设计及管理,这样的架构中包含了浏览器、网络和Web 服务器等关键主体,主要体现在网站设计、以浏览器为客户端的Web应用程序开发(例如信息类网站、网上商店、虚拟邮局、客户关系管理。)等项目管理中。
按照笔者的经验,网站项目管理可以分为以下l六个阶段进行控制: 1. 需求分析及变更管理 2. 项目模型及业务流程分析 3. 系统分析及软件建模 4. 界面设计、交互设计及程序开发 5. 系统测试和文档编写 6. 客户培训、技术支持和售后服务 需要说明的是,这些阶段虽然具有一定的延续性,但是并非完全隔断的,例如需求变更管理和测试工作、文档编写都是贯穿整个项目过程的,许多工作时交叉进行或同时进行的。 (一)如何做好需求分析及变更管理? 业务员与客户进行的沟通,撰写需求分析报告是项目展开的基础。
项目是以客户的需求为中心,而不是为技术而迁就需求。 一:让客户畅所欲言,罗列出所有的需求 让用户将所有的想法尽可能的阐述清楚,并把所有的要求罗列出来,不要遗漏。
这时候不应该害怕“勾引”起客户的潜在需求而增加设计开发的工作量,从而被今后客户无止境的变更拖入泥潭,直接明白地跟客户把问题和要求一条条地列出来,把条理、归纳、分析先都扔到一边去,将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作。 很明显,假如客户的需求做的都不完整,随时可能会产生意想之外的变更,甚至这个变更会破坏已经做的模型及结构,那么这个项目从开始就注定了会失败;比如站点所有的功能都实现了,本地测试起来也没有什么问题了,但是你却不知道客户的系统是要承受每天100万独立IP的访问,而你原来想当然的以为了不起就是1万独立IP访问的访问流量,稍微有经验的开发人员都会明白这样的设计是个灾难,无论是应用服务器、数据库还是程序全部要重新开发! 二:透过现象分析潜在的需求 很多情况下客户并非专业人士,在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关,这需要我们去为客户进行分析、归纳和整理,尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。
客户往往对需求的概念是非常模糊的,大多时候给出的需求都是笼统而且尺度难以控制的,这就要求业务人员在倾听了客户的详细说明以后,帮助客户进行整理和分析,同时预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。 比如在为客户设计办公自动化系统的时候,也许就要为客户预留将来与他们的业务单位进行交互的通道;在设计邮件系统的时候要考虑可能会需要广告管理服务器;设计网络电子商店时今后增加库存产品进销存统计分析等等;限于时间财力的考虑,客户通常能够接受分阶段实施的开发过程,在需求分析时,提早为客户设想到今后的需求变更除了使项目开发更加顺利以外,也为今后业务的进一步深入打下了更好的基础。
笔者曾负责一个大型新闻网站的设计,当客户拿着将近五十页厚的一本设计要求报告时,我发现有四十页的内容对程序开发来说都是重复的,而在其中一页的角落却画了个“搜索其他网站相关新闻”的按钮,并且没有做任何说明,仅仅这10个字所完成的工作量完全顶的上其他整整四十页重复赘述所做的工作,客户完全不知道这个要求引发的问题实际就是一个搜索引擎的开发,通过协商,客人同意了修改成站内搜索的引擎。 三:利用自然的语言描述项目模型 在业务员与客户进行沟通和调查时撰写的需求分析,尽可能用自然的语言进行描述,虽然客户的水平和资历有所不同,但是最自然的描述能够使项目开发的各个成员都能清楚地理解需求含义,不至于在理解上产生偏差。
对客户而言,这样的模型描述最接近真实,容易参与修订,并能以此为测试和验收的依据。 请比较以下两份关于需求的描述, “用户在访问首页的时候可以在点击‘客户通道’按钮,弹出填写‘用户名’和‘密码’的窗口,输入正确后在新窗口打开客户通道的首页,在该页显示所有可操作的功能的导航条和最新的导读新闻链接列表 。”
“站点分为公开和加密两种状态,通过身份验证机制使特有的用户可以访问到加密信息,并提供不同于普通用户的功能。” 前段描述我们就很容易想象的出来设计完成的网站是什么样子,而后一段的描述可能会做出无数不同的版本,造成对需求理解的歧意。
四:利用示意图和图表将用户的需求表现出来 需求分析无论文字上怎么样表述都还是抽象的,对客户而言理解毕竟是困难的,将基本确定的需求制作出示意图是最直观有。
7. 网页需求分析怎么写
1)绘制关联图:绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。
2)创建开发原型:创建用户接口原型当开发人员或用户不能确定需求时,开发一个用户接口原型,这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。
3)分析可行性:分析需求可行性在允许的成本、性能要求下,分析每项需求实施的可行性,明确与每项需求实现相联系的风险,包括与其它需求的冲突,对外界因素的依赖和技术障碍。
4)确定需求优先级:确定软件工程需求的优先级别应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时,在特定的版本中加入每一项变更,并在那个版本计划中作出需要的变更。
5)为需求建立模型:为需求建立模型需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
6)编写数据字典:创建数据字典数据字典是对系统用到的所有数据项和结构的定义,以确保开发人员使用统一的数据定义。在需求阶段,数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。
7)应用质量功能调配:使用质量功能调配质量功能调配是一种高级系统技术,它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。它将需求分为三类:期望需求,即客户或许并未提及,但如若缺少会让他们感到不满意;普通需求;兴奋需求,即实现了会给客户带去惊喜,但若未实现也不会受到责备。