2011年软考系统架构设计师学习笔记（43）

jasoncjx

为了更好的帮助大家考试，考试百科在文章系统架构设计师辅导：学习笔记中，为大家提供的如下内容：<br />　　14.2 系统构想<br />　　14.2.1 系统构想的定义<br />　　系统构想是开发人员与用户之间共同的协议。<br />　　按照该协议，开发人员需要在特定的时间内完成系统用户的需求，系统构想必须简短而切中要点。<br />　　高度概括了业务架构的核心内容。<br />　　14.2.2 架构师的作用<br />　　系统构想有助于各方明了系统的目标和范围。<br />　　确保系统开发的计划、设计等阶段能依次有序地展开。<br />　　系统构想阶段，架构师合理的介入，有以下好处：<br />　　1、有利于使系统架构师本身对系统的看法更加全面、准确。<br />　　2、统一系统开发人员对系统的看法。<br />　　3、正确确定需求的优先次序。<br />　　4、最大程度上提高客户对设计等过程的参与程度，更好地与客户沟通。<br />　　14.2.3 系统构想面临的挑战<br />　　架构师对其控制能力之外的因素通常无能为力，可以通过有效地评估，以及高级经理和架构师之间保持紧密的联系克服这些困难。<br />　　还必须面对以下几种情况：<br />　　1、很多架构师把架构看成是他们独自的创造，只要他们认为合适的就进行修改。<br />　　2、有些人不是拥有产品线构想的高级经理，却总是由这些人决定雇佣谁来做架构师。<br />　　14.3 需求分析 <br />　　14.3.1 架构师的工作<br />　　需求一般定义系统的外部行为和外观以及用户信息，而不用设计系统的内部结构。<br />　　对需求分析通常考察以下6个方面的内容：<br />　　1、系统范围对象关系图。<br />　　2、用户接口原型，用户操作的一个雏形。<br />　　3、需求的适用性，该用什么技术解决，性能怎么样，是否与其他需求相重合或矛盾，需求分析应注意需求本身的实用或适用，而不必考虑其实现。<br />　　4、确定需求的优先级。<br />　　5、为需求建立功能结构模型，组件图，实体数据对象图。<br />　　6、使用质量功能分配(Quality Function Deploymen，QFD)发现隐藏质量需求，建立相关质量场景，先期预测需求风险。<br />　　有效地捕捉行为需求的方法是分析用例(Use Case)<br />　　用例包含图和文字描述，符号 简单、抽象，保证表述需求时简单性和清晰度。<br />　　14.3.2 需求分析的任务<br />　　1、需求分析的目的<br />　　完整、准确地描述用户对系统的需求，跟踪用户需求的变化，准确地反映到系统架构和设计中，设计和用户的需求保持一致。<br />　　具有决策性、方向性、策略性的作用。<br />　　2、需求分析的特点<br />　　追求系统需求的完整性、一致性、验证性。<br />　　保持和用户要求同步，<br />　　保持需求分析各侧面之间的一致，<br />　　保持需求和系统设计间的同步。<br />　　14.3.3 需求文档与架构<br />　　每个用例都有一个相关需求的文字描述，定义用例应该和领域专家一起进行，如果没有领域专家的长期参与，只能是一种“伪分析”。<br />　　用例为定义架构提供了一个系统的领域行为模型。<br />　　界面的外观、功能、导航同用例紧密相连，有效定义屏幕的方法叫低保真度原型(Low-fidelity Prototyping)，领域专家也始终参与到屏幕定义中去。<br />　　需求分析的项目词汇表，也将在架构规划中被扩展。<br />上面就是文章系统架构设计师辅导：学习笔记的部分内容，后续文章请继续关注考试百科。http://pc.kaoshibaike.com 相关论坛：http://bbs.kaoshibaike.com/forum.php?mod=forumdisplay&amp;fid=78