我们怎样做需求(十九)、非功能需求

来源 :我们应当怎样做需求分析                                                 作者:fangang


我曾经看过许多关于需求分析的书籍,老外写的,国人写的,都有。但我总体就是一个感觉:累。各种各样的分析、各种各样的视图,让人眼花缭乱。为什么会这样呢?不得不说,需求分析是一个太宽泛的概念了,不同的行业(商业的、管理的、游戏的),不同类型的软件(底层的、桌面的、网络应用的),不同的设计方式(面向过程的、面向对象的),需求分析的过程都存在着巨大的差异。要制订放之四海而皆准的方法谈何容易。即使同一类型的软件,它们也存在着各自的特点,有的问题大多数软件都不用考虑,而它必须考虑。正因为如此,许多关于需求分析的方法和书籍描述得挺复杂的。

   但我要说,我们做需求分析应当化繁为简,不必去拘泥于那些过程。怎样化繁为简?寻找适合自己的,避免做过度分析和设计,这种思想也是敏捷开发的精髓。比如我所从事的管理软件的研发,关注业务流程、关注业务实体、关注规则约束,功能方面的需求就分析完成了大半。然后再关注查询报表、关注外部接口、关注打印导出等细小功能,功能方面就差不多了。

   但是,我不得不说,需求分析人员最容易忽略的部分就是非功能需求。非功能需求更加靠近的是技术,是设计,是实现,是架构师关注的内容,是需求人员最不擅长的方面,这也是非功能需求为什么常常被忽略的重要原因。正因为如此,架构师应当尽早参与到项目中,参与到需求分析中,尽早分析需求的技术可行性,尽早考虑性能、安全性、可靠性等非功能需求,尽早开始架构设计。

   在非功能需求分析中另一个非常常见的错误,就是将非功能需求仅仅归结为一些放之四海而皆准的原则,比如专门拿出一章来描述报表查询效率要怎样、系统易用性要怎样。诚然,这些原则性的东西是十分必要的,但许多非功能需求不能仅仅停留在这些基本原则上,要落实到对一个一个功能的分析中。

   说这么多虚的,咱们还是上实例吧。还是这个考核系统,每天在上班后1小时内,将有90%的用户会上线查看自己的考核结果。因此,在进行考核结果查询功能的分析中,我们写下了这样的话:查询必须高效(预计查询数据量:xxx),并且支持高并发操作(预计并发用户峰值:xxx)。有了这些描述,设计和开发人员会着重注意该功能的性能问题,测试人员也可以着重进行该部分的性能测试。

   在另一个项目中,用户需要对大量的数据进行选择,进而完成制作清册、下派、回退等操作。在前期的需求分析中,需求人员没有仔细分析这些操作的易用性,没有提供给用户批量选择等功能,直到试运行时才发现。当时系统到各基层试运行时,激起了巨大的民怨,给项目带来了巨大的负面影响。多亏我们及时发现问题,加班加点完成了相关操作的批处理功能,才使项目得以顺利推行。如此看来,非功能需求对于一个软件项目是多么重要。因此,我建议,在需求分析的细化阶段,需求分析人员应当与架构师一起,一项一项地去分析每个功能的非功能需求,并在用例说明中记录下有特殊非功能需求的功能,使我们对非功能需求的分析落到实处。

   那么哪些是非功能需求呢?我们可以简单归纳为“URPS+”,即可用性(Usability)、可靠性(Reliability)、性能(Performance)、可支持性(Supportability)以及其它(+)。而这5部分我们可以进一步细化。

   可用性是一个非常宽泛的概念,它泛指那些能让用户顺利使用系统的指标,包括易用性(易操作、易理解)、准确性、安全性(权限体系、访问限制)、兼容性(服务器、客户端的兼容度),等等。

   可靠性就是系统可以可靠运行,包括系统成熟度(数据吞吐量、并发用户量、连续不停机性能等)、数据容错度、系统易恢复性,等等。

   性能,我认为是需求分析阶段最主要的分析内容。用户对性能的要求没有止境,但现实却是残酷的。性能受到许多因素的影响,包括业务需求、软件设计、数据库设计、系统部署方式,等等。其中,业务需求和部署方式,对性能的影响是最大的,我们必须在需求分析阶段就想清楚,解决掉。有一次,客户提出了一个数据导出的功能,这看似一个非常普通的功能。但是经过仔细地分析我们发现,客户在执行数据导出前的查询时,如果选择时间跨度数年,查出的数据量可能达到数十万。要将数十万数据一次性地导入到一个excel文件中,这不论从运行效率、系统稳定性,还是技术可行性分析都是不可取的。最后,我们经过与客户的协商,一次性导出数据最大不超过2万,同时提供了分页导出的功能,可以让他们选择导出从第几页到第几页的数据。这样,如果数据量大,客户可以经过多次将数据导出,数据导出的性能得以保证。

   系统部署架构对性能的影响也是巨大的。一个管理系统,是市级集中,还是省级集中,甚至全国集中,对性能的考量是不一样的。市级集中不会过于担心性能的问题;省级集中就必须要考量并发访问量,是否要建立集群;全国集中就必须考量是否使用消息队列,所有流程是否有性能瓶颈,以及采用什么技术架构更适于并发访问等等。而这一切都是系统架构师应当考量的内容。

   最后一个内容,也是最容易被忽略的一个内容,就是可支持性。可支持性,就是软件的可维护性、易变更性。可支持性对于客户是透明的,不可见的,因此客户通常不关心这个。由于时间紧、人员素质参差不齐,这部分也常常为管理者所忽略。但试问,谁没有维护糟糕系统的痛苦经历?谁们的系统维护了数年经过数次升级后还能维护?在需求分析与设计阶段,可支持性实际上体现在,我们是否能有效识别系统可变的需求,并能够提供合理的方案。这体现的也是架构师的功底。一次分析和设计ERP软件的时候,我发现应付单需要生成凭证,随后又发现应收单、采购单、销售发票都要生成凭证。既然这么多单据需要生成凭证,是否还有其它我们还不知道的单据也要生成凭证,是否可以有一个统一的接口。果不其然,核销单、工资单、固定资产核定都需要生成凭证。最后我们设计成了一个统一的生成凭证接口。还有一次,我们发现客户报表在查询SQL、过滤条件、显示列等部分经常变,因此设计成一套可配置的报表系统,大大提高了系统可维护性。

   需求分析是一个撒大网的过程,而不是姜太公钓鱼的过程。功能需求固然重要,非功能需求同样重要。我们在进行非功能需求的分析时,除了制订整体的原则以外,还要落实到各个具体的功能中,将这些功能所潜在的、特殊的非功能需求挖掘出来,提前进行分析设计,对于可行性不高的应及时与客户商讨,才能有效地避免日后存在的这些方面的风险。