??xml version="1.0" encoding="utf-8" standalone="yes"?>久久夜色精品国产噜噜亚洲a,亚洲国产精品xo在线观看,亚洲国产精品无码久久九九http://www.tkk7.com/wufang5/articles/259021.html懒虫懒虫Wed, 11 Mar 2009 02:21:00 GMThttp://www.tkk7.com/wufang5/articles/259021.htmlhttp://www.tkk7.com/wufang5/comments/259021.htmlhttp://www.tkk7.com/wufang5/articles/259021.html#Feedback0http://www.tkk7.com/wufang5/comments/commentRss/259021.htmlhttp://www.tkk7.com/wufang5/services/trackbacks/259021.html

1Q引a

1Q?  ~写目的

· 阐明开发本软g的目的；

1Q?  目背景

· 标识待开发Y件品的名称、代码；

· 列出本项目的d提出者、项目负责h、系l分析员、系l设计员、程序设计员、程序员、资料员以及(qing)与本目开展工作直接有关的人员和用P

· 说明该Y件品与其他有关软g产品的相互关pR?/span>

1Q?  术语说明

列出本文档中所用到的专门术语的定义和英文羃写词的原文?/span>

1Q?  参考资料（可有可无Q?/span>

    列D~写软g需求规D明时所参考的资料Q包括项目经核准的计划Q务书、合

同、引用的标准和规范、项目开发计划、需求规D明、用实例文档，以及(qing)相关产品

的Y仉求规D明?/span>

    在这里应该给?gu)l的信息Q包括标题、作者、版本号、发表日期、出版单位或?/span>

料来源?/span>

2Q项目概q?/strong>

    2Q?  待开发Y件的一般描q?/span>

    描述待开发Y件的背景Q所应达到的目标Q以?qing)?jng)场前景等?/span>

    2Q?  待开发Y件的功能

    q待开发Y件所h的主要功能。ؓ(f)?jin)帮助每个读者易于理解，可以使用列表?/span>

囑Ş的方法进行描q。用图形表C，可以采用Q?/span>

    · 层数据图Q?/span>

    · 用例UseCase图；

    · pȝ程图；

    · 层次Ҏ(gu)图?/span>

   2Q?  用户特征和水qI是哪cMh使用Q?/span>

    描述最l用户应h的受教育水^、工作经验及(qing)技术专ѝ?/span>

    2Q?  q行环境

    描述软g的运行环境，包括gq_、硬件要求、操作系l和版本Q以?qing)其他的?/span>

件或与其共存的应用程序等?/span>

    2Q?  条g与限?/span>

    l出影响开发h员在设计软g时的U束条款Q例如：(x)

    · 必须使用或避免用的特定技术、工兗编E语a和数据库Q?/span>

    · g限制Q?/span>

    · 所要求的开发规范或标准?/span>

3Q功能需?/strong>

    3Q?  功能划分

    列D出所开发的软g能实现的全部功能Q可采用文字、图表或数学公式{多U方?/span>

q行描述?/span>

3Q?  功能描述

对各个功能进行详l的描述?/span>

4Q外部接口需?/strong>

4Q?  用户界面

对用户希望该软g所h的界面特征进行描q。以下是可能要包括的一些特征：(x)

· 要采用的图形用L(fng)面标准或产品pd的风|

· 屏幕布局Q?/span>

· 菜单布局Q?/span>

· 输入输出格式Q?/span>

· 错误信息昄格式Q?/span>

采用RAD开发工P  比如VisioQ构造用L(fng)面?/span>

4Q?  g接口

     描述pȝ中Y件品和g讑֤每一接口的特征，以及(qing)g接口支持的设备、Y件与g接口之间Q以?qing)硬件接口与支持讑֤之间的约定，包括交流的数据和控制信息的性质以及(qing)所使用的通信协议?/span>

4Q?  软g接口

    描述该Y件品与其有兌Y件的接口关系Qƈ指出q些外部软g或组件的名字和版本号。比如运行在什么操作系l上Q访问何U类型的数据库，使用什么数据库q接lgQ和什么商业Y件共享数据等?/span>

4Q?  通信接口

     描述和本软g产品相关的各U通信需求，包括?sh)子邮g、Web览器、网l通信协议{?/span>

4Q?  故障处理

    对可能的软g、硬件故障以?qing)对各项性能而言所产生的后果进行处理?/span>

5Q性能需?/strong>

5Q?  数据_?/span>

输出l果的精度?/span>

    5Q?  旉Ҏ(gu)?/span>

    旉Ҏ(gu)可包括如下几方?/span>

    ·响应旉Q?/span>

    ·更新处理旉Q?/span>

    ·数据转换与传输时_(d)

     ·q行旉{?/span>

    5Q?  适应?/span>

     在操作方式、运行环境、与其他软g的接口以?qing)开发计划等发生变化Ӟ软g的适应能力?/span>

6Q其他需?/strong>

列出在本文的其他部分未出现的需求。如果不需要增加其他需求，可省略这一部分?/span>

7Q数据描q?/strong>

   7Q?  ?rn)态数?/span>

    7Q?  动态数?/span>

包括输入数据和输出数据?/span>

    7Q?  数据库描q?/span>

    l出使用数据库的名称和类型?/span>

     7Q?  数据字典

对于数据图、层ơ方框图中出现的所有图形元素在数据字典中都要作Z个词条加以定义，使得每一个图形元素都有唯一的一个清晰明的解释?/span>

数据字典中所有的定义必须是严密的、精的Q不可有二意性?/span>

    7Q?  数据采集

    ·列出提供输入数据的机构、设备和人员

    ·列出数据输入的手Dc(din)介质和讑֤Q?/span>

    ·列出数据生成的方法、介质和讑֤?/span>

8Q附?/strong>

    包括分析模型Q待定问题图表等?/span>



懒虫 2009-03-11 10:21 发表评论
]]>如何q行软g需求分?/title><link>http://www.tkk7.com/wufang5/articles/259019.html</link><dc:creator>懒虫</dc:creator><author>懒虫</author><pubDate>Wed, 11 Mar 2009 02:20:00 GMT</pubDate><guid>http://www.tkk7.com/wufang5/articles/259019.html</guid><wfw:comment>http://www.tkk7.com/wufang5/comments/259019.html</wfw:comment><comments>http://www.tkk7.com/wufang5/articles/259019.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.tkk7.com/wufang5/comments/commentRss/259019.html</wfw:commentRss><trackback:ping>http://www.tkk7.com/wufang5/services/trackbacks/259019.html</trackback:ping><description><![CDATA[<span style="color: #222222; font-family: 宋体; font-size: 14px; line-height: 22px; ">需求的定义包括从用戯度（pȝ的外部行为）(j)Q以?qing)从开发者角度（一些内部特性）(j)来阐q需求?br />     关键的问题是一定要~写需求文档。我曄目睹q一个项目中途更换了(jin)所有的开发者，客户被迫与新的需求分析者坐C赗系l的分析人员_(d)(x)“我们想与你谈谈你的需求?#8221;客户的第一反应便是Q?#8220;我已l将我的要求都告诉你们前M(jin)Q现在我要的是l我~一个系l?#8221;。而实际上Q需求ƈ未编写成文档Q因此新的分析h员不得不从头做v。所以如果只有一堆邮件、会(x)谈记录或一些零的未整理的对话Q你q信你已明白用L(fng)需求，那完全是自欺Zh?br />     需求的另外一U定义认为需求是“用户所需要的q能触发一个程序或pȝ开发工作的说明”。有些需求分析专家拓展了(jin)q个概念Q?#8220;从系l外部能发现pȝ所h的满于用户的特炏V功能及(qing)属性等”。这些定义强调的是品是什么样的，而ƈ非品是怎样设计、构造的。而下面的定义则从用户需要进一步{Ud?jin)系l特性：(x)<br /> 需求是指明必须实现什么的规格说明。它描述?jin)系l的行ؓ(f)、特性或属性，是在开发过E中对系l的U束?br />     从上面这些不同Ş式的定义不难发现Qƈ没有一个清晰、毫无二义性的“需?#8221;术语存在Q真正的“需?#8221;实际上在Z的脑中Q这个h们主要是指客P但一般情况下Q用户ƈ不能描述自己的需要，只就需要系l分析h员根据用L(fng)自己语言的描q整理出相关的需要再q一步和客户核对。系l分析员和客户需要确保所有项?a target="_blank" style="text-decoration: none; ">风险</a>承担者在描述需求的那些名词的理解上务必达成p?br /> M文档形式的需求（例如如下要描述的需求规D明书Q仅是一个模型，一U描q?br /> <center><strong>2Q需求分析的d</strong></center><clk>开?nobr id="clickeyekey3" onclick="kwC(event,3,"")" oncontextmenu="return false" onmouseover="kwE(event,3, this)" onmouseout="kwL(event,this)" onmousemove="kwM(3)" style="text-decoration: underline; color: #6600ff; background-color: transparent; border-bottom-width: 1px; border-bottom-style: dotted; border-bottom-color: #6600ff; ">软g</nobr>pȝ最为困隄部分是准确说明开发什么。最为困隄概念性工作便是编写出详细技术需求，q包括所有面向用戗面向机器和其它软gpȝ的接口。同时这也是一旦做错，最l会(x)l系l带来极大损害的部分Qƈ且以后再对它q行修改也极为困难?/clk><br /> 目前Q国内品的庞杂Q一家企业可能有几个pȝq立q行Q它们之间接口是pȝ开发h员最头痛的问题?br /> 对于商业最l用户应用程序，企业信息pȝ和Y件作Z个大pȝ的一部分的品是显而易见的。但是对于我们开发h员来_(d)q没有编写出客户认可的需求文档，我们如何知道目于何时结束？而如果我们不知道什么对客户来说是重要的Q那我们又如何能使客h到满意呢Q?br />     然而，即便qZ商业目的的Y仉求也是必ȝ。例如库、组件和工具q些供开发小l内部用的软g。当然你可能偶尔勉K文档说明p与其他h意见较ؓ(f)一_(d)但更常见的是出现重复q工q种不可避免的后果，而重新编制代码的代h(hun)q远过重写一份需求文档的代h(hun)Q这些血的教训正在国内的软g开发者n上发生?br />     q来Q我遇到一个开发小l开发包括代码编辑器在内的一套内部用的计算助Y件。不q的是，当他们开发完q个工具后，发现q个工具不能打印出源代码文gQ用者当然希望有q个功能。结果这个小l只好手工抄写源代码文档以供代码(g)查。这说明那怕需求明无误ƈ构思准，如果我们没有~写文档QY件达不到期望目标也只能是咎由自取?jin)?br />     相反的情况，我曾见一个要集成?#8220;错误跟踪pȝ”中的单界面写?jin)一需求说明。?a target="_blank" style="text-decoration: none; ">操作pȝ</a><clk>pȝ<nobr id="clickeyekey6" onclick="kwC(event,6,"")" oncontextmenu="return false" onmouseover="kwE(event,6, this)" onmouseout="kwL(event,this)" onmousemove="kwM(6)" style="text-decoration: underline; color: #6600ff; background-color: transparent; border-bottom-width: 1px; border-bottom-style: dotted; border-bottom-color: #6600ff; ">理</nobr>员在为处理脚本时发现单的一张需求清单竟是如此有用。他们依据需求对pȝq行试Ӟ此系l不仅非常清晰地实现?jin)所有必需功能Q而且未发CQ何错误?/clk><br />     事实上，需求文档在开发过E中一直v指导作用?br /> <center><strong>3Q需求分析过E?/strong></center>    可把整个软g<a target="_blank" style="text-decoration: none; ">需求工E?/a>研究领域划分为需求开发和需求管理两部分更合适，如图4-1所C：(x)<br />     <img height="196" src="http://se.csai.cn/Requirement/Images/No0201.jpg" width="515" style="font-size: 12px; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initial; border-color: initial; color: #222222; " alt="" />?-1 需求工E域的层ơ分解示意图<br />     需求开发可q一步分为：(x)问题获取、分析、编写规D明和验证四个阶段。这些子包括Y件类产品中需求收集、评仗编写文档等所有活动。需求开发活动包括以下几个方面：(x)<br />      定产品所期望的用L(fng)别?br />      获取每个用户cȝ需求?br />      ?jin)解实际用户d和目标以?qing)这些Q务所支持的业务需求?br />      分析源于用户的信息以区别用户d需求、功能需求、业务规则、质量属性、徏议解x法和附加信息?br />      系l的需求分为几个子pȝQƈ需求中的一部䆾分配lY件组件?br />      ?jin)解相关质量属性的重要性?br />      商讨实施优先U的划分?br />      所攉的用户需求编写成文档和模型?br />      评审需求规D明，保对用户需求达到共同的理解与认识，q在整个开发小l接受说明之前将问题都弄清楚?br />     需求管理需?#8220;建立q维护在<a target="_blank" style="text-decoration: none; ">软g工程</a>中同客户达成的合?#8221; 。这U合同都包含在编写的需求文档与模型中。客L(fng)接受仅是需求成功的一半，开发h员也必须能够接受他们Qƈ真正把需求应用到产品中。通常的需求管理活动包括：(x)<br />      定义需求基U（q速制定需求文档的MQ?br />      评审提出的需求变更、评估每变更的可能影响从而决定是否实施它?br />      以一U可控制的方式将需求变更融入到目中?br />      使当前的目计划与需求一致?br />      估计变更需求所产生影响q在此基上协商新的承诺，q种承诺具体体现在项目解x案上?br />      让每w求都能与其对应的设计、源代码和测试用例联pv来以实现跟踪?br />      在整个项目过E中跟踪需求状态及(qing)其变更情c(din)?br /> <clk>以上几点说明是我ȝ?jin)成功实施项目后pȝ分析人员?nobr id="clickeyekey2" onclick="kwC(event,2,"")" oncontextmenu="return false" onmouseover="kwE(event,2, this)" onmouseout="kwL(event,this)" onmousemove="kwM(2)" style="text-decoration: underline; color: #6600ff; background-color: transparent; border-bottom-width: 1px; border-bottom-style: dotted; border-bottom-color: #6600ff; ">l验</nobr>Q同时也Ҏ(gu)国内外的其他pȝ实施的相x功经验，q行?jin)ȝ?/clk><br /> <center><strong>4Q需求的cd</strong></center>    下面q些定义是需求工E领域中常见术语的定义?br />     软g需求包括三个不同的层次Q业务需求、用户需求和功能需求（也包括非功能需求）(j)?br />     1Q业务需求（business requirementQ反映了(jin)l织机构或客户对pȝ、品高层次的目标要求，它们在项目视图与范围文档中予以说明?br />     2Q用户需?user requirement) 文档描述?jin)用户用品必要完成的Q务，q在使用实例Quse caseQ文档或Ҏ(gu)脚本说明中予以说明?br />     3Q功能需?functional requirement)定义?jin)开发h员必d现的软g功能Q得用戯完成他们的Q务，从而满了(jin)业务需求?br /> 在Y仉求规D明书 QSRSQ中说明的功能需求充分描qC(jin)软gpȝ所应具有的外部行ؓ(f)。Y仉求规D明在开发、测试、质量保证、项目管理以?qing)相关项目功能中都v?jin)重要的作用。对一个大型系l来_(d)软g功能需求也许只是系l需求的一个子集，因ؓ(f)另外一些可能属于子pȝQ或软g部gQ?br /> <clk>    作ؓ(f)功能需求的补充QY仉求规D明还应包括非功能需求，它描qC(jin)pȝ展现l用L(fng)行ؓ(f)和执行的<nobr id="clickeyekey0" onclick="kwC(event,0,"")" oncontextmenu="return false" onmouseover="kwE(event,0, this)" onmouseout="kwL(event,this)" onmousemove="kwM(0)" style="text-decoration: underline; color: #6600ff; background-color: transparent; border-bottom-width: 1px; border-bottom-style: dotted; border-bottom-color: #6600ff; ">操作</nobr>{。它包括产品必须遵从?/clk><a target="_blank" style="text-decoration: none; ">标准</a>、规范和合约Q外部界面的具体l节Q性能要求Q设计或实现的约束条件及(qing)质量属性。所谓约束是指对开发h员在软g产品设计和构造上的限制。质量属性是通过多种角度对品的特点q行描述Q从而反映品功能。多角度描述产品对用户和开发h员都极ؓ(f)重要?br />     下面以一个字处理E序Z来说明需求的不同U类。业务需求可能是Q?#8220;用户能有效地U正文档中的拼写错误”Q该产品的包装盒面上可能会(x)标明q是个满业务需求的拼写(g)查器。而对应的用户需求可能是“扑և文档中的拼写错误q过一个提供的替换列表来供选择替换拼错的词”。同Ӟ该拼写检查器q有许多功能需求，如找到ƈ高亮度提C错词的操作Q显C提供替换词的对话框以及(qing)实现整个文档范围的替换?br />     从以上定义可以发玎ͼ需求ƈ未包括设计细节、实现细节、项目计划信息或试信息。需求与q些没有关系Q它x的是充分说明你究竟想开发什么。项目也有其它方面的需求，如开发环境需求或发布产品?qing)移植到支撑环境的需求。尽这些需求对目成功也至关重要，但它们ƈ非本书所要讨论的?br /> <center><strong>5Q需求分析的原则</strong></center>不重视需求过E的目队伍自食其果。需求工E中的缺陷将l项目成功带来极大风险，q里?#8220;成功”是指推出的品能以合理的h、及(qing)时地在功能、质量上完全满用户的期望。下面将讨论一些需求风险?br />     不适当的需求过E所引v的一些风?<br />     1. 无够用户参?br /> <clk>    客户l常不明白ؓ(f)什么收集需求和保需求质量需p那么多功夫，开发h员可能也不重视用L(fng)参与。究其原因：(x)一是因为开发h员感觉与用户<nobr id="clickeyekey1" onclick="kwC(event,1,"")" oncontextmenu="return false" onmouseover="kwE(event,1, this)" onmouseout="kwL(event,this)" onmousemove="kwM(1)" style="text-decoration: underline; color: #6600ff; background-color: transparent; border-bottom-width: 1px; border-bottom-style: dotted; border-bottom-color: #6600ff; ">合作</nobr>不如~写代码有意思；二是因ؓ(f)开发h员觉得已l明白用L(fng)需求了(jin)。在某些情况下，与实际用品的用户直接接触很困难，而客户也不太明白自己的真正需求。但q是应让h代表性的用户在项目早期直接参与到开发队伍中Qƈ一同经历整个开发过E?/clk><br />     pȝ人员在实践过E中Q也有些感觉Q在实施一家公司的目Ӟ若无_的用户参与，pȝ人员获得的需求是片面的，不完整的Q这L(fng)l在需求之初就埋下风险?br />     2. 用户需求的不断增加<br />     在开发中若不断地补充需求，目p变越庞大以致过其计划及(qing)预算范围。计划ƈ不L与项目需求规模与复杂性、风险、开发生产率?qing)需求变更实际情늛一_(d)q得问题更难解冟뀂实际上Q问题根源在于用户需求的改变和开发者对新需求所作的修改?br />     要想把需求变更范围控制到最，必须一开始就寚w目视图、范围、目标、约束限制和成功标准l予明确说明Qƈ此说明作ؓ(f)评h(hun)需求变更和新特性的参照框架。说明中包括?jin)对每种变更q行变更影响因素分析?a target="_blank" style="text-decoration: none; ">变更控制</a>q程Q有助于所有风险承担者明白业务决{的合理性，即ؓ(f)何进行某些变_(d)相应消耗的旉?a target="_blank" style="text-decoration: none; ">资源</a>或特性上的折中?br />     产品开发中不断延箋的变更会(x)使其整体l构日渐紊ؕQ补丁代码也使得整个E序难以理解和维护。插入补丁代码模块q背强内聚、松耦合的设计原则，特别是如果项?a target="_blank" style="text-decoration: none; ">配置理</a>工作不完善的话，收回变更和删除特性会(x)带来问题。如果你早地区别这些可能带来变更的Ҏ(gu)，你就能开发一个更为健壮的l构Qƈ能更好地适应它。这栯计阶D需求变更不?x)直接导致补丁代码，同时也有利于减少因变更导致质量的下降?br />     3. 模棱两可的需?br />     模棱两可是需求规D明中最为可怕的问题。它的一层含义是指诸多读者对需求说明生了(jin)不同的理解；另一层含义是指单个读者能用不止一个方式来解释某个需求说明?br /> 模棱两可的需求会(x)使不同的风险承担者生不同的期望Q它?x)开发h员ؓ(f)错误问题而浪Ҏ(gu)_(d)q且使测试者与开发者所期望的不一致。一位系l测试h员曾告诉我，Ҏ(gu)在的试l经常对需求理解有误，以致不得不重写许多测试用例ƈ重做许多试?br />     处理模棱两可需求的一U方法是l织好负责从不同角度审查需求的队伍。仅仅简单浏览一下需求文档是不能解决模棱两可问题的。如果不同的评审者从不同的角度对需求说明给予解释，但每个评审h员都真正?jin)解需求文档，q样二义性就不会(x)直到目后期才被发现Q那时再发现的话?x)得更正代价很大?br />     4. 不必要的Ҏ(gu)?br /> <clk>    “画蛇添”是指开发h员力囑֢加一?#8220;用户ƣ赏”但需求规D明中q未涉及(qing)的新功能。经常发生的情况是用户ƈ不认些功能性很有用Q以致在其上耗费的努?#8220;白搭”?jin)。开发h员应当ؓ(f)客户构思方案ƈZ们提供一些具有创新意识的思\Q具体提供哪些功能要在客h需与开发h员在允许旉内的<nobr id="clickeyekey4" onclick="kwC(event,4,"")" oncontextmenu="return false" onmouseover="kwE(event,4, this)" onmouseout="kwL(event,this)" onmousemove="kwM(4)" style="text-decoration: underline; color: #6600ff; background-color: transparent; border-bottom-width: 1px; border-bottom-style: dotted; border-bottom-color: #6600ff; ">技?/nobr>可行性之间求得^衡，开发h员应努力使功能简单易用，而不要未l客户同意，擅自q客户要求Q自作主张?/clk><br />     同样Q客h时也可能要求一些看上去?#8220;?#8221;Q但~Z实用价值的功能Q而实现这些功能只能徒耗时间和成本。ؓ(f)?jin)?#8220;画蛇添”的危宛_量减，应确信：(x)你明白ؓ(f)什么要包括q些功能Q以?qing)这些功能?#8220;来龙去脉”Q这样得需求分析过E始l是注重那些能用户完成他们业务d的核?j)功能?br />     5. q于_的规D?br />     有时Q客户ƈ不明白需求分析有如此重要Q于是只作一份简略之至的规格说明Q仅涉及(qing)?jin)品概念上的内容，然后让开发h员在目q展中去完善Q结果很可能出现的是开发h员先建立产品的结构之后再完成需求说明。这U方法可能适合于尖端研I性的产品或需求本w就十分灉|的情c(din)但在大多数情况下，q会(x)l开发h员带来挫折（使他们在不正的假设前提和极其有限的指导下工作）(j)Q也?x)给客户带来烦(ch)恼Q他们无法得C们所设想的品）(j)?br />     6. 忽略?jin)用户分c?br />     大多C品是׃同的Z用其不同的特性，使用频繁E度也有所差异Q用者受<a target="_blank" style="text-decoration: none; ">教育</a>E度和经验水q也不尽相同。如果你不能在项目早期就针对所有这些主要用戯行分cȝ话，必然D有的用户对品感到失望。例如，菜单驱动操作寚wU用户太低效?jin)，但含义不清的命o(h)和快捷键又会(x)使不熟练的用h到困难?br />     7. 不准的计划<br />     据统计，D需求过E中软g成本估计极不准确的原因主要有以下五点Q频J的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规D明和不完善的需求分析?br /> 对不准确的要求所提问题的正确响应?#8220;{我真正明白你的需求时Q我׃(x)来告诉你”。基于不充分信息和未l深思的寚w求不成熟的估计很Ҏ(gu)Z些因素左叟뀂要作出估计Ӟ最好还是给Z个范围。未l准备的估计通常是作ZU猜给出的Q听者却认ؓ(f)是一U承诺。因此我们要力l出可达到的目标q坚持完成它?br /> <center><strong>6Q需求分析h员和用户的合作关p?/strong></center>    优秀的Y件品是建立在优U的需求基之上的。而高质量的需求来源于客户与开发h员之间有效的交流与合作。通常Q开发h员与客户或客户代理hQ如?jng)场人员间的关系反而会(x)成ؓ(f)一U对立关pR双方的理者都只想自己的利益而搁|用h供的需求从而生摩擦，在这U情况下Q不?x)给双方带来一点益处?br />     只有当双方参与者都明白要成功自己需要什么，同时也应知道要成功合作方需要什么时Q才能徏立v一U合作关pR由于项目压力与日渐增，所有风险承担者有着一个共同的目标q一点容易被遗忘。其实大安惛_发出一个既能实现商业h(hun)|又能满用户需要，q能使开发者感到满的优秀软g产品?br />     软g客户需求权利书列出?jin)十条关于客户在目需求工E实施中与分析h员、开发h员交时的合法要求。每一Ҏ(gu)利都对应着软g开发h员、分析h员的义务。而Y件客户需求义务书也列Z(jin)十条关于客户在需求过E中应承担的义务。如果愿意，可以其作ؓ(f)开发h员的权利书?br /> 客户有如下权利：(x)<br />     1Q要求分析h员用符合客戯a?fn)惯的表?br /> 需求讨论应集中于业务需要和dQ故要用业务术语，你应其教给分析人员Q而你 不一定要懂得计算机的行业术语?br />     2Q要求分析h员了(jin)解客L(fng)业务?qing)目?br />     通过与用户交来获取用户需求、分析h员才能更好地?jin)解你的业务d和怎样才能使品更好地满你的需要。这有助于开发h员设计出真正满你的需要ƈ辑ֈ你期望的优秀软g。ؓ(f)帮助开发h员和分析人员Q可以考虑邀(g)请他们观察你或你的同事是怎样工作的。如果新开发系l是用来替代已有的系l，那么开发h员应使用一下目前的pȝQ这有利于他们明白目前pȝ是怎样工作的，其工作流E的情况Q以?qing)可供改q之处?br />     3Q要求分析h员编写Y仉求规D?br />     分析人员要把从你和其他客户那里获得的所有信息进行整理，以区分开业务需求及(qing)规范、功能需求、质量目标、解x法和其它信息。通过q些分析p得到一份Y仉求规D明。而这份Y仉求规D明便在开发h员和客户之间针对要开发的产品内容达成?jin)协议。Y仉求规D明书可以用一U你认ؓ(f)易于阅和理解的方式l织~写。要评审~写出的规格说明以确保它们准而完整地表达?jin)你的需求。一份高质量的Y仉求规D明能有助于开发h员开发出真正需要的产品?br />     4Q要求得到需求工作结果的解释说明<br />     分析人员可能采用?jin)多U图表作为文字性Y仉求规D明的补充。因为如工作程NL(fng)图表能很清楚地描q出pȝ行ؓ(f)的某些方面。所以需求说明中的各U图表有着极高的h(hun)倹{虽然它们不太难于理解，但是你很可能Ҏ(gu)q不熟?zhn)。因此可以要求分析h员解释说明每张图表的作用或其它的需求开发工作结果和W号的意义，?qing)怎样(g)查图表有无错误及(qing)不一致等?br />     5Q要求开发h员尊重你的意?br />     如果用户与开发h员之间不能相互理解，那关于需求的讨论会(x)有障，共同合作能大家“兼听则明”。参与需求开发过E的客户有权要求开发h员尊重他们ƈ珍惜他们为项目成功所付出的时间。同P客户也应对开发h员ؓ(f)目成功q一共同目标所作出的努力表C尊重与感激?br />     6Q要求开发h员对需求及(qing)产品实施提供Q拿Z?br />     通常Q客h说的“需?#8221;已是一U实际可能的实施解决Ҏ(gu)Q分析h员将力从这些解x法中?jin)解真正的业务?qing)光求，同时q应扑և已有pȝ不适合当前业务之处Q以保产品不会(x)无效或低效。在d弄清业务领域内的事情后，分析人员有时p提出相当好的改进Ҏ(gu)。有l验且富有创造力的分析h员还能提出增加一些用户ƈ未发现的很有价值的pȝҎ(gu)?br />     7Q描qC品易使用的特?br />     你可以要求分析h员在实现功能需求的同时q要注重软g的易用性。因些易用特性或质量属性能使你更准、高效地完成d。例如，客户有时要求产品?#8220;用户友好”?#8220;健壮”?#8220;高效?#8221;Q但q对于开发h员来_(d)太主观了(jin)q无实用价倹{正的应是Q分析h员通过询问和调查了(jin)解客h要的友好、健壮、高效所包含的具体特性?br />     8Q调整需求，允许重用已有的Y件组?br />     需求通常要有一定的灉|性。分析h员可能发现已有的某个软glg与你描述的需求很相符。在q种情况下，分析人员应提供一些修攚w求的选择以便开发h员能够在新系l开发中重用一些已有的软g。如果有可重用的Z(x)出现Q同时你又能调整你的需求说明，那就能降低成本和节省旉Q而不必严格按原有的需求说明开发。所以说Q如果想在品中使用一些已有的商业常用lgQ而它们ƈ不完全适合你所需的特性，q时一定程度上的需求灵zL就昑־极ؓ(f)重要?jin)?br />      9Q获得满_户功能和质量要求的系l?br />     每个人都希望目获得成功。但q不仅要求你要清晰地告知开发h员关于系l?#8220;做什?#8221;所需的所有信息，而且q要求开发h员能通过交流?jin)解清楚取舍与限制。一定要明确说明你的假设和潜在的期望。否则，开发h员开发出的品很可能无法让你满意?br /> 客户有下列义务：(x)<br />     1Q给分析人员讲解你的业务<br />     分析人员要依靠你l他们讲解的业务概念?qing)术语。但你不能指望分析h员会(x)成ؓ(f)该领域的专家Q而只能让他们真正明白你的问题和目标。不要期望分析h员能把握你们业务的细微与潜在之处Q他们很可能q不知道那些对于你和你的同事来说理所当然?#8220;常识”?br />     2Q抽出时间清楚地说明q完善需?br />     客户很忙Q经常在最忙的时候还得参与需求开发。但无论如何Q你有义务抽出时间参?#8220;头脑风暴”<a target="_blank" style="text-decoration: none; ">?x)?/a>的讨论，接受采访或其它获取需求的zd。有时分析h员可能先以ؓ(f)明白?jin)你的观点，而过后发现还需要你的讲解。这Ӟ误(g)心(j)一些对待需求和需求的_֌工作q程中的反复Q因为它是h们交中的很自然的现象，何况q对软g产品的成功极为重要?br />     3Q准而详l地说明需?br />     ~写一份清晰、准的需求文档是很困隄。由于处理细节问题不但烦(ch)且又耗时Q故很容易留下模p不清的需求。但是，在开发过E中Q必d解决q种模糊性和不准性。而你恰是册些问题作出决定的最佳h选。不然的话，你就只好靠开发h员去正确猜测?jin)。在需求规D明中暂时加上待定Qto be determined, TBD也可采用汉语拼音略写“DQDQ待定”Q的标志是个不错的办法。用该标志可指明?jin)哪些需要进一步探讨、分析或增加信息的地斏V不q，有时也可能因为某个特D需求难以解x没有人愿意处理它而注上TBD标志。尽量将每项需求的内容都阐q清楚，以便分析人员能准的其写进软g需求规D明中。如果你一时不能准表qͼ那就得允许获取必要的准确信息q样一个过E。通常使用所谓的原型技术。通过开发的原型Q你可以同开发h员一起反复修改，不断完善需求定义?br />     4Q及(qing)时地作出军_<br />     正如一位徏{师Z修徏房屋Q分析h员将要求你做Z些选择和决定。这些决定包括来自多个用h出的处理Ҏ(gu)或在质量Ҏ(gu)冲H和信息准确度中选择折衷Ҏ(gu){。有权做出决定的客户必须U极地对待这一切，快做处理、做军_。因为开发h员通常只有{你做出?jin)决定才能行动，而这U等待会(x)延误目的进展?br />     5Q尊重开发h员的需求可行性及(qing)成本评估<br />     所有的软g功能都有其成本h(hun)|开发h员最适合预算q些成本Q尽许多开发h员ƈ不擅长评估预）(j)。你所希望的某些品特性可能在技术上行不通，或者实现它要付出极为高昂的代h(hun)。而某些需求试囑֜操作环境中要求不可能辑ֈ的性能或试囑־C些根本得不到的数据，开发h员会(x)Ҏ(gu)作出负面的评h见，你应该尊重他们的意见。有Ӟ你可以重新给Z个在技术上可行、实C便宜的需求，例如Q要求某个行为在“瞬间”发生是不可行的，但换U更具体的时间需求说法（“?0ms以内”,但若没有准确的技术分析不能轻易下l论Q，q就可以实现?jin)?br />     6Q?划分需求优先?br />     大多数项目没有够的旉或资源来实现功能性的每个l节。决定哪些特性是必要的，哪些是重要的Q哪些是好的Q是需求开发的主要部分。只能由你来负责讑֮需求优先Q因为开发者ƈ不可能按你的观点军_需求优先。开发者将Z定优先U提供有x个需求的p和风险的信息。当你设定优先Ӟ你帮助开发者确保在适当的时间内用最的开支取得最好的效果。在旉和资源限制下Q关于所需Ҏ(gu)能否完成或完成多少应该重开发h员的意见。尽没有h愿意看到自己所希望的需求在目中未被实玎ͼ但毕竟是要面对这U现实的。业务决{有时不得不依据优先U来~小目范围或g长工期，或增加资源，或在质量上寻找折街?br />     7Q评审需求文档和原型<br />     正如我们在W? 4章讨论的Q无论是正式的还是非正式的方式，寚w求文档进行评审都?x)对软g质量提高有所帮助。让客户参与评审才能真正鉴别需求文档是否的完整、正说明了(jin)期望的必要特性。评审也l客户代表提供一个机?x)，l需求分析h员带来反馈信息以改进他们的工作。如果你认ؓ(f)~写的需求文档不够准，有义务早告诉分析人员qؓ(f)改进提供。通过阅读需求规D明，很难惌实际的Y件是什么样子的。更好的Ҏ(gu)是先Z品开发一个原型。这样你p提供更有价值的反馈信息l开发h员，帮助他们更好地理解你的需求。必认识到Q原型ƈ非是一个实际品，但开发h员能其转变、扩充成功能齐全的系l?br />      8Q需求出现变更要马上联系<br />      不断的需求变更会(x)l在预定计划内完成高质量产品带来严重的负面媄(jing)响。变更是不可避免的，但在开发周期中变更在晚期出现Q其影响大。变更不仅会(x)D代h(hun)极高的返工，而且工期也会(x)被迫延误Q特别是在大体结构已完成后又需要增加新Ҏ(gu)时。所以一旦你发现需要变更需求时Q请一定立即通知分析人员?br />     9Q应늅开发组l处理需求变更的q程<br />     Z(jin)变更带来的负面影响减少到最低限度，所有的参与者必遵照项目的变更控制q程。这要求不放弃所有提出的变更Q对每项要求的变更进行分析、综合考虑Q最后作出合适的决策以确定将某些变更引入目中?br />     10Q尊重开发h员采用的需求工E过E?br /> 软g开发中最h战性的莫过于收集需求ƈ定其正性。分析h员采用的Ҏ(gu)有其合理性。也怽认ؓ(f)需求过E不太划，但请怿花在需求开发上的时间是“很有价?#8221;的。如果你理解q支持分析h员ؓ(f)攉、编写需求文档和保其质量所采用的技术，那么整个q程会(x)更ؓ(f)利。尽去询问分析人员Z么他们要攉某些信息Q或参与与需求有关的zd?br />     pȝ分析人员在开发过E中可能?x)遇C下问题，一些很忙的客户可能不愿意积极参与需求过E，而缺客户参与将很可能导致不理想的品。故一定要保需求开发中的主要参与者都?jin)解q接受他们的义务。如果遇到分歧，通过协商以达成对各自义务的相互理解，q样能减今后的摩擦?br /> <center><strong>7Q需求文?/strong></center>    需求开发的最l成果是Q客户和开发小l对要开发的产品达成一致协议。协议综合了(jin)业务需求、用户需求和软g功能需求。就像我们早先所看到的，目视图和范围文档包含了(jin)业务需求，而用实例文档则包含?jin)用户需求。你必须~写从用实例派生出的功能需求文档，q要~写产品的非功能需求文档，包括质量属性和外部接口需求。只有以l构化和可读性方式编写这些文档，q由目的风险承担者评审通过后，各方面h员才能确信他们所赞同的需求是可靠的?br />     你可以用以下三U方法编写Y仉求规D明：(x)<br />      用好的结构化和自然语a~写文本型文档?br />      建立囑Ş化模型，q些模型可以描绘转换q程、系l状态和它们之间的变化、数据关pR逻辑或对象cd它们的关pR?br />      ~写形式化规D明，q可以通过使用数学上精的形式化逻辑语言来定义需求?br /> <clk>׃形式化规D明具有很强的严密性和_度，因此Q所使用的Ş式化语言只有极少数Y件开发h员才熟?zhn)Q更不用说客户了(jin)。虽然结构化的自然语ah许多~点Q但在大多数<nobr id="clickeyekey5" onclick="kwC(event,5,"")" oncontextmenu="return false" onmouseover="kwE(event,5, this)" onmouseout="kwL(event,this)" onmousemove="kwM(5)" style="text-decoration: underline; color: #6600ff; background-color: transparent; border-bottom-width: 1px; border-bottom-style: dotted; border-bottom-color: #6600ff; ">软g工程</nobr>中，它仍是编写需求文档最现实的方法。包含了(jin)功能和非功能需求的Z文本的Y仉求规D明已lؓ(f)大多数项目所接受。图形化分析模型通过提供另一U需求视图，增强?jin)Y仉求规D明?/clk><br />     软g需求规D明不仅是pȝ试和用h档的基础Q也是所有子pd目规划、设计和~码的基。它应该可能完整地描述pȝ预期的外部行为和用户可视化行为。除?jin)设计和实现上的限制QY仉求规D明不应该包括设计、构造、测试或工程理的细节。许多读者用Y仉求规D明来辑ֈ不同的目的：(x)<br />     客户和营销部门依赖它来?jin)解他们所能提供的产品?br />      <a target="_blank" style="text-decoration: none; ">目l理</a>Ҏ(gu)包含在Y仉求规D明中描述的品来制定规划q进度安排、工作量和资源?br />      软g开发小l依赖它来理解他们将要开发的产品?br />      试组使用软g需求规D明中对品行为的描述制定试计划、测试用例和试q程?br />      软gl护和支持h员根据需求规D明了(jin)解品的某部分是做什么的?br />      产品发布l在需求规D明和用户界面设计的基上编写客h档，如用h册和帮助屏幕{?br />      <a target="_blank" style="text-decoration: none; ">培训</a><clk>人员Ҏ(gu)需求规D明和用户文档~写<nobr id="clickeyekey7" onclick="kwC(event,7,"")" oncontextmenu="return false" onmouseover="kwE(event,7, this)" onmouseout="kwL(event,this)" onmousemove="kwM(7)" style="text-decoration: underline; color: #6600ff; background-color: transparent; border-bottom-width: 1px; border-bottom-style: dotted; border-bottom-color: #6600ff; ">培训</nobr>材料?/clk><br /> 软g需求规D明作Z品需求的最l成果必d有综合性：(x)必须包括所有的需求。开发者和客户不能作Q何假设。如果Q何所期望的功能或非功能需求未写入软g需求规D明，那么它将不能作ؓ(f)协议的一部分q且不能在品中出现?br />     我见q有一个项目突然接到测试h员发出的错误N的报告。结果是他们试的是老版本的软g需求规D明，而他们觉得错误的地方正是产品所独有的特性。他们的试工作是徒劳的Q因Z们一直在老版本的软g需求规D明中L错误的系l行为?br />     在编写Y仉求规D明，希望读者牢C下的Q?br />      对节、小节和单个需求的L(fng)~排必须一致?br />      在右辚w分留下文本注释区?br />      允许不加限制C用空根{?br />      正确使用各种可视化强调标志（例如Q黑体、下划线、斜体和其它不同字体Q?br />      创徏目录表和索引表有助于读者寻找所需的信息?br />      Ҏ(gu)有图和表指定L(fng)和标识号Qƈ且可按号码进行查阅?br />      使用字处理程序中交叉引用的功能来查阅文档中其它项或位|，而不是通过늠或节受?br />     Z(jin)满软g需求规D明的可跟t性和可修Ҏ(gu)的质量标准Q必d一定每个软g需求。这可以使你在变更请求、修改历史记录、交叉引用或需求的可跟t矩阵中查阅特定的需求。由于要辑ֈq一目的Q用单一的项目列表是不够的，因此Q我描q几个不同的需求标识方法，q明它们的优点与缺炏V可以选择最适合你的Ҏ(gu)?br />     (1) 序列h单的Ҏ(gu)是赋予每个需求一个唯一的序列号Q例如SRS-13。当一个新的需求加入到商业需求管理工L(fng)数据库之后，q些理工具׃(x)为其分配一个序列号Q许多这L(fng)工具也支持层ơ化~号Q。序列号的前~代表?jin)需求类型，例如SRS代表“软g需求说?#8221;。由于序列号不能重用Q所以把需求从数据库中删除Ӟq不释放其所占据的序列号Q而新的需求只能得C一个可用的序列受这U简单的~号Ҏ(gu)q不能提供Q何相关需求在逻辑上或层次上的区别Q而且需求的标识不能提供M有关每个需求内容的信息?br />     (2) 层次化编码这也许是最常用的方法。如果功能需求出现在软g需求规D明中W? . 2部分Q那么它们将h诸如3.2.4.3q样的标识号。标识号中的数字多则表C需求越详细Q属于较低层ơ上的需求。即使在一个中型的软g需求规D明中Q这些标识号也会(x)扩展到许多位数字Qƈ且这些标识也不提供Q何有x个需求目的的信息。如果你要插入一个新的需求，那么该需求所在部分其后所有需求的序号要增加。删除或Ud一个需求，那么该需求所在部分其后所有需求的序号要减少。但其他地方的引用将混ؕQ对于这U简单的层次化编L(fng)一U改q方法是寚w求中主要的部分进行层ơ化~号Q然后对于每个部分中的单一功能需求用一个简短文字代码加上一个序列号来识别。例如，软g需求规D明可能包?#8220;W?.2.5部分—编辑功?#8221;Qƈ此部分~写成子模块文档Q然后配|管理?br />     有时Q你觉得~少特定需求的某些信息。在解决q个不确定性之前，可能必须与客户商议、检查与另一个系l的接口或者定义另一个需求。?#8220;待确?#8221;Qto be determined, TBD或采用汉语拼音略写DQDQ符号作为标准指C器来强调Y仉求规D明中q些需求的~陷。通过q种Ҏ(gu)Q你可以在Y仉求规D明中查找所要澄清需求的部分。记录谁解军_个问题、怎样解决?qing)什么时候解冟뀂把每个TBD~号q创Z个TBD列表Q这有助于方便地跟踪每个目?br />     在l进行构造需求集合之前，必须解决所有的TBD问题Q因ZQ何遗留下来的不确定问题将?x)增加出错的风险和需求返工。当开发h员遇C个TBD问题或其它模p之处时Q他可能不会(x)q回到原始需求来解决问题。多半开发者对它进行猜，但ƈ不L正确的。如果有TBD问题未解决Q而你又要l箋q行开发工作，那么可能推q实现这些需求，或者解册些需求的开攑ּ问题Q把产品的这部分设计得易于更攏V?br />     ~写优秀的需求文档没有现成固定的Ҏ(gu)Q最好是Ҏ(gu)l验q行。从q去所遇到的问题中可你受益匪。许多需求文档可以通过使用有效的技术编写风格和使用用户术语而不是计机专业术语的方式得以改q?br /> 你在~写优秀的需求文档时Q希望读者还需牢记以下几点Q?br />      保持语句和段落的短?br />      采用d语态的表达方式?br />      ~写h正确的语法、拼写和标点的完整句子?br />      使用的术语与词汇表中所定义的应该一致?br />      需求陈q应该具有一致的样式Q例?#8220;pȝ必须..”或?#8220;用户必须..”Qƈ紧跟一个行为动作和可观察的l果。例如，“仓库理子系l必LCZ张所h的仓库中有存货的库存清单?#8221;<br />      Z(jin)减少不确定性，必须避免模糊的、主观的术语Q例如，用户友好、简单、有效、、最<a target="_blank" style="text-decoration: none; ">新技?/a>、优的、可接受的等。当用客?#8220;用户友好”或?#8220;?#8221;Ӟ你应该明它们的真正含义q且在需求中阐明用户的意图?br />      避免使用比较性的词汇Q定量地说明所需要提高的E度或者说清一些参数可接受的最大值和最倹{当客户说明pȝ应该“处理”?#8220;支持”?#8220;理”某些事情Ӟ你应该能理解客户的意图。由于需求的~写是层ơ化的，因此Q可以把层不明的需求向低层详细分解Q直到消除不明确性ؓ(f)止?br />      文档的编写h员不应该把多个需求集中在一个冗长的叙述D落中。在需求中诸如“?#8221;Q?#8220;?#8221;之类的连词就表明?jin)该部分集中了(jin)多个需求。务必记住，不要在需求说明中使用“??#8221;Q?#8220;{等”之类的连词?br /> <center><strong>8Q需求分析的q程</strong></center>    需求获取是在问题及(qing)其最l解x案之间架设桥梁的W一步。获取需求的一个必不可的l果是对目中描q的客户需求的普遍理解。一旦理解了(jin)需求，分析者、开发者和客户p探烦(ch)出描q这些需求的多种解决Ҏ(gu)。参与需求获取者只有在他们理解?jin)问题之后才能开始设计系l，否则Q对需求定义的M改进Q设计上都必d量的q工。把需求获取集中在用户d上—而不是集中在用户接口上—有助于防止开发组׃草率处理设计问题而造成的失误?br />     需求获取、分析、编写需求规D明和验证q不遵@U性的序Q这些活动是怺隔开、增量和反复的。当你和客户合作Ӟ你就会(x)问一些问题，q且取得他们所提供的信息（需求获取）(j)。同Ӟ你将处理q些信息以理解它们，q把它们分成不同的类别，q要把客户需求同可能的Y仉求相联系。然后，你可以客户信息l构化，q编写成文档和示意图。下一步，可以让客户代表评审文档q纠正存在的错误。这四个q程贯穿着需求开发的整个阶段?br />     ׃软g开发项目和l织文化的不同，对于需求开发没有一个简单的、公式化的途径。下面列Z(jin)1 4个步骤，你可以利用它们指g的需求开发活动。对于需求的M子集Q一旦你完成?jin)第十三步，那么你就可以很有信?j)地l进行系l的每一部分的设计、构造，因ؓ(f)你将开发出一个好的?<br />     1. 定义目的视囑֒范围?br />     2. 定用户cR?br />     3. 在每个用L(fng)中确定适当的代表?br />     4. 定需求决{者和他们的决{过E?br />     5. 选择你所用的需求获取技术?br />     6. q用需求获取技术对作ؓ(f)pȝ一部分的用实例进行开发ƈ讄优先U?br />     7. 从用户那里收集质量属性的信息和其它非功能需求?br />     8. 详细拟订使用实例使其融合到必要的功能需求中?br />     9. 评审使用实例的描q和功能需求?br />     10. 如果有必要，p开发分析模型用以澄清需求获取的参与者对需求的理解?br />     11. 开发ƈ评估用户界面原型以助惛_q未理解的需求?br />     12. 从用实例中开发出概念试用例?br />     13. 用测试用例来使用实例、功能需求、分析模型和原型?br />     14. 在l进行设计和构造系l每一部分之前Q重?~1 3步?br /> 需求获取可能是软g开发中最困难、最关键、最易出错及(qing)最需要交的斚w。需求获取只有通过有效的客户—开发者的合作才能成功。分析者必d立一个对问题q行d探讨的环境，而这些问题与产品有关。ؓ(f)?jin)方便清晰地q行交流Q就要列出重要的组Q而不是假x有的参与者都持有相同的看法。对需求问题的全面考察需要一U技术，利用q种技术不但考虑?jin)问题的功能需求方面，q可讨论目的非功能需求。确定用户已l理解：(x)对于某些功能的讨论ƈ不意味着卛_在品中实现它。对于想到的需求必集中处理ƈ讑֮优先U，以避免一个不能带来Q何益处的无限大的目?br />     需求获取是一个需要高度合作的zdQ而ƈ不是客户所说的需求的单拷贝。作Z个分析者，你必透过客户所提出的表面需求理解他们的真正需求。询问一个可扩充的问题有助于你更好地理解用户目前的业务过Eƈ且知道新pȝ如何帮助或改q他们的工作?br /> 需求获取利用了(jin)所有可用的信息来源Q这些信息描qC(jin)问题域或在Y件解x案中合理的特性。一个研I表明：(x)比v不成功的目Q一个成功的目在开发者和客户之间采用?jin)更多的交流方式。与单个客户或潜在的用户l一起谈，对于业务软g包或<a target="_blank" style="text-decoration: none; ">信息理</a>pȝQMISQ的应用来说是一U传l的需求来源?br />     在每一ơ谈讨Z后，C所讨论的条目，q请参与讨论的用戯论ƈ更正。及(qing)早ƈl常q行座谈讨论是需求获取成功的一个关键途径Q因为只有提供需求的人才能确定是否真正获取需求。进行深入收集和分析以消除Q何冲H或不一致性。尽量理解用L(fng)于表qC们需求的思维q程。充分研I用h行Q务时作出决策的过E，q提取出潜在的逻辑关系。流E图和决{树(wi)是描q这些逻辑决策途径的好Ҏ(gu)?br />     当进行需求获取时Q应避免受不成熟的细节的影响。在对切合的客户d取得p之前Q用戯很容易地在一个报表或对话框中列出每一的_设计。如果这些细节都作ؓ(f)需求记录下来，他们?x)给随后的设计过E带来不必要的限制。你可能要周期性地(g)查需求获取，以确保用户参与者将注意力集中在与今天所讨论的话题适合的抽象层上。向他们保证在开发过E中Q将?x)详阐qC们的需求?br />     在一个逐次详细描述q程中，重复地详q需求，以确定用L(fng)标和dQƈ作ؓ(f)使用实例。然后，把Q务描q成功能需求，q些功能需求可以用户完成其Q务，也可以把它们描述成非功能需求，q些非功能需求描qC(jin)pȝ的限制和用户对质量的期望。虽然最初的屏幕构思有助于描述你对需求的理解Q但是你必须l化用户界面设计</span> <img src ="http://www.tkk7.com/wufang5/aggbug/259019.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.tkk7.com/wufang5/" target="_blank">懒虫</a> 2009-03-11 10:20 <a href="http://www.tkk7.com/wufang5/articles/259019.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss> <footer> <div class="friendship-link"> <p>лǵվܻԴȤ</p> <a href="http://www.tkk7.com/" title="亚洲av成人片在线观看">亚洲av成人片在线观看</a> <div class="friend-links"> </div> </div> </footer> վ֩ģ壺 <a href="http://www-840012.com" target="_blank">ȫӳѹۿ߿</a>| <a href="http://528676.com" target="_blank">˳վ߹ۿ</a>| <a href="http://91ttvv.com" target="_blank">91ƵƷȫѹۿ</a>| <a href="http://zz4466.com" target="_blank">޹Ʒ߲ </a>| <a href="http://93qsgy.com" target="_blank">ɫWWWƷƵ</a>| <a href="http://gzweida88.com" target="_blank">鶹Ʒѿ</a>| <a href="http://91ttvv.com" target="_blank">޾ƷAAƬѽ</a>| <a href="http://266hd.com" target="_blank">ĻƷƵ</a>| <a href="http://gxshenquan.com" target="_blank">ɫһëƬ޻Ƭȫ</a>| <a href="http://xx16xx.com" target="_blank">һһͰһƵ </a>| <a href="http://guoyit.com" target="_blank">߿ƬvѹۿƵ777</a>| <a href="http://gg596gg.com" target="_blank">þպƷһ</a>| <a href="http://5s6b.com" target="_blank">Ƶ</a>| <a href="http://bjlfggcm.com" target="_blank">sss߲</a>| <a href="http://v1s3u5.com" target="_blank">ӰƬ鶹ӰƬѹۿ</a>| <a href="http://dbyssw.com" target="_blank">޳avƬwwwѼ</a>| <a href="http://26uuyy.com" target="_blank">߹ۿ㶮</a>| <a href="http://fsrongxing.com" target="_blank">ִˬƵ</a>| <a href="http://3atv66.com" target="_blank">޵һ㽶_a</a>| <a href="http://gzmsijz.com" target="_blank">ŷһëƬ</a>| <a href="http://0515zs.com" target="_blank">ŷɫŷ</a>| <a href="http://yaku100.com" target="_blank">޾Ʒ˾þþ</a>| <a href="http://9844555.com" target="_blank">þþþþþõѲ</a>| <a href="http://changfafangzhi.com" target="_blank">޼Ůۺ99</a>| <a href="http://1880531.com" target="_blank">޲AVӰƬ߲</a>| <a href="http://1y3c.com" target="_blank">Դ߹ۿѰ </a>| <a href="http://33sse.com" target="_blank"> ר</a>| <a href="http://cn-zggx.com" target="_blank">ŮһͰһһƵ </a>| <a href="http://shandonghj.com" target="_blank">պĻһ</a>| <a href="http://xiamenwave.com" target="_blank">ҹ޸˾</a>| <a href="http://6000cpkj.com" target="_blank">þþƷƵ</a>| <a href="http://acccx.com" target="_blank">һ24޿</a>| <a href="http://liuxilife.com" target="_blank">޹˾þһҳ</a>| <a href="http://ee45987.com" target="_blank">99þۺϾƷ</a>| <a href="http://www1616hh.com" target="_blank">ŷ߹ۿ</a>| <a href="http://9akk.com" target="_blank">޳ɫۺվ</a>| <a href="http://xxxxnii.com" target="_blank">ѸԴվ߹ۿ</a>| <a href="http://hubmba.com" target="_blank">aëƬƵѹۿӰԺ</a>| <a href="http://bdykdq.com" target="_blank">ҹþþþ </a>| <a href="http://see13.com" target="_blank">޹Ʒպ߹ۿ</a>| <a href="http://dqcjlb.com" target="_blank">ڵ߹ۿƵ</a>| <script> (function(){ var bp = document.createElement('script'); var curProtocol = window.location.protocol.split(':')[0]; if (curProtocol === 'https') { bp.src = 'https://zz.bdstatic.com/linksubmit/push.js'; } else { bp.src = 'http://push.zhanzhang.baidu.com/push.js'; } var s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(bp, s); })(); </script> </body>