第2章 用户需求

2. 用户需求

我们知道,学习软件开发,最好的方式就是去做项目。本章,就将启动一个示例项目,我们会讨论如何与用户交流,并从中获取真正的需求。而这将是项目成功的第一步,道理很简单,只有明确了目标,我们才能向着正确的方向开展工作。

2.1. 谁是真正的用户

在与用户会面,了解用户对软件的需求之前,我们先讨论一个问题,谁是真正的用户?

一个软件系统,它同时也是一件商品,而我们知道,商品的购买者未必就是真正的使用者,在单位里更是这样,而软件项目同样如此;假如老板批准购买了某个软件,他自己会使用吗?如果他不实际使用,他怎么又知道软件好不好呢?

好吧,我们就不更深入地讨论这些内容了,现在,我们只从技术角度来分析这个问题。在分析软件用户这个问题上,我们还要更详细地区分以下一些概念:

  • 客户,作为软件的客户,他们应该是购买软件的人或组织,但是,能做决定购买软件的人未必会真正使用软件。
  • 使用者,作为真正操作软件的人,他们应该是工作的真正执行者,我们的软件正是用来帮助他们完成实际工作的,而我们通常所说的用户就是软件的真正使用者。
  • 开发者,也就是我们,软件开发者,但绝对不是,也不应该是只会写代码和拖拽控件的那一种。

我们在使用“用户”这一术语时,经常将客户和使用者不加区分,而在本书中,我们约定,除有特殊说明,“用户”一词将是指软件的真正使用者。

2.2. 与用户会面

很多人会认为,与用户会面是市场部门的事情;但是,作为软件的开发者,如果我们不与客户有着深入地交流,那么,我们怎么才能理解用户真正的需求呢?

所以,与用户见见面是必不可少的了。问题是:何时?何地?要做何准备?又如何交流呢?

2.2.1. 时间与地点

一般来讲,与用户会面的时间应该由用户来定,一方面是礼貌性的,而最重要的是,用户决定会面的时间,一般会选择自己不太忙的时间,而此时,用户就会有更多的精力来与我们交流,而不是应付了事;这样一来,我们获取的信息也就会更有价值。

与用户会面的地点,我想,最合适的就是用户工作的地方。为什么呢?这当然也是有私心的,虽然开发者可能需要跑很远的路,但这绝对是值得的。首先,我们可以从用户工作的环境中获取非常多的,并且是很有价值的信息,比如,用户的电脑使用情况(操作系统,办公软件或系统)、网络情况等等,用心观察并仔细记录,必会有所收获。

2.2.2. 准备工作

在与用户会面之前,我们需要做一些什么准备呢?

我们知道,如果要进行深入的交流,两方有着共同的话题是很重要的。问题是,作为软件开发者,我们总不能去和用户讨论开发技术吧?如果话题不以开发者为中心,那么,就只能以用户为中心了,所以,我们必须有做一些功课。

一般来讲,普通用户并不知道软件的开发过程,他们只会对自己的工作比较熟悉,所以,会面时,如果我们对用户的工作一无所知,就会少了很多可以交谈的话题,如果没有和用户有着深入地交流,我们如何开发软件呢?如何用软件来帮助用户更高效的工作呢?

由此,我们可以认为,作为软件开发者,如果我们决定开发哪个领域的软件,不但需要熟练掌握各种开发技术和方法,还必须对业务领域有足够的了解,否则,是不可能有效地进行软件开发工作的。

我们知道,在数据无处不在的世界里,数据的处理方式、呈现方式和应用方式都是不同的,所以,在下面的示例中,会以一个接近真实的虚拟项目为例,虽然我们主要关注的是软件开发技术和方法的应用,但在实际开发各种行业的软件时,要充分理解所属行业和领域的具体工作流程,以及相应的数据处理方法。

除了从业务知识上做功课,我们还需要准备一些工具,在我看到,纸和笔可能是最重要的工具了,当然,如果用户允许,我们还可以对交谈进行录音或录像,这样就可以重复地、细致地回顾交谈的内容。

2.2.3. 如何交流

与用户交流可能是一件很愉快的事件,也有可能是一项很困难的工作,但这项工作对于软件开发成功与否却又是至关重要的,所以,我们必须要注意一些问题。

开发者应该当学生

这实际上是一个态度问题。很多情况下,开发人员会认为自己是软件开发方面的专家,而软件的用户根本就不懂软件的开发,所以,开发者会比用户更懂得他们需要什么样的软件。

从某些角度上来讲,这也没错,大多数软件的使用者根本不知道软件是怎么来的,这是事实;但是,如果是因为这样,开发者就听不进用户的任何话(主要是对需求的描述),那么,大多数项目的结果很可能会与失败结缘,如果项目不小心成功了,那开发者的运气真是太好了。

还是那句话,软件只是工作时使用的工具,如果工作的实质不清楚,如何开发出一个高效的工具呢?要知道,南辕北辙在软件开发工作中是很容易发生的事情,所以,我们必须要从与用户交流的过程中了解用户工作的流程和方法,并了解用户工作中的专业术语,一定要作为一名谦虚的学生去学习这些内容。

在与用户交流的过程中,“我比用户更懂软件开发”的态度绝对不应该出现,因为这时并不是软件开发的时间,而是了解用户工作内容和方法的时间。此时,作为开发者,需要做的工作就是聆听、记录、理解用户真正的工作内容、流程、专业术语、数据处理方法,以及工作所需要的结果。

做好记录

好记性不如烂笔头。

用户对于工作细节的描述,如果我们不进行完整的记录,很快就会忘记其中的一些细节,而这些细节将会是在软件开发中非常重要的参考依据。所以,在任何情况下,在与用户交流时,一定不要忘记带上纸和笔,把所有的内容都记录下来,不明白和不清晰的地方,一定要与用户进行交流和确认。

在软件设计和开发过程中,纸和笔会是最高效的工具之一,您可能会想用一些电了设备来进行记录,但是,最终你会发现,这些设备都没有纸和笔简单、便捷;在后面进行软件设计工作时,我们依然到看到纸和笔的作用。

提出正确的问题

如果在交谈中,我们没有谈到软件设计的问题,而用户也没有提出什么带有个人观点的要求,比如喜欢什么颜色、字体,界面背景使用什么颜色或什么图片等;这将会是一个非常好的情况,因为现在,双方的注意力都放在了真正的工作中,而实际上,这些也正是软件功能的本质所在。

在需求分析过程中,避免与工作无关内容的干扰是很重要的,无论是用户一方的,还是开发者一方的。在进行用户需求分析工作时,避免这些干扰的方法之一就是要提出正确的问题,比如:

“您希望软件有什么功能?”就不是一个好问题,用户并不了解软件开发或者软件功能,他们只对自己的工作了解,所以,不要让用户决定开发什么样的软件,或者怎么开发软件;简单地说,就是不要让用户来决定软件功能,而是让用户来描述自己的工作。

“您的工作详细流程是什么?”是一个好问题,这样一来,用户就可以专心描述自己工作的真正内容了,这正是他们所熟悉和擅长的东西,用户并不需要去考虑软件是如何开发的。

接下来,我们就来看一个与用户交流的场景。

2.3. (场景)与用户的第一次会面

作为开发者,我们在不断学习和实践,开发技能也在不断地提高,在朋友圈里也会越来越有些名气了,这不,一位同窗好友就联系到你,需要你帮忙做一个小软件。好吧,既然是朋友,我们在这里就先不讨论报酬上的事了,现在我们只专注于软件开发。

我们称这位朋友为小李,他现在就职于某个新成立的咨询公司,公司主要业务就是根据客户需要做一些市场调查,并提供相应的调查报告。公司刚刚成立不久,运气还算不错,接了一个小生意,是XYZ汽车公司的市场调查项目。

现在的问题是,公司并没有充足的资金来获取强大的软件系统,所以,只好四处打听,请会软件开发的朋友帮忙做一个简单的数据处理系统(最重要的是减少成本,做生意不容易呀!^^),正好,老同学小李想到了你。

2.3.1. 会面场景

今天下午,天气不错,按照约定,我们来到了小李的公司,准备谈一谈关于软件的需求问题。对方参加交流的人员除了小李,还有一名刘经理。双方互相打了招呼,然后直入主题。

刘经理:“受XYZ汽车公司的委托,我们要做一个关于XYZ汽车品牌的市场调查,我们将在4S店对来看车选车,以及保养和维修车辆的顾客进行随机的抽样调查。现在调查问卷都准备好了,并已经开始在多个XYZ品牌的4S店开始填写工作。现在的问题是,当问卷收回后,我们需要以最快的速度把数据汇总出来,我们公司没有这方面的专业人员,而专业的系统都太昂贵了,所以,我们想请您开发一个小型的软件系统,能够快速地录入数据、汇总数据,并给出各种统计结果。”

开发者:“这个听起来并不是太复杂,电子表格是不是就能做呢?”

刘经理:“电脑操作方面具体是小李做的,就请小李来具体说明吧。”

小李:“好的,是这样的,我们考虑过使用电子表格,但是,在测试录入数据工作时经常会出错,而且数据统计起来还要做很多的工作;所以,我们想是不是可以有一个软件,能够快速录入数据,并且在录入数据时能够检查数据正确性,最后能够自动统计结果并导出成电子表格格式,这样,我们就可以很方便出调查数据了。”

开发者:“就是说,软件的主要功能就是录入调查数据,然后给统计结果?”

小李:“是这样的。”

开发者:“这个应该不难,那你们的调查问卷是什么样的呢?”

小李:“我这里正好有一张。”说着,小李从文件夹里拿出了一张调查问卷,问题也不是很多,我们一起看一下。


XYZ品牌汽车市场调查问卷

□1、您是否拥有或曾经拥有过XYZ品牌汽车?

(1)是 (2)否

□2、您是否会考虑选择或再次选择XYZ品牌汽车?

(1)会 (2)不会 (3)不确定

3、您对XYZ品牌汽车各方面的看法:

□a.外观 (1)满意 (2)比较满意 (3)不满意

□b.内饰 (1)满意 (2)比较满意 (3)不满意

□c.动力 (1)满意 (2)比较满意 (3)不满意

□d.舒适性 (1)满意 (2)比较满意 (3)不满意

□e.售前服务 (1)满意 (2)比较满意 (3)不满意

□f.售后服务 (1)满意 (2)比较满意 (3)不满意

□4、您来4S店是为谁选车?

(1)自己家用 (2)亲朋好友 (3)政府或事业单位 (4)企业

(5)其他组织

□5、您是从哪个渠道了解XYZ品牌汽车的?

(1)朋友介绍 (2)报刊杂志 (3)电脑查询 (4)移动设备查询

(5)广告牌 (6)其他方式

6、您要对XYZ汽车公司说些什么?


开发者:“就这么简单?”

小李:“是的,就这几个问题?”

开发者:“我对汽车不是很懂,从这几个问题中能了解些什么问题呢?”

小李:“实际上,XYZ公司就想通过调查了解一下市场对XYZ汽车的满意度,比如现有的车主使用是否满意,是否愿意推荐给自己的朋友,或者有哪些方面不太满意,从而可以进一步改进,另一方面,通过大家了解信息的方式,还可以改进推广方式。”

开发者:“听进来有点儿意思,我也正想买辆车呢,正好了解一下这个品牌。”

小李:“等数据出来你就可以知道好不好了。”

(这主意真不错^^)

开发者:“这个软件应该比较简单,那么,数据录入后都需要一些什么样的报表呢?”

小李:“这个就比较多了,……”

接下来,小李给出了一些需要的统计结果(希望你正好带了纸和笔): - 当问题(1)答案是1时,问题(2)的回答就直接可以反映出用户的忠诚度。 - 当问题(1)答案是2时,问题(2)的回答可以反映出准车主对XYZ汽车的总体映像如何。 - 问题(3)分别给出了选择汽车的几个重要因素,可以了解大家对这些方面的满意度。 - 问题(4)可以反映选购车的用途,也从侧面反映了XYZ汽车所面向的主要市场。 - 问题(5)反映了大家了解汽车信息的方式,可以根据结果有针对性的加强这方面的推广工作。 - 问题(6)是礼貌性的问题,让大家能够提供更多的信息,有助于XYZ公司进一步地改进。

(先缓口气,消化几分钟再说,……)

开发者:“这个软件是要单机版?还是要网络版?”

……

(小李和刘经理都无法回答这个问题,希望你能很快明白这一点。)

开发者(换个方式):“这个软件需要几个人操作?”

小李:“现在看来就是我一个人使用。”

开发者:“那我明白了。另外,我能看看你们电脑的工作环境吗?”

小李:“没问题。”

一会儿,大家来到了小李的电脑前,作为一个软件开发者,我们应该很容易看出电脑里安装的是什么系统和哪些办公软件。小李的电脑是很“典型”的,包括了Windows XP系统和Office 2003办公软件,这些信息应该会对我们的软件开发有帮助。

开发者:“生成的报表格式是Excel的就可以了吧?”

小李:“是的,就是我们用的这个。”

开发者:“好的,基本的工作要求我都了解了,我考虑一下,这两天给出一个方案。”

刘经理:“好的,有什么事情直接和小李联系就行了,数据处理工作主要是他来做的,你们是同学,交流起来也更方便。”

开发者:“好的,刘经理。”

……

2.3.2. 需要明确的问题

谁是真正的用户?

在前面,我们已经讨论过在软件开发过程中的角色问题,那么,在这个场景中,谁是真正的用户呢?

答案是:小李。并不是因为我们假设小李是同窗,也不是因为刘经理让有问题直接与小李联系,而是因为小李的确是真正执行工作的人,而从交流过程中可以看出,软件最重要的操作人就是小李,所以,当我们需要了解软件的需求时,就应该与小李进行交流。

这是一个什么样的软件?

从交流的结果看,软件的功能实际并不复杂,也许你已经跃跃欲试了,不过,我们还是要多次思考:我们应该开发出什么样的软件?

这个项目实际上是一个比较简单,同时也是比较典型的数据处理软件,其功能不过是录入、统计汇总和输出报表。而软件的类型,就交流的结果看,一个单机版的软件应该是可以了,用户并没有提出更多的要求,所以,我们也不应该假设用户的需求,现在,我们可以认为,需要开发的就是一款单机版的数据处理软件。

关于开发的头脑风暴

如果大家已经掌握了一些,或者非常熟悉C#和.NET Framework相关开发资源,那么,经常会在思考软件功能的时候考虑它的实现方法,也就是会有一些头脑风暴,在大脑中形成软件的代码结构、界面样式,以及数据的管理方法等。

这些都是很自然的事情,但有一点需要说明,那就是这种情况需要一定的控制,现在,我们对用户的需求还没有完全确认,现在就开始开发的细节似乎有些太早了些,所以,对于软件的实现,想想当然没有问题,但不应过多的深入细节,因为我们还没有真正进入开发阶段。

我接下来还有很重要的工作要做,那就是……

2.4. 提取真正的需求

前面,我们通过与用户的交流,大概了解了用户的工作是如何进行的,工作的内容是什么,以及工作的结果是什么。接下来的工作,我们必须对这些内容进行进一步的整理,并对不明确的部分进行确认,以便为真正的开发工作做好准备。

2.4.1. 需求分析

在前面的场景中,我们已经对用户的需求有了一些文字上的了解,在软件设计过程中,随手画一画结构或流程图是非常好的习惯。一图值千言,这句话在此时是非常正确的。实际上,如果我们将上述的用户需求画出一个初步的流程图也非常简单,如图。

图像说明文字

图中,我们将此项目中的数据处理工作分成了三个步骤,这也是数据处理的一般性流程。在这三个步骤中,我们都分别列出了需要注意的问题;您可能会问,为什么是这些内容需要注意?答案是,从用户的对话内容和提供的资料中提取的。

接下来的讨论中,我们将以此图为依据。这里,我们先讨论这三个工作步骤,而具体的实现方法,也就是数据处理的流程和方法问题,在后面的内容中会继续讨论。

数据采集

根据用户的描述,数据采集工作是比较简单的,只是将调查问卷的问题答案输入到软件中,而需要注意的则是答案输入的正确性。

对于软件中需要处理的数据,一定要有足够的信息和资料做支撑;而这些信息和资料就来自于用户,其中,更多的内容应该是来自于真正的工作人员,也就是我们前面所说的软件使用者(场景中的小李)。

计算汇总

在小李的描述中,我们了解了数据最终呈现的结果,但是,从采集的基础数据到生成报表过程中,还需要对数据进行一系列的计算和加工。

根据小李的描述,统计的结果是多种多样的,但是,我们可以了解到,这些计算结果可以很方便地通过编程语言或数据库特性得出,所以,这在技术上也并没有什么可怕的。

生成报表

通过基础数据,我们可以很方便地生成用户所需要的报表,……

那么,报表需要使用什么样的格式呢?还好我们在用户那里进行了确认,生成的报表为Excel格式。

2.4.2. 还缺些什么?——需求最简原则

我们已经对画出的软件的简单处理模型做了一些了解,并确认了其中的一些细节问题,而现在,在很多情况下,开发者都会思考这样的问题:“我们还有什么没考虑到吗?需求中还缺些什么功能呢?”

如果在前面的工作过程中,我们想不出软件中还需要什么功能,那么,就不要盲目地去添加,这就是需求分析的最简原则,一切以事实为依据,而不是去想像;而这其中依据的事实,就是用户工作的本质。

还缺点什么?暂时不用担心了。对于不明确的地方,我们还可以找用户进行确认。

2.4.3. 向用户确认需求分析结果

接下来的工作,我们可以将上面的软件模型图以及我们对这些内容的理解交给用户,以便得到确认,并且,我们还可以对不明确的地方进行交流和确认。

根据我开发类似项目的经验来看,前面的这个模型已经是比较完整地表现了这个项目的基本模型,虽然它还比较简单;一般来讲,用户可能已经比较认可了,不过,我们还是应该注意,用户有时候会随时添加一些要求,此时,作为开发者,我们应该和前面处理需求的方法一样对待:

  • 要有谦虚、认真、务实的态度。
  • 认真记录。
  • 仔细分析并提取真正的需求。 
    对于附加的要求也要详细的记录,在开发时,我们根据实际情况考虑这些内容。比如,小李近视比较严重,此时,小李可能会提出,软件的字体能不能大点,因为他在上网时经常要把内容放大才能看得舒服,这只是小李的个人要求,而不是工作的一部分,所以,这只是附加要求,而不是软件需求,不过,我们会记录下来,在软件开发时会考虑这样的个人要求。

2.5. 软件功能

接下来,我们需要做的是将用户的工作内容和流程向软件模型转变。在这一过程之前,必须确保对用户的需求有着深刻地认识,如果有些需求不清楚,我们还可以继续与用户进交流和确认,只有这样,我们接下来的工作才会更加顺利。

实际上,用户需求模型与软件模型还是有很大区别的,前面的需求模型图非常简单,如果直接用来进行软件开发显然是不合适的;现在,我们需要继续对这个模型图进行细化工作,以生成可以用于开发工作的软件模型。在软件模型中,需要涉及的内容就比较多了,主要包括一系列的业务处理流程,以及工作内容和数据的处理方法。

在这一过程当中,我们最重要的工具还是纸和笔,我们需要使用这些工具将软件功能和模型画出来,这就是软件的纸上原型。使用纸上原型,我们可以快捷、灵活地分析和处理软件的模型。

2.5.1. 数据采集

结合对于用户工作内容的分析,我们可以得出在数据采集工作中的主要操作,即: - 数据录入,在软件的界面中,分别录入每一份问卷的数据。 - 数据检查,对录入的数据进行正确性检查。 - 数据保存,保存已录入并检查正确的数据。 - 数据载入,对于已保存的数据,可以载入到界面,此时,用户可以修改并重新保存。

综合这些步骤,数据采集工作的流程如下图。

图像说明文字

其中,数据载入操作只是一个可选的操作,如果用户不需要浏览或修改已录入的数据,那么,就并不需要载入这些数据。

对于上述的一系列操作,我们完全可以在一个界面中完成,结合用户提供的问卷,我们可以考虑一个与问卷高度一致的界面。如下图:

图像说明文字

画出软件界面草图的同时,如果我们对.NET Framework中的控件比较熟悉,可能会在脑海里不时地出现这些控件的影子,这应该是职业习惯,但是我们应该注意,对于这种情况,一定要适可而止,不要在需求分析和软件初步设计阶段就过早地陷入技术细节之中。原因很简单,任何开发技术和方法都是为软件的功能和需求服务的,不应该让开发技术影响我们对软件真正功能的判断。

在界面中,我们没有看到“数据检查”的操作,的确是这样。此时,我们可以思考一下,是不是需要一个单独的“数据检查”操作按钮呢?

我的答案是,完全没有必要!数据检查的工作可以在“保存”操作前自动完成,这样可以有效地简化用户的操作。为什么是这样呢?我想,这应该就是真实业务与软件操作之间的交汇点,同时也是比较容易出现问题的地方;而这其中最主要的问题表现在:手工操作设计过度和自动化设计过度。

手工操作设计过度

如果我们添加了“数据检查”按钮,那么,就是一个典型的手工操作设计过度。在实现工作中,如果是在Excel中,或是直接在纸质问卷(报表)中填写数据时,用户很可能会对录入的数据进行人工检查;但是,在我们的软件中,这项工作就可以在程序中自动完成,所以,对于一些可以自动化完成的工作,一定要体现软件的这项优势,不要用着先进武器去打原始战争。

不过,有一点还是值得我们注意,这里所指的自动检查只能是对数据的范围做一些基本的检查,这主要是防止录入时的误操作,比如,录入了不正确的数据或奇异值(超出有效或合理的数据范围)等情况;而录入的数据与实际填写数据是否一致,这项工作只能由用户自己来进行人工核对了。在避免人工录入数据错误操作上,有不少的方法可以使用,在后面,我们会讨论相关的主题。

自动化设计过度

如果软件自动化设计过度,用户就会失去对工作过程的感知,可能会有一些莫名其妙的感觉,失去操作过程的真实感,而这种情况往往会让用户感到恐惧,因为他们看不到自己的工作过程或工作内容时,会担心他们的工作成果是不是会丢了。

现在,我们可以了解,手工操作和自动化是软件设计过程中互相矛盾的两个方面。所以,在手工操作设计和自动化设计之间,我们必须找到一个平衡点,即要让用户感觉到工作的过程,同时,又要体现计算机自动计算的特点。

2.5.2. 计算汇总

计算汇总功能,在本书的示例中,就是实现小李所提出的一系列统计结果,实际上,如果我们真的开始工作以后,你就会发现,在计算和汇总调查数据时,是非常灵活和多样化的,同时,也是非常复杂的一项工作。这需要我们充分利用数据库和开发工具的各种特点来完成。

现在,我们以小李提出的两个统计项目来讨论本项目中的计算汇总功能。 第一个是:“当问题一的答案是1时,问题二的回答就直接可以反映出用户的忠诚度。”

那么,用户,也就是现任车主的忠诚度如何计算呢?首先,必须给出在问题一中选择1的总数(使用S表示);然后,我们根据问题二的答案所占的比例就可以看出现任车主对XYZ汽车是不是满意了,如问题二的三个答案:

1——会再次购买,说明车主对XYZ汽车比较满意,如果这个答案所占比例比较大,说明大家对XYZ汽车还是比较满意的。而且,这部分车主很有可能会向朋友推荐XYZ汽车,这很不错。如果此数据表示为a,那么,现有车主的忠诚度就是(a/S)*100%。

2——不会,说明这部分车主对XYZ汽车有一些不太满意的地方。也许问题三的回答可以给出这些方面的答案。

3——不确定,XYZ汽车公司还是多努力出好车留住这部分客户吧!

第二个是:“当问题一的答案是2时,问题二的回答可以反映出准车主对XYZ汽车的总体映像如何。”

这部分实际上反映了有多少潜在的客户,对于问题二的不同回答,可以帮助我们得出潜在客户的比例,这和第一个问题的计算方法是相似的。

希望你可以将剩下来的问题也都分析一下,这样就可以清楚地了解在数据的计算汇总过程中都需要一些怎么样的基础数据,同时,需要什么样的计算方法,以及得出什么样的结果。

2.5.3. 生成报表

在示例项目中,我知道了用户在工作中会使用Excel 2003,那么,在生成报表时,就可以利用这一点,我们可以在软件中通过Excel 2003来生成报表,这样就可以省下了不少的开发工作。

利用用户的软件环境实现软件功能,可以有效地提高我们开发软件的效率,但有一点,如果我们不能确定用户的软件环境时怎么办呢?

比如在示例项目中,如果用户根本就没有使用软件来制作报表,而是直接要使用我们开发的软件来完成这项工作,那么,我们的软件中会如何来处理报表呢?有很多用于生成报表的软件或组件可以帮助我们在项目中实现报表功能,如Crystal Report等。但是,如果我们对各种开发技术都了解一些的话,我们完成可以不使用任何报表工具,而只需要使用一项最基本的技术来实现简单的表格功能,而且这个功能是真正的跨平台。

什么技术?很简单,使用HTML。我们可以将报表中的数据自己编码生成HTML表格,然后,可以通过浏览器打开。是不是很简单,也非常的通用,试想一下,用户使用的计算机哪一台会没有安装浏览器呢?实际上,使用ASP.NET开发Web项目,我们可以很方便地实现网络版的报表功能。 以上只是讨论,而现在,真正的报表格式是什么呢?Excel 2003!。

2.6. 项目需求确认

经过前面的交流、分析与确认,我们已经基本了解用户对于本软件的需求,对于一个软件项目,在这一阶段可以形成《项目需求确认书》,此文档的主要功能有两个:

  • 明确用户对于软件功能的要求。白纸黑字,签字画押,可以有效防止不愉快的事情发生。
  • 为软件开发工作做准备。明确了具体的目标,开发工作就好做了。

以下,我将结合用户的描述、开发者的分析和确认,对示例项目的需求做一个完整的描述,以便在后续的开发中使用。


整体目标与要求

软件将为用户的品牌满意度调查服务,主要功能包括调查问卷的录入、统计汇总并生成数据报表,为客户市场发展提供依据。

软件功能

经过两方的交流与确认,软件的功能包括以下几个方面。

  • 基本数据采集。使用本软件进行问卷的手工录入。
  • 计算汇总。根据录入的调查数据,计算各种所需要的数据。
  • 生成报表。根据已列出的要求给出报表。报表将生成Excel格式。

附注

  • 统计报表类型由双方协商,另行决定。
  • 界面字体要大一点。

实际上,本项目的确非常简单,所以,需要确认的内容也不多。在实际的项目中,我们应该根据与用户交流的结果,在《项目需求确认书》中只要能够完整地记录下软件的需求就可以,此时,并不要求确认书内容的长短,只要能够反映出用户对软件的需求就可以了。

有经验的朋友可能看出了,这里少了很多细节问题,比较报表的类型,这些内容不细化同样可能产生不必要的麻烦,不过,我们只是做示例,就不要太复杂了,这里提一下,大家在实际应用中应该注意,需要说清楚的问题还是应该越详细越好。在这一过程中,我们还可以通过多个需求确认书或需求修订书来完成。

最重要的是,我们要明确需要开发一款什么样的软件。

2.7. 获取需求小结

前面,我们已经根据示例项目了解了一些用户需求获取、分析、确认的方法和注意事项,在这里,我们将这些内容列出来,方便大家在学习和工作中查询和参考,当然,你还可以在这些内容之外不断地添加自己的总结,这也是我们学习和积累的好方法。

2.7.1. 找到真正的用户

在需求分析之前,我们必须找到真正的用户,在这一过程中,我们的目标是真正的从事具体工作的人员,不是只看工作结果的老板,也不是不懂业务的工作人员。

从事具体工作的人员,往往也正是软件的最终使用者,他们将会使用软件进行自己的工作,此时,软件应该是他们有力的助手,可以帮助他们高效地完成工作,而不是一个碍手碍脚的工具。

真正的用户应该是非常熟悉自己的工作内容、流程,以及工作最终所需要的结果,并且,他们还应该能够完整、详细地对自己的工作进行描述,如果用户不能很好地描述自己的工作,那么,我们就必须提出正确的问题进行引导。

2.7.2. 请用户详细描述自己的工作

注意,这里是“请”用户详细描述自己的工作,作为开发者,我们此时的工作就是了解用户的工作,包括其工作内容、流程和所需要的结果,只有真正理解了用户工作的本质,我们才可能开发出对用户有用的软件。反之,如果我以软件专家自诩,对用户真正的需求不理不睬(无论是有意或是无意的),那么,我们就会失去真正的目标,从而可能盲目地去进行开发,此时,你做的越多,可能就会离真正的目标越远。

所以,我们必须让用户完整、详尽地描述自己的工作内容和流程,必须正确地指出工作应该达到什么样的目标,以及需要什么样的结果。此时,我们必须要用正确的方法,合理地引导用户来描述自己的工作,请注意,用户应该是工作方面的专家,而开发者此时的角色应该是学生。

2.7.3. 提出正确的问题

如果用户对于自己工作的描述不够详细,那么,我们就必须进行一些引导,此时,作为软件开发者,我们所要做的就是提出正确的问题。

不同的软件项目,其关注的主题可能并不一样,所以,开发者提出的问题也会有很大的差异,在这里,我们只能列出提出正确问题的一些基本原则,更多的内容还需要开发者在实践过程中具体事情具体对待。

提出正确的问题,首先,我们必须有明确的目的,此时,我们要清楚,自己需要了解的内容是什么,主要有两个方面:

  • 用户工作方面。包括工作内容、流程、数据(或信息)的处理方式和方法,以及工作最终的结果是什么(如工作报告、报表等)。
  • 用户的软件使用环境。包括操作系统、网络环境、常用软件,工作中使用的电子文档(包括文件格式和内容的样式)。

另外,除非用户也是真正的软件开发者(不是只懂得几个术语的人),否则不要和用户讨论软件需要什么功能或者是如何来设计软件。

2.7.4. 详细记录

无论是用户的描述,还是回答开发者的问题,甚至是看上去无关紧要的交谈内容(那可能只是你的错觉),我们都应该做详细的记录,只是这样,我们才能最大限度地获取用户的工作信息。如果使用纸和笔记录较慢,可以在用户允许的情况下进行录音或录像,以便更仔细地分析交谈内容。

通过这些记录,可以对下一步的需求分析和软件设计提供有效的依据,而不是根据开发者的想像来进行软件开发。当然,如果开发者有足够的经验,那就又是另外一回事了;不过,这些经验是否有效,还是需要实践来验证的。

2.7.5. 分析并提取真正的需求

分析并提取真正的需求,需要有可靠的信息,而这些参考信息的来源主要包括两个方面,即用户描述和提供的资料。

对于用户描述,我们需要进行详细记录;而对于用户能够提供的资料,我们需要认真分析其中的细节,从而能够从中找到更多的、有用的信息。

需求分析最简原则是指,开发者在分析和提取用户需求时,必须要有足够的证据做支撑,要从用户提供的信息和资料中提取真正的需求,而不要自己去想像需求。但从另一个方面讲,对需求合理的推断除外,但我们如何把握这个度呢?恐怕没有什么绝对的答案,唯一的原则就是推断不但会以事实为依据,还与开发者的经验,以及开发者对项目理解是否深入有关。

同时,开发者还要注意区分真正的需求和附加要求之间的区别。

2.7.6. 确认分析结果

当开发者通过用户提供的信息和资料完成了需求的初步分析后,必须要向用户进行确认,此时,可以采取文档的形式,也可以进行口头上的交流,主要是请用户对需求分析结果进行确认。

在这一过程中,如果开发者还有不清楚的地方,应继续与用户交流并确认,直到所有的已知问题都通过用户的确认为止。

2.7.7. 区分需求与附加要求

对于用户需求分析的结果,很要可能包含了两部分内容,即真正的需求和附加要求。

真正的需求是指用户工作的真正内容,这些内容反映出了软件所需要开发的真正功能,如数据如何处理、结果以怎样的形式呈现等等。

附加要求。一般会是指某些用户的个体喜好或要求,如字体、颜色、外观等,这些要求对工作的实质并没有决定性的作用,但出于对用户的尊重,我们还是应该对这些要求进行记录,并在软件开发中根据情况做出权衡。对于容易实现的要求,我们当然可以做个顺水人情,但对于复杂的要求,甚至是对软件开发有害的要求(用户可能并不知道这样的要求会对软件开发带来多大的麻烦),我们应该与用户进行沟通,能够让用户放弃这样的要求。

作为软件开发人员,我们不但要获取真正的需求,而且要学习如何巧妙地忽略用户不合理要求。

2.7.8. 画出模型草图

从需求到软件模型,再到软件开发,是一个比较复杂的过程,而且不是一个非常自然的过程,这其中,对于模型的转换是一项非常复杂的工作,在这一系列过程中,在纸上能够随手画一画不同的模型,会对我们理解整个软件的结构有着非常大的帮助。很多时候,纸和笔都是开发人员手中最有效的工具之一。

2.7.9. 防止过早陷入技术细节

对于熟练的开发者,经常会在需求分析和软件设计过程中同时思考相应的实现技术,这几乎是无法避免的,但对于这一现象,我们必须从两个方面来看待:

在设计过程中,能够同时进行技术同步设计,在需求分析结束后,就可以马上进行软件的设计和开发工作,对于熟练的软件开发人员来讲,这的确可以提高工作效率。

从另一个方面来讲,这种情况必须要进行有效地控制,在用户需求和设计阶段,对于技术细节的思考要适可而止,因为这部分工作的主体是搞清楚用户工作的本质,这样才能专注于软件的功能,而在明确这些需求以后,再考虑使用开发技术来实现这些功能,这样才能专注于软件的本质,从而有效避免技术应用对软件功能的影响。

2.7.10. 文档的应用

在需求分析完成阶段性工作时,最好有一个《项目需求确认书》,这样,可以为用户和开发者确定一些明确而统一的目标,软件开发的道路就会比较通畅。

很多软件开发者对于项目文档可谓是非常的痛苦,一方面需要加班加点进行软件的开发工作,另一方面还要同步文档内容,而这些内容往往并没有太大的意义,甚至有些是为了文档而文档,这的确是某些项目中的文档处理方式。

如果人员充足,在项目组中有专人从事文档的维护工作,对于软件开发者来说,就会轻松不少,但是,如果在人手很紧张的情况下,项目文档的相关工作就需要我们更认真地思考一下了。

项目文档的应用,我想应该从实用性出发,而不是为了表面上的好看而工作。项目文档应该对整个项目起着正确引导和记录的作用。

一方面,在各个阶段,文档都能够对工作的方法和目标做一个统一的标准,这样,大家的工作就可以朝着一个方向前进,此时,项目文档的作用就是为整个开发团队的工作进行正确地引导。

另一方面,在项目开发的各个阶段,应该对阶段性的工作做一些记录,此时,最主要的是工作目标是否达到?工作中的问题是什么?这些问题是否得到了解决?解决的方法是什么?这一系列问题的答案将会我们整个工作过程中有着实际意义的资料,更是我们学习和积累的宝贵财富。

如果文档只是对软件设计和编码工作的重复,那么,这样的文档就不会有太大的意义,其内容也永远不会比代码更新,所以,复制代码功能的文档是没有意义的。对代码解释最好的方法,就是在代码中来完成,无论是代码本身或是使用简单明了的注释,这些都会比在文档中解释代码更有效,也更及时。

此外,项目文档可以是普通文档,也可以在项目管理系统中形成,这主要看项目中使用了什么样的管理方法和工具。

目录