软件需求工程

软件需求工程周立新博士北京大学软件与微电子学院课程提纲1.软件需求基本理论和概念2.软件需求工程过程3.软件需求获取4.软件需求分析5.软件需求规格说明6.软件需求验证7.软件需求管理8.软件需求实现9.软件需求工程新进展10.软件需求开发与需求管理工具课程参考书1.KarlE.Wiegers著,陆丽娜，王忠民，王志敏等译，软件需求，机械工业出版社，20002.IanK.Bray著，需求工程导引，人民邮电出版社，20033.GeriSchneiderandJasonP.Winters著,姚淑珍，李巍等译，用例分析技术，机械工业出版社，20024.DeanLeffingwellandDonWidrig著,蒋慧，林东译，软件需求管理：统一方法，机械工业出版社，20025.RalphR.Young著,韩柯，耿民等译，有效需求实践，机械工业出版社，20026.以上参考书相对应的英文版本7.RUP第一章软件需求基本理论和概念1.软件需求定义2.需求工程的本质3.问题域与解系统4.软件需求分类1.功能需求2.性能需求(非功能需求)3.设计约束4.商业约束5.客户/用户/开发者的需求观6.不合格的需求派生的问题7.高质量的需求带来的好处8.优秀需求所具有的特征项目失败的原因分析No.Top10Factors平均值1Inadequaterequirementsspecification不充分的需求规范4.52Changesinrequirements需求的改变4.33Shortageofsystemsengineers缺乏系统工程师4.24Shortageofsoftwaremanagers缺乏了解软件特性的经理人4.15Shortageofqualifiedprojectmanagers缺乏合格的项目经理4.16Shortageofsoftwareengineers缺乏软件工程师3.97Fixed-pricecontract固定价合同3.88Inadequatecommunicationsforsystemintegration系统集成阶段,交流与沟通不充分3.89Insufficientexperienceasteam团队缺乏经验3.610Shortageofapplicationdomainexperts缺乏应用领域专家3.6Scale:5=VerySerious3=Serious1=NoSeriousSource:Carnegie-MellonUniversity,SoftwareEngineeringInstitute错误认识•Ageneralstatementofobjectivesissufficienttobeginwritingprograms—wecanfillinthedetailslater需求不清楚就进入编程阶段，期望以后修改。更多的情况下是边写边修改•Projectrequirementscontinuallychange,butchangecanbeeasilyaccommodatedbecausesoftwareisflexible软件调节和改变是很灵活的，任何需求的变更都可容易地在软件中反映出来这些认识多来自极小项目的开发经验，当你面对一个中大型项目时必须彻底改变这些错误观念！1.软件需求的定义•IEEE软件工程中需求的定义(1977)1.用户解决问题或达到目标所需的条件和能力2.系统或系统部件为满足合同、标准、规范或其它正式规定文档所需具有的条件和能力3.以上条件和能力的文档说明•客户希望在问题域内产生的效果–需求与问题域的差别•Sommerville&Sawyer1997–需求是指系统必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束2.需求工程的本质•需求工程简单化描述为她关注系统将要做什么；而设计关注系统将怎样做•需求工程可以看作把一个定义不足的问题转换为一个定义充分的问题以便找出解决方案。这是因为客户需求信息经常是粗糙的和不完整的•需求工程的通用性、理论性和实践性，怎样理解其学科性质，如何学习才能掌握它的本质？有一劳永逸的方法和工具吗？能否将另一个成功项目的需求工程方法照搬到现在的项目–答案是不能！3.问题域(ProblemDomain)与解系统(SolutionSystem)•问题域：被开发系统的应用领域，即在现实世界中由这个系统进行处理的业务范围•解系统：指可以在问题域内产生某种效果的系统，而构成软件需求的正是这些想要获得的效果，它也正是为何做软件需求的原因和目的问题域ProblemDomain问题域接口解系统分析规格说明设计问题域的类型•分类I1.系统软件2.应用软件，进一步划分为商业软件和工程软件•分类II1.批处理系统/系统脱机2.交互系统3.实时系统•分类III1.数据为主的系统2.交互为主的系统3.算法为主的系统问题域的类型数据为主交互为主算法为主A.气象预报系统B.收银机系统C.电梯控制系统D.工资系统E.文字处理系统F.文件转换系统G.手机定位系统ABCDEFG需求的层次业务需求项目视图与范围文档用户需求质量属性使用实例文档系统需求功能需求其它非功能需求约束条件软件需求规格说明SRS4.软件需求的分类①业务需求业务需求(businessrequirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图和范围文档中予以说明例如某运营商对定位系统的业务需求4.软件需求的分类②用户需求用户需求(userrequirement)描述了用户使用产品必须要完成的任务，它们在使用实例(usecase)和情景描述(scenario)文档中予以说明4.软件需求的分类③功能需求“一般”意义的需求指的是功能或行为需求，这样的需求通常是和解系统的适当行为(用户需求)相关联，是开发人员必须实现的软件功能。功能需求可以在多种不同的抽象层次上来表达，这使得导出需求过程比较复杂和困难：a)Physicalbehaviorb)Input-outputrelationshipc)Observablestatesd)Userinterface4.软件需求的分类④非功能需求非功能需求是功能需求的补充，它描述了系统完成功能实现的补充和约束条件。如产品必须遵从的标准、国际规范和合约；外部界面的规范；性能需求如：系统运行速度(Speed)，可靠性(Reliability)，容量(Capacity)，可用性(Availability),可使用性(Usability)；其它质量属性如：快捷性、简易性、直觉性、健壮性等。在具体操作时，关于可靠性和可用性的规范最为困难，但又是客户最为关心的4.软件需求的分类④非功能需求a)Responseb)Accuracyc)Frequencyd)Capacitye)Throughputf)Defectratesg)Modifiabilityh)Supportability4.软件需求的分类⑤设计约束设计约束是真正意义上的非功能约束，它们约束系统怎样被构建而不是系统做什么。设计约束的一般内容为–解系统将在其上运行的目标机器–底层的体系结构-分布式的或本地的–系统运行的内存大小–应当采用的任何前端图形用户界面(GUI)程序包–系统运行的操作系统–应当使用的编程语言–其它应集成的软件包如数据库管理系统(DBMS)–必须应用的开发标准–应采用的设计方法等等4.软件需求的分类⑤设计约束a)Languageb)OSc)SWtoHWinterfaced)Algorithme)Powerf)Timingg)Memoryh)ProcessorutilizationI)Weightetc4.软件需求的分类⑥商业约束商业约束通常关注的是软件产品完成的时间以及开发费用问题，是客户最为关心的问题。解系统的开发时间和费用与系统功能性、可靠性、可用性等关键需求性能有着必然与复杂的关系。是项目需求与项目管理的结合点。商业约束通常是和需求工程过程同步的，即商业约束是在调查其它需求的同时获得，而且易于识别，不存在技术上的困惑，但却是管理上的难点。商业约束如果不存在一个独立文档，则会出现在业务需求描述中。4.软件需求的分类⑦系统需求对于一个复杂的系统或产品，软件功能需求只是系统需求的一个子集，需要从系统需求中剥离出来。系统需求描述了系统中各个方面的需求，可能包含硬件、软件、其它关联系统，而且系统的功能及非功能描述并不依赖于物理层次，如软件和硬件的划分。系统和软件需求分析人员需要将软件需求部分独立出来。在CMM中这部分工作称为需求分配(requirementallocation)4.软件需求的分类⑧开发过程需求(ProcessRequirements)Arequirementsthatspecifiesaneedorconstraintabouthowaproductwellbedesigned,produced,delivered,ormaintained;e.g.,thespecificationofamethodology,manufacturingprocess,ordeliveryconstraint.Processrequirementsaredistinguishedfromproductrequirements.ProcessrequirementsoftenappearinaStatementofWorkratherthaninarequirementsdocument.4.软件需求的分类⑧开发过程需求(ProcessRequirements)a)ConfiguurationManagementb)Deploymentc)DevelopmentMethodsd)Docummentatione)ManufacturingMethodsf)Metricsg)QualityAssuranceh)ReviewprocessesI)VerificationStandards5.客户/用户/开发者的需求观•客户的需求观在一个比较高的层次上，为产品提供宏观的描述和指导性的框架，是项目的基础；•用户的需求观往往代表了产品应该完成的任务及其具有的特性，细节，真实性；•开发者的需求观则应是使产品最大限度的满足需求，并最大程度的理解用户的需求。6.不合格的需求派生的问题•如果项目初始的需求分析不合理，会导致客户和开发人员之间的目标不一致，这意味着客户对产品的期望和目标得不到准确的理解，很可能在开发过程中或移交产品后发现产品不能符合客户实际的需求，从而导致项目的失败。不适当的需求引起的一些风险1.无足够用户参与–用户参与不多会导致产品无法被接受2.用户需求的不断增加–用户需求的增加带来过度的耗费和产品质量的降低3.模棱两可的需求说明–将导致时间的浪费和返工4.不必要的特性–用户增加一些不必要的特性和开发人员画蛇添足5.过分精简的规格说明–过分简略的需求说明以致遗漏某些关键需求6.忽略用户分类–忽略某类用户的需求将导致众多客户的不满7.不准确的计划–不完善的需求说明使得项目计划和跟踪无法准确进行不适当的需求引起的一些风险1.无足够用户参与客户经常不明白为什么收集需求和确保需求质量需花费那么多工夫，开发人员可能也不重视用户的参与。很多情况下，开发人员觉得已经完全明白了用户的需求，甚至想当然地设计了一些用户并不认可的使用实例。尽管原因是多方面的，尽早让具有代表性的用户参与是可以避免一定的风险的不适当的需求引起的一些风险2.用户需求的不断增加在开发过程中，若不断地补充需求，项目就会越来越大直到超出计划和预算范围。这是软件开发中极其普遍的问题，也是软件需求管理中重点涉及的问题。如果变更发生在设计编码以后，这样的变更会使软件结构日渐紊乱，补丁代码使模块违背强内聚、低耦合的设计原则，使程序越来越难以理解和维护。要想把变更范围控制到最小，必须一开始就对项目视图、范围、目标、约束和成功标准给予明确说明，并作为今后需求变更处理时的参考框架。不适当的需求引起的一些风险3.模棱两可的需求