案例：非功能性需求的设计

why，需求为什么变化？   甲方的特殊原因：     不知道如何说清楚需求；     没有明确的需求；     没有确认乙方描述的需求；   乙方的特殊原因：     理解错了需求；     没有很好的诱导客户的需求；   共性原因：     业务就是变化；     人与人之间的沟通本来就存在障碍； 特殊原因是可以消除的，共性原因是难以消除的。 who : 谁会提出需求变化？   客户：客户方的

培训教室管理需求描述：维护教室信息可新增/修改/删除教室，维护信息字段：教室编号、楼层、容量、功能、说明。1 有几个功能处理？新增、修改、删除、查询四个功能处理。2 为什么查询是单独的一个功能处理？因为进入培训教室管理的页面后，列出了已经输入的所有的教室的信息，可以不做其他任何操作退出，只是看看有哪些已有的教室。在上述的需求描述中没有明确说明查询的功能，但是根...

决定项目成功的核心角色是什么？我认为是三个角色：项目经理、技术经理与需求经理。
  项目经理：解决管理上如何做的问题，对项目的进度与质量负责。具体职责包括了：过程定义、估算、计划制定、计划跟踪与控制、风险管理、质量管理等。
  技术经理：解决技术上如何做的问题，对项目的技术方案负责。具体职责包括了：技术可行性的评估、技术方案的确定、设计、设计验证、技术难题的解决、实现等。
  需求经理：解决做什么的问题，对项目的需求与范围负责。具体职责包括了：需求获取、需求分析、

大概在5年以前曾经从网上搜到了Barry Boehm提出的软件工程的七原则（Seven Basic Principles of Software Engineering），这是Barry Boehm1983年发表的文章，在网上搜到的是别人对这七个原则的转译与介绍，看后觉得怪怪的，总是觉得有些地方不能准确把握这七个原则的含义。于是去google搜其原文，未果，最近终于搜到了原文，因此更能准确把握Ba

作者：任甲林　来源：CSAI.cn　http://www.csai.cn　2005年6月13日 摘要 　　本文介绍了软件需求评审失败的5个案例，提出对软件需求评审的实践具有指导意义的9个建议。 关键词 　　需求评审，需求层次，阶段评审，检查单，评审流程 　　软件需求是软件开发的最重要的一个输入，需求风险也常常是软件开发过程中最大的一个风险，降低需求风险的一个重要手段就是需求评审，但是需求评审是所有