《软件需求分析实战》阅读笔记
2024-04-10 17:09:07 0 举报AI智能生成
《软件需求分析实战》主要讲述了：需求分析的工作步骤；需求分析的工作内容；如何进行需求调研；如何进行系统规划；如何设计软件；如何设计出好软件；快速原型开发模型；需求文档的撰写；如何应对需求变更；如何成为需求分析高手。
作者其他创作
大纲/内容
一、需求分析入门
认识管理软件
什么是管理软件
什么是好管理软件
有用性
易学性
易用性
灵活性
可重用性
易交互性
高效性
健壮性
管理软件的发展
常用的管理软件
管理软件的实施方式
认识需求分析
什么是需求分析
需求获取
观察法
体验法
问卷调查法
访谈法
单据分析法
报表分析法
需求调研会法
系统规划
需求确定
整理需求
设计系统蓝图
数据建模
功能设计
界面设计
原型说明书
需求变更
成为一个需求分析师
什么是需求分析师
性格要求
要善于沟通
要善于听取不同的意见
要有团队精神
掌握IT专业知识
掌握企业管理知识
企业运作流程
财务会计
采购
销售
库存
生产
计划
成本
质量
人力资源
组织
精通一种开发模型
小结
重点
深刻理解什么是好软件，为设计好软件打下坚实的基础。（★ ★ ★ ★ ★ ）
了解管理软件常用的实施方式，不同方式的优缺点。 （★ ）
了解企业管理工作包括哪些内容。 （★ ）
了解成为一个好的需求分析师的条件。 （★ ）
理解“快速原型”开发模型。 （★ ★ ）
思考
你觉得你们学校的管理工作包括哪些内容？
如果让你策划一款软件系统管理你们的学校，你觉得可以包括哪些功能？
根据好软件的几个特点，分析一下腾讯的微信App。
评价一下你在学校中看到过的某管理软件（如学生选课系统、图书管借书系统等）。
结合需求分析师的性格要求，分析一下自己的性格特点。
二、需求获取
观察法
优点：直观，容易理解。
缺点：大量的工作不容易看出所以然、 费时费力。
使用：跟其它方式结合使用。
体验法
优点：理解深刻。
缺点：耗时费力，成本太大。
使用：业务工作人员自己写软件、甲方直接雇佣开发者。
问卷调查法
如何制作调查问卷
选择答题者
问卷调查的局限性
访谈法
访谈对象确定
访谈准备
访谈预约
访谈进行
访谈结果整理
访谈结果确认
单据分析法
如何收集单据
收集单据务必要全面
收集单据的过程也是个调研的过程
搜集单据务必是被使用过的
每种单据仅收集一张并不足够
如何分析单据
理清每个单据的源头
理清单据的流动路径
理清每个字段的前因后果
注意边角上的不正规内容
单据管理
报表分析法
不要轻视报表分析
生成报表的触发条件
生成报表的数据来源
分析报表逻辑
1、使用常识判断
2、听客户讲解
3、研习客户文档
4、研习电子表格公式
报表对功能设计的重要影响
1、引入中转数据
2、保存报表结果数据
3、报表可能是功能模块
4、意想不到的另类需求
需求调研会法
会前
会后
小结
重点
需求调研的七种方法，理解调研过程中需要将这些方法结合运用（ ★ ）
如何制作调查问卷（ ★ ★ ★ ★ ）
如何准备调研访谈 （ ★ ★ ）
访谈过程如何进行（ ★ ★ ）
如何收集单据（ ★ ★ ★ ）
如何分析单据（ ★ ★ ★ ★ ★ ）
生成报表的触发条件（ ★ ）
如何分析报表（ ★ ★ ★ ★ ★ ）
报表对功能设计的影响（ ★ ★ ★ ★ ★ ）
思考
1. 编写一份调查问卷，了解学校是如何管理学生宿舍的。
2. 为了给学校图书馆开发图书管理系统，你要对图书管理员进行一次访谈。展望一下你会如何安排这次访谈。
3. 回忆一下你最近填写的某张单据（如某申请表、请假单），说说其中的管理思想。
4. 找一张与你相关的单据，分析这个单据的流动路径、每个字段的因果关系。
5. 分析一下你最近的成绩报告单，你觉得其中蕴含了哪些软件功能需求？
6. 假设学校要求学生每次上课都要打卡，然后根据打卡记录生成学生的上课考勤报表（统计每节课的迟到、旷课人数）。这是个需要大量计算的报表，分析一下要做出这个报表需要哪些软件功能？如何提高报表效率？
三、系统规划
系统规划的工作内容
需求确定
认清需求
将抽象的需求具体化
将自然语言描述的需求结构化
注意避免理解偏差
控制需求
识别超出项目范围的需求
识别错误的需求
识别技术上不能实现的需求
挖掘需求
整理需求
需求调研报告
项目目标
期待解决的问题
项目范围
双方约定
相关资料
需求
数据
相关系统
待定问题
业务流程图
系统蓝图设计
进行价值分析
规划软件边界
规划工作方式
规划使用软件的地点
规划使用软件系统的时间
规划软件系统的触发事件
规划使用软件系统工作的场景
几个注意事项
警惕利益受损者
避免重复劳动
处理好软件关系
避免信息孤岛
什么是信息孤岛
形成原因
1、人为因素
2、编码差异
3、缺少关联字段
4、数据结构差异
处理方式
1、数据接口
2、统一编码
3、整合平台
4、综合解决方案
小结
重点
如何将用户的需求具体化、结构化（ ★ ★ ★ ★ ★ ）
如何识别超出项目范围的需求（ ★ ★ ★ ）
如何识别错误的需求 （ ★ ★ ）
需求调研报告的编写方式（ ★ ★ ★ ★ ）
如何绘制业务流程图（ ★ ★ ）
如何规划软件边界（ ★ ★ ★ ）
如何规划工作方式（ ★ ★ ★ ★ ★ ）
让用户重复劳动产生的原因（ ★ ）
信息孤岛形成的原因，常用处理方式（ ★ ★ ★ ★ ）
思考
学校需要开发一款管理学生档案信息的软件。对于学生基本信息的编辑权限，客户提出了这个需求：学生的基本信息由班主任录入，如果班主任请假，领导又催得急的话，学工处王老师处理。 ——用正确的方式重新描述本需求。
假设需要开发一款软件用于学校宿舍的床位分配，根据你的想法提出关于床位分配的需求。注意需求描述要尽量明确、精准、没有二义性，且一般非IT人员能够看得懂。
根据学校图书馆借书、还书的管理要求，画出业务流程图。
假设你到学校图书馆借书，图书管理员通过软件处理借书事宜。描述一下处理借书的工作场景。
观察在学习、生活中使用到的一些软件，请举一个信息孤岛的例子，并说明（或猜想）其形成的原因，有什么解决方法。
四、数据建模
认识数据建模
逻辑设计
物理设计
实体关系
一对一关系
一对多关系
多对多关系
范式
第一范式
第二范式
第三范式
BC范式
数据库设计
表
1、认清实体
2、关系是不确定的
3、关系是会变化的
4、历史信息让一对多关系不复存在
5、一些特殊的表
表的关系
1、一对一关系
2、一对多关系
3、特殊关系
附属关系
递归关系
字段
1、字段来源
属性字段
管理性字段
2、主键
3、数据类型
4、默认值
数据字典
几个注意事项
数据建模不是孤立的
注意可扩展性
不要教条主义
不要经验主义
小结
重点
数据建模的工作内容（ ★ ）
现实世界中的三种实体关系（ ★ ）
设计表的注意点（ ★ ★ ★ ★ ）
特殊的表（ ★ ★ ）
表与表的关系（ ★ ★ ★ ★ ★ ）
字段的数据类型（ ★ ★ ）
如何编写数据字典（ ★ ★ ★ ★ ★ ）
数据建模不是孤立的（ ★ ★ ）
数据建模要考虑可扩展性（ ★ ★ ★ ）
数据建模不要教条主义（ ★ ★ ）
思考
观察在学习、生活中使用到的一些软件，请举一个信息孤岛的例子，并说明（或猜想）其形成的原因，有什么解决方法。
如果要给学校图书馆开发一款图书管理软件，你觉得包括哪些实体？
这些实体有什么关系？
这款图书管理软件需要哪些表？表跟表之间有什么关系？使用Visio画出数据模型。
图书与书架是什么关系？如果要求保存图书的放置历史，这个关系变成什么关系？试画出两种不同的数据模型。
一个存放图书基本信息的表（如图书编号、书号、作者、定价等）可能包括哪些字段？使用Word写出它的数据字典。
五、功能设计
需求用例
什么是需求用例
用例的构成
1. 用户
2. 前置条件
3. 后置条件
4. 主场景
5. 扩展场景
6. 规则
用例编写
功能建模
什么是功能建模
功能点
1、什么是功能点
2、功能点的构成
3、什么是功能模块
原子功能
划分功能
功能逻辑
基础功能逻辑
1、数据库操作：增加数据
2、数据库操作：修改数据
3、数据库操作：删除数据
4、数据库操作：查询数据
5、非数据库操作：计算
6、非数据库操作：显示
7、非数据库操作：传递
数据流
工作流
一些功能逻辑案例
权限控制逻辑
功能权限控制逻辑
数据权限控制逻辑
结转逻辑
可变逻辑
自定义逻辑
功能优化
灵活性
问题一：这个地方一定要写死吗？
问题二：这个规则是必需的吗？
问题三：这个地方用户需求真的很明确吗？
问题四：这个地方用户需求发生变化的可能性大吗？
问题五：这个地方我抓住了业务的核心吗？
问题六：这个地方的处理跟业务的现实一致吗？
可重用性
尽量减少功能间的关联
注意数据流动的方向
建立团队的通用规范与通用功能
高效性
使用率不同的数据采用不同的保存方式
利用中转数据
外键必填
优先使用客户端资源
小结
重点
工作场景的撰写方式。 （ ★ ★ ）
如何进行功能划分。 （ ★ ★ ★ ）
常用的基础功能逻辑。 （ ★ ）
什么是工作流。 （ ★ ）
如何画工作流图。 （ ★ ★ ★ ★ ★ ）
常见的功能逻辑案例。 （ ★ ★ ）
如何提高软件功能的灵活性。 （ ★ ★ ★ ★ ★ ）
如何提高软件功能的可重用性。 （ ★ ★ ★ ★ ）
如何提高软件功能的高效性。 （ ★ ★ ★ ★ ）
思考
假设需要给学校图书管开发一款图书管理软件，根据你对图书馆管理图书的业务的了解，进行功能划分（从功能模块到原子功能）。
撰写学生到图书馆借书的主场景。
学校学生请假的管理要求：如果不超过3天，班主任批假；如果超过3天不超过7天，班主任批假后学工处批假；如果超过7天，班主任批假后学工处批假，最后李校长批假。根据这个要求画出工作流图。
上一题，如何处理“李校长批假”这个问题？设计两种方案，一种写活，一种写死。分析一下这两种方案的优缺点。
某社交软件，好友更换头像后，当前用户的通讯录中展示的还是以前的头像（只有跟对方聊天后才会将头像更换成最新）。说说软件设计者为什么要这么做。
九、从入门到优秀
减少失误
调研失误
忽视用户需求
忽视异常业务
片面地控制需求
缺少引导
规划失误
只做需求的搬运工
不考虑使用者
不考虑使用场景
不考虑实施与服务
设计失误
原型跟数据流脱节
不尊重“原则”
不考虑用户级别
不考虑数据积累
过度设计
有所权衡
优化的权衡
灵活性与健壮性
易学性与易用性
高效性与数据一致性
成本与利益的权衡
用户与软件团队
研发与实施
短期与远期
关注团队
了解团队
团队分工
团队的技术边界
团队规范
团队的可重用功能
重视文档
文档可以提高效率
文档是知识得以积累的载体
没有文档的组织是没有前途的
建立规范
需求分析管理规定
需求调研要求
需求调研报告的撰写
业务流程图的绘制
数据模型的绘制
数据字典的编写
需求用例的编写
工作流图的绘制
原型设计要求
原型说明书的编写
通用需求
需求变更说明书的编写
高远的眼光
软件是管理体系的一部分
软件在管理体系中的地位
软件对相关人员工作的影响
用户使用软件功能的触发条件
信息如何流入系统
信息如何流出系统
软件之外还有软件
软件因集成而获得新生
软件集成不容易
软件集成的常用方法
软件是有生命的
基因
怀胎
诞生
成长
成熟
衰老
死亡
小结
重点
不考虑使用者的规划失误（ ★ ）
不考虑使用场景的规划失误（ ★ ）
常见的设计失误（ ★ ★ ）
优化功能时的权衡（ ★ ★ ★ ★ ★ ）
文档的重要性（ ★ ★ ★ ）
规范：需求分析管理规定（ ★ ★ ★ ★ ）
规范：原型设计要求（ ★ ★ ★ ）
规范：通用需求（ ★ ★ ★ ★ ★ ）
软件集成（ ★ ★ ）
思考
在你开发或使用过的软件中，举一个例子说明如何根据不同条件考虑灵活性与健壮性的。
在你开发或使用过的软件中，举一个例子说明如何根据不同条件考虑易学性与易用性的。
举两个学习或生活中的事例，说明隐性知识与显性知识的区别。
仔细研读案例“需求分析管理规定”，试着补充3项内容。
仔细研读案例“原型设计要求”，试着补充3项内容。
仔细研读案例“通用需求”，试着补充3项内容。
八、需求变更
认识需求变更
需求变更总是有的
产生原因
1、调研不充分
2、沟通有歧义
3、异常没考虑
4、规划不到位
5、设计有瑕疵
6、实现欠灵活
7、实施不熟练
8、业务会变化
9、管理在改善
10、想法在改变
11、软件要发展
需求变更的控制
技术手段
沟通说服
成本约束
处理需求变更
需求变更的难易
改变界面的需求变更
改变功能逻辑的需求变更
改变数据库结构的需求变更
改变历史数据的需求变更
从根本上解决问题
从整个系统的角度出发考虑问题
不考虑实质与根源，只治标不治本
需求变更文档
需求变更未必是坏事
提高客户黏性
带来利润
推动功能扩展
将需求变更直接做成功能
使用参数处理需求变更
“炼”出软件产品
小结
重点
做软件离不开需求变更（ ★ ）
需求变更产生原因（ ★ ★ ★ ★ ★ ）
处理改变数据库结构的需求变更的困难所在（ ★ ★ ★ ★ ）
处理改变历史数据的需求变更的困难所在 （ ★ ★）
处理需求变更时，要从根本上解决问题（ ★ ★ ★ ★ ★ ）
需求变更文档的编写（ ★ ★ ★ ）
如何让需求变更推动软件功能的扩展（ ★ ★ ★ ）
为什么说可以通过需求变更“炼”出软件产品（ ★ ★ ）
思考
假设需要给学校图书馆开发一款图书管理软件。就学生借书的业务过程，根据你的理解，列举出有哪些正常业务，有哪些异常业务。（提示，一次正常的借书过程是正常业务，而图书丢失则是异常业务）。
假设上题的图书管理软件中，规定一个读者一次只能借阅一本书。后来，管理要求发生了变化，允许一次借阅不超过五本书。请分析这次变更应该如何处理，对历史数据有什么影响。
食堂一卡通系统中，学生用餐时需要刷IC卡。现在食堂管理方要求增加人脸识别功能，即学生既可以刷IC卡，也可以刷脸用餐。请分析这次变更应该如何处理，是否需要改变数据库结构，对历史数据有何影响。
七、原型说明书
原型说明书编写基础
定义：原型说明书以原型为基础
一个原型说明书模板
一个原型说明书案例
编写要求
原型说明书章节详解
1、概要·原型规范
2、概要·功能一览
3、概要·模块结构
4、概要·业务术语
5、总体要求与规则·统一要求
6、总体要求与规则·主要算法
7、总体要求与规则·共用规则
8、功能模块·功能点
如何撰写功能点需求
1、功能点·主要功能
2、功能点·主要用户
3、功能点·主场景
4、功能点·权限
5、功能点·功能需求
6、功能点·规则
7、功能点·重用功能
8、功能点·数据字典
9、功能点·注意事项
常见错误
1、将编号弄成了行号
2、写了规则，却没有引用
3、写了需求之外的内容
4、写了原型已经表达出来的需求
5、写了自明的需求
文档优化
聚焦
精简编号结构
用于辅助录入的小操作可以采用特殊的描写方法
编号层级不要太多
忽略一些通用操作
引入语法
提炼通用需求
小结
重点
理解原型说明书是以原型为基础的（ ★ ）
本章介绍的原型说明书模板（ ★ ★ ★ ）
学会编写原型说明书（ ★ ★ ★ ★ ）
避免一些常见错误（ ★ ★ ★ ）
本章用于需求描述的语法（ ★ ★ ★ ★ ★ ）
提炼通用需求（ ★ ★ ★ ★ ）
思考
假设需要给学校图书管开发一款图书管理软件，根据你对图书馆管理图书的业务的了解，设计出原型，并编写原型说明书。
说说你在编写上题的原型说明书时，是如何考虑优化文档的？
什么是“自明的需求”？根据你的理解举几个例子。
什么是“通用需求”？根据你的理解举几个例子。
制订一些可以用于需求描述的语法规范，对案例“用于需求描述的语法”进行补充。
提炼一些书中没有提到的通用需求，对案例“提炼通用需求”进行补充。
六、界面设计
界面设计基础
定义
什么是软件界面
常用输入设备
常用输出设备
以人为本
1、不要让用户难以学习
2、不要让用户感到厌烦
3、不要让用户感到恐惧
4、不要让用户难以捉摸
原型设计
1、手画法
2、Office工具设计法
3、原型工具设计法
4、开发工具设计法
5、直接开发法
开发模型
一般步骤
1. 需求调研
2. 原型设计
3. 原型评审
4. 根据用户反馈修改原型
5. 重新评审
6. 用户确认
7. 根据原型开发软件
注意事项
1.与用户沟通要有个度，过犹不及。
2.用户的意见很重要，但并不总是正确的。
3.从用户的意见中发现设计稿存在的问题，而不是解决方法。
4.不同的项目，可以采用不同的评审方式。
界面设计过程
入口设计
1、功能菜单
2、工作台
3、九宫格
4、弹出菜单
5、快捷方式
功能主界面设计
1、上边查询条件，下边查询结果
2、左边大项，右边查询结果
3、左边树状结构，右边查询结果
4、上边主表，下边子表
5、左边主表，右边子表
6、树形列表
7、分级列表
8、日历
表单布局设计
常用方式：
1、平铺
2、分组
3、动态加载
4、表格
5、Tab页
6、混合
注意点：
1、合理安排界面空间
2、突出重点
3、信息展现要有层次感
4、注意组件顺序
操作设计
查询类界面
表单类界面
消息设计：
消息弹出框
消息区
日志
其他方式
界面优化
易学性
1、提炼核心功能
2、追随主流软件
3、贴近业务流程
4、统一操作习惯
5、减少用户干预
6、倡导边干边学
易用性
1、 让功能方便调用
2、 让工作容易处理
3、 减少用户录入
4、 减少按键此数
5、 减少在键盘与鼠标之间的切换
健壮性
1、 不让用户犯错误
2、 让用户少犯错误
3、 让用户容易发现错误
4、 允许用户纠正错误
5、 降低用户错误的影响面
交互性
1、重要操作需要确认
2、不要让用户有石沉大海的感觉
3、消息是给用户看的，不是给程序员看的
4、消息需要精准
5、交互要适可而止
6、不要滥用弹出框
小结
重点
理解人机交互要强调“以人为本”（ ★ ★ ★ ★ ★ ）
常用的原型设计方式（ ★ ★ ）
界面设计包括哪些过程（ ★ ★ ★ ★ ）
常用的功能主界面（ ★ ）
常用的表单布局方式（ ★ ）
易学性优化（ ★ ★ ★ ★ ★ ）
易用性优化（ ★ ★ ★ ★ ★ ）
健壮性优化（ ★ ★ ★ ）
交互性优化（ ★ ★ ★ ）
思考
除了书中提到的功能入口方式，你还看到过什么不同的入口方式？
就界面优化的方式，分析一下微信的“摇一摇”功能。
仔细分析微信App，从易学性、易用性、健壮性、交互性几个方面阐述软件设计者的设计思想。
设计图书出借的功能界面。就你的设计，你觉得有哪些方面需要跟用户沟通确认？
就上题图书出借的功能界面，从易学性、易用性、健壮性、交互性几个方面说明自己的设计思想。
0 条评论
下一页
