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

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

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

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

35. 34 Lifecycle models

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

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

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

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

40. 39 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

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

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

43. 42 Analyzing the Problem

44. 43 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

45. 44 The problem domain

46. 45 A more Realistic Problem domain

47. 46 “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. 47 Problem/solution domains needs features Software requirements Problem domain solution domain

49. 48 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. 49 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. 50 Different Skills  Working with customers  Software programming  Testing  Design and architecture abilities  Also requirements management

52. 51 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. 52 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. 53 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. 54 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. 55 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?

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

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

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

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

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

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

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

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

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

66. 65 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?

67. 66 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

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

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

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