Details

Autor(en) / Beteiligte

• Meyer-Stabley, Bertrand,

Titel

Handbook of requirements and business analysis

Ort / Verlag

Cham, Switzerland : Springer,

Erscheinungsjahr

[2022]

Link zum Volltext

• SpringerLink Books - AutoHoldings

Beschreibungen/Notizen

• Includes bibliographical references and index.
• Intro -- Short contents -- Preface -- THE MATERIAL -- OBSTACLES TO QUALITY -- DESCRIPTIVE AND PRESCRIPTIVE -- A BALANCED VIEW -- KEY IDEAS -- GEEK AND NON-GEEK -- AUTHOR'S EXPERIENCES BEHIND THIS HANDBOOK -- BIBLIOGRAPHICAL NOTES AND FURTHER READING -- ACKNOWLEDGMENTS -- HANDBOOK PAGE -- CREDITS -- Contents -- 1 Requirements: basic concepts and definitions -- 1.1 DIMENSIONS OF REQUIREMENTS ENGINEERING -- 1.1.1 Universe of discourse: the four PEGS -- 1.1.2 Distinguishing system and environment -- 1.1.3 The organizations involved -- 1.1.4 Stakeholders -- 1.2 DEFINING REQUIREMENTS -- 1.2.1 Properties -- 1.2.2 Statements -- 1.2.3 Relevance -- 1.2.4 Requirement -- 1.2.5 Requirements engineering, business analysis -- 1.3 KINDS OF REQUIREMENTS ELEMENT -- 1.4 REQUIREMENTS AFFECTING GOALS -- 1.4.1 Goal -- 1.4.2 Special case: obstacle -- 1.5 REQUIREMENTS ON THE PROJECT -- 1.5.1 Task -- 1.5.2 Product -- 1.6 REQUIREMENTS ON THE SYSTEM -- 1.6.1 Behavior -- 1.6.2 Special cases: functional and non-functional requirements -- 1.6.3 Special cases: examples (scenarios) -- 1.7 REQUIREMENTS ON THE ENVIRONMENT -- 1.7.1 Constraint -- 1.7.2 Special cases of constraints: business rule, physical rule, engineering decision -- 1.7.3 Assumption -- 1.7.4 Distinguishing between constraints and assumptions -- 1.7.5 Effect -- 1.7.6 Invariant -- 1.8 REQUIREMENTS APPLYING TO ALL DIMENSIONS -- 1.8.1 Component -- 1.8.2 Responsibility -- 1.8.3 Limit -- 1.8.4 Special case: role -- 1.9 SPECIAL REQUIREMENTS ELEMENTS -- 1.9.1 Silence -- 1.9.2 Noise -- 1.9.3 Special case: hint -- 1.9.4 Metarequirement -- 1.9.5 Special case: justification -- 1.10 THE PEOPLE BEHIND REQUIREMENTS -- 1.10.1 Categories of stakeholders -- 1.10.2 Who produces requirements? -- 1.11 WHY PERFORM REQUIREMENTS? -- 1-E EXERCISES -- 1-E.1 Silence and noise -- 1-E.2 Classifying elements of a requirements document.
• 1-E.3 Constraints and assumptions -- BIBLIOGRAPHICAL NOTES AND FURTHER READING -- TERMINOLOGY NOTE: VERIFICATION AND VALIDATION -- 2 Requirements: general principles -- 2.1 WHAT ROLE FOR REQUIREMENTS? -- 2.1.1 The need for requirements -- 2.1.2 The role of requirements -- 2.1.3 The nature of requirements -- 2.1.4 The evolution of requirements -- 2.1.5 The place of requirements in the project lifecycle -- 2.1.6 The form of requirements -- 2.1.7 Outcomes of requirements -- 2.2 HUMAN ASPECTS -- 2.2.1 Stakeholders -- 2.2.2 Authors -- 2.3 REQUIREMENTS ELICITATION AND PRODUCTION -- 2.4 REQUIREMENTS MANAGEMENT -- 2.5 REQUIREMENTS QUALITY -- 2.6 OTHER PRINCIPLES -- 2-E EXERCISES -- 2-E.1 Limit cases -- 2-E.2 Stakeholders -- 2-E.3 Requirements quality -- BIBLIOGRAPHICAL NOTES AND FURTHER READING -- 3 Standard Plan for requirements -- 3.1 OVERALL STRUCTURE -- 3.2 FRONT AND BACK MATTER -- 3.3 USING THE PLAN -- 3.3.1 Forms of requirements conforming to the Standard Plan -- 3.3.2 Customizing the plan -- 3.3.3 Mutual references -- 3.4 THE GOALS BOOK -- 3.5 THE ENVIRONMENT BOOK -- 3.6 THE SYSTEM BOOK -- 3.7 THE PROJECT BOOK -- 3.8 MINIMUM REQUIREMENTS -- 3-E EXERCISES -- 3-E.1 Finding the right place -- 3-E.2 Restructuring a requirements document -- 3-E.3 Devising a project plan -- 3-E.4 Use cases in different places -- BIBLIOGRAPHICAL NOTES AND FURTHER READING -- 4 Requirements quality and verification -- 4.1 CORRECT -- 4.1.1 About correctness -- 4.1.2 Ensuring correctness -- 4.1.3 Assessing correctness -- 4.1.4 Parts of the Standard Plan particularly relevant to assessing correctness -- 4.2 JUSTIFIED -- 4.2.1 About justifiability -- 4.2.2 Ensuring justifiability -- 4.2.3 Assessing justifiability -- 4.2.4 Parts of the Standard Plan particularly relevant to assessing justifiability -- 4.3 COMPLETE -- 4.3 COMPLETE -- 4.4 CONSISTENT -- 4.4.1 About consistency.
• 4.4.2 Ensuring consistency -- 4.4.3 Assessing consistency -- 4.4.4 Parts of the Standard Plan particularly relevant to assessing consistency -- 4.5 UNAMBIGUOUS -- 4.5.1 About non-ambiguity -- 4.5.2 Ensuring non-ambiguity -- 4.5.3 Assessing non-ambiguity -- 4.5.4 Parts of the Standard Plan particularly relevant to assessing non-ambiguity -- 4.6 FEASIBLE -- 4.6.1 About feasibility -- 4.6.2 Ensuring feasibility -- 4.6.3 Assessing feasibility -- 4.6.4 Parts of the Standard Plan particularly relevant to assessing feasibility -- 4.7 ABSTRACT -- 4.7.1 About abstractness -- 4.7.2 The difficulty of abstracting -- 4.7.3 Overspecification -- 4.7.4 Design and implementation hints -- 4.7.5 Beware of use cases -- 4.7.6 Ensuring abstractness -- 4.7.7 Assessing abstractness -- 4.7.8 Parts of the Standard Plan particularly relevant to assessing abstractness -- 4.8 TRACEABLE -- 4.8.1 About traceability -- 4.8.2 Ensuring traceability -- 4.8.3 Assessing traceability -- 4.8.4 Parts of the Standard Plan particularly relevant to assessing traceability -- 4.9 DELIMITED -- 4.9.1 About delimitation -- 4.9.2 Ensuring delimitation -- 4.9.3 Assessing delimitation -- 4.9.4 Parts of the Standard Plan particularly relevant to assessing delimitation -- 4.10 READABLE -- 4.10.1 About readability -- 4.10.2 Ensuring readability -- 4.10.3 Assessing readability -- 4.10.4 Parts of the Standard Plan particularly relevant to assessing readability -- 4.11 MODIFIABLE -- 4.11.1 About modifiability -- 4.11.2 Ensuring modifiability -- 4.11.3 Assessing modifiability -- 4.11.4 Parts of the Standard Plan particularly relevant to assessing modifiability -- 4.12 VERIFIABLE -- 4.12.1 About verifiability -- 4.12.2 Ensuring verifiability -- 4.12.3 Assessing ("verifying") verifiability -- 4.12.4 Parts of the Standard Plan particularly relevant to assessing verifiability -- 4.13 PRIORITIZED.
• 4.13.1 About prioritization -- 4.13.2 Ensuring prioritization -- 4.13.3 Assessing prioritization -- 4.13.4 Parts of the Standard Plan particularly relevant to assessing prioritization -- 4.14 ENDORSED -- 4.14.1 About endorsement -- 4.14.2 Ensuring endorsement -- 4.14.3 Assessing endorsement -- 4.14.4 Parts of the Standard Plan particularly relevant to assessing endorsement -- 4-E EXERCISES -- 4-E.1 Oppositions and tradeoffs -- 4-E.2 Alphabetical order, recursively defined -- 4-E.3 Family relations -- 4-E.4 Salad definition -- 4-E.5 Consistency -- BIBLIOGRAPHICAL NOTES AND FURTHER READING -- 5 How to write requirements -- 5.1 WHEN AND WHERE TO WRITE REQUIREMENTS -- 5.2 THE SEVEN SINS OF THE SPECIFIER -- 5.2.1 The Sins list -- 5.2.2 Noise and silence -- 5.2.3 Remorse -- 5.2.4 Falsehood -- 5.2.5 Synonyms -- 5.2.6 Etcetera lists -- 5.3 REPETITION -- 5.4 BINDING AND EXPLANATORY TEXT -- 5.5 NOTATIONS FOR REQUIREMENTS -- 5.5.1 Natural language -- 5.5.2 Graphical notations -- 5.5.3 Formal notations -- 5.5.4 Tabular notations -- 5.5.5 Combining notations -- 5.6 SOME EXAMPLES: BAD, LESS BAD, GOOD -- 5.6.1 "Provide status messages" -- 5.6.2 The flashing editor -- 5.6.3 Always an error report? -- 5.6.4 Words to avoid -- 5.7 STYLE RULES FOR NATURAL-LANGUAGE REQUIREMENTS -- 5.7.1 General guidelines -- 5.7.2 Use correct spelling and grammar -- 5.7.3 Use simple language -- 5.7.4 Identify every part -- 5.7.5 Be consistent -- 5.7.6 Be prescriptive -- 5.8 THE TBD RULE -- 5.9 DOCUMENTING GOALS -- 5.10 THE SEVEN SINS: A CLASSIC EXAMPLE -- 5.10.1 A simple specification -- 5.10.2 A detailed description -- 5.10.3 More ambiguity! -- 5.10.4 Lessons from the example -- 5.10.5 OK, but can we do better? -- 5-E EXERCISES -- 5-E.1 Addressing criticism -- 5-E.2 Text formatting -- 5-E.3 Do not just format, justify -- BIBLIOGRAPHICAL NOTES AND FURTHER READING.
• 6 How to gather requirements -- 6.1 PLANNING AND DOCUMENTING THE PROCESS -- 6.2 THE ROLE OF STAKEHOLDERS -- 6.3 SOURCES OTHER THAN STAKEHOLDERS -- 6.4 THE GLOSSARY -- 6.4.1 Clarify the terminology -- 6.4.2 Kidnapped words -- 6.4.3 Acronyms -- 6.5 ASSESSING STAKEHOLDERS -- 6.6 MAKING BUSINESS ANALYSTS AND DOMAIN EXPERTS WORK TOGETHER -- 6.7 BIASES, INTERVIEWS AND WORKSHOPS -- 6.8 CONDUCTING EFFECTIVE INTERVIEWS -- 6.8.1 Setting up and conducting an interview -- 6.8.2 Interview reports -- 6.9 CONDUCTING EFFECTIVE WORKSHOPS -- 6.9.1 Why workshops help -- 6.9.2 When to run workshops -- 6.9.3 Planning a workshop -- 6.9.4 Running a workshop -- 6.9.5 After the workshop -- 6.10 ASKING THE RIGHT QUESTIONS -- 6.10.1 Uncover the unsaid -- 6.10.2 Cover all PEGS -- 6.10.3 Do not confuse roles -- 6.10.4 Ask effective questions -- 6.10.5 Get stakeholders to prioritize -- 6.11 PROTOTYPES: TELL OR SHOW? -- 6.11.1 What is a prototype? -- 6.11.2 Incremental prototypes -- 6.11.3 Throwaway prototypes -- 6.11.4 UI prototypes -- 6.11.5 Feasibility prototypes -- 6.11.6 Limitations of prototypes -- 6.11.7 Risk assessment and mitigation -- 6-E EXERCISES -- 6-E.1 Throwaway prototypes and second-system effect -- 6-E.2 A glossary for web-based sales -- 6-E.3 A glossary for text formatting -- 6-E.4 A workshop plan -- BIBLIOGRAPHICAL NOTES AND FURTHER READING -- 7 Scenarios: use cases, user stories -- 7.1 USE CASES -- 7.2 USER STORIES -- 7.3 EPICS AND USE CASE SLICES -- 7.4 THE BENEFITS OF SCENARIOS FOR REQUIREMENTS -- 7.5 THE LIMITATIONS OF SCENARIOS FOR REQUIREMENTS -- 7.6 THE ROLE OF USE CASES AND USER STORIES IN REQUIREMENTS -- 7-E EXERCISES -- 7-E.1 Scenarios for graphical manipulation -- 7-E.2 User stories from a use case -- BIBLIOGRAPHICAL NOTES AND FURTHER READING -- 8 Object-oriented requirements -- 8.1 TWO KINDS OF SYSTEM ARCHITECTURE -- 8.2 THE NOTION OF CLASS.
• 8.3 RELATIONS BETWEEN CLASSES AND THE NOTION OF DEFERRED CLASS.
• Description based on print version record.