软件工程课件：08-Req

1、The Nightmare“Its your worst nightmare. A customer walks into your office, sit down, looks you straight in the eyes, and says, “I know you think you understand what I said, but what you dont understand is what I said is not what I mean.” Invariably, this happens late in the project, after the deadli

2、ne commitments have been made, reputation are on the line, and serious money is at stake.All of us who have worked in the systems and software business for more than a few years have lived this nightmare, and yet, few of us have learned to make it go away. ”- R. Young, Effective Requirements Practic

3、es, Addison-Wesley, 2001 1“The Hardest single part of building a software system is deciding what to build. No part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”- Fred Brooks2Outline3Why requirements engineering is criticalThe basic co

4、ncepts Uniform Modeling Language (UML)Behavior-driven analysis SummarySolutionDomainSRSUserProblemDomainAnalystDeveloperWhy Requirements EngineeringRequirements engineering builds a bridge to design and construction.SRS: Software Requirements Specification4Why software fails?1. Incomplete Requiremen

5、ts13.1%2. Lack of User Involvement12.4%3. Lack of Resources10.6%4. Unrealistic Expectations9.9%5. Lack of Executive Support9.3%6. Changing Requirements & Specifications8.7%7. Lack of Planning8.1%8. Didnt Need It Any Longer7.5%9. Lack of IT Management6.2%10. Technology Illiteracy4.3%11. Others9.9%Sou

6、rce: Standish Group 1995，350个公司，8000个项目5“The seeds of major software disasters are usually sown in the first three months of commencing the software project.”Capers JonesWhere Are the Defects Come from?Jones & Thayer, 1981,30-35 KLOC , 35% from design activities 40-80 KLOC, 10% from requirements, 55

7、% from design 65-86 KLOC, 8-10% from requirements, 40-50% from design Boehm, 1984Middle-size, 48% from requirementsComputer Weekly Report, 199444.1% from requirement6The Cost of Requirements Defects“ Requirements are major source of expensive bugs. The range is from a few percent to more than 50%, d

8、epending on application and environment. What hurts most about these bugs is that theyre the earliest to invade the system and the last to leave. Its not unusual for a faulty requirement to get through all development testing, beta testing, and initial field use, only to be caught after hundreds of

9、sites have been installed.” Beizer, 19907The Cost of Requirements Defects8Phase to Remove DefectsRelative CostRequirements0.1 0.2Design0.5Coding1Unit Testing2System Testing5Maintenance20A Brief Summary: The FactsDefects start from software requirementsSoftware requirements defects are the most expen

10、siveSoftware requirements defects can be detected and removed in the early stage of software development. 9Defects%Misunderstanding49Negligence 31Inconsistency13Ambiguity 5Disorganization2Method%Walkthrough65Unit Testing10Integration Testing5Evolution6Others14Requirements EngineeringRequirementsThe

11、features that the system must have or a constraint that it must satisfy to be accepted by the client a model of the system that aims to be correct, complete, consistent, and verifiable. Requirements EngineeringThe acquisition, analysis, specification, validation, and management of software requireme

12、nts10Layers of Software RequirementsBusiness requirementsThe business needs and value of the software system.User requirementsStatements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.System requirementsA structured docume

13、nt setting out detailed descriptions of the system services. Written as a contract between client and contractor.Software specificationA detailed software description which can serve as a basis for a design or implementation. Written for developers.11Functional / Non-Functional RequirementsFunctiona

14、l requirementsStatements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.Non-functional requirementsconstraints on the services or functions offered by the system such as timing constraints, constraints

15、 on the development process, standards, etc.Domain requirementsRequirements that come from the application domain of the system and that reflect characteristics of that domain12Biz needsPrj. SpecUser needsUsageSpecFun. Req.Non-Fun. Req.ConstraintsSRS13e-Government SystemBusiness RequirementsNewsWork

16、flowDocumentEmailUserRequirements1.User management 1.1 user registration 1.2 user login 1.3 authorization 1.4 2.Email management 2.1 account management 2.2 inbox 2.3 .Performance Response time Concurrent users Reliability MTBF ScalabilityFunctionalNon-functionalRequirements14From Requirement Definit

17、ion to SpecificationUsers needs The software must provide a means of representing and accessing external files created by other tools. Specification:151.1 The user should be provided with facilities to define the type of external files.1.2 Each external file type may have an associated tool which ma

18、y be applied to the file.1.3 Each external file type may be represented as a specific icon on the users display.1.4 Facilities should be provided for the icon representing an external file type to be defined by the user. 1.5 When a user selects an icon representing an external file, the effect of th

19、at selection is to apply the tool associated with the type of the external file to the file represented by the selected icon. Functional RequirementsDescribe functionality or system servicesDepend on the type of software, expected users and the type of system where the software is usedFunctional use

20、r requirements may be high-level statements of what the system should do but functional system requirements should describe the system services in detail16Examples of Functional RequirementsThe user shall be able to search either all of the initial set of databases or select a subset from it.The sys

21、tem shall provide appropriate viewers for the user to read documents in the document store. Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the accounts permanent storage area.17Non-functional requirementsDefine system properties and constraints

22、e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc.Process requirements may also be specified mandating a particular CASE system, programming language or development methodNon-functional requirements may be more critical than

23、functional requirements. If these are not met, the system is useless18Non-functional classificationsProduct requirementsRequirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.Organisational requirementsRequirements which are a con

24、sequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.External requirementsRequirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.1

25、9Non-Functional Requirement Types20Non-Functional Requirements ExamplesProduct requirement4.C.8 It shall be possible for all necessary communication between the APSE and the user to be expressed in the standard Ada character setOrganisational requirement9.3.2 The system development process and deliv

26、erable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95External requirement7.6.5 The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system21Measurement of Non-Functional Requirem

27、entsAttributeMeasureSpeedTransactions / sectResponse time for each transactionRefresh frequencySizeMemoryUsabilityTime to Training The detail of the helperReliabilityMean time to failureRobustnessMean time to recoveryDamage seriousnessPortabilityThe percentage of platform-dependent programThe number

28、 of different platforms can be adapted to22Requirements Engineering ProcessFeasibilityStudyRequirementsElicitation &AnalysisRequirementSpecification RequirementValidation FeasibilityReportSystemModelsSRSRequirements Management23Requirements Analysis ModelingThe intent of analysis model is to provide

29、 a description of the required information, functional, and behavioral domains for a computer-based system. To evaluate the systems components in relationship to one another.To determine how requirements fit into this picture, and to assess the “aesthetics” of the system as it has been conceived. 24

30、Requirements SpecificationThe final work product produced by the requirements engineer. Describe the function and performance of a computer-based system and the constraints that will govern its development. The foundation for subsequent software engineering activities. The contract between the devel

31、oper and the customers on what the application will do. The formality and format of a specification varies with the side and the complexity of the software to be built. Methods of defining an SRS are described by the IEEE specification 830-1998. 25Problems with Natural Language SpecificationsAmbigui

32、ty The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguousOver-flexibilityThe same thing may be said in a number of different ways in the specificationLack of modularizationNL structures are inadequate to structure system requirements. 26Al

33、ternatives to NL SpecificationStructured natural languageStandard forms or templates to express the requirements specificationDesign description languagesSimilar to programming language but with more abstract featuresGraphical notationsGraphical language supplemented by text annotationsMathematical

34、specificationsBased on mathematical concepts such as FSM. 2728Example Z SpecificationRequirements ValidationRequirements validation examines the specification to ensure thatAll software requirements have been stated unambiguouslyInconsistencies, omissions, and errors have been detected and corrected

35、The work products conform to the standards established for the process, the project, and the product. 29Domain Requirements ProblemsUnderstandability Requirements are expressed in the language of the application domain, hard to be understood by software engineers developing the systemImplicitnessDom

36、ain specialists understand the area so well that they do not think of making the domain requirements explicit. 30Requirements Completeness and ConsistencyIn principle, requirements should be both complete and consistentCompleteThey should include descriptions of all facilities required.ConsistentThe

37、re should be no conflicts or contradictions in the descriptions of the system facilities. In practice, it is impossible to produce a complete and consistent requirements document.31Requirements ImprecisionProblems arise when requirements are not precisely statedAmbiguous requirements may be interpre

38、ted in different ways by developers and usersE.g. “Appropriate viewers”The user: people with specific knowledgeThe developer: a text viewer software tool32Requirements ValidationRequirement reviewA manual process to check the requirements document for anomalies and omissions.A formal review: the rev

39、iew team should check each requirement for consistency and check the requirements as a whole for completenessVerifiabilityComprehensibilityTraceabilityAdaptabilityConflicts, contradictions, errors and omissions should be pointed out33“发现任何不友好并且带有未知任务的或者有可能在5分钟之内飞入空中禁区的飞行物时要拉响警报”某自动售货机系统的功能需求说明管理功能：增

40、添商品设置各种商品的价格（以0.5元为单位）查询各种产品在各段时间内的销售情况和需求情况（产品已售完，但用户还有需要）取走钱币撤走架上的某种商品，改为其他种类商品管理界面美观需求案例一 :需求案例二 :Completeness and Consistency (C&C)(完整性/一致性)34Requirements ManagementRequirements traceabilityTraceability is concerned with the relationships between requirements, their sources and the system design

41、Source traceabilityLinks from requirements to stakeholders who proposed these requirementsRequirements traceabilityLinks between dependent requirementsDesign traceabilityLinks from the requirements to the design35Requirements ManagementRequirement changesThe priority of requirements from different v

42、iewpoints changes during the development processSystem customers may specify requirements from a business perspective that conflict with end-user requirementsThe business and technical environment of the system changes during its developmentChange Management36Requirements ManagementChange prediction and identificationEnduring