公司产品需求分析法

公司产品需求分析法
公司产品需求分析法

一、KANO模型

KANO模型分为:基本型需求、期望型需求、兴奋型需求。

1.基本型需求,这类需求是应该得到满足,有是应该的,没有是会引起用户不满;所以这类需求是比较重要也是需求挖掘和需求分析应当用心做好的,这是一个产品的基础。

举例说明,聊天表情,几乎任何具备聊天场景的IM,都有发送表情的功能,输入法也开发了自己的默认表情,如果你设计一款新的APP,缺少了表情,可能会让用户不满。

2.期望型需求,在做用户调研或则访谈的时候,用户反馈如果有某个功能,该多好,当你想深入了解的时候,用户或客户自己也说不明白为什么需要这个功能,就是觉得如果你有,就很好。

如果没有其实也影响不大;还有种可能,用户使用了竞品友商的产品,进行相互对比的时候,告诉你某某产品有这个功能,我觉得你们也应该有,这类需求属于期望型需求同时也属于基本型需求,所以这类需求不满足,会引起用户的不满,得到满足,会给产品加分但是不会太多。

对于期望型需求,我曾经也纠结过苦恼过,也设计过原型,一直迟迟没有提交开发,这类需求收集到了可以提前准备,等时机成熟(有很多用户或则客户都提到这个需求)或则有开发资源的时候,再做。

举个例子,我现在在做的是ToB的产品,是专业的销售人员、外勤人员的行为管理软件,提需求的大部分是后勤人员,他们的工作就是使用后台进行监督、管理、汇总等,尤其是刚刚使用我们产品,对考勤管理特别用心,每天都会盯着考勤查看谁请假、出差、迟到早退、各种异常,然后每月工资也会按照考勤来制定。

问题来了,用户提到如果考勤能这样排版、这样汇总、如果能够在一个页面看到所有信息等等。

其实这些需求都是某些用户频繁使用产品,遇到的麻烦和想偷懒所提出的,他们期望软件帮他们完成所有的工作,然后自己每天就是坐在电脑前静静的等待结果。

这类需求,需要慎重容易导致产品变得越来越臃肿,为了满足了任何人的需求,反而满足不了任何人的需求。所以很多文章都提到,产品经理面对需求,需要做减法。期望型需求,就是考验产品经理做加法还是做减法的判断力。

3.兴奋型需求,让人出乎意料的产品属性,这类需求满足了会给产品增加不少魅力和好评。

举个例子,我在使用番茄,遇到一个问题,我每天需要固定一个时间看书,去完成这个番茄计划,但是每天去设置是很麻烦的事情,我当时就想有没有一个循环设置的方式,只用设置一天的几点到几点我要完成某事,然后勾选重复每天,就可以以后不用在设置,每天按照计划完成就可以了。

我把设置页面每个按钮都点了一边,意外发现有这样的功能,我非常兴奋,早上上班还给我们老板演示了下这个功能,和我们外勤管理软件的巡店模式非常接近。

二、马斯洛需求层次

马斯洛需求包含5个层次,分别是:生理上的需要、安全上的需要、情感和归属的需要、尊重的需要、自我实现的需要。

1. 生理上的需要:食物/ 水/ 睡眠/ 生理平衡/ 分泌/ 性/ 呼吸;对应的移动互联网产品有美团外卖、陌陌等。

2.安全上的需要:人身安全/ 健康保障/ 资源所有/ 财产安全/ 道德保障/ 工作保障/ 家庭安全;对应的移动互联网产品有支付宝、咕咚、乐运动、超级减肥王、动动记步、KEEP等。

3. 情感和归属的需要:爱情/ 友情/ 性亲密;对应的移动互联网产品有珍爱网、世纪佳缘、生日管家、她趣等等。

4. 尊重的需要:自我尊重/ 信心/ 成就/ 对他人尊重/ 被他人尊重;对应的移动互联网产品有新浪微博等。

5. 自我实现的需要:道德/ 创造力/ 自觉性/ 问题解决能力/ 公正度/ 接受现实能力;对应的移动互联网产品有在行。

三、5W2H法

1. WHAT——用户目标是什么?产品目标是什么?企业目标是什么?

2. WHO——谁是用户?谁是目标用户?他们有什么特征属性。

3. WHY——为什么?为什么要这么做?理由何在?原因是什么?

4. WHEN——用户在什么时候会用?使用的场景处于什么时间段。

5. WHERE——用户在哪里使用?使用的场景所处的位置,如公交地铁、办公室、户外等。

6. HOW——怎么做?如何提高效率?如何实施?方法怎样?用户会怎样使用?

7. HOW MUCH——做到什么程度?当成核心功能做深做透还是只是浅浅的做。

四、SWOT分析模型

SWOT分别代表:

S:strength(优势);内部因素,例如充足的资金、有影响力的品牌或公司形象、市场份额、牛x的技术力量等等。。

W:weakness(劣势);内部因素,例如缺失人才、时间紧迫、资金缺口大等等。

O:opportunity(机会);外部因素,例如发现市场空白点、竞争对手失误、等等。

T:threat(威胁)。外部因素,例如出现新的竞争对手活着替代产品、目标用户流失、政策风险等等。

根据以上四点,按照优先级或紧迫度分别列出符合的条件的事实,便可以构建出一个通用的SWOT矩阵或者模型。

1、SO(优势-机会:增长性战略)

这是一种理想的战略组合,充分利用内部优势和外部机会进行企业发展的战略。比如公司内部在某一领域具有绝对优势,且这一需求已然成为用户痛点,或非常受资本市场的青睐,那么就可以采取这一策略。

2、WO(弱点-机会:扭转型战略)

即利用外部机会来弥补内部弱点。例如目前很多有实力的大型互联网公司都推出了开放平台产品,利用自身的流量优势和影响力,吸引开发者,达到合作共赢的目的。对于开发者来说,推广与渠道可能恰恰是其弱点,如果充分利用大公司开放平台的机会,就很可能会使自己找到一条光明大道。

3、ST(优势-威胁:多种经营战略)

利用自身优势,尽量规避外部威胁。比如一些公司被同行业或竞争对手收购、合并或者合作就是采取这一策略。

4、WT(弱点-威胁:防御型战略)

公司在某一领域或项目产品中不存在任何优势、机会不大,甚至存在一些劣势和威胁的时候,通常会采取这种防御战略。比如某公司出了一款产品在市场中大行其道,那么为了自己不被彻底击败或者有效的阻击对手,那么他可能会做一款同样的产品,但又不会在这款产品投入太多资源,其实目的仅仅是为了能够起到一定的阻击对手的效果。

SWOT分析法不需要考虑的过于复杂但需要全面,同事需要对自身和外部环境有一个比较客观的认识。通过这一方法,基本可以找到一款产品领域中自身所处的位置和采取怎样的竞争策略。

五、波士顿矩阵

1. 销售增长率和市场占有率“双高”的产品群(明星类产品);

2. 销售增长率和市场占有率“双低”的产品群(瘦狗类产品);

3. 销售增长率高、市场占有率低的产品群(问题类产品);

4. 销售增长率低、市场占有率高的产品群(现金牛类产品)。

六、PEST分析法

PEST分析是指宏观环境的分析,P是政治环境(politics),E是经济环境(economy),S是社会环境(society),T是技术环境(technology)。

PEST分析法可能不会经常用到,但是这是一个潜在我们不容忽视的思维,比如我们在分析竞品的时候我们知道我们有哪些技术优势,我们能够在什么地方可以领先别人;再比如我们现在正在做的项目,符合两会的主张,借着政策的利好,迎合政府的口号,去设计开发产品;并且获得了一笔小小的投资,也有了经济基础,目前正打算收购一家硬件厂商。

有了政策、技术、经济环境,我们可以实现很多以前我们没有想过或则不敢做的需求。所以PEST分析法,我们可以无视它,但是不能否认它存在的意义。

-需求分析方法论

需求分析方法论 原则上,需求分析阶段IT中心应尊重需求方的项目管理和项目分析能力;在具体的任务开展上,以不干扰需求方的自主权为主,除非在项目过程中发现需求方的项目管理以及项目分析能力存在很大的差距和不足。 为了保证项目的成功,IT中心必须加强项目管理和项目分析工作,在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。 其中,需求分析是一个项目的开端,也是项目建设的基石。在以往的信息化建设失败的案例中,80%是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一,就是对需求分析的把握程度。而项目的整体风险往往表现在需求分析不明确、业务流程不合理,用户不习惯或不愿意去用应用管理软件。作为IT中心,必须提醒需求方重视需求分析的重要性,采用必要的手段和方法来进行需求调研,同时IT 中心也应深入具体的需求调研中去。只有这样才能切切实实地把握用户的需求和方向,才能在将来的功能界定、实施上有发言权。 一、如何进行需求分析 需求分析不象侦探推理那样需从蛛丝马迹着手,而是应该先了解宏观的问题,再了解细节的问题。 一个应用软件系统(记为S)的涉及面可能很广,可以按不同的问题域(记为D)分类,每个问题域对应于一个软件子系统。 S={D1,D2,D3,…Dn} 问题域Di由若干个问题(记为P)组成,每个问题对应于子系统中的一个软构件。 Di={P1,P2,P3,…Pm} 问题Pj有若干个行为(或功能,记为F),每个行为对应于软构件中的实现接口。 Pj={F1,F2,F3,…Fk} 需求说明书应该对于那些只想了解宏观需求的领导,和需要了解细节的技术人员都合适。在写需求说明书时应该注意两个问题: 1、最好为每个需求注释“为什么”,这样可让双方(IT中心、需求方)了解需求的本质,以便选用最合适的技术来实现此需求。 2、需求说明不可有二义性,更不能前后相矛盾。如果有二义性或前后相矛盾,则要重新分析此需求。 二、重点监控需求分析 由于项目的特殊性和行业覆盖的广阔性,以及需求分析的高风险性,软件需求分析的重要性是不言而喻的,同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。 1、用户说不清楚需求 有些用户对需求只有朦胧的感觉,当然说不清楚具体的需求。例如总部各部门及各地的很多店铺在进行应用系统以及网络建设时,需求方的办公人员大多缺乏IT系统建设方面的专家和知识。此时,用户就会要求IT中心系统分析人员替他们设想需求。项目的需求存在一定的主观性,为项目未来建设埋下了潜在的风险。 2、需求自身经常变动 根据以往的历史经验,随着用户对信息化建设的认识和自己业务水平的提高,他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。事实上,历史上没有一个软件的需求改动少于三次的!所以必须接受“需求会变动”这个事实,在进行需求分析时要懂得防患于未然,尽可能地分析清楚哪些是稳定的需求,哪些是易变的需求,以便在系统选型及实施时,将软件的核心建筑在稳定的需求上,同时留出变更空间。IT中心在需求分析的功能界定上担任一个中间、公平、公正的角色,所以也必须积极参与到需求分析的准备中来,以便协助需求方来界定“做什么”、“不做什么”的系统功能界限。 3、IT中心分析人员或用户理解有误 系统分析人员不可能都是全才,更不可能是行业方面的专家。用户表达的需求,不同的分析人员可能

软件需求分析(案例答案)

案例one:教学管理系统(用例驱动的交互式需求获取) 以一个教学管理系统JXGL的分析与设计作为示例,说明用例驱动技术在软件项目开发中的应用。 高等学校的教学管理内容十分丰富,工作繁多。作为一个示例,规定开发教学管理系统JxGL只处理每学期的课程选修注册和学生的成绩管理。教学管理系统JXGL的用户是学校的学生、教师和教学管理员。学生使用JXG系统查询新学期将开设的课程和授课教师的情况,选择自己要学习的课程,并进行登记注册。学生还可以使用JXGL系统查询自己的课程成绩。教师使用JXGL系统查询新学期将开设的课程、参加听课的学生情况,以及学生的考试成绩。教学管理员使用JXGL系统进行教学管理,包括新学期的课程选课注册管理和学生成绩管理。 1.需求描述: 对教学管理系统JXGL要求提供两个方面的服务: (1)选课管理,负责新学期的课程选课注册工作; (2)成绩管理,负责学生成绩管理。 在选课管理方面应填写的用户需求描述如下。 (1)录入与生成新学期课程表 教学管理员在新学期开始前录入新学期课程,打印将开设的课程目录表,供师生参 考选择。若某课程的实际选课学生少于10人,则停开该课程,把该课程从课程目 录表中删除;若某课程的选课学生多于30人,则停止选课。 (2)学生选课注册 新学期开始前一周为选课注册时间,在此期间学生可以选课注册,并且允许改变或 取消注册申请。 每个学生选课不超过4门课程。每门课程最多允许30名学生选课注册。 学生可以在图书馆、各系资料室、学生宿舍等处的计算机上联网进行选课注册。在 选课注册结束后,教学管理员打印学生选课注册名单和开课通知书,送交有关部门 和授课教师。 (3)查询 可以查询课程信息、学生选课信息和学生、教师信息。 学生、教师、教学管理员可以查询课程表,获得课程信息。查询的关键词以是:课 程名,授课教师名,学分。 教师、教学管理员可以查询学生选课情况。查询的关键词可以是:学生名、程名, 授课教师名,学分。学生只允许查询自己的选课信息,不允许查询别人选课信息。 学生、教师、教学管理员可以查询学生或教师的信息。查询的关键词可以是学生名、 教师名,性别、班级、职称。 (4)选课注册信息的统计与报表生成。 教学管理员对学生的选课注册信息进行统计(按课程,按学生,按班级),印汇总统 计报表。 在成绩管理方面应填写的用户需求描述如下: (1)成绩录入:

客户需求分析

客户需求分析 客户需求分析($APPEALS)概述 $APPEALS是一种了解客户需求的、确定产品市场定位的工具。一般是使用在市场规划和产品规划的细分市场中,因为可以从多个维度,不同的权重来分析需求,所有$APPEALS一定会联系到细分市场,联系到竞争对手,涉及到差异化分析和蓝海的价值创新(减少,增加,剔除,创新)。差异化可以说是理解市场和分析市场中的一个重要内容,只有清楚了差异化才能够树立自己产品的核心竞争力。客户需求分析 ($APPEALS)的内容: $APPEALS方法是IBM在IPD总结和分析出来的客户需求分析的一种方法。它从8个方面对产品进行客户需求定义和产品定位。具体如下:$-产品价格(Price);A-可获得性(Availability);P-包装(Packaging);P-性能(Performance);E-易用性(Easy to use);A-保证程度(Assurances);L-生命周期成本(Life cycle of cost);S-社会接受程度(Social acceptance)。客户需求分析($APPEALS)内容框架的目的 使用客户$APPEALS框架来确定客户的欲望与需要,建立针对每一个细分市场的产品包对应图。客户$APPEALS框架的目的主要包括以下方面的内容: 处理目标细分市场的全部客户欲望与需要建立客户驱动的需求集,作为投资的重点确定要想在所选细分市场获得成功必须达到的主要分界标准确定促使客户选择公司产品的主要差异 客户需求分析($APPEALS)的内容详解 $价格 这个要素反映了客户为一个满意的产品/交付希望支付的价格。用这个标准来要求供应商时,要从实际和感觉这两方面来考虑客户能接受的购买价格。将包括以下的数据评估:技术、低成本制造、物料、人力成本、制造费用、经验、自动化程度、简易性、可生产性等。 A保证

培训需求分析的方法和工具

培训需求分析的方法和工具 培训需求分析是企业培训的出发点,也是最重要的一步工作。如果需求分析不准确,就会让接下来的培训偏离轨道,做无用功,浪费企业的人力、物力和财力,却收不到应有的效果。企业要进行有效的需求分析,就必须采取合适方法和工具,本文全面介绍了通常情况下培训需求分析使用的方法以及对应的工具。 一、需求分析的方法和工具 1.1 调研问卷法 调研问卷法是最普遍也最有效的收集资料和数据的方法之一。一般由培训部门设计一系列培训需求相关问题,以书面问卷的形式发放给培训对象,待培训对象填写之后再收回进行分析,获取培训需求的信息和数据。 调研问卷法进行培训需求分析,可以遵循以下五个步骤,见表1: 在设计调研问卷的问题时,应该注意下几个问题: 1、问题尽量简短,并注意使用简单的、固定用法的术语,避免使用读者不了解或者容易引起歧义的名词; 2、一个问题只涉及一件事,避免“结构复杂”的问句; 3、题目设计要简单,不要使作答者作计算或逻辑推理; 4、避免出现诱导答案的问题,保证作答者完全陈述自己观点。

备注:填表时在对应的内容下面用“√”标明。 1.2 访谈法 访谈法也是数据收集的一种重要方法。它是指为了得到培训需求的数据和信息,与访谈对象进行面对面交流的活动过程。这个过程不只是收集硬性数据,比如事实、数据等,包括印象、观点、判断等信息。 访谈法可以遵循以下几个步骤进行,见表3:

1.3现场取样法 现场取样法一般较多使用于服务性行业的培训需求调查(如饭店、卖场等),是通过选取培训对象现场实际工作的部分片段进行分析,以确定培训需求的一种分析方法。现场取样法主要包括两种形式:拍摄和取样。 拍摄是指在培训对象的工作环境中安装监控录影机、摄像机等拍摄设备,对培训对象的现场工作过程进行实际拍摄,事后通过录影带进行观察分析,得出培训需求结论。表5为拍摄样板的示例。

什么是方案需求分析

什么是项目需求分析? 需求分析是指理解用户需求,就功能与客户达成一致,估计和评估项目代价,最终形成开发计划的一个复杂过程。(这个和我在微软体验到的又不太一样,微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度,这一点也可以理解,因为公司的性质有根本差别)在这个过程中,用户的确是处在主导地位,需求分析工程师和要负责整理用户需求,为之后的设计打下基础。需求分析阶段结束后,要求得到:1.SRS文档(System Requirement Specification); 2.DRM 文档;3.Acceptance Plan. 从广义上理解:需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。 狭义上理解:需求分析指需求的分析、定义过程。 一、为什么要需求分析 需求分析就是分析用户的需求是什么.如果投入大量的人力,物力,财力,时间,开发出的却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的,而你在开发前期

忽略了的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死. 需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型系统的开发中,他的作用要远远大于程序设计. 二、需求分析的任务 简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求. 三、需求分析的过程 需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审. 问题识别:就是从系统角度来理解,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括:功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率),安全保密需求,用户界面需求,资源使用需求(运行是所需的内存,CPU等),消耗与开发进度需求,预先估计以后系统可能达到的目标. 分析与综合:逐步细化所有的功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型).

软件需求分析重点-

软件需求分析重点 第1 章软件需求基础知识 返工的成本占了总开发成本的30%-50%,而对于返工的情况,70%-80%是国需求错误引起的。(11) 在对所有讨论问题有了更深入的了解之前不要急于回答。不能充分理解需求,就会作出过于乐观的估计,最终不可避免地陷入超支的泥潭。(13-14)造成软件成本估算失败的最主要原因包括频繁变更需求、遗漏需求、未与用户充分沟通、需求的说明不精确以及地需求的分析不透彻等。给出估算结果时,应该提供范围(最好的情况,最可能的情况和最糟的情况)或把握程度(“我有九成把握在三个月内完成”)。(14) 从产品的实际用户处收集需求这一过程是不可替代的。(18) 第2 章客户眼中的需求 某些需求问题源于混淆了不同层次的需求(业务需求、用户需求和功能需求)。(19) 要想开发出优秀的软件产品,必须以优质需求为基础精心制定计划。(20)不要指望项目涉众天生知道如何合作进行需求开发。必须花时间讨论如何最有效地进行协作。(22) 需求审阅是最有价值的保证软件质量的活动之一。(25) 需求批准过程的所有参与者都应该明白签字意味着什么,否则会出现很多问题。(25) 不可能在项目初期就能明确所有的需求,需求肯定要随时间的推移而发生变化。(26) 第3 章需求工程的推荐方法 熟练的需求分析员应具备以下特点:耐心,思维条理性强,有良好的交际和沟通能力,理解产品应用领域,并且掌握丰富的需求工作技术。(29)为每类用户选择代言人(31)

观察用户工作的过程(31) 跨项目重用需求(32) 过早地以尚不明确的需求为基础进行开销和进度评估是非常不可靠的。(37)38图表 不要期望可以线性地、顺序地完成获取、分析、编写规格说明和验证这些需求开发活动。(38) 第4 章需求分析员 相比缺乏经验的需求分析员,使用经验丰富的需求分析员能使项目所需求的工作量减少三分之一。(42) 优秀的需求分析员应同时具备出色的交流、引导和人际交待能力,具备技术和业务领域的丰富知识,以及适合这项工作的相应个性。耐心和真诚的合作愿望是关键的成功因素。(44) 需求分析员必须研究可能出错的情形。(44) 第5 章确定产品前景与项目范围 第6 章获取客户的需求 能否让开发人员更准确地了解用户需求,将决定软件需求工作能否取得成功,进而影响到软件开发的成功。(62) 项目伊始就应确定谁来担任问题的决策人。(72) 第7 章聆听客户的需求 需求开发工作的成果就是项目涉众之间就被处理的需求达成共识。(75) 需求获取的参与者在理解问题之前要抵制住诱惑,不要急于设计系统。 要强调用户任务,而不是用户界面,要强调根本需要,而不是用户表达出来的期望,这样有助于项目团队避免过早是制定设计的细节。 在软件开发中,需求获取也许是最困难、最关键、最容易出错和最需要沟通的一个环节。(76)

软件需求分析方法

需求分析方法 一需求分析概括 需求分析应该先了解宏观的问题,再了解细节的问题。 一个应用软件系统(记为S)的涉及面可能很广,可以按不同的问题域(记为D)分类,每个问题域对应于一个软件子系统。 S={D1,D2,D,…Dn} 问题域Di由若干问题(记为P)组成,每个问题对应于子系统中的一个软构件。 Di={P1,P2,P3,…Pn} 问题Pi有若干个行为(或功能,记为F),每个行为对应于软构件中的实现接口。 Pj={F1,F2,F3,…Fk} 需求说明书应该对于那些只想了解宏观需求的领导和需要了解细节的技术员都合适。在写需求说明书时,应该注意两个问题: 1.最好为每个需求注释“为什么”,这样可以让程序员了解需求的本质,以便选用最合适 的技术来实现此需求 2.需求说明不能有”二义性”,更不能前后矛盾。如果有二义性或前后矛盾,即要重新分 析此需求。 二需求分析方法论 第一阶段:“访谈式”

第一阶段是和具体用户方的领导层、业务层人员的访谈沟通,主要目的是从宏观上把握用户的具体需求方向和趋势,了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。 建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局,最好能指定本次项目的接口人。 实现手段:访谈、调查表格 输出成果:调查报告、业务流程报告 第二阶段:“诱导式” 结合第一阶段的基本信息,做出简单的用户流程页面,同时结合以往的项目经验对用户采用诱导式,启发式的调研方法和手段,和用户一起探讨业务流程设计的合理性、准确性、习惯性。用户可以操作简单演示的DEMO,感受整个业务流程的设计合理性、准确性等等问题,以及提出改进意见和方法。 实现手段:诱导(拜访)、原型演示 输出成果:调研分析报告、原型反馈报告、业务流程报告 第三阶段:“确认式” 此阶段在上述两个阶段成果的基础上,进行具体的流程细化、数据项的确认阶段。这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表,并能清晰地向用户描述系统的业务流设计目标。通过审查,提出反馈意见,并对已经可接受的报告、文档签字确认。 实现手段:拜访(回顾、确认),提交业务流程报告、数据项表;原型演示系统 输出成果:需求分析报告、数据项、业务流程报告、原型系统反馈意见(后三者可以统一归到需求分析报告中)

需求分析方法主要步骤

1.1主要步骤 遵循科学的需求分析步骤可以使需求分析工作更高效。需求分析的一般步骤如图2-3所示。 需求涉及的方面有很多。 在功能方面,需求包括系统要做什么,相对于原系统目标系统需要进行哪些修改,目标用户有哪些,以及不同用户需要通过系统完成何种操作等。 在性能方面,需求包括用户对于系统执行速度、响应时间、吞吐量和并发度等指标的要求。 在运行环境方面,需求包括目标系统对于网络设置、硬件设备、温度和湿度等周围环境的要求,以及对操作系统、数据库和浏览器等软件配置的要求。 在界面方面,需求涉及数据的输入/输出格式的限制及方式、数据的存储介质和显示器的分辨率要求等问题。 1.1.1获取需求,识别问题 开发人员从功能、性能、界面和运行环境等多个方面识别目标系统要解决哪些问题,要满足哪些限制条件,这个过程就是对需求的获取。开发人员通过调查研究,要理解当前系统的工作模型和用户对新系统的设想与要求。 此外,在需求的获取时,还要明确用户对系统的安全性、可移植性和容错能力等其他要求。比如,多长时间需要对系统做一次备份,系统对运行的操作系统平台有何要求,发生错误后重启系统允许的最长时间是多少等。

遗漏需求是最难修订的需求错误。 --RobertL.Glass 获取需求是需求分析的基础。为了能有效地获取需求,开发人员应该采取科学的需求获取方法。在实践中,获取需求的方法有很多种,比如,问卷调查、访谈、实地操作、建立原型和研究资料等。 问卷调查法是采用调查问卷的形式来进行需求分析的一种方法。通过对用户填写的调查问卷进行汇总、统计和分析,开发人员便可以得到一些有用的信息。采用这种方法时,调查问卷的设计很重要。一般在设计调查问卷时,要合理地控制开放式问题和封闭式问题的比例。 开放式问题的回答不受限制,自由灵活,能够激发用户的思维,使他们能尽可能地阐述自己的真实想法。但是,对开放式问题进行汇总和分析的工作会比较复杂。 封闭式问题的答案是预先设定的,用户从若干答案中进行选择。封闭式问题便于对问卷信息进行归纳与整理,但是会限制用户的思维。 访谈通过开发人员与特定的用户代表进行座谈,进而了解到用户的意见,是最直接的需求获取方法。为了使访谈有效,在进行访谈之前,开发人员要首先确定访谈的目的,进而准备一个问题列表,预先准备好希望通过访谈解决的问题。在访谈的过程中,开发人员要注意态度诚恳,并保持虚心求教的姿态,同时还要对重点问题进行深入的讨论。由于被访谈的用户身份可能多种多样,开发人员要根据用户的身份特点,进行提问,给予启发。当然,进行详细的记录也是访谈过程中必不可少的工作。访谈完成后,开发人员要对访谈的收获进行总结,澄清已解决的和有待进一步解决的问题。 关注用户的行为而不是他们的言语。

用户需求分析报告(范本)

用户需求分析报告(范本) 需求分析报告 引言 当决定要开发一个信息系统时,首先要对信息系统的需求进行分析,需求分析要做的工作是深入描述软件的功能和性能,确定软件设计的限制和软件同其他系统元素的接口细节,定义软件的其他有效性需求。 抽象出当前系统的逻辑模型。在理解当前系统“怎么做”的基础上,抽取其“做什么”的本质,从而从当前系统的物理模型抽象出当前系统的逻辑模型。在物理模型中有许多物理因素,随着分析工作的深入,有些非本质的物理因素就成为不必要的负担,因而需要对物理模型进行分析,区分出本质的物理因素就成为不必要的负担,因而需要对物理模型进行分析,区分出本质的和非本质的困素,去掉那些非本质的困素即可获得反映系统本质的逻辑模型。任务概述 随着信息时代的到来,图书的信息化管理使得问题得以解决,图书馆管理系统的出现就显得水到渠成了。 本系统主要上可以分为两大模块:图书馆管理员模块和读者登录模块,并在这两大模块下分成多个子模块。图书的使用对象是借阅者,例如学生,教师。 因此根据这些信息,本系统的主要功能就是:实现图书馆图书信息的管理和维护,图书浏览、查询等。 数据描述 系统功能结构 学生用户端:查询图书,学生用户可以进行简单的查询和高级查询,预约图书,当要借的的书不在馆时,可以提前预约。挂失图书,图书丢失要挂失,可以在学生用户端实现。 管理员端:学生用户管理,实现学生用户信息的修改,删减,添加,查询。图书管理,包括对图书的增加,删减,查询等。管理员管理:操作者包括超级管理员和普通管理员,超级管理员可以对普通管理员进行删减,查询等操作,而普通管理员只有修改自己密码的权限。借阅管理:主要是学生借阅管理,归还图书和缴纳罚款的管理。

需求分析与测试的重要性

需求分析与测试的重要性 读《软件工程案例教程》有感 对于学习软件工程这门课程,我认为有许多东西要学习。其实在我看来学习这门课程的精髓是学习一种方法。是一个如何去分析和处理问题的过程,应该说其范畴已经远远不止局限于该门课程,成为了一个综合的一个能够解决问题的思想集合。读完软件工程案例教程这本书,我觉得自己受益匪浅。 整本书的内容逻辑很清晰明了,由浅入深循序渐进,首先我就大概描述下我们所学的内容,第一章是从整体分析软件工程这门学科的发展和所处的社会环境,接着后面的几章深入分析了软件开放过程和模式、软件项目管理、计算机工程、需求分析、结构化分析建模以及基于UML面向对象分析建模和测试等。对于这本书我主要对需求分析和测试比较感兴趣,在这我要着重的谈一些自己的心得体会以及自己的看法。 一.需求分析 1.1需求分析的重要性 一款成功的软件是建立在成功的需求分析之上的,而高质量的需求来源于用户与开发人员之间有效的沟通与合作。当用户有一个问题可以用计算机系统来解决,而开发人员开始帮助用户解决这个问题,沟通就开始了。由此我们可以看出需求分析的重要性。 需求获取可能是最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往有错误的认识:用户知道需求是什么,我们所要做的就是和他们交谈从他们那里得到需求,只要问用户系统的目标特征,什么是要完成的,什么样的系统能适合商业需要就可以了,但是实际上需求获取并不是想象的这样简单,这条沟通之路布满了荆棘。首先需求获取要定义问题范围,系统的边界往往是很难明确的,用户不了解技术实现的细节,这样造成了系统目标的混淆。 其次是对问题的理解,用户对计算机系统的能力和限制缺乏了解,任何一个系统都会有很多的用户或者不同类型的用户,每个用户只知道自己需要的系统,而不知道系统的整体情况,他们不知道系统作为一个整体怎么样工作效率更好,也不太清楚那些工作可以交给软件完成,他们不清楚需求是什么,或者说如何以一种精确的方式来描述需求,他们需要开发人员的协助和指导,但是用户与开发人员之间的交流很容易出现障碍,忽略了那些被认为是"很明显"的信息。最后是需求的确认,因为需求的不稳定性往往随着时间的推移产生变动,使之难以确认。为了克服以上的问题,必须有组织的执行需求的获取活动。 1.2需求分析的原则 (1)需求分析必须能够表达和理解问题的数据域和功能域。数据域包括数据流、数据内容和数据结构,而功能域反映上述3方面的控制信息。 (2)需求分析要把一个复杂问题按功能进行分解并逐层细化。通常,软件系统要处理的问题如果太大、太复杂就很难理解,若划分成几部分,并确定各部分间的接口,就可完成整体的功能。在需求分析过程中,软件系统的用户需求中的数据、功能和行为都应细化。 (3)需求建模。模型可以帮助系统分析人员更好地理解软件系统的数据、功能和行为,这些模型是软件工程中下一阶段进行系统设计的基础。 1.3需求分析的注意事项

软件需求分析方法

欢迎阅读 软件需求分析(Software Reguirement Analysis)是研究用户需求得到的东西,完全理解用户对软件需求的完整功能,确认用户软件功能需求,建立可确认的、可验证的一个基本依据。 1)对实现软件的功能做全面的描述,帮助用户判断实现功能的正确性、一致性和完整?性,促 使用户在软件设计启动之前周密地、全面地思考软件需求; 2)了解和描述软件实现所需的全部信息,为软件设计、确认和验证提供一个基准;

3)为软件管理人员进行软件成本计价和编制软件开发计划书提供依据; 需求分析的具体内容可以归纳为六个方面:软件的功能需求,软件与硬件或其他外部系统接口,软件的非功能性需求,软件的反向需求,软件设计和实现上的限制,阅读支持信息。 软件需求分析应尽量提供软件实现功能需求的全部信息,使得软件设计人员和软件测试人员不再需要需求方的接触。这就要求软件需求分析内容应正确、完整、一致和可验证。此外,为保证软件设计质量,便于软件功能的休整和验证,软件需求表达无岔意性,具有可追踪性和可修改性。2.1、????? 软件功能需求 1 不 (5)??? 尽可能不使用“待定”这样的词。所有含有待定内容的需求都不是完整的文件,如果出现待定的部分,必须进行待定部分内容说明,落实负责人员、落实实施日期。 2)功能描述的无岔意性和可追踪性 需求功能描述的无岔意性、可追踪性和规范化: (1)??? 功能描述必须清晰地描述出怎样输入到怎样输出,并且输入、输出描述应对应有数据流描述、控制流描述图,这些描述必须与其它地方描述一致;

(2)??? 可以用语言、方程式、决策表、矩阵或图等对功能的描述。如果选用语言描述必须使用结构化的语言,描述前必须说明该步骤(或子功能)的执行是顺序,选择, 重复,还是并发,然后说明步骤逻辑。整个描述必须单入单出。 (3)??? 描述时,每一个功能名称和参照编号必须唯一,且不要将多个功能混在一起进行描述,这样便于功能的追踪和修改。 (4)??? 功能描述应注意需求说明和程序设计的区别。需求设计仅仅是软件的功能设计,它给出软件运行的的外部功能描述,以及为了实现这一外部功能必须做哪些事情(采 2.2、 2.3、 (2)??? 处理容限、精度、采样参数的分辨率,误差处理等; (3)??? 可靠性的MTBF要求,可维护性、安全性要求等。(对可能的不正常的输入给以正常响应是可靠性的重要内容,这属于功能性需求。) 2.4、????? 软件反向需求 软件的反向需求描述软件在那些情况下不能做什么。这一条是随软件实际要求而定。有两类情形需要采用反向需求的形式。第一种情况:某些用户需求适宜采用反向形式说明,如数据安全性要求属于这类形式。第二种情况:对一些可靠性和安全性要求较高的软件,有些必须描述软件不能做些什么。如控制点火时序,我们必须交代清楚在那些情况下不能点火,否则会造成故障。

如何进行软件需求分析

软件需求分析(Software Reguirement Analysis)是研究用户需求得到的东西,完全理解用户对软件需求的完整功能,确认用户软件功能需求,建立可确认的、可验证的一个基本依据。 软件需求分析是一个项目的开端,也是项目实施最重要的关键点。据有关的机构分析结果表明,我们设计的软件产品存在不完整性、不正确性等问题80%以上是需求分析错误所导致的,而且由于需求分析错误造成根本性的功能问题尤为突出。因此,一个项目的成功软件需求分析是关键的一步。 一、软件需求分析理论 如果我们用数学方法来描述软件需求分析,可以将一个应用软件定义为S,可能应用软件涉及功能性问题非常广,我们用抽象化理论分析,可以划分为各个功能域,可以用D1、D2、… Dn表示,那么,我们可以用一个表达式描述为S={D1,D2,D3,…Dn} 但是,功能域Di依然存在着有若干个问题P1、P2、P3、… Pm组成,并且每个功能对应于子系统中的一个软构件,我们可以表示为 Di={P1,P2,P3,…Pm} 同样,功能Pj有若干个行为F1、F2、F3、… Fk,每个行为对应于软构件中的实现方法 Pj={F1,F2,F3,…Fk} 一个软件包含了所有功能的集合,同时包含了实现所有功能的所有方法和算法描述。需求分析是依据于用户需求,经过需求问题识别,进行分析、消化与综合,制订规格说明,评审,分为四个阶段,形成用户需求与设计同步,设计满足用户需求目标。 需求分析方法始终贯穿着吸收、同化、贯彻方法和手段,用商业化行为解决需求与实现中存在的矛盾,解决用户需求与商业化产品融通,解决规范与个性化追求。 二、软件需求分析目标 软件需求分析的主要实现目标: 1)对实现软件的功能做全面的描述,帮助用户判断实现功能的正确性、一致性和完整性,促使用户在软件设计启动之前周密地、全面地思考软件需

用户需求分析的方法和启示

用户需求分析的方法和启示 来源:tomsinsight,专注于中国互联网的深度数据分析洞察 互联网的红利烧红了一个新的职业:产品经理。一夜间,人人都是产品经理。边装低姿态,变暗示自己产品领域倍专业,居功至伟。很多成名大佬喜欢说:“其实,我是一名产品经理”,不论之前是写博客的还是说相声的。名头可以随便起,但是作为一个产品经理的核心功力:用户需求分析,就没有那么容易忽悠了。 让我们从一个故事说起: 从前有一个国王,国王有个极其娇惯、任性、无比作的公主,这个国王又无比的宠爱这个公主:不管这个公主有什么愿望,国王一定满足。终于有一天,公主说:“父王,我要月亮!”,于是国王叫来一个臣仆,说把月亮给我女儿给摘来,不然我就杀了你,臣仆欲哭无泪,最终被国王杀害,接着叫来另一个臣仆,也无奈之愤愤而终。在公主的哭闹下,臣仆一个个死去,终于轮到了一个聪明的,他接到任务后,来到公主前谦卑的问:“亲爱的公主啊,请告诉愚昧的臣仆,月亮是什么啊?”公主不耐烦的说:“月亮是什么你都不知道!月亮就是用金子做的,如手指盖般大小,弯弯的,晚上就会挂在我窗前的树枝上啊,白天不知道被谁偷走了。”此臣仆暗喜,照此炮制,逃过一劫。 这个故事从我们TOMsInsight团队的老板口中听到,讲完此故事后,老板叹了口气,说:“需求啊,需求,也许上帝都不知道人类的需求是什么。”当然老板就是老板,多少都会有一些深沉(zhuang B)属性,但是此故事却让我们分析师团队很受启发。

互联网发展至今,当用户至上一次次的被提起;当以产品、用户为中心,打造极致成为口号;当大学落榜生都由于自己装过几百个app而就自以为是合格的产品经理;当大量互联网从业人员都由于自以为发现了用户需求上的空白几乎而觉得要不是自己有房贷那创业了肯定是一个互联网巨头;再加上不懂技术只能围绕产品概念说事的互联网科技媒体助拳,一时间好像只有产品经理在改变世界。 当这些浮躁的情绪在整个行业里绵延的时候,我们又能不能沉下心来,真正的去深入用户需求分析呢。今天TOMsInsight的主题是:那些用户需求分析背后隐藏的门槛。 用户需求分析技能门派之分 用户需求分析的方法技能大概可以分成两个门派,或者说两个不同的风格: 一种是注重意识形态分析,喜欢的是:用户心理、人性利用、用户体验、交互体验、群体效应、用户调研、深度用户理解、用户行为模拟、再加上一些炒作的概念、等等。出于后文描述方便,我们可以把这一类叫做:软派。 另一种是注重数据建模和分析,喜欢的是:数据、用数据说话、数据建模、结构化数据构建、用户数据细分、用数据profiling用户、大数据分析、数据模拟运营、小流量测试、等等。同样出于后文描述方便,我们可以把这一类叫做:硬派。 为什么用户需求分析会变成这两种门派呢:

软件需求分析习题大全

软件需求分析习题大全 Coca-cola standardization office【ZZ5AB-ZZSYT-ZZ2C-ZZ682T-ZZT18】

习题集 一、单项选择题 1、需求分析最终结果是产生()。 A.项目开发计划 B.可行性分析报告 C.需求规格说明书 D.设计说明书答案:C 2、需求分析中,开发人员要从用户那里解决的最重要的问题是()。 A.让软件做什么 B.要给软件提供哪些信息 C.要求软件工作效率怎样 D.让软件具有何种结构 答案:A 3、需求规格说明书的内容不应包括对()的描述。 A.主要功能 B.算法的详细过程 C.用户界面和运行环境 D.软件性能答案:B 4、需求规格说明书的作用不应包括()。 A.软件设计的依据 B.用户与开发人员对软件要做什么的共同理解 C.软件验收的依据 D.软件可行性研究的依据 答案:D 5、下面关于面向对象方法中消息的叙述,不正确的是()。 A.键盘、鼠标、通信端口、网络等设备一有变化,就会产生消息 B.操作系统不断向应用程序发送消息,但应用程序不能向操作系统发送消息 C. 应用程序之间可以相互发送消息 D.发送与接收消息的通信机制与传统的子程序调用机制不同 答案:B 6、面向对象技术中,对象是类的实例。对象有三种成份:()、属性和方法(或操作)。 A. 标识 B. 规则 C. 封装 D. 消息 答案:A 7、软件需求分析阶段的工作,可以分成以下四个方面:对问题的识别、分析与综合、 制定规格说明以及()。 A.总结 B.实践性报告 C.需求分析评审 D.以上答案都不正确 答案:C 8、软件需求规格说明书的内容不应包括对()的描述。 A.主要功能 B.算法的详细过程 C.用户界面及运行环境 D.软件的性能 答案:B 9、产品特性可以称为质量属性,在众多质量属性中,对于开发人员来说重要的属性有哪些(B ) A 有效性、效率、灵活性、互操作性 B 可维护性、可移植性、可重用性、可测试性 C 完整性、可靠性、健壮性、可用性 D 容错性、易用性、简洁性、正确性

客户需求分析

客户需求分析方法1 目录了解用于客户情景分析和语言表达需求的KJ分析方法的重要组成部分分组联系区别排序找出NUD客户需求指出KJ方法怎样用于开发客户需求指出怎样创立一项客户调查来检验和获得客户需求的排序数据找出和确认客户NUD需求Taguchi流失功能需求数据KJ方法适用于I-D-O-V的第一阶段产品商业化过程KJ方法的位置… KJ 方法是协助发现NUD需求的工具新: 一种新的需求,客户从来没有提出,独特: 一种已经被竞争对手或替代产品满足的产品或服务需求,但你公司还没有类似产品有一定难度: 一种很难去实现的要求如果不是NUD,怎么办那么这种需求就是“ECO”… 容易…对我们来说可以很容易地去实现普通…我们曾经满足过这种需求,它不是独特的有历史的…它不是新的需求,我们有丰富经验来满足这种需求回顾获得和处理客户需求的过程DFSS 工具: 情景KJ 分析DFSS 工具: 情景转化DFSS 工具: 需求KJ 分析DFSS 工具: 客户需求排序调查进行情景和需求KJ分析需要的信息… 客户采访中得到情景需求和客户语言表达的需求处理KJ情景数据需要的资金和资源概念设计的三个步骤哦,我获得了很好的数据…但我应该怎样处理数据来确认我创建的是正确的产品要求呢?KJ 方法Jiro Kawakita, 一位日本人文学家改造了这些方法,用于实施语言分析处理KJ方法有三个主要步骤: 1. 情景KJ分析 2. 将情景和语言表达数据转化为需求 3. 需求KJ 分析KJ 方法从原始的语言和文字说明开始把相似内容的数据分在同一组把分组数据用结构化的“提炼阶梯”处理,输入的数据形成一个说明的逻辑树内部数据结构按重要性进行排序,以满足研究的需要情景KJ: 建立客户工作环境的普通情景共有两类情景…. 采访过程中在采访者脑海里形成的一幅动态或静态画面采访者实际看到的有关工作环境的动态或静态画面. 这些情景被用生动的语言在易事贴上记录下来…这是你们团队所看到的记录. 情景KJ: 建立客户工作环境的普通情景这些情景往往是协助开发潜在需求的难得数据有些需求并没有被客户表达出来通过脑海中的情景,你发现的新的机会看到的而不是听到的机会建立情景KJ 图的步骤步骤1: 为VOC情景分析提供明确的主题步骤2: 在易事贴上阐明并记录情景(黑色情景) 步骤3: 合并重复的情景来减少情景数量步骤4: 把相似的情景分在一组(尽量每组3-4 幅情景图) 步骤5: 为每一组起一个名字(红色情景图表示精练阶梯中的更高一层) 步骤6: 为红色情景图进行再分组步骤7: 对每一组起一个名字(兰色情景图代表在精练阶梯中的更高一层) 步骤8: 在兰色情景图组之间用箭头表示它们之间的支持或矛盾关系情景 ERP客户需求分析20条法则 对商业用户来说,他们后面是成百上千个供应商,前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客,如何做好精细到一个小小调料包的进、销、调、存的商品流通工作,这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目,正是软件开发成功的关键所在。 对商业用户来说,他们后面是成百上千个供应商,前面是成千上万个消费顾客。怎样利 用软件管理错综复杂的供应商和消费顾客,如何做好精细到一个小小调料包的进、销、调、存的商品流通工作,这些都是商业企业需要信息管理系统的理由。软件开发的意义 也就在于此。而弄清商业用户如此复杂需求的真面目,正是软件开发成功的关键所在。

需求分析方法主要步骤

需求分析方法主要步骤公司标准化编码 [QQX96QT-XQQB89Q8-NQQJ6Q8-MQM9N]

1.1主要步骤 遵循科学的需求分析步骤可以使需求分析工作更高效。需求分析的一般步骤如图2-3所示。 需求涉及的方面有很多。 在功能方面,需求包括系统要做什么,相对于原系统目标系统需要进行哪些修改,目标用户有哪些,以及不同用户需要通过系统完成何种操作等。 在性能方面,需求包括用户对于系统执行速度、响应时间、吞吐量和并发度等指标的要求。 在运行环境方面,需求包括目标系统对于网络设置、硬件设备、温度和湿度等周围环境的要求,以及对操作系统、数据库和浏览器等软件配置的要求。 在界面方面,需求涉及数据的输入/输出格式的限制及方式、数据的存储介质和显示器的分辨率要求等问题。 1.1.1获取需求,识别问题 开发人员从功能、性能、界面和运行环境等多个方面识别目标系统要解决哪些问题,要满足哪些限制条件,这个过程就是对需求的获取。开发人员通过调查研究,要理解当前系统的工作模型和用户对新系统的设想与要求。 此外,在需求的获取时,还要明确用户对系统的安全性、可移植性和容错能力等其他要求。比如,多长时间需要对系统做一次备份,系统对运行的操作

系统平台有何要求,发生错误后重启系统允许的最长时间是多少等。 遗漏需求是最难修订的需求错误。 获取需求是需求分析的基础。为了能有效地获取需求,开发人员应该采取科学的需求获取方法。在实践中,获取需求的方法有很多种,比如,问卷调查、访谈、实地操作、建立原型和研究资料等。 问卷调查法是采用调查问卷的形式来进行需求分析的一种方法。通过对用户填写的调查问卷进行汇总、统计和分析,开发人员便可以得到一些有用的信息。采用这种方法时,调查问卷的设计很重要。一般在设计调查问卷时,要合理地控制开放式问题和封闭式问题的比例。 开放式问题的回答不受限制,自由灵活,能够激发用户的思维,使他们能尽可能地阐述自己的真实想法。但是,对开放式问题进行汇总和分析的工作会比较复杂。 封闭式问题的答案是预先设定的,用户从若干答案中进行选择。封闭式问题便于对问卷信息进行归纳与整理,但是会限制用户的思维。 访谈通过开发人员与特定的用户代表进行座谈,进而了解到用户的意见,是最直接的需求获取方法。为了使访谈有效,在进行访谈之前,开发人员要首先确定访谈的目的,进而准备一个问题列表,预先准备好希望通过访谈解决的问题。在访谈的过程中,开发人员要注意态度诚恳,并保持虚心求教的姿态,同时还要对重点问题进行深入的讨论。由于被访谈的用户身份可能多种多样,开发人员要根据用户的身份特点,进行提问,给予启发。当然,进行详细的记录也是访谈过程中必不可少的工作。访谈完成后,开发人员要对访谈的收获进行总结,澄清已解决的和有待进一步解决的问题。 关注用户的行为而不是他们的言语。 --JakobNielsen 为了深入地了解用户需求,有时候开发人员还会以用户的身份直接参与到现有系统的使用过程中,在亲身实践的基础上,更直接地体会现有系统的弊端

软件工程需求分析案例

11.假设你在一所职业高中工作,负责该校信息系统的建设与维护。财务科长请你研究用学校拥有的微型计算机生成工资明细表和各种财务报表的可能性。请详细描述你用结构化分析方法分析上述问题的过程。 答:通常,结构化分析过程包括问题定义、可行性研究和需求分析3个阶段。下面分别叙述这3个阶段的分析过程。 (1)问题定义 从何处着手解决财务科长提出的问呢?立即开始考虑实现工资支付系统的 详细方案并动手编写程序,对技术人员无疑是很有吸引力的。但是,在这样的 早期阶段就考虑具体的技术问题,却很可能会是我们迷失前进的方向。会计部 门(用户)并没有要求在学校自己的计算机上实现工资支付系统,仅仅要求研 究这样的可能性。后者是和前者很不相同的问题,它实际上是问,这样做预期 将获得的经济效益能超过开发这个系统的成本吗?换句话说,这样做值得吗? 优秀的系统分析员还应该进一步考虑,用户面临的问题究竟是什么。财务 科长为什么想研究在自己的计算机上实现工资支付系统的可能性呢?询问财务 科长后得知,该校一直由会计人工计算工资并编制财务报表,随着学校规模扩 大工作量也越来越大。目前每个月都需要两名会计紧张工作半个月才能完成, 不仅效率低而且成本高。今后学校规模将进一步扩大,人工计算的成本还会进 一步提高。 因此,目标是寻找一种比较便宜的生成工资明细表和各种财务报表的办法,并不一定必须在学校自己的计算机上实现工资支付系统。财务科长提出的要求,实际上并没有描述应该解决的问题,而是在建议一种解决问题的方案。这种解 决方案可能是一个好办法,分析员当然应该认真研究它,但是也还应该考虑其 他可能的解决方案,以便选出最好的方案。良好的问题定义应该明确地描述实 际问题,而不是隐含的描述解决问题的方案。 分析员应该考虑的另一个关键问题,是预期的项目规模。为了改进工资支 付系统最多可以花多少钱?虽然没人明确提出来,但是肯定会有某个限度。应 该考虑下述3个基本数字:目前计算工资所花费的成本,新系统的开发成本和 运行费用。新系统的运行费用必须低于目前的成本,而且节省的费用应该能使 学校在一个合理的期限内收回开发新系统时的投资。 目前,每个月有两名会计用半个月时间计算工资和编制报表,一名会计每 个月的工资和岗位津贴共约2000元,因此,每年为此项工作花费的人工费约2.4万元。显然,任何新系统的运行费用也不可能减少到小于零,因此,新系统每 年最多可能获得的经济效益是2.4万元。 为了每年能节省2.4万元,投资多少钱是可以接受的呢?绝大多数单位都 希望在3年内收回投资,因此,7.2万元可能是投资额的一个合理的上限值。 虽然这是一个很粗略的数字,但是它确实能使用户对项目规模有一些了解。 为了请客户(会计科和学校校长)检验分析员对需要解决的问题和项目规 模的认识是否正确,以便在双方达成共识的基础上开发出确实能满足用户实际 需要的新系统,典型地,分析员用一份简短的书面备忘录表达他对问题的认识,这份文档称为“关于系统规模和目标的报告书”(见表2.1)。

相关文档
最新文档