Requirements Engineering

1. RequirementsEngineering Southern Methodist University CSE 7316

2. The Requirements Problem

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. 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. (IEEE83), ANSI/IEEE Std 729/1983

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

7. 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. ANSI/IEEE Std729/1983

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

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

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

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

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

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

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

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!

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

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

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.

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

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

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

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

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.

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

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)

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

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

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

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!

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

31. 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 Fixing a defect

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

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

34. Lifecycle models

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

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

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

38. Requirements Definition Overlaps Later Phases Requirements Definition Design Generation Testing at some arbitrary time ...

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

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

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

42. Analyzing the Problem

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

44. The problem domain

45. A more Realistic Problem domain

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

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

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

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

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