Agile Stories are Actually Requirements

It's popular in the Agile community to speak about User Stories and how they are?Not requirements.?

As a System Engineer, here's some background on Systems Architecture and Requirements Engineering.

Let's start with some background about Systems and their Engineering. The foundation for this approach is Systems Engineering, using Model-Based Systems Engineering.

Every system is a component of a larger system. This will take us from the lowest level up the Universe as a system. Large systems are the environment in which the component system operates.?

Systems are made up of layered sets of sub-systems and layered sets of supersystems. This layer structure defines a set of essential requirements that meet the needs of the context or environment without imposing specific implementation constraints. These requirements reflect the architectural and design decisions that satisfy the essential?requirements to provide capabilities to the system user.

Let's start with what are the characteristics of a System. People make systems. Systems have the following attributes:

• They exist for some purpose that benefits people
• They consist of components that fulfill an intended purpose through the interrelationships of their components.
• Through exchanges of information, the system interacts with its environment.
• The system must fit into an operating environment which defines the restrictions on its behavior

Back to Stories as Requirements

Let's consider Stories as components of Features and Features as components of Capabilities. We can model the evolution of software development with a hierarchy of?objects, each with an attribute.? ??

The notion that Agile Stories are NOT requirements is similar to the stalking horse of Waterfall development.

Let's look at an actual definition of a requirement from the Systems Engineering discipline point of view. There is a credible complaint between businesses and developers that the business should not be defining the design of the solution but rather stating what capabilities are needed to fulfill the business's mission. The implication is that customers and management should not be designing the solution. There are reasons for placing restrictions on the implementation, though.?

• The need to reuse previously developed software to maintain continuity of the business processes
• The need for standard components?
• The need for commonality of functions and interfaces with existing systems

These and others are the basis of?requirements constraints and impact the?evolution of the components of the system. This contradicts the naive notion that good architectures emerge from the developers. Which is counter to all good Systems Engineering Architecture principles [1], [2], and [3]

Back to the notion of requirements and User Stories

A requirement is a statement, usually in conventional narrative form, of one or more related stakeholder needs that a system must fulfill

This description narrative of a requirement comes in several forms, including:

A Primitive Requirement that is?

A statement containing enough detail for design decisions, expressible in the form on an indivisible sentence with? single verb actioning on a single object

A Performance Requirement that is a?

A statement expressing how well the system must conform with one or more Primative Requirements. Performance requirements measure respnse times, repetition rates, accuracy.

An example of this approach is the statement

The system shall calculate aircraft position at least once every 10 seconds with an accuracy of 15 meters to provide the users of the system (pilots or operators) with the ability to navigate along a desired course to a defined destination?

Those agile advocates who claim User Stories are NOT requirements may want to learn about Systems Engineering principles and how to apply them in an agile domain before making such statements.

In the Systems Engineering paradigm, Stories as requirements means stating

• Required constraints
• Required capabilities
• Performance requirements

“As a user, I need the systems to perform it’s function over the temperature range of -20℃ to +40℃ with no more than 1 failure in 2000 hrs of continuous operation"

However, we have to remember that not all systems are requirements-driven and are not driven by?formal requirements. An example is a city, where it is likely that no one sits down and writes a requirements specification and builds the city. Cities and towns emerge from a set of guidelines (building codes and urban plans) from settlements and grow into large systems, roads, and buildings. The original settlers of Manhatten Island never dreamed what their creation would evolve into. [1], pp. 27.

Resources for the Basis of Requirements and Their Description of Capabilities

[1] Systems Architecting: Creating and Building Complex Systems

[2] The Art of Systems Architecting

[3] The Timeless Way of Building

[4] Systems Thinking: Coping with 21st Centruy Problem, John Boardman and Brain Sauser

[5] Systemic Thinking: Build Maps for Worlds of Systems, John Boardman and Brian Sauser

[6] A Primer for Model-Based Systems Engineering, 2nd Edition, David Long and Zane Scott

[7] Systems Engineering Coping with Complexity, Richard Stevens, Peter Brook, Ken Jackson, and Stuart Arnold

[8] The Systems Bible, The Beginners Guide to Systems Large and Small, John Gall

[9] Systemantics: How Systems Work and Especially How They Fail, John Gall

[10] Capabilities-Based Planning for Enterprise Projects