系统分析与设计概述：4 需求建模

第二阶段系统分析

需求建模CollegeofComputerScienceandTechnologyZhejiangUniversity阶段概述本阶段是SDLC五个阶段中的第2个阶段在上一阶段，系统规划阶段，分析员已经做了初步的调查，了解了更多的系统需求，并从技术、经济、社会和文化、进度、资源等方面，确定了项目需求的合理性和可行性本阶段，分析员将使用需求建模、数据和过程建模及对象建模来描述新系统在进入到下一阶段前，还需要考虑系统开发策略需求建模在需求建模的工作环节，需要采用基于团队的方法收集系统项目事实，准备文档以及创建要用于系统设计和开发的模型这其中需要经历一系列的过程，包括使用事实发现技术，如会谈、文档复查、观察、问卷调查、抽样和调查研究等获取需求列出并描述需求，包括输入、过程、输出以及性能、控制等定义整体拥有成本做一次成功的会谈最后，使用有效的文档编制方法，产生系统需求文档，并将此有效的文档编制方法贯穿项目始终系统分析阶段概述所谓系统分析，其总体目标就是了解项目系统，确保其支持业务需求，为系统开发奠定坚实的基础在这一阶段，通常都会使用模型和其它文档工具来描述和呈现将要建立的系统系统分析活动系统分析主要包括四项活动：需求建模、数据和过程建模、对象建模、开发策略考虑如图所示，尽管瀑布模型呈现了顺序特征，但在实际的建模过程中，每当发现新的事实，或者系统需求有改变时，三种建模任务之间总会产生典型的交互行为系统分析阶段的每一个活动都有最终产品及一个或多个里程碑，大项目的系统活动往往需要很多工作来进行人、任务、资源、时间、预算等的协调需求建模数据和过程建模对象建模开发策略系统分析技术由于新的信息系统的开发将会涉及并影响使用该系统的企业的所有人，因此，采用合适的系统分析技术显得尤为重要首先，需要分析员具有很强的分析能力和人际交往能力分析员拥有强的分析能力使其能够较快确定问题核心，评价关键元素，并创建有用的解决方案而人际交往能力对分析员来说更为重要。因为，分析员需要和所有工作层次的人共同工作，协调用户的需求冲突，并最终达成对系统需求的共同一致另外，系统分析阶段的工作策略也至关重要，它将影响到系统分析工作的顺利进行，以及系统需求的完整取得和众人的一致认同通常都会采用从系统分析的初始就采用面向团队的开发策略面向团队的方法和技术面向团队的开发方法给我们带来的最为明显的好处就是，系统需求获取的高效以及较低的需求获取成本另外，用户的参与也使得需求能够更好地贴合用户，发现问题可以尽早发现并得到纠正面向团队的方法和目前仍然流行的结构化方法有较大的不一样，后者当且仅当需要用户的输入或确认时，才和用户沟通基于团队的开发模式事实是已经存在一段时间了，其中常见的一种就是所谓的联合应用程序开发(JAD)——进行事实发现和需求建模的面向用户开发技术另一种流行的方法是快速应用程序开发(RAD)，用户可以参与开发过程的每一步JAD通常只集中于事实发现和需求决策上，而RAD则针对系统开发任务的整个过程提供了一种快速跟踪的方法，包括计划、设计、构建和实施联合应用程序开发在JAD中，用户可以作为一个积极的参与者参与开发过程目前典型的用户参与策略是JAD团队技术，就是将用户、经理、IT专业人员组成任务团队，一起收集信息，讨论并定义新系统需求下表是典型的JAD参与者及其任务JAD参与者任务JAD项目领导制定JAD会议议程并主持会议高层管理者为项目提供企业级授权和支持经理为项目提供部门级支持，了解项目如何支持业务功能和需求用户在当前操作中，提供期望的日常任务流程的操作需求描述系统分析员为JAD成员提供技术帮助和资源记录员为JAD会议创建文档，和分析员一起创建新系统模型

但JAD方法也有缺点，如资源开销会比传统的方法更大。不过与用户参与带来的好处，如用户对新系统的支持度提高、新系统更容易成功等好处相比，大多数情况下，开销的增加还是值得的快速应用程序开发这是一种基于团队的技术，能够加速信息系统的开发，产生机能信息系统和JAD不同的是，JAD的最终产品是需求模型，而RAD作为一个完整、拥有4个阶段的生命周期，其最终产品则是新的信息系统RAD非常依赖原型的创建和用户的参与允许用户尽可能早地检查工作模型，以确定是否满足他们的需求，并提出修改建议根据用户的输入修改原型，反复交互直至用户满意项目组使用CASE工具构建原型，并创建一系列连续的文档RAD阶段和活动RAD模型由四个阶段组成：需求计划、用户设计、构建和验收注意用户设计和构建阶段之间连续的交互过程

RAD的目标就是通过用户参与来缩减资源消耗

RAD的优点是高效、低成本缺点是强调系统本身结构，而可能忽略企业战略上的业务需求另外，加速开发会导致质量等目标被忽略需求计划构建用户设计转换任务

用户、经理和IT职员对企业需求、项目范围和系统需求达成一致意见获得批准继续任务

用户参与构建模型和原型进行严密的JAD型会议任务

程序和应用开发编码单元、集成和系统测试任务

数据转换全面测试系统变更用户培训建模工具和技术

建模包括用来在各个开发阶段描述系统的方法，包括图、表、形式表达及非技术语言模型往往会有助于用户、项目相关人员、管理人员等理解系统的设计，而建模描述工具可以帮助这样的理解，以及有利于用户与系统的交互常用的工具主要有：CASE工具、功能分解图、数据流图、统一建模语言等CASE工具在CASE工具环境下，分析员可以交替使用建模和事实发现技术：首先，将事实发现结果转变成模型然后，研究模型，以确定是否需要更多的事实发现系统分析员通常都会使用功能分解图和统一建模语言来帮助理解系统需求功能分解图功能分解图(FDD)是一种自顶向下描述业务功能和过程的方法使用FDD，分析员可以显示业务功能，并将这些功能分解成更低层的功能和过程。下图是系统开发过程工作分解的示意图RequirementsDefinitionSystemDevelopmentSystemTestingDocumentationSystemDesignEquipmentHistoryModuleSparePartsInventoryControlModuleDataDictionaryDevelopmentScreen&ReportDesignLogicDiagramsCodeDevelopmentModuleTestingWorkOrderControlModule数据流图FDD之后，分析员可以创建数据流图(DFD)来描述系统存储、处理和转换数据的过程在稍大规模的系统中，DFD都应该是分层结构的一个用PAD图绘制的描述某算法的DFD开始结束aj

Until

x5i

Until

x6bx1kfx4ghdefkx2de123

While

x3c统一建模语言统一建模语言(UML)是一种可以使软件系统设计可视化并能为其组织文档的方法UML提供了各种图形工具，如用例图和顺序图。在需求建模过程中，分析员可以利用UML从用户角度出发来描述信息系统如图，是用UML表示某个事实存在的基本方法ShapeShapePolygonCircleSpline……PolygonCircleSpline……系统需求审核列表在需求建模过程中，分析员必须确定并清晰描述所有的系统需求作为信息系统包含的特征的系统需求，必须既能满足系统业务需求，又能为用户所接受作为衡量一个已完成系统总体可接受性的基准，系统需求由五大类组成：输入输出过程性能控制教材P.81对上述每一类，都给出了一些实例示范未来增长、成本和效益在项目系统的系统分析阶段，一个优秀的分析员不仅关注系统的需求，同时还必须关注需求以外的许多方面。如，系统的可扩展性、整体拥有成本系统可扩展性决定了一个系统未来处理自身增长和需求的能力整体拥有成本包括系统交付用户后的运作和支持费用这两者可能会直接影响项目系统今后的市场竞争力和被接受程度换句话说，一个系统能否被市场所接受，并不仅仅由技术和功能、性能所决定，还取决于许多非技术因素可扩展性可扩展性是指系统处理未来增加的业务量和交易的能力可扩展性好的系统意味着可以使用更长的时间，以及能够更好地适应用户需求和市场的变化，因此更能够为市场所欢迎，系统的初期投资也能有更多的回报系统扩展通常包括重要的系统功能和性能的增加和改进由于系统能力的扩展往往还意味着系统数据存储和处理量的增大，以及系统网络吞吐量的增加因此，为了对系统可扩展性进行评价，需要分析员尽早掌握系统将来可能的输入、输出和过程的业务量信息这就需要分析员对项目系统今后服务的领域有深入的理解和预见整体拥有成本如果系统开发费用可以被视作开发系统的直接费用，那么系统服务、支持、运行、维护、日常开支等费用就是相对于直接费用的间接费用作为系统从开发到运行、维护的全部费用，整体拥有成本(TCO)应该是直接成本和间接成本的总和在有多个方案选择的时候，对TCO的估算就显得特别重要由于间接费用通常都是不那么明显的，许多起初看上去并不昂贵的系统，最后往往会成为费用最多的选择因此，对间接费用的估算，往往是对分析员最大的考验，分析员必须尽力确定间接费用因为，即使具体的效益很难量化，还是应该体现IT投资的战略角色好在微软已经开发了一种度量总成本和效益的方法，即快速经济合理性论证(REJ)，可以帮助分析员优化IT投资的框架事实发现事实发现就是采用合适的事实发现技术收集项目系统需求相关的信息，为需求建模提供资料事实发现技术包括面谈、文档复查、观察、调查、问卷调查、抽样和研究等事实发现概述虽然目前已经有一些工具可以帮助分析员收集、整理和分析事实，但实际的事实发现过程还是需要分析员自己完成分析员通常可以提出类似以下的问题来确定所需要的信息：当前系统支持哪些业务功能？新系统必须支持什么战略目标和业务需求？目标系统的收益和TCO怎么样？系统将处理什么样的交易？用户和经理需要从系统了解什么信息？新旧系统之间需要交互吗？业务过程再造工程可以减少哪些手续？存在哪些安全问题？哪些风险是可以接受的？什么样的资金预算和时间表约束会影响系统开发？分析员为了顺利收集到这些信息，必须首先制定策略，确定采用的事实发现技术，设计必要的方法、框架或表格，执行事实发现技术Who、what、where、when、how和why事实发现一般都会涉及到5个熟悉的问题：Who、what、where、when、how对于每个问题，分析员还都必须追问一个很重要的问题：why下表列出了基本的问题以及应该在什么时候提出这些问题，它反映的是，在需求建模过程中，随着重点从当前系统转移到目标系统所需要提出并解答的问题的示例当前系统目标系统谁做的？为什么这个人做？应该什么人做？做的什么？为什么做这个？应该做什么？在什么地方做的？为什么在那里做？应该在什么地方做？什么时候做的？为什么那个时候做？应该什么时候做？怎样做的？为什么用这种方法做？应该怎样做？面谈作为最常用的事实发现技术，面谈是一个有计划的会面过程，使得分析员可以有目的地从面谈对象那里获取有意义的信息想要成功地进行面谈，需要事先进行计划，并执行面谈计划，最后将面谈结果整理成文档，这些都需要一定的技能在获得前面了解的面谈必要的各项信息后，就可以按照以下七个步骤进行面谈：确定面谈对象确立面谈目标准备面谈内容和确定面谈方法准备面谈进行面谈将面谈结果整理成文档对面谈进行评价面谈过程需要注意的问题分析员在选择面谈候选人时，必须考虑组织的非正式结构——因为这些人可能更有影响力或在目标业务领域更有地位、学识更高面谈目标的确立应与面谈对象的角色相关，如高层对象多谈宏观层面的内容，这样会有利于分析员对系统的整体理解和把握在作面谈提问时，应避免使提问带有诱导性，这可能使答案带有倾向性，而使结果偏离需要，或误导分析员的工作面谈时间应该尽可能限制在1小时内，地点通常在被访者办公室或中立的第三地，这两类面谈地点各有好处，前者方便取得资料，而后者可以尽量避免打扰尽可能不要安排连续面谈，因为分析员需要时间尽快记录面谈获取的信息其它事实发现技术文档复查：有助于对当前系统如何运作有更好的理解。需要注意的