Requirements-Led Project Management: Discovering David's Slingshot

Hardcover (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $2.50
Usually ships in 1-2 business days
(Save 94%)
Other sellers (Hardcover)
  • All (7) from $2.50   
  • New (1) from $105.00   
  • Used (6) from $2.50   
Close
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any BN.com coupons and promotions
$105.00
Seller since 2014

Feedback rating:

(178)

Condition:

New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Page 1 of 1
Showing All
Close
Sort by

Overview

Requirements are a crucial ingredient of any successful project. This is true for any product—software, hardware, consumer appliance, or large-scale construction. You have to understand its requirements—what is needed and desired—if you are to build the right product. Most developers recognize the truth in this statement, even if they don't always live up to it.

Far less obvious, however, is the contribution that the requirements activity makes to project management. Requirements, along with other outputs from the requirements activity, are potent project management tools.

In Requirements-Led Project Management, Suzanne and James Robertson show how to use requirements to manage the development lifecycle. They show program managers, product and project managers, team leaders, and business analysts specifically how to:

  • Use requirements as input to project planning and decision-making
  • Determine whether to invest in a project
  • Deliver more appropriate products with a quick cycle time
  • Measure and estimate the requirements effort
  • Define the most effective requirements process for a project
  • Manage stakeholder involvement and expectations
  • Set requirements priorities
  • Manage requirements across multiple domains and technologies
  • Use requirements to communicate across business and technological boundaries

In their previous book, Mastering the Requirements Process, the Robertsons defined Volere—their groundbreaking and now widely adopted requirements process. In this second book, they look at the outputs from the requirements process and demonstrate how you can take advantage of the all-important links between requirements and project success.

Read More Show Less

Product Details

  • ISBN-13: 9780321180629
  • Publisher: Addison-Wesley
  • Publication date: 8/20/2004
  • Edition description: New Edition
  • Pages: 327
  • Product dimensions: 7.64 (w) x 9.88 (h) x 1.15 (d)

Meet the Author

James Robertson

Suzanne Robertson and James Robertson have, over many years, helped hundreds of companies improve their requirements techniques and move into the fast lane of system development. Their courses and seminars on requirements, analysis, and design are widely praised for their innovative approach. The Robertsons are principals of the Atlantic Systems Guild, a well-known consultancy specializing in the human dimensions of complex system building. They are also the coauthors of Requirements-Led Project Management (Addison-Wesley, 2005).

James Robertson and Suzanne Robertson have, over many years, helped hundreds of companies improve their requirements techniques and move into the fast lane of system development. Their courses and seminars on requirements, analysis, and design are widely praised for their innovative approach. The Robertsons are principals of the Atlantic Systems Guild, a well-known consultancy specializing in the human dimensions of complex system building. They are also the coauthors of Requirements-Led Project Management (Addison-Wesley, 2005).

Read More Show Less

Read an Excerpt

Overture

We explain how requirements and their successful management are inextricably linked to project success.

Through the years your authors have participated in and observed many projects, both successful and otherwise. A factor present in every successful project and absent in every unsuccessful project is sufficient attention to requirements. The "requirements," as we use the term, means having knowledge of the functionality and the qualitative properties the product must have, as well as constraints that affect the product.

It does not matter what the product is. Our clients in electronics, aviation, automotive, pharmaceutical, government, and software have all found the same thing: Requirements must be correctly understood before the right product can be built. Requirements are the way of communicating between the people who commission a product on behalf of anticipated users and builders of that product. The requirements are usually communicated in the form of a text document, a set of models, or both, according to the nature and needs of the particular project.

We believe it is self-evident you must know the requirements before being able to construct the right product and that many projects are aware of this even when they do not specifically practice it.

However, less awareness exists of the contribution requirements make to the managing of a project. Our experience is many project managers make less than optimum use of requirements.

For example, one of the outputs from the requirements activity is a context model. Requirements analysts build this model to define the precise scope of their study, then proceed to use it to determine the business use cases. But this is not just an analysis model—it contains enough information for a project manager to measure the size of the task and to make accurate estimates of the needed effort. Similarly, the requirements analysts go through a process to identify all the stakeholders who have requirements for the project. By simply counting these stakeholders and looking at the requested interview durations, it is possible to schedule resources.

The project manager's intention is to deliver a product that satisfies (or perhaps enthralls!) the customer. We refer to this as a project success indicator and will discuss these in the first chapter. The requirements activity, as we set it out in this book, suggests you make use of project sociology analysis to ensure you have the right people on the requirements team, you use appropriate elicitation methods, you invent parts of the product (some of our most useful products are pure inventions), and add a customer value to each of the requirements. These are all major contributors to building a product to satisfy your customer, yet we sometimes see project managers short-change this activity in the hope of saving time to delivery. It never does save time and the product is always heavily (and expensively) modified before the customers find any use for it. Alternatively, the project manager who spends too much time on the requirements activity (yes, it can be done) is naturally wasting resources that can be better used elsewhere.

We aim to show you here how to effectively gather the requirements (Chapter 4), how much time you should be spending on your requirements (Chapter 11), and, fundamentally, whether or not you should be investing in building the product in the first place (Chapter 2).

Most important, we aim to show you the potential of requirements activity. Like David's slingshot, this relatively simple tool in the right hands can produce results far beyond its cost. We also hope it equips you to tame a few giants for yourself.

Development of Volere

Formalizing the link between requirements and project management has taken some time and many, many projects. We started toward this goal in 1995 when we posted the first edition of the Volere Requirements Specification Template on our Web sites. The template is a framework for gathering and recording the different types of requirements-related knowledge. We wanted a formality for specifying atomic requirements, grouping them into business and product-related chunks and making them traceable throughout the project. We also wanted the flexibility of having requirements in a variety of forms and of choosing (according to the specific situation) when to gather detail, and how much. Since then, tens of thousands of people have downloaded the template. We originally developed Volere with software products in mind, but our requirements template and process have been adopted by people in projects as diverse as restoring old churches, designing motor vehicles, labelling pharmaceuticals, air traffic control, planning business procedures, and designing phones. After all, a requirement is a requirement regardless of whether it is for software, hardware, organizational procedures, consumer products, or anything else that someone wants or needs.

We have added the feedback from Volere users around the world along with our own practical experiences in consulting and teaching to develop and refine our approach. Part of the Volere approach is a generic process for gathering and communicating requirements. This is proving effective as shown by the thousands of organizations scattered throughout the world who are using adaptations of this process for their requirements gathering.

Volere (Vol-Air-Ray) is the Italian verb for "to wish or to want." We have used the word as the name for our work on requirements (template, process, tools, training, audits, and clinics). You can find more information at our requirements Web site at www.volere.co.uk.

This Book

This book is about the contribution requirements make to the success of development projects. The book is intended for you if you are connected with the development of software or hardware or consumer products or services. You probably have the word "manager," or "leader" or something similar as part of your job title.

The book references some requirements-gathering techniques. We are not attempting to tell you how to perform these; we assume you already have some familiarity with them. When we talk about the requirements activities, we do so in light of how they contribute to project management, and project success. This book is about how to make better use of requirements and how to use the products of requirements as a management tool that contributes to project success.

During the course of this book we will show you

  • How a quick cycle time can deliver more appropriate products.
  • The most effective requirements process for your project.
  • How to use the requirements as a way of discovering stakeholders and managing their involvement.
  • The best way of progressively prioritizing requirements and managing expectations.
  • How you can quantify customer value and concentrate on satisfying the most valuable requirements.
  • How to manage requirements across multi-domain/scope/technology projects.
  • How you can measure and communicate requirements progress.
  • How you can use requirements as input to project management planning and decision making.
  • How you can use requirements to communicate across business and technological boundaries.

The book also has insights for business analysts. However, it is neither an introductory book nor a techniques book. Our previous effort, Mastering the Requirements Process, is recommended if you are looking for a "how to" book on requirements analysis. In this book we are looking beyond the technicalities of the requirements process to justify the effort needed to discover requirements, to show how to get stakeholder commitment, to measure the effort needed, and to show you how to exploit the all-important links between requirements and project success.

Our intention is to provide practical ways of using requirements to contribute to your project's success. We feel we will have succeeded if your next project runs a lot more smoothly, your communication with stakeholders is more effective, you can react more quickly to changes, you can quantify the improvements, and you enjoy it more.

Read More Show Less

Table of Contents

1 Requirements and project success 1
2 Requirements value 21
3 Project sociology 45
4 Learning what people need 79
5 Inventing requirements 113
6 Requirements simulations 135
7 Requirements for existing systems 163
8 Measuring requirements 183
9 Managing the requirements 207
10 Requirements meta-management 243
11 Your requirements process 255
App. A Requirements knowledge model 289
App. B Volere requirements specification template 301
Read More Show Less

Preface

Overture

We explain how requirements and their successful management are inextricably linked to project success.

Through the years your authors have participated in and observed many projects, both successful and otherwise. A factor present in every successful project and absent in every unsuccessful project is sufficient attention to requirements. The "requirements," as we use the term, means having knowledge of the functionality and the qualitative properties the product must have, as well as constraints that affect the product.

It does not matter what the product is. Our clients in electronics, aviation, automotive, pharmaceutical, government, and software have all found the same thing: Requirements must be correctly understood before the right product can be built. Requirements are the way of communicating between the people who commission a product on behalf of anticipated users and builders of that product. The requirements are usually communicated in the form of a text document, a set of models, or both, according to the nature and needs of the particular project.

We believe it is self-evident you must know the requirements before being able to construct the right product and that many projects are aware of this even when they do not specifically practice it.

However, less awareness exists of the contribution requirements make to the managing of a project. Our experience is many project managers make less than optimum use of requirements.

For example, one of the outputs from the requirements activity is a context model. Requirements analysts build this model to define the precise scope of their study, then proceed to use it todetermine the business use cases. But this is not just an analysis model--it contains enough information for a project manager to measure the size of the task and to make accurate estimates of the needed effort. Similarly, the requirements analysts go through a process to identify all the stakeholders who have requirements for the project. By simply counting these stakeholders and looking at the requested interview durations, it is possible to schedule resources.

The project manager's intention is to deliver a product that satisfies (or perhaps enthralls!) the customer. We refer to this as a project success indicator and will discuss these in the first chapter. The requirements activity, as we set it out in this book, suggests you make use of project sociology analysis to ensure you have the right people on the requirements team, you use appropriate elicitation methods, you invent parts of the product (some of our most useful products are pure inventions), and add a customer value to each of the requirements. These are all major contributors to building a product to satisfy your customer, yet we sometimes see project managers short-change this activity in the hope of saving time to delivery. It never does save time and the product is always heavily (and expensively) modified before the customers find any use for it. Alternatively, the project manager who spends too much time on the requirements activity (yes, it can be done) is naturally wasting resources that can be better used elsewhere.

We aim to show you here how to effectively gather the requirements (Chapter 4), how much time you should be spending on your requirements (Chapter 11), and, fundamentally, whether or not you should be investing in building the product in the first place (Chapter 2).

Most important, we aim to show you the potential of requirements activity. Like David's slingshot, this relatively simple tool in the right hands can produce results far beyond its cost. We also hope it equips you to tame a few giants for yourself.

Development of Volere

Formalizing the link between requirements and project management has taken some time and many, many projects. We started toward this goal in 1995 when we posted the first edition of the Volere Requirements Specification Template on our Web sites. The template is a framework for gathering and recording the different types of requirements-related knowledge. We wanted a formality for specifying atomic requirements, grouping them into business and product-related chunks and making them traceable throughout the project. We also wanted the flexibility of having requirements in a variety of forms and of choosing (according to the specific situation) when to gather detail, and how much. Since then, tens of thousands of people have downloaded the template. We originally developed Volere with software products in mind, but our requirements template and process have been adopted by people in projects as diverse as restoring old churches, designing motor vehicles, labelling pharmaceuticals, air traffic control, planning business procedures, and designing phones. After all, a requirement is a requirement regardless of whether it is for software, hardware, organizational procedures, consumer products, or anything else that someone wants or needs.

We have added the feedback from Volere users around the world along with our own practical experiences in consulting and teaching to develop and refine our approach. Part of the Volere approach is a generic process for gathering and communicating requirements. This is proving effective as shown by the thousands of organizations scattered throughout the world who are using adaptations of this process for their requirements gathering.

Volere (Vol-Air-Ray) is the Italian verb for "to wish or to want." We have used the word as the name for our work on requirements (template, process, tools, training, audits, and clinics). You can find more information at our requirements Web site at www.volere.co.uk.

This Book

This book is about the contribution requirements make to the success of development projects. The book is intended for you if you are connected with the development of software or hardware or consumer products or services. You probably have the word "manager," or "leader" or something similar as part of your job title.

The book references some requirements-gathering techniques. We are not attempting to tell you how to perform these; we assume you already have some familiarity with them. When we talk about the requirements activities, we do so in light of how they contribute to project management, and project success. This book is about how to make better use of requirements and how to use the products of requirements as a management tool that contributes to project success.

During the course of this book we will show you


  • How a quick cycle time can deliver more appropriate products.
  • The most effective requirements process for your project.
  • How to use the requirements as a way of discovering stakeholders and managing their involvement.
  • The best way of progressively prioritizing requirements and managing expectations.
  • How you can quantify customer value and concentrate on satisfying the most valuable requirements.
  • How to manage requirements across multi-domain/scope/technology projects.
  • How you can measure and communicate requirements progress.
  • How you can use requirements as input to project management planning and decision making.
  • How you can use requirements to communicate across business and technological boundaries.

The book also has insights for business analysts. However, it is neither an introductory book nor a techniques book. Our previous effort, Mastering the Requirements Process, is recommended if you are looking for a "how to" book on requirements analysis. In this book we are looking beyond the technicalities of the requirements process to justify the effort needed to discover requirements, to show how to get stakeholder commitment, to measure the effort needed, and to show you how to exploit the all-important links between requirements and project success.

Our intention is to provide practical ways of using requirements to contribute to your project's success. We feel we will have succeeded if your next project runs a lot more smoothly, your communication with stakeholders is more effective, you can react more quickly to changes, you can quantify the improvements, and you enjoy it more.



0321180623P08022004
Read More Show Less

Introduction

Overture

In which we explain how requirements, and their successful management, are inextricably linked to project success.

Over the years your authors have participated in and observed many projects, both successful and otherwise. One of the factors that has been present in every successful project, and absent in every unsuccessful project, is sufficient attention being paid to the requirements. The requirements, as we use the term here, mean having knowledge of the functionality and the qualitative properties that the product must have, and of the constraints that affect the product.

It does not matter what the product is. Our clients in electronics, aviation, automotive, pharmaceutical, government and software have all found the same thing: that the requirements must be correctly understood before the right product can be built. The requirements are the way of communicating between the people who commission a product on behalf of the expected users, and the builders of that product. The requirements are usually communicated in the form of a text document or a set of models, or both, according to the nature and needs of the particular project.

We believe that it is self-evident that you must know the requirements before being able to construct the right product, and that many projects are aware of this even when they do not specifically practice it.

There is however less awareness of the contribution that requirements make to the managing of a project. It is our experience that many project managers make less than optimum use of requirements.

For example, one of the outputs from the requirements activity is a context model. Therequirements analysts build this model to define the precise scope of their study, and then go on to use it to determine the business use cases. But this is not just an analysis model - it contains enough information for a project manager to measure the size of the task and to make accurate estimates of the needed effort. Similarly the requirements analysts go through a process to identify all the stakeholders who have requirements for the project. By simply counting these stakeholders and looking at the requested interview durations, it is possible to schedule resources.

The project manager's intention is to deliver a product that satisfies (or perhaps enthrals) his customer. We refer to this as a project success indicator and will discuss these in the next chapter. The requirements activity, as we set it out in this book, suggests that you make use of project sociology analysis to ensure that you have the right people on the requirements team, that you use appropriate elicitation methods, that you invent parts of the product (some of our most useful products are pure inventions), and add a customer value to each of the requirements. These are all major contributors to building a product to satisfy your customer, and yet we sometimes see project managers short-changed this activity in the hope of saving time to delivery. It never does save time, and the product is always heavily (and expensively) modified before the customers find any use for it. Alternatively, the project manager who spends too much time on the requirements activity (yes, it can be done) is naturally wasting resources that could be better used elsewhere.

We aim to show you here how to effectively gather the requirements (Chapter 4) much time you should be spending on your requirements (Chapter 11), and importantly, whether or not your should be investing in building the product in the first place (Chapter 2).

Most importantly, we aim to show you the potential of the requirements activity. Like David's slingshot, this relatively simple tool, when in the right hands, can produce results far beyond its cost. We also hope it equips you to tame a few giants for yourself.

Development of Volere

To formalize the link between requirements and project management has taken some time and many, many projects. We started towards this goal in 1995 when we posted the first edition of the Volere requirements specification template on our web sites. The template is a framework for gathering and recording the different types of requirements-related knowledge. We wanted a formality for specifying atomic requirements, grouping them into business and product-related chunks and making them traceable throughout the project. We also wanted the flexibility of having requirements in a variety of forms and of choosing (according to the specific situation) when and how much detail to gather. Since then, tens of thousands of people have downloaded the template. We originally developed Volere with software products in mind, but our requirements template and process have been adopted by people in projects as diverse as restoring old churches, designing motor vehicles, labelling pharmaceuticals, air traffic control, planning business procedures and designing phones. After all, a requirement is a requirement regardless of whether it is for software, hardware, organisational procedures, consumer products or anything else that someone wants or needs.

Volere (Vol-Air-Ray) is the Italian verb for to wish or to want. We have used the word as the name for our work on requirements (template, process, tools, training, audits and clinics). You can find more information at our requirements Web site.

We have added the feedback from Volere users around the world along with our own practical experiences in consulting and teaching to develop and refine our approach. Part of the Volere approach is a generic process for gathering and communicating requirements. This is proving effective as shown by the thousands of organisations scattered throughout the world who are using adaptations of this process for their requirements gathering.

This Book

This book is about the contribution that requirements make to the success of development projects. The book is intended for you if you are connected with the development of software or hardware or consumer products or services. You probably have the word manager or leader or similar as part of your job title.

The book will reference some requirements gathering techniques. We are not attempting to tell you how to do these; we assume that you already have some familiarity with them. When we are talking about the requirements activities, we will do so in the light of how they contribute to project management, and project success. This book is about how to make better use of requirements and how to use the products of requirements as a management tool that will contribute to project success.

During the course of this book we will show you:

  • How a quick cycle time can deliver more appropriate products.
  • The most effective requirements process for your project.
  • How to use the requirements as a way of discovering stakeholders and managing their involvement.
  • The best way of progressively prioritising requirements and managing expectations.
  • How you can quantify customer value, and concentrate on satisfying the most valuable requirements.
  • How to manage requirements across multi-domain/scope/technology projects.
  • How you can measure and communicate requirements progress.
  • How you can use requirements as input to project management planning and decision-making.
  • How you can use requirements to communicate across business and technological boundaries.

The book also has insights for business analysts. However, it is neither an introductory book nor a techniques book. Our previous effort Mastering the Requirements Process is recommended if you are looking for a "how to" book on requirements analysis. In this book we are looking beyond the technicalities of the requirements process to justify the effort needed to discover requirements, to show how to get stakeholder commitment, to measure the effort needed, and to show you how to exploit the all-important links between requirements and project success.

Our intention is to provide practical ways of using requirements to contribute to your project's success. We feel that we will have succeeded if your next project runs a lot more smoothly, your communication with stakeholders is more effective, you can react more quickly to changes, you can quantify the improvements, and you enjoy it more.

James Robertson and Suzanne Robertson
London, March 2004



Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing 1 Customer Reviews
  • Anonymous

    Posted October 25, 2004

    innovate

    The authors are from Britain and often make references to British companies in the book. So I was surprised and amused to see a photo of a tablecloth they'd scribbled on with ideas. It was from the Crocodile Cafe in Pasadena, Los Angeles. A restaurant I'd also often been to. Small world?! The book has one key chapter. On inventing. Everything else is secondary. The authors discuss how you should strive to see what makes your company unique compared to its competitors. What is its core competence? Or your own, for that matter. Does your company offer a quicker response to customer queries? A quicker delivery time? An easier ordering process? They encourage you to think up new advantages. And to do this continually. They suggest that brainstorming once a month or less is not really brainstorming. Ditto for prototyping new gadgets or features. Innovation needs constant intellectual exercising. This chapter is clearly the most hazy and frustrating of the entire book. So intangible compared to the other chapters, which describe processes that can be straightforwardly implemented. But this chapter is also the most valuable. Your ability to innovate faster than your competitors may ultimately be the only real advantage you have. By the way, the book refers to eBay and says 'Meg Whitman [the CEO] had the very simple inspiration of putting auctions on the Internet'. Not so. It was the founder, Pierre Omidyar, who conceived of this. When Whitman came on board, eBay was already conducting these auctions.

    Was this review helpful? Yes  No   Report this review
Sort by: Showing 1 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)