软件需求分析、设计

• 需求的层次：

1. 业务需求：指反应企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围，项目视图和范围文档把业务需求集中在一个简单、紧凑的文档中，该文档为以后的开发工作奠定了基础。
2. 用户需求：用户需求描述的是用户的具体目标，或用户需求系统必须能够完成的任务。也就是说，用户需求描述了用户能使用系统来做什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景（scenaios）进行整理，从而建立用户需求。
3. 系统需求：系统需求是从系统的角度来说明软件的新需求，包括功能需求、非功能性需求和设计约束等。用户利用这些功能来完成任务，满足业务需要。功能需求通常是通过系统特性的描述表现出来的，所谓特性，是指一组逻辑上相关的功能需求，表示习惯为用户提供某项功能（服务），使雍和宫的业务目标得以满足；非功能性需求是系统必须具备的属性和品质，又可细分为软件质量属性（例如：可维护性、效率等）和其它非功能性需求。设计约束也成为限制条件或补充规约，通常是对系统的一些约束说明，例如，必须采用国有自主知识产权的数据库系统，必须运行在UNIX操作系统之下等。

• 质量功能部署

Quality Function Deployment， QFD是一种将用户需求转化为软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD将软件需求分为三类，分别是常规需求、期望需求、和意外需求。

1. 常规需求：用户任务系统应该做的的功能或性能，实现越多用户会越满意。
2. 期望需求：用户想当然任务系统应具备的功能或性能，单并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。
3. 意外需求：也成为兴奋需求，是用户需求范围外的功能或性能（但通常是软件开发人员很乐意赋予系统的技术特性），实现这需求用户会很高兴，但不实现也不影响其购买的决策。意外需求是控制在开发人员手中的，开发人员可以选择实现更多的意外需求，以便得到高满意、高忠诚度的用户，也可以（出于成本或项目周期的考虑）选择不实现任何意外需求。

• 需求获取

需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。需求获取是否科学、准备充分，对获取出来的结果影响很大，这是因为大部分用户无法完整的描述需求，而且也不能看到系统的全貌。

常见的需求获取方法包括用户访谈、问卷调查、采样、情节串联版、联合需求计划等。

• 需求分析
   

一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性。

SA方法需求分析，其建立的模型核心是数据字典，围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型（也称为状态模型）。

使用实体联系图（E-R图）表示数据模型；

用数据流图（Data Flow Diagram，DFD）表示功能模型；

使用状态转换图（State Transform Diagram， STD）表示行为模型。

E-R图主要描述实体、属性，以及实体之间的关系；

DFD从数据传递和加工的角度，利用图形符 通过逐层细分描述系统内各个部件的功能和数据在它们之间的传递情况，来说明系统所完成的功能。

STD通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，指出作为特定事件的结果将执行哪些动作。

OO方法，对问题域进行分析和理解，正确认识其中的事物及他们之间的关系，找出描述问题域和系统功能所需的类和对象，定义他们的熟悉和职责，以及他们之间形成的各种联系。

OOA模型包括用例模型和分析模型。

• 软件需求规格说明书（Software Requirement Specification，SRS）

SRS应该包括以下内容：

1. 范围。包括SRS适用的系统和软件的完整标识，包括标识 、标题、缩略词语、版本 和发行 ；简述SRS适用的系统和软件的用途，描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、承建方和支持机构；标识当前和计划的运行现场；列出其它相关的文档；概述SRS的用途和内容，并描述与其使用有关的保密性和私密性的要求；说明编写SRS所依据的基线。
2. 需求。SRS的主体部分，详细描述软件需求，可以分为以下项目：

所需的状态和方式、需求概述、适应性规格、软件配置能力需求、软件配置项外部接口需求、软件配置项内部接口需求、适应性需求、保密性和私密性需求、软件配置项环境需求、计算机资源需求（包括硬件需求、硬件资源利用需求、软件需求和通信需求）、软件质量因素、有关后勤需求。。。

1. 合格性规定。指定每个需求所使用的方法，确保需求得到满足。
2. 需求可追踪性。
3. 尚未解决的问题
4. 注解
5. 附录。

1. 需求验证，又称为需求确认。其活动是为了确定以下几个方面的内容：

1. SRS正确的描述了预期的、满足项目干系人需求的系统行为和特征。
2. 需求是完整的和高质量的。
3. 需求的表示在所有地方都是一致的。
4. 需求为继续进行系统设计、实现和测试提供了足够的基础。

1. UML。一种定义良好、易于表达、功能强大且普遍适用的建模语音，融入了软件工程领域的新思想、新方法和新技术，不仅支持OOA和OOD，还支持从需求分析开始的软件开发的全过程。

UML结构包括构造块、规则和公共机制三个部分。

UML中事物包括结构事物、行为事物、分值事物、注释事物

UML中关系：依赖、关联、泛化、实现。

       Dependency、association、generalization、realization

UML2.0包括14中图：

类图class diagram

对象图 object diagram

构件图component diagram

组合结构图 composite structure diagram

用例图 use case diagram

顺序图 sequence diagram

通讯图 communication diagram

定时图 timing diagram

状态图 state diagram

活动图 activity diagram

部署图 deployment diagram

制品图 artifact diagram

包图   package diagram

交互概览图 interaction overview diagram

       UML视图包括：逻辑视图、进程视图、实现视图、部署视图、用例视图。

• 面向对象分析

OOA模型独立于具体实现，即不考虑与系统具体实现有关的因素；

OOA和OOD的区别在于，OOA的任务是“做什么”，OOD的任务是“怎么做”。

面向对象分析阶段的核心工作是建立系统的用例模型与分析模型：

（1）用例模型：

（SA结构化分析）方法采用功能分解的方式来描述系统功能，SA方法的缺点是分割了各项系统功能的应用环境，从各项功能项入手，很难了解到这些功能如何相互关联来实现一个完整的系统服务的。

       从用户角度来看，他们并不想了解系统的内部结构和设计，关心的是系统所能提供的服务，这就是用例方法的基本思想。

       OOA方法中，构建用例模型一般需要经过四个阶段：识别参与者、合并需求获得用例、细化用例描述和调整用例模型。

       用例之间的关系主要有包含、扩展和泛化。

1. 包含关系。当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系表示他们。其中这个提取出来的公共用例称为“抽象用例”，而把原始用例称为基本用例。
2. 扩展关系。如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例。
3. 泛化关系。当多个用例共同拥有一种类似的结构和行为时，可以将他们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。

（2）分析模型：

       分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及他们如何保持通信，实现系统行为（动态模型）。

       领域模型又称为概念模型或简称为域模型，也就是找到哪些代表事物与概念的对象，即概念类。

       建立分析模型的过程大致包括定义概念类、确定类之间的关系、为类添加职责、建立交互图等，其中前三个步骤统称为CRC（Class-Responsibility-Collaborator）建模。

       类之间的主要关系有关联、依赖、泛化、聚合、组合和实现等。