软件需求工程课程总结

       依稀还记得这堂课起始于中秋假期前的那个下暴雨的周三夜晚，不知不觉中一个学期的软件需求工程课程就这样结束了，感谢刘老师一学期以来的指导和帮助，丰富的课堂形式给了我很多的启发。以下正文部分是关于本课程的小结：

 

Topic 1：SystematicLiterature Review

       本次的SLR作业老师希望我们能针对自己感兴趣的主题进行调研，由于所在的实验室可能会涉及一些新硬件的研究，我从ACM数据库里以“Storage Class Memory”为关键词搜索到了一篇2016年发表在SIGMOD会议上的文章，按照要求，填充了以下的表格信息：

 

Research Paper Title	FPTree: A Hybrid SCM-DRAM Persistent and Concurrent B-Tree for Storage Class Memory
Database	ACM
Journal / Conference Name	SIGMOD
Date of Publication	2016
Keywords used for retrieving	Storage Class Memory
Paper Methodology Used	Experiment

 

        但是，如果需要更精确地搜索确定主题范围内的文章可能需要提供更多的关键词，一个关键词通常是不够充分的，这在以后的文献检索中需要注意。

这篇文章的背景是近些年出现了一种新的硬件技术，称为“存储类内存（Storage Class Memory）”，简称SCM，它的出现使得人们重新思考原先被隔离开的内存-硬盘的存储结构，SCM结合了传统存储介质经济、容量大、非易失的特点和 DRAM 低延迟、可字节访问的特点，在未来可能SCM会取代DRAM作为一个统一的内存，即同时作为主存和存储器，但是现有的数据结构还不能很好地支持它满足这些需求。

        文章所做的工作目的是希望改进传统的应用在主存的B-Tree索引结构，因为作者认为传统的索引技术没能满足新硬件特性下的一致性要求，例如对比于DRAM，SCM的延迟更高，写速度比读速度慢很多，除此之外，设计持久化的数据结构、保证数据一致性很难，因为SCM是通过易失的CPU cache进行访问的，软件对于此的控制力很小。简而言之，如果需要更好的性能，就需要设计更适合的数据结构，于是作者设计了FPTree索引，希望可以达到能够相当于DRAM的性能，同时解决一些关于持久化内存泄漏和数据恢复的问题。

        虽然目前已有一些关于在SCM上设计B-tree结构的相关工作，例如CDDS B-Tree , the wBTree , the NV-Tree ，但这些工作普遍存在的问题是：与优化的DRAM中B树的访问速度相差甚远，还存在许多包括数据一致性、持久化内存泄漏、数据恢复和部分写的问题。

   

Summery of paper

       文章介绍了FPTree的详细结构和具体的操作，可以保证从任意点的故障恢复到一个一致性的状态而不丢失信息，除此之外FPTree的访问速度能够与DRAM相当，对不同的SCM设备的延迟有很好的弹性，同时也能支持高并发的场景。

 

Topic 2：Game about PotentialThreat

       课堂上我们做了两次关于potentialthreat的游戏，由于写这篇博客的时候距离当时有点时间了，我有点遗忘了，大致记得是给定了我们一些要攻击的对象和一些攻击方法，我们可以知晓这些被攻击对象的攻击价值和他的弱点，针对每个人不同的弱点采取针对性的方式进行攻击，这些攻击方式可以是物理攻击、社会攻击和网络攻击。

       我记得当时课上的一个例子是，在一间公共办公室里有一个想换工作的实习生和一个被财务人员遗失在此处的存有重要数据的U盘，如果想要以此场景为攻击对象获得这个U盘，首先要想办法支开这个实习生，既然他很想换工作，攻击者就可以利用这个心理伪造一封类似可以提供更好待遇的工作机会，急需面谈这样的邮件诱惑实习生离开办公室，攻击团队里的其他攻击者可以伪装成公司内部的人员趁机潜入并取得这个U盘，完成攻击。

       游戏虽然简单，但是还是有所启发的，每个人都有自己的心理弱点，你永远不能想到攻击者会针对你设计出什么样的攻击场景，让你不知不觉落入圈套，近些年盛行的电信诈骗让人防不胜防，我们还是应该时刻保持着警惕性，尽可能地防止落入攻击者的圈套。

 

Topic 3：Goal-orientedRequirements Engineering Methods --- KAOS

       使用了KAOS进行目标建模，考虑的问题的场景大致是：目前，许多小区的物业管理等工作仍停留在传统的手工操作，诸如打印、分发水电费缴费单等工作需要耗费大量的人力、物力和财力，重复工作较多、工作效率低下，智慧社区系统作为一种先进的管理平台与管理手段，可以减少传统物业管理中的手工劳动，提高物业管理系统员工工作的效率，降低物业公司的运营成本，从而获取更大经济效益，使企业在行业中保持竞争优势。

       系统的目标应该是：功能上应当满足物业管理的基本要求，例如物业管理费的计算、通知和收取，还可以增添额外的信息化服务功能；同时还需要保证智慧社区系统是安全可靠的，保障业主的信息不泄露；智慧社区系统需要提供对用户友好的界面，操作简单，响应时间在合理范围之内；另外，开发和后期维护智慧社区系统的成本也必须尽可能的减少。

       下图是系统的一个整体的目标模型图：

 

 

        责任模型方面需要考虑系统涉及的各个角色需要承担的责任，例如：

        智慧社区系统开发商需要：1、提供信息录入的接口；2、提供计算物业管理费的接口；3、提供发送通知和查看通知的接口；4、提供缴费的接口；5、提供系统使用说明；6、保障系统安全；7、保障系统故障恢复；

        物业管理人员需要：1、及时录入相关信息；2、系统计算出物业管理费用之后确认并发送通知给业主；

智慧社区系统需要：1、能够检测到操作请求；2、能够识别登录用户权限等级；3、能够对操作结果给出友好的提示；4、能够执行合理的操作请求

        下图是系统的责任模型之一：

 

 

系统中可能涉及的对象及其说明如下：

1、电表：指业主住房关联的电表，或业主住房所在楼层关联的电表，记录了关联范围内的用电量情况，是计算物业管理费的所需数据之一。

2、楼层：指业主住房所在的楼层，可作为相关查看功能的筛选条件。

3、楼栋：指业主住房所在的楼栋，可作为相关查看功能的筛选条件。

4、社区：指业主住房所在的社区，可作为相关查看功能的筛选条件。

5、水表：指业主住房关联的水表，记录了关联范围内的用水量情况，是计算物业管理费的所需数据之一。

6、停车位：指业主拥有的社区内的停车位，社区需要向业主按停车位的数量收取车位管理费，是计算物业管理费的所需数据之一。

7、业主：指社区内房产的合法所有人（以户为单位）。

8、住房：指业主所拥有的社区内的房产。

下图是一开始有些错误的和经过批改修正后的系统的对象模型之一：

 

 

模拟物业管理人员点击计算物业管理费的过程涉及大致如下：

操作：点击计算物业管理费

输入：日期范围、业主范围、社区基本信息、水电表示数信息

输出：

1、计算成功，得到应缴费用列表，确认结果后向业主发送缴费通知，业主收到缴费通知

2、计算失败，系统提示相应的失败提示信息

下图是模拟物业管理人员点击计算物业管理费的过程模型：

下图是系统存在的潜在障碍之一：

 

 

Topic 4：Change managementand Requirements Traceability

       在这个模块简单谈谈自己关于需求变更管理和需求跟踪的一些思考：

       虽然大家都知道需求变更会带来很多不利的后果，但它的确是不可避免的，为了使其对项目的影响降低到最小，需要在整个项目的生命周期中进行综合的变更控制管理。

例如在项目启动的需求分析阶段，必须尽可能地在需求文档中清晰地定义需求的范围，这样在双方签字之后，若客户后期还需要提出超出合同范围的需求变更就必须另外收费，这样可以防止客户在前期不重视配合需求分析，而在后期经常变更需求，实际上有利于双方的合作。

       在项目的实施阶段，要评估变更可能带来的风险，必须执行正规的需求变更管理流程，正规的需求变更管理流程大致包括：识别变更，评估变更对项目的影响，设计变更的备选方案，提出变更申请，项目管理人员及相关人员批准或否决变更，追溯变更的实施情况等。即使是很小的需求变更也不能因为认为这个过程浪费时间，降低了开发效率而不去执行正规的需求变更管理流程，否则可能会导致需求变更的历史无法追溯，如此积少成多，使得需求逐渐变为不可控，最终可能导致项目失败，同时可能并没有认真评估客户的变更需求是否合理，进一步影响项目进度和质量；另外，任何的需求变更仍然要和成本投入挂钩，要让客户建立对需求变更是有成本的概念，从而能够慎重地对待需求变更。

        然而，一切的规则执行起来还是靠人，规则是明确的，但如何执行却是有很多可能，能否自觉地严格按照规定执行需求变更管理会最终影响到项目整体的进度和质量，但是繁琐的变更流程也的确会对项目的开发效率造成一定的影响，如何权衡还需要根据实际情况考虑。

        以上只是我的一些简单思考，由于本人还只是个学生，没有丰富的实际工程经验，可能存在不准确的地方，还希望读者可以指正。