blackcat123的博客

假定技术能力和管理水平均分为两个段位：高和低。那么只需解答一个问题就可以判断出团队所属的段位：项目是否大规模应用UML？？如果答案为是，那么团队属于高段位，否则属于低段位。UML，是统一建模语言的缩写，是面相对象软件开发的最基本的技术方法。通常将UML应用于需求分析与系统设计。谈谈为什么UML与技术能力有关。如果技术人员，包括产品经理、需求分析师、架构师、技术经理、程序员，不会使用UML，会显得很外行。技术人员是一定有段位差距的。段位高的是预防问题。而段位低的是制造问题，且陷入“制造——修复——制造——修复

程序员的思维优势是善于把控细节。程序员在了解到需求后会立即思考技术实现的方法，并立马找出需求存在的缺陷，把问题扼杀在摇篮里。可能是程序员性格原因，还可能是因为程序员经过长期的项目实战训练，变得越来越对细节敏感，形成了思维惯性。毕竟计算机本身就是高精度的，如果错了一个符号，很可能全部报废，就像Windows蓝屏那样。然而没有编程工作经历的产品经理（需求分析师）在细节把控方面明显弱一些。细节肯定是很重要的，假设要开发一个导弹发射系统。如果你的程序有一点点出错，哪怕是错了一个符号，那么你发射出去的导弹势必不会击中

工作成果（部分），UML、原型设计、产品设计、思维导图、visio、axure、需求分析、专利

部分章节还读了两三遍。个人认为这本书应当作为产品经理的入门书籍。大学软件专业也应当开设相关课程，就定名为“需求工程”，将此书作为教材。可以说，此书是关于需求的百科全书，能让你了解到各方各面。并且学习门槛低，不需要太多预备知识，也不需要多么强的逻辑思维能力和抽象思维能力。作为入门书籍太合适了。不过呢，深度肯定是远远不够的，单独把建模拎出来就够你喝一大壶了。建模三大支柱：建模语言、建模方法、建模工具。想建模的，我强烈推荐 Enterprise Architect。此工具很牛，还支持需求开发和需求管理。

这方面也是有不少书籍的，譬如 《系统工程原理与实践》《基于模型的系统工程有效方法》《系统工程中的实践创造与创新》《系统工程方法论 —— 从TBSE进阶到MBSE》《系统工程：分析、设计与开发》。另外需要补充的是，如果产品经理的工作涉及到硬件，那么恐怕还需要学习SysML（系统建模语言），它是针对系统工程的建模语言。然而事实是，这样的投资，它的回报率是很高的，甚至能达到百倍以上。回到软件开发的正题，产品经理除了学习UML外，还有必要掌握其它的和需求有关的建模方法，例如 数据流图、判定树、判定表、鱼骨图。

需求管理包括项目过程中所有保持需求协议的完整性、准确性和流通性的活动。图显示了需求管理的四大核心活动:版本控制、变更控制、需求状态跟踪和需求跟踪。可以将所有这些信息包含在一个需求管理过程描述中。或者，写单独的版本控制、变更控制、影响分析和状态跟踪过程。这些过程适用于整个组织，因。组织要定义项目团队需要执行的需求管理活动。将这些活动记录下来并进行培训，确保组织成员一致而有效地执行这些活动。

有效的需求过程强调的是协同开发产品，并在整个项目过程中将干系人视为合作伙伴。通过需求获取活动，开发团队可以更好地了解用户或市场，这是成功的一个关键要素。如果团队强调的是用户任务，而不是局限于一些“浮华”的特性，就不会出现代码写出来却没人用的情况。最终你会了解客户的想法，相对于在开发产品之前而不是交付之后再意识到问题，付出的代价要小得多。这种论点认为，花在需求活动上的投资不会有回报。要得到更优准的需求，需要的成本包括开发新程序和文档模板、培训团队和购买工具。最大的投资是项目团队花在需求工程任务上的实际时间。

用户对该原型进行评估，直接向设计者提供有关界面功效的建议，如采用正式的评估技术(比如使用提问单、分级评分表)，这样设计者就能从调查结果中得到需要的信息(比如80%的用户不喜欢其中保存数据文件的机制);评估可以从非正式的“测试驱动”(比如用户可以临时提供一些反馈)到正式的设计研究(比如向一定数量的最终用户发放评估问题表，采用统计学的方法进行评估)。在标准时间间隔内正确完成任务的数量、使用动作的频度、动作顺序、观看屏幕的时间、出。错的数目、错误的类型、错误恢复时间、使用帮助的时间、标准时间段内查看帮助的次数。

例如，邮件列表被用于存放邮件的名字，该列表本身可以进行排序、合并或清除(基于菜单的动作)，但是，它不会通过用户的交互被拖动和删除。不幸的是，许多设计人员往往很晚才注意到这些问题(有时在操作原型已经建立起来后才发现有问题)，这往往会导致不必要的反复、项目拖延及用户的挫折感，最好的办法是在设计的初期就将这些作为设计问题加以考虑，因为此时修改比较容易，代价也低。这些方针解决了宽度设计问题(例如，在不同的市场情况下屏幕布局可能是不同的)，以及离散实现问题(例如，不同的字母表可能生成特定的标识和间距需求)。

在某些应用中，计算机系统的用户界面被放在“用户友好”的位置(例如，合适的亮度、良好的显示高度、简单方便的键盘操作)，但有些地方(例如，工厂的地板和飞机座舱)亮度可能不是很适合，噪音也可能是个问题，也许不能选择使用键盘、鼠标或触摸屏，显示方位也不甚理想。我非常关心射入房间的光线，关心窗外的风景(如果它很漂亮，就会吸引我的注意力)，关心无障碍墙的长度，关心房间内活动空间的通道大小。如果选择编辑，就可以移动传感器和摄像机，添加新的或删除已有的传感器和摄像机，编辑平面图并编辑摄像机和传感器的设置。

用户的心理模型(系统感觉)是最终用户在脑海里对系统产生的印象，例如，请某个餐厅评级移动App的用户来描述其操作，那么系统感觉将会引导用户的回答，准确的回答取决于用户的经验(新手只能做简要的回答)和用户对应用领域软件的熟悉程度。实现模型组合了计算机系统的外在表现(界面的观感)，结合了所有用来描述系统语法和语义的支撑信息(书、手册、录像带、帮助文件)。为了将这些模型融合起来，所开发的设计模型必须包含用户模型中的一些信息，实现模型必须准确地反映界面的语法和语义信息。对新系统的一般感悟，并定义不同的用户类别。

一个经过精心设计的用户界面不会加重用户的记忆负担，因为用户必须记住的东西越多，和系统交互时出错的可能性也就越大。可用性好的系统带来的诸多好处在于[Don99]:提高销售量和用户满意度、具有竞争优势、在媒体中获得良好的评价、获得良好的口碑、降低支持成本、提升最终用户生产力、降低培训费用、减少文档开销、减少来自不满意用户的投诉。Constantine指出，系统的可用性并非取决于设计美学、交互技术的发展水平或者内置的界面智能等方面，而是当界面的架构适合于将要使用这些界面的用户的需求时，才能获得可用性。

可用性是指用户在使用高科技产品所提供的功能和特性时，对使用的容易程度和有效程度的定量测量。计和位置、描述性屏幕文本的定义、窗口的规格说明和命名，以及主要的和次要的菜单项规格说明。不管软件展示了什么样的计算能力、发布了什么样的内容及提供了什么样的功能，如果软件不方便使用、常导致用户犯错或者不利于完成目标，你是不会喜欢这个软件的。遵循一系列的界面设计原则，定义界面对象和界面动作，然后创建构成用户界面原型基础的屏幕布局。原型的开发是通过用户测试驱动的，测试驱动的反馈将用于原型的下一次迭代修改。

需求检测中的冲突通常是目标自身存在冲突的结果。完全确定需要什么的情况下，包括:对其计算环境的能力和限制所知甚少，对问题域没有完整的认识，与系统工程师在沟通上存在问题，忽略了那些他们认为是“明显的”信息，确定的需求和其他客户及用户的要求相冲突，需求说明有歧义或不可测试。确认需求的评审小组包括软件工程师、客户、用户和其他利益相关者，他们检查系统规格说明，查容或解释上的错误，以及可能需要进一步澄清的地方、丢失的信息、不一致性(这是建造大型产品或系统时遇到的主要问题)、冲突的需求或是不可实现的(不能达到的)需求。

这些问题中的每一个都是极富挑战性的，当这些问题集中在一起时，即使是最有经验的管理人员和实际工作人员也会感到头痛。在RalphYoung[You01]的一本关于有效需求实践的书的前言中，写道:这是最恐怖的噩梦:一个客户走进你的办公室，坐下，正视着你，然后说:“我知道你认为你理解我说的是什么，但你并不理解的是，我所说的并不是我想要的。在设计和开发某个优秀的计算机软件时，如果软件解决的问题是错误的，那么即使软件再精巧也满足不了任何人的要求。利益相关者评审需求工程的工作产品，以确保你所理解的正是他们真正想要的。

以用途为核心的策略强调的是对用户目标的理解和探求，以便提取必要的系统功能。从实际角度来看，需求开发的目标是大家对“足够好”的需求达成共识后，着手产品开发的下一步一不管是整个产品的1%还是100%一而风险在可控范围之内。规划出多周期的需求探究活动，我们要逐步优化概要需求，使其进一步准确和细化，并与用户共同确认得出正确的需求。需求管理的目标不是抑制变更或加大其难度，而是为了预测和协调不可避免且实际存在的变更，最终最小化变更对项目的破坏性影响。找出需求中的遗漏的或多余的、不必要的需求，以便定义范围。

描述该产品与其他软件组件(由名称和版本来标识)之间的关联，包括其他应用程序、数据库、操作系统、工具、库、网站和集成的商业组件;如果你的组织要处理各种类型或规模的项目，例如新的大型系统开发或是对现有系统进行微调，就要针对项目的主要类别来选择一个软件需求规范说明模板。如果软件需求规范说明定义了大型系统的一个组成部分,那么就要说明该软件是如何与整个系统相关联的，并且要确定两者之间的主要接口。对用户类的描述是一种可再利用的资源。图中的模板显示的是由系统特性所组织的功能需求，而这只是众多组织方式中的一种。

但是,这种非形式化的规格说明书是难于验证的,特别在目标系统规模庞大、规格说明书篇幅很长的时候,人工审查的效果是没有保证的,冗余、遗漏和不一致等问题可能没被发现而继续保留下来,以致软件开发工作不能在正确的基础上顺利进行。一旦用PSL对系统做了完整描述,就可以调用PSA产生一组分析报告,其中包括所有修改规格说明数据库的记录,用各种形式描述数据库信息的参照报告(包括图形形式的描述),关于项目管理信息的总结报告,以及评价数据库特性的分析报告。(4) 有效性必须证明需求是正确有效的,确实能解决用户面对的问题。

加信息主要有系统名称、图的作者,完成的日期,本图描述的模块的名字,模块在层次图中的编号,调用本模块的模块清单,本模块调用的模块的清单,注释,以及本模块使用的局部数据元素等。它的基本形式是在左边的框中列出有关的输入数据,在中间的框内列出主要的处理,在右边的框内列出产生的输出数据。树形结构的顶层是一个单独的矩形框,它代表完整的数据结构,下面的各层矩形框代表这个数据的子集,最底层的各个框代表组成这个数据的实际数据元素(不能再分割的元素)。图是用Warnier图描绘一类软件产品的例子,它说明了这种图形工具的用法。

状态转换图(简称为状态图)通过描绘系统的状态及引起系统状态转换的事件,来表示系统的行为。在活动表中经常使用下述3种标准事件:cntry, exit 和do.entry事件指定进人该状态的动作,exit事件指定退出该状态的动作,而do事件则指定在该状态下的动作。事件是在某个特定时刻发生的事情,它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。状态规定了系统对事件的响应方式。系统对事件的响应,既可以是做一个(或一系列)动作, 也可以是仅仅改变系统本身的状态,还可以是既改变状态又做动作。

第二,随着范式级别的提高,数据的存储结构与基于问题域的结构间的匹配程度也随之下降,因此,在需求变化时数据的稳定性较差。(3) 第三范式 符合第二范式的条件,每个非关键字属性都仅由关键字决定,而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述(即一个非关键字属性值不依赖于另一个非关键字属性值)。软件系统经常使用各种长期保存的信息,这些信息通常以一定方式组织并存储在数据库或文件中,为减少数据冗余,避免出现插人异常或删除异常,简化修改数据的过程,通常需要把数据结构规范化。

数据对象可以是外部实体(例如,产生或使用信息的任何事物)、事物(例如,报表)、行为(例如,打电话)、事件(例如,响警报)、角色(例如,教师、学生)、单位(例如,会计科)、地点(例如,仓库)或结构(例如,文件)等。此外, ER模型使用简单的图形符号表达系统分析员对问题域的理解,不熟悉计算机技术的用户也能理解它, 因此, ER模型可以作为用户与分析员之间有效的交流工具。数据对象彼此间是有关联的,例如,教师“教”课程,学生“学”课程,教或学的关系表示教师和课程或学生和课程之间的一种特定的连接。

为了开发出复杂的软件系统,系统分析员应该从不同角度抽象出目标系统的特性,使用精确的表示方法构造系统的模型,验证模型是否满足用户对目标系统的需求,并在设计过程中逐渐把和实现有关的细节加进模型中,直至最终用程序实现模型。通常用自然语言完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。前面讲过的数据流图,描绘当数据在软件系统中移动时被变换的逻辑过程,指明系统具有的变换数据的功能,因此,数据流图是建立功能模型的基础。

为了解决这些问题，往往需要向用户和其他有关人员请教，他们的回答使分析员对目标系统的认识更深入更具体了，系统中更多的数据元素被划分出来了，更多的算法被搞清楚了。对这组新数据流图的分析追踪可能产生新的问题,这些问题的答案可能又在数据字典中增加一些新条目,并且可能导致新的或精化的算法描述。首先进行初步的访谈,通过用户对基本问题的回答,初步确定待解决的问题的范围和解决方案。需求分析的目标是获知用户的真实需求，而这一信息的唯一来源是用户，因此，让用户起积极主动的作用对需求分析工作获得成功是至关重要的。

分析员知道怎样用软件实现人们的需求，但是在需求分析开始时他们对用户的需求并不十分清楚，必须通过与用户沟通获取用户对软件的需求。虽然在可行性研究阶段已经粗略地了解了用户的需求，甚至还提出了一些可行的方案，但是，可行性研究的基本目的是用较小的成本在较短的时间内确定是否存在可行的解法，因此许多细节被忽略了。需求分析和规格说明是一项十分艰巨复杂的工作。对软件需求的深入理解是软件开发工作获得成功的前提条件，不论人们把设计和编码工作做得如何出色，不能真正满足用户需求的程序只会令用户失望，给开发者带来烦恼。

几张自己绘制的UML图。全部来源于公司项目，使用建模工具 Enterprise Architect。自己做的其余文档（含绘图），因保密协议不便于公开。

来自真实的商业项目实战，使用Enterprise Architect、UML类图、活动图

如果是 2 个公司之间的供求关系，请将需求文档化。如果是 2 个部门之间的供求关系，请将需求文档化......

如果需求出了问题，最大的恶果就是返工——重复以为已经完成的工作——尤其是在开发末期或者发布之后。返工通常会占到开发总成本的30%~50%，而需求错误占返工成本的70%~85%。