需求分析当中的非功能需求

在进行产品开发时需求分析人员除了解决好客户的功能性需求之外，还应该关注那些非功能需求。中培教育《需求分析与管理最佳实践》培训专家郭老师表示，需求分析是一个非常广泛的概念，不同的行业（商业的、管理的、游戏的），不同类型的软件（底层的、桌面的、网络应用的），不同的设计方式（面向过程的、面向对象的），需求分析的过程都存在着巨大的差异。要制订放之四海而皆准的方法谈何容易。即使同一类型的软件，它们也存在着各自的特点，有的问题大多数软件都不用考虑，而它必须考虑。正因为如此，许多关于需求分析的方法和书籍描述得挺复杂的。
    郭老师认为，做需求分析应当化繁为简，不必去拘泥于那些过程。怎样化繁为简？寻找适合自己的，避免做过度分析和设计，这种思想也是敏捷开发的精髓。比如我所从事的管理软件的研发，关注业务流程、关注业务实体、关注规则约束，功能方面的需求就分析完成了大半。然后再关注查询报表、关注外部接口、关注打印导出等细小功能，功能方面就差不多了。
    郭老师进一步指出，需求分析人员最容易忽略的部分就是非功能需求。非功能需求更加靠近的是技术，是设计，是实现，是架构师关注的内容，是需求人员最不擅长的方面，这也是非功能需求为什么常常被忽略的重要原因。正因为如此，架构师应当尽早参与到项目中，参与到需求分析中，尽早分析需求的技术可行性，尽早考虑性能、安全性、可靠性等非功能需求，尽早开始架构设计。
    在非功能需求分析中另一个非常常见的错误，就是将非功能需求仅仅归结为一些放之四海而皆准的原则，比如专门拿出一章来描述报表查询效率要怎样、系统易用性要怎样。诚然，这些原则性的东西是十分必要的，但许多非功能需求不能仅仅停留在这些基本原则上，要落实到对一个一个功能的分析中。
    在前期的需求分析中，需求人员没有仔细分析这些操作的易用性，没有提供给用户批量选择等功能，直到试运行时才发现。这样会给项目带来了巨大的负面影响。如此看来，非功能需求对于一个软件项目是多么重要。因此，我建议，在需求分析的细化阶段，需求分析人员应当与架构师一起，一项一项地去分析每个功能的非功能需求，并在用例说明中记录下有特殊非功能需求的功能，使我们对非功能需求的分析落到实处。
    那么哪些是非功能需求呢？郭老师将其归纳为“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（）。而这部分我们可以进一步细化。
    可用性是一个非常宽泛的概念，它泛指那些能让用户顺利使用系统的指标，包括易用性（易操作、易理解）、准确性、安全性（权限体系、访问限制）、兼容性（服务器、客户端的兼容度），等等。
    可靠性就是系统可以可靠运行，包括系统成熟度（数据吞吐量、并发用户量、连续不停机性能等）、数据容错度、系统易恢复性，等等。
    性能，郭老师认为是需求分析阶段最主要的分析内容。用户对性能的要求没有止境，但现实却是残酷的。性能受到许多因素的影响，包括业务需求、软件设计、数据库设计、系统部署方式，等等。其中，业务需求和部署方式，对性能的影响是最大的，我们必须在需求分析阶段就想清楚，解决掉。

系统部署架构对性能的影响也是巨大的这一切都是系统架构师应当考量的内容。最后一个内容，也是最容易被忽略的一个内容，就是可支持性。可支持性，就是软件的可维护性、易变更性。可支持性对于客户是透明的，不可见的，因此客户通常不关心这个。由于时间紧、人员素质参差不齐，这部分也常常为管理者所忽略。但试问，谁没有维护糟糕系统的痛苦经历？谁们的系统维护了数年经过数次升级后还能维护？在需求分析与设计阶段，可支持性实际上体现在，我们是否能有效识别系统可变的需求，并能够提供合理的方案。这体现的也是架构师的功底。

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