精华内容
下载资源
问答
  • 做数据分析的基础在于数字的「分类」与「比较」「上个月的销售额是 3000 万日元」在销售会议上,如果你只用这一句话就结束了关于「上个月的销售情况」的报告,会怎样呢?「哦,然后呢……?」上司、同事们应该会产生...

    做数据分析的基础在于数字的「分类」与「比较」

    「上个月的销售额是 3000 万日元」

    在销售会议上,如果你只用这一句话就结束了关于「上个月的销售情况」的报告,会怎样呢?

    「哦,然后呢……?」

    上司、同事们应该会产生这样的疑问。这样是万万不行的。

    「我们知道了这些数据。但是这些数据代表了什么含义?」

    可能有人会对你提出这样的疑问,如果你回答不上来,就有必要认真学习商业数据分析的基础知识。

    实际上,这里有个很大的课题。在公司内部累积了各种各样的数据,但在大多数情况下这些数据都没有得到充分利用。因为没有人知道为了提高收益进行现状分析、设定目标、制定计划,应该如何灵活运用这些来之不易的数据。所以也无从下手。

    所谓数字分析的基础,就是「分类、比较」。

    首先,将数据细致拆分到某种程度。比如「销售额」这种数据,可考虑从以下角度进行划分。

    • 按客户(年龄层)
    • 按地域划分
    • 按分公司划分
    • 按商品划分
    • 按负责人划分

    接下来,将这些拆分后的数字资料与其他数据做对比。「与某个标准相比,是高还是低?」如果不运用这样的指标,就无从评价这些数据是好是坏。

    关于这一点,有几个标准解答范例,比如做以下说明。

    「上个月的销售额为 3000 万,与去年同期相比增加了 112%,达到目标达成率的 108%。」

    「按商品类别来看后,A 商品占全体的 70%,可以说销售额大多来自这个商品。」

    「因此,有必要提高其他商品的比例,建立更加稳定的利润结构」

    从销售额减去劳动成本、原价等,可得到的「毛利」、「毛利率」等数据,验证这些数据时不仅要从销售额出发,还要以「销售件数」为着眼点进行分析,这也是非常重要的。

    像这样的说明,并不是只有掌握了丰富的商业知识与经验才能做好。事先了解工作中需处理的数据的基础,之后利用简单的除法运算,谁都能够做到。

    商务工作中分析数据的 3 个基础指标

    但是,突然让你「分析商务数据」,你也不知道如何分析数据资料,也不知道应该和什么样的数据做对比,这样你就会被困在 Excel 的数据中,即使花费了大量的时间,也无法得到满意的结果。在此,希望大家掌握分析商业数据上的三大基础指标。

    • 同比率(与去年相比是增加还是减少)
    • 预算与实绩相比(是否达到目标)
    • 构成的比率(每项各占多少比例)

    以上无论哪一种,都可以用简单的除法运算计算出来。

    同比率 ~ 销售额是增长还是下降

    【计算公式】

    同比率 = 今年的数据 ÷ 去年的数据

    在企业中评价销售额成绩的第一大指标,就是同比率。也就是说,与去年相比销售额是增长还是减少的数值。

    • 去年的销售额为 100 万日元,今年的销售额为 120 万日元,则同比率为 120%,「数据达标」。
    • 去年销售额为 100 万日元,今年销售额为 90 万日元,则同比率为 90%,「低于去年」。

    并不是说,这个指标一定要超过 100%。

    销售额少于去年的话,可以对这一数据进行进一步的分析,研究同期增长率,找出销售额下降的主要原因。当然,有时比如由市场变化导致的销售额下降,这种无法明确其中原因的情况也是存在的,也有「某公司的大客户公司倒闭导致整体业绩下滑」这样问题并不出在自己公司的情况。无论是哪一种,都能分析出「销售额下滑」这一状况的原因所在。这种分析都可以从同比率这种简单的除法中看出来。

    分析同比率最重要的一点是「同一时期、同一期间与去年作比较」。商务活动十分容易受到季节变动的影响。受季节变化、节假日影响较大的日本,同一款商品在不同季节的销路都会发生变化,季节不同,畅销商品也不一样。因此,需要大家思考以下这些问题。

    • 检验当月的业绩 ➛ 得出「环比率」
    • 检验每 3 个月的业绩 ➛ 得出「同比率」

    有时候可以用「与上个月相比销售额是否有所增长」来进行分析。比如「9 月份游乐场的游客数比上个月下降了 40%」这样的结果,因为 8 月份为暑假期间,得出这样的结果并不奇怪,但如果与去年的 9 月份相比游客也是大幅减少的话,就能够快速判断出入园人数其实是在减少这种倾向。接下来,就可以面向 10 月份想出解决对策,付诸行动。

    达成率 ~ 是否达成目标

    【计算公式】

    达成率 = 实际值 ÷ 预期值(目标值)

    所谓达成率,即「预算金额」与「实际金额」的比率。这里的「预算金额」就是指目标。也就是说,达成率表示的是「高于还是低于目标金额」的指标。

    「预算」在达成率中表示目标值,而有一些文化企业将「预算」这个词作为「公司可使用的资金」的意思来使用。但是,「预算与实绩管理」这个词是商务经营的基本用语,预算这个词本身就含有目标的意思。希望大家有所了解。

    结构比率 ~ 数字明细各占多少比例

    【计算公式】

    结构比率 = 部分 ÷ 整体

    全公司的销售总额等整体的统计数据,有必要进一步计算出详细的数据。像前文中提到的,我们可以从以下的角度进一步分析数据。

    • 客户(年龄层)
    • 地域
    • 分公司
    • 商品
    • 负责人

    以这些标准分析得出的各个构成要素在整体中占有的比例,这个比例数字就是结构比率。也被称作「份额」「构成比率」。由此,可以分析出各个要素的贡献度、偏重比例、依赖程度等。

    学会「用数据说话」

    如下这张按负责人划分的销售额一览表。

    按负责人划分的销售额一览表

    37bd82c49690cfac823d976df07aaaa0.png

    像这样只看见实际数据,只能大概了解每名负责人之间的业绩对比,做出非常模糊的判断。最多得出这样的结论:

    「山崎的销售额是最多的啊。」

    「川又的销售额真是少得可怜。」

    只能用抽象的形容词来说明。

    我们经常可以听到这句话:用数据说话增加说服力。即使知道「每一名销售人员的销售额的业绩」的数据也没有任何意义。「用数据说话」最为重要的基础事项在于:

    「实际数据,以百分比(比率、比例)表现才是有说服力的数据」

    试着在这张表中追加每一名负责人的结构比率吧。

    按负责人划分的销售额一览表中追加各负责人的结构比率

    f861f0bd6cc85a1b328622839c446a29.png

    如此一来,大家就会知道每一名负责人销售额所占比例。将数据制作成图表的话,就会一目了然。

    即使是口头说明,像下面这样解说的话,讲话人的说服力、聆听者的理解程度也会截然不同。

    【Before】

    山崎的销售额是最多的啊。

    【After】

    山崎的销售额构成比占整体的 43%,约占整体的一半。

    「最多的」这种措辞非常幼稚,而「占整体的 43%」这种说法只是将前者转为带有百分比数据的表达方式,就迅速变成了商务级别的对话级别。

    当然,只是改变表达方式并不是我们的工作。「了解了这一事实,接下来要采取什么行动」,将获得的数据作为下一次的计划、行动的根据来使用,才是分析数据的重点。

    必须清楚制作表格的目的

    运用这些方法实际分析销售额的资料如下。

    按全国各分公司的销售额,得出同比率、达成率、结构比率的表格

    e5d5ebcc2b57c6adb22867cdf201a6de.png

    这是某企业的全国各分公司的销售额数据,这张表格里含有同比率、达成率和各分公司在所有分公司的销售额中所占的比率。除了同比率,其中还有一个指标表示实际差额——「去年差额」。另外,同时比较同比率与达成率,以及在表格中添加结构比率这些数据也有重大意义。其中最重要的是要明确这些问题:

    「在表格中想要表达什么?」

    「制作表格的目的是什么?」

    为何不仅要添加同比率,还要添加「去年差额」?

    首先,在表格中添加同比率,以及表示实际差额的去年差额的意义是什么?比如说,以酒税区分「啤酒」为例,来看一下首都圈与冲绳的同比率吧。

    首都圈的同比率为 107%,冲绳是 132%。首都圈的同比率为 107% 这个数据表示对比去年有所增长,可以说是个很好的成绩。但是与冲绳的 132% 比较后,就能得出「冲绳比首都圈地区增长得更多」的结论。另外,也会这么想「冲绳的销售人员比首都圈的更加努力,因此获得了比去年更好的成绩」。

    这时,除同比率的数据外,如果设有表示与去年的实际差额的「去年差额」项目,就能从另一个的角度解读这份资料了。确实,冲绳地区的销售额销售人员在努力增加销售额,所以同比率的数据比较高。但是,同比率这种表示增长率的指标,如果分母小的话,那么得出的结果会呈现出大幅增加的状态。因此,

    「对比首都圈与冲绳的销售额增长度后,显然冲绳地区的销售人员更为优秀」

    不能只是说明这点,通过对比去年差额这种表示实际差额的数据,

    「首都圈也积累增加了大额交易,对全公司的贡献程度很高」

    就能够做出补充说明,所以才要追加「去年差额」这个数据。

    以百分比表现数据很重要,但是反过来说,「百分比也要和实际数字一同解释说明」。如「利润率」这一指标很重要,但比较各企业经营情况的时候不能只比较利润率,同时还应比较「利润额」,这样才能做出最正确的判断。

    添加同比率 &达成率的理由

    在表格中并列添加同比率和达成率是有明确理由的。

    我们来对比一下首都圈的同比率和达成率吧。同比率为 107% 意味着今年的销售业绩超过了去年,而达成率的 86% 意味着远远未达到预算目标。这时就会引出一个疑问:

    「这个目标值(预算)是否恰当?」

    从而会让大家反思「目标值是不是过高」?

    有些公司会把是否达成预算(目标)作为评价销售经理或者销售部门业绩的考核标准。那么要采用这样的指标当然需要设置一个合适的目标值。如果设定了无论如何都达不到的目标,没有达到目标就无法得到认可……但人类是情感动物,这样做会打击员工的积极性。

    这种情况下,作为检验目标值是否恰当的方法之一,可以比较同比率和达成率。也就是说:

    「虽然销售额同比率为 107%,但是这个数字远远未达到目标值,这是否说明原来设置的目标值过高?」

    这样就有进一步商量讨论的余地了。

    这时,如果只是提出「目标值设得过高」也没有任何说服力。而通过展现同比率这一指标,

    「虽然同比率达到了 107%,却还是远远没有达到目标值,这样的目标值到底是如何计算出来的呢?」

    这样就会促使大家进一步讨论,从而提出合适的目标。

    为什么要添加结构比率

    原则上来说,得出的数据并不会出现特别异常的情况。拥有巨大市场的首都圈等大城市的结构比率相对较高也是理所应当的事。

    而在此添加结构比率是为了观察是否存在结构比率突然增大或突然减少的情况。如果平时构成比率并不高的地区的构成比率突然增大,

    「这一地区是不是发生了什么事情,会不会存在潜在商机?」

    「这一地区的负责人是不是采取了特殊举措?」

    像这样进一步调查,就能得到新的发现。

    同时考查实际业绩和百分比,这一点很重要。「只看实际业绩」或「只看百分比」,都会引起遗漏或错误判断现状的问题。

    将数据资料迅速转化为表格的技巧

    下图为前文中提到的表格的全貌。

    前文中的表格全貌

    9dee2f8603cf50c0e2b2e3276a1db944.png

    这张表是根据同一张表内的【数据加工】工作表中的数据为材料制作的。

    作为表格的材料的【数据加工】工作表中数据

    047c39bb4bcf5f96a049ad9d83315b0d.png

    这张表格由 5 个项目构成。每一列项目名的单元格中主要有以下项目:

    • A 列 ➛ 表示销售日期的六位数值
    • B 列 ➛ 零售商区域
    • C 列 ➛ 商品代码
    • D 列 ➛ 商品名称
    • E 列 ➛ 销售额

    也就是说,这些数据表示的是在某一段期间内,按月份、地区、商品来分类的销售额数据。但是,浏览这个放有大量信息的数据表,即使我们只能了解某些事实,却还是不能知道整体趋势和实际业绩。

    那么,如果让你「以这个数据为材料分析销售情况」,应该从哪里着手呢?

    首先,如果你能立刻想到同比率、达成率和结构比率三个基本指标的话,就能够快速开展分析工作。

    将新的统计标准追加添加到元数据中

    我们再确认一下最终表格的结构。

    纵轴为「种类」和「分公司」。横轴为按季度分类的 2009 年和 2010 年,这两个年度的项目。

    但是,元数据中却没有这些项目。

    实际上这里需要转化数据。

    • 商品名称 ➛ 种类
    • 县名 ➛ 分公司
    • 销售日期 ➛ 年度、季度

    具体来说,需要在元数据中的作业列中追加转化后的数据。最终,元数据会变成下表的状态。

    在元数据中追加转化后的数据

    b4a343f6ae83fcc3f786b6e33c2c2215.png

    F 列的「种类」,是参照 C 列的商品代码输入的。另外,G 列的「分公司」,则是参照 B 列的县名输入的。

    以第 2 行的数据为例,数据发生了如下转化。

    • 爱知县 ➛ 中部
    • 27210786➛ 发泡酒

    为了快速完成这种转化,需要预先制作转化对应表(转化表)。比如在其他工作表中制作下图这样的表格。

    74d416cb3b9d40c00d5bcb626d8bd1bd.png

    事先制作这样的变化对应表作为准备材料,之后再用 VLOOKUP 函数就可以转化所有数据。

    我们来逐个看一下追加转换后的数据的函数。用来制作转化数据的表格的名称为「变化表」。

    • F 列(种类)➛=VLOOKUP(C2,变化表!A:C,3,0)
    • G 列(分公司)➛=VLOOKUP(B2,变化表!E:F,2,0)
    • H 列(年度)➛=LEFT(A2,4)
    • I 列(月)➛=VALUE(RIGHT(A2,2))
    • ※只使用 RIGHT 函数的话会得出「01」这样的字符串,因此作为在 J 列中的 VLOOKUP 函数的第一参数使用时会出现错误,应用 VALUE 函数将其转化为数值。
    • J 列(季度)➛=VLOOKUP(I2,变化表!H:I,2,0)
    • K 列(KEY)➛=F2&G2&H2&J2

    ※用于输入统计表中的 SUMIF 函数的第一参数(检索范围)。

    在第 2 行中输入这些函数,然后一直复制到数据最后一行(双击鼠标就可瞬间完成),就能快速转化数据。元数据中没有的项目,可以通过函数自行追加,按照自己的想法统计数据。这样一来,就整理好了用作材料的数据。

    请勿使用数据透视表(Pivot Table)

    在 Excel 中,有一个方法可以快速统计出数据库形式的数据,那就是数据透视表(Pivot Table)。通过实际的使用案例,我们来看一下它有哪些作用。

    ➊ 选择需要统计的数据库表格中的任意一个单元格,【插入】选项卡 ➛ 点击【数据透视表】。

    ➋ 在下面弹出的【创建数据透视表】窗口中点击【确定】。

    7fb245a15320098e87c2b8f4128ab05e.png

    这里,已经勾选数据透视表选项卡 ➛【视图】中【使用历来数据透视表设定(可拖拽格子内的区域)】的画面,勾选这一选项,使用数据透视表时会更加方便。

    ➌ 在画面右侧,会出现选择的数据库表项目一览的字段列表画面。在此,勾选【零售商区域】,数据透视表的纵轴就会出现「零售商区域」。

    64f561cbcbf53d133bf91415cf4d8cdf.png

    ➍ 在字段列表中勾选【销售金额】,就可以按照零售商区域统计金额。

    20a19a9fc452c55ae622c6405f01d805.png

    ➎ 接下来将【商品代码】的部分拖拽复制至画面右下方的【列区域】中,就可以按照「零售商区域」「商品代码」来统计金额。

    ab2b90cf5f5300082cafff536abe49b5.png

    像这样,数据透视表可以简单制作各种统计表格。因为其强大的统计功能,被认作是「制作表格的必备工具」,在实际工作中经常被使用。但它有个很大的漏洞,那就是:

    「如果把定期更新的资料为源数据制作成数据透视表,就会大大降低制作效率。」

    这一点请务必记住。

    大家经常犯的错误就是不断使用数据透视表进行汇总,然后复制到表格中,并且不断重复这样的操作。这种做法不仅非常没有效率,而且在复制粘贴过程中也非常容易产生错误。

    一旦建立格式,就可反复套用

    这时,从材料数据中制作用函数统计的格式是最好的方法。一旦做成这种格式,之后只要将材料数据粘贴到固定位置就能够完成表格。

    在表格中,首先在单元格 J6 中输入以下汇总公式:

    =SUMIF(数据加工!$K:$K,

    $A6&$B6&J$5&J$4,数据加工!$E:$E)

    在单元格 J6 中输入 =SUMIF(数据加工!$K:$K,$A6 &$B6&J$5&J$4,数据加工!$E:$E)

    ea0a08881b830c390d6d75f4e8d6b62a.png

    在第二参数中,结合了以下 4 个单元格的数值。

    • 单元格 A6「啤酒」
    • 单元格 B6「北海道」
    • 单元格 J5「2009」
    • 单元格 J4「1Q」

    在单元格 J5 中实际上输入的是「2009」这个数值。同样,单元格 K5 里也输入了「2001」这个数值。但是,单元格上显示的却是「2009 年」,后缀有「年」这个字。在【设置单元格格式】➛【表示格式】的【自定义】中,在【种类】的编辑栏中输入以下内容,就能够在单元格中显示「年」这个字。

    0「年」

    但是,实际上在单元格中输入的是「2009」、「2010」这样的数值。而前文中的函数的第二参数就变为了「啤酒北海道 20091Q」的字符串。

    第一参数指定的是「数据加工」工作表中的 K 列,这一列中组合了种类、分公司、年度、季度这 4 个字符串。也就是说,这个公式在进行这样的处理,

    • 「数据加工」工作表的 K 列
    • 为「啤酒北海道 20091Q」字符串时
    • 统计「数据加工」工作表 E 列的销售额总值

    将这个 J6 中的公式直接从 J6 复制到 K14 后,就能统计出各分公司的年度销售额。

    92b95d047ecdb7c4a05f0c9283b84e73.png

    将单元格 J6 的公式一直复制到 K14

    这是将最开始单元格 J6 中的公式一直复制粘贴到 J6:K14 的范围后,例如,选择单元格 K9,按

    F2

    键后,就会变成下表中的状态。

    单元格 K9 中含有 SUMIF 函数

    ec95aa4aced283c9db92d58890cd53b7.png

    第二参数引用了 4 个单元格的 SUMIF 函数,但 A9、K4 这两个单元格看上去引用的是空白单元格。这里其实使用了一个秘诀。

    下图是选中 A 列的状态。选中后,各个种类中的「啤酒」、「发泡酒」不仅直接出现在单元格中,同时也以白色文字的状态存在于 A 列空白位置的单元格中。

    在 A 列中的文字变为白色

    f8c9fec23b1d5b5614d741f62266a2bb.png

    当然,这些文字是作为 SUMIF 的参数输入到单元格中的,但如果所有的单元格中都出现这些文字也会让人无法看懂表格中的内容,所以只保留一个单元格中的文字,将其他单元格中的相同文字的字体颜色设置为白色。在第 4 行中才采用了相同的处理方法。

    接下来,用 SUMIF 函数统计出总和,并在同比率的单元格中加入今年 ÷ 去年的除法公式,就可以得出同比率。

    这时,在有同比率的表格中事先设置「数值小于 100% 时单元格内文字变红且加粗」这样的格式,就可以像下图中这样自动判定计算结果并改变文字格式。

    通过附带条件格式将同比率的数值小于 100% 的单元格中的文字设置成红字且加粗

    679aa4b21a5b12d4cf027f2951d78962.png

    然后,按照以下的操作顺序在其他单元格中填入公式,即可完成表格。

    ➊ 选中啤酒的第一季度(1Q)范围,按Ctrl+C复制。

    d46f0328151162e6f0551c79b7e213ed.png

    ➋ 指定粘贴的范围。

    0a726b685ff0189dd0a090fb7b6d6834.png

    ➌ 按Ctrl+V 粘贴。

    bb43556128d89a57565f32926ef40524.png

    如此一来,只要在一开始制作自动汇总表的格式,就能多次利用,也就不用再重复相似的统计工作了。通过这个机制,只要在「数据加工」工作表的特定位置粘贴元数据,函数就会自动计算数据,表格也就制作完成了。

    这样,1 分钟就能完成原本需要 2 小时才能完成的工作。如果是使用数据透视表的话,即使做到天黑,制作好的资料也可能会有错误,根本无法使用。

    用最少的精力获得最大成果的帕累托①分析法

    为削减经费所付出的努力真的有意义吗?

    提高销售额。

    减少开支。

    这二者都是为了提高利润十分重要的事项,但并不是胡乱行动。如果把精力浪费在错误的对象上,即使花费大量的时间和精力,也无法获得满意的结果,最后只能获得「多劳少得」的下场。这样,不仅降低了生产能力,更是增加了多余的时间成本,浪费时间。严重的话,也会打击员工的积极性。

    比如减少开支。大部分的企业认为努力「减少不必要的成本」本身是件非常有意义的事情。但是,不要忘记为了减少开支需要花费一定的劳动和时间成本。如果为削减成本花掉的时间成本,反而超过了削减的部分,这样就本末倒置了。像这样「毫无意义地努力削减经费」的做法十分不可取。我列举一些至今为止我遇到的实际事例供大家参考:

    • 将便利贴裁开使用
    • 利用打印纸的反面
    • 离开座位 10 分钟以上的话,关闭计算机电源
    • 裁切使用过的打印纸,当作记事本

    这些都是十分花费时间和精力的事情,想要通过这些方法削减经费,并不能减少很可观的开支,也就是说无法产生新的利益。考虑到做这些事情需要花费的人工费用,可能还会产生赤字。像这种削减成本的工作通常十分无趣,生产性也过低,也会导致员工的积极性下降。

    关于削减成本方面,经常可以听到这样一句话,「积少成多」。

    我们需要辨别「我做的这些工作是否真的能够积少成多。」

    帕累托法则

    「帕累托法则」是在商务领域中经常会提到的思考方法,也叫作「80:20 法则」。它是指:

    「销售额的 80%,是由 20% 的客户提供的。」

    「经费的 80%,是由 20% 的员工使用的经费构成的。」

    一言以蔽之,假定了「一部分的构成要素会给整体带来巨大影响」。

    通过下面的表格会更加容易理解。

    按客户分类的销售额结构比率

    9f68b6270644248cdf787be4b7db6b2f.png

    这是某公司按客户分类的销售额结构比率数据做成的图表。客户分为 A、B 两组,表示每组中的客户数量(图表内为件数)和销售金额的比例。

    从这张图表中,可以立刻发现一个事实:在件数中占比不到 26% 的 A 组客户,却提供了 80% 的销售额。如果失去或者损失这 26%
    的客户的销售额的话,甚至会达到影响整个公司的经营状况的程度。因此,就可以做出建立防止这 26% 的客户流失、采取继续维持合作关系的战略这样的判断。

    将帕累托分析法运用于制作图表的 3 个方法

    想要制作出这样的图表,需要按照以下的 3 个分析手法的顺序处理。

    ➊ 排名分析

    首先,可以简单地按照消费金额的大小给客户排序。这时,可通过 Excel 的排序功能处理。这样就可以将重要的客户排在名单的最上方。

    例如,在提交新产品方案的时候,可以按照这个顺序给客户打电话。如果客户名单是按姓氏排列的话,选择使用下列的哪一种方法,也会大大影响销售的效率。

    • 直接按照顺序从上往下依次打电话
    • 先按照消费金额的大小(降序)排列数据,从上往下依次打电话

    Excel 的「排序」功能能够帮助我们实现「从最重要的客户开始联络」这样理所当然的想法。

    ➋ ABC 分析

    按照客户分类的销售额数据进行降序排列后,计算出每个客户的消费金额的构成比率。在下一页的表格中,单元格 C1 中含有所有客户的消费金额的总和。将 C1
    和每位客户的消费金额做除法,可以得出结构比率的数据。在单元格 D4 中输入下列公式,一直复制粘贴到最后一行。

    =C4/$C$1

    然后,将结构比率相加,可以得出累计结构比率。

    得出每个客户的消费金额的结构比率

    fb0ea60fede17a60c6c7321f5c6cb1bc.png

    得出累计结构比率

    7c9868b55734ccda775368930b841649.png

    像这样,比如就能知道「前 3 家客户公司占了整体销售额的 50%,说明这三家公司是我们重要的客户」。为了明确客户的重要程度,「将客户分成若干小组」这种分析手法就是 ABC 分析法。在此,将累计结构比率大于或等于 80% 的客户分到 A 组,小于 80% 的分到 B 组。

    可用 IF 函数处理这种分类。在单元格 F4 中输入下列公式,一直复制粘贴到最后一行,就能自动分成 A、B 两组了。

    =IF(E4

    在单元格 F4 中输入 =IF(E4 ,「A」,「B」),分成 A、B 组

    33fc03a83331a88987a881f18d6137c7.png

    ➌ 帕累托分析

    2821c7f53e1eaafca69af0f3c36db778.png

    像这样将客户分为 A 等组与 B 等组之后,接下来就要计算两组的「交易件数」和「总计金额」了。表格则呈现以下形式。

    得出 A 组客户与 B 组客户的「交易件数」与「总计金额」

    用 COUNTIF 函数计算「A 和 B 各有多少个」。

    用 SUMIF 函数得出「A 和 B 的总销售额是多少」。

    得出实际数字后,再计算结构比率。A 的销售件数占整体的 26%,但销售额却占结构比率的 80%。而 B 的销售件数虽然占整体的 74%,销售额的结构比率却不足 20%。将这个结果制作成图表,就会看到前文中的「按客户分类的销售额结构比率」那样的表。

    这样就一目了然了吧?对于这家公司来说,首先必须维护好 A 组客户,当然也不能忽视 B 组。但从优先顺序来说,应该要对 A 组客户予以更多的重视。从经营战略角度来说,

    「把提供给 A 组客户的优惠政策介绍给 B 组客户,可以刺激 B 组客户的购买欲,积极升级到 A 组的等级。」

    而提出这种战略计划的根据或分析,只需制作一张简单的 Excel 表格。

    在削减经费方面也是一样。提取出占据大部分比例的要素后,不对症下药的话也不会有任何改善。如将便利贴裁成一半使用,重复利用打印纸的反面,等等,与其在这种事情上花费大量的时间,还不如多找出「占整体经费 80% 的支出是什么」。

    「社长的租车费用占了很大比例。」

    「如果减掉『管理层的交际费』里面每月的夜总会花销,经费能节省 20%。」

    这样就能发现一些真正需要改善的地方。不要在费力而不见效的事情上花费大量的时间和精力。为了明确真正应该付出努力的对象,一定要在了解 Excel 的基础技能的基础上,熟练运用各种分析手法。

    以「资金方块拼图」来理解公司的资金流动

    以「销售目标」为主要课题的企业非常多,其实在商务活动中应该重视的数字不只有「销售额」,「利润」也同样重要。

    「利润」,粗略来讲就是「销售额减去成本后得到的数字」。如果销售额是 100 万日元,但是成本也花去了 100 万,那么利润就是零。

    想要增加利润,选择以下两种中的其中一种或者二者结合运用(但在真实的经营环境下,并不一定都会有效果。削减经费后却导致销售额下滑,增加经费也有可能增加利润)。

    • 增加销售额
    • 削减经费

    那么,为了增加销售额,应该做些什么?削减经费,又应该做些什么呢?

    这里介绍给大家一个绝对不会弄错先后顺序的方法,那就是下面的「资金方块拼图」,通过这张图可以完全把握公司的资金流动情况。

    08812876d7955038dadfa99475ccb305.png

    为了增加公司的现金流和利润,提高销售额、削减经费是最有效的方法。

    战略上要明确轻重缓急,为了使对策的效果最大化,应该从哪方面着手。

    想要明确改善对象,能够找出「占据 80% 的 20% 是什么」的帕累托分析法是最有效的方法。「资金方块拼图」,是西顺一郎先生的 STRAC 表为基础建立的一种思考方法,和仁达也先生获得了原作者的允许,将其改良。

    作为提供商品和服务的等价回报,从客户那里收取费用。这就是销售额 ①。

    供应商成本、材料费、外包费等与销售额呈比例变动的费用,需要从销售额中剔除。这一部分费用称作「变动成本」②。

    从 ① 的销售额减去 ② 的变动成本后得到的资金就是 ③「毛利」。

    租金、人工成本和其他销售管理成本等变动成本以外的费用称作「固定成本」④。

    固定成本大致可分为两部分,人工成本 ⑤ 和「其他固定成本」⑥。

    从固定成本中减去毛利得到的剩余资金就是「利润」⑦。

    这些用语,与利润表、资产负债表等各种财务表中出现的会计用语多少有些不同。例如,「利润」原本有销售利润、经常性净利润和当期利润等意思,在本书中作简化说明。

    如何运用帕累托分析法

    这 7 个资金种类中,哪种可以运用帕累托分析法处理呢?

    例如「削减固定成本」,相信这是每家公司都在努力做的事情。为了知道「应该从固定成本中的哪个经费开始下手」,可以使用帕累托分析法。

    如果想不增加固定成本而提高员工薪资的话,就要考虑削减人工成本除外的「其他固定成本」。这时,削减「其他固定成本」那个部分就变得尤其重要。只要找到效果较大的目标,即占据整体 80% 的 20% 的费用项目,然后从这个地方开始着手削减经费就事半功倍了。

    关于变动费用也是一样。如果占据大部分进货成本的是少数的供货商和商品的话,只要他们稍微降低一些价格,就极有可能大幅减少成本 = 增加毛利。与不断地对供货商提出难以接受的降价要求比起来,这个方法无疑是最明智的。

    当然关于销售额方面,按照客户、商品进行分类后运用 ABC 分析、帕累托分析,立刻就能找出重点客户和利润最大的商品。

    平均值会说谎

    最后,还有一件事想告诉大家。

    几乎所有关于 Excel 的书或研讨会,都把导出「平均值」的 AVERAGE 函数作为一个重要的基础函数介绍给大家。但是,在我的 Excel 培训课上并不会这样做。为什么呢?这是因为在制作处理数字数据的资料表格时,我认为不应该随意使用「平均值」。

    「平均值会说谎」

    请首先记住这句话。

    我们在许多场合都会遇到平均值这个指标。如考试成绩的平均分、平均收入。知道了平均值,再和自己的实际情况作对比,随着数值忽高忽低也或喜或忧。

    所谓平均值,就是所有数值的总和除以全部个数所得出的数值。这总会让人觉得它是「所有数值中最中间的数值」。但是,平均值有可能是脱离实际情况的。

    例如,有一家想要在某一地区开展销售房屋业务的建筑公司,要在此区域调查可行的价格范围,于是对当地的人均年收入进行了调研,结果得出 600 万日元。于是,这家建筑公司做出了这样的判断:该地区「年收入 600 万日元的人占大多数」。因此决定以年收入 600 万日元左右的人群为目标建筑楼盘。但实际上,当地人们的收入情况有非常明显的等级差别,即「年收入 900 万日元的人群」与「年收入 300 万日元的人群」呈两极分化状态。的确,两者相加除以 2,就可以得出平均年收入为 600 万日元的结果。但是实际上,并没有年收入达到 600 万日元的人群。

    另外,公司一般用到的指标还有「平均年收入」。以此为判断依据的时候也需要注意。乍一看很高的平均年收入数字,很有可能是因为一部分中高层管理人员的高额收入拉高了平均值,而实际上大部分员工的年收入要远远低于平均值。

    像这样的例子不在少数。请一定注意平均值会有偏离实际情况的风险。

    统计学中针对这个问题,给出了「标准差」的概念,用于了解计算平均值的各个数值的偏差情况。但是,即使在公司报告说明时使用这个概念,即使听者感觉理解了这部分内容,但在实际的商务现场中并一定具有足够的说服力来实现方案中的内容。

    遇到在商务文本中使用「平均值」的情况时,如果追问这个平均值是如何得出的,很多人会这么回答:「差不多是这样」、「之前的负责人算出来的」。没有带着明确的意图制作资料,就会变成这样。这是需要花费自己的宝贵时间与精力的工作,「这件工作能得到怎样的成果?」对这一点要有足够深刻的认识,绝不能随意地制作商务文本。

    希望大家能够牢记工作必需的三大要素:自主性、责任感、全局观,将 Excel 当成武器,大幅提高自己的工作能力。

    ①帕累托分析法(Paretoanalysis)是制定决策的统计方法,用于从众多任务中选择有限数量的任务以取得显著的整体效果。帕累托分析法使用了帕累托法则,关于做 20% 的事可以产生整个工作 80% 的效果的法则。

    展开全文
  • 怎样做需求分析

    2017-04-27 10:04:14
    需求分析 在具体的研究需求分析之前,我们...关键过程区域构成了软件项目的管理控制的基础,并且确立了上下文各区域的关系,其中规定了技术方法的采用、工程产品的,模型、文档、数据报告、表格等,等的产生、里程
    需求分析

    在具体的研究需求分析之前,我们先了解一下软件工程这个概念。软件工程分为三个层次,过程层、方法层、工具层。在最基础的过程层,最重要的就是一组被称为关键过程区域(KPAs)的框架(KPA的概念在讨论CMM的书中有详细的概念说明)。关键过程区域构成了软件项目的管理控制的基础,并且确立了上下文各区域的关系,其中规定了技术方法的采用、工程产品的,模型、文档、数据、报告、表格等,等的产生、里程碑的建立、质量的保证及变化的适当管理。方法层主要是过程在技术上的实现。它解决的问题是如何做。软件工程方法涵盖了一系列的任务:需求分析、设计、编程、测试、维护。同时他还包括了一组基本原则,控制了每一个的关键过程区域。工具层就很好理解了,他对过程层和方法层提供了自动和半自动的支持。这些辅助工具就称为CASE

    可以看到需求分析的位置,但是事实上需求分析是跨越了软件工程的三个层次的。这一点是和其他的过程是一样的。当然我们这里比较重点强调的是在软件工程的方法层,同时也涉及到一些过程层的思想,至于工具层则不再我们的讨论之列,但是会提到一些很适合在需求分析时应用的工具,诸如WordExcelVisio等。

    方法

    需求分析都包括了哪些方法呢?这里列举出在《需求分析》一书中推荐的一些方法,

    1) 
    绘制系统关联图,这种关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。

    2) 
    创建用户接口原型,当开发人员或用户不能确定需求时,开发一个用户接口原型一个可能的局部实现这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。

    3) 
    分析需求可行性,在允许的成本、性能要求下,分析每项需求实施的可行性,明确与每项需求实现相联系的风险,包括与其它需求的冲突,对外界因素的依赖和技术障碍。

    4) 
    确定需求的优先级别,应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时,在特定的版本中加入每一项变更,并在那个版本计划中作出需要的变更。

    5) 
    为需求建立模型,需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。

    6) 
    创建数据字典,数据字典是对系统用到的所有数据项和结构的定义,以确保开发人员使用统一的数据定义。在需求阶段,数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。

    7) 
    使用质量功能调配,(QFD)是一种高级系统技术,它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。QFD将需求分为三类:期望需求,即客户或许并未提及,但如若缺少会让他们感到不满意;普通需求;兴奋需求,即实现了会给客户带去惊喜,但若未实现也不会受到责备(Zultner 1993;Pardee 1996)。

    记住一点,不要试图在你的项目中把这些方法都用上去,四个现代化并不是一夜就可以实现的。同样,尝试着使用你认为对你很有帮助的方法,确实收到效果之后,在考虑继续学习方法。因为上面提到的都是需求分析的大方法,事实上还有很多很多的方法可以采用,例如,采用SRS模板、指明需求的来源、为每项需求注上标号、记录业务规范、创建需求跟踪能力矩阵、审查需求文档、以需求为依据编写测试用例、编写用户手册、确定合格的标准。

    业务建模

    很多人都没有意识到业务需求阶段应该做些什么事情,实际上业务建模是最重要的一件事情。不要觉得业务建模这个词很深奥,让人模不着头脑。其实所有做过需求分析的人都做过业务建模,比如你了解企业的运作模式就是一种你脑海中的业务建模。但是大多数人都没有科学的、系统的、文档化的做过业务建模。

    业务建模的目的在于: 

    了解目标组织(将要在其中部署系统的组织)的结构及机制。

    了解目标组织中当前存在的问题并确定改进的可能性。
    确保客户、最终用户和开发人员就目标组织达成共识。
    导出支持目标组织所需的业务需求。

    上面的话是不是很抽象呢,其实没有什么复杂的:人和电脑是完全不同的思想(思维方式)。所以,原先适合人的业务流程对于计算机来说可不一定合适的,为了最大限度的利用计算机,必须要了解原先的业务流程并对此加易改造(流程自动化),当然这些动作需要得到用户的许可。有些人认为说只有ERP这种大系统才需要对业务流程进行重组,但是实际上,不论是部门级的MIS系统,还是社会级的电子商务系统,都需要对业务流程进行改造,所不同的只是改造的程度。

    业务建模很重要的一点是在分析企业流程的同时分析出基础企业对象(Common Business Object)(这个词我翻译的不好,如果大家有更好的翻译,请告诉我)。任何企业都有最基础的一些元素,例如银行的CBO就有帐户,制造业的CBO就有订单等。有一次我的一个在企业应用方面研究多年的朋友告诉我一个秘诀,他说,企业的CBO无非是4个:客户、员工、产品和供应商(银行的供应商应该称为同业)。其他的所有CBO都是在这四个CBO的基础上发展起来的。比如说CBO中客户和产品是多对多的关系,根据关系数据的理论,任何多对多的关系都可以拆分成多个一对多或一对一的关系。你就可以在这两个类之间引入订单类,客户和订单之间是一对多,订单和产品之间又是一对多,这样一个多对多的关系就拆分成两个一对多的关系,而新的订单类也就顺理成章的产生了。在订单类产生时,你可能还会加入一个关联类:业务员类。而业务员类又是从员工类继承下来的。所以呢,企业的四种CBO通过不同的组合,不同的关系,能够形成企业运作的许许多多的CBO

    CBO
    是做业务建模的基础,在此基础上,通过评估业务状态,说明当前业务,确定业务流程,改进业务流程的定义,设计业务流程实现,改进角色和职责,研究流程自动化,开发领域模型等一系列在RUP中定义的工作流程实现业务建模的目标。

    需求获取

    需求获取(requirement elicitation)是需求工程的主体。对于所建议的软件产品,获取需求是一个确定和理解不同用户类的需要和限制的过程。获取用户需求位于软件需求三个层次的中间一层。业务需求决定用户需求,它描述了用户利用系统需要完成的任务。从这些任务中,分析者能获得用于描述系统活动的特定的软件功能需求,这些系统活动有助于用户执行他们的任务。

    需求获取是在问题及其最终解决方案之间架设桥梁的第一步。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求,分析者、开发者和客户就能探索出描述这些需求的多种解决方案。参与需求获取者只有在他们理解了问题之后才能开始设计系统,否则,对需求定义的任何改进,设计上都必须大量的返工。把需求获取集中在用户任务上而不是集中在用户接口上有助于防止开发组由于草率处理设计问题而造成的失误。

    需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序,这些活动是相互隔开、增量和反复的。当你和客户合作时,你就将会问一些问题,并且取得他们所提供的信息(需求获取)。同时,你将处理这些信息以理解它们,并把它们分成不同的类别,还要把客户需求同可能的软件需求相联系(分析)。然后,你可以使客户信息结构化,并编写成文档和示意图(说明)。下一步,就可以让客户代表评审文档并纠正存在的错误(验证)。这四个过程贯穿着需求分析的整个阶段。

    需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户开发者的合作才能成功。分析者必须建立一个对问题进行彻底探讨的环境,而这些问题与产品有关。为了方便清晰地进行交流,就要列出重要的小组,而不是假想所有的参与者都持有相同的看法。对需求问题的全面考察需要一种技术,利用这种技术不但考虑了问题的功能需求方面,还可讨论项目的非功能需求。确定用户已经理解:对于某些功能的讨论并不意味着即将在产品中实现它。对于想到的需求必须集中处理并设定优先级,以避免一个不能带来任何益处的无限大的项目。

    需求获取是一个需要高度合作的活动,而并不是客户所说的需求的简单誊本。作为一个分析者,你必须透过客户所提出的表面需求理解他们的真正需求。询问一个可扩充(open-ended)的问题有助于你更好地理解用户目前的业务过程并且知道新系统如何帮助或改进他们的工作。调查用户任务可能遇到的变更,或者用户需要使用系统其它可能的方式。想像你自己在学习用户的工作,你需要完成什么任务?你有什么问题?从这一角度来指导需求的开发和利用。

    还有,探讨例外的情况:什么会妨碍用户顺利完成任务?对系统错误情况的反映,用户是如何想的?询问问题时,以还有什么能” ,”?时,将会发生什么”“你有没有曾经想过” ,“有没有人曾经为开头。记下每一个需求的来源,这样向下跟踪直到发现特定的客户。

    有些时候,尝试着问一些愚蠢的问题也有助于客户打开话匣子。如果你直接要求客户写出业务是如何实现的,客户十有八九无法完成。但是如果你尝试着问一些实际的问题,例如:以我的理解,你们收到订单后,会...”。客户立刻就会指出你的错误,并滔滔不绝的开始谈论业务,而你,就在一边仔细的聆听吧。这一招就叫做抛砖引玉

    需求讨论会上必须要使用笔记本电脑,还要指定一个打字熟练的人把所有的讨论记录下来,记录的同时还要做一定的整理。如果不这样做,那么你结束会议的时候就会发现,所有的讨论只剩下一个模糊的印象,需求对你来说仍然是一件遥远的事情。在座谈讨论之后,记下所讨论的条目(item),并请参与讨论的用户评论并更正。及早并经常进行座谈讨论是需求获取成功的一个关键途径,因为只有提供需求的人才能确定是否真正获取需求。进行深入收集和分析以消除任何冲突或不一致性。

    尽量把客户所持的假设解释清楚,特别是那些发生冲突的部分。从字里行间去理解以明确客户没有表达清楚但又想加入的特性或特征。Gause Weinberg1989)提出使用上下文无关问题”—这是一个高层次的问题,它可以获取业务问题和可能的解决方案的全部信息。客户对这些问题的回答诸如产品要求怎样的精确度你能帮我解释一下你为什么不同意某人的回答吗?这些回答可以更直接地认识问题,而这是封闭(close-end)问题所不能做到的。

    需求获取利用了所有可用的信息来源,这些信息描述了问题域或在软件解决方案中合理的特性。一个研究表明:比起不成功的项目,一个成功的项目在开发者和客户之间采用了更多的交流方式(Kiel and Carmel 1995)。与单个客户或潜在的用户组一起座谈,对于业务软件包或信息管理系统(MIS)的应用来说是一种传统的需求来源。直接聘请用户进行获取需求的过程是为项目获得支持和买入(buy-in)的一种方式。

    尽量理解用户用于表述他们需求的思维过程。充分研究用户执行任务时作出决策的过程,并提取出潜在的逻辑关系。流程图和决策树是描述这些逻辑决策途径的好方法。

    在需求获取的过程中,你可能会发现对项目范围的定义存在误差,不是太大就是太小。如果范围太大,你将要收集比真正需要更多的需求,以传递足够的业务和客户的值,此时获取过程将会拖延。如果项目范围太小,那么客户将会提出很重要的但又在当前产品范围之外的需求。当前的范围太小,以致不能提供一个令人满意的产品。需求的获取将导致修改项目的范围和任务,但作出这样具有深远影响的改变,一定要小心谨慎。

    正如经常所说的,需求主要是关于系统做什么,而解决方案如何实现是属于设计的范围。这样说虽然很简洁,但似乎过于简单化。需求的获取应该把重点放在做什么上,但在分析和设计之间还是存在一定的距离。你可以使用假设怎么做来分类并改善你对用户需求的理解。在需求的获取过程中,分析模型、屏幕图形和原型可以使概念表达得更加清楚,然后提供一个寻找错误和遗漏的办法。把你在需求开发阶段所形成的模型和屏幕效果看成是方便高效交流的概念性建议,而不应该看成是对设计者选择的一种限制。

    需求获取讨论会中如果参与者过多,就会减慢进度。人数大致控制在57人是最好的。这些人包括客户、系统设计者、开发者和可视化设计者等主要工程角色。相反地,从极少的代表那里收集信息或者只听到呼声最高、最有舆论影响的用户的声音,也会造成问题。这将导致忽视特定用户类的重要的需求,或者其需求不能代表绝大多数用户的需要。最好的权衡在于选择一些授权为他们的用户类发言的产品代表者,他们也被同组用户类的其它代表所支持。

    没有一个简单、清楚的信号暗示你什么时候已完成需求获取。当客户和开发者与他们的同事聊天、阅读工业和商业上的文献及在早上沐浴时思考时,他们都将对潜在产品产生新的构思。你不可能全面收集需求,但是下列的提示将会暗示你在需求获取的过程中的返回点。

    1. 
    如果用户不能想出更多的使用实例,也许你就完成了收集需求的工作。用户总是按其重要性的顺序来确定使用实例的。

    2. 
    如果用户提出新的使用实例,但你可以从其它使用实例的相关功能需求中获得这些新的使用实例,这时也许你就完成了收集需求的工作。这些新的使用实例可能是你已获取的其它使用实例的可选过程。

    3. 
    如果用户开始重复原先讨论过的问题,此时,也许你就完成了收集需求的工作。

    4. 
    如果所提出的新需求比你已确定的需求的优先级都低时,也许你就完成了收集需求的工作。

    5. 
    如果用户提出对将来产品的要求,而不是现在我们讨论的特定产品,也许你就完成了收集需求的工作。

    以上知识大致上讨论需求分析应该如何做,实际上对于需求分析的方法有很多很多,已经形成了一定的理论,当然这种理论比较偏向与方法学,而方法学的应用主要还是要靠个人。所以,大家在实际应用的时候,不妨结合自己的实际,有选择性的采用一些方法,那你就是成功的。
    展开全文
  • 怎样做需求分析

    千次阅读 2005-07-03 10:36:00
    (转载自CSAI.CN)需求分析 在具体的研究需求分析之前,我们先...关键过程区域构成了软件项目的管理控制的基础,并且确立了上下文各区域的关系,其中规定了技术方法的采用、工程产品的,模型、文档、数据报告、表
    (转载自CSAI.CN)

    需求分析
      在具体的研究需求分析之前,我们先了解一下软件工程这个概念。软件工程分为三个层次,过程层、方法层、工具层。在最基础的过程层,最重要的就是一组被称为关键过程区域(KPAs)的框架(KPA的概念在讨论CMM的书中有详细的概念说明)。关键过程区域构成了软件项目的管理控制的基础,并且确立了上下文各区域的关系,其中规定了技术方法的采用、工程产品的,模型、文档、数据、报告、表格等的产生、里程碑的建立、质量的保证及变化的适当管理。方法层主要是过程在技术上的实现。它解决的问题是如何做。软件工程方法涵盖了一系列的任务:需求分析、设计、编程、测试、维护。同时他还包括了一组基本原则,控制了每一个的关键过程区域。工具层就很好理解了,他对过程层和方法层提供了自动和半自动的支持。这些辅助工具就称为CASE。
      可以看到需求分析的位置,但是事实上需求分析是跨越了软件工程的三个层次的。这一点是和其他的过程是一样的。当然我们这里比较重点强调的是在软件工程的方法层,同时也涉及到一些过程层的思想,至于工具层则不再我们的讨论之列,但是会提到一些很适合在需求分析时应用的工具,诸如Word、Excel、Visio等。
    方法
      需求分析都包括了哪些方法呢?这里列举出在《需求分析》一书中推荐的一些方法,
      1) 绘制系统关联图,这种关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。
      2) 创建用户接口原型,当开发人员或用户不能确定需求时,开发一个用户接口原型—一个可能的局部实现—这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。
      3) 分析需求可行性,在允许的成本、性能要求下,分析每项需求实施的可行性,明确与每项需求实现相联系的风险,包括与其它需求的冲突,对外界因素的依赖和技术障碍。   

            4) 确定需求的优先级别,应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时,在特定的版本中加入每一项变更,并在那个版本计划中作出需要的变更。
      5) 为需求建立模型,需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
      6) 创建数据字典,数据字典是对系统用到的所有数据项和结构的定义,以确保开发人员使用统一的数据定义。在需求阶段,数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。
      7) 使用质量功能调配,(QFD)是一种高级系统技术,它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。QFD将需求分为三类:期望需求,即客户或许并未提及,但如若缺少会让他们感到不满意;普通需求;兴奋需求,即实现了会给客户带去惊喜,但若未实现也不会受到责备(Zultner 1993;Pardee 1996)。
      记住一点,不要试图在你的项目中把这些方法都用上去,四个现代化并不是一夜就可以实现的。同样,尝试着使用你认为对你很有帮助的方法,确实收到效果之后,再考虑继续学习方法。因为上面提到的都是需求分析的大方法,事实上还有很多很多的方法可以采用,例如,采用SRS模板、指明需求的来源、为每项需求注上标号、记录业务规范、创建需求跟踪能力矩阵、审查需求文档、以需求为依据编写测试用例、编写用户手册、确定合格的标准。
    业务建模
      很多人都没有意识到业务需求阶段应该做些什么事情,实际上业务建模是最重要的一件事情。不要觉得业务建模这个词很深奥,让人模不着头脑。其实所有做过需求分析的人都做过业务建模,比如你了解企业的运作模式就?是一种你脑海中的业务建模。但是大多数人都没有科学的、系统的、文档化的做过业务建模。
      业务建模的目的在于:
      了解目标组织(将要在其中部署系统的组织)的结构及机制。
      了解目标组织中当前存在的问题并确定改进的可能性。
      确保客户、最终用户和开发人员就目标组织达成共识。
      导出支持目标组织所需的业务需求。
      上面的话是不是很抽象呢,其实没有什么复杂的:人和电脑是完全不同的思想(思维方式)。所以,原先适合人的业务流程对于计算机来说可不一定合适的,为了最大限度的利用计算机,必须要了解原先的业务流程并对此加以改造(流程自动化),当然这些动作需要得到用户的许可。有些人认为说只有ERP这种大系统才需要对业务流程进行重组,但是实际上,不论是部门级的MIS系统,还是社会级的电子商务系统,都需要对业务流程进行改造,所不同的只是改造的程度。
      业务建模很重要的一点是在分析企业流程的同时分析出基础企业对象(Common Business Object)(这个词我翻译的不好,如果大家有更好的翻译,请告诉我)。任何企业都有最基础的一些元素,例如银行的CBO就有帐户,制造业的CBO就有订单等。有一次我的一个在企业应用方面研究多年的朋友告诉我一个秘诀,他说,企业的CBO无非是4个:客户、员工、产品和供应商(银行的供应商应该称为同业)。其他的所有CBO都是在这四个CBO的基础上发展起来的。比如说CBO中客户和产品是多对多的关系,根据关系数据的理论,任何多对多的关系都可以拆分成多个一对多或一对一的关系。你就可以在这两个类之间引入订单类,客户和订单之间是一对多,订单和产品之间又是一对多,这样一个多对多的关系就拆分成两个一对多的关系,而新的订单类也就顺理成章的产生了。在订单类产生时,你可能还会加入一个关联类:业务员类。而业务员类又是从员工类继承下来的。所以呢,企业的四种CBO通过不同的组合,不同的关系,能够形成企业运作的许许多多的CBO。
      CBO是做业务建模的基础,在此基础上,通过评估业务状态,说明当前业务,确定业务流程,改进业务流程的定义,设计业务流程实现,改进角色和职责,研究流程自动化,开发领域模型等一系列在RUP中定义的工作流程实现业务建模的目标。
    需求获取
      需求获取(requirement elicitation)是需求工程的主体。对于所建议的软件产品,获取需求是一个确定和理解不同用户类的需要和限制的过程。获取用户需求位于软件需求三个层次的中间一层。业务需求决定用户需求,它描述了用户利用系统需要完成的任务。从这些任务中,分析者能获得用于描述系统活动的特定的软件功能需求,这些系统活动有助于用户执行他们的任务。 需求获取是在问题及其最终解决方案之间架设桥梁的第一步。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求,分析者、开发者和客户就能探索出描述这些需求的多种解决方案。参与需求获取者只有在他们理解了问题之后才能开始设计系统,否则,对需求定义的任何改进,设计上都必须大量的返工。把需求获取集中在用户任务上—而不是集中在用户接口上—有助于防止开发组由于草率处理设计问题而造成的失误。 需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序,这些活动是相互隔开、增量和反复的。当你和客户合作时,你就将会问一些问题,并且取得他们所提供的信息(需求获取)。同时,你将处理这些信息以理解它们,并把它们分成不同的类别,还要把客户需求同可能的软件需求相联系(分析)。然后,你可以使客户信息结构化,并编写成文档和示意图(说明)。下一步,就可以让客户代表评审文档并纠正存在的错误(验证)。这四个过程贯穿着需求分析的整个阶段。 需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户—开发者的合作才能成功。分析者必须建立一个对问题进行彻底探讨的环境,而这些问题与产品有关。为了方便清晰地进行交流,就要列出重要的小组,而不是假想所有的参与者都持有相同的看法。对需求问题的全面考察需要一种技术,利用这种技术不但考虑了问题的功能需求方面,还可讨论项目的非功能需求。确定用户已经理解:对于某些功能的讨论并不意味着即将在产品中实现它。对于想到的需求必须集中处理并设定优先级?,以避免一个不能带来任何益处的无限大的项目。 需求获取是一个需要高度合作的活动,而并不是客户所说的需求的简单誊本。作为一个分析者,你必须透过客户所提出的表面需求理解他们的真正需求。询问一个可扩充(open-ended)的问题有助于你更好地理解用户目前的业务过程并且知道新系统如何帮助或改进他们的工作。调查用户任务可能遇到的变更,或者用户需要使用系统其它可能的方式。想像你自己在学习用户的工作,你需要完成什么任务?你有什么问题?从这一角度来指导需求的开发和利用。
      还有,探讨例外的情况:什么会妨碍用户顺利完成任务?对系统错误情况的反映,用户是如何想的?询问问题时,以“还有什么能” ,”当?时,将会发生什么”“你有没有曾经想过” ,“有没有人曾经”为开头。记下每一个需求的来源,这样向下跟踪直到发现特定的客户。
      有些时候,尝试着问一些“愚蠢”的问题也有助于客户打开话匣子。如果你直接要求客户写出业务是如何实现的,客户十有八九无法完成。但是如果你尝试着问一些实际的问题,例如:“以我的理解,你们收到订单后,会...”。客户立刻就会指出你的错误,并滔滔不绝的开始谈论业务,而你,就在一边仔细的聆听吧。这一招就叫做“抛砖引玉”。
      需求讨论会上必须要使用笔记本电脑,还要指定一个打字熟练的人把所有的讨论记录下来,记录的同时还要做一定的整理。如果不这样做,那么你结束会议的时候就会发现,所有的讨论只剩下一个模糊的印象,需求对你来说仍然是一件遥远的事情。在座谈讨论之后,记下所讨论的条目(item),并请参与讨论的用户评论并更正。及早并经常进行座谈讨论是需求获取成功的一个关键途径,因为只有提供需求的人才能确定是否真正获取需求。进行深入收集和分析以消除任何冲突或不一致性。
      尽量把客户所持的假设解释清楚,特别是那些发生冲突的部分。从字里行间去理解以明确客户没有表达清楚但又想加入的特性或特征。Gause 和Weinberg(1989)提出使用“上下文无关问题”—这是一个高层次的问题,它可以获取业务问题和可能的解决方案的全部信息。客户对这些问题的回答诸如“产品要求怎样的精确度”或“你能帮我解释一下你为什么不同意某人的回答吗?”这些回答可以更直接地认识问题,而这是封闭(close-end)问题所不能做到的。
      需求获取利用了所有可用的信息来源,这些信息描述了问题域或在软件解决方案中合理的特性。一个研究表明:比起不成功的项目,一个成功的项目在开发者和客户之间采用了更多的交流方式(Kiel and Carmel 1995)。与单个客户或潜在的用户组一起座谈,对于业务软件包或信息管理系统(MIS)的应用来说是一种传统的需求来源。直接聘请用户进行获取需求的过程是为项目获得支持和买入(buy-in)的一种方式。
      尽量理解用户用于表述他们需求的思维过程。充分研究用户执行任务时作出决策的过程,并提取出潜在的逻辑关系。流程图和决策树是描述这些逻辑决策途径的好方法。
      在需求获取的过程中,你可能会发现对项目范围的定义存在误差,不是太大就是太小。如果范围太大,你将要收集比真正需要更多的需求,以传递足够的业务和客户的值,此时获取过程将会拖延。如果项目范围太小,那么客户将会提出很重要的但又在当前产品范围之外的需求。当前的范围太小,以致不能提供一个令人满意的产品。需求的获取将导致修改项目的范围和任务,但作出这样具有深远影响的改变,一定要小心谨慎。 正如经常所说的,需求主要是关于系统做什么,而解决方案如何实现是属于设计的范围。这样说虽然很简洁,但似乎过于简单化。需求的获取应该把重点放在“做什么”上,但在分析和设计之间还是存在一定的距离。你可以使用假设“怎么做”来分类并改善你对用户需求的理解。在需求的获取过程中,分析模型、屏幕图形和原型可以使概念表达得更加清楚,然后提供一个寻找错误和遗漏的办法。把你在需求开发阶段所形成的模型和屏幕效果看成是方便高效交流的概念性建议,而不应该看成是对设计者选择的一种限制。 需求获取讨论会中如果参与者过多,就会减慢进度。人数大致控制在5到7人是最好的。这些人包括客户、系统设计者、开发者和可视化设计者等主要工程角色。相反地,从极少的代表那里收集信息或者只听到呼声最高、最有舆论影响的用户的声音,也会造成问题。这将导致忽视特定用户类的重要的需求,或者其需求不能代表绝大多数用户的需要。最?好的权衡在于选择一些授权为他们的用户类发言的产品代表者,他们也被同组用户类的其它代表所支持。 没有一个简单、清楚的信号暗示你什么时候已完成需求获取。当客户和开发者与他们的同事聊天、阅读工业和商业上的文献及在早上沐浴时思考时,他们都将对潜在产品产生新的构思。你不可能全面收集需求,但是下列的提示将会暗示你在需求获取的过程中的返回点。
      1. 如果用户不能想出更多的使用实例,也许你就完成了收集需求的工作。用户总是按其重要性的顺序来确定使用实例的。
      2. 如果用户提出新的使用实例,但你可以从其它使用实例的相关功能需求中获得这些新的使用实例,这时也许你就完成了收集需求的工作。这些新的使用实例可能是你已获取的其它使用实例的可选过程。   3. 如果用户开始重复原先讨论过的问题,此时,也许你就完成了收集需求的工作。
      4. 如果所提出的新需求比你已确定的需求的优先级都低时,也许你就完成了收集需求的工作。
      5. 如果用户提出对将来产品的要求,而不是现在我们讨论的特定产品,也许你就完成了收集需求的工作。
      以上知识大致上讨论需求分析应该如何做,实际上对于需求分析的方法有很多很多,已经形成了一定的理论,当然这种理论比较偏向与方法学,而方法学的应用主要还是要靠个人。所以,大家在实际应用的时候,不妨结合自己的实际,有选择性的采用一些方法,那你就是成功的。

    用例在需求分析中的使用
      多年来,分析者总是利用情节或经历来描述用户和软件系统的交互方式,从而获取需求(McGraw and Harbison 1997)。Ivar Jacobson(1992)把这种看法系统地阐述成用例(用例)的方法进行需求获取和建模。虽然用例来源于面向对象的开发环境,但是它也能应用在具有许多开发方法的项目中,因为用户并不关心你是怎样开发你的软件。而最重要的,用例的观点和思维过程带给需求开发的改变比起是否画正式的用例图显得更为重要。注意用户要利用系统做什么远远强于询问用户希望系统为他们做什么这一传统方法。 用例的重要功能是用画用例图的功能来鉴别和划分系统功能。它把系统分成角色(actor)和用例(用例)。角色(actor)表示系统用户能扮演的角色(role)。这些用户可能是人,可能是其他的计算机一些硬件或者甚至是其它软件系统,唯一的标准是它们必须要在被划分进用例的系统部分以外。它们必须能刺激系统部分并接收返回。用例描述了当角色给系统特定的刺激时系统的活动。这些活动被文本描述。它描述了触发用例的刺激的本质,输入和输出到其他活动者,和转换输入到输出的活动。用例文本通常也描述每一个活动在特殊的活动线时可能的错误和系统应采取的补救措施。 这样说可能会非常复杂,其实一个用例描述了系统和一个角色(actor)的交互顺序。用例被定义成系统执行的一系列动作,动作执行的结果能被指定角色察觉到。用例可以:
      用例捕获某些用户可见的需求,实现一个具体的用户目标。
      用例由角色激活,并提供确切的值给角色。
      用例可大可小,但它必须是对一个具体的用户目标实现的完整描述。在UML中,用例表示为一个椭圆。
      角色是指用户在系统中所扮演的角色。其图形化的表示是一个小人。在某些组织中很可能有许多角色实例(例如有很多个销售员),但就该系统而言,他们均起着同一种作用,扮演着相同的角色,所以用一个角色表示。一个用户也可以扮演多种角色。例如,一个高级营销人员既可以是贸易经理,也可以是普通的营销人员;一个营销人员也可以是售货员。在处理角色时,应考虑其作用,而不是人或工作名称,这一点是很重要的。
      我们使用不带箭头的线段将角色与用例连接到一起,表示两者之间交换信息,称之为通信联系。角色触发用例,并与用例进行信息交换。单个角色可与多个用例联系;反过来,一个用例可与多个角色联系。对同一个用例而言,不同角色有着不同的作用:他们可以从用例中取值,也可以参与到用例中。需要注意的是角色在用例图中是用类似人的图形来表示,尽管执行的,但角色未必是人。例如,角色也可以是一个外界系统,该外界系统可能需要从当前系统中获取信息,与当前系统有进行交互。
      一个用例可能包括完成某项任务的许多逻辑相关任务和交互顺序。因此,一个用例是相关的用法说明的集合,并且一个说明(scenario)是用例的实例。这种关系就像是类和对象的关系。在用例中,一个说明被视为事件的普通过程(normal course),也叫作主过程,基本过程,普通流,或“满意之路” (happy path)。在描述普通过程时列出执行者和系统之间相互交互或对话的顺序。当这种交互结束时,执行者也达到了预期的目的。
      在用例中的其它说明可以描述为可选过程(alternative coruse)。可选过程也可促进成功地完成任务,但它们代表了任务的细节或用于完成任务的途径的变化部分。在交互序列中,普通过程可以在一些决策点上分解成可选过程,然后再重新汇成一个普通过程。
    角色类和角色实例
      软件产品最终是给一些用户来使用的,而用户之间的差异是非常大的。造成差异的原因包括了对计算机的认知程度的不同,使用习惯的不同,在软件目标组织中所处的地位不同,地理位置不同,业务熟练程度不同。
      不同的用户都有自己一系列的功能需求和非功能需求。对电脑熟练程度不同的人可能就会有不同的要求,熟练程度低的用户可能希望有一个友好的界面,熟练程度高的用户可能更希望有快捷键或宏的操作以提高工作效率。考虑到用户的差异性,将用户分类并研究用户类的行为特征是非常有必要的。所以在做具体的需求之前,先将用户分局行为和特点进行分类,对于研究、收集用户的需求是非常有帮助的。
      可以利用一个简单的表格列出一些原始的分类,然后不断的完善这个表格。确认你的分类之间没有交集。并充分描述用户分类的行为,目的,要求等。在企业分析中,比较常见的分类可能包括,供应商,客户,部门等。
      就像C++中的类和对象一样,我们把分析出的用户分类称为“角色类”,把实际的用户称为“角色实例”。在得到用户分类之后,最重要的就是要选出用户代表,用户代表不仅仅是在需求阶段中参与项目,还必须对项目的全过程负责。用户代表能够代表用户分类的需求。抓住用户代表的需求就大致把握住了用户类的需求。当然,需求分析还是需要在用户中做大规模的调查的,只是要把重点放在用户代表上。
      确保和用户直接进行沟通!大家有没有玩过传话的游戏,可能看过。一群人排成一列,一句话从排头挨个向后传,到最后,那句话已经是面目全非了。所以,一定要保证项目组能够直接和用户接触。 对于和用户直接沟通这一点,一般的针对特定企业的应用系统当然是不成问题,可是如果是开发行业软件,和用户直接沟通就成为一件几乎是不可能的事情。在这种情况下,一般有几种解决的办法:
      做大规模的市场调查,针对你的目标市场做市场调查,并根据统计学的理论建立你的数学模型。这部分的工作效果最好,其性质有些象一些游戏公司会发布一些Demo版的游戏。可是对于一般的企业来说,这项工作费时费力,高昂的成本往往使大家知难而退。我的意见是,方法是非常好的,但是可以采用折衷的办法,例如选取有代表性的企业,为特定企业制作一个较小的版本并收集反馈意见等。这涉及到很多市场营销的内容,并不是我的专业所长,这里就不多弄斧了。 聘请行业专家,一个行业专家往往可以在项目需求方面发挥极为重要的作用。一个行业专家往往都有大量的行业经验和行业的人际关系网络。在产品的设计方面,这个行业专家提供很多宝贵的意见。在目前很多的软件的开发过程中都采用了这种方式。行业专家有两种:一种是在这个行业中有很深的资历,但是对软件技术并不熟悉;第二种是开发过同类软件的软件专家,这种人在开发同类软件过程中已经积累了大量的项目经验,并且具有软件开发的知识。这种方式是获取需求的最好的方式。 分析对比同类软件,微软在开发Office、Visual Studio的时候,也是参照了Lotus和Borland的成熟产品。这种方式的特点在于成本很低,比较适合和其他的方式配合使用。但是,要注意自己有没有触犯专利法。
    需求的冲突
      有的时候,虽然已经将用户分类并选出了用户代表。但是需求的来源众多,往往会发生需求之间自相矛盾的事情。需求从四面八方收集来后,人们难以解决冲突,澄清模糊之处以及协调不一致之处。某些人还要对不可避免要发生的范围问题单独作出决定。在项目的早期阶段,你必须决定谁是需求问题的决策者。如果不清楚谁有权并且有责任来作出决策,或者授权的个人不愿意或不能作出决策,那么决策者的角色将自然而然地落在开发者身上。这是一个非常糟糕的选择,因为开发者通常没有足够多的信息和观点来作出业务上的决策。
      在软件项目中,谁将对需求作出决策的问题并没有统一的正确答案。分析员有时听从呼声高的或来自最高层人物的最大的需求。即便使用用户代表这一手段,必须解决来自不同用户类的相冲突的需求。通常,应尽可能由处于公司底层的人作出决策,因为他们与问题密切相关,并能得到关于这些问题的广泛信息。
      如果不同的用户类有不一致的需求,那么必须决策出满足哪一类用户的需求更为重要。了解可能使用产品的客户种类的信息和他们的用法与产品的业务目标的关系如何,将有助于你决定哪一个用户类所占份额最大。
      当开发者想象中的产品与客户需求冲突时,通常应该由客户作出决策。然而,不要陷到“客户总是对的”的陷阱中去,对他们百依百顺。现实中,客户并不总是对的。客户总是持有自己的观点,开发者必须理解并尊重这一观点。
    用例
      在具体的需求过程中,有大的用例(业务用例),也有小的用例。主要是由于用例的范围决定的。用例像是一个黑盒,它没有包括任何和实现有关或是内部的一些信息。它很容易就被用户(也包括开发者)所理解(简单的谓词短语)。如果用例不足以表达足够的信息来支持系统的开发,就有必要把用例黑盒打开,审视其内部的结构,找出黑盒内部的Actor和用例。就这样通过不断的打开黑盒,分析黑盒,再打开新的黑盒。直到整个系统可以被清晰的了解为止。


      为什么要采用这种分析方法呢?计算机系统除了在与外界系统、人员有一系列的交互,在系统内部也往往存在着复杂的交互。因此,在系统建模时,除了描述系统与外界的交互,同时还要描述系统内部的交互。传统的MIS系统中,系统与外界的交互较多。典型的,如ATM取款机:存在着大量的用户与ATM,ATM与其它系统的交互。而电信领域的系统,与外界的交互较少。例如,系统的输入可能仅仅是从交换机上采集信息,然后由系统进行处理。系统的复杂逻辑包含在系统内部处理的流程上,而非与外部系统的交互。建模主要任务是表达系统内部的交互。
      用例图适于表达交互,之所以上面使用了电信系统,是因为用例最早来自于Ericsson的交换机系统。当时,还是Ericsson雇员的Jacobson初步建立了用例图的概念,并于1994年提出了OOSE方法,其最大特点是面向用例(Use-Case),并在用例的描述中引入了外部角色的概念。用例的概念是精确描述需求的重要武器,比较适合支持商业工程和需求分析。随着用例的发展,用例被大量的 用于对功能进行描述。每个用例代表了系统与外部ACTOR的交互。可以采取顺序图来表达用例的具体操作程序。ACTOR用于确定系统的边界。
      ACTOR、用例可以从不同的层次来描述信息。采用该原则的原因有:
      1. 需求并不是在项目一开始就很明确,往往是随着项目的推进,逐渐细化。
      2. 人的认知往往具有层次的特性。从粗到细、从一般到特殊。采用不同的层次来描述,适于认知的过程。 使用用例开发系统的一般过程
      在开发过程的初始阶段,可以根据具体的项目特点,制订开发各个视图之间的关联原则,指导规范。在开发的过程中,视图的组织原则应不断进行维护、更新。
      识别ACTOR来识别系统与外界交互的实体。ACTOR具有特定领域的特征,例如:交换机(采集系统)、97信息系统等。在系统层次的ACTOR确定了系统的边界。
      识别用例。同ACTOR一样,用例具有不同层次。对较为概括的USECASE,需要细化。注:系统开发需要一定的规则来确定,如何来分解用例;可能基于原有系统的经验,或是参考现有资料。
      当用例细化到可以被理解的层次。需要基于用例进行下一步的开发。如前面提到的,用例主要用来描述交互。因此,存在交互的实体和交互的细节。交互的实体采用类图来描述;而交互的细节,采用顺序图来描述。
      当系统复杂到一定层次时,类图和顺序图可能不能足以描述其复杂程度。在该情况下,需要使用状态图来辅助阐述。状态图和顺序图之间使用事件联结在一起。它们之间的一致性问题,目前UML和ROSE没有提供解决方案。相对折衷的方法是使用事件的命名规范强制一致性。
      可以说,之前说的所有的东西都是为了能够导出用例在需求中的作用。用例是从用户的角度看待系统,而不是基于程序员的角度。这样的话,用例驱动的系统能够真正做到以用户为中心,用户的任何需求都能够在系统开发链中完整的体现。用户和程序员间通过用例沟通,避免了牛头马嘴的尴尬局面。 从前,系统开发者总是通过情节来获取需求,是问用户希望系统为他做什么。在Jacobson发明了用例的概念之后,需求获取就变成问用户要利用系统做什么。这是立场不同导致的结果。用户通常并不关心系统是如何实现的(也有少数可爱的技术狂是例外)。对他们来说,更重要的是要达到他的目的。相反的,大部分的程序员的工作习惯就是考虑计算机应该如何实现用户的要求。所幸的是,用例方法能够调和双方的矛盾,因为虽然用例是来源于用户,服务于用户,但是它同样可以用于开发的流程。当系统的开发过程都是基于用例的,用用例获取需求,用用例设计,用用例编码,用用例测试的时候。这个开发过程就是用例驱动的。 用例和用例文档
      《软件需求》一书中提到了几种方法来确定用例:
      首先明确执行者和他们的角色,然后确定业务过程,在这一过程中每一个参与者都在为确定用例而努力。
      确定系统所能反映的外部事件,然后把这些事件与参与的执行者和特定的用例联系起来。
      以特定的说明形式表达业务过程或日常行为,从这些说明中获得用例,并确定参与到用例中的执行者,有可能从现在的功能需求说明中获得用例。如果有些需求与用例不一致,就应考虑是否真的需要它们。
      用例代表了用户的需求,在你的系统中,应该直接从不同用户类的代表或至少应从代理那里收集需求。用例为表达用户需求提供了一种方法,而这一方法必须与系统的业务需求相一致。分析者和用户必须检查每一个用例,在把它们纳入需求之前决定其是否在项目所定义的范围内。基于“用例”方法进行需求获取的目的在于:描述用户需要使用系统完成的所有任务。在理论上,用例的结果集将包括所有合理的系统功能。在现实中,你不可能获得完全包容,但是比起我所知道的其它获取方法,基于用例的方法可以为你带来更好的效果。 当使用用例进行需求获取时,应避免受不成熟的细节的影响。在对切合的客户任务取得共识之前,用户能很容易地在一个报表或对话框中列出每一项的精确设计。如果这些细节都作为需求记录下来,他们会给随后的设计过程带来不必要的限制。你可能要周期性地检查需求获取,以确保用户参与者将注意力集中在与今天所讨论的话题适合的抽象层上。向他们保证在开发过程中,将会详尽阐述他们的需求。在一个逐次详细描述过程中,重复地详述需求,以确定用户目标和任务,并作为用例。然后,把任务描述成功能需求,这些功能需求可以使用户完成其任务,也可以把它们描述成非功能需求,这些非功能需求描述了系统的限制和用户对质量的期望。虽然最初的屏幕构思有助于描述你对需求的理解,但是你必须细化用户界面设计。 建立用例文档。在每一次的需求获取之后,都会生成很多未整理的需求,你必须将它们组织成用例文档。使用诸如模板的技术能够提高你的速度和需求的复用性。一个用例文档可以使用表格来组织,主要的要素包括了用例标识号、用例名称、父用例标志号、创建者、创建时间、审核者、修订记录、角色、说明、先决条件、请求结果、优先级、普通过程、可选过程、例外、非功能需求、假设、注释和问题。 虽然列举出了这么多的属性,但是实际中使用的属性这要看你的团体而定,看项目的大小而定。把大量的时间花在用例的描述上是没有意义的。用户需要的是一个软件系统,并不是一大堆的用例说明。



    展开全文
  • BI能应付绝大多数场景的数据分析,尤其擅长多维数据切片,不需要建模;甚至数据清洗环节也能放在前端,通过过滤筛选、新建计算公式等来解决。最后呈现可视化,并可设计数据报告。这里我用FineBI来这样一份分析。...

    BI能应付绝大多数场景的数据分析,尤其擅长多维数据切片,不需要建模;甚至数据清洗环节也能放在前端,通过过滤筛选、新建计算公式等来解决。最后呈现可视化,并可设计数据报告。

    这里我用FineBI来做这样一份分析。

    FineBI做分析大体是这样的流程:连接/导入数据——数据处理/清洗(过滤、筛选、新增公式列)——探索式分析——数据可视化——出报告。

    二、数据清洗加工

    1.薪水上下限分割:

    将CSV文件数据导入FineBI中(新建数据链接,建立一个分析业务包,然后导入这张excel表)。因为薪水是以xxK-xxk(还有一些类似校招/薪资面议的数据)的形式进行存储的,我这边使用FineBI新增公式列(类似excel函数)将这些字符进行分割:

    薪水下限(数值):left( indexofarray ( split (salary,"-") ,1),find( "K",INDEXOFARRAY( split(salary,"-") ,1))-1)

    薪水上限(含K字符):right ( indexofarray( split(salary,"-") ,2),len(salary)- find("K",indexofarray(split(salary,"-"),2 ) ) )

    薪水上限(数值):left( 薪水上限(文本),find("K",薪水上限(文本))-1 )

    这样就得到每个岗位的数值格式的薪水区间了:

    2.脏数据清洗:

    浏览了一下数据,没有大问题,但是发现里面有一些类似BIM工程师的岗位信息,这些应该都是土木行业的工程师,这边我直接过滤掉即可(不包含“BIM”且不包含“bim”)。

    3.岗位平均数据计算

    再新增列,平均薪水=(薪水下限+薪水上限)/2,即可得到每个岗位的平均薪水。

    4.真实城市截取

    由于城市字段存储有的数据为“城市-区域”格式,例如“上海-徐汇区”,为了方便分析每个城市的数据,最后新增列“城市”,截取“-”前面的真实城市数据。

    城市:if(find("-",city)>0 , left(city, find("-",city)-1 ),city)

    至此,18000多条数据差不多清洗完毕,食材已经全部准备好,下面可以正式开始数据可视化的美食下锅烹饪。

    三、数据可视化

    数据可视化可以说是很简单了,拖拽要分析的数据字段即可。

    但是这里用finebi分析要理解一个思路。常规我们用excel做分析或者说做图表,是先选用钻则图表然后设定系列、数值。这里没有系列和数值的概念,只有横轴和竖轴。拖入什么字段,该字段就以该轴进行扩展,至于图表嘛,finebi会自动判别推荐。

    我这边以各城市平均薪水/岗位数量分析为例给大家简单展示FineBI的可视化呈现过程。

    1、横轴以“城市”字段扩展,展现两类数据。先是薪水值,拖拽到纵轴,默认对数值类的字段是汇总求和的。点击字段可直接对改字段修改计算、过滤等操作。

    此图来自官网,图中数据不是本次分析的数据,仅供参考

    2、然后分析每个城市BI岗位的情况。将数据记录数这个指标拖入到纵轴展示。同样的方式,可以修改字段名。这里为了区分两者,将其修改为折线图,并且倒叙展示。

    同理,其他图表也是这样的操作,想清楚展现什么样的数据,怎样展现,数据要作何处理。就得心应手了。其他图表就不一一赘述了。

    最后,大概花了15分钟,一份完整的智联招聘网站-BI工程师岗位数据分析的可视化报告就制作完成啦~

    审美有限,只能做成这样,其实这个FineBI还能做出这样的效果。

    四、分析结果

    1.目前BI工程师岗位在智联招聘网站的平均薪资为13.46K(痛哭。。。拉低平均薪水的存在),主要薪水区间大概在12-15K(占比27.07%),相关工作需求总数为634个(仅仅为某一天的招聘需求数据)。

    2.从城市岗位需求数量分布来看,BI工程师需求主要集中在北京、上海、深圳、广州区域;各城市BI工程师平均薪水方面,去除岗位需求量较少的城市来看,国内排在前面的分别为深圳(14.72K)、上海(14.59K)、北京(14.51)、杭州(12.07K)、成都(11.13K)、广州(10.94K)。

    3.从工作年限的平均薪水和岗位需求数量来看,工作5-10年的资深BI工程师的平均薪水可以达到20K以上(朝资深BI工程师方向奋斗!!!1年以下年限的计算出来的平均薪水虽然为19K,但是由于样本量只有3个,所以参考意义不大),其中大部分的工作需求年限为3-5年,平均薪水为14.24K。

    4.从学历方面来看,最低学历需求主要以本科/大专为主,本科和大专学历要求的平均薪资分别为12.68K和11.97K(感觉差距并不大,过硬的技术实力可能才是企业最为看重的吧),博士和硕士学历需求很少。

    5.看了一些高薪的招聘企业,最高的可以给到30K~40K的薪酬水平,其中主要是互联网、IT类公司为主。

    醍醐灌顶,顿时有了奋斗的动力~知识就是财富,继续好好学习去吧,少年!!!

    展开全文
  • 作者林骥我在做数据分析的时候,经常提醒自己,要多想一想,为什么做这个数据分析?不要陷入使用工具的泥潭而不能自拔,不要为了做图表而做图表,不要为了写报告而写报告。数据分析的工具只是实现目标...
  • 作为⼀一名在数据⾏行行业打拼了了两年年多的数据分析师,虽然⽬目前收⼊入还算ok,但每每想起房价,男⼉儿三⼗十还未⽴立,内⼼心就不不免彷徨不不已~两年年时间⾥里里曾经换过⼀一份⼯工作,⼀一直都是从事⼤...
  • 为此,未明学院数据分析训练营的同学利用课上所学,分析了明星微博粉丝数据,同时借助数据分析探究了明星的微博营销模式,提出了运营建议。大数据对互联网行业商业决策的指导意义可见一斑! 《微博明星...
  • 一个数据分析师,最怕的一件事情莫过于在没有数据的情况下,让你去一个详细的数据分析报告。确实,巧妇难为无米之炊,数据是数据分析、数据挖掘乃至数据可视化最最基础的元素。利用Python进行数据分析最重要到一步...
  • 一. 数据分析的基本流程 01 明确需求与目的 02 数据收集:巧妇难为无米之炊 内部数据:内部数据库 ...一个类比,比如,我们现在要一道菜,那我们需要进行怎样的流程呢? 确定做菜、买菜、洗菜、切菜、炒菜、盛
  • 在有些传统行业,数据分析师工作重点是「行业报告」等;在阿里巴巴等大型互联网公司,职位区分比较明确,数据分析师大部分时间只产品和运营的分析工作,至于「基础数据处理」、「搭建数据产品」等等不涉及;在创业...
  • 在有些传统行业,数据分析师工作重点是「行业报告」等;在阿里巴巴等大型互联网公司,职位区分比较明确,数据分析师大部分时间只产品和运营的分析工作,至于「基础数据处理」、「搭建数据产品」等等不涉及;在创业...
  • 不知道大家是怎样做这类数据报告的。在我还是统计员(俗称表哥)的时候,用的多为Excel。、 每到时间节点就各种催数据、汇总、然后做报表。汇报的时候总要熬个两天夜做PPT,回头会议上分发。但汇报反馈总是平平,...
  • 那么身为一个在职场打拼、会抓热点、有技术控的编辑,怎样做一次不妖艳,不从众的八卦研究呢?今天小编就为大家秀一把新学的技能:用python完成一次与众不同的八卦。 本文以奥运数据为导向进行体育明星特点分析,...
  • 数据来源于BOSS直聘,说实话,现在的招聘网站,得比较好的还是BOSS直聘,其相关的数据报告等都是比较有代表性的。今天我们就来看看相关的数据吧! 数据获取 BOSS直聘上有这么一个接口,可以很好的获取当前不同...
  • 学生信息管理系统 (一)系统功能基本要求: (1)具有用户登录功能。 (2)具有学生信息的录入功能。...(4) 独立完成课程设计,并完成课程设计报告报告应记录设计的过程,尤其是分析/设计/实现过程中的决策。
  • 数据服务合同.doc

    2021-01-18 13:59:24
    分析内容: 提供结果: 提供本次分析的总的分析报告,包括:①包括原始数据描述的Excel表格、②上述____种分析的图表及图注中英文各一份。具体格式和样品与甲方协商而定。数据分析完成后由甲方进行确认服务内容...
  • 如果要问数据怎样做才能显得最装逼,那么答案一定只有一个: “数据可视化”! 看上去也很炫酷对不对,其实上面的可视化图表其实并不复杂,很多人推荐的Python、R语言、Tableau等专业数据分析工具几乎...
  • 数据运营思维导图

    2018-04-26 14:24:22
    —怎么好“运筹”,数据分析告诉你 以往鉴来,未卜先知 —怎么发现历史的规律以预测未来,数据分析告诉你 工作思维 对业务的透彻理解是数据分析的前提 数据分析是精细化运营,要建立起体系化思维(金字塔思维...
  • 大学化学实验报告.doc

    2021-01-19 11:57:02
    大学化学实验报告 大学化学实验报告的格式是怎样的?那么,下面就随小编一起来看看吧。大学化学实验报告格式 1):实验目的,专门写实验达到的要求和任务来实现。(例如,为了研究添加硫酸铜条件的溶液中的氢氧化钠溶液...
  • 2019数据运营思维导图

    2019-03-29 21:34:09
    数据运营 作用&意义 知错能改,善莫大焉 —错在哪里,数据分析告诉你 运筹帷幄,决胜千里 —怎么好“运筹”,数据分析告诉你 以往鉴来,未卜先知 —怎么发现历史的规律以预测未来,数据分析告诉你 工作思维 对业务...
  • 一个完善的销售月工作总结报告应当包括如下内容: 1、销售情况总结: 销售业绩和销售目标达成情况,要求既有详细数据,又有情况分析。 2、行动报告:当月都干了什么工作,都去了什么地方、工作时间怎样安排的,...
  • 如果要问数据怎样做才能显得最装逼,那么答案一定只有一个:“数据可视化”!看上去也很炫酷对不对,其实上面的可视化图表其实并不复杂,很多人推荐的Python、R语言、Tableau等专业数据分析工具几乎都能很轻松的实现...
  • 就这些问题,我院社调部、女生部对全校八个院系了抽样调查,结果分析如下: 恋爱现状及原因分析 在被调查的同学中, 42% 的同学表示自己谈过或是正在恋爱,而有 31% 的同学则表示目前未谈,若遇到合适的也会陷入...
  • 15.2.1 成为一名更优秀的数据分析师 331 15.2.2 成为一名更优秀的开发者 331 15.2.3 成为一名更优秀的视觉化讲故事者 332 15.2.4 成为一名更优秀的系统架构师 332 15.3 下一步什么 332 ...
  • Pandas是一个功能非常强大的数据分析工具,它能够非常有效的提高你的网页开发效率尤其是当开发过程涉及到数据分析的时候。Pandas能应用在下列网页开发情境中• 对表格数据进行可视化以确保对象映射查询是正确的• 在...
  • 就这些问题,我对全校各个院系了抽样调查,结果分析如下:一、大学生的恋爱特点1. 普遍性。在被调查的同学中,42%的同学表示自己谈过或是正在恋爱,而有31%的同学则表示目前未谈,若遇到合适的也会陷入其中...
  • 最近在学习如何打数据挖掘比赛,感觉以前自己根本没有分析的去比赛,因此我在重温之前的一些比赛,想看一下大神的思路是怎样的,今天这个比赛就是kaggle的入门比赛:泰坦尼克号比赛。虽然是入门的,但是有太多的...

空空如也

空空如也

1 2 3 4 5
收藏数 88
精华内容 35
关键字:

怎样做数据分析报告