1 / 29

Simplistic Requirements Models Considered Harmful

Simplistic Requirements Models Considered Harmful. David Gelperin.

sidneyj
Télécharger la présentation

Simplistic Requirements Models Considered Harmful

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. Simplistic Requirements Models Considered Harmful DavidGelperin Objective: The solution is not in the textbooks, because they are full of simplistic requirement models. Few project stakeholders and academics appear to understand some basics of solution requirements development (SRD). This seminar covers new perspectives on the goals and strategies of SRD achieved by condensing 20 years of discovery into a set of pragmatic concepts and practical tactics for addressing major SRD challenges and their mitigations.

  2. Topics Session 3 - 1:50 to 2:25 • Crosscutting requirements (3) • Quality Requirements UpFront (3) • Principles review & sharing Session 4 - 2:30 to 3:00 • Mixed strategies (6) • Open challenges (6) • Final exercise & sharing Session 1 - 12:00 to 12:45 • Understanding complexity (12) • Requirements-related information (6) • Requirements development (6) Session 2 - 12:50 to 1:45 • SRD artifacts (4) • Functional domain requirements (7) • Quality requirements (21)

  3. Session 1 - 12:00 to 12:45 • Understanding complexity (12) • Requirements-related information (6) • Requirements development (6)

  4. Understanding Complexity • Complex means difficult to understand by people of average intelligence • Simple means easy to understand by people of average intelligence • We are biologically programmed to prefer simple, • but we often overdo it • Simplistic means too simple e.g., female identification by male jewel beetles • Simplistic sells i.e., widely-accepted may mean too-simple

  5. Oversimplification Bias • Psychologists say we prefer simplistic solutions • We are mentally addicted to few, unconditional rules • Software process advice (and political rhetoric) is filled with these • Advantages of small-scale mental models may help explain our simplistic bias • In addition, the human (and male jewel beetle) capacity for denial is infinite

  6. We often oversimplify Ideas should be made as simple as possible -- but no simpler. paraphrasing A. Einstein For every complex problem there is an answer that is clear, simple, and wrong. H. L. Mencken

  7. Reality is more complex than many imagine i.e., Occam may be wrong Requirements development is much more complex than many imagine

  8. Models • A model represents aspects of its subject. • H2Ois a model of a water molecule. It identifies the constituent atoms and their counts.Another model shows relative size and orientation of these atoms as well. • A simplistic model omits important elements of the aspects it represents and/or misrepresents those aspects. For example, ISO25010 is a simplistic model of quality attributes. Functional and non-functional requirements is a simplistic model of requirements types.

  9. US tax code Rube Goldberg devices Complex models are not simple Spaghetti code sufficient, but partially unnecessary Unnecessary Complexity necessary and sufficient Complexity (3 kinds) Essential Complexity Simplicity London Underground General Relativity Benzene ring DNA 10

  10. Complexity ofTypes of Solution Requirements necessary and sufficient Essential Complexity UR Requirements Model (19) Simplicity Complexity necessary, but insufficient and/or defective SEBOK Requirements Model (2) Insufficient Complexity (Simplistic, Naive) 11

  11. Complexity of Quality Models necessary and sufficient LiteRM Quality Model (> 30) Simplicity Complexity Essential Complexity necessary, but insufficient and/or defective Insufficient Complexity (Simplistic, Naive) ISO 25010 et. al. (1)

  12. Complexity of Solution RequirementsDevelopment necessary and sufficient Basic SRD pattern (elicit +18) Simplicity Complexity Essential Complexity necessary, but insufficient and/or defective SEBOK Requirements Process (elicit) Insufficient Complexity (Simplistic, Naive) Requirements development is full of simplistic models

  13. Managing Risk “Risk management is project management for adults” -- Tom DeMarco & Tim Lister Risk management tactics When feasible, simplify unnecessary complexity e.g., refactor code When necessary, complexify the simplistic models and methods Simplistic models limit understanding You can’t manage what you don’t understand

  14. You knowYou don’t know e.g., my birthdate e.g., your birthdate What you know What you don’t know simplistic ain’t so is so essentially complex, but currently simplistic e.g., number of red stripes on a US flag undiscovered ideas e.g., perceptrons

  15. Session 1 - 12:00 to 12:40 • Understanding complexity (12) • Requirements-related information (6) • Requirements development (6)

  16. Scope of requirements-related information • Application domain ontology e.g., AV control concepts • Problem/opportunitye.g., autonomous vehicle control • Stakeholders e.g., occupants, roadway sharers, … • Solution context e.g., sensors, effectors, vehicle, vehicle conditions, traffic conditions, roadway conditions, weather conditions, driving laws, … • Solution risks e.g., safety of occupants, safety of others, … • Assumptions • Achievable restrictions on feasible solutions (i.e., requirements) • Requirements risks and mitigations That’s a lot to know

  17. Application Domain Ontology Adequate domain understanding of autonomous vehicle controls entails learning precise definitions for named concepts: • entities: people, people indicators (e.g., strollers), vehicles, substantial objects (e.g., jackknifed trucks) • entity relationships: tailgating • values: speed limits • conditions: people indicators detected, roadway impassable • calculations: safe stopping distance • hazards: sink holes, kangaroos, fallen powerlines • procedures: safe swerving • facts: drivers move into open lanes • rules: common US traffic laws in the current year

  18. An essentially-complex solution requirements model Not all types are necessary in every set of requirements Note major role played by developers

  19. Glossaries with precise definitions promote clarity Tower of Unrecognized Ambiguity Tower of Babel For new domainsor applications, terminology management is very important

  20. Value of precise definitions • Precise definitions catalyze critical conversations • Their value is directly related to the difficulty of their creation i.e., easy = low value hard = high value

  21. Is this creature “near” the roadway?

  22. Session 1 - 12:00 to 12:40 • Understanding complexity (12) • Requirements-related information (6) • Requirements development (6)

  23. What is a requirement? A solution requirementis a restriction that determines whether a proposed solution is adequate. A proposed solution may comply with all known requirements, but still be inadequate because (a) the set is inadequate and/or (b) some requirements are defective.

  24. Value of Requirements Some believe that poor requirements are a leading cause of project failures Poor requirements cause: • flawed estimation and poor decision making • poor design and poor verification • system failures • disappointed stakeholders 54% of the 486 requirements faults in specs for the International Space Station were missing, omitted, or incomplete requirements. Another 24% were incorrect. Good requirements matter. Simplistic models don’t help.

  25. Goal of requirements development To manage understanding risk by promoting deep, synchronized, and accurate stakeholder understanding of necessary restrictions

  26. Basic SRD Pattern • Acquisition of requirements-related information (e.g., glossary) • Analysis and derivation (e.g., conflicts & risk mitigations) • [Specification and modeling] (e.g., interfaces and prototyping) • [Designing system architecture] • [For the selected architecture, design an achievement, monitoring, and verification strategy for each quality and estimate their effort.]

  27. Ways to Acquire • Analyze • application domain & boundaries • connected systems • stakeholders • rule sources • ec-model of requirement types • organizational constraints e.g., government laws & regulations • ec-model of quality attributes • capability descriptions • user guides • similar systems • reverse engineering • Elicit • Do or observe • Associate, derive, & generalize • Design quality achievement, monitoring, & verification strategies e.g., mitigate hazards • Reuse • Model usage • Design acceptance tests • Prototype Alexander & Beus-Dukic Discovering Requirements ec= essentially complex

  28. SRD may be a never ending story “For many complicated, highly interactive, or embedded systems, … we continue to discover requirements knowledge into deployment and beyond” Lutz & Mikulski JPL

More Related