What do you think?
Rate this book
Handbook of Requirements and Business Analysis
Meyer’s Handbook of Requirements and Business Analysis is a comprehensive treatise providing the reader with all the principles and techniques necessary to produce effective requirements.
Even the best design, implementation and verification are worthless if they are the solution to the wrong problem. Defining the problem properly is the task of requirements, also known as business analysis. To be successful, a project must apply to requirements the same engineering standards as to other parts of system construction.
The Handbook presents a holistic view of requirements including four elements or Project, Environment, Goals and System. One of its principal contributions is the definition of a Standard Plan for requirements documents, consisting of the four corresponding books and replacing the structure of the obsolete IEEE 1998 standard.
The text covers both classical requirements techniques and advanced topics. The successive chapters concepts and definitions; requirements principles; the Standard Plan for requirements; how to write good requirements; how to gather requirements; scenario techniques (use cases, user stories); object-oriented requirements; how to take advantage of formal methods; abstract data types; and the place of requirements in the software lifecycle.
The Handbook is suitable both as a practical guide for industry and as a textbook, with over 50 exercises and supplementary material available from the book’s site, including slides and links to video lectures (MOOCs).
Even the best design, implementation and verification are worthless if they are the solution to the wrong problem. Defining the problem properly is the task of requirements, also known as business analysis. To be successful, a project must apply to requirements the same engineering standards as to other parts of system construction.
The Handbook presents a holistic view of requirements including four elements or Project, Environment, Goals and System. One of its principal contributions is the definition of a Standard Plan for requirements documents, consisting of the four corresponding books and replacing the structure of the obsolete IEEE 1998 standard.
The text covers both classical requirements techniques and advanced topics. The successive chapters concepts and definitions; requirements principles; the Standard Plan for requirements; how to write good requirements; how to gather requirements; scenario techniques (use cases, user stories); object-oriented requirements; how to take advantage of formal methods; abstract data types; and the place of requirements in the software lifecycle.
The Handbook is suitable both as a practical guide for industry and as a textbook, with over 50 exercises and supplementary material available from the book’s site, including slides and links to video lectures (MOOCs).
Kindle Edition
Published July 30, 2022
5 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 2 of 2 reviews
October 1, 2025
This is an interesting, thoughtful book with many provocative insights on Requirements Engineering. According to the author’s preface, the chapters cover:
In Chapter 2 (Requirements: General Principles), the author insists on the need to write requirements before designing or coding, on their evolutionary nature, and on the need to be forwards and backwards traceable, that is to:
In Chapter 5 (How to write requirements), Meyers distills years of experience into very pertinent recommendations, ending the chapter by analyzing a small, but fruitful case study from text processing.
Chapter 6 (How to gather requirements) is a brief introduction to requirements elicitation which overviews such key aspects as assessing stakeholders, conducting effective interviews, and workshops. The reader would do well to complement this chapter with more detailed business analysis textbooks covering the area -Meyer provides some interesting starting points in the final bibliographical notes section of the chapter.
In Chapter 7 (Scenarios: use cases, user stories), Meyer shows his reservations about use cases and user stories, bluntly asserting:
I found chapter 11 (Are my requirements complete) uncharacteristically confusing. Meyer does provide several definitions of what it means for requirements to be complete. Perhaps the most intriguing one is goal-completeness defined as:
Chapter 12 (Requirements in the software lifecycle) is not a concluding chapter, but paradoxically, an opening one. It “rescues”(Meyer’s word!) aspects of the waterfall, spiral, RUP, and agile models, focusing on when and how to deal with requirements, in order to propose a new model, called the PEGS model, based on seamless, concurrent development of “clusters”(subsystems). An interesting idea, but one which requires another book to exemplify convincingly.
The book includes pointers to further material on which key exercises are based. Unfortunately, many of these pointers lead nowhere or the material originally included there has disappeared. This includes Bettina Bair’s example requirements document used in key exercises in several chapters of the book, As of 2025, I found the companion web pages to the book disappointing and incomplete -for example the published link to the templates for writing requirements by Jean-Michel Bruel referenced at https://se.inf.ethz.ch/requirements/s... has been deleted by the owner.
Meyer focuses on the fundamental concepts underlying requirements and quality criteria for requirements, which are particularly useful for analyzing requirements. The book’s coverage of ethical value-based goals, non-functional systems requirements, crowd-based Requirement Engineering, and some of the more process-based aspects of Requirements Engineering is skimpy at best. However, Bertrand Meyer’s analytical and writing skills, his experience, and his ability to cut through a complex subject to distill key observations and suggestions make this a fascinating book to read and reflect on.
1: A precise definition of requirements concepts, and a classification of requirement kinds.In the preface, Meyer quite rightly criticizes some IEEE and ISO definitions of requirements and requirements elicitation; in chapter 1, he provides a carefully crafted definition of requirements. From the start of chapter 1, he distinguishes four kinds of requirements: Project, Environment, (business) Goals, and System ( abbreviated as PEGS) requirements:
2: A discussion of general requirements principles.
3: A Standard Plan applicable to the requirements of any project.
4: A review of the quality attributes for requirements and associated verification criteria.
5: Precise guidelines on how to write effective requirements.
6: A description of how to obtain requirements, a process known as elicitation.
7: A discussion of use cases and other scenario-based requirements techniques.
8: A presentation of the object-oriented approach to requirements.
9: An introduction to formal requirements, using mathematical rigor for precision.
10: An important kind of formal specification, abstract data types.
11: What it means for requirements to be “complete”, and how to achieve this goal.
12: How to make requirements a core part of the project lifecycle.
- A goal is a result desired by an organization.He meticulously explains what the PEGS requirements are, clearly distinguishing special cases of goals such as obstacles, environment constraints such as business rules, laws of nature, prefixed engineering decisions, assumptions (posited properties of the environment), effects (environment property affected by the system), and , invariants (an environment property that must be maintained). He also distinguishes between functional and non-functional system requirements, as is to be expected, and provides an explicitly incomplete list of non-functional requirements, namely,
- A system is a set of related artifacts, devised to help meet certain goals.
- A project is the set of human processes involved in the planning, construction, operation and revision of a system.
- An environment is the set of entities (such as people, organizations, devices and other material objects, regulations, and other systems) external to the project and system but with the potential to affect the goals, project or system or to be affected by them.
… properties of performance (timing properties on operations, parameters of storage use or bandwidth), security, and privacy.I also liked his definition of a requirements level justification:
Explanation of a project or system property in reference to a goal or environment property.The first chapter also provides a correct definition of stakeholders as:
...the groups of people recognized by the project as having the potential to affect, or be affected by, the project, environment, goals or system.Meyer’s analytic framework of requirements is a key contribution of the book.
In Chapter 2 (Requirements: General Principles), the author insists on the need to write requirements before designing or coding, on their evolutionary nature, and on the need to be forwards and backwards traceable, that is to:
Record all the consequences of the requirements on the project and system.Chapter 3 (Standard Plan for Requirements) proposes organizing the requirements into four “books”, one for each PEGS setting out the “chapters” for each book in a straightforward and attractive way. For example, the Project Book should contain the following chapters:
Record the requirements sources of project and system elements.
P.1 Roles and personnelwhile the Goals Book cleaves to most Business Analysis frameworks to include chapters on:
P.2 Imposed technical choices
P.3 Schedule and milestones
P.4 Tasks and deliverables
P.5 Required technology elements
P.6 Risk and mitigation analysis
P.7 Requirements process and report
G.1 Context and overall objectiveChapter 4 (Requirements quality and verification) is one of the key chapters in the book and prescribes fourteen assessable quality criteria for requirements: Correct, Traceable, Justified, Delimited, Complete, Readable, Consistent, Modifiable Unambiguous, Verifiable, Feasible, Prioritized, Abstract, and Endorsed.
G.2 Current situation
G.3 Expected benefits
G.4 Functionality overview
G.5 High-level usage scenarios
G.6 Limitations and exclusions
G.7 Stakeholders and requirements sources
In Chapter 5 (How to write requirements), Meyers distills years of experience into very pertinent recommendations, ending the chapter by analyzing a small, but fruitful case study from text processing.
Chapter 6 (How to gather requirements) is a brief introduction to requirements elicitation which overviews such key aspects as assessing stakeholders, conducting effective interviews, and workshops. The reader would do well to complement this chapter with more detailed business analysis textbooks covering the area -Meyer provides some interesting starting points in the final bibliographical notes section of the chapter.
In Chapter 7 (Scenarios: use cases, user stories), Meyer shows his reservations about use cases and user stories, bluntly asserting:
Use cases and user stories cannot by themselves define requirements. Several reasons make them insufficient for that purpose.Even though he describes INVEST user stories, he is not sanguine about their use as requirements. However he does recommend user cases and user stories as techniques for requirements elicitation:
Note first that scenarios only apply — out of the four PEGS — to the System and to the Goals. They bring nothing to the specification of the Project and Environment.
Take advantage of use cases, user stories, use case slices, tests and other forms of scenarios as tools for elicitation and verification of requirements.Meyer believes there are some important deficiencies in use cases and user stories and devotes the next three chapters to proposing, in their stead, object-oriented requirements (chapter 8), formal methods (chapter 9), and object-oriented requirements based on abstract-data types as models (chapter 10). He also claims that such an approach allows the requirements to be written in the same language as the code, showing how this would look in Eiffel. These are provocative statements and I am not entirely convinced by the chapters. Of course, looking at object-oriented requirements in the sense Mayer presents them, harks back to EER modeling, so it is not unreasonable and certainly has a distinguished history. Such an object-oriented perspective is also related to UML-modeling, but where UML is born from an attempt at integrating several diagrams and models such as use cases, EER-based class diagrams, an object constraint language (OCL) and automata into the same framework, Meyer strives to substitute the multiple UML diagrams and models with the high-level mechanisms available in Eiffel. The idea certainly merits further, more detailed analysis and I, for one, look forward to the announced companion to this book, Jean-Michel Bruel, Sophie Ebersold and Mariya Naumcheva’s Effective Requirements: Complete Examples and Practical Material. According to Meyer, the book was to be published in 2022, but a search on the Springer website (October 1st 2025) reveals it is due to be published on November 16th 2025 under a changed title, Applying Requirements and Business Analysis.
Do not use them as a substitute for actual requirements specifications.
I found chapter 11 (Are my requirements complete) uncharacteristically confusing. Meyer does provide several definitions of what it means for requirements to be complete. Perhaps the most intriguing one is goal-completeness defined as:
A set of requirements is goal-complete if for every goal there exist project or system requirements ensuring the achievement of that goal.. However although traceability certainly helps determine if a goal has been linked to project or system requirements, determining whether achievement of those project or system requirements ensure that a particular goal would be met is an entirely different kettle of fish. Suppose one of the goals is to ensure an organization’s revenue increase by 20% after the first six months of system operation -only by implementing the system, operating it and measuring revenue after six months of operations can one know whether the target has been met.
Chapter 12 (Requirements in the software lifecycle) is not a concluding chapter, but paradoxically, an opening one. It “rescues”(Meyer’s word!) aspects of the waterfall, spiral, RUP, and agile models, focusing on when and how to deal with requirements, in order to propose a new model, called the PEGS model, based on seamless, concurrent development of “clusters”(subsystems). An interesting idea, but one which requires another book to exemplify convincingly.
The book includes pointers to further material on which key exercises are based. Unfortunately, many of these pointers lead nowhere or the material originally included there has disappeared. This includes Bettina Bair’s example requirements document used in key exercises in several chapters of the book, As of 2025, I found the companion web pages to the book disappointing and incomplete -for example the published link to the templates for writing requirements by Jean-Michel Bruel referenced at https://se.inf.ethz.ch/requirements/s... has been deleted by the owner.
Meyer focuses on the fundamental concepts underlying requirements and quality criteria for requirements, which are particularly useful for analyzing requirements. The book’s coverage of ethical value-based goals, non-functional systems requirements, crowd-based Requirement Engineering, and some of the more process-based aspects of Requirements Engineering is skimpy at best. However, Bertrand Meyer’s analytical and writing skills, his experience, and his ability to cut through a complex subject to distill key observations and suggestions make this a fascinating book to read and reflect on.
September 19, 2024
Handbook of Requirements and Business Analysis
by Meyer
Contents:
PREFACE
1: Requirements: basic concepts and definitions
2: Requirements: general principles
3: Standard Plan for requirements
4: Requirements quality and verification
5: How to write requirements
6: How to gather requirements
7: Scenarios: use cases, user stories
8: Object-oriented requirements
9: Benefiting from formal methods
10: Abstract data types
11: Are my requirements complete?
12: Requirements in the software lifecycle
------------------------------------------------------------------------------
REQUIREMENTS...
The oldest, shortest words - 'yes' and 'no' - are those that require the most thought.
~ Pythagoras
In product development and process optimization, a requirement is a singular documented physical or functional need that a particular design, product, or process aims to satisfy.
It is commonly used in a formal sense in engineering design, including for example in systems engineering, software engineering, or enterprise engineering. It is a broad concept that could speak to any necessary (or sometimes desired) function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder.
Requirements can come with different levels of specificity; for example, a requirement specification or requirement "spec" (often imprecisely referred to as "the" spec/specs, but there are actually different sorts of specifications) refers to an explicit, highly objective/clear (and often quantitative) requirement (or sometimes, set of requirements) to be satisfied by a material, design, product, or service.
A set of requirements is used as inputs into the design stages of product development.
Requirements are also an important input into the verification process since tests should trace back to specific requirements.
Requirements show what elements and functions are necessary for the particular project. When iterative methods of software development or agile methods are used, the system requirements are incrementally developed in parallel with design and implementation.
With the waterfall model requirements are developed before design and implementation.
The term requirement has been in use in the software engineering community since at least the 1960s.
According to the Guide to the Business Analysis Body of Knowledge® version 2 from IIBA (BABOK), a requirement is:
1: A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
2: A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
3: A documented representation of a condition or capability as in (1) or (2).
This definition is based on IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology.
------------------------------------------------------------------------------
BUSINESS ANALYSIS...
“More often than not, the most significant asset may not be on the balance sheet.”
~Naved Abdali
Business analysis is a professional discipline focused on identifying business needs and determining solutions to business problems.
Solutions may include a software-systems development component, process improvements, or organizational changes, and may involve extensive analysis, strategic planning, and policy development.
A person dedicated to carrying out these tasks within an organization is called a business analyst or BA.
Business analysts are not found solely within projects for developing software systems. They may also work across the organization, solving business problems in consultation with business stakeholders. Whilst most of the work that business analysts do today relates to software development/solutions, this is due to the ongoing massive changes businesses all over the world are experiencing in their attempts to digitize.
Although there are different role definitions, depending upon the organization, there does seem to be an area of common ground where most business analysts work.
The responsibilities appear to be:
1: To investigate business systems, taking a holistic view of the situation.
This may include examining elements of the organization's structures and staff development issues as well as current processes and IT systems.
2: To evaluate actions to improve the operation of a business system.
Again, this may require an examination of organizational structure and staff development needs, to ensure that they are in line with any proposed process redesign and IT system development.
3: To document the business requirements for the IT system support using appropriate documentation standards.
In line with this, the core business analyst role could be defined as an internal consultancy role that has the responsibility for investigating business situations, identifying and evaluating options for improving business systems, defining requirements, and ensuring the effective use of information systems in meeting the needs of the business.
by Meyer
Contents:
PREFACE
1: Requirements: basic concepts and definitions
2: Requirements: general principles
3: Standard Plan for requirements
4: Requirements quality and verification
5: How to write requirements
6: How to gather requirements
7: Scenarios: use cases, user stories
8: Object-oriented requirements
9: Benefiting from formal methods
10: Abstract data types
11: Are my requirements complete?
12: Requirements in the software lifecycle
------------------------------------------------------------------------------
REQUIREMENTS...
The oldest, shortest words - 'yes' and 'no' - are those that require the most thought.
~ Pythagoras
In product development and process optimization, a requirement is a singular documented physical or functional need that a particular design, product, or process aims to satisfy.
It is commonly used in a formal sense in engineering design, including for example in systems engineering, software engineering, or enterprise engineering. It is a broad concept that could speak to any necessary (or sometimes desired) function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder.
Requirements can come with different levels of specificity; for example, a requirement specification or requirement "spec" (often imprecisely referred to as "the" spec/specs, but there are actually different sorts of specifications) refers to an explicit, highly objective/clear (and often quantitative) requirement (or sometimes, set of requirements) to be satisfied by a material, design, product, or service.
A set of requirements is used as inputs into the design stages of product development.
Requirements are also an important input into the verification process since tests should trace back to specific requirements.
Requirements show what elements and functions are necessary for the particular project. When iterative methods of software development or agile methods are used, the system requirements are incrementally developed in parallel with design and implementation.
With the waterfall model requirements are developed before design and implementation.
The term requirement has been in use in the software engineering community since at least the 1960s.
According to the Guide to the Business Analysis Body of Knowledge® version 2 from IIBA (BABOK), a requirement is:
1: A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
2: A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
3: A documented representation of a condition or capability as in (1) or (2).
This definition is based on IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology.
------------------------------------------------------------------------------
BUSINESS ANALYSIS...
“More often than not, the most significant asset may not be on the balance sheet.”
~Naved Abdali
Business analysis is a professional discipline focused on identifying business needs and determining solutions to business problems.
Solutions may include a software-systems development component, process improvements, or organizational changes, and may involve extensive analysis, strategic planning, and policy development.
A person dedicated to carrying out these tasks within an organization is called a business analyst or BA.
Business analysts are not found solely within projects for developing software systems. They may also work across the organization, solving business problems in consultation with business stakeholders. Whilst most of the work that business analysts do today relates to software development/solutions, this is due to the ongoing massive changes businesses all over the world are experiencing in their attempts to digitize.
Although there are different role definitions, depending upon the organization, there does seem to be an area of common ground where most business analysts work.
The responsibilities appear to be:
1: To investigate business systems, taking a holistic view of the situation.
This may include examining elements of the organization's structures and staff development issues as well as current processes and IT systems.
2: To evaluate actions to improve the operation of a business system.
Again, this may require an examination of organizational structure and staff development needs, to ensure that they are in line with any proposed process redesign and IT system development.
3: To document the business requirements for the IT system support using appropriate documentation standards.
In line with this, the core business analyst role could be defined as an internal consultancy role that has the responsibility for investigating business situations, identifying and evaluating options for improving business systems, defining requirements, and ensuring the effective use of information systems in meeting the needs of the business.
Displaying 1 - 2 of 2 reviews