麦哲思科技

本文用简单的例子、通俗的语言概要解释了概念模型、逻辑模型与物理模型的区别。

很多项目组在设计文档中仅仅是把非功能性需求的描述拷贝到设计文档的非功能性章节。因此特地设计了两个简单的需求给大家参考，希望能够引导设计人员重视非功能性需求的设计。

业务流程图是用来描述客户业务作业方式的有效手段，它可以清晰地客户业务流程中涉及的人员角色、业务活动、业务数据以及他们之间的关系，是用来澄清需求的有效手段。

需求访谈的人员需要经过专门的训练，掌握需求访谈的技巧，才能在比较短的时间内，获取客户的真正需求，并且比较完备。那么，应该如何进行需求访谈呢，我根据需求访谈工作坊的练习结果及个人经验，整理了如下的18个注意事项。

需求用户需求时，应该有几个人参与呢？分别承担什么职责呢？怎么和用户澄清需求呢？三驾马车的做法可以帮你更高效地获取需求！

很多项目需求写的模糊，如何对这些模糊的需求进行澄清呢？通过哪些问题可以帮我们澄清需求呢？我设计了一个问题单供大家参考。

自20世纪70年代以来，M. M. Lehman通过对软件系统演化现象的观察，陆续总结了8条定律，称之为定律并非那么严谨，但是对于认识软件维护的规律，改进软件维护的过程具有很好的指导意义。1 （1974年）持续变更定律。系统必须持续调整以适应各种变化，否则这些系统将变得越来越不令人满意。2 （1974年）复杂度增长定律。随着系统的演化，其复杂度会逐渐增加，除非采取措施来降低或保持其复杂度。3 （1974年）自我调整定律。软件演化过程的是自调整的，每次演化版本的度量数据近似正态分布。4 .

笔者在咨询实践中总结了针对软件需求工程的12条最佳实践，罗列如下。所谓最佳并非严密的逻辑证明，而是经过大量的实践与观察依据经验确定的，智者见智，仁者见仁，有争议在所难免，仅供参考，能够对大家有所启发，足矣。1 成立甲乙双方参与的需求控制组项目的成功不单是乙方的成功，而是甲乙双方的成功，甲乙双方紧密配合，互相理解，互相合作才能成功，需要避免一方独大，一方具有绝对控制权的现象，所以成立甲乙双方参与的需求控制组是避免需求蔓延的有效手段。该组织具有对需求的决策权，对于每项需求的增删改都要平衡了进度、质量、投入后才能

<br />穷举、分类、分层、抽象是我推荐的4种分析问题的方法，即可以用于需求的分析，也可以用于其它的方面。<br /><br /><br />穷举就是罗列出所有可能的情况。当知道某一种可能的时候，要举一反三，列出所有的可能，针对问题的全集考虑解决方案。假如你考虑开发一个库存管理系统，有入库单、出库单、损溢单等3种类型的单据，有2种帐本：库存流水帐、库存成本帐。当考虑记帐的算法时就要考虑3*2=6种情况，也就是说要考虑6种算法，这就是穷举。在做软件需求分析时，尤其需要穷举的方法，确保需求的完备性。采用穷举的

1 先理解概念，再学习原则先理解OO的基本概念，比如：封装、继承、多态、组合/聚合、依赖等，理解各概念的内涵，弄清楚这些概念的具体实现方式及各实现方式的优缺点。2 先学习原则，再学习模式设计原则是蕴含在设计模式后最根本的思想，掌握了基本的设计原则可以做到不拘泥于某个具体的设计模式，可以更容易的理解设计模式，知道在何种情况下应该采用某种模式，可以自己创造合理的设计模式。设计原则可以参考的2本书籍是《

已发布接口（published interface）与公共接口（public interface） 表弟在读《重构》一书，对已发布接口的概念有些迷惑，我对其进行通俗的解释如下： 已发布接口是指已经发布出去为其他系统的构件所使用的接口，有多少接口的调用者是无法知道的，已发布接口必须保持稳定，否则一旦修改，将引起其调用者的失败，而又不可能穷举出其调用者对他们进行修改，因为接口的作者不知道有多少调用者，

十月一之后安排了我去培训《设计模式》，由于听众多为C与C++的新手，我想先从重构开始讲起，循序渐进，于是我决定仔细阅读〈重构〉这本书。 这本书我很久之前买的，当时大概读了读，感觉不错，就拿给了我表弟去读，他是程序新手。 这次是系统地读。 有个朋友曾经跟我说过，这本书不错，只是有点罗嗦，他是十多年经验的老程序员了，有此感觉很正常。写一个好程序的道理其实就如一层窗户纸，一点就透。但是，难得的是这本书系

需求与设计的区别究竟是什么？ 教科书上的经典答案是：需求关注系统“做什么”，设计关注“如何做”，其实这是一个很模糊的说法。无论是在结构化方法中还是在面向对象的方法中，需求分析的结果既包括了“做什么”也部分包括了“如何做”，只不过描述“如何做”时抽象的层次比较高或者描述了某个局部需求的“如何做”。客户在提出系统需求时，可能对“如何做”提出一些约束条件，比如客户要求必须采用三层结构，必须采用某个中间件

需求描述方法是专业的需求分析人员必须掌握的技能，在众多的方法中，图形化描述需求是重中之重，一图胜千言。在没有文字之前，人与人之间的沟通是通过图形来表达的，象形文字是造字的最主要的手段。随着时间的推移，人们越来越依赖于文字，反而弱化了用图形表达思想的技能。做为需求人员，应该将图形化表达思想的能力重新捡起来，形成自己的技能，我们称之为图解力。需求人员应该掌握哪些图形的使用方法呢？请参见下边的不完全列表

递归是指方法在执行的过程中自己调用自己。用递归能解决的问题通常能将问题不断缩小为性质相同但规模更小的问题（递归情况），直到问题足够小能够直接解决（基本情况）。递归程序编写有4个要点：1问题是否可以递归描述？2递归结束的条件是什么？3递归调用之前做什么准备工作？4递归调用之后做什么收尾工作？ 以下通过一个稍微复杂的程序来举例说明一下如何编写递归程序。有一只中国象棋中的 “ 马 ” ，在半张棋盘的左下

1 想清楚，写清楚，说清楚，才是真正的清楚！2 多花点时间沟通清楚需求，才能把握正确方向！3 修复需求错误的成本是代码错误的几十倍！4 程序员最大的坏习惯就是：急于动手写代码！ 5 提高开发效率的捷径：一次做对，不返工！6 写代码之前三件事：     弄清楚做什么；     说清楚怎么做；     想清楚怎么测！7 职业的程序员设计程序，业余的程序员调试程序；8 拷贝粘贴式的作业方式，最容易导入b

培训日期：2007年9月14日到2007年9月15日日程安排：第1天:上午：单元测试的技术与方法培训下午：LINUX下CUNIT单元测试工具的使用方法第2天：上午：分组练习下午：分组练习练习总结练习情况概述：约50名开发人员参加了练习，分成了7个小组进行了练习，其中一个小组原来采用C#在windows开发平台下进行软件开发，其他小组均是在LINUX环境下用C语言开发。练习均在实际的工作环境中进行的

产品集成（PI）即把不同部件集成在一起，形成一个更大的部件或一个完整的可交付的产品。该PA包含了集成策略的制定、集成准备、集成、集成后的验证与确认、以及交付的活动。 实践列表 PI 1.1 Assemble solutions and deliver to the customer.  组装解决方案并交付给客户 ...

  2009年曾经写过一篇博文，讲述需求与设计的界线（参见博文：https://blog.youkuaiyun.com/dylanren/article/details/4965181），最近又有所思考，对上篇博文整理补充如下。       首先我们从两个日常生活的例子思考一下：       案例一：DIY一台PC。                      概要描述...

在开发过程中，开发人员、测试人员都需要阅读其他人写的需求规格说明书，当阅读别人的需求文档时，我们需要关注什么呢？参见下图的要点：        首先需要了解关于该系统的总体信息，主要包含2条：       1 明确出该软件与其他系统、人、设备的交互关系。可以通过环境图，帮我们梳理清楚该软件与周边环境的关系，从宏观上对软件所处的位置有所理解。如下图所示：       2 系统的目标是什么，即解决了客

非功能性需求是需求的一个重要组成部分，它影响了系统的架构设计，需要开发人员重点关注。但是在工程实践中，往往客户不会提出非功能性需求，需求人员在描述需求时不知道如何描述，在国际的各种标准中，对非功能性需求有定义，但是比较抽象。因此我整理如下常见的非功能性需求的描述案例，供需求人员进行参考。1、性能需求描述案例：响应时间：在95％的情况下，一般时段响应时间不超过1.5秒，高峰时段不超过4秒。定位系统从

根据我们的经验，需求变更越多，造成的软件修改越多，bug也就会越多，事实是否如此呢？需要我们根据历史的数据进行检验。某企业采集了历史上多个项目的的需求变更次数、交付代码的规模、软件测试发现的缺陷个数，参见下表，基于这些历史数据我们分析一下，看看我们的经验结论是否成立。表一：需求变更的历史数据 ID 需求变更数 代码规模LOC 总缺陷数 测试缺陷密度bugs/KLOC

名称 测试对象 侧重点 参照物 充分性的评价方法 时机 测试方法 测试执行者 单元测试 软件的最小单元，如函数、方法等 逻辑的正确性 详细设计、源程序 代码、分支等覆盖率 软件中的基本组成单位完成后，边开发边测试 白盒测试、动态测试 一般是开发人员 集成测试 软件的模块、子系统 接口的正确性 概要设计、详细设计 接口覆盖率 软件系统集成过程中，边集

（1）系统测试人员参与需求评审         （2）定义明确的测试需求         （3）测试人员要在需求阶段介入项目组         （4）系统测试用例要覆盖所有的场景         （5）建立产品需求与测试用例的跟踪矩阵         （6）评审测试用例         （7）利用回归测试工具        （8）

作者：任甲林　来源：希赛网　http://www.csai.cn 摘要 　　本文介绍了需求管理的必要性，并介绍了控制需求渐变的一些方法。 关键词 　　需求管理，需求渐变，需求复用 　　软件需求是整个软件项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，他不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的，软件需求是软件项目最难把

简单工厂：一个具体工厂通过条件语句创建多个产品，产品的创建逻辑集中与一个工厂类。客户端通过传不同的参数给工厂，实现创建不同产品的目的增加新产品时，需要修改工厂类、增加产品类，不符合OCP原则 工厂方法：一个工厂创建一个产品，所有的具体工厂继承自一个抽象工厂。客户端先创建不同产品的工厂，再由工厂创建具体产品，产品的创建逻辑分散在每个具体工厂类中。客户端只依赖于抽象工厂与抽象产品，不依赖任何具

说明：本文已刊登于《信息技术与标准化》07年第3期新一代的功能点规模估算方法: COSMIC-FFP1 引言软件规模估算是估计软件开发的工作量、成本与资源需求的基础，通过规模与其他度量数据还可以度量项目的生产率、缺陷密度，目前在工程界流行的估算方法是代码行估算方法和功能点分析方法（function points analysis，FPA法）。代码行估算方法是一种经验估算方法，通常会采用

1 有经验的人参与估算 一方面要对估计的内容有开发经验,另一方面也要经过了估计的训练,在估计方面有经验.两种经验缺少其一,估计的风险都比较大. 2 分解的颗粒度要小 在估计时要对估计的内容进行分解,划整为零,对于小的任务进行估计时,才容易把握.比如让你估计一碗大米中有多少粒一样,一般的办法就是把大米划分成大小基本相等的几堆,先估计其中一小堆或者数一数,然后再估计整体的粒数. 3 确保没有遗漏 如果

这个问题客户问过我，我也解答过多次，但是我一直没有更直接的理由说服我自己，认为必须先做规模估计再做工作量估计。 比如：对维护类的项目，或者是维护类的活动，为什么要估计规模呢？项目组的人没有技术风险，对需求很熟悉。   我总结了如下的理由： （1）     以规模来估计工作量与成本 （2）     规模估计与实现的人与技术无关，比较客观 （3）     可以度量项目的开发效率：规模/工作量 （4）

请告诉我：你一生会认识多少人呢？ 听到这个问题，你可能认为无法回答，其实是可以估算的,只不过你没有去做。 首先，我们定义清楚什么可以称为“认识”一个人？ 如果你曾经记住他的名字，你见到他时能够记起曾经和他一起做过某件事情，那就可以称为认识他了，这就是在明确需求。 其次，还是让我们采用穷举与分类的思想，假如对你认识的人员按如下的方式来分类： （1）为你服务的： 父母 老师 物业公司 ……. (2)

在我咨询的客户中，软件企业对于单元测试的执行情况可以划分为4类：  （1）不做单元测试  （2）组织级要求了开发人员做单元测试，但是开发人员在做单元测试时，测试用例仅覆盖了程序中的正常路径，基本上是一个函数只有一个单元测试用例  （3）组织级要求了每千行代码必须有多少个单元测试用例，一般是在50个/KLOC到100个/KLOC之间。  （4）要求语句覆盖与分支覆盖必须达到100%。其中（3）、（4

代码走查的最主要的目的是为了发现程序中的逻辑错误，编程风格方面的错误可以通过风格检查的工具去检查。如下的检查单给代码走查的专家发现逻辑错误提供了一个很好的帮助。序号检查项1代码的注释与代码是否一致？注释是否是多余的？2是否存在超过3层嵌套的循环与/或判断？3变量的命名是否

背景描述：近期要去讲一次重构，想收集一个案例，恰好从网上看到了一个朋友写的一个计算算术表达式的C#程序，原程序是计算含括号的正整数表达式的四则运算值。读后，发现问题比较多，而且逻辑有错误，因此对其进行了重构。为简化起间，将程序的功能进行了简化：1 计算的算术表达式只含有+、-、*、/运算2 不含有括号3 表达式的第一个符号是数字4 假定表达式是合法的算术表达式且满足上边的约

（1）经验法Ø     DELPHI方法：需要多个专家参与。Ø     类比法：可以一个专家根据历史相似的项目进行估计。（2）模型法Ø     一元线性关系工作量=规模*生产率+C生产率借鉴历史项目的数据，C为一个常量，多数情况下为0。这是最简单的估算模型。Ø     多元线性关系工作量=规模*生产率*复用率*难度系数*人员能力系数*……+ C生产率借鉴历史项目的数据，C为一个常量，多数情况下为0

场景一：合同前的工作量估算场景描述：（1） 没有实施过CMMI2级（2） 合同未签，需要给客户报价（3） 有客户的概要需求，有类似的项目数据可供参考（4） 需要估计整个项目的总工作量，以便于估算总成本，给客户报价估算步骤：（1）寻找类似的历史项目，进行项目的类比分析，根据历史项目的工作量凭经验估计本项目的总工作量；（2）进行WBS分解，力所能及地将整个项目的任务进行分解；（3）参考类似项目的数据，

经验法则如下：1 测试人员参与需求评审，需求人员参与测试用例的评审不懂需求，不了解需求的测试人员是不可能设计出完备的测试用例的。测试人员参与需求评审一是可以评审需求的可测试性，二是了解需求。  需求人员评审测试用例可以检验用例的完备性，判断测试人员是否理解了需求。2 系统测试用例覆盖每一个场景场景是在需求中描述的用户使用系统的一条操作路径。覆盖每个场景是系统测试用例设计的基本要求。3 集成测试用例

函数一： getMaxInTwo(int a,int b) { if a>=b return a; else return b; } 函数二： getMaxInThree(int a,int b,int c) { a=a+1; int max=getMaxInTwo(a,b); max=getMaxInTwo(max,c); } 单元测试用例的设计： getMaxInTwo的UT用例： （3，2）

作者：任甲林　来源：希赛网　 　　在需求工程中，需求获取阶段是和用户交往最多的一段时间, 而绝大部分用户是不懂得需求分析方法的，他们不知道怎样全面而又准确无误地表达自己的需求，因而对于需求分析人员来讲，需要掌握很好的方法与技巧，恰当地启发引导用户表达自己的需求，以便为项目的成功提供一个很好的基石。 一 需求获取的2个基本原则 1 深入浅出 　　对企业的需求调研的要尽可能的全面、细致,调研的需求是个

要点如下： (1) 本项目的技术路线，即：   Ø        采用的技术方法，如是采用OO的方法、还是结构化的方法，是采用.net还是JAVA;   Ø        总体的技术结构,如采用几层体系结构，每层的责任是什么；   Ø        系统的网络结构，如系统的功能在网络上的部署分布；   Ø        核心技术难点的解决方案