那一年东京还不热
软件需求分析的需求类型
下面这些定义是需求工程领域中常见术语的定义。
软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。
1.业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。
2.用户需求（user requirement） 文档描述了用户使用产品必须要完成的任务，这在使用实例（usecase）文档或方案脚本说明中予以说明。
3.功能需求（functional requirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
在软件需求规格说明书（SRS）中说明的功能需求充分描述了软件系统所应具有的外部行为。
软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。
对一个大型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统（或软件部件）。
作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。
它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。
所谓约束是指对开发人员在软件产品设计和构造上的限制。
质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。
多角度描述产品对用户和开发人员都极为重要。
下面以一个子处理程序为例来说明需求的不同种类。
业务需求可能是：“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。
而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。
同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。
从以上定义可以发现，需求并未包括设计细节、实现细节、项目计划信息或测试信息。
需求与这些没有关系，它关注的是充分说明你究竟想开发什么。
项目也有其它方面的需求，如开发环境需求或发布产品及移植到支撑环境的需求。
尽管这些需求对项目成功也至关重要，但它们并非本书所要讨论的。
软件工程需求规格说明书
展开全部 软件开发过程：立项、需求分析、概要设计、详细设计、编码、测试、运行及维护；单元测试 参照 详细设计说明说（LLD）集成测试 参照 概要设计说明书（HLD）系统测试 参照 需求规格说明说（SRS）需求规格说明书 是为使用用户和软件开发者双方对该软件的初始规定有一个共同的理解， 使之成为整个开发工作的基础。
概要设计 就是设计软件的结构，包括组成模块，模块的层次结构，模块的调用关系，每个模块的功能等等。
详细设计 就是为每个模块完成的功能进行具体的描述，要把功能描述转变为精确的、结构化的过程描述。
...
业务需求,用户需求,功能需求是什么意思？有什么区别
我们的软件产品或者项目，其需求都有三个层级和三个方面。
一、我们首先看需求的三个层次软件需求包括3个不同的层次――业务需求、用户需求和功能需求。
业务需求 （Business requirement）表示组织或客户高层次的目标。
业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。
业 务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。
使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。
用户需求 （user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。
用例、场景描述和事件――响应表都是表达用户需求的有效途径。
也就是说用户需求描述了用户能使用系统来做些什么。
功能需求 （functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。
功能需求有时也被称作行为需求 （behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。
功能需求描述是开发人员需要实现什 么。
注意：用户需求不总是被转变成功能需求。
产品特性，所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标 得以满足。
对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。
客户希望得到的产品特性和用 户的任务相关的需求不完全是一回事。
一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。
系统需求 （system requirement）用于描述包含有多个子系统的产品（即系统）的顶级需求。
系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。
人也可以是系统的一部分，因此某些系统功能可能要由人来承担。
业务规则 包 括企业方针、政府条例、工业标准、会计准则和计算方法等。
业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。
然而，业务规则常常会限制谁 能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。
有时，功能中特定的质量属性（通过功能实现）也源于业务规则。
所以，对某些功能 需求进行追溯时，会发现其来源正是一条特定的业务规则。
功能需求记录在软件需求规格说明（SRS）中。
SRS完整地描述了软件系统的预期特性。
SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库 或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。
开发、测试 、质量保证、项目管理和其他 相关的项目功能都要用到 SRS。
除此之外，对于需求层次，我们还有其它的分法：组织级需求->业务需求->用户需求->功能需求（有时也叫行为需求）。
组织级需求： 一 般代表着组织的愿景和目标。
对于大的公司，一般是通过资深的咨询顾问和咨询公司得出的，呈现的方式是咨询报告。
比如在ITSM或者企业信息化这方面。
典型 的组织级的需求是：降低成本、减少库存成本、提升IT服务部门在企业中的价值、通过ISO20000、提高IT服务的效率、提高员工的满意度等。
业务需求： 是要完组织的使命，达成组织的愿景的各个业务流程和业务单元具有的需求。
业务需求服从于组织需求。
用户需求： 用户级的需求，是在业务级的需求下，各个岗位协作完成业务而具有的需求。
我们在软件需求规格说明书中表述的需求其实主要是这一部分需求。
功能需求： 同样，它代表着产品或者软件需求具备的能力。
一般是管理人员或者产品的市场部门人员负责定义软件的业务需求，以提高公司的运营效率（对信息系统而言）或产品的市场竞争力（对商业软件而言）。
所有的用 户需求都必须符合业务需求。
需求分析员从用户需求中推导出产品应具备哪些对用户有帮助的功能。
开发人员则根据功能需求和非功能需求设计解决方案，在约束条 件的限制范围内实现必需的功能，并达到规定的质量和性能指标。
当一项新的特性、用例或功能需求被提出时，需求分析员必须思考一个问题：“它在范围内 吗？”。
如果答案是肯定的，则该需求属于需求规格说明，反之则不属于。
但答案也许是“不在，但应该在”，这时必须由业务需求的负责人或投资管理人来决定： 是否扩大项目范围以容纳新的需求。
这是一个可能影响项目进度和预算的商业决策。
二、需求的三个方面 除了功能需求外，SRS中还包含非功能需求，包括性能指标和对质量属性的描述。
质量属性 （quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。
这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或 开发人员都很重要。
其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。
还有一项称为可用性（usability）的质量属性，它规 定了业务需求中“有效”（efficiently）一词的含义。
约束（constraint）限制了开发人员设计和构建系统时...
如何进行软件需求分析
展开全部 1.概念需求的定义包括从用户角度（系统的外部行为），以及从开发者角度（一些内部特性）来阐述需求.关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者，客户被迫与新的需求分析者坐到一起.系统的分析人员说：＂我们想与你谈谈你的需求.＂客户的第一反应便是：＂我已经将我的要求都告诉你们前任了，现在我要的就是给我编一个系统＂.百事通而实际上，UGGs，需求并未编写成文档，因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话，你就确信你已明白用户的需求，那完全是自欺欺人.需求的另外一种定义认为需求是＂用户所需要的并能触发一个程序或系统开发工作的说明＂.有些需求分析专家拓展了这个概念：＂从系统外部能发现系统所具有的满足于用户的特点、功能及属性等＂.这些定义强调的是产品是什么样的，而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性：需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性，是在开发过程中对系统的约束.从上面这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的＂需求＂术语存在，真正的＂需求＂实际上在人们的脑海中，这个人们主要是指客户，但一般情况下，用户并不能描述自己的需要，只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.任何文档形式的需求（例如如下将要描述的需求规格说明书）仅是一个模型，一种描述.2.需求分析的任务开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难.目前，国内产品的庞杂，一家企业可能有几个系统并立运行，它们之间接口是系统开发人员最头痛的问题.对于商业最终用户应用程序，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道项目于何时结束？而如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？然而，即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价，这些血的教训正在国内的软件开发者身上发生.近来，我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是，当他们开发完这个工具后，发现这个工具不能打印出源代码文件，使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确，如果我们没有编写文档，软件达不到期望目标也只能是咎由自取了.相反的情况，我曾见一个要集成到＂错误跟踪系统＂中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误.事实上，需求文档在开发过程中一直起指导作用.3.需求分析过程可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适，如图4-1所示：图4-1 需求工程域的层次分解示意图需求开发可进一步分为：问题获取、分析、编写规格说明和验证四个阶段.这些子项包括软件类产品中需求收集、评价、编写文档等所有活动.需求开发活动包括以下几个方面：确定产品所期望的用户类别.获取每个用户类的需求.了解实际用户任务和目标以及这些任务所支持的业务需求.分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息.将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件.了解相关质量属性的重要性.商讨实施优先级的划分.将所收集的用户需求编写成文档和模型.评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚.需求管理需要＂建立并维护在软件工程中同客户达成的合同＂ .这种合同都包含在编写的需求文档与模型中.客户的接受仅是需求成功的一半，开发人员也必须能够接受他们，并真正把需求应用到产品中.通常的需求管理活动包括：定义需求基线（迅速制定需求文档的主体）.评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它.以一种可控制的方式将需求变更融入到项目中.使当前的项目计划与需求一致.估计变更需求所产生影响并在此基础上协商新的承诺，这种承诺具体体现在项目解决方案上.让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪.在整个项目过程中跟踪需求状态及其变更情况.以...
项目管理中的srs是什么意思？
项目管理中的SRS一般指： Software Requirements Specification， 或是System Requirements Specification。
软件项目管理中的常用单词简写PI:Project Initiation（项目启动）PPL:Project Plan（制定项目计划，Establish PPL）STP:System Testing Plan（系统测试计划）HLD: High Level design，也叫General design （概要设计）ITP:Integration Testing Plan（集成测试计划）LLD: Low Level design，也叫Detail design （详细设计）UTP:Unit Testing Plan（单元测试计划）
气囊游丝的使用须知
安全气囊系统能够增加对车内乘客的安全保护，但前提是必须正确地认识和使用气囊系统。
驾驶员座的气囊在转向盘的中央。
副驾驶气囊在右侧仪表板内。
注意：如果在乘员和气囊中间有什么物件，气囊就可能无法正常膨开，或者可能会将此物件打到乘员身上，导致严重伤害甚至死亡。
因此，在气囊膨开的空间内不能有任何东西，千万不要在转向盘上或气囊罩盖附近放置任何东西。
驾驶员和副驾驶的正面气囊在中度至重度正面碰撞或接近正面碰撞时膨开，但是，根据设计，只有当碰撞力超过预先设定的限值时气囊才能膨开。
该限值描述了气囊膨开时的碰撞严重程度，设定时考虑了多种设想的情况。
气囊是否膨开并不取决于车速的高低，而主要决定于碰撞的物体、碰撞的方向和汽车的减速度。
如果您的汽车正面撞到静止的、坚硬的墙上，限值大约是14~27km/h（不同的车辆限值可能略有不同）。
气囊可能在不同的碰撞速度下膨开，具体与以下因素有关：碰撞的物体是静止的还是运动的。
碰撞的物体是否易于变形。
碰撞物体的宽（如一堵墙）窄（如一根柱子）程度。
碰撞的角度。
正面气囊在车辆翻滚时，在后面碰撞时，或在大多数侧面碰撞时都不会膨开，因为在这些情况下正面气囊的膨开起不到保护乘客的作用。
在任何碰撞中，都不能仅仅根据车辆的损坏程度或维修费用的高低来判断气囊是否应当膨开。
对于正面碰撞或接近正面碰撞，气囊的膨开取决于碰撞的角度和汽车的减速度。
气囊系统在大多数行驶条件下都能够正常工作，包括越野行驶。
但是，一定要时刻保持安全车速，尤其在不平路面上。
另外，一定要系好安全带。
要注意观察位于仪表盘上的安全气囊警告灯。
在正常情况下，点火开关转到“ACC”或“ON”位置时，警告灯会亮大约6秒钟，进行自检，然后熄灭，若警告灯一直亮，则表明安全气囊系统有故障，应立即进行修理。
否则，有可能出现气囊不起作用或误弹出的情况。
SRS, Stimulated Raman Scattering ，受激拉曼散射 。
是一种非弹性散射，光波的频率要降低或光子的能量减少。
SRS和介质光学性质有关。
受激喇曼散射是和光与硅原子振动模式间相互作用有关的宽带效应。
受激喇曼散射使得信号波长就象是更长波长信号通道或者自发散射的喇曼位移光的一个喇曼泵。
在任何情况下，短波长的信号总是被这种过程所衰减，同时长波长信号得到增强。
SRS(Software Requirements Specification)， 软件需求规格说明书 软件开发，一般要经过需求定义、需求分析、系统设计、概要设计、详细设计、编码、单元测试、集成测试、系统测试、发布等阶段，需求分析阶段一般需要撰写软件需求规格说明书，也即SRS SRS音效：SRS Audio Sandbox由U.S.A SRS Labs公司根据人类听觉系统的动力学（Dynamics of Human Hearing System）原理及心理声学（Psychoacoustics）而研究出来的专利音响高端改善技术。
实际上目前有很多3D效果增强软件，但是这些软件多是以播放器插件的形式进行播放的，而SRS Audio Sandbox则与之完全不同，它利用操作系统的底层技术，以驱动程序的形式装入系统。
实际上不论采用何种声卡，任何媒体播放程序，这款软件都能够为你的PC提供3D音频效果。
这次更新的版本是v1.6.7.0，提供以下功能。
这款产品支持的音效如下 SRS WOW HD - 提升压缩和未压缩音频性能，能在水平位置与垂直位置创造声场深度，并增强低音相应。
SRS TruSurround XT - 多声道音源传输为两声道立体声环境时提供逼真的环绕声体验。
SRS Circle Surround II - 混合立体声或单声道音源输出为5.1或6.1环境并具备环绕音频效果。
SRS Headphone 360 - 为耳机提供真实的5.1环绕声体验。
高级音频性能 SRS? 3D - 为单声道或是立体声环境提供3D环境音效。
SRS 3D Center Control - 一个虚拟化的动态空间以聆听测试前景声与背景声混合效果。
SRS TruBass - 低音混合效果 SRS FOCUS - 为压缩音源提供扬声器输出优化 SRS Definition - 传递更具现场感更生动的声音效果。
SRS Dialog Clarity - 使电影或是视频中的声乐表现更加生动清晰。
项目需求分析怎么写
展开全部 项目需求分析的概念 需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。
（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。
需求分析阶段结束后，要求得到：1.SRS文档（System Requirement Specification）; 2.DRM 文档；3.Acceptance Plan. 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上理解：需求分析指需求的分析、定义过程。
一、为什么要需求分析 需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力，财力，时间，开发出的软件却没人要，那所有的投入都是徒劳.如果费了很大的精力，开发一个软件，最后却不满足用户的要求，从而要重新开发过，这种返工是让人痛心疾首的.（相信大家都有体会）比如，用户需要一个for linux的软件，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题，而想当然的认为是开发for windows的软件，当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，痕不得找块豆腐一头撞死. 需求分析之所以重要，就因为他具有决策性，方向性，策略性的作用，他在软件开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型软件系统的开发中，他的作用要远远大于程序设计. 二、需求分析的任务 简言之，需求分析的任务就是解决＂做什么＂的问题，就是要全面地理解用户的各项要求，并准确地表达所接受的用户需求.三、需求分析的过程 需求分析阶段的工作，可以分为四个方面：问题识别，分析与综合，制订规格说明，评审. 问题识别 就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准.这些需求包括：功能需求（做什么），性能需求（要达到什么指标），环境需求（如机型，操作系统等），可靠性需求（不发生故障的概率），安全保密需求，用户界面需求，资源使用需求（软件运行是所需的内存，CPU等），软件成本消耗与开发进度需求，预先估计以后系统可能达到的目标. 分析与综合 逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分.最后，综合成系统的解决方案，给出要开发的系统的详细逻辑模型（做什么的模型）. 制订规格说明书 即编制文档，描述需求的文档称为软件需求规格说明书.请注意，需求分析阶段的成果是需求规格说明书（好象软考曾经考过这个问题），向下一阶段提交. 评审 对功能的正确性，完整性和清晰性，以及其它需求给予评价.评审通过才可进行下一阶段的工作，否则重新进行需求分析。
四、需求分析的方法 需求分析的方法有很多.这里只强调原型化方法，其它的方法如：结构化方法，动态分析法等（个人认为，对初学者不必深究这些方法，实际上我也从来没用过这些方法）在此不讨论. 原型化方法是十分重要的（是软考等常考的知识点）.原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能. 原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能，但是这个系统可能在可靠性，界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性，技术的可行性，或考察是否满足用户的需求等.如，为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型.以后的目标系统就在原型系统的基础上开发. 原型主要有三种类型（软考考过）：探索型，实验型，进化型.探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性.实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠.进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。
在使用原型化方法是有两种不同的策略：废弃策略，追加策略.废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改，形成比较好的思想，据此设计出较完整，准确，一致，可靠的最终系统.系统构造完成后，原来的模型系统就被废弃不用.探索型和实验型属于这种策略。
追加策略：先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，发展成为最终系统。
进化型属于这种策略.
