需求Requirement,软件工程的开始
关于需求分析
转载:
http://community.csdn.net/Expert/topic/4252/4252256.xml?temp=.4403498
需求分析：requirement analysis
概要设计：preliminary design
详细设计：detailed design
需求分析是当前软件工程中的关键问题，需求分析阶段的任务是：在可行性分析的基础上，进一步了解、确定用户需求。准确地回答 “系统必须做什么？” 的问题。获得需求规格说 明书。还涉及到软件系统的目标、软件系统提供的服务、软件系统的约束和软件系统运行的环境。它还涉及到这些因素和系统的精确规格说明，以及系统进化之间的关系。
需求分析的基本任务包括：
(1) 抽取需求 分析现行系统存在需要解决的问题。获取足够多的问题领域的知识，需求抽取的方法一般有问卷法、面谈法、数据采集法、用例法、情景实例法以及基于目标的方法等；还有知识工程方法，例如，场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等 。
(2) 模拟和分析需求 需求分析和模拟又包含三个层次的工作。首先是需求建模。需求模型的表现形式有自然语言、半形式化(如图、表、结构化英语等)和形式化表示等三种。需求概念模型的要求包括实现的独立性:不模拟数据的表示和内部组织等；需求模拟技术又分为企业模拟、功能需求模拟和非功能需求模拟等。
(3) 传递需求 传递需求的主要任务是书写软件需求规格说明。
(4) 认可需求 就是对需求规格说明达成一致，其主要任务是冲突求解，包括定义冲突和冲突求解两方面。常用的冲突求解方法有：协商、竞争、仲裁、强制、教育等，其中有些只能用人的因素去控制。
(5) 进化需求 客户的需要总是不断(连续)地增长，但是一般的软件开发又总是落后于客户需求的增长，如何管理需求的进化(变化)就成为软件进化的首要问题。对于传统的变化管理过程来说，其基本成分包括软件配置、软件基线和变化审查小组。当前的发展是软件家族法 ，即产品线方法。多视点方法也是管理需求变化的一种新方法，它可以用于管理不一致性， 并进行关于变化的推理。
概要设计是在需求分析的基础上通过抽象和分解将系统分解成模块，确定系统功能是实现。
基本任务是：建立软件系统结构（划分模块、定义模块功能、模块间的调用关系、定义模块的接
口、评价模块的质量）、数据结构和数据库的设计（数据结构设计、概念设计、逻辑设计、物理
设计）、编写概要设计文档（概要设计说明书、用户手册、数据库设计说明书、修订测试计
划）。
论软件产品设计中的需求分析
详细:
http://51cmm.csai.cn/Requirement/NO000003.htm
管理信息系统需求调研分析指南
详细:
http://www.yesky.com/SoftChannel/72342393336102912/20031205/1750811.shtml
解决需求工程中的基本问题
如果需求的捕获方法选择不当或使用不当，通常会暴露出两方面问题。
第一，软件需求不能如实反映用户的真正需要。
第二，软件需求不能被开发团队的不同工种直接共用。
需求内容的具体组织形式主要针对软件需求归约（SRS），存在两个比较突出的问题。
第一，不符合国际通行的规范。
第二，与软件需求归约相关的流程指导薄弱。
详细:
http://51cmm.csai.cn/Requirement/No002.htm
需求的层次
转载
http://community.hf-mstc.org/cs/blogs/dongwei/archive/2006/04/05/2084.aspx
软件需求包括3个不同的层次――业务需求、用户需求和功能需求。
除此之外，每个系统还有各种非功能需求。
业务需求（Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。
用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。
功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（behavioral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。
系统需求（system requirement）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。
业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。
功能需求记录在软件需求规格说明（SRS）中。SRS完整地描述了软件系统的预期特性。SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到SRS。
除了功能需求外，SRS中还包含非功能需求，包括性能指标和对质量属性的描述。
质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。
约束（constraint）限制了开发人员设计和构建系统时的选择范围。
产品特性。所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。
还有一项称为可用性（usability）的质量属性，它规定了业务需求中“有效”（efficiently）一词的含义。
管理人员或市场营销人员负责定义软件的业务需求，以提高公司的运营效率（对信息系统而言）或产品的市场竞争力（对商业软件而言）。所有的用户需求都必须符合业务需求。需求分析员从用户需求中推导出产品应具备哪些对用户有帮助的功能。开发人员则根据功能需求和非功能需求设计解决方案，在约束条件的限制范围内实现必需的功能，并达到规定的质量和性能指标。
当一项新的特性、用例或功能需求被提出时，需求分析员必须思考一个问题：“它在范围内吗？”。如果答案是肯定的，则该需求属于需求规格说明，反之则不属于。但答案也许是“不在，但应该在”，这时必须由业务需求的负责人或投资管理人来决定：是否扩大项目范围以容纳新的需求。这是一个可能影响项目进度和预算的商业决策。
不属于需求的内容
需求规格说明中不包括（除已知约束外的）设计和实现的细节、项目的计划信息，以及测试信息（Leffingwell 和 Widrig 2000）。把这些内容与需求分开，就可以把需求活动的注意力集中到了解开发小组需要开发的产品特性上。项目中通常还包括其他类型的需求，如开发环境需求，进度或预算限制，帮助新用户跟上进度的培训需求，或者发布产品使其转入支持环境的需求。这些都属于项目需求而不是产品需求，因此不属于软件需求的讨论范围。
这里将继续...
