1、软件需求软件需求工程工程周立新周立新 博士博士北京大学软件与微电子学院北京大学软件与微电子学院课程提纲课程提纲1.1.软件需求基本理论和概念软件需求基本理论和概念 2.2.软件需求工程过程软件需求工程过程 3.3.软件需求获取软件需求获取 4.4.软件需求分析软件需求分析 5.5.软件需求规格说明软件需求规格说明 6.6.软件需求验证软件需求验证 7.7.软件需求管理软件需求管理 8.8.软件需求实现软件需求实现 9.9.软件需求工程新进展软件需求工程新进展 10.10.软件需求开发与需求管理工具软件需求开发与需求管理工具课程参考书课程参考书1.1.Karl E.Karl E.WiegersW
2、iegers著著,陆丽娜，王忠民，王志敏等译，软陆丽娜，王忠民，王志敏等译，软件需求，机械工业出版社，件需求，机械工业出版社，20002000 2.2.Ian K.BrayIan K.Bray著著，需求工程导引，人民邮电出版社，需求工程导引，人民邮电出版社，20032003 3.3.Geri Schneider and Jason P.WintersGeri Schneider and Jason P.Winters著著,姚淑珍，李姚淑珍，李巍等译，用例分析技术，机械工业出版社，巍等译，用例分析技术，机械工业出版社，20022002 4.4.Dean Dean LeffingwellLeffi
3、ngwell and Don and Don WidrigWidrig著著,蒋慧，林东译，蒋慧，林东译，软件需求管理：统一方法，机械工业出版社，软件需求管理：统一方法，机械工业出版社，20022002 5.5.Ralph R.YoungRalph R.Young著著,韩柯，耿民等译，有效需求实践，韩柯，耿民等译，有效需求实践，机械工业出版社，机械工业出版社，20022002 6.6.以上参考书相对应的英文版本以上参考书相对应的英文版本7.7.RUPRUP第一章第一章 软件需求基本理论和概念软件需求基本理论和概念1.软件需求定义软件需求定义2.需求工程的本质需求工程的本质3.问题域与解系统问题域
4、与解系统4.软件需求分类软件需求分类1.功能需求功能需求2.性能需求性能需求(非功能需求非功能需求)3.设计约束设计约束4.商业约束商业约束5.客户客户/用户用户/开发者的需求观开发者的需求观6.不合格的需求派生的问题不合格的需求派生的问题7.高质量的需求带来的好处高质量的需求带来的好处8.优秀需求所具有的特征优秀需求所具有的特征项目失败的原因分析No.Top 10 Factors 平均值平均值 1 Inadequate requirements specification 不充分的需求规范不充分的需求规范 4.5 2 Changes in requirements 需求的改变需求的改变 4.
5、3 3 Shortage of systems engineers 缺乏系统工程师缺乏系统工程师 4.2 4 Shortage of software managers 缺乏了解软件特性的经理人缺乏了解软件特性的经理人 4.1 5 Shortage of qualified project managers 缺乏合格的缺乏合格的项目经理项目经理 4.1 6 Shortage of software engineers 缺乏软件工程师缺乏软件工程师 3.9 7 Fixed-price contract 固定价合同固定价合同 3.8 8 Inadequate communications for
6、system integration 系统集成系统集成阶段阶段,交流与沟通不充分交流与沟通不充分 3.8 9 Insufficient experience as team 团队缺乏经验团队缺乏经验 3.6 10 Shortage of application domain experts 缺乏应用领域缺乏应用领域专家专家 3.6 Scale:5=Very Serious 3=Serious 1=No Serious Source:Carnegie-Mellon University,Software Engineering Institute错误认识错误认识A general stateme
7、nt of objectives is sufficient to begin writing programs we can fill in the details later需求不清楚就进入编程阶段，期望以后修改。需求不清楚就进入编程阶段，期望以后修改。更多的情况下是边写边修改更多的情况下是边写边修改Project requirements continually change,but change can be easily accommodated because software is flexible软件调节和改变是很灵活的，任何需求的变更软件调节和改变是很灵活的，任何需求的变更都
8、可容易地在软件中反映出来都可容易地在软件中反映出来这些认识多来自极小项目的开发经验，当你面对这些认识多来自极小项目的开发经验，当你面对一个中大型项目时必须彻底改变这些错误观念！一个中大型项目时必须彻底改变这些错误观念！1.软件需求的定义软件需求的定义 IEEEIEEE软件工程中需求的定义软件工程中需求的定义(1977)(1977)1.1.用户解决问题或达到目标所需的条件和能力用户解决问题或达到目标所需的条件和能力2.2.系统或系统部件为满足合同、系统或系统部件为满足合同、标准标准、规范或其它正式、规范或其它正式规定文档所需具有的条件和能力规定文档所需具有的条件和能力3.3.以上条件和能力的以上
9、条件和能力的文档说明文档说明 客户希望在客户希望在问题域问题域内产生的效果内产生的效果需求与问题域的差别需求与问题域的差别 SommervilleSommerville&Sawyer 1997&Sawyer 1997需求是指系统必须实现什么的规格说明。它描述了系需求是指系统必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约统的行为、特性或属性，是在开发过程中对系统的约束束2.需求工程的本质需求工程的本质 需求工程简单化描述为她关注系统将要做什么；需求工程简单化描述为她关注系统将要做什么；而设计关注系统将怎样做而设计关注系统将怎样做 需求工程可以看作把一个定义不足的
10、问题转换为需求工程可以看作把一个定义不足的问题转换为一个定义充分的问题以便找出解决方案。这是因一个定义充分的问题以便找出解决方案。这是因为客户需求信息经常是粗糙的和不完整的为客户需求信息经常是粗糙的和不完整的 需求工程的通用性、理论性和实践性，怎样理解需求工程的通用性、理论性和实践性，怎样理解其学科性质，如何学习才能掌握它的本质？有一其学科性质，如何学习才能掌握它的本质？有一劳永逸的方法和工具吗？能否将另一个成功项目劳永逸的方法和工具吗？能否将另一个成功项目的需求工程方法照搬到现在的项目的需求工程方法照搬到现在的项目 答案是不答案是不能！能！3.问题域问题域(Problem Domain)与与
11、解系统解系统(Solution System)问题域：被开发系统的应用领域，即问题域：被开发系统的应用领域，即在现实世界中由这个系统进行处理的在现实世界中由这个系统进行处理的业务范围业务范围 解系统：指可以在问题域内产生某种解系统：指可以在问题域内产生某种效果的系统，而构成软件需求的正是效果的系统，而构成软件需求的正是这些想要获得的效果，它也正是为何这些想要获得的效果，它也正是为何做软件需求的原因和目的做软件需求的原因和目的问题域问题域 Problem Domain问题域问题域 接口接口 解系统解系统分析分析规格说明规格说明设计设计问题域的类型问题域的类型 分类分类I I1.1.系统软件系统软
12、件2.2.应用软件，进一步划分为商业软件和工程软件应用软件，进一步划分为商业软件和工程软件 分类分类IIII1.1.批处理系统批处理系统/系统脱机系统脱机2.2.交互系统交互系统3.3.实时系统实时系统 分类分类IIIIII1.1.数据为主的系统数据为主的系统2.2.交互为主的系统交互为主的系统3.3.算法为主的系统算法为主的系统问题域的类型问题域的类型数据为主数据为主交互为主交互为主算法为主算法为主A.A.气象预报系统气象预报系统B.B.收银机系统收银机系统C.C.电梯控制系统电梯控制系统D.D.工资系统工资系统E.E.文字处理系统文字处理系统F.F.文件转换系统文件转换系统G.G.手机定位
13、系统手机定位系统A AB BC CD DE EF FG G需求的层次需求的层次业务需求业务需求项目视图与项目视图与范围文档范围文档用户需求用户需求质量属性质量属性使用实例文档使用实例文档系统需求系统需求功能需求功能需求其它非功其它非功能需求能需求约束条件约束条件软件需求规格说明软件需求规格说明SRS4.软件需求的分类软件需求的分类 业务需求业务需求业务需求业务需求(business requirement)(business requirement)反映反映了组织机构或客户对系统、产品高层次了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图和范围文的目标要求，它们在项目视图和范围文档
14、中予以说明档中予以说明例如某运营商对定位系统的业务需求例如某运营商对定位系统的业务需求4.软件需求的分类软件需求的分类 用户需求用户需求用户需求用户需求(user requirement)(user requirement)描述描述了用户使用产品必须要完成的任务，了用户使用产品必须要完成的任务，它们在使用实例它们在使用实例(use case)(use case)和情景和情景描述描述(scenario)(scenario)文档中予以说明文档中予以说明4.软件需求的分类软件需求的分类 功能需求功能需求“一般一般”意义的需求指的是功能或行为需求，意义的需求指的是功能或行为需求，这样的需求通常是和解系
15、统的适当行为这样的需求通常是和解系统的适当行为(用户需用户需求求)相关联，是开发人员必须实现的软件功能。相关联，是开发人员必须实现的软件功能。功能需求可以在多种不同的抽象层次上来表达，功能需求可以在多种不同的抽象层次上来表达，这使得导出需求过程比较复杂和困难：这使得导出需求过程比较复杂和困难：a)a)Physical behaviorPhysical behaviorb)Input-output relationshipb)Input-output relationshipc)Observable statesc)Observable statesd)User interfaced)User
16、interface4.软件需求的分类软件需求的分类 非功能需求非功能需求非功能需求是功能需求的补充，它描述了系统非功能需求是功能需求的补充，它描述了系统完成功能实现的补充和约束条件。如产品必须完成功能实现的补充和约束条件。如产品必须遵从的标准、国际规范和合约；外部界面的规遵从的标准、国际规范和合约；外部界面的规范；性能需求如：系统运行速度范；性能需求如：系统运行速度(Speed)(Speed)，可靠，可靠性性(Reliability)(Reliability)，容量，容量(Capacity)(Capacity)，可用性，可用性(Availability),(Availability),可使用性
17、可使用性(Usability)(Usability)；其它；其它质量属性如：质量属性如：快捷性、简易性、直觉性、健壮快捷性、简易性、直觉性、健壮性等。性等。4.软件需求的分类软件需求的分类 非功能需求非功能需求a)Responsea)Responseb)Accuracyb)Accuracyc)Frequencyc)Frequencyd)Capacityd)Capacitye)Throughpute)Throughputf)Defect ratesf)Defect ratesg)Modifiabilityg)Modifiabilityh)Supportabilityh)Supportabilit
18、y4.软件需求的分类软件需求的分类 设计约束设计约束设计约束是真正意义上的非功能约束，它们约束系统怎设计约束是真正意义上的非功能约束，它们约束系统怎样被构建而不是系统做什么。设计约束的一般内容为样被构建而不是系统做什么。设计约束的一般内容为 解系统将在其上运行的目标机器解系统将在其上运行的目标机器 底层的体系结构底层的体系结构 -分布式的或本地的分布式的或本地的 系统运行的内存大小系统运行的内存大小 应当采用的任何前端图形用户界面应当采用的任何前端图形用户界面(GUI)(GUI)程序包程序包 系统运行的操作系统系统运行的操作系统 应当使用的编程语言应当使用的编程语言 其它应集成的软件包如数据库
19、管理系统其它应集成的软件包如数据库管理系统(DBMS)(DBMS)必须应用的开发标准必须应用的开发标准 应采用的设计方法等等应采用的设计方法等等4.软件需求的分类软件需求的分类 设计约束设计约束a)Languagea)Languageb)OSb)OSc)SW to HW interfacec)SW to HW interfaced)Algorithmd)Algorithme)Powere)Powerf)Timingf)Timingg)Memoryg)Memoryh)Processor utilizationh)Processor utilizationI)Weight etcI)Weight
20、etc4.软件需求的分类软件需求的分类 商业约束商业约束商业约束通常关注的是软件产品完成的时间以及开发商业约束通常关注的是软件产品完成的时间以及开发费用问题，是客户最为关心的问题。费用问题，是客户最为关心的问题。解系统的开发时间和费用与系统功能性、可靠性、可解系统的开发时间和费用与系统功能性、可靠性、可用性等关键需求性能有着必然与复杂的关系。是项目用性等关键需求性能有着必然与复杂的关系。是项目需求与项目管理的结合点。需求与项目管理的结合点。商业约束通常是和需求工程过程同步的，即商业约束商业约束通常是和需求工程过程同步的，即商业约束是在调查其它需求的同时获得，而且易于识别，不存是在调查其它需求的
21、同时获得，而且易于识别，不存在技术上的困惑，但却是管理上的难点。在技术上的困惑，但却是管理上的难点。商业约束如果不存在一个独立文档，则会出现在业务商业约束如果不存在一个独立文档，则会出现在业务需求描述中。需求描述中。4.软件需求的分类软件需求的分类 系统需求系统需求对于一个复杂的系统或产品，软件功能需求只对于一个复杂的系统或产品，软件功能需求只是系统需求的一个子集，需要从系统需求中剥是系统需求的一个子集，需要从系统需求中剥离出来。系统需求描述了系统中各个方面的需离出来。系统需求描述了系统中各个方面的需求，可能包含硬件、软件、其它关联系统，而求，可能包含硬件、软件、其它关联系统，而且系统的功能及
22、非功能描述并不依赖于物理层且系统的功能及非功能描述并不依赖于物理层次，如软件和硬件的划分。系统和软件需求分次，如软件和硬件的划分。系统和软件需求分析人员需要将软件需求部分独立出来。在析人员需要将软件需求部分独立出来。在CMMCMM中中这部分工作称为需求分配这部分工作称为需求分配(requirement(requirement allocation)allocation)4.软件需求的分类软件需求的分类 开发过程需求开发过程需求(Process Requirements)A requirements that specifies a need or constraint about how a
23、product well be designed,produced,delivered,or maintained;e.g.,the specification of a methodology,manufacturing process,or delivery constraint.Process requirements are distinguished from product requirements.Process requirements often appear in a Statement of Work rather than in a requirements docum
24、ent.4.软件需求的分类软件需求的分类 开发过程需求开发过程需求(Process Requirements)a)Configuurationa)Configuuration Management Management b)Deployment b)Deployment c)Development Methodsc)Development Methods d)Docummentationd)Docummentation e)Manufacturing Methodse)Manufacturing Methods f)Metricsf)Metrics g)Quality Assuranceg)Q
25、uality Assurance h)Review processesh)Review processes I)Verification Standards I)Verification Standards 5.客户客户/用户用户/开发者的需求观开发者的需求观 客户的需求观在一个比较高的层次上，为客户的需求观在一个比较高的层次上，为产品提供宏观的描述和指导性的框架，是产品提供宏观的描述和指导性的框架，是项目的基础；项目的基础；用户的需求观往往代表了产品应该完成的用户的需求观往往代表了产品应该完成的任务及其具有的特性，细节，真实性；任务及其具有的特性，细节，真实性；开发者的需求观则应是使产品最大
26、限度的开发者的需求观则应是使产品最大限度的满足需求，并最大程度的理解用户的需求。满足需求，并最大程度的理解用户的需求。6.不合格的需求派生的问题不合格的需求派生的问题 如果项目初始的需求分析不合理，会如果项目初始的需求分析不合理，会导致客户和开发人员之间的目标不一导致客户和开发人员之间的目标不一致，这意味着客户对产品的期望和目致，这意味着客户对产品的期望和目标得不到准确的理解，很可能在开发标得不到准确的理解，很可能在开发过程中或移交产品后发现产品不能符过程中或移交产品后发现产品不能符合客户实际的需求，从而导致项目的合客户实际的需求，从而导致项目的失败。失败。不适当的需求引起的一些风险不适当的需
27、求引起的一些风险1.1.无足够用户参与无足够用户参与 用户参与不多会导致产品无法被接受用户参与不多会导致产品无法被接受2.2.用户需求的不断增加用户需求的不断增加 用户需求的增加带来过度的耗费用户需求的增加带来过度的耗费和产品质量的降低和产品质量的降低3.3.模棱两可的需求说明模棱两可的需求说明 将导致时间的浪费和返工将导致时间的浪费和返工4.4.不必要的特性不必要的特性 用户增加一些不必要的特性和开发人员用户增加一些不必要的特性和开发人员画蛇添足画蛇添足5.5.过分精简的规格说明过分精简的规格说明 过分简略的需求说明以致遗漏某过分简略的需求说明以致遗漏某些关键需求些关键需求6.6.忽略用户分
28、类忽略用户分类 忽略某类用户的需求将导致众多客户的忽略某类用户的需求将导致众多客户的不满不满7.7.不准确的计划不准确的计划 不完善的需求说明使得项目计划和跟踪不完善的需求说明使得项目计划和跟踪无法准确进行无法准确进行不适当的需求引起的一些风险不适当的需求引起的一些风险1.1.无足够用户参与无足够用户参与 客户经常不明白为什么收集需求和确保客户经常不明白为什么收集需求和确保需求质量需花费那么多工夫，开发人员需求质量需花费那么多工夫，开发人员可能也不重视用户的参与。很多情况下，可能也不重视用户的参与。很多情况下，开发人员觉得已经完全明白了用户的需开发人员觉得已经完全明白了用户的需求，甚至想当然地
29、设计了一些用户并不求，甚至想当然地设计了一些用户并不认可的使用实例。尽管原因是多方面的，认可的使用实例。尽管原因是多方面的，尽早让具有代表性的用户参与是可以避尽早让具有代表性的用户参与是可以避免一定的风险的免一定的风险的不适当的需求引起的一些风险不适当的需求引起的一些风险2.2.用户需求的不断增加用户需求的不断增加 在开发过程中，若不断地补充需求，项目就会越来在开发过程中，若不断地补充需求，项目就会越来越大直到超出计划和预算范围。这是软件开发中极越大直到超出计划和预算范围。这是软件开发中极其普遍的问题，也是软件需求管理中重点涉及的问其普遍的问题，也是软件需求管理中重点涉及的问题。题。如果变更发
30、生在设计编码以后，这样的变更会使软如果变更发生在设计编码以后，这样的变更会使软件结构日渐紊乱，补丁代码使模块违背强内聚、低件结构日渐紊乱，补丁代码使模块违背强内聚、低耦合的设计原则，使程序越来越难以理解和维护。耦合的设计原则，使程序越来越难以理解和维护。要想把变更范围控制到最小，必须一开始就对项目要想把变更范围控制到最小，必须一开始就对项目视图、范围、目标、约束和成功标准给予明确说明，视图、范围、目标、约束和成功标准给予明确说明，并作为今后需求变更处理时的参考框架。并作为今后需求变更处理时的参考框架。不适当的需求引起的一些风险不适当的需求引起的一些风险3.3.模棱两可的需求说明模棱两可的需求说
31、明模棱两可，也就是需求的模棱两可，也就是需求的“二义性二义性”，是需求说明，是需求说明中最可怕的问题。中最可怕的问题。模棱两可的需求风险承担者产生不同的期望，使开模棱两可的需求风险承担者产生不同的期望，使开发人员产生错误的设计，使测试人员编写不匹配的发人员产生错误的设计，使测试人员编写不匹配的测试用例。测试用例。模棱两可的需求直接的后果就是返工。根据统计，模棱两可的需求直接的后果就是返工。根据统计，返工会耗费总开发费用的返工会耗费总开发费用的40%40%，其中，其中70%70%80%80%是由是由需求方面的错误造成的。需求方面的错误造成的。认真、高质量的需求评审可以消除大部分的模棱两认真、高质
32、量的需求评审可以消除大部分的模棱两可型的错误。可型的错误。不适当的需求引起的一些风险不适当的需求引起的一些风险4.4.不必要的特性不必要的特性“画蛇添足画蛇添足”是指开发人员力图增加一些是指开发人员力图增加一些“用户可用户可能欣赏能欣赏”，但需求规格中并未涉及的新功能；这类，但需求规格中并未涉及的新功能；这类新功能可能很花哨但用户并不认为很有用，但实现新功能可能很花哨但用户并不认为很有用，但实现却耗费可观。相反的情况也存在，即客户会提出这却耗费可观。相反的情况也存在，即客户会提出这些花哨的但缺乏实用价值的需求，需求分析人员应些花哨的但缺乏实用价值的需求，需求分析人员应做的是去说服客户避免将资源
33、浪费在这些无关紧要做的是去说服客户避免将资源浪费在这些无关紧要的功能上。的功能上。与此相关的做法是，在可能的情况下，为客户提供与此相关的做法是，在可能的情况下，为客户提供新的解决方案，在允许的资源和技术可行性之间求新的解决方案，在允许的资源和技术可行性之间求得平衡。得平衡。不适当的需求引起的一些风险不适当的需求引起的一些风险5.5.过分精简的规格说明过分精简的规格说明 有时客户并不明白需求分析如此重要，于是只作一有时客户并不明白需求分析如此重要，于是只作一份简略之至的规格说明。仅涉及产品的某些概念，份简略之至的规格说明。仅涉及产品的某些概念，其它让开发人员在项目进展中去完善，结果是为了其它让开
34、发人员在项目进展中去完善，结果是为了管理上的某种要求，开发人员先建立产品结构、甚管理上的某种要求，开发人员先建立产品结构、甚至是完成编码，然后再补充需求说明。大多数情况至是完成编码，然后再补充需求说明。大多数情况下，这会增加开发过程的迂回、返工。下，这会增加开发过程的迂回、返工。不适当的需求引起的一些风险不适当的需求引起的一些风险6.6.忽略用户分类忽略用户分类 多数产品是由不同的人使用不同的特性，使用频繁多数产品是由不同的人使用不同的特性，使用频繁程度、受教育程度、经验水平也不相同。如果产品程度、受教育程度、经验水平也不相同。如果产品功能设计不能满足某些关键用户需求，会大大影响功能设计不能满
35、足某些关键用户需求，会大大影响产品的用户接受度。产品的用户接受度。不适当的需求引起的一些风险不适当的需求引起的一些风险7.7.不准确的计划不准确的计划 需求分析不充分和缺乏理解会导致计划的乐观估计；需求分析不充分和缺乏理解会导致计划的乐观估计；导致需求过程中软件成本估计极不准确的主要原因导致需求过程中软件成本估计极不准确的主要原因为：为：a)a)频繁的需求变更；频繁的需求变更；b)b)遗漏的需求；遗漏的需求；c)c)与用户交流不够；与用户交流不够；d)d)质量低下的需求规格说明；质量低下的需求规格说明；e)e)不完善的需求分析。不完善的需求分析。7.高质量的需求带来的好处高质量的需求带来的好处
36、 实行有效的需求工程管理的组织能获实行有效的需求工程管理的组织能获得多方面的好处。最大的好处是在开得多方面的好处。最大的好处是在开发后期和整个维护阶段重做的工作大发后期和整个维护阶段重做的工作大大减少了。这使得整个开发过程少走大减少了。这使得整个开发过程少走了许多弯路，并在开始阶段就为整个了许多弯路，并在开始阶段就为整个产品开发过程指明了方向。产品开发过程指明了方向。8.优秀需求所具有的特征优秀需求所具有的特征1.1.完整性完整性(Complete)(Complete)2.2.正确性正确性(Correct)(Correct)3.3.可行性可行性(Feasible)(Feasible)4.4.必
37、要性必要性(Necessary)(Necessary)5.5.与实现无关性与实现无关性(Implementation Independent)(Implementation Independent)6.6.划分优先级划分优先级 (Prioritized,Future and(Prioritized,Future and trade-offs)trade-offs)7.7.无二义性无二义性(Unique)(Unique)8.8.可验证性可验证性(Verifiable)(Verifiable)9.9.正确的详细层次正确的详细层次(Right level of details)(Right leve
38、l of details)8.优秀需求所具有的特征优秀需求所具有的特征 完整性完整性(Complete)(Complete)每一项需求都必须将所要实现的功能描每一项需求都必须将所要实现的功能描述清楚述清楚,以使开发人员获得设计和实现以使开发人员获得设计和实现这些功能所需的所有必要信息。这些功能所需的所有必要信息。正确性正确性(Correctness)(Correctness)每一项需求都必须准确地陈述所要开发的每一项需求都必须准确地陈述所要开发的功能。其判别标准是是否符合需求的来源，功能。其判别标准是是否符合需求的来源，如用户需求和系统需求。其检验标准就是如用户需求和系统需求。其检验标准就是通
39、过用例和场景分析验证是否满足用户或通过用例和场景分析验证是否满足用户或客户的真实需要。客户的真实需要。8.优秀需求所具有的特征优秀需求所具有的特征 可行性可行性(Feasible)(Feasible)每一项需求都必须在已知系统和环境的技每一项需求都必须在已知系统和环境的技术、资源等限制范围内是可以实施的。做术、资源等限制范围内是可以实施的。做到这一点，需要多方人员参与检查其可行到这一点，需要多方人员参与检查其可行性，这些人员包括：开发软件工程师，系性，这些人员包括：开发软件工程师，系统工程师，市场人员等。统工程师，市场人员等。必要性必要性(Necessary)(Necessary)每一项需求都
40、必须和某项真正用户需求，每一项需求都必须和某项真正用户需求，如使用实例或某项高层系统需求，相关如使用实例或某项高层系统需求，相关联。联。It specifies what must be done and only what must be done8.优秀需求所具有的特征优秀需求所具有的特征 与实现无关性与实现无关性需求关注的是系统将要做些什么，其后的需求关注的是系统将要做些什么，其后的阶段如设计，关注该系统将怎样来实现。阶段如设计，关注该系统将怎样来实现。如果一项需求与实现密切相关，这会限制如果一项需求与实现密切相关，这会限制设计人员优化、合理设计系统的自由度。设计人员优化、合理设计系统的
41、自由度。划分优先级划分优先级给每项需求分配一个可实施的优先级以指给每项需求分配一个可实施的优先级以指明其在产品中的重要程度。如果所有的需明其在产品中的重要程度。如果所有的需求都同等重要，项目管理者在节省预算或求都同等重要，项目管理者在节省预算或调度中就会无从选择。调度中就会无从选择。8.优秀需求所具有的特征优秀需求所具有的特征 无二义性无二义性(Unique(Unique，Unambiguous)Unambiguous)每项需求对所有相关的读者只能有一个明确统每项需求对所有相关的读者只能有一个明确统一的解释。由于自然语言极易导致二义性，应一的解释。由于自然语言极易导致二义性，应尽量把每项需求用
42、简明的用户语言表达出来。尽量把每项需求用简明的用户语言表达出来。避免二义性的有效方法包括对需求文档的正规避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型等。审查，编写测试用例，开发原型等。可验证性可验证性(Verifiable)(Verifiable)每项需求都应能够被人或机器加以验证，否则每项需求都应能够被人或机器加以验证，否则将无法确定该项需求是否实现正确。验证方法将无法确定该项需求是否实现正确。验证方法主要为测试用例，场景符合性分析，正规审查，主要为测试用例，场景符合性分析，正规审查，原型演示。原型演示。8.优秀需求所具有的特征优秀需求所具有的特征 正确的详细层次正确
43、的详细层次(Right level of(Right level of detail)detail)每项需求或者一组需求都应包含相应的层每项需求或者一组需求都应包含相应的层面信息，以便据此足以导出下一层产品需面信息，以便据此足以导出下一层产品需求或设计，但不应提供对下一层活动如设求或设计，但不应提供对下一层活动如设计不必要的限制计不必要的限制优秀需求具有的特性优秀需求具有的特性 需求规格说明的特征需求规格说明的特征1.1.完整性完整性(Complete)(Complete)2.2.一致性一致性(Consistent)(Consistent)3.3.简洁明了简洁明了(Concise)(Conci
44、se)4.4.可修改性可修改性(Modifiable)(Modifiable)5.5.可跟踪性可跟踪性(Traceable)(Traceable)优秀需求规格说明的特性优秀需求规格说明的特性 完整性完整性(Complete)(Complete)需求规格说明完整性是指不能需求规格说明完整性是指不能遗漏任何必要的信息，这里不遗漏任何必要的信息，这里不仅仅指需求本身，还包括相关仅仅指需求本身，还包括相关的参考信息，如基于的国际标的参考信息，如基于的国际标准，高层需求信息等。准，高层需求信息等。优秀需求规格说明的特性优秀需求规格说明的特性 一致性一致性(Consistent)(Consistent)需
45、求规格说明一致性是指软件需求规格说明一致性是指软件需求不能与其它需求如系统需需求不能与其它需求如系统需求、业务需求相矛盾。正规的求、业务需求相矛盾。正规的文档审查和基于实例和场景分文档审查和基于实例和场景分析的验证是保证一致性的通用析的验证是保证一致性的通用做法。做法。Internally consistentInternally consistent Externally consistentExternally consistent优秀需求规格说明的特性优秀需求规格说明的特性 简洁明了简洁明了(Concise)(Concise)每一需求都应清晰地对应某一每一需求都应清晰地对应某一系统功能或
46、用户需要，它能够系统功能或用户需要，它能够容易地被所有风险承担者阅读容易地被所有风险承担者阅读和理解并能够容易地映射到某和理解并能够容易地映射到某一使用实例或场景。一使用实例或场景。优秀需求具有的特性优秀需求具有的特性Original:All satelite images in the database shall be made available at the workstation upon request in those presentations defined in 8.8(15 pages long)Improved:All satelite images in the da
47、tabase shall be made available at the workstation upon request in those presentations defined in 8.8.6(contain 2 pages instruction)优秀需求规格说明的特性优秀需求规格说明的特性 可修改性可修改性(Modifiable)(Modifiable)涉及同类主题的需求应该有组织地放在一起。涉及同类主题的需求应该有组织地放在一起。为维护每一需求变更历史纪录时，应该修订为维护每一需求变更历史纪录时，应该修订SRSSRS。这就要求每项需求要独立标出，并与别的需这就要求每项需求要独
48、立标出，并与别的需求区别开来，从而无二义性。求区别开来，从而无二义性。每项需求只应在每项需求只应在SRSSRS中出现一次。这样更改中出现一次。这样更改时易于保持一致性。时易于保持一致性。另外，使用目录表、索引和相互参照列表方另外，使用目录表、索引和相互参照列表方法将使软件需求说明更容易修改，并在修改法将使软件需求说明更容易修改，并在修改时能自动保持一致时能自动保持一致优秀需求规格说明的特性优秀需求规格说明的特性 可跟踪性可跟踪性(Traceable)(Traceable)应能在每项软件需求与它的根源和设计应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起连元素、源代码、测试用例之间建立起连接链，这种可跟踪性要求每项需求以一接链，这种可跟踪性要求每项需求以一种结构化的、粒度好（种结构化的、粒度好（fine-grainedfine-grained）的方式编写并单独表明，而不是大段大的方式编写并单独表明，而不是大段大段的叙述。段的叙述。Q&？
