TA的每日心情 | 开心 2021-10-13 13:59 |
---|
签到天数: 2 天 连续签到: 1 天 [LV.1]测试小兵
|
回复29#Anny.2008
Q1:需求规格说明书:如何有效的需求评审?(一般来说,评审的内容包括:规范性、正确性、必要性、可行性、无歧义性、完整性、可验收性、一致性、可追踪性及可用性。可否把您认为比较好的“需求评审检查单”在这提供一份,我将感激涕零!~~)
Q2:需求规格说明书中没有描述的需求,但却是客户实际需要的(在家闭门造车,无市场调研)。测试人员用什么方式收集这类需求?
Q3:需求总是不能固定?不固定就会引出问题,然后引出一系列的bug,如何更好的控制?我想很多人都有如此的困惑,可否详细列一下“需求变更的工作流程”?
你好,首先回答你的第二个问题吧,因为是收集需求方面的问题,你说的没有描述的需求却是实际中存在的,这类是属于隐性需求,常包括一些涉及到行业的基本规则流程;软件的基本操作与术语;目前中大家都在执行的好的设计风格与习惯等,如菜单功能布局的方式:常用的选项放前面,重要的次后,次要的选项在最后,且对其嵌套的层次一般不超过3级等。 这种类型的需求你首先得对该项目所属的业务领域及流程进行详细的了解,当然越详细越好了呵呵,如金融的,或电信的或是安防方面的等等,可以通过书籍,网络,朋友等方式来熟悉 2:熟成约定的软件技术(一些很基本的,共有的约定及操作习惯),可以看看国家软件行业规则方面的资料或是参考类似项目的一些共性方法与相关的约定 3:项目所属行业的法律法规也是其隐性需求之一,多了解下相关行业的法律法规了 4:客户认为是大家都知道的,对于这种类型的需求,解决方式就要与客户多沟通,把一些模糊的,有待确定的问题及时的达成一致。做好这几点的话我相信在隐性需求这块就会设计得很全面不会有太大的遗落了。
有了需求后如何有效评审呢,我觉得方法很多,其中最重要的是在评审前让大家都知道评审的范围,流程方式及所要达到结果,并且让大家有时间来熟悉自己所要评审的内容这样的话对评审的效果会有很大的帮助。在评审时很多情况下我们所要面对的都是一堆厚厚的需求文档,如果做为评审的组织者的话,我想他会在事先把些重要的,优先级高的需求发给相关的人员,接下来才会发一些级别低点的需求。当然在具本执行过程中会有很多的技功方法的如在评审的过程中是先以个人发言的形式或是以小组的形式等,其更多的组织方法你可查下相关需求评审流程方面的文档。至于相关的评审检查表,sorry,因为现在在外面,没有,只有等回去找找在给你了。
第三个问题:在项目中特别是前期需求变动的频率会比较大,我觉得这是正常的,只要在我们的控制接受范围。因为刚开始时客户可能自己都不知道真正想要什么,并且对所要的系统功能还不清楚,不明白, 而随着项目的不断进展,客户对系统的了解随之加深,这样的话就会不断的出现新的需求,或对原有需求的改动了。这是客户自身原因而引起需求变动的,当然就更不用说因沟通不到位而引起的需求变动了。 对于这种情况我觉得可以采用这几种方式来尽量减小因需求的变动而带来的相关影响,如,新的bug的出现,项目的延期等 。 1. 首先在开始时就让客户意识到需求的重要性,这样可预防或尽量减少客户的任意要求。2.在合同中就应有相关需求变动方面的约束,如需求的次数,提出的方式等 3. 建立独立的需求评审部门与需求变更控制流程,每次的需求变更都有相应的文档跟踪 4. 每次的变更后做好相应文档如use case, test case, test plan, 等的更新。 在这要重点说说需求变更的流程:客户提出需求更改的请求->由客户代表把需求变动的要求提交给需求评审部门-> 需求评审部门会做一个需求可行性,更改的风险性等全方面的一个评估报告->OK,接受的话会给客户一个同意更改的文档(当然如果不接受的话即应把拒绝理由,如更改后会增加资金的投入,项目的延期等 回复给客户,让客户来承担相关的责任并来做最终的决定),并且告诉客户新变动的需求会在哪个version,哪个时间点给提进去-> 最后就是做好相应文档的更新了。希望能对你有所帮助。 谢谢 |
|