关于需求和原型的思考（2）
产品设计的过程，会经历三个阶段：可用，好用，用的爽。
产品的可用性，就像一个原始的瓢一样，可以拿来勺水，但是并不好用。后来在一代代人的改进中，给瓢加了一个把柄，人使用瓢变得更加的方便，这就是从可用到好用的进程。
1. 需求分析的过程
构建产品设计可用的过程，就是需求分析的过程，需求分析的过程产生需求说明书。
需求分析的过程，将梳理清楚业务需求，用户需求，并推导出软件需求。
image
例如：某城市由政府带领，公安部门牵头，完成城市的房屋、人口、以及单位信息采集，为城市精细化治理建立基础。这是一个业务需求。
而需要参与到信息采集过程的部门主要有：市政府相关工作人员，公安部门相关工作人员，以及各村网格员。他们需要做的事情，就是用户需求（5W1H）。
例如市政府人员需要发布数据采集任务，网格员需要到线下进行数据采集工作；数据管理员需要配合进行采集数据数量，质量等的管理工作。这些，都属于用户需求。
在用户需求确定了之后，我们要识别用户需求哪些是由系统完成的，进行详细的需求分析，并进行需求建模，构建可供开发使用的实实在在的软件系统。
例如，我们可能在系统的最初阶段，基于资金的短缺，只选择提供线上数据采集系统，辅助其中最核心，最多工作量的用户需求：网格员进行数据采集工作。
所以不是所有的业务需求，都会转化为软件需求，需要根据当时的业务目标，用户需求，以及资源条件等来决定哪些需求会纳入软件需求。
image
而需求分析的最后，将进行系统建模，确定如下内容：
- 软件目标
2. 建设内容范围
3. 系统环境上下文
4. 利益涉众
5. 系统使用用户
6. 系统活动图
7. 用例图
8. 用例规约
这些系统建模的要素，将作为需求规格说明书的核心内容。
而需求规格说明书，将作为系统架构师的系统构建输入条件，完成系统架构的设计。
由系统内容范围，构建系统大功能模块
由系统使用用户，以及系统活动图，构建系统类对象
由系统用例规约的业务流程，构建系统数据流转方式
由系统的上下文环境，以及其他的内容，综合构建系统技术架构，划分应用层，平台层，数据层等，按照不同系统类型做不同的架构层次划分。
在这里我们可以看下软件系统开发的发展历程，其实，一开始是没有软件产品设计人员的角色存在的。都是需求确定了，有需求文档，开发就可以开发了。而开发出来的软件，往往按照程序设计的方式进行构建，虽然能满足用户的实际需求，但是不包好用。就像插座厂商做出来的家用插座，给你提供两孔的插座位，也给你提供三孔插座位，但是，你用了两孔的，三孔的就没法插进去。用了三孔的，两孔的就没有办法插进去一样别扭。
软件需求说明书，只定义了“可用的产品”，但是它没有从用户的使用体验的角度上来构建“好用，用的爽”的产品。
所以在需求分析之后，我们需要进行产品的“用户体验设计”，构建产品“好用，用的爽”的过程。而这个过程也将输出产品交互原型，以及产品界面视觉。
