1 / 105

Requirements Engineering

This course covers definitions, processes, product properties, and management of software requirements. Learn about the importance of requirements analysis, tasks involved, system behavior, and artifact purposes in effective requirement engineering. Understand the significance of documentation, specifications, verification, and traceability in creating good requirements. Key considerations, process management, and common errors in requirements engineering are also discussed.

imogenee
Download Presentation

Requirements Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RequirementsEngineering Southern Methodist University CSE 7316

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  24. The Requirements Problem

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

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

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

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

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

  30. Defect Summary

  31. Defect Summary

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

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

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

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

  36. Lifecycle models

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

  38. Spiral model

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

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

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

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

  43. Analyzing the Problem

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

More Related