More About Software Requirements Thorny Issues and Practical Advice

by Wiegers, Karl

• ISBN13: 9780735622678
• ISBN10: 0735622671
• Edition: 1st
• Format: Paperback
• Copyright: 2005-12-20
• Publisher: Microsoft Press

Summary

No matter how much instruction you've had on managing software requirements, there's no substitute for experience. Too often, lessons about requirements engineering processes lack the no-nonsense guidance that supports real-world solutions. Complementing the best practices presented in his book, Software Requirements, Second Edition, requirements engineering authority Karl Wiegers tackles even more of the real issues head-on in this book.With straightforward, professional advice and practical solutions based on actual project experiences, this book answers many of the tough questions raised by industry professionals. From strategies for estimating and working with customers to the nuts and bolts of documenting requirements, this essential companion gives developers, analysts, and managers the cosmic truths that apply to virtually every software development project.Discover how to: Make the business case for investing in better requirements practices Generate estimates using three specific techniques Conduct inquiries to elicit meaningful business and user requirements Clearly document project scope Implement use cases, scenarios, and user stories effectively Improve inspections and peer reviews Write requirements that avoid ambiguity

Author Biography

Karl E. Wiegers is a leading speaker, author, and consultant on requirements engineering, project management, and process improvement. As Principal Consultant with Process Impact, he conducts training seminars for corporate and government clients worldwide. Karl has twice won the Software Development Productivity Award, which honors excellence in productivity-enhancing products and books.

Table of Contents

Preface	xiii
Part I On Essential Requirements Concepts
Requirements Engineering Overview	3	(8)
``Requirement'' Defined	3	(1)
Different Types of Requirements	4	(3)
Business Requirements	5	(1)
User Requirements	5	(1)
Functional Requirements	6	(1)
System Requirements	6	(1)
Business Rules	7	(1)
Quality Attributes	7	(1)
External Interfaces	7	(1)
Constraints	7	(1)
Requirements Engineering Activities	7	(2)
Looking Ahead	9	(2)
Cosmic Truths About Software Requirements	11	(10)
Requirements Realities	11	(3)
Requirements Stakeholders	14	(2)
Requirements Specifications	16	(5)
Part II On the Management View of Requirements
The Business Value of Better Requirements	21	(8)
Tell Me Where It Hurts	21	(2)
What Can Better Requirements Do for You?	23	(2)
The Investment	25	(1)
The Return	26	(2)
An Economic Argument	28	(1)
How Long Do Requirements Take?	29	(4)
Industry Benchmarks	29	(1)
Your Own Experience	30	(1)
Incremental Approaches	31	(1)
Planning Elicitation	32	(1)
Estimating Based on Requirements	33	(18)
Some Estimation Fundamentals	33	(2)
Estimation Approaches	35	(2)
Goals Aren't Estimates	37	(1)
Estimating from Requirements	37	(1)
Measuring Software Size	38	(2)
Story Points	40	(1)
Use Case Points	41	(4)
Testable Requirements	45	(2)
The Reality of Estimation	47	(4)
Part III On Customer Interactions
The Myth of the On-Site Customer	51	(6)
User Classes and Product Champions	51	(2)
Surrogate Users	53	(1)
Now Hear This	54	(3)
An Inquiry, Not an Inquisition	57	(12)
But First, Some Questions to Avoid	57	(2)
Questions for Eliciting Business Requirements	59	(1)
User Requirements and Use Cases	60	(2)
Questions for Eliciting User Requirements	62	(3)
Open-Ended Questions	65	(1)
Why Ask Why?	66	(3)
Two Eyes Aren't Enough	69	(8)
Improving Your Requirements Reviews	69	(8)
Part IV On Use Cases
Use Cases and Scenarios and Stories, Oh My!	77	(8)
Use Cases	77	(2)
Scenarios	79	(3)
User Stories	82	(3)
Actors and Users	85	(4)
When Use Cases Aren't Enough	89	(14)
The Power of Use Cases	89	(1)
Project Type Limitations	90	(1)
Event-Response Tables	91	(2)
Use Cases Don't Replace Functional Requirements	93	(3)
Use Cases Reveal Functional Requirements	96	(7)
Part V On Writing Requirements
Bridging Documents	103	(2)
How Much Detail Do You Need?	105	(8)
Who Makes the Call?	105	(2)
When More Detail Is Needed	107	(1)
When Less Detail Is Appropriate	108	(2)
Implied Requirements	110	(1)
Sample Levels of Requirements Detail	110	(3)
To Duplicate or Not to Duplicate	113	(4)
Cross-Referencing	114	(1)
Hyperlinks	114	(1)
Traceability Links	115	(1)
Recommendation	116	(1)
Elements of Requirements Style	117	(12)
I Shall Call This a Requirement	117	(2)
System Perspective or User Perspective?	119	(1)
Parent and Child Requirements	120	(1)
What Was That Again?	121	(8)
Complex Logic	121	(1)
Negative Requirements	122	(2)
Omissions	124	(1)
Boundaries	125	(1)
Avoiding Ambiguous Wording	126	(3)
The Fuzzy Line Between Requirements and Design	129	(8)
Solution Ideas and Design Constraints	130	(1)
Solution Clues	131	(6)
Part VI On the Requirements Process
Defining Project Scope	137	(10)
Vision and Scope	137	(1)
Context Diagram	138	(2)
Use Case Diagram	140	(1)
Feature Levels	141	(2)
Managing Scope Creep	143	(4)
The Line in the Sand	147	(6)
The Requirements Baseline	148	(1)
When to Baseline	149	(4)
The Six Blind Men and the Requirements	153	(12)
Limitations of Natural Language	154	(1)
Some Alternative Requirements Views	154	(3)
Why Create Multiple Views?	157	(2)
Selecting Appropriate Views	159	(2)
Reconciling Multiple Views	161	(4)
Part VII On Managing Requirements
Handling Requirements for Multiple Releases	165	(6)
Single Requirements Specification	166	(1)
Multiple Requirements Specifications	167	(1)
Requirements Management Tools	168	(3)
Business Requirements and Business Rules	171	(6)
Business Requirements	171	(1)
Business Rules	172	(1)
Business Rules and Software Requirements	173	(4)
Measuring Requirements	177	(6)
Product Size	177	(1)
Requirements Quality	178	(1)
Requirements Status	179	(1)
Requests for Changes	180	(1)
Effort	181	(2)
Exploiting Requirements Management Tools	183	(6)
Write Good Requirements First	183	(1)
Expect a Culture Change	184	(1)
Choose a Database-Centric or Document-Centric Tool	184	(1)
Don't Create Too Many Requirement Types or Attributes	185	(1)
Train the Tool Users	186	(1)
Assign Responsibilities	186	(1)
Take Advantage of Tool Features	186	(3)
References	189	(6)
Index	195