book

Managing Software Requirements: A Use Case Approach, Second Edition

by Dean Leffingwell, Don Widrig

May 2003

Intermediate to advanced

544 pages

11h 20m

English

Addison-Wesley Professional

Read now

Unlock full access

Copyright
Dedication
The Addison-Wesley Object Technology Series
The Component Software Series
Foreword
The Rock ProblemA Simple Metaphor: Building a HouseAbout This Book
Preface to the Second Edition
About the Second EditionAcknowledgments
Preface to the First Edition
ContextRequirements Lessons from Building Software for OthersLessons from Building High-Assurance SystemsLessons from the Requirements Management BusinessExperiences at Rational SoftwareSummary
Introduction
1. The Requirements Problem
The Goal of Software DevelopmentA Look at the DataThe Root Causes of Project Success and FailureThe Frequency of Requirements ErrorsThe High Cost of Requirements ErrorsSummary
2. Introduction to Requirements Management
DefinitionsWhat Is a Software Requirement?What Is Requirements Management?Application of Requirements Management TechniquesTypes of Software ApplicationsSystems ApplicationsThe Road MapThe Problem DomainStakeholder NeedsMoving Toward the Solution DomainFeatures of the SystemSoftware RequirementsSummary
3. Requirements and the Software Lifecycle
Traditional Software Process ModelsThe Waterfall ModelThe Spiral ModelThe Iterative ApproachLifecycle PhasesIterationsDisciplinesRequirements in the Iterative ModelSummary

4. The Software Team
Software Development as a Team ActivityRequisite Team Skills for Effective Requirements ManagementTeam Members Have Different SkillsThe Organization of Software TeamsThe Case StudyBackground for the Case StudyThe HOLIS Software Development TeamSummary
1. Analyzing the Problem
5. The Five Steps in Problem Analysis
Step 1: Gain Agreement on the Problem DefinitionThe Problem StatementStep 2: Understand the Root Causes—The Problem Behind the ProblemAddressing the Root CauseStep 3: Identify the Stakeholders and the UsersStep 4: Define the Solution System BoundaryStep 5: Identify the Constraints to Be Imposed on the SolutionSummaryLooking Ahead
6. Business Modeling
The Purpose of Business ModelingUsing Software Engineering Techniques for Business ModelingChoosing the Right TechniqueThe Unified Modeling LanguageBusiness Modeling Using UML ConceptsFrom the Business Model to the Systems ModelWhen to Use Business ModelingSummaryLooking Ahead
7. Systems Engineering of Software-Intensive Systems
What Is Systems Engineering?Pragmatic Principles of Systems EngineeringThe Composition and Decomposition of Complex SystemsRequirements Allocation in Systems EngineeringOn Derived RequirementsA Quiet RevolutionWhen Generations Collide: Graying Baby Boomer Meets Generation X-erAvoiding the Stovepipe System ProblemWhen Subsystems Are SubcontractsAddressing the ConundrumThe Case Study: Systems Engineering for HOLISPreliminary User NeedsProblem AnalysisHOLIS: The System, Actors, and StakeholdersHOLIS Systems EngineeringThe Subsystems of HOLISSummary
Team Skill 1 Summary
2. Understanding User and Stakeholder Needs
8. The Challenge of Requirements Elicitation
Barriers to ElicitationThe “Yes, But” SyndromeThe “Undiscovered Ruins” SyndromeThe “User and the Developer” SyndromeSummary
9. The Features of a Product or System
Stakeholder and User NeedsFeaturesManaging Complexity by Picking the Level of AbstractionAttributes of Product FeaturesSummary
10. Interviewing
Context-Free QuestionsSolutions-Context QuestionsThe Moment of Truth: The InterviewCompiling the Needs DataThe Analyst's Summary: 10 + 10 + 10 ≠ 30The Case StudyA Note on QuestionnairesSummary
11. Requirements Workshops
Accelerating the Decision ProcessPreparing for the WorkshopSelling the ConceptEnsuring the Participation of the Right StakeholdersAttending to LogisticsProviding Warm-Up MaterialsChoosing the FacilitatorSetting the AgendaRunning the WorkshopProblems and Tricks of the TradeBrainstorming and Idea ReductionProduction and Follow-UpSummary
12. Brainstorming and Idea Reduction
Live BrainstormingIdea ReductionPruning IdeasGrouping IdeasDefining FeaturesPrioritizing IdeasCumulative Voting: The Hundred-Dollar Test“Critical, Important, Useful” CategorizationWeb-Based BrainstormingThe Case Study: The HOLIS Requirements WorkshopThe AttendeesThe WorkshopThe SessionThe Analysis of ResultsSummary
13. Storyboarding
Types of StoryboardsWhat Storyboards DoTools for StoryboardingTips for StoryboardingSummary
Team Skill 2 Summary
3. Defining the System
14. A Use Case Primer
The Benefits of Use CasesUse Case BasicsOn ActorsUse Case AnatomyA Step-by-Step Guide to Building the Use-Case ModelStep 1: Identify and Describe the ActorsStep 2: Identify the Use Cases and Write a Brief DescriptionStep 3: Identify the Actor and Use-Case RelationshipsStep 4: Outline the Individual Use CasesStep 5: Refine the Use CasesOn Use Cases, Storyboarding, and User Interface DesignUse Cases and User InterfacesUse Cases and StoryboardingA Use Case Storyboard ExampleThe Case Study: The HOLIS Use CasesFind the HOLIS ActorsFind the HOLIS Use CasesAssociate the Actors and Use CasesOutline the Use CasesSummary
15. Organizing Requirements Information
Organizing Requirements of Complex Hardware and Software SystemsOrganizing Requirements for Product FamiliesOn “Future” RequirementsThe Case Study: Organizing the HOLIS RequirementsSummaryLooking Ahead
16. The Vision Document
Components of the Vision DocumentThe Delta Vision DocumentThe Vision Document for Version 1.0The Vision Document for Version 2.0The Delta Vision Document in a Legacy System EnvironmentSummary
17. Product Management
The Role of the Product ChampionThe Product Manager in a Software Product CompanyPrimary Activities for a Product ManagerDriving the VisionMaintaining the Product Road MapDefining the Whole Product PlanSponsoring the Use-Case Model and Supplementary RequirementsTesting the Product ConceptCompleting the User ExperienceDefining Commercial TermsPositioning and MessagingSupporting ActivitiesBranding and Product LabelingEnd User Training MaterialsProduct DemoSales and Marketing CollateralThe Product Champion in an IS/IT ShopSummary
Team Skill 3 Summary
4. Managing Scope
18. Establishing Project Scope
The Problem of Project ScopeThe Hard QuestionThe Requirements BaselineSetting PrioritiesAssessing EffortAdding the Risk ElementReducing ScopeA Reasonable First EstimateThe Case Study: Scope Management for HOLISSummary
19. Managing Your Customer
Engaging Customers to Manage Their Project ScopeCommunicating the ResultNegotiating with the CustomerManaging the BaselineOfficial ChangesUnofficial ChangesSummary
Team Skill 4 Summary
5. Refining the System Definition
20. Software Requirements—A More Rigorous Look
Looking Deeper into Software RequirementsThe Relationship between Software Requirements and Use CasesThe Relationship between Features and Software RequirementsThe Requirements Dilemma: What versus HowExcluding Project InformationExcluding Design InformationMore on Requirements versus DesignIterating Requirements and DesignA Further Characterization of RequirementsFunctional Software RequirementsNonfunctional Software RequirementsDesign ConstraintsSummaryLooking Ahead
21. Refining the Use Cases
How Use Cases EvolveThe Scope of a Use CaseThe Case Study: Anatomy of a Simple Use CaseReviewing the ActorsReviewing the NameRefining the DescriptionDefining and Refining the Flow of EventsIdentifying the Pre- and Post-conditionsIdentifying Special RequirementsSummary of Our Refined Use CaseExtending Use CasesIncluding Use Cases in Other Use CasesSummaryLooking Ahead
22. Developing the Supplementary Specification
The Role of the Supplementary SpecificationExpressing Functional Requirements in the Supplementary SpecificationExploring Nonfunctional RequirementsUsabilityReliabilityPerformanceSupportabilityUnderstanding Design ConstraintsSources of Design ConstraintsRestriction of Design OptionsConditions Imposed on the Development ProcessRegulations and Imposed StandardsHandling Design ConstraintsAre Design Constraints True Requirements?Identifying Other RequirementsLinking the Supplementary Specification to the Use CasesTemplate for the Supplementary SpecificationSummaryLooking Ahead
23. On Ambiguity and Specificity
Finding the “Sweet Spot”Mary Had a Little LambTechniques for DisambiguationSummary
24. Technical Methods for Specifying Requirements
PseudocodeFinite State MachinesDecision Tables and Decision TreesActivity DiagramsEntity-Relationship ModelsSummary
Team Skill 5 Summary
6. Building the Right System
25. From Use Cases to Implementation
Mapping Requirements Directly to Design and CodeThe Orthogonality ProblemObject OrientationThe Use Case as a RequirementManaging the TransitionModeling Software SystemsThe Architecture of Software SystemsThe “4+1” View of ArchitectureThe Role of the Use-Case Model in ArchitectureRealizing Use Cases in the Design ModelStructural and Behavioral Aspects of CollaborationsUsing Collaborations to Realize Sets of Individual RequirementsFrom Design to ImplementationSummaryLooking Ahead
26. From Use Cases to Test Cases
A Tester's Perspective: Musings on the Big Black BoxIs a Use Case a Test Case?Common Testing TermsRelationships of Test ArtifactsThe Role of the Test CasesUse-Case ScenariosDeriving Test Cases from Use Cases: A Four-Step ProcessStep 1: Identify the Use-Case ScenariosStep 2: Identify the Test CasesStep 3: Identify the Test ConditionsStep 4: Add Data Values to Complete the Test CaseManaging Test CoverageBlack-Box versus White-Box Testing with Use CasesSummary
27. Tracing Requirements
The Role of Traceability in Systems DevelopmentThe Traceability RelationshipA Generalized Traceability ModelTracing Requirements in the System Definition DomainTracing User Needs to FeaturesTracing Features to Use CasesTracing Features to Supplementary RequirementsTracing Requirements to ImplementationTracing Use Cases to Use-Case RealizationsTracing from the Use-Case Realization into ImplementationTracing Supplementary Requirements into ImplementationTracing from Requirements to TestingTracing from Use Case to Test CaseTracing from Supplementary Requirements to Test CasesUsing Traceability ToolsProceeding without Traceability ToolsSummary
28. Managing Change
Why Do Requirements Change?External FactorsInternal Factors“We Have Met the Enemy, and They Is Us”A Process for Managing ChangeStep 1: Recognize That Change Is Inevitable, and Plan for ItStep 2: Baseline the RequirementsStep 3: Establish a Single Channel to Control ChangeStep 4: Use a Change Control System to Capture ChangesStep 5: Manage Change HierarchicallyRequirements Configuration ManagementTool-Based Support for Change ManagementElements Impacted by ChangeAudit Trail of Change HistoryConfiguration Management and Change ManagementSummaryLooking Ahead
29. Assessing Requirements Quality in Iterative Development
Software Project QualityAssessing Quality in Iterative DevelopmentRequirements Artifacts SetsPerforming the AssessmentQuality Assessment Checklists for RequirementsSummary
Team Skill 6 Summary
Looking Ahead
Getting Started
DedicationWhat You've Learned So FarIntroductionTeam Skill 1: Analyzing the ProblemTeam Skill 2: Understanding User and Stakeholder NeedsTeam Skill 3: Defining the SystemTeam Skill 4: Managing ScopeTeam Skill 5: Refining the System DefinitionTeam Skill 6: Building the Right System
30. Agile Requirements Methods
Mitigating Requirements Risk with Effective Requirements PracticesMethodology Design GoalsPrinciple 1: Interactive, Face-to-Face Communication Is the Cheapest and Fastest Channel for Exchanging InformationPrinciple 2: Excess Methodology Weight Is CostlyPrinciple 3: Larger Teams Need Heavier MethodologiesPrinciple 4: Greater Ceremony Is Appropriate for Projects with Greater CriticalityDocumentation Is a Means to an EndAn Extreme Requirements MethodAn Agile Requirements MethodA Robust Requirements MethodSummary
31. Your Prescription for Requirements Management
Selecting Your Requirements ApproachThe Simplifying AssumptionsThe PrescriptionStep 1: Get OrganizedStep 2: Understand the Problem Being SolvedStep 3: Understand User and Stakeholder NeedsStep 4: Define the SystemStep 5: Continuously Manage Scope and Manage ChangeStep 6: Refine the System DefinitionStep 7: Build the Right SystemStep 8: Manage the Requirements ProcessStep 9: Congratulations! You've Shipped a Product!On to the Next Release!
Appendixes
A. HOLIS Artifacts
Background for the Case StudyLumenations, Ltd.The HOLIS Software Development TeamTeam Skill 1: Analyzing the ProblemLumenations Problem StatementSystem Block Diagram with Actors IdentifiedActor SurveyStakeholder SurveyConstraints Imposed on the SolutionTeam Skill 2: Understanding User and Stakeholder NeedsSummary of User Needs as Collected from InterviewsThe Requirements WorkshopThe WorkshopThe SessionThe Analysis of ResultsHOLIS System-Level Use-Case Model SurveyTeam Skill 3: Defining the SystemHOLIS Requirements OrganizationHOLIS Vision DocumentLumenations, Ltd.HOLIS Vision Document© 2002 Lumenations, Ltd. 102872 Cambridge Ave. Marcy, NJ 12345Team Skill 4: Managing ScopeTeam Skill 5: Refining the System DefinitionHOLIS Sample Use Case: Control LightBrief DescriptionBasic FlowAlternative Flow of EventsPre-conditions for Control Light Use CasePost-condition for Control Light Use CaseExtension PointsSpecial RequirementsHOLIS Central Control Unit Supplementary SpecificationTeam Skill 6: Building the Right SystemHOLIS Sample Test Case 01: Test Control LightDescriptionHOLIS Sample Test Case 02: Test Round-Trip Message ProtocolDescriptionEvents
B. Vision Document Template
Table of Contents
C. Use-Case Specification Template
Table of ContentsUse-Case NameBrief DescriptionSystem or SubSystemFlow of EventsBasic FlowAlternative FlowsSpecial RequirementsPre-conditionsPost-conditionsExtension Points
D. Supplementary Specification Template
Table of Contents
E. Requirements Management in the Rational Unified Process
The Structure of the Rational Unified ProcessRequirements Management in the Rational Unified ProcessAnalyzing the ProblemUnderstanding User and Stakeholder NeedsDefining the SystemManaging ScopeRefining the System DefinitionManaging Changing RequirementsProcess Integration
F. Requirements Management in the SEI-CMM and within ISO 9000:2000
Requirements Management in the SEI-CMMRequirements Management in ISO 9000:2000
Bibliography

Content preview from Managing Software Requirements: A Use Case Approach, Second Edition

Chapter 18. Establishing Project Scope

Key Points

Project scope is a combination of product functionality, project resources, and available time.
Brooks' law states that adding labor to a late software project makes it even later.
If the effort required to implement the system features is equal to the resources available during the scheduled time, the project has an achievable scope.
Overscoped projects are typical. In many projects, it will be necessary to reduce the scope by as much as a factor of two.
The first step in establishing project scope is to establish a high-level requirements baseline.

The Problem of Project Scope

As with any professional activity, meeting commitments in application development involves making realistic assessments of project ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Managing Software Requirements the Agile Way

Publisher Resources

ISBN: 032112247XPurchase book

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Managing Software Requirements: A Use Case Approach, Second Edition

by Dean Leffingwell, Don Widrig

Chapter 18. Establishing Project Scope

The Problem of Project Scope

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.