2. Requirements Engineering Southern Methodist University CSE 7316

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

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

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.

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

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.

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

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

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

11. 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!

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

13. 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

14. 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.

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

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

17. 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...

18. 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

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

20. 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

21. 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)

22. 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

23. 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.

24. 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

25. The Requirements Problem

26. 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!

27. 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

28. 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.

29. 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%) …..

30. 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

31. 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

32. 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

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

34. 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

35. 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

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

37. Lifecycle models

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

39. Spiral model

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

41. 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

42. 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

43. Summary Definitions and general concepts Process and product Product properties Requirements management The problem domain

44. Analyzing the Problem

45. 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

46. The problem domain

47. “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

48. Problem/solution domains needs features Software requirements Problem domain solution domain

49. 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

50. 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 !!

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

52. 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

53. 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!

54. 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

55. 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

56. 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

57. 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!

58. Ishikawa (Fishbone/Cause-and Effect) diagram

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

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

61. 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

62. 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

63. 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?

64. 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

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

66. System boundary World divided into two parts  Our system  Things that interact with our system

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

68. 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?

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

70. 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

71. 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!

72. 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?

73. 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?

74. 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

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

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

77. Problem Solving

78. 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

79. 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

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

81. 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

82. 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

83. 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

84. 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

85. 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

86. 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

87. 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

88. 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

89. 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

90. 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

91. 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

92. 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

93. 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

94. 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

95. 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

96. 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

97. 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

98. 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

99. 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

100. 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.. ?

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

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

103. 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!

104. 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)

105. 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

106. 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