《火球:UML大战需求分析(第二版)》读书笔记

Posted 2021-07-02 EGG IXD

UML

UML（Unified Modeling Language）统一建模语言，可用于需求分析、软件设计，UML大体可分为两类包括：结构型UML、行为型UML。

下图过大模糊,高清链接：https://www.yuque.com/eggjidan/rfx8hy/tbghwt?inner=kCXML

UML学习难点

• Thinking in UML：掌握UML形（语法）容易，掌握神（思维方式）需长期练习实践。
• 培养以下能力：书面表达能力；归纳总结能力；“面向对象”（面向对象分析OOA）的思维能力和抽象能力 ---多应用类图。

需求分析

• 心态转变：需求变更是好事，说明客户对需求的理解更近了一步，以达到“双赢”为项目追求的目标；
• 项目刚开始时，客户对需求的理解比项目组强，项目组需短时间内对需求认识超越客户，切实理解客户真正需要；
• 背景、需要和需求规格：

注：

• 越是基层用户，越容易提出“需求规格”级别需求，相反，越是高层客户，越容易提出“需要”级别需求（应从业务分析开始，在此基础上整理出需求用例，70%靠需求分析理解30%靠需求整理）。

• 与客户进行沟通时慎用uml、需求确认及及签署时不能乱用uml。

需求分析过程

注：对需求分析可分别进行结构建模（最常用类图）和行为建模（最常用活动图）。

需求阶段常见的技术细节

• 系统的技术选型，包括开发语言（如Java、NET、php）、数据库平台（如Oracle、mysql、SQL Server）等；
• 系统部署在怎样的服务器上？（如原有服务器、新采购服务器）服务器的软硬件配置情况；
• 系统需要和原有系统对接？将来有哪些系统进行对接？
• 系统需要倒入那些数据？需要和哪些系统同步数据？
• 客户原有的IT平台需要如何改造？怎样兼顾新系统和原有系统？
• 系统安全性、性能等方面的要求程度？

注：使用部署图、构件图描述客户当前IT架构、列出客户在技术框架方面的要求、针对于要求用部署图和构件图设计新系统的技术框架、与客户沟通和确认IT架构环境需要怎样的改造（到客户IT系现场进行调研，找IT负责人了解清楚，服务器操作系统是否已经打最新的安全补丁、数据库是否有备份措施）？新系统如何部署在客户的IT环境里？

关于非功能性需求实例

1.软件技术架构要求；

2.安全性、易用性、性能、接口等方面的要求；

3.根据实际情况还可列出可靠性、一致性、开放性....(不要过于详细，一些从实际需求出发，列出符合用户利益且公司可做到的指标)

安全性：

• 用户通过Internet访问本系统时，只能以HTTPS的方式访问；
• 系统需记录用户的重要“写”操作，记录的内容包括用户名、操作内容。重要“写”的操作包括系统登入、登出........。

易用性：

本系统是客户日常工作所依赖的系统，系统尽量提供便捷的操作方式。

• 尽量减少用户输入量，多用省却值和选择输入，如选项较多，需要提供便捷的筛选方式。
• 能根据用户的输入习惯，只能地提供常用的输入选择。需提供智能选择的地方包括......    。

性能：

• 服务器配置为....,客户端配置为...,同时使用本系统的人数约为xx人，用户进行常用操作时，系统反应时间不超过5s，常用操作包括....。

接口：

满足系统需求前提下，尽量减少与第三方系统接口，接口内容尽量简单，尽量是（单/双）向和只读或.....。

注：性能方面不要过度量化，如吞吐量、响应时间等性能指标。公司内部使用MIS类系统不需要吞吐量、响应时间等。

注：

• 不要写“放之四海皆准”的内容，粒度太粗没有参考价值；
• 根据项目的业务需求、客户的IT架构环境，写出针对性要求；
• 抓住主要问题，列出具体要求，不必追求面面俱到；
• 主要考虑客户在正常使用状态下系统应达到的要求，出现几率低的情况可不考虑；
• 写出的内容就是承诺做到的，只写出可接受且能做到的内容；
• 文字准确，客户能理解，削除的内容可被验证；
• 此内容应为后续软件设计和测试提供重要的依据，后续工作需持续细化、补充完善。

需求分析完整流程

需求规格说明书

将前面需求分析的内容整理为需求规格说明书（需求文档），包括如下内容：

数据库设计三大范式

范式定义：设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。而通常我们用的最多的就是第一范式（1NF）、第二范式（2NF）、第三范式（3NF），也就是本文要讲的“三大范式”。

范式优点：降低数据的冗余性

范式缺点：获取数据时，需要通过Join拼接出最后的数据

函数依赖：某个属性集决定另一个属性集时，称另一属性集依赖于该属性集

• 完全函数依赖：通过AB能得出C，但 是A、B单独得不出C，那么C是完全依赖于AB。
• 部分函数依赖：过AB能得出C，通过A也能得出C，或者通过B也能得出C，那么C是部分依赖于AB。
• 传递函数依赖：通 过A得到B，通过B得到C，但是C得不到A，那么C是传递依赖于A。

三大范式：

• 第一范式：1NF是对属性的原子性，要求属性具有原子性，不可再分解；

• 注：1NF是所有关系型数据库的最基本要求，只要在RDBMS中已经存在的数据表，那一定符合1NF。

• 第二范式：2NF是对记录的唯一性，要求记录有唯一标识，即实体的唯一性，即不存在部分依赖；

• 第三范式：3NF是对字段的冗余性，要求任何字段不能由其他字段派生出来，它要求字段没有冗余，即不存在传递依赖；

注：符合高一级范式的设计，必定符合低一级范式！

反三范式：一般数据库需满足第三范式（3NF）。没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余，达到以空间换查询效率的目的。

范式中部分引用于知乎刘慰，链接：https://www.zhihu.com/question/24696366/answer/29189700

并发冲突

设计系统时不要忽略并发冲突问题（否则会导致“无法重现”问题或“脏数据”从而导致系统逻辑问题），例如修改部门领导审批的请假申请，在确认修改前，领导已批准（状态变化），申请者并不知情的情况。其解决方案包括：

• 规定在某一阶段，只能由某个角色来修改，避免并发冲突（程序简单，但可能不符合实际需要）；
• 确定并发冲突的处理规则，程序做并发冲突的判断和处理（程序会变复杂）。

单点登录（Single Sign On）

简称为 SSO，是比较流行的企业业务整合的解决方案之一。SSO的定义是在多个 应用 系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

• 优点：提高用户效率；提高开发人员效率；简化管理（加入单点登录协议，管理用户账号负担减轻）。
• 缺点：不利于重构；无人看守桌面，信息隐私安全问题。

权限集中管理

在一个地方统一管理系统所有权限。

单点登录和权限集中管理方案

1.可考虑系统通过集成windows的域认证，解决单点登录、权限集中管理问题。

• 优点：直接利用现有资源，无需开发认证管理和用户管理；
• 缺点：需具备良好的windows域管理环境、使用计算机习惯域与信息隐私安全问题；

2.开发单点登录和权限集中管理系统。

3.做简单的用户管理和权限管理功能。（不支持单点登录）要考虑软件公司和客户双方利益，与实际情况。

4.与其他系统做用户同步对接。前置条件如下：

• 技术互相支持（同步用户数据或设计和实现了相关接口）
• 用户对“单点登录“进行授权和设置

注：技术难度和工作量虽不大，但需互相之间有很强的利益结合点，否则合作毫无基础，风险大。

实际工作文档处理方式（适当裁剪）

1.项目型的项目：采用《需求规格说明书》内容框架，但不包括系统特性内容；

2.产品研发型的项目：两份需求文档，包括《项目远景》、《需求规格说明书》，其中《项目远景》内容包括背景和需要（含系统特性）；

3.需求调研但不开发的项目：按《需求规格说明书》内容框架拆分多个文档，最终统一为一份文档。

项目组各角色对需求端的把握程度要求

关于敏捷的内容就不做笔记了，直接看敏捷类的书就好～

关于读后感

这本书断断续续的读了一周左右，干货很多，前面大篇幅介绍各类UML（偏理论），中间部分是一个需求分析案例（实践案例），最后部分是关于敏捷和UML对比与融合。整本书架构清晰，最喜欢的是需求分析案例部分，将前面的理论知识融会贯通。希望自己能将它很好的运用到工作中，形成自己的知识体系！

end