NFR

你NFR了吗？

NFR，即非功能性需求 (Non -Functional Requirements) ，即系统能够完成所期望的工作的性能与质量。具体包括如下内容：

– 效率： 软件实现其功能所需要的计算机资源大小，“时间 -空间”；
– 可用性： 用户使软件的容易程度，和学习；
– 可维护性： 软件适应“变化”的能力，系统很容易被修改从而新需求 或采用新的算法、数据结构能力；
– 可移植性： 软件不经修改或稍加就可以运行于同硬环境 (CPU 、 OS 和编译器 )的能力；
– 清晰性： 易读、理解，可以提高团队开发效率降低维护代价；
– 安全性： 在对合法用户提供服务的同时，阻止未授权使；
– 兼容性： 不同产品相互交换信息的能力；
– 经济性： 开发成本、时间和对市场的适应能力。
– 商业质量： 上市时间、成本 /受益、目标市场与老系统的集成生命周期 长短等。

软件工程课程上到这里，软工大项目我也完成的差不多了。至此，我想就软工开发经验，来谈谈NFR中的几点。

首先，我们来看看可用性。我们开发的项目是国际合作处系统，显而易见这个工程是面向对象的，而不是面向过程的。因此，可用性至关重。设想用户要看新闻，他们怀着愉快的心情打开我们的网站，然而，他们在我们的网站中迷失了。。。逛了半个小时，网站给他们的印象就是根本不知道在干嘛，甚至怎么找到新闻都是问题。这样的网站无疑是失败的。网站要易于让用户学习，不管是看新闻的“吃瓜群众”还是国际合作处秘书。

其次，我们来看可维护性。这当然是对我这种“程序员”来说的。毕竟网站是我开发的，维护工作当然得我来做。有谁能比我更了解我开发的网站呢？但是哦，实际公司运营过程中并不是这样的。在公司运营中，开发者与运营者是分开的。因此，开发者要留有足够多的说明文档给维护者。开发者最好能够将程序封装成模块，这样系统除了bug，维护人员可以根据模块尽快找到bug， 并且在模块中应用对应的技术攻克bug，完成debug。

我们接着看可移植性。系统最好可以封装成模块，这样的话就可以有较好的可移植性。比如我们的软工项目如果在本地，就会部署到tomcat上，然后运行。但是，这个项目也可以export成一个包，然后这个包就能够部署到新浪云、阿里云、腾讯云等网络平台上，可以让更多的用户使用。当然，可移植性远不止web项目的可移植，还包括更多的用户程序、系统程序在不同操作系统、运行环境下的可移植性。

系统的安全性，这是一个亘古不变的难题。自从有了计算机，就有了破坏计算机的人；自从有了互联网，就有了破坏互联网规则的人。阴阳守恒，相克相生。我们无法避免网络攻击，因此我们只能魔高一尺，道高三尺。这学期学了软件安全这门课，很有用。余教授讲了许多互联网攻击的手法和实例，并讲了如何识别互联网攻击（识别算法）、如何规避预防互联网攻击。在软工项目中，也会有很多“不配合的用户”。比如，他就用汇编的知识，打开我们网络应用的时候给我们来一个缓冲区攻击破了密码，或者不好好访问我们的web， 而是给我们搞一些僵尸网络等等。作为网站的开发者和维护者，这个软工项目是我的“亲儿子”，我怎么能够容许这种事情肆意发生呢？不可以!因此，我得增加我的网络应用的健壮性（robust）！

最后我们来看看商业质量。根据大王的要求，我们的软工项目是要有真实用户的，真实用户使用web，给反馈，我们接着改。因此，我打算将我们的“上市时间”提早到14周周三，提前一周上市，然后拉用户过来体验，给建议，改，改，改。我们的目标市场首先是哈工大国际合作处秘书，其次是来访学者，工大交流生，出访教授等等。