要给一个名词下定义,是一件很严肃和严谨的事情,因此,要给出需求工程准确的定义是不太现实的。本书从方法论推进和实施的角度出发,提出了本书对需求工程的理解和定义。需求工程是面向业务全局、系统顶层的一种着眼于软件过程全过程的工程,是将客户业务作为内部研究对象、将软件工程实施作为外部研究对象的工程。之后,书中提到的需求工程即以此定义为准。......
2023-11-17
快速而不完美的建模在我们的方法论中作为一种贯彻思想,通过快速为过程建模来理解当前的工作,并与客户达成一致意见。绝大多数客户很赞成并适应这种模型的动态特性,因为这种方式可以让客户提前看到业务最终执行的大致情况。
快速而不完美的过程模型模拟了当前的情况,当然也可以对将来的过程建模。在方法论的实施中,主要使用白板、原型工具(这里推荐使用mockplus),方法论的承载工具也都基于这两项工具的开发。
白板建模针对过程中的每个活动,建立过程模型。你可以将任何内容,任何对象画在白板上,然后将它们画线连接,你的办公室或者会议室墙壁可以采用白板涂料,如图2-4所示,或白板挂板,以便随时满足你的想法。
图2-4 白板建模
使用白板对业务过程建模,一个明显的优势就是方便擦除,便于讨论和修改调整,方便RA人员(参见附录C)和客户共同参与建模过程。例如,一个活动连线不对,可以很快擦除或使用另外一种颜色标注或代替;如果位置不对,那就重新画一个。其实当RA和客户在进行业务碰撞的时候,发现有些业务是可以简化的,或者发现有些业务之间改条连线会更加高效。这些都有益于我们寻找系统的本质并对工作方式的优化产生影响。
白板对于我们快速地理解业务提供了便捷且有效的途径,原型工具则在一定程度上深入了低层次的细节,从而能够更加有效地锁定需求。使用原型工具的基本思路是用草图或原型勾画建立的项目(或产品),然后逆向工程,印证需求或导出需求。特别针对下列情况,这是更加有效的方法。
(1)项目(或产品)以前不存在,很难想象。
(2)项目(或产品)的用户对这种项目(或产品)或建议的技术没有经验。
(3)客户之前做了一段时间的工作,但卡住了。(www.chuimin.cn)
(4)客户很难说出他们的需求。
(5)RA很难理解需求是什么。
(6)项目(或产品)的可行性存在疑问。
在收集需求时,如果让客户想象,他们需要将来的项目(或产品)做什么。其结果往往受限于客户的想象力和经验,以及他们描述目前不存在的事物的能力。
与之相对的是,原型为客户提供了一些真实的东西,或者至少是可查看的信息。原型让客户感到项目(或产品)足够真实,从而提出其他可能遗漏的需求。在一定程度上我们可以说“原型就是需求诱饵”:当客户看到原型所展示的功能时,他们会想到一些其他需求。当然,原型也可以用于演示需求的后果。在项目中我们不可避免地会遇到一些特殊的需求,它们只有唯一的一个提请者,他可能会说没有了这项需求工作就无法顺利开展,但是又没有合理的依据和支撑,无法有效地判定他的需求是一个使产品更好的想法,抑或只是完成一件不必做的事情的复杂方法?原型就可以弄清楚,所以对难以彻底了解的需求构建了一个原型后,这些需求就可以变得可见,也使得每个人都有机会去理解它们,讨论它们,然后决定它们是否有价值,是否应该留在最终的项目(或产品)中。可能的原型界面如图2-5所示。
图2-5 原型界面
简单来说,你将项目(或产品)的原型(可能是几种可选模型)展示给客户来看,并询问他们,使用像这个原型的项目(或产品)是否能完成他们的工作。如果回答是“是”,那么就可以确定该原型版本所展示的需求;如果回答是“否”,那么就应该根据客户的建议和你的分析更改原型后再询问。通过原型你可以展示客户的工作,检验其是否合理地展示了关键的建议或要求,从而明确他们对自己工作的看法是否与你一致。而且,从这些观点上不同的要求你可以发现,你所面对的客户在工作中最看重哪些方面,他们如何看待自己的工作。而且对于即将要做出较大创新或调整的业务部分,你要进行适当的引导,让他们在一定程度上能够比较快地适应新的工作方式,这对于很多RA来讲不是一件容易的事情,但这是我们与用户世界有真实联系的首次接触,对于接下来的工作影响深远。
有关软件需求工程的文章
要给一个名词下定义,是一件很严肃和严谨的事情,因此,要给出需求工程准确的定义是不太现实的。本书从方法论推进和实施的角度出发,提出了本书对需求工程的理解和定义。需求工程是面向业务全局、系统顶层的一种着眼于软件过程全过程的工程,是将客户业务作为内部研究对象、将软件工程实施作为外部研究对象的工程。之后,书中提到的需求工程即以此定义为准。......
2023-11-17
需求工程的过程分为需求准备、需求获取、业务建模、系统建模等阶段,中间各环节通过关联规则体系串接起来以达到跟踪监控整体需求工程进度的目的。......
2023-11-17
在方法论中原型界面就是原型,并不代表系统的最终实现,可以使用草图来表示。图3-18审核薪资原型界面同时配合原型界面的使用以及为设计人员提供关键元素,每个原型界面都有对应的用例脚本展示,主要以边界类、业务类及实体类的划分为依据,按照MVC的主要思想将设计的关键要素表达出来。......
2023-11-17
业务目标又称为业务前景,是对要建设的系统的展望。业务目标非常重要,在定义边界一章中会看到,边界正是基于业务目标来定义的。投资构建系统的原因,以及这样做利益相关者会从业务中得到什么,这些都可帮助确定业务目标。业务目标不仅仅是要解决问题,还要提供业务上的效益。业务目标大部分情况下是由客户提出,当然也可以由开发方整理得出。在初步了解业务目标以后,接下来的工作就是找出项目范围内的利益相关者。......
2023-11-17
为了真正理解客户的需求并给出满足这些需求的解决方案,必须理解真实世界中的问题。这些工作包括业务背景调查、业务前景分析、业务可行性分析、技术可行性分析等。在统一过程中,以上内容汇集到被称为《前景》的文档中。业务前景和客户期望所描述的内容与UML分析技术关系密切,严格来说,这些正是UML分析的开始。这几部分基本囊括了薪酬管理系统的主要业务范围,读者可稍作了解。......
2023-11-17
图3-4薪酬表表头图3-5薪酬业务对象在上述业务对象的获取中,首先将薪酬表转换为业务对象,当然RA人员在获取原始表的同时,需要初步了解表内元素的基本含义,在转换为业务对象时,在相应的备注信息栏中予以说明。......
2023-11-17
业务用例视图是表达客户业务执行的静态视图,是实现某关联业务目标的具体体现。业务用例可以从需求调研收集的岗位手册、业务流程指南、职务说明中获得,也可以从涉众期望中获取,当然与客户的会议、访谈及其他形式的沟通都是获取业务用例的方法。当然在2.2.2节提及获取业务用例的时候,要时刻记着业务用例的完整性,避免将步骤作为用例,业务用例是一项完整业务汇集的过程。......
2023-11-17
相关推荐