Communications of the ACM
A Standard Plan for Modern Requirements
The PEGS approach: time to use a plan for specifying 21st century IT systems
Requirements documents for software projects in industry, agile or not, typically follow a plan defined in a 1998 IEEE standard (IEEE 830-1998 [1]), "reaffirmed" in 2009. IEEE 830 has the merit of simplicity, as it fits in 37 pages of which just a few (competently) describe basic requirements concepts and less than 10 are devoted to explaining the standard recommended plan, which itself consists of 3 sections with subsections. Simplicity is good but the elementary nature of the IEEE-830 plan is just not up to the challenges of modern information technology. It is time to retire this venerable precursor and move to a structure that works for the kind of ambitious, multi-faceted IT systems we build today.
For the past few years I have worked on defining a systematic approach to requirements, culminating in a book to be published in the Fall, Handbook of Requirements and Business Analysis. One of the results of this effort is a standard plan, based on the "PEGS" view of requirements where the four parts cover Project, Environment, Goals and System. The details are in the book (for some of the basic concepts see a paper at TOOLS 2019, [2]). Here I will introduce some of the key principles, since they are already be used -- as various people have done since I first started presenting the ideas in courses and seminars (particularly an ACM Webinar, organized by Will Tracz last March, whose recording is available on YouTube, and another hosted by Grady Booch for IBM).
The starting point, which gives its name to the approach, is that requirements should cover the four aspects mentioned, the four "PEGS", defined as follows:
- A Goal is a result desired by an organization.
- 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, revision and operation 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.
The recommended standard plan consequently consists of four parts or books.
This proposed standard does not prescribe any particular approach to project management, software development, project lifecycle or requirements expression, and is applicable in particular to both traditional ("waterfall") and agile projects. It treats requirements as a project activity, not necessarily a lifecycle step. One of the principles developed in the book is that requirements should be treated as a dynamic asset of the project, written in a provisional form (more or less detailed depending on the project methodology) at the beginning of the project, and then regularly extended and updated.
Similarly, the requirements can be written using any appropriate notation and method, from the most informal to the most mathematical. In a recently published ACM Computing Surveys paper [3], my colleagues and I reviewed the various levels of formalism available in today's requirements approaches. The standard plan is agnostic with respect to this matter.
The books may reference each other but not arbitrarily. The permitted relations are as follows: