我们应当怎样做需求分析：非功能需求

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

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

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

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

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

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

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

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

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

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

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

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

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

[url=http://fangang.iteye.com/blog/1345099]我们应当怎样做需求分析[/url]
[url=http://fangang.iteye.com/blog/1345283]我们应当怎样做需求调研：初识[/url]
[url=http://fangang.iteye.com/blog/1392009]我们应当怎样做需求调研：拜访[/url]
[url=http://fangang.iteye.com/blog/1394911]我们应当怎样做需求调研：研讨会[/url]
[url=http://fangang.iteye.com/blog/1396971]我们应当怎样做需求调研：需求研讨[/url]
[url=http://fangang.iteye.com/blog/1403342]我们应当怎样做需求调研：迭代[/url]
[url=http://fangang.iteye.com/blog/1474362]我们应当怎样做需求调研：需求捕获（上）[/url]
[url=http://fangang.iteye.com/blog/1474368]我们应当怎样做需求调研：需求捕获（下）[/url]
[url=http://fangang.iteye.com/blog/1481975]我们应当怎样做需求分析：功能角色分析与用例图[/url]
[url=http://fangang.iteye.com/blog/1481996]我们应当怎样做需求分析：业务流程分析（上）[/url]
[url=http://fangang.iteye.com/blog/1482008]我们应当怎样做需求分析：业务流程分析（下）[/url]
[url=http://fangang.iteye.com/blog/1482165]我们应当怎样做需求分析：用例说明[/url]
[url=http://fangang.iteye.com/blog/1482171]我们应当怎样做需求分析：查询报表分析[/url]
[url=http://fangang.iteye.com/blog/1483063]我们应当怎样做需求分析：子用例与扩展用例[/url]
[url=http://fangang.iteye.com/blog/1483082]我们应当怎样做需求分析：行动图和状态图[/url]
[url=http://fangang.iteye.com/blog/1487102]我们应当怎样做需求分析：业务领域分析[/url]
[url=http://fangang.iteye.com/blog/1488291]我们应当怎样做需求分析：原文分析法[/url]
[url=http://fangang.iteye.com/blog/1493720]我们应当怎样做需求分析：领域驱动设计[/url]
[url=http://fangang.iteye.com/blog/1497941]我们应当怎样做需求分析：非功能需求[/url]
[url=http://fangang.iteye.com/blog/1502857]我们应当怎样做需求确认：需求列表[/url]
[url=http://fangang.iteye.com/blog/1502858]我们应当怎样做需求确认：一个需求列表的实例[/url]
[url=http://fangang.iteye.com/blog/1504123]我们应当怎样做需求确认：快速原型法[/url]
[url=http://fangang.iteye.com/blog/1505381]我们应当怎样做需求确认：需求规格说明书[/url]
[url=http://fangang.iteye.com/blog/1506403]我们应当怎样做需求确认：评审与签字确认会[/url]

（续）

我们应当怎样做需求分析：非功能需求相关推荐

我们应该怎样做需求分析?（一）需求调研
摘自百度文库链接:https://wenku.baidu.com/view/1e2bab73f46527d3240ce0cb.html 一. 我们应当如何做需求分析? 需求分析不是一蹴而就的 ...
《我们应该怎样做需求分析》阅读笔记
认识: 软件需求分析是贯穿软件项目从出生到成长或者死亡的,我们必须搞清楚到手的软件是为了什么要做什么做成什么样,通过顾客的描述彼此的合作分析需求与业务逻辑,不断改进从而实现软件在合理范围内符合顾客要求 ...
《我们应当怎样做需求分析》阅读笔记
在阅读<我们应当怎么做需求分析>这篇文章后,我了解到了许多有关软件需求的相关知识与内容. 文中主要说了三项重要的内容,分别是需求调研.需求分析以及需求确认.而我恰好也觉得这些就是本学期&l ...
针对非业务的通用框架开发，如何做需求分析和设计？
项目背景我们希望设计开发一个小的框架,能够获取接口调用的各种统计信息,比如,响应时间的最大值(max).最小值(min).平均值(avg).百分位值(percentile).接口调用次数(count ...
项目管理：怎样做需求分析（一）
如果将需求分析阶段的工作归结为编写需求规格说明书,这种简化的做法往往是导致项目后期层出不穷问题的罪魁祸首.建议采用以下步骤形成软件需求:获取用户需求→分析用户需求→编写需求文档→评审需求文档→管理需 ...
《我们应当怎样做需求分析》读书笔记
<我们应当怎样做需求分析>读书笔记 <我们应当怎样做需求分析>这篇博客的作者以自己的经验和教训告诉我们怎样解决项目中的需求问题.要解决需求问题,就要从需求调研.需求分析.需求确 ...
需求分析及需求文档的编写
通常,软件开发工程师和软件测试工程师的工作都开始于软件需求说明书成型的基础上.那么软件需求说明书到底是怎么来的,软件的需求分析到底怎么做?今天我就针对这个话题结合我自己的一些理解和经历来梳理一下. 需 ...
我们应当怎样做需求分析：业务领域分析
在需求分析工作中,最后一项分析工作就是业务领域分析啦.业务领域分析,就是对需求分析中涉及到的业务实体,以及它们相互之间关联关系的分析.前面我们谈到了功能角色分析,或者说用例分析,它是从整体的角度对整个 ...
我们应当怎样做需求分析[转]
又到新年了,日历又要从2011年翻到2012年了,这使我有太多的感慨,进而勾起了对太多往事的回忆.过去的10年,毫无疑问是中国软件业发展最快的10年.当我们刚刚毕业的时候,还在使用VB.PB开发一些简 ...

我们应当怎样做需求分析：非功能需求

我们应当怎样做需求分析：非功能需求相关推荐

最新文章

热门文章