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. 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 super systems. This layers 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 needed to provide capabilities to the user of the system
Let's start with what are the characteristics of a System. Systems are made by people. Systems have the following attributes:
- They exist for some purpose that benefits people
- They consist of components that fulfill an intended purpose through 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
If we 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 business and developers, that the business should not be defining the design of the solution, but rather stating what capabilities are needed to fulfill a mission of the business. The implication is that customers and management have 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 is counter to 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 that 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.
- 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"
But we have to remember not all systems are requirements-driven, are not driven by formal requirements. An example is a city, where it is likely that no one actually 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 and 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