2. 1 Requirements Engineering Southern Methodist University CSE 7316

3. 2 The Requirements Problem

4. 3 Agenda  Definitions and general concepts  Process and product  Product properties  Requirements management  The problem domain

5. 4 What is a requirement?  A software capability needed by the user to solve a problem to achieve an objective  A software capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documentation

6. 5 (IEEE83), ANSI/IEEE Std 729/1983 Definition of Requirement  A condition or capability needed by a user to solve a problem or achieve an objective.  A condition or capability that must be met or possessed by a system or a system component to satisfy a contract, standard, specification, or other formally imposed document. The set of all requirements forms the basis for subsequent development of the system or component.

7. 6 Davis90 Requirements Analysis is Important  Five Hypotheses:  The later in the lifecycle an error is found, the more expensive it is to fix.  Many errors are not found until well after they are made.  Many requirements errors are being made.  Requirements errors are typically incorrect facts, omissions, inconsistencies, and ambiguities.  Requirements errors can be detected

8. 7 ANSI/IEEE Std729/1983 Requirements Analysis Definition  The process of studying user needs to arrive at a definition of system or software requirements.  The verification of system / software requirements.

9. 8 Requirements Analysis Definition  An Iterative process of:  Identifying  Analyzing  Documenting  Verifying  (etc.) Definition of required system behavior

10. 9 Requirements Analysis Task Software Requirements Document Conceptual Model derive understandable modifiable precise build “outside-in”  begin with environment  work inward to the system

11. 10 Environment and System Environment System state of entities in environment state of system activities events

12. 11 Process and Artifacts Context Analysis Design Process Developer- Oriented Software Requirements Artifact Customer Requirements Process Developer Requirements Process Customer- Oriented Software Requirements Artifact Brackett89, CE-SPM-01-02-06 Software Needs Artifact

13. 12 Context Analysis Design Process Developer- Oriented Software Requirements Artifact Customer Requirements Process Developer Requirements Process Customer- Oriented Software Requirements Artifact Brackett89, CE-SPM-01-02-06 Software Needs Artifact Market Needs User Needs Document System Requirements Specification Statement of Operational Need (SON) System Operational Requirements Document (SORD) Concept of Operations Process and Artifacts

14. 13 Context Analysis Design Process Developer- Oriented Software Requirements Artifact Customer Requirements Process Developer Requirements Process Customer- Oriented Software Requirements Artifact Brackett89, CE-SPM-01-02-06 Software Needs Artifact Requirements Requirements Definition Requirements Document Requirements Specification Use Case Model Functional Description Part 1 specification. Process and Artifacts

15. 14 Context Analysis Design Process Developer- Oriented Software Requirements Artifact Customer Requirements Process Developer Requirements Process Customer- Oriented Software Requirements Artifact Brackett89, CE-SPM-01-02-06 Software Needs Artifact Behavioral Specification System Specification Specification Document Requirements Specification Functional Specification Functional Description Process and Artifacts

16. 15 Goals  Process goal  keep the process under our intellectual control at all times  Artifact goal  organize the artifact so that it allows others to comprehend the product to be built  amount of effort should be proportional to the size of the product -- not worse!

17. 16 Weinberg89 An Effective Artifact is the Primary Goal  COMMUNICATION  Agreement between developer & customer  A basis for design  A basis for V&V

18. 17 Artifact Purposes  The artifact(s) answer these questions  What problem is the system supposed to solve?  What does the customer require from the system?  What does the developer need to know about the system to design it?  The artifact(s) of the requirements analysis process are specifications that the software designer can use

19. 18 Documentation vs. Specifications  "Documents" are all of the materials produced during requirements analysis, e.g. backs of envelopes, data dictionaries, prototypes, etc.  “Specifications” are formal documents that are "contractually" binding in some manner, such as:  Basis for acceptance tests  Basis for payment  etc.

20. 19 Properties of a "Good" Requirements Specification  Unambiguous  Complete  Correct  Prioritized  Verifiable  Sufficient for design  Consistent  Modifiable  Traceable  Traced  Useable during operations & maintenance

21. 20 Unambiguous  Mathematically precise  A matter of agreement  A “contract” between the customer and the developer... ST st : Symbol -|-> Type defined = dom st

22. 21 Verifiable  Customer and developer must agree on the criteria and on the method for verification.  testing  inspection  etc.  Every requirement must have verification criteria — or... it isn’t a requirement...

23. 22 Context Analysis Design Document 1. 2. 3. Requirements Document Test Plans 4. Traceable  1. Backward to context analysis  2. Forward to design  3. Within the document  4. To test/verification plans

24. 23 Requirements Management  Requirements Management is one of the 6 KPAs needed to go to level 2 (Repeatable) of the CMM.  Requirements are set at the beginning and not changed during the build -- when they change, the current build stops and a new cycle starts.

25. 24 Key Considerations of Requirements Management  Identify functional requirements (e.g. draft user’s manual)  Identify system needs  Identify customer expectations -- delivery, packaging, and support  Identify measures of success -- cost, schedule, and performance  Identify validation & acceptance criteria  Identify support requirements

26. 25 Managing the Process  Estimation -- how can one estimate the scope of the requirements definition effort early?  Effort depends on  size/scope of project  breadth of sources  duration of effort  Two common errors  too much effort (over-specification)  too little effort (under-specification)

27. 26 Humphrey89 Why Requirements Management?  Sometimes we get firm requirements, but the law of software perversity states: “The firmer the requirements; the more likely they are wrong.”  Requirements change as the job progresses  writing the program changes our perception of the task  computer implementation of a human task changes the task itself

28. 27 Humphrey89 Why Requirements Management? (cont’d)  In large-scale programs, the task of writing a complete statement of requirements is not just difficult – it is practically impossible.  customer doesn’t know what is needed   statement of requirements is wrong   statement of requirements will change  Recommendation: establish a link to someone who knows the application and work together until the job is done.

29. 28 Humphrey89 Practical Solution  Incremental development process  gradually increase level of detail as the requirements and implementation are mutually refined  Start with the minimal requirements that both we and the user “know” are valid...  implement  test  use in trial form  plan & develop next increment

30. 29 The requirements problem  Customers  External entity; buy ours instead of theirs!!  Company that has hired us to develop high quality s/w that will give them a competitive advantage  Tools vendor  Defense business  Our company! Something that will make us better!

31. 30 Some Data (Standish)  $250 billion spent on IT for 175,000 projects  $2,322,000 for large company  $1,331,000 for medium company  $434,000 for small company  31% of projects canceled before completion  52.7% will cost an average of 181% of original estimate

32. 31 10% 30% 50% Requirements Definition Software Design CodingTestingDeployment $ 5 $ 10 Req’ts Definition Software Design CodingTestingDeployment Source of Errors - %'s Communications of the ACM, Jan. '84 Relative Cost to Correct Errors - $1000's Source: AT&T Bell Labs Estimates Errors You are here.

33. 32 Root causes of “challenged” projects  Lack of user input (13% of all projects)  Incomplete requirements and specifications (12% of projects)  Changing requirements and specifications (12% of projects)  Inadequate technology skills (7%)  …..

34. 33 Primary success factors  User involvement (16% of all successful projects)  Executive management support (14%)  Clear statement of requirements (12%)  Two largest problems cited in other surveys  Requirements specifications  Managing customer requirements

35. 34 Defect Summary Defect originsDefect potential Removal efficiency Delivered defects Requirements1.0077%0.23 Design1.2585%0.19 Coding1.7595%0.09 Documentation0.6080%0.12 Bad fixes0.4070%0.12 Total5.0085%0.75

36. 35 Defect Summary Defect originsDefect potential Removal efficiency Delivered defects Requirements1.0077%0.23 Design1.2585%0.19 Coding1.7595%0.09 Documentation0.6080%0.12 Bad fixes0.4070%0.12 Total5.0085%0.75

37. 36 Relative cost to repair.1-.2.5 1 2 5 20 Stage Requirements Design Coding Unit test Acceptance test Maintenance

38. 37 Fixing a defect  Re-specification  Redesign  Recoding  Retesting  Change orders; telling users and operators to replace  Corrective action; refund checks to angry customers, rerunning a computer job  Scrap; code, design, test cases  Recall of defective versions of shrink wrap and manuals  Warranty costs  Product liability; customers suing for damages  Service costs  Documentation

39. 38 Requirements Management  A systematic approach to eliciting, organizing, and documenting the requirements of the system, and a process that establishes and maintains agreement between customer and the project team on the changing requirements of the system  Requirements management process called for by both CMM and ISO 9000

40. 39 Requirements Management  Boeing 777 – 300,000 requirements  > 4 million loc  1280 embedded processors

41. 40 Lifecycle models

42. 41 Stagewise Model System Requirements Software Requirements Analysis Program Design Implementation Testing Operations 1970 [Royce]

43. 42 Waterfall Model Waterfall Model System Requirements Software Requirements Analysis Program Design Implementation Testing Operations 1970 [Royce]

44. 43 Spiral Model Evaluate Alternatives; Identify, Resolve Risks Determine Objectives, Alternatives, Constraints Develop, Verify Next-Level Product Plan Next Phases CUMULATIVE COST COMMITMENT PARTITION

45. 44 Requirements Definition Overlaps Later Phases Requirements Definition DesignGeneration Testing at some arbitrary time...

46. 45 Evolutionary Delivery Model: Rational Unified Process Business Modeling Requirements Analysis & Design Workflows Inception Elaboration Phases Construction Transition Implementation Test Deployment Configuration & Change Management Project Management Environment Iterations InitialE # 1E # 2C # 1C # 2C # nT #1T #2 Content Time

47. 46 Generalized Software Development Process S/W Requirements S/W sys test plan System test maintain & enhance Prelim Design Integration test plan Integration test Detail Design Unit test plan Unit test coding deliver product

48. 47 Summary  Definitions and general concepts  Process and product  Product properties  Requirements management  The problem domain

49. 48 Analyzing the Problem

50. 49 Requirements roundtable  http://interactive.sei.cmu.edu/Features/199 9/March/Roundtable/Roundtable.mar99.ht m http://interactive.sei.cmu.edu/Features/199 9/March/Roundtable/Roundtable.mar99.ht m

51. 50 The Problem Domain  Home of real users and other stakeholders  People whose needs must be addressed  People who need “the rock”  These people are not like us !  Different technical and economic backgrounds  Speak in funny acronyms  Motivations that seem strange and unfathomable

52. 51 The problem domain

53. 52 A more Realistic Problem domain

54. 53 “Features”  A service that the system provides to fulfill one or more stakeholder needs  Simple descriptions in the user’s language used as labels to communicate with the user how the system addresses the problem

55. 54 Problem/solution domains needs features Software requirements Problem domain solution domain

56. 55 Software as a team activity  “Software development has become a team sport” – Booch 1998  COCOMO – capability of the TEAM has the greatest impact on software productivity

57. 56 Requisite team skills for requirements management  Analyzing the problem domain  Understanding user needs  Defining the system  Managing scope  Refining system definition  Building the right system  We will discuss all of these !!

58. 57 Different Skills  Working with customers  Software programming  Testing  Design and architecture abilities  Also requirements management

59. 58 Problem Analysis  Some applications solve problems  Others take advantage of opportunities in the market (existence of a problem may not be clear)  SimCity  Myst  Problem analysis; the process of understanding real-world problems and user needs and proposing solutions to meet those needs

60. 59 What is a Problem?  “A problem can be defined as the difference between things as perceived and things as derived” – Weinberg  Sometimes the simplest solution is a workaround or revised business plan, rather than a new system  Changing the desire or perception may be the most cost effective solution!

61. 60 Problem Analysis  The goal of problem analysis is to gain a better understanding of the problem being solved before development begins  Gain agreement on the problem definition  Understand the root causes – the problem behind the problem  Identify the stakeholders and the users  Define the system boundary  Identify the constraints to be imposed on the solution

62. 61 1. Gain Agreement on the Problem Definition  Write down the problem and see if everyone agrees  Have the customer describe the benefits  Seems simple but this step can cause much discussion and emotion

63. 62 Problem Statement Format ElementDescription The problem of Describe the problem affects Identify stakeholders affected by the problem the result of which Describe the impact of this problem on stakeholders and business activity benefits of Indicate the proposed solution and list a few key benefits

64. 63 2. Understand Root Causes  Gain understanding of real problem and real causes  “Root cause” analysis  Total Quality Management techniques  Ask people directly involved what the problems are!

65. 64 Fishbone Diagram Too much scrap Inaccurate sales orders Damaged in shipment Customer returns Finished goods Obsolescence Manufacturing defects Other

66. 65 Addressing the root cause  Quality data demonstrates that many root causes are simply not worth fixing

67. 66 Sales order problem statement ElementDescription The problem of Inaccuracies in sales orders affects Sales order personnel, customers, manufacturing, shipping, and customer service the result of which Is increased scrap, excessive handling costs, customer dissatisfaction, and decreased profitability benefits of A new system to address the problem include;  Increased accuracy of sales orders at point of entry  Improved reporting of sales data to management  Higher profitability

68. 67 3. Identify the Stakeholders and the Users  Stakeholder; anyone who could be materially affected by the implementation of a new system or application  Many stakeholders are users  Others are indirect users  Affected by the business outcomes that the system influences  Non-user stakeholder needs must also be identified and addressed

69. 68 Questions  Who are the users of the system?  Who is the customer (economic buyer) for the system?  Who else will be affected by the outputs that the system produces?  Who will evaluate and bless the system when it is delivered?  Who will maintain the system?

70. 69 Users and stakeholders of new system UsersOther stakeholders Sales and order entry clerks MIS director and development team Sales order supervisorChief financial officer Production controlProduction manager Billing clerk

71. 70 4. Define the solution system boundary  Boundary defines the border between the solution and the real world that surrounds the solution inputs system outputs

72. 71 System boundary  World divided into two parts  Our system  Things that interact with our system

73. 72 Actors  Someone or something, outside the system, that interacts with the system I/O users Our solution Other systems I/O System boundary

74. 73 Finding actors  Who will supply, use, or remove information from the system?  Who will operate the system?  Who will perform any system maintenance?  Where will the system be used?  Where does the system get its information?

75. 74 System Perspective Sales Order clerk Billing clerk Shipping clerk Production foreman New sales Order entry Legacy System With Pricing data System boundary

76. 75 5. Identify the constraints to be imposed on the solution  Constraints are restrictions on the degrees of freedom we have in providing a solution  Various sources of constraints  Schedule  ROI  Budget for labor and equipment  Environmental issues  Operating systems and databases  etc

77. 76 Constraints  Constraints may be given to us before we start or we may have to actively elicit them  Should understand the perspective of the constraint  Should understand when the constraint no longer applies to the solution  The less constrained the better!

78. 77 Potential system constraints SourceSample considerations Economic  What financial or budgetary constraints are applicable?  Are there costs of goods sold or any product pricing considerations?  Are there any licensing issues? Political  Are there any internal or external political issues that affect potential solutions?  Interdepartmental issues? Technical  Are we restricted in the choice of technologies?  Are we constrained to work with existing platforms or technologies?  Are we prohibited from any new technologies?  Are we to use any purchased software packages?

79. 78 Potential system constraints SourceSample considerations System  Is the solution to be built on our existing systems?  Must we maintain compatibility with existing solutions?  What operating systems and environments must be supported? Environmental  Are there environmental or regulatory constraints?  Legal?  Security requirements? Schedule and resources  Is the schedule defined?  Are we restricted to existing resources?  Can we use outside labor?  Can we expand resources?

80. 79 Summary – 5 steps of problem analysis  Gain agreement on the problem definition  Understand root causes  Identify stakeholders and users  Identify the system boundary  Identify the constraints on the system

81. 80 Constraints  Purpose of the product  Client, customer, other stakeholders  Users of the product  Requirements constraints  Naming conventions and definitions  Relevant facts  Assumptions

82. 81 Project issues  Open issues  Off the shelf solutions (COTS)  New problems  Tasks  Cutover  Risks  Costs  User documentation  Waiting room

83. 82 Problem Solving

84. 83 Problem Solving Course not about programming Mainly about how to define a problem for people to solve by programming a computer –must provide all the information that programmers and interface designers need to make a computer bring about effects outside the computer This complete statement of the problem is called requirements

85. 84 Problem Solving  Writing software requirements is a form of communication between people  All lot of stakeholders involved  people who desire effects from the software  people who want to perform some task  people who design the machine behavior  people who configure (program) the machines

86. 85 Pick up cargos Haul cargos to destinations Print reports interfaces Database schemas subroutines Linked lists R S Not programming Interface design documents

87. 86 Introduction  Goal of any kind of engineering is to give people ability to do something they currently can’t do  Task of the engineer is to build the device  To write a useful requirements document we must understand what engineers to in order to produce a design that meets the requirements

88. 87 Engineering  Engineering is essentially bridging the gap between requirements and available materials  aeronautical; materials for flight  software engineer; configuring a computer to perform tasks related to information, transmitting information and causing objects to behave in accordance with specified rules

89. 88 Materials of a Software Engineer  Materials are intangible  instructions that a computer is capable of executing  subroutine libraries  high level programming languages  Bridging the requirements/materials gap is not easy  sponge for cleaning easy to see  dishwasher took many years

90. 89 Bridging the Gap  Once somebody figures out how to bridge the gap successfully, the design can be repeated and slightly verified to solve new problems

91. 90 How to bridge the gap  Many theories on how to bridge the gap  Functional decomposition  top-down design  stepwise decomposition  Steps  engineer identifies function of the system to be built  if function maps directly to available parts, allocate function to those parts -> done

92. 91 Functional Decomposition  otherwise divide the function into subfunction and repeat steps 2 and 3 until every subfunction is small enough to map onto the smallest parts of the design  Divide and conquer approach  Problem is that there are many different ways to divide a high level function into subfunctions and there is no way to tell if these divisions are good until into lowest levels of design

93. 92 Problem solving and design patterns  Exhaustive list of all problem solving techniques (order of decreasing effectiveness)  Already knowing the solution  Already knowing the solution to a similar problem  All other techniques

94. 93 Problem solving and design patterns  As engineers we are not interested in giving problems a sporting chance  Engineering problems are so different from each other that few of the ideas or knowledge that enable you to solve one problem will help you solve a problem from a different field  Completely generalized ideas are too unfocused

95. 94 How engineering really works  Engineers apply and slightly vary already existing, time-tested designs  Engineers engage in unstructured exploration of new designs and new ways to put old designs together  Both types can occur on the same project

96. 95 Design Patterns  Despite the importance of standard designs in all engineering fields, it has mostly been left implicit  People learn standard designs for bridges, D.C. generators, brakes, etc  What they do not learn is that standard designs separates professional engineering from tinkering

97. 96 Design Patterns  In software this standard design has become to be know as a design pattern  The word pattern emphasizes that the design can be applied a million times over without ever doing it the same way twice  a brick pattern varies little from application to application  a suspension bridge pattern is a more flexible idea that requires additional intelligence and imagination to apply

98. 97 Design Patterns  Patterns were applied by Christopher Alexander in town planning and architecture  Patterns found in towns and buildings  street café is a pattern  corner grocery is a pattern  dormer window  Rich vocabulary of words allows you to write well - rich vocabulary of design patterns allows us to design well

99. 98 Design Patterns  A pattern is not a reusable component  a component is a physical object  two different instances are identical - both are instances of the same design  a pattern is a reusable idea - no two instances are quite the same  The application of patterns is called design or engineering; the creation of new instances is called manufacturing

100. 99 Why Software is Hard  Early in the history of an engineering field, practices tend to be unstructured exploration instead of application of time- tested ideas  This is natural - in the early days there are fewer time-tested ideas  In the early days there is emphasis on innovation - the field does not produce reliable results  Many untested ideas which often fail

101. 100 Why Software is Hard  Mature engineering fields  engineers spend most of their time combining and making slight variations to time-tested ideas  Solve problems from a well defined set of problems  building a transformer  this is a standard design in electrical engineering  ingenuity still required to solve unexpected problems

102. 101 Why Software is Hard  Invention of entirely new designs still continues  space shuttle tiles  A large vocabulary of time tested ideas makes for a systematic and reliable engineering discipline  very few homes collapse from their own weight  few transformers fail to meet specification

103. 102 Why Software is Hard  Orderly engineering; application and slight variation of time-tested design patterns  Exploratory engineering; unstructured exploration of new kinds of designs  Major reason software projects fail is because there is still a large gap between the system that the customer wants delivered and the available time-tested designs

104. 103 Pattern Composition and Decomposition  Patterns in software engineering  sorting  searching  many types of data structures  parsing  rendering 3-D images  Allow experienced programmers to make design decisions at a higher level than program code

105. 104 Pattern Composition and Decomposition  Pattern decomposition; recognizing a pattern that is built from smaller patterns  Difference from function decomposition is that the patterns have been put together before  Function composition is what led the Wright brothers to succeed where others failed

106. 105 Pattern Composition and Decomposition  Structure of birds versus decomposing flight into its subfunctions  Each subfunction then implemented by further decomposition  But is this what they really did.. ?

107. 106 Functional decomposition of Wright brothers airplane SubfunctionImplementation Forward propulsion Four cylinder engine, propellers LiftWings SteeringRudder, bendable wingtips

108. 107 Functional decomposition of Wright brothers airplane SubfunctionImplementation Up/down propulsion? East/west propulsion? North/south propulsion?

109. 108 Pattern Composition and Decomposition  Wright brothers used wings, an engine, a propeller, rudder was because they had those things  nobody had components that implemented up/down propulsion, east/west propulsion, etc  despite mathematical elegance, nobody does this!  If internal combustion engine did not exist, they would not have deduced one!

110. 109 Pattern Decomposition  Most of the design came from imitation;  idea of wings came from birds  steering mechanism from observing the way birds bend their wings to change direction  engine designed to meet own needs  Town planner wants to build a bridge to go across the bay gives requirements to the engineer who then decomposes the problems into patterns (girders, etc)

111. 110 Pattern Composition and Decomposition  Exploratory engineering works the other way around  composing patterns  build a solution in search of a problem  early computers went this way  we’re still a long way from determining everything we can do with a computer  In orderly engineering pattern decomposition is the rule

112. 111 Pattern Composition and Decomposition  Architecture-driven project; starts with an implementation idea and looks for ways to extend it that provide new and unanticipated benefits to the customer  Requirements-driven project; starts with well-defined benefits and draws upon existing, proven implementation ideas