1 / 34

Lecture 3 Requirements

CS 540 – Quantitative Software Engineering. Lecture 3 Requirements. Software Requirements Process. Requirements Elicitation Requirements Analysis Use Cases Requirements Specification Prototype/Modeling Requirements Management. Highlights of quantitative approach. Lambda Protocol

sakina
Download Presentation

Lecture 3 Requirements

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. CS 540 – Quantitative Software Engineering Lecture 3 Requirements

  2. Software Requirements Process • Requirements Elicitation • Requirements Analysis • Use Cases • Requirements Specification • Prototype/Modeling • Requirements Management

  3. Highlights of quantitative approach • Lambda Protocol • Overlaps with Systems Engineering • Industrial Strength Requirements for Software Intensive Systems-of-Systems

  4. What is a requirement? • A property that must be exhibited by a system to solve some problem. • Requirements may be • Functional providing product capabilities • Non-Functional constraining the implementation

  5. Robust Requirements Discrete Specifications Ideal Volume Robust Requirements Dynamic Range

  6. Spiral Model Cumulative Cost Determine objectives, alternatives, constraints Progress through steps Evaluate alternatives; identify and resolve risks 1 2 Risk Analysis Risk Analysis Risk Analysis Risk Analysis Prototype 1 Prototype 2 Prototype 3 Operational Prototype Review Commitment Partition Simulations, models, benchmarks Requirements Plan; Life-cycle plan Concept of Operation Software Requirements Detailed Design Software Product Design Code Development Plan Req.s Validation Unit Test Integration and Test Plan Design Validation and Verification Integration and Test Acceptance Test 4 Plan next phase Implementation Develop and verify next-level product 3 From Boehm (1988), p. 64

  7. Project uncertainty 4x 2x 1.5x 1.25x Relative Cost Range x 0.8x 0.67x 0.5x Concept of Operation Requirements Specifications Product Design Specifications Detailed Design Specifications Accepted Software 0.25x Feasibility Plans and Requirements Product Design Detailed Design Development and Test Phases and Milestones

  8. Reasonable control over quality, measured process Adaptive feedback process Process defined & institutionalized, reliable cost & schedule Level 4 Managed Process Level 2 Repeatable Process Level 3 Defined Process Level 5 Optimizing Process 0% 0% 12% 7% Intuitive, dependent on talented individuals Level 1 Initial Process 81% Ad Hoc, chaotic SEI Capability Model Key Process Areas Process change managementTechnology change managementDefect prevention Software quality managementQuantitative process management Peer reviews & training programInter-group coordinationProduct engineeringProcess definition & focusIntegrated software management Configuration ManagementQuality AssuranceSubcontract ManagementProject planning, tracking, & oversightRequirements management Source: Andriole, Stephen J., Managing System Requirements, Methods, Tools, and Cases McGraw-Hill, 1996

  9. Top Ten Software Risk Items From Boehm (1988), p. 6

  10. Creeping featurism • Endemic to the Software Industry • Occurs on more than 70% of all applications over 1000 function points • From a 60 project sample • Average creep = 35% • Maximum = 200% • Creeping requirements change about 1% per month • For a 3 year project, 1/3 of the delivered requirements will be added after requirements are baselined. • Rate of software requirements change is higher than for other engineering fields (electrical, mechanical, civil). Source: Assessment and Control of Software Risks, Capers Jones, 1994 It’s only software!

  11. What drives creeping featurism? • Not knowing real user needs, not their wants. • Changes in normal business environment • Solution changes nature of business • Economic downturns. • Failure to adopt processes designed to limit creeping featurism • Primitive technologies for exploring and modeling requirements • Failure to use technology to measure the impact of creeping requirements Source: Assessment and Control of Software Risks, Capers Jones, 1994

  12. Managing requirements • Create and invoke the MOV (Measurable Operational Value) • Establish, update and model the business case . • Strategic linkages to business and technology organizations to AVOID SHELFWARE • Continuous customer agreement on requirements • Requirements agreement used as a basis for estimating, planning, implementing and tracking • FORMAL COMMITMENT PROCESS Source: Andriole, Stephen J., Managing System Requirements, Methods, Tools, and Cases McGraw-Hill, 1996

  13. Requirements engineering process • Process Models • Process Actors and Stakeholders • Process Support and Management • Process Quality and Improvements • Relationship to the Business Decision Informal Statement of Requirements Decision Point: Accept Document or re-enter spiral Requirements Elicitation Requirements Analysis & Negotiation Requirements Document & Validation Report Agreed Requirements Requirements Validation Requirements Specification Draft Requirements Document

  14. QSE Lambda Protocol • Prospectus • Measurable Operational Value • Prototyping and Modeling • sQFD: Simplified Quality Function Deployment • Schedule, Staffing, Quality Estimates • ICED-T: Intuitive, Consistent, Efficient, Durable and Thoughtful • Trade-off Analysis As of 31 August

  15. Requirements Engineering(van Vliet, p.209) user User Rqts Feedback Models to be Validated by user Rqts Spec models Knowledge elicitation specification validation Validation results Request more Knowledge Problem domain Domain Knowledge Domain Knowledge

  16. More on Requirements • Requirements are the what and why but … • “… it is an illusion to expect that perfect requirements can be formulated ahead of time” - (Endres & Rombach, p. 15) • Outsourced products require careful requirements - key in today’s world • All stakeholders must participate

  17. Importance of Requirements • Often too many, unstable due to late changes, ambiguous, incomplete • Glass: “Requirements deficiencies are the prime source of project failures.” • Boehm: “Errors are most frequent during the requirements and design activities and are more expensive the later they are removed.” • Cost of requirements errors increase with their longevity.

  18. Some Success Processes • Should expend 15-30% of effort on requirements • Requirements should be assigned priorities • Traceability should be enforced throughout • Validation and verification

  19. What goes wrong • Miss or misunderstand a majority of the essential requirements - prototyping and other elicitation techniques are helpful • Endless requirements - requirements stages require a cutoff point • Sales team (or management) interferes and confuses what is desired with what is required • Spend too little time on user interface requirements - what does the user see in the end, eh?

  20. Requirements Process • Elicit feature or functional requirements from the user (Boehm -as much as 40% of final features not in requirements specification) • Understand constraints and non-functional requirements - many are ‘ilities • Analyze the requirements (use cases) to make sure they flow and make sense • Develop prototype, model or user documentation • Produce and control a requirements specification

  21. Requirements Elicitation • Implicit conceptual model of users becomes explicit • Requires us to become quick learners but • Much of knowledge is • Knowledge taken for granted • Tacit-knowledge skillfully applied in the background, not verbalized • Involves habits, customs, inconsistencies • Influenced by frequency and recency • What’s needed may be different from what exists

  22. Requirements Elicitation Techniques • Asking: interview, questionnaire, structured interview, Delphi (group based) • Task analysis: hierarchical decomposition • Scenario based analysis: instances of tasks, use-case (not only for OO) • Ethnography: studying folks in natural setting • Walking around • Models

  23. Requirements Elicitation Techniques • Form analysis: existing forms • Natural language descriptions: training, manuals, • Derivation from existing system • Domain analysis: study existing systems w/in domain, reusable components • Project future business environment from PMO and systems

  24. Requirements Elicitation Techniques • Business Process Redesign - radically redesign the processes, information processing systems should enable • At the very least rethink the existing process • Prototyping • Usually a combination • Panels of Subject Matter Experts

  25. Requirements Analysis • Lambda Protocol • Revise requirements as needed • Redo and replan with GANTT chart • Review MOV and ICED-T to see if it is worth doing

  26. Cost of Big Requirements Up Front (BRUF) Even “Successful” Projects Have Significant Waste Feature usage Source: Jim Johnson of the Standish Group, Keynote Speech XP 2002 As of 9/26

  27. Serial development is costly The Longer You Wait for Feedback, the more costs are sunk.

  28. Business Analyst A sometime facilitator between customers and developers.

  29. We value: Individuals and interactions Working software Customer collaboration Responding to change Over: Processes and tools Comprehensive documentation Contract negotiation Following a plan Agile Values (www.agilealliance.org) Some things are more important than others

  30. Communication Medium

  31. Agile Software Requirements Management

  32. Summary: Typical Requirements Specifications • Project/Feature Title: Identification (Release and Identifier) Author(s) • Scope and Purpose • Measurable Operational Value • Summary • Feature Description • Interfaces • Constraints • Non-functional Requirements (“ilities”) • Change log • Responses to the unexpected • Glossary/References

  33. Summary: Requirements • Software Requirement: property which must be exhibited by software developed or adapted to solve a particular problem • Fundamentals: Functional vs. non-functional, Quantifiable vs Qualifiable, Emergent vs. Basic • Four Phases: Elicitation, Analysis, Specifications, Validation • Elicitation: sources and techniques • Analysis: Classification, Modeling, Design, and Negotiation • Specifications: System Definition, Requirements Specifications • Validation: Requirements Reviews, Prototyping, Model Validation, Acceptance • Practical Considerations: Iteration, Change Management, Attributes, Traceability, Measurement

  34. Summary: Requirements Directions • Requirements elicitation and proposals have become part of “software services” and “system integration” • Business process analysis • Process re-engineering • Conceptual data modeling • Task and work-flow analysis • Request for Quotations/Request for Proposals • Information strategy planning • Enterprise Resource Management/Customer Relationship Management • Standards exist (i.e., IEEE 830) but very domain dependent • Provides communication vehicle customer-analyst/analyst-developer • Assignment: Read B&Y Chapter 3, MMM Chapter 3. • Search “Software Requirements”/ Review 3-5 websites for commercial products/ Reference your sites and provide overview of current products.

More Related