需求分析与系统设计(二)阅读笔记

时间:2020-12-09 16:44:16

同样这本书也提到些关于uml“统一建模语言”,除了在上本书中的阅读笔记中所说的外,统一建模语言还是一种通用的、可视化的建模语言,用于对软件系统的人工制品进行详细说明、可视化、构造和文档化。它捕获对必须构建的系统的决策和理解,用于理解、设计、浏览、配置、维护和控制该系统的相关信息。它准备为所有的开发方法、生命周期阶段、应用领域和媒体所使用。另外关于uml本人也是抱有一份特殊的感情,在大二上学期,就学习了uml图的绘制和使用,在大三上学期王老师课上也相应使用和收获此方法。其语言结构允许为系统的静态结构和动态行为建模。系统被建模为一套合作的对象,这些对象响应外部事件来执行为客户带来利益的任务。特定的模型强调系统的某些方面,而忽略了其他模型中被强调的那些方面。集成在一起的一套模型提供了对系统的完整描述。

需求引导的传统方法,需求引导的传统方法包括面谈、调查表、观察和研究业务文档。这些都是简单的、符合成本效益的方法。但这些传统方法的效果与项目的风险程度是成反比的。高风险意味着系统难以实现,甚至高层的需求也非常不清楚。个人认为在这种项目中,这些传统的方法就不可能胜任。需求引导的现代方法书中提到的有软件原型法、头脑风暴、联合应用开发和快速应用开发。与之前讨论的其他方法比较,它们提供对需求更好的理解,但需要更大代价和更多努力。然而,长期的付出可能是值得的,现代的需求引导方法与传统的需求引导方法不同在于形式的多样,方法的有效性等,个人更看重现代需求引导的方法。

有感启示:观察对于业务分析员的重要性,有些情况下,业务分析员发现通过面谈和调查表很难获得彻底完整的信息。客户或者不能有效的表达信息,或者只有一个完整的业务过程中的片段知识。这种情况下,观察可能是有效的发现事实的技术。毕竟,学习如何系一条领带的最好方法就是观察系领带的过程。书中介绍三种观察的方式:被动观察、主动观察、解释观察,重点解说下解释观察,在工作过程中,用户向观察者说明他进行的活动。首先要使观察具有代表性,观察应该持续较长的一段时间,在不同的时间段上和不同的工作负荷下进行。个人认为:观察的主要困难在于,人们在被观察的情况下总想按照形式化的规则和过程去做。这样会由于隐藏了正面或负面的工作方法而歪曲了现实情况。另外,由于有些工作的性质需要处理敏感的个人信息和组织秘密,因此观察法也有道德隐私,甚至法律问题存在。

在课堂上,王老师教个我们:在面对用户时,最好选择拿一个小本,做好对用户谈话重点的记录工作,至于为何不采取录音等方法,上述已经阐明,若是在一个有录音的情况,用户便会变得畏首畏尾不再是之前的侃侃而谈,从而不能获得更加及时正确的信息,那肯定有人会说可以偷偷录音啊,方法不错,但若是让用户知道,他又会怎么像,总之多锻炼锻炼,练成一手速记的好本事,来日也不会吃亏。

书中读到关于“头脑风暴”的表述,课上老师也提起过,看来老师是真真正正一本一本的把这些书看完的,言归正传头脑风暴是通过放下公正、社会禁忌和规则来产生新思想或者发现专业问题解决方案的一种会议技术,课下老师让我们展开头脑风暴会议以方便项目的确定和完成。通常,头脑风暴不是为了分析问题或者做出决定,而是产生新思想或者可能的解决方案。之后的分析和做决定与头脑风暴技术无关。相比之前,调解人应之前,调头脑风暴需要一个人来主持会议,即调制人。在会议之前,调解人应当为将产生的新想法界定问题/机会领域,这被称为问题机会陈述。既然利益相关者对于具体需求总是需求是什么达成一致很困难,因此,头脑风暴在需求引导中非常有用。更甚者,利益相关者总是对需求有狭隘的观点,而头脑风暴能够帮助启发它们多一点创意。