《从需求分析走向概要设计》由会员分享，可在线阅读，更多相关《从需求分析走向概要设计（12页珍藏版）》请在金锄头文库上搜索。
1、从需求分析走向概要设计王青 2007-07-28在软件过程中，需求分析和概要设计是两个极其重要的阶段。需求分析是概要设计的依据，而设计则 是需求自然的逻辑延续。从需求分析走向概要设计，就是我们从待解决问题的领域走向解决方案的领域， 也就是我们从客观的现实世界走向主观的计算机待建系统世界的过程。为了使得大家对这一过程的目的、 原则和具体工作有较为清楚的认识，特阐述以下内容与大家讨论。凡以下之内容，均系一家之言，不妥之 处，敬请指正。软件工程的方法学软件工程的方法学方法学是指导我们解决问题的原则，它是我们对于具体问题解决方案的哲学基础，是我们思考问题， 解决问题的方式方法。下面的一些方法学是软件工
2、程的理论基础和逻辑起点，它们在软件工程的具体方法、 规则和关键活动域中都有体现。了解这些方法论，有助于我们加深对软件工程的理解；同时在我们优化软 件工程的活动中，对它们的了解和应用更会使我们的工作事半功倍。分治法：将大的问题分解为小的问题，从而缩小问题的规模，降低问题的复杂度，减少风险。逻辑完整性：所有的活动和所有的制品，都有其逻辑上的起点和支撑点；同时，也都有其逻辑上相应 的结果。可管理：所有的活动和制品都应当能够被控制和调整。文档化（documented）：将不可见的活动和思维成果外化为具体的文档。敏捷与 MDA：敏捷的原则在于够用就好；而 MDA 立足于用模型取代部分文档，增强设计的可追
3、溯 性与可重构性。 软件工程的这些方法学于实践当中体现为软件过程，而软件过程的实施则依靠管理和组织的保障，在 此限于篇幅不再赘述。需求分析的制品需求分析的制品需求分析的过程是对现实世界中的待解决问题的建模过程，同时也是深入剖析待建系统的过程。它的 成果通常包括：一组 Use Case：通过对前置条件、后置条件和事件流的描述来清楚的界定系统使用者对于系统的 功能性需求。Domain Model：明确待建系统中的业务实体以及它们之间的关系SRS/ARS （Software/Application Requirements Specification）：综述待建系统的目的、功能性需 求、接口/界面需
4、求、约束以及非功能性需求。概要设计的制品概要设计的制品概要设计就是在需求分析成果的基础之上，运用软件设计的原则、模式、惯例和经验，提出问题的解 决方案，并明确界定待建系统的结构、接口和界面。在概要设计结束时，待建系统的技术架构、部署图、 组件的划分、各个组件的外部接口、用户界面（静态原型） 、持久化方案等设计要点都已经确定，系统的 表示层，业务逻辑层和数据层的解决方案也已经明确。我们通常用下面的这些制品来描述我们概要设计的 结果：全局制品全局制品Physical Architecture Diagram系统的物理结构，包括网络环境和服务器分布：图表 1 系统物理架构图Technical Arc
5、hitecture Diagram系统的层次结构，以及各层次所使用的具体技术：图表 2 系统技术架构图Installation Package Directory系统安装包的目录结构：mgsclsrcbuildlibjavawebsqltestWEB-INFresourceimgmgsclentrywebstrutsjspsecurityuseruserformsactionMore entries are omitted for clarifyingjavascripthtml图表 3 系统安装包目录结构Deployment Diagram系统中的各个模块的部署情况：图表 4 系统模块部署图
6、表示层制品（针对表示层制品（针对 Web Application）Sitemap图示待建系统界面由哪些页面构成，以及它们间的层次与导航关系：图表 5 SitemapStatic- Prototype一组静态 html 页面用以说明定义待建系统的最终用户界面，参考附件：prototype.zip其它其它虽然表示层的技术相对简单，但是如果用户有 RIA（Rich Internet Application）方面的需求，则通常需 要在客户端实现一些较为复杂的逻辑（表示逻辑不是业务逻辑！） ；此时我们应该对这些需求进行设计， 用到的制品类似于在下面的业务逻辑层和数据层中罗列的制品；但是，必须注意到客户端
7、技术的特殊性， 例如：脚本语言和沙箱模式。业务逻辑层制品业务逻辑层制品Components Diagram系统中各个包中所有的公有类图表 6 组件图Component Interface Diagram系统中每个包的对外接口图表 7 组件接口图Component Requirements Specification组件需求规格说明书，用以明确每一个组件的设计需求，作为下阶段详细设计的一个重要输入，参见附件： CRS_example.docSequence Diagrams时序图，针对每个用例，图示系统如何实现这个用例，满足用户的需求图表 8 系统时序图数据层制品数据层制品Entity Rela
8、tionship Diagram数据库设计的 ER 图：图表 9 数据库设计 ER 图DDL Script数据定义脚本：根据技术架构中选定的数据库管理系统，将 ER 图具体化为 sql 脚本文件，参见附件 creat_db.sqlCommunication Data Schema数据交换 schema，系统与其它系统交换业务数据的时候（EDI）需要的数据模式，依据所利用的数据描述 技术的不同而不同，通常是 XML 的 schema，也就是 xsd 文件，参考附件: C-Schema_example.xsd在工程实践当中为了查阅和评审的方便，我们通常将所有上述制品集中于概要设计 （High Le
9、vel Design Specification）和数据字典 （Data Dictionary）文档中，并同时分别独立保留和管理每份制品。其它概要设计阶段的制品其它概要设计阶段的制品测试工作域制品测试工作域制品Test Plan测试计划，参考附件: Test Plan.xlsTest Data测试数据，参考附件: Test Data.doc管理工作域制品管理工作域制品Software Project Plan (updated)更新已有的 SPP，对详细设计阶段的工作进行细致的定义和安排概要设计工作流概要设计工作流下面的活动图描述了概要设计阶段的各项工作，请参考附件中的模型文件：HLD_Process.mdl，模型中对 于每个工作有更为详细的介绍（注意活动的 documentation） 。
