需求分析与系统设计

第一步，需求分析。最初的需求一般来自产品经理，这些需求大多比较模糊，软件工程师需要和产品经理就每个细节进行充分沟通，明确最终要交付的是怎样一个产品，同时考虑到每个环节可能遇到的问题。

第二步，设计。设计是程序开发里非常重要的一环，具体细分为技术调研、原型设计、架构设计等。

第三步，编码。等到软件工程师弄清楚该怎么做了，就开始通过代码去实现设计里的内容，有很多有关编码的原则和方法。

第四步，测试。测试指的是一系列检验代码能否正常运行的方法，包括很多类型，比如单元测试、性能测试、集成测试，等等。

等到上面这些环节全部完成，一个程序才能正式发布上线。程序上线后免不了出现Bug，这时候还需要软件工程师不断修复和迭代。

一般来说，新人进入公司后，主要做的是执行层面的任务，这些任务只是整个软件工程里的一小部分，比如写个模块，修复Bug，相当于从最基础的工作做起。这个阶段你需要重点关注的是，第一，养成良好的工作习惯；第二，培养自己的执行能力——说白了，就是脚踏实地，做好工作中一点一滴的事情。

不要小看这两点，因为只有养成好的工作习惯，并且能够保质保量完成任务，一位软件工程师的单兵素养才算基本建立起来。越是复杂的系统工程，对单兵素养的要求就越高，软件工程师这一行尤其如此。

一般来说，新人通常集中于编码、测试、改Bug等工作，在上级的指导下把已经设计好的程序开发实现出来，或者是通过改Bug维护已有的程序。

一个网站开发项目就是一个软件工程。网站开发隶属于软件工程，开发流程为：需求分析→设计说明（细分为概要设计和详细设计）→代码编写→程序测试→软件交付→客户验收→后期维护。本讲分别从需求分析、设计说明的角度研究如何分析客户需求，并根据客户需求设计网站架构。

1、软件工程概述
软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好技术方法结合起来的学科。它涉及到程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。

2、软件工程阶段
定义阶段：可行性研究、初步项目计划、需求分析
开发阶段：概要设计、详细设计、实现、测试
运维阶段：运行、维护
3、软件需求
软件需求包括3个不同的层次――业务需求、用户需求和功能需求。除此之外，每个系统还有各种非功能需求。

（1）业务需求
业务需求（business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter或market requirement）文档。

（2）用户需求
用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径，也就是说用户需求描述了用户能使用系统来做些什么。

（3）功能需求
功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（behavioral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。

（4）系统需求
系统需求（system requirement）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。

业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。
功能需求记录在软件需求规格说明（SRS）中。SRS完整地描述了软件系统的预期特性。SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到SRS。
（5）非功能需求
除了功能需求外，SRS 中还包含非功能需求，包括性能指标和对质量属性的描述。其它非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。

质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。
约束（constraint）限制了开发人员设计和构建系统时的选择范围。
4、软件设计
软件设计是从软件需求规格说明出发，形成软件的具体设计方案的过程，也就是说在需求分析阶段明确软件是“做什么”的基础上，解决软件“怎么做”的问题。结构化设计方将把软件设计分为概要设计和详细设计两个阶段。

概要设计阶段的主要任务，通过分析需求规格说明对软件进行功能分解，确定软件的总体结构。
详细设计阶段确定每个模块功能所需要的算法和数据结构，设计出每个模块的逻辑结构。
软件设计阶段结束时的工作成果是软件设计说明书，它描述软件系统的组成模块结、模块间的调用关系，以及每个模块的输入、输出和详细的过程描述。

（二）商城需求说明
假设我们是一家软件开发公司，公司员工分别有需求工程师、网页设计师、前端工程师、后端工程师和测试工程师，现有一名客户想开发自家的购物平台，该客户拥有实体门店，专售母婴产品。大多数情况下，客户对网站平台的开发流程只有表面的认知，他们不会提出详细的需求，只会说出他们的目的，比如说“我只想有一个自家的购物平台，能让我的客户在线购买产品，好像淘宝那样就行了。”在实际开发中，我们肯定不能直接仿造淘宝交付给客户，毕竟客户有自己的实体门店，应结合门店现有的业务流程定制购物平台。

对于客户的精简需求，需求工程师需要深入了解客户的具体需求，比如了解客户现有的顾客量、产品类型、实体店的进销存管理方式等因素，这些都会影响网站设计模式，例如现有的顾客数量需要考虑网站的并发量、产品类型影响网站页面设计（如商品详细页的布局设计）、实体店的进销存管理方式影响商品库存管理，是否考虑缺货提醒、预售功能等。

需求工程师根据客户的实际情况，梳理并归纳以下需求要点：

（1）网站需要提供搜索功能，便于用户搜索商品。
（2）搜索结果需要根据销量、价格、上架时间和收藏数量进行排序。
（3）商品详情应有尺寸、原价、活动价、图片展示、收藏功能和购买功能。
（4）用户购买后应看到订单信息，订单信息包括支付金额、购买时间和订单状态。
（5）商品购买应支持在线支付，如支付宝或微信支付等功能。
（6）目前顾客数量约有3000人，实体店暂无进销存系统。

在需求分析阶段，需求工程师要不断地与客户反复交流，并将交流结果以Demo的方式展示给客户，直到客户确认无误为止。在此阶段，需求工程师需要使用简单的绘图软件完成Demo设计，比如Axure或Visio等软件。除此之外，需求工程师还要将收集的需求信息编写成需求规格说明书。

（三）设计说明
当我们完成客户的需求分析之后，下一步是执行系统的设计说明，它包括了概要设计和详细设计。概要设计划分为系统总体结构设计、数据结构及数据库设计、概要设计文档说明。详细设计是对系统每个功能模块进行算法设计、业务逻辑处理、网页界面设计、代码设计等具体的实现过程。

1、概要设计
在概要设计阶段，系统总体结构设计需要由需求工程师和开发人员共同商议，针对用户需求来商量如何设计系统各个功能模块以及各个模块的数据结构。我们根据用户需求，网站的概要设计说明如下：

网站首页应设有导航栏，并且所有功能展示在导航栏，在导航栏的下面展示各类的热销商品，当单击商品图片时即可进入商品详细页面，导航栏上方设有搜索框，便于用户搜索相关商品。
商品列表页将所有商品以一定规则排序展示，用户可以从销量、价格、上架时间和收藏数量设置商品的排序方式，并且在页面的左侧设置分类列表，选择某一分类可以筛选出相应的商品信息。
商品详细页展示某一商品的主图、名称、规格、数量、详细介绍、购买按钮和收藏按钮，并在商品详细介绍的左侧设置了热销商品列表。
购物车页面只能在用户已登录的情况下才能访问，它是将用户选购的商品以列表形式展示，列表每行数据包含了商品图片、名称、单价、数量、合计和删除操作，用户可以增减商品的购买数量，并且能自动计算费用。
个人中心页面用于展示用户的基本信息及订单信息，只能在用户已登录的情况下才能访问。
用户登录注册页面是共用一个页面，如果用户账号已存在，则对用户账号密码验证并登录，如果用户不存在，则对当前的账号密码进行注册处理。
数据库使用MySQL 5.7以上版本，数据表除了Django内置数据表之外，还需定义商品信息表、商品类别表、购物车信息表和订单信息表。
从概要设计看到，我们大概搭建了网站的整体架构，下一步是在整体架构的基础上完善各个功能模块的细节内容。在详细设计中，网站开发最主要的是完成网页设计和数据库的数据结构，如果某些功能涉及复杂的逻辑业务，还需编写相应的算法。