在软件行业中，“设计”一词既熟悉又陌生，理论上大家都知道软件开发前需要做设计，但是具体要说明什么是设计、设计包括的内容、方法、交付物、标准以及由谁来设计时，却又说不太清楚（除去一些大型软件企业外）。多数的软件公司没有“设计师”的岗位，甚至都没有设置设计环节，特别是在中小型的软件公司，需求调研完成直接交给程序员是普遍现象。一般来说这样的软件公司的业务架构图、界面原型设计等工作都是由需求工程师来完成的。有鉴于此，这里简单地介绍一下需求工程师在从事“设计角色”时需要的能力。
图1 设计工作的位置
设计工作的内容可以分为二大部分
□非技术部分：包括了业务设计、应用设计两个部分（需求工程师要掌握，本文重点）
□技术部分：技术设计（开发工程师要掌握，本文不涉及）
第三篇介绍对需求工程师设计能力的要求
怎么判断需求工程师是否做了“设计岗位”的工作呢？严格的说开发工程师（程序员）应该是按照设计规格书进行编码开发的。如果你所在的软件公司在需求工程师和开发工程师之间没有“设计师岗位”，那么开发工程师就一定是依据需求工程师编制的【需求规格说明书】进行编码开发的，此时就可以判断：需求工程师在调研分析需求的同时，也做了包括业务设计、应用设计等在内的设计工作（技术设计是由懂得技术的开发工程师完成的）。
1. 设计目的
设计工作的目的是将前面需求分析的结果，按照软件实现的要求细化为具体的架构图形、功能界面原型、数据关系图以及支持开发的说明文字等资料。
所有的系统相关人（客户、咨询/需求、程序员、测试、实施等）通过这个设计资料，在软件开发完成前就可以准确地了解未来的系统，如根据这个设计资料可以知道：
□系统具有什么功能、运行方式、给客户工作带来的变化效果等。
□系统实现的技术路线、实现方案、测试用例等
□所需编码资源、进度计划、交付内容等。
设计工作是搞清楚怎么做什么系统的过程。
2. 设计作用
1） 设计工作的作用
设计工作的作用可以分为几个方面来来理解。
（1）业务设计
决定了产品的“可用性”，业务设计正确说明系统可用。业务设计是参照客户的实际工作，确定具体的业务逻辑、数据逻辑、业务功能等，比如报销模块的设计内容：报销流程（业务逻辑）、报销数据来源（数据逻辑）、报销操作界面（业务功能）。设计结果的正确与否直接关系到这个系统是否可用，因此业务设计正确是系统建设的基础。
（2）应用设计
决定了产品的“易用性”，应用设计正确说明系统好用。应用设计重点关注的是系统设计是否人性化、是否给客户带来工作效率的提升，比如：将系统从“人找事”设计成为“事找人”，这样的设计为客户带来工作环境的优化，大幅度提升工作效率，减少人为的工作失误，让系统自动地为用户提供服务。
（3）客户价值
软件的客户价值主要来源于业务设计和应用设计的成果，前者决定了业务价值的高低（系统带来的业务优化、改善、效益的提升）、后者决定了应用价值（系统带来的工作方式变化、工作效率的提升），特别是应用设计的结果极大地影响客户对系统的满意度。
（4）降低风险
设计工作做得越细致、具体，通过反复的“设计推演”，就可以避免开发完成后的返工，这是设计工作的一个非常重要的目的。
顺便说一句，由于软件行业普遍存在着对“设计工作”的重视不足，软件完成后大量的、频繁的返工是常见现象，其重要原因之一就是缺乏设计（或缺乏优秀的设计），开发前谁都不知道完成后的系统是什么样的（缺乏业务验证、应用验证），完成后一试用客户就会提出很多要修改的要求，系统不得不修改，甚至要推翻重来。
2） 需求工程师的作用
在没有设计师岗位的软件公司，需求工程师事实上是充当了“设计师”的角色。不论在哪个行业、也不论制作什么产品，设计师都是产品成功与否的关键角色，设计师的水平直接关系到了产品的水平、最终决定了产品的价值。在设计方面需求工程师的作用归纳如下（不限于此）：
□在前面咨询和调研角色将需要的素材和要求全部收集并确认完成，下面要由设计角色参照要求将需求素材与软件技术要求相结合，给出未来系统的设计图（设计资料）。
□设计工作是决定产品的关键，需求工程师要判断设计的正确性、可行性、合理性等。
□设计角色在系统开发过程中具有决定权，包括系统样式、规格、标准（业务和应用两方面），技术设计师和程序员原则上是不可以在未经许可的情况下改动设计。
□严格地讲，程序员不是按照需求，而是按照设计资料进行编码开发的；同理，测试工程师也是基于设计资料编写用例和测试的。
□将客户提出的需求，按照软件的要求进行，使得需求可以转换为软件系统的功能。
■可以说，需求工程师的工作成果是软件开发内容、客户满意度、软件价值的关键。
注：关于设计与架构的异同
“设计”是个大概念，设计包含了“架构”，架构工作属于设计全过程中的初期阶段，架构的主要内容是进行“规划、概要”等粗粒度的设计，其重点在对系统进行整体的规划、制定系统的设计理念、框架、主线、原则、标准等。一般谈到设计时，不但包括系统的整体架构，也包括详细设计（小到一个“字段”在界面上的摆放位置）。因此“设计师”的工作范围更加宽泛，而“架构师”的工作一般特指设计阶段的前期工作。
3. 设计能力
搞清楚了设计的目的和作用后，下面就要谈谈在这个阶段对需求工程师的能力要求。对需求工程师的设计能力要求与他和后面技术工程师之间的交付内容相关。作为设计角色，需求工程师要能够精准地给出业务和应用两个方面对系统的功能要求、标准。下面主要从两个方面谈一下：必备能力、专业知识。
1）必备能力
针对“设计师”的岗位，对需求工程师能力要求相对较高，他要掌握的能力比较综合，不是简单的看、听、说的单一能力等，而是思维能力和动手能力相结合的综合能力，这里举几项做个参考（不限于此）：
（1）规划能力
具有站在客户领导视角观察和理解问题的能力，可以从整体上理解客户需求（经营、管理和执行三层提出的需求），要能够同时考虑到：新系统与其它既有系统在空间上的关系、新系统今天的内容与明天的扩展在时间上的关系。
（2）建模能力
要能够从系统的视角对需求进行分析、抽提、找出规律，然后建立最简洁的业务处理模型。模型建立的好，则系统的架构合理、复用性强、容易实现、且对需求的应变能力也强。
（3）画图能力
毫无疑问，设计交付成果的重要形式就是图形（业务架构图、数据关系图、界面原型图等），看一眼图形基本上就可以判断出来设计者的水平，所以对需求工程师来说：用图形的方式能够正确地表达多少设计成果是非常重要的能力判断标准。
（4）逻辑能力
对于软件工程一阶段中的所有角色（咨询、调研和设计）来说，逻辑能力都是必不可少的，而且对于设计岗位的逻辑能力不但要体现在思维层面，更重要的是要将思维的结果用正确的图形表达出来，图形中的逻辑要清晰。
2）专业知识
需求工程师作为“设计师”的角色，在设计阶段需要的专业知识主要是指软件设计方面。包括：
（1）概要设计知识：根据前期的【需求规格说明书】对系统进行顶层设计，包括整体规划、设计理念、业务主线、技术路线、原则以及相应的规则和标准等内容。
（2）详细设计知识（业务）：根据【概要设计规格书】，对架构层、功能层和数据层的内容进行业务方面的细节设计，如业务建模、业务原型确定、字段定义、字典/看板/表单等的设计。
（3）详细设计知识（应用）：根据【概要设计规格书】，对架构层、功能层和数据层的内容进行应用方面的细节设计，如系统原型、流程机制、登录、门户、权限、以及系统易用性相关的设计。
（4）详细设计知识（技术）：不在对需求工程师能力的要求范围内（省略）。
（5）用例设计知识：前面设计的是否合理、正确、并满足客户需求呢？这里就需要进行用例设计，包括业务用例（检验业务设计部分的内容）、应用用例（检验应用设计部分的内容）。
（6）技术实现知识：对需求工程师虽不要求会编码，但是最好也能够掌握一定的系统构成、系统开发、系统测试等相关常识（越多越好），有了这方面的知识更容易判断客户需求与软件实现之间的合理性。
■能力，来源于将学习到的知识在实践中进行反复的应用、总结、积累。
4. 设计成果
设计成果包括了以上全部的设计资料
（1）概要设计规格书。
（2）详细设计（业务）的规格书、业务用例。
（3）应用设计（应用）的规格书、应用用例。
■设计小结
相比较于咨询和调研的工作内容来说，设计工作要求的难度可能比较大，需要的知识也比较多，但是在小规模的软件企业或是小型的软件项目中大都没有特定的设计师，因此需求工程师具有一定的设计能力就尤为重要。
■需求工程师的能力总结
至此关于需求工程师的能力要求就介绍完了，从上述的介绍中可以看出来，完美的系统开发除去需要大量优秀的程序员外，同样还需要很多优秀的需求工程师，没有需求工程师正确地完成上述工作（咨询、调研、设计），程序员的技术水平再高也无法得到优秀的产品。这两者的协同合作是完成系统的必要条件，不存在哪个为主哪个为辅为判断。
从图1上可以看出、需求工程师的前面是咨询师的岗位、后面是设计师的岗位，不论向哪个方向努力，都会有一个更高的岗位在等待着需求工程师。需求工程师的调研能力是咨询能力和设计能力的基础要求。
如果你在一个小型的软件公司、或是一个小项目里做事，那么上述所说的“咨询师、需求工程师、软件设计师”三者所需要的能力都要具备。
你从事的是其中哪个角色？是否打算成为一个全能的角色呢？
■关于软件设计，请参看李鸿君的“如何绘制逻辑图”、“界面设计方法”等系列博文。
本系列到此结束。关于详细的设计方法介绍，请参考《大话软件工程—需求分析与软件设计》一书。
