Requirement-driven Design (RD)
(originally published on Dec 21 2015)
== “It really works” ==
- Requirement-driven Design (RD) is an initiative to provide a method and key concepts to describe and test the correctness of systems.
- Requirement-driven Design describes a system as a structured set of requirements ('features', 'behaviors') using high-level notations.
- Requirement-driven Design has both sound theoretical and strong practical bases.
Key concepts. RD focuses to:
- Requirements: a requirement describes that the system (1:) in a given context (2:) for a certain event (trigger, e.g., a user interaction) (3:) should respond in a specific way
- the given context means initialization (precondition, BDD: 'given')
- the event triggers actions ('operations', 'functions', BDD: 'when')
- the correctness of the response can be checked (postconditions, BDD: 'then')
- A requirement can be an 'invariant' (a so-called non-functional requirement) that must be hold all the time, but invariants can also be expressed using the pattern above (the 'when' is identical)
- Conversations: series of initializations/triggers/responses flows as a conversation between the system and its environment (e.g., its user), so requirements can be specified as conversations
- Examples: Conversations can be specified by examples that belongs to given types according to the systems reactions; examples fill conversational patterns and may based on generated data
- Structuring/Possibilities: the feature domain of the system can be described as branches of possibilities, that are possible types of contexts and possible trigger-events, so the systems' description can be organized into a structure (like a decision-tree)
- Multiversing: branches of specific possibilities can be organized into a 'multiverse' 'subtree', so after a specific 'multiverse' 'restart point' each possible paths of branches are executed (this solves the so-called combinatorial problem of testing)
- Requirement map: the RD description of the systems is a (decision tree-like) structure that presents the behavior of the systems; each branch is a 'gate' into a possible flow of the conversation, so the whole specification works as a map of the systems' behavior
- Living Specification: Requirement description may refer to methods to check the requirements, that means the system can be checked against the requirements.
- Validity: RD focuses to prove the validity of systems; checks may describe non-critical or critical correctness (in case of error, the conversation can be continued or has to be cut off)
- Layering: Requirements can be organized into layers (using priorities), so validity can be checked only to a specific depth
- Targeting: Validity checks can be narrowed for a given set of requirements (specifying the nodes/subtrees of the decision tree that have to be executed). In practice this means a 'Living Correctness' test, that is a real-time pointed checks of the emphasized flows.
- Business Facade: Steps of the requirement description have to be named in business terms, so Business Analyst can understand and manage the overall structure of the specification
- Living Documentation: Conversational steps can have documentation lines, so during a run an up-to-date documentation can be generated
RD covers the main concepts of the
- Behavior Driven Design (BDD)
- Test-driven Development (TDD)
- Design By Example and Specification By Example
- Development by User Stories
- Use Case Driven and Iterative methods (such as Rational Unified Process) for Requirement Capture and Testing
RD can be used with Agile and Waterfall methods, too.
The aim of the Firefly testing environment is to put RD into working practice.
The concepts of the RD mentioned above focus the external view of the system. There are also techniques to describe an internal view using a structure-event-reaction model.