未验证 提交 2e70be4f 编写于 作者: X xiaowuhu 提交者: GitHub

Xiaowuhu/20201015 (#576)

* add more

* Update 6.2 需求技术分析.md

* update

* Update 6.2 需求技术分析.md

* add more

* Update 6.2 需求技术分析.md

* add more

* add more

* fix

* change the order

* modify order

* add more

* Update 6.5 功能流程模型.md

* add more

* add more

* add

* add more

* order changed

* add more

* add more

* add more

* fix

* add more

* change folder

* modify structure

* modify

* add more

* Update 6.10 非功能性的需求分析.md
Co-authored-by: NXiaowu Hu <xiaowuhu@microsoft.com>
上级 81159f28
书名:架构之路
作者:胡晓武 ......
斯博士说:"作者写书的目的绝对不是为了成就作者,而是为了成就每一位读者。" 很多作者在写作的时候,往往需要收集整理大量资料,然后把自己认为最重要最正确的精华呈现出来。但是!这样做的问题是,经过萃取的东西,一般读者是看不懂的。
# 需求技术分析
面向对象的分析技术
## 用例图
## 数据流图
## 流程图
## 状态迁移图
# 需求调研
需求调研
需求引导
需求来源
可行性分析
软件系统的需求包括3个不同的层次:
- 业务需求
- 用户需求
- 行为需求
其中,行为需求又包括:
- 功能需求
- 非功能需求
【slide】
需求调研的任务,就是通过各种方法,根据业务需求获得用户需求。
需求分析的任务,就是通过各种方法,根据用户需求得到行为需求。
这一章我们讲述需求调研的各种方法。
# 典型用户的故事分析
*这个图也许可以放在别的地方,这里已经很大信息量了*
我们先请出软件业界著名的秋千图:
<image src="Images/swing.png">
|序号|标题|解读|
|--|--|--|
|1|客户的描述|挂在树上供三个孩子玩耍的秋千|
|2|项目经理的理解|两根绳子拴在树上,挂一个木板|
|3|分析员的设计|修改支撑系统的结构以便让秋千能晃动|
|4|程序员的实现|实现了静态拓扑结构设计:绳、树、木板|
|5|商业顾问的描述|舒适无比、光芒四射|
|6|项目文档|空空如也,如云如烟|
|7|上线的产品|缺东少西,不知所云|
|8|客户投资|巨大得可以修建一个游乐场了|
|9|技术支持|少之又少,无依无靠|
|10|用户的真实需求|树杈+绳子+轮胎|
需求挖掘是一切软件的起源,差之毫厘,谬之千里。在秋千图的例子中,各个环节的误差导致了彻底的失败。
在郭德纲的相声《梦中婚》里,客户需要挖一口井,但是工程人员把图纸拿反了,最后盖了一个烟囱,一边盖一边还纳闷儿:这个烟囱这么设计的这么粗?
以上都是夸张的例子,我们再来分析一下木头是如何做需求挖掘的。
## 用户画像
(Persona模型)
......@@ -45,6 +21,24 @@
|4|职业|专业需求|主管级研究员老张|
|5|专家|深度需求|大佬 Harry|
Persona 用户画像,古希腊罗马戏剧中的面具$^{[1]}$。
中国的传统戏剧如京剧中有所谓的脸谱,不同的人物性格就用不同的脸谱予以直观的表示。古代希腊、罗马的戏剧中也有类似的表现手法,不过不是脸谱,而是面具,不同角色戴不同面具。佩戴面具可以解决一人分饰多角的问题,还能克服剧场条件限制,使远处的观众辨别出角色的形象和表情。
这种面具,拉丁文就叫做 persona 。正因为如此,persona 渐渐成了戏剧中的“人物角色”的意思。由于每个人在社会生活中都要扮演一定的人格角色,所以 persona 就从戏剧中的“人物角色”延伸为表示人在社会生活中的人格角色,从而产生了英语单词 person 。
在用户界面设计领域,Alan Cooper 提出来的一种通过调研和问卷获得的典型用户模型,用于产品需求挖掘与交互设计的方法。把这个词分解为7个单词的词头,虽然略为勉强,但也起到了帮助人们记忆的目的。
|字头|单词|直译|从设计角度的解释$^{[2]}$|
|--|--|--|--|
|P|Primary|基本性|该用户角色是否基于对真实用户的情景访谈|
|E|Empathy|同理性|用户角色中包含姓名、照片和产品相关的描述,该用户角色是否引同理心|
|R|Realistic|真实性|对那些每天与顾客打交道的人来说,用户角色是否看起来像真实人物|
|S|Singular|独特性|每个用户是否是独特的,彼此很少有相似性|
|O|Objectives|目标性|该用户角色是否包含与产品相关的高层次目标,是否包含关键词来描述该目标|
|N|Number|数量性|用户角色的数量是否足够少,以便设计团队能记住每个用户角色的姓名,以及其中的一个主要用户角色|
|A|Applicable|应用性|设计团队是否能使用用户角色作为一种实用工具进行设计决策|
## 军儿哥
军儿哥根本不是我们这个软件的使用对象,所以就不要费力气了,和他聊聊天气就可以了。
......
......@@ -26,7 +26,7 @@
1. 是一个网站,可以部署在校园网或者 Azure 上;
2. 要求白天时段运行,即 5x8 小时;
3. 支持并发用户数最大为两个班的同学数量(因为这类系统比较贵,学校只能配备一两个电教教室);
4. 需要有可手写的宽屏幕,如 Surface Hub(微软的手写大屏幕硬件,配有定制的 Windows 10 操作系统);
4. 需要有可支持手写(笔)的宽屏幕,如 Surface Hub(微软的手写大屏幕硬件,配有定制的 Windows 10 操作系统);
5. 手写(笔)数据可以保存为矢量或者图像,作为板书记录;
6. 系统是 Windows 操作系统,可以安装 Office 办公套件;
7. 系统本身可以上网,或连接 Azure;
......
# 需求分析
需求分析解决“做什么”的问题,系统设计解决“怎么做”的问题。
需求调研的任务,就是通过各种方法,根据业务需求获得用户需求。
需求分析的任务,就是通过各种方法,根据用户需求得到行为需求。
这一章我们讲述需求分析的各种方法。
需求分析的准则:
1. 必须理解和表示问题的信息域,根据这条准则应该建立静态结构模型。
2. 必须定义软件应完成的功能,这条准则要求建立功能流程模型。
3. 必须表示作为外部事件结果的软件行为,这条准则要求建立动态行为模型。
4. 必须对描述信息、功能和行为的模型进行分解,用层次的方式展示细节
从数据角度对现实世界建立信息模型。大型软件较复杂;很难直接对其分析和设计,常借助模型。模型是开发中常用工具,系统包括数据处理、事务管理和决策支持。实质上,也可看成由一系列有序模型构成,其有序模型通常为功能模型、信息模型、数据模型、控制模型和决策模型。有序是指这些模型是分别在系统的不同开发阶段及开发层次一同建立的。建立系统常用的基本工具是E—R图。经过改进后称为信息建模法,后来又发展为语义数据建模方法,并引入了许多面向对象的特点。
\ No newline at end of file
# 需求分析的重要性
需求分析是软件生命周期中相当重要的一个阶段。
【slide】pie chart
1999年,美国专门从事跟踪 IT 项目成功或失败的权威机构 Standish Group,对23000个项目进行的研究结果表明,28%的项目彻底失败,46%的项目超出经费预算或者超出工期,只有约26%的项目获得成功。
而在这些高达74%(28% + 46%)的不算成功项目中,有约60%的失败是源于需求问题,也就是差不多有一半的项目都遇到了这个问题,这一可怕的现象引起人们对需求分析的高度重视。
需求分析阶段的主要任务是通过需求分析人员与用户之间的广泛交流,不断澄清一些模糊的概念,最终形成一个完整的、清晰的、一致的需求说明。
## 国外故事:秋千图的例子
我们先请出软件业界著名的秋千图:
<image src="Images/6-Swing.png">
(给每个子图加上序号)
|序号|标题|解读|
|--|--|--|
|1|客户的描述|挂在树上供三个孩子一起玩耍的秋千|
|2|项目经理的理解|两根绳子拴在树上,挂一个木板|
|3|分析员的设计|修改支撑系统的结构以便让秋千能晃动|
|4|程序员的实现|实现了静态拓扑结构设计:绳、树、木板|
|5|商业顾问的描述|舒适无比、光芒四射|
|6|项目文档|空空如也,如云如烟|
|7|上线的产品|缺东少西,不知所云|
|8|客户投资|巨大得可以修建一个游乐场了|
|9|技术支持|少之又少,无依无靠|
|10|用户的真实需求|树杈+绳子+轮胎,可以供该客户的三个孩子玩耍|
需求调研与分析是一切软件的起源,差之毫厘,谬之千里。在秋千图的例子中,各个环节的误差导致了彻底的失败。
1. 首先,客户的描述是“我的三个孩子可以一起玩耍”,根据客户的描述,这个秋千必须可以同时容纳三人。显然这个描述是不准确的:“一起”的含义并不是三个孩子同时在秋千上,有可能是一个孩子在秋千上,两个孩子在地上推秋千。
2. 项目经理没见过三层的秋千,但是他觉得只要秋千的踏板足够宽,可以站好几个孩子。另外,如果想保证安全的话,两根绳子最好能拴在两个树杈上,这样可以分担承重。
3. 分析师认为分担承重的需求很重要,但是如果秋千需要前后晃动,必须有空间,那就不得不把树锯开。当然左右各加一个支撑是必须的,这样系统可以保持稳定。
4. 程序员的实现完全符合秋千的静态拓扑结构:两根绳子拴住树干上,下面挂一个踏板。至于秋千的动态模型可以后期再考虑。
5. 产品快成型了,市场人员坐不住了,开始到处宣传:我们的产品非常的安全和舒适,孩子们就好像是坐在沙发里一样,家长不必有任何担心。
6. 没有人写文档,需求、设计口口相传,导致各个环节都出现误差。
7. 工程人员自己家里也有简易秋千,一根绳子就可以搞定。所以在安装产品时忘记带踏板了,那就索性只挂一个绳索,这样孩子们依旧可以愉快地攀爬。
8. 客户抱怨,为此项目一再增加投入,最后发现累计投入可以建造一座游乐场了。
9. 后期的技术支持认为:客户的抱怨是有道理的,我们应该把树砍掉,让客户建造游乐场。
10. 其实客户的真实需求只是一根绳索下面挂一个旧轮胎。
## 国产故事:烟囱和井的例子
【slide】
在郭德纲的相声《梦中婚》里,客户郭师傅需要挖一口井,但是工程人员把图纸拿反了,最后建了一个烟囱,一边干一边还纳闷儿:这个烟囱为什么设计的这么粗?
其实,有很多机会可以避免这个错误,而且可以轻易觉察。但是如果对应到软件开发上,就没有那么容易了,这要求在软件开发中有严格的流程管理和及时(通过scrum meeting)沟通。
【slide】
1. 包工头作为中间环节没有给上下游交代清楚。包工头在这里可以对应到需求分析人员,他如果拿着图纸(需求规格说明书)和客户确认一下需求,或者直接告诉施工方(开发人员)客户是要挖一口井,也不会出现这样的错误。
2. 文档不严格,不完整。如果在图的上方注明《郭师傅家的深井挖建工程图》,除非工人是文盲,否则也不会拿反图纸。
3. 施工人员拿到图纸后,针对对图中的疑点,及时和包工头沟通。开发人员看到需求规格说明书后,可能有他自己的理解(和秋千图的例子一样),针对任何疑点,都要及时与需求分析人员沟通。
4. 施工人员及时与客户现场沟通。在软件开发中,客户通常是看不到软件的样子的,这和烟囱的例子不可类比。所以,更要求开发人员及时做好产品原型(prototype)交给需求分析人员(包工头)和客户(郭师傅)进行确认。
5. 包工头经常来现场检查工程进展。需求分析人员在完成文档后,并非就完成工作了,而是要阶段性地和开发人员进行交流,监督、检查进度、质量以及需求满足情况。
## 需求分析的特点及难点
需求分析的特点及难点,主要体现在以下几个方面。$^{[1]}$
1. 定位困难
主要原因一是应用领域的复杂性及业务变化,难以具体确定;二是用户需求所涉及的多因素引起的,比如运行环境和系统功能、性能、可靠性和接口等。
2. 需求常变
软件的需求在整个软件生存周期,常会随着时间和业务而有所变化,如客户环境和业务流程的改变,市场趋势的变化等,也会随着分析、设计和实现而不断深入完善,可能在最后重新修订软件需求。
3. 交流困难
需求分析涉及的人事物及相关因素多,与用户、业务专家、需求工程师和项目管理员等进行交流时,不同的背景知识、角色和角度等,使交流共识较难。
4. 认知矛盾
由于不同人员对系统的要求认识不尽相同,所以对问题的表述不够准确,各方面的需求还可能存在着矛盾。难以消除矛盾,形成完备和一致的定义。
### 参考资料
- [1] 《软件工程》,清华大学出版社
# 非功能性的需求分析
在上一节中,我们分析了来自学校的教职员工的各个不同层次的需求,使我们清楚地认识到了业务、用户、功能三个层次的需求的区别和联系。在本节中,我们将会做进一步的扩展,把上述三个层次形成的一维关系扩展为二维关系,以便能够更准确地把握需求。
$$
需求 = 功能需求 + 非功能需求 \tag{6.10.1}
$$
$$
非功能需求 = 模糊需求 + 质量属性 + 约束条件 \tag{6.10.2}
$$
## 模糊需求
模糊需求一般在业务需求层次提出,常见的就是三个字:快、好、省。
【slide】
对于业务级投资人、负责人等领导来说,预期的质量需求就是三个字:快、好、省。这和当年的“多快好省”经济发展总路线如出一辙,实践证明是不能兼顾的。
1. 快,可以理解为开发速度快,或者软件运行速度快。
2. 好,可以理解为开发质量好,或者软件功能好。
3. 省,可以理解为开发成本低,或者软件价格低。
悖论:
1. 速度又快、功能又好的产品,价格肯定不低,做不到省。
比如说我们训练一个深度学习模型,如果用 GPU 的话,训练速度快,效果好,但是 GPU 的价格非常的昂贵。
2. 功能又好、成本又省的产品,不是开发周期长,就是运行速度慢。
同样是训练一个深度学习模型,用 CPU 当然也可以完成任务,但是使用 GPU 可以一小时搞定的东西,用 CPU 却需要两天。
3. 速度又快、成本又省的产品,用膝盖想一想都能知道好不到哪里去。
还是训练深度学习模型,为了便宜就用 CPU 搞,为了速度快就少训练几轮,那么最后的模型效果肯定不好。
## 质量属性(Quality Attribute)
质量属性包含很多内容,我们将会在后面的章节中专门介绍,在本节中可以用公式 6.10.3 来简单表述:
$$
质量属性=性能+安全+可靠+其它 \tag{6.10.3}
$$
质量属性的项目非常多,但通常我们都用下面三个主要的属性来衡量软件的质量,而且是可以写在《需求规格说明书》中的。在公式 6.10.3 中用“其它”来代表不常用到的属性。
- 性能(Performance)
比如,我们可以要求一个软件:
- 用户登录响应时间不超过0.5秒;
- 可以支持并发访问用户数至少10000个;
- 系统至少可以存储100M的用户文件。
- 安全性(Security)
其实就是正反两个方面:
- 向合法用户提供服务;
- 阻止非授权使用。
- 可靠性(Reliability)
软件系统在一定的时间内无故障运行的能力,比如:
- 72小时小负载下可稳定运行;
- 30分钟内的超负荷运行;
- 4小时内负载从10%增加到100%的运行情况。
- 可维护性(Maintainability)
一般甲方会提出可维护性要求,但通常是比较虚的,比如:
- 要求乙方给甲方人员培训,熟悉系统架构和模块;
- 乙方在一年内保证软件顺利运行;
- 软件提供 API 接口,可以二次开发。
## 约束条件(Constraint)
【slide】
### 来自甲方 - 资源约束
客户总是会在下面几个问题上“斤斤计较”:
- 时间
- 即软件开发完毕交付的时间,而且如果客户不懂得软件开发的规律,往往会要求在不可能的时间内一次性交付。
- 而对于开发者来说,一定要争取宽裕的开发时间,通常是把预估的时间乘以2.比如预估3个月完成,那么就要和客户承诺6个月完成。
- 在交付问题上,一次性地不可能搞定所有需求,至少需要3次以上的迭代,在没有新需求出现的前提下,才有可能完成。
- 金钱
即开发软件、部署软件、后期宣传所需要的费用。
### 来自乙方 - 开发约束
主要是乙方要考虑自己的开发团队的具体情况,比如:
- 领域知识
开发人员对于目标软件所在的领域知识是否足够了解。比如要做一个银行系统的应用软件,一般银行都会找一个长期合作的软件开发商合作,避免领域知识的培训等额外工作。
- 技术水平
- 技术岗位繁多
如前端、后端,完全是不一样的编程思路。后端:入门难,深入更难,枯燥乏味,没有太大成就感,看一堆业务逻辑代码。前端:入门简单,先易后难,能看到自己做出来的展示界面,有成就感。
- 开发语言繁多
PHP 并不是最好的编程语言(这是业界流行的一个笑话),但是它和Java、C、C++、Python、C#、JavaScript等成为最流行的编程语言,一个开发人员能够熟练使用(不是精通)三种以上的编程语言,就已经很不错了。
- 框架平台繁多
会用 React 的就不用 Vue(二者都是JS前端框架),会用 Struts 的就不用 GWT(二者都是 Java 框架),会用 .NetFramework的就不用 .NetFramework Core(二者都是 C# 框架),等等。
- 团队情况
一个糟糕的经验是:三个臭皮匠,顶个诸葛亮。一个合理的做法是:一个诸葛亮带三个臭皮匠。
- 成员磨合程度,主要是在工作习惯、沟通能力方面的考量。一个团队有新人加入的话,在初期,往往是拉低团队的生产力;如果新人很多,磨合期就要预计长一些。
- 成员地理分布,主要是指像微软这种跨国公司,经常有跨区域合作的情况。比如做手机上的 Edge 浏览器时,PM 主要在美国,开发人员主要在中国,但是分在北京和苏州两个地方,还有一些依赖模块在欧洲开发。这需要制定好接口,并协调多方的进度保持一致。
### 来自环境 - 技术约束
- 批准的技术清单
许多大型组织在开发之前,都会列出一个可以使用的技术清单。如果你需要使用清单上没有的技术,就需要申请。
- 现有系统的互操作性
会规定在整合已有系统的时候可以使用的协议和技术。
- 目标部署平台
目标部署平台是影响技术决策的主要因素之一。比如 Windows 和 Linux 的不同,再比如桌面软件和移动软件的区别。
- 技术成熟度
有些组织喜欢采用有风险的尖端技术,而有些组织则比较保守。
- 使用开源软件
GPL(General Public License)协议规定,如果使用了它人的开源软件,那么自己的软件必须也开源。
### 来自领域 - 业务约束
- 行业标准
- 比如中国的财务软件就有自己的数据接口标准,否则会出现任意两个软件之间的数据交换困难。这就要求在需求中提及“输出必须符合接口标准”。
- 另外一个例子是目前的深度学习框架,如TensorFlow, PyTorch,MXNet等,都有自己的模型结构,无法互操作。微软开发了 ONNX(Open Neural Network Exchange,开放神经网络交换)格式的模型标准,可使得模型在不同的框架下使用。目前官方支持 ONNX 格式的框架有:Caffe2、PyTorch、MXNet、ML.NET、CNTK,而TensorFlow非官方(开源方式)支持。
- 政策法规
举两个例子:
- 微软对用户的隐私问题非常的重视,所以在任何系统中,都不能保存能够反向映射到一个自然人的用户日志;
- 中国对地图数据的安全性有要求,不能存放在中国境外的服务器上。所以当年笔者得到了一个进入微软做国内地图数据处理的工作机会,从心里感激这个政策法规。
# 需求规格说明书
需求规格说明书(SRS,Software Requirement Specification)。
在微软,通常把需求规格说明书称作Functional Spec(Specification,规格说明书)、Feature Spec。因为这是 PM 需要完成的工作,所以经常叫做 PM Spec。
需求规格说明书是需求分析阶段完成后的输出。
......@@ -26,24 +28,6 @@
## Persona/Scenario 典型用户与场景
Persona 用户画像,古希腊罗马戏剧中的面具$^{[1]}$。
中国的传统戏剧如京剧中有所谓的脸谱,不同的人物性格就用不同的脸谱予以直观的表示。古代希腊、罗马的戏剧中也有类似的表现手法,不过不是脸谱,而是面具,不同角色戴不同面具。佩戴面具可以解决一人分饰多角的问题,还能克服剧场条件限制,使远处的观众辨别出角色的形象和表情。
这种面具,拉丁文就叫做 persona 。正因为如此,persona 渐渐成了戏剧中的“人物角色”的意思。由于每个人在社会生活中都要扮演一定的人格角色,所以 persona 就从戏剧中的“人物角色”延伸为表示人在社会生活中的人格角色,从而产生了英语单词 person 。
在用户界面设计领域,Alan Cooper 提出来的一种通过调研和问卷获得的典型用户模型,用于产品需求挖掘与交互设计的方法。把这个词分解为7个单词的词头,虽然略为勉强,但也起到了帮助人们记忆的目的。
|字头|单词|直译|从设计角度的解释$^{[2]}$|
|--|--|--|--|
|P|Primary|基本性|该用户角色是否基于对真实用户的情景访谈|
|E|Empathy|同理性|用户角色中包含姓名、照片和产品相关的描述,该用户角色是否引同理心|
|R|Realistic|真实性|对那些每天与顾客打交道的人来说,用户角色是否看起来像真实人物|
|S|Singular|独特性|每个用户是否是独特的,彼此很少有相似性|
|O|Objectives|目标性|该用户角色是否包含与产品相关的高层次目标,是否包含关键词来描述该目标|
|N|Number|数量性|用户角色的数量是否足够少,以便设计团队能记住每个用户角色的姓名,以及其中的一个主要用户角色|
|A|Applicable|应用性|设计团队是否能使用用户角色作为一种实用工具进行设计决策|
有了典型用户后,就要把该用户“放进”具体的应用场景中。Scenario 的意思,就是要把用户放进一个真实的故事片段中,来检验其可行性。
比如前面所述的木头与神经网络课程的故事,用典型用户木头(老师)和毛毛(学生)作为故事的主角,串连起了两个故事片段,在故事中提及了大量的电教课程细节,都可以使用微软提供的技术方案来解决。
......@@ -69,6 +53,10 @@ Function 和 Feature 不是同一层意思:
*本软件要求在 Windows 10 操作系统上运行,可以管理多达 32 个类别和每个类别中最多 1024 篇论文。要求显示屏物理分辨率至少为 1920x1080。*
*推理子系统的性能要求在20毫秒以下。*
*网站允许200个用户并发,每个用户的响应时间为50毫秒。*
## UI/UX 用户界面与交互
复杂软件的用户界面和交互,是需要 Designer 参与的,会提供全套的界面元素设计和交互设计。如果是简单的功能,PM 可以根据以有的界面元素直接给定。
......
# 需求类别分析
# 需求语义分析
需求语义分析,就是通过记录用户诉求(文字的或语言的),仔细领会用户的真实意图和工作流程。具体的方法可以有以下几种:
- 小组讨论
- 卡片分类
- 单据报表分析法
## 小组讨论
项目小组成员通过任何形式获得用户需求,回来后自己内部开会,对需求进行讨论,目的如下:
- 把抽象的需求具体化
- 用户:“这么多论文乱七八糟的,根本没法找!”
- 毛毛:“我觉得用户并不喜欢读很多论文。”
- 木头:“需要论文分类管理功能,可能是根据类别、会议或者日期。”
*解释:用户的需求有时是用情绪化的语言形式表达出来的。*
- 用计算机专业词汇描述需求
- 用户:“把这个论文好好的保管好,以后还要用。”
- 用户:“这个论文很有价值,以后还要再看。”
- 毛毛:“给论文加一个类似豆瓣评分的级别。”
- 木头:“按日期保存论文到系统指定的存储位置,并可以根据日期和名称检索。”
*解释:需求文档要明确指出存储、检索的功能。*
- 避免需求理解偏差
- 用户:“这个游戏软件主要是面对儿童的,比如我,希望家里的三个分别为7岁、10岁、12岁的孩子都可以玩。”
- 实习生毛毛:“用户希望如果一个家庭有三个孩子的话,可以同时玩这个游戏。”
- 毛毛:“用户希望如果一个家庭有三个孩子的话,可以同时玩这个游戏。”
- 木头:“别闹,用户是希望各个年龄段的孩子都可以玩。”
*解释:用户的举例通常带有实例化性质,需求文档需要泛化这些需求。比如该用户家的三个孩子恰巧都是男孩儿,或者该用户家的孩子的身高比同龄人的平均身高要高,这些都需要广泛调查后再确定目标用户。其实在著名的秋千图的例子里,用户的原始想法是用一个橡胶轮胎挂在树上做秋千,这样他的三个孩子都可以玩儿。但是需求分析人员把“三个孩子都可以玩儿”理解为“三个孩子可以同时玩儿”,于是设计了一个三层的木板结构。*
- 确定需求边界
- 用户:“能不能加两个人手,在这个月就把那个云端同步的功能也一起做了?”
- 木头:“对不起,我们本期的需求已经确定了‘论文注释‘功能只在客户端保存,开发计划已经排满了。况且云端同步功能还需要购买 Azure 资源,这部分也不在预算内。”
- 毛毛:“云端同步的功能,只是把客户端的注释标记上传到云端保存而已,好像没有很大的工作量。”
- 木头:“对不起,我们本期的需求已经确定了‘论文注释’功能只在客户端保存,开发计划已经排满了。况且云端同步功能还需要购买 Azure 资源,这部分也不在预算内。”
*解释:用户总希望少花钱多办事,而市场人员往往为了订单随口承诺一些事情,需求文档需要明确这些边界。做计划外的功能,会影响计划内的软件的质量,和一些不可预估的如预算、设备、部署等方面的麻烦。*
- 识别错误需求
- 用户:“这个论文最好还能保存成 Word 格式,便于修改。”
- 木头:“你......我......人家发表的论文你改哪门子改?”
- 用户:“这个论文最好还能保存成 docx 格式,便于修改。”
- 毛毛:“保存成 docx 功能还能用 Word 打开阅读,很方便。”
- 木头:“你......我......人家发表的论文你改什么改?”
*解释:对用户的一些需求,需要分析它的背后的含义,再确定其正确性。*
- 识别真实需求
- 用户:“我批改了这篇论文,我想把我的意见通过电子邮件转达给其它人。”
- 木头:“您实际上是想通过网络的方式把您的意见快速准确地转达给其它人,那不如我们后期考虑在 Azure 上搭建一个服务器吧,这样大家都可以分享自己的见解。”
- 毛毛:“电子邮件是无纸办公的重要手段,倒是可以考虑增加这个功能。”
- 木头:“用户实际上是想通过网络的方式把自己的意见快速准确地转达给其它人,那不如我们后期考虑在 Azure 上搭建一个服务器吧,这样大家都可以分享自己的见解。”
*解释:就如同亨利福特遇到的情况,用户希望有一匹快马,但其实用户需要的只是“快”,而不是“马”,“快”是真正的需求,“马”只是载体,所以福特开始造新的载体——汽车。理解用户的真实意图,用自己的专业知识提供解决方案。*
......@@ -53,15 +64,15 @@
- 快速理解功能要点
-用户角度可以清楚这个软件可以提供什么类型的功能,而不是乱糟糟地堆砌一堆功能
-客户角度可以清楚这个软件可以提供什么类型的功能,而不是看到乱糟糟堆砌的一堆功能,这可以帮助客户建立对这个软件的质量方面的信心
- 需求分析人员可以从已有分类中开拓思路,设计出一个惊喜型的功能。
分类设定,其实对人类的思维是一个双刃剑。木头的感觉是,很容易陷入这些条条框框里,陷入其中不能自拔。另一方面,也可以帮助需求分析人员仔细研究每个类别里的功能,找出缺失的部分,或者找出缺失的类别,来开发出惊喜型功能。
分类设定,其实对人类的思维是一个双刃剑。木头的感觉是,很容易陷入已定类别中不能或者不敢突破。另一方面,也可以帮助需求分析人员仔细研究每个类别里的功能,找出缺失的部分,或者找出缺失的类别,来开发出惊喜型功能。
- 开发人员可以快速学习领域知识,理解真正的需求。
木头自己就通过这次分类整理,真正地认识到了浏览器功能的全貌,一旦有了“上帝视角”,会不由自主地感叹到:“原来如此,那么浏览器那个组的几百号儿人,这些年都做了什么,为什么 Edge 浏览器口碑越来越差?”。话音未落,浏览器组先是换了一个大老板,紧接着决定用 Chromium 做引擎,重新写 Edge 浏览器的 Shell,而这个大老板,就是以前在 Windows Team 负责 Shell 的
木头自己就通过这次分类整理,真正地认识到了浏览器功能的全貌,一旦有了“上帝视角”,会不由自主地感叹到:“原来如此!那么浏览器那个组的几百号儿人,这些年都做了什么,为什么 Edge 浏览器口碑越来越差?”。话音未落,浏览器组先是换了一个大老板,紧接着决定用 Chromium 做引擎,重新写 Edge 浏览器的 Shell,而这个大老板,就是以前在 Windows Team 负责 Shell 的,这说明了一个问题 —— 上层已经决定用 Chromium 做引擎,让一个对 Shell 很有经验的人去领导 Edge 项目的开发,在 Chromium 的基础上做一个微软风格的 Shell,成为新的 Edge 浏览器
- 模块功能整合
......@@ -92,7 +103,7 @@
传统行业中,往往存在一些手工填写的单据或报表,可以给流程控制提供很好的抽象信息,比如:银行的存款单、取款单,仓库的入库单、出库单,海关的报关单、提货单,企业的采购单、验货单,财务的资产负债表、损益表等等。
这些单据其实就是数据流图中的数据/文件部分,也可以做为数据设计的依据,但是其中肯定有很多冗余的项,需要用范式知识来解决。
这些单据其实就是数据流图中的数据/文件部分,也可以做为数据设计的依据,但是其中肯定有很多冗余的项,需要用范式知识来解决。范式知识我们将在后面介绍。
入库单示例
......@@ -101,9 +112,10 @@
|鼠标|LG302|个|1000|2020/09/01|12|2020/09/22|限量版|
|键盘|C104|个|200|2020/09/02|9|2020/09/23|京东专供|
如上面这个表单,作为一张纸质的原始表单来说,已经比较完善了。但是作为软件用的表单,还缺一个唯一的入库单号做主键,否则无法索引。
如上面这个表单,作为一张纸质的原始表单来说,已经比较完善了。但是作为软件用的表单,有两个地方要注意:
另外就是型号字段是个外键,需要设计另外一张表来描述 LG302 和 C104 的具体特性,如重量、体积、颜色、无线/有线、是否人体工程学设计等等。
1. 还缺一个唯一的入库单号做主键,否则无法索引。
2. 另外就是型号字段是个外键,需要设计另外一张表来描述 LG302 和 C104 的具体特性,如重量、体积、颜色、无线/有线、是否人体工程学设计等等。