Frequently Asked Questions about PEGS

This document is an extracted chapter of the Companion book of Bertrand Meyer’s Handbook of requirements and business analysis. Some of the links, pointing to other parts of the Companion book will hence be deactivated.

We have collected in that appendix a set of questions that were often asked during the early presentations of PEGS. They are not provided in a particular order but have been grouped by main concerns.

1. Kinds of requirements and specific concepts

1.1. Multiple categories

Can a requirement belong to multiple categories (e.g., being both a limit and an invariant)?

No. If you hesitate between two or more, chose the one that makes the most sense.

1.2. Actors

How are actors identified in PEGS?

An actor is responsible of a task or a behavior, and can be represented:

As a system component (e.g., an input-output system monitoring some temperature value). It will be listed in the S.1—Components chapter.
As a human actor, we will then use the term role to refer to its responsibility in PEGS. It will be listed in the P.1—Roles and personnel chapter.
As an environment component (e.g., a data center). It will be listed in the E.2—Components chapter.

1.3. Constraints versus Imposed technical choices

How to distinguish between constraints and Imposed technical choices?

An imposed technical choice is indeed a constraint. Nevertheless it is better to separate them from the other environment constraints in a separate chapter.

We advice to systematically check constraints and find any technical choice to move them to (or make sure they are referenced in) the corresponding chapter (P.2—Imposed technical choices).

1.4. Constraints versus Assumptions

How to distinguish between constraints and assumptions?

The difference between a constraint and an assumption can sometimes seem fuzzy. It comes from the fact that the same condition can be a constraint for a certain domain (e.g., a network provider) and an assumption for another (e.g., a system developer using that network).

If an environment condition:

restricts what the implementation of the system can do: it is a constraint.
facilitates the implementation of the system: it is an assumption.

An equivalent characterization defines how the condition affects the work of the developers (defined as any people involved in the development of the system):

A constraint makes the developers’ work harder (by limiting the extent of what the system is permitted to do).
An assumption makes the developers’ work easier (by freeing the system from having to consider some cases).

The following table is a non-exhaustive list of characteristics that can help differentiate the two concepts.

Table 1. Assumption vs. Constraints
Assumptions	Constraints
Generally accepted as true without proof	Condition/restriction that limits the options/possibilities available
Typically made about the environment/project/…	Typically imposed by external factors
Usually made by the project team	Typically imposed from outside the team
Often made based on incomplete/uncertain information	Typically well-defined and clearly understood
May need to be validated	Are often justified or documented

1.5. Effect versus Functional requirement

How to distinguish between an effect and a functional requirement?

If it describes a change of property induced by the development of the whole system, it is an effect.
If the change described is brought by an individual execution (of software system or code), it is a functional requirement.

Let’s imagine a campus where classrooms are equipped with some LED display (outside of each classroom) about the scheduled courses. An example effect of the system is “the display for every classroom shall indicate the occupation schedule for the room for the current 24-hour period”. An example functional requirement (addressing that effect) is, in the specification of a scheduling operation, “update the displays for all classrooms affected by the new scheduling”.

+ TIP: Each effect requirement should be associated with at least one functional requirement.

1.6. Effect versus Expected benefits

How to distinguish between an effect and an expected benefit?

See discussions on requirements 7 in [exercises], 3-E.1.

1.7. Rationale

How are rationales managed in PEGS?

We use the term justification. In PEGS, a justification is a case of meta-requirement which corresponds to an argument explaining the reason for a property of the System or Project in terms of a Goal or of an Environment property.

1.8. Interviews and reviews

How are interviews reports and reviews managed in PEGS?

Interviews and reviews play a critical role in requirements engineering, serving as essential techniques for gathering, validating, and refining requirements (see chapter 6 of the Handbook about gathering requirements). Whatever approach is used to conduct these crucial steps for requirements engineering, it is a valuable addition to the documentation.

We consider that the best place to describe the interviews and reviews processes is the chapter P.7—Requirements process and report.

1.9. Software Architecture

Where should I describe my software architecture in PEGS?

While not fully in the scope of requirements engineering, integrating software architecture considerations can help creating a strong foundation for the development of a software system that meets both the functional and non-functional needs of stakeholders. In addition, if the system of interest either already exists or is based on an existing one, this should be described in the requirements documentation.

Here are some examples of additional details that can be added:

A UML component diagram in chapter S.1—Components or E.2—Components (whether they are internal or external)
A domain model in chapter E.1—Glossary
High-level APIs or a UML communication diagrams in chapter S.3—Interfaces
A UML activity diagram could detail some of the use case in chapter S.4—Detailed usage scenarios

1.10. Security

How do I deal with specific (or crosscutting) concerns such as Security in PEGS?

Handling specific concerns, such as security, in requirements engineering is a common practice. For security aspects, the purpose is to ensure that the software system is designed, developed, and deployed with the necessary security measures to protect against potential threats and vulnerabilities.

Most of the requirements dedicated to a particular concern (such as security) will be expressed as constraints on either the system itself (chapter E.3—Constraints) or on the development (chapter P.7—Requirement process and report). We advise to also use chapter S.5—Prioritization to emphasize on the different aspects of the system’s specific concerns. If a particular approach is dedicated to this concern, or if specific artifacts need to be produced, or if specific steps need to be validated in the process, these should be described in the P.4—Tasks and deliverables chapter.

2. Agile approach

If I want to use PEGS, but I have already an Agile process to follow, where can I define my agile key artifacts?

Requirements engineering plays a crucial role in Agile approaches such as Scrum, although its implementation and emphasis may differ from traditional waterfall methodologies. In the following we discuss some of the key concerns of Scrum and how PEGS can handle them.

Product Backlog: In Scrum, the product requirements are captured in the Product Backlog. The Product Backlog is a dynamic and prioritized list of user stories, features, enhancements, and bug fixes that need to be implemented over time. These items represent the requirements of the product. User stories are discussed in the next point due to their importance. We consider that features, enhancements, and bug fixes are development artifacts.

As such, classical product backlog artifacts do not need to be explicitly mentioned in one of the four books. Nevertheless:

a list of features would make sense in chapter S.2—Functionality, and
each artifact should refer to at least one requirement.

User Stories

Instead of detailed and exhaustive documentation of requirements, Agile methodologies use user stories (see chapter 7.2 of the Handbook). They are concise, informal descriptions of a feature from the perspective of the end-user or customer. These stories, while not being requirements as such, are an efficient way to illustrate them.

We consider that the best place to list them is the chapter S.4—Detailed usage scenarios where they might replace (or complement) use cases for example. Epic, could be listed in G.5—High-level usage scenarios.

Personas: A persona is a fictional representation of a particular user type or archetype that represent the various segments of the target audience. Personas encapsulate user characteristics, goals, needs, behaviors, and pain points.

As such, they can be detailed in a dedicated part of chapter G.7—Stakeholders and requirements sources.

Prioritization and Refinement: In agile methods, requirements are continuously prioritized based on their value and potential impact. The Product Owner (who should be listed in P.1—Roles and personnel) is responsible for maintaining and prioritizing the Product Backlog.

We advise maintaining a separate document (which might be an appendix of the requirements documentation) that prioritizes the requirements (or user stories) with their reference from the Requirements book. This allows to preserve the reference of the requirements while considering the required agility in treating them.

If not in a separate document, the chapter S.5—Prioritization can be used for this purpose, with a particular care of its versioning and dynamic nature if used in an agile context.

Sprint Planning: In Scrum, work is organized into time-bound iterations called sprints. During Sprint Planning, the team selects a set of user stories from the Product Backlog to work on in the upcoming sprint. The selected user stories are broken down into smaller tasks, helping the team better understand the requirements and estimate the work involved.

We consider that the best place to describe those plannings is the chapter P.3—Schedule and milestones (with complementary details potentially in P.4 Tasks and deliverables).

3. Goal-Oriented Requirements Engineering

Goal-oriented approaches like KAOS (Knowledge Acquisition in Automated Specification) focus on capturing and analyzing goals and their relationships to derive system requirements. It helps to ensure that the resulting system meets the intended goals and objectives of its stakeholders. Here’s how PEGS fits into these approaches.

3.1. Goal Modeling and Decomposition

Can I use Goal-Oriented Requirements Engineering (GORE) with PEGS?

In KAOS, the primary focus is on modeling goals. These goals represent the desired outcomes that stakeholders want to achieve with the system. Goals are organized hierarchically, where higher-level goals are refined into more specific sub-goals.

We consider that the best place to describe this hierarchy is the chapter G.3—Expected benefits. The systematic referencing mechanisms should also enforce the traceability between sub-goals and goals.

3.2. Responsibility Modeling

How can I represent GORE responsibilities in PEGS?

KAOS introduces the concept of agents and responsibilities. Agents are entities that can contribute to achieving goals, and responsibilities define the actions or behaviors that agents must perform to satisfy specific goals.

Agents can be listed in:

chapter G.7—Stakeholders and requirements sources, if they are human,
chapter E.2—Components if they are parts of the environment,
chapter S.1—Components if they are specific parts of the system.

Responsibilities can be specifically identified as such in chapter S.4—Detailed usage scenarios.