1 / 27

Importance of Requirements in Software Engineering

This chapter discusses the importance of requirements in software engineering, including eliciting, modeling, reviewing, and documenting requirements. It also highlights the risks and challenges of requirements extraction and provides techniques for ensuring quality requirements.

ostrowski
Download Presentation

Importance of Requirements in Software 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. CSCI 6231 Software Engineering(Chapter 10?) Requirements Workflow Instructor: Morris Lancaster

  2. Overview • Slides on Text Material are Backup. • Introduction • Discuss • Eliciting requirements from clients • Modeling requirements • Reviewing • Documenting CSCI 6231 Chapter 10

  3. Introduction • Requirements Analysis • Capture what the customer wants • Negotiate/iterate on what we and the customer can agree to • And which is testable CSCI 6231

  4. Importance of Requirements “The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.” Brooks, Frederick P., Jr. (1987). “No silver bullet: Essence and accidents of software engineering.” IEEE Computer, 20(4), April 1987: pp 10-19. CSCI 6231

  5. Importance of Requirements • In 1994, the Standish Group surveyed over 350 companies about their over 8000 software projects to determine status of the industry • 31% cancelled before completed • 9% delivered on time and within budget in large companies • 16% delivered on time and within budget in small companies • Top reported factors contributing to failures • Incomplete requirements 13.1% ** • Lack of user involvement 12.4% ** • Lack of resources 10.6% • Unrealistic expectations 9.9% ** • Lack of executive support 9.3% • Changing requirements and specifications 8.7% ** • Lack of planning 8.1% • System no longer needed 7.5% **? CSCI 6231

  6. Requirement • An expression of desired behavior • Objects/Entities • States that objects can be in • Functions performed to change states or characteristics • Non-functional requirements • Timeline • Extracted from the user • Refined at specification time (allocated to software) • Baselined as trace-back-to during implementation • Are basis for testing • Can change at any time CSCI 6231

  7. Requirements Extraction • An expression of desired behavior • Objects/Entities • States that objects can be in • Functions performed to change states or characteristics • Timeline • Extracted from the user and other inputs • Refined at specification time (allocated to software) • Baselined as trace-back-to during implementation • Are basis for testing • Can change at any time CSCI 6231

  8. Requirements Extraction • Sources • Stakeholders • The person/organization paying for the system • Customers of the above who will purchase the system • End users of the system • Domain Experts • Market Researchers • Lawyers/Auditors • Software Engineers • Consistency? • One approach is to encourage inconsistency during the requirements process and document stakeholder views, maintaining them CSCI 6231

  9. Requirements Extraction • Sources - continued • Documentation • Existing procedures/processes/system • Observation of the current system • User performance of tasks • Apprenticeship with users • Products from Domain Specific Strategies such as JAD • Brainstorming CSCI 6231

  10. Requirements Extraction • Issues • Requirements are not well formed or well understood at the beginning • Customers are not able to describe what they want or need • It is difficult for the software engineer to rapidly understand someone else’s business concerns • Customers use their jargon and domain specific thought models as assumed baselines • The software engineer’s jargon and domain specific thought models interfere CSCI 6231

  11. Requirements Extraction • Types • Functional • Non functional (quality requirements, etc) • Constraints • Design constraints (previously made, platform or product) • Process constraints (how we build it, customer whims, agile) CSCI 6231

  12. Requirements Extraction • Types (more) • Design constraints • Physical environment • Interfaces • Users • Process constraints • Resources • Documentation • Quality constraints • Performance • Security CSCI 6231

  13. Requirements Extraction • Types (more) • Quality constraints • Performance • Security • Reliability and availability • Maintainability • Precision and accuracy • Time to delivery/cost CSCI 6231

  14. Requirements Extraction • Requirements Documents • Requirements Definition • A complete listing of everything that the client wants to achieve • Requirements Specification • Restates the requirements as a specification of how the proposed system shall behave CSCI 6231

  15. Requirements Extraction • Requirements Characteristics • Are the requirements correct? – review by all • Are the requirements consistent? – any conflicts, have views been reconciled? • Are the requirements unambiguous ?– be able to see the person on the hill with the telescope • Are the requirements complete? – ranges of inputs/outputs and operational environments specified with expected behaviors • Are the requirements feasible? • Is every requirement relevant? • Are the requirements testable? • Are the requirements traceable/ CSCI 6231

  16. Requirements Extraction • Testable • Once a requirement is stated, we should be able to determine whether or not a proposed solution meets the requirements • Evaluation must be objective • Atmospheric humidity information must be accessible immediately • Atmospheric humidity information must be retrieved within 5 seconds of a request CSCI 6231

  17. Modeling Notations • Modeling • Implements repeatable processes that can be used to achieve results within a given set of bounds • Many specification and design notation methods CSCI 6231

  18. Modeling Notations • Entity Relationship Diagrams (Chen – 76) • Entities, attributes, relationships • UML Class Diagram • Name, attributes, operations, associations, generalizations, subclasses • Event Traces • Sequence of events • Message Sequence Charts CSCI 6231

  19. Modeling Notations • State Machines • State transitions, possible state • UML Statechart Diagrams • Petri Nets • Data-Flow diagrams • Data centric view with processes shown • Use Case Diagram • Formal Approaches • Logic (temporal) • Set Theoretic (Z) • Algebraic Specifications CSCI 6231

  20. Modeling Notations • Also there are methodologies which incorporate multiple views • The objective is to have a set of notations that can be used throughout the development or life cycle of the initiative • An important characteristic is the ability to flesh out requirements iteratively (and follow ons to design and implementation) using all of the same tools we began with and that there are relationships (informational) between the notations/tools CSCI 6231

  21. Prototyping • Throwaway • We must introduce it as a visiting orphan, or • We must tear it from the tight grip of the user and throw it in the trash in front of them • Evolutionary • The user will watch their child grow CSCI 6231

  22. Requirements Definition • Outline general purpose and scope • Describe the background and rationale behind the proposed system • Describe the essential characteristics of an acceptable solution • Describe the environment in which the system will operate • Outline any customer proposals for solving the problem • Document all assumptions made about the environment CSCI 6231

  23. Requirements Specification • Document interfaces, inputs and outputs in detail, destinations, etc • Restate functionality in terms of the interfaces’ inputs and outputs • Devise fit criteria for each customer quality requirement. CSCI 6231

  24. Verification and Validation • Validation • Is it valid? • Do the requirements accurately reflect the customer’s • Verification • Do the documents/artifacts produced thus far conform CSCI 6231

  25. Verification and Validation Techniques • Validation • Walkthroughs and formal inspections • Reading • Interviews • Reviews • Checklists • Scenarios • Prototypes • Simulation CSCI 6231

  26. Verification and Validation Techniques • Verification • Cross-referencing artifacts • Simulation • Checks for consistency and completeness • Checks for unreachable states, situations • Computer aided verification • Mathematical Proofs CSCI 6231

  27. Summary • Requirements definition and specification documents must describe the problem, leaving solution selection to the designers • Large number of sources and means for collecting requirements • Many different types of definition and specifications techniques • Specification techniques differ in their tool support, maturity, understandability, ease of use, and mathematical formality. • Requirements questions can be answered using models or prototypes. • Requirements must be validated to ensure they accurately reflect the customers’ expectations CSCI 6231

More Related