Modeling & Executable Specifications
GreenMethod uses models and executable specifications selectively, as tools to remove ambiguity where written description alone is insufficient.
Modeling is not treated as a mandatory phase or a documentation deliverable in its own right. It is applied when it meaningfully improves shared understanding, decision-making, or delivery confidence.
Purpose of Modeling
Models are used to clarify structure, flow, and responsibility boundaries.
Typical purposes include:
explaining how a system or process is expected to behave
aligning stakeholders with different perspectives
making implicit assumptions visible
supporting discussion and decision-making
Models are created to be understood, not to demonstrate notation proficiency.
Use of UML and Visual Models
UML and similar visual models are applied where they provide clarity that text alone cannot.
Common use cases include:
high-level process flows
responsibility and interaction boundaries
lifecycle overviews
dependency relationships
Models are kept intentionally high-level. They avoid tool-specific detail, configuration data, or implementation-level constructs.
Diagrams complement documentation artefacts; they do not replace them.
Executable Specifications and BDD
In situations where system behavior is central to understanding, GreenMethod applies Behavior-Driven Development (BDD) principles to express expectations in a precise, structured form.
BDD is used to:
describe behavior from a business perspective
reduce ambiguity in requirements and acceptance criteria
align business and technical stakeholders on expected outcomes
Executable specifications are written in clear, readable language and focus on what should happen, not how it is implemented.
Role of Cucumber
The open-source tool Cucumber is used as a specification and structuring aid.
Within this context, Cucumber serves to:
impose consistency on behavioral descriptions
make assumptions and outcomes explicit
support traceability between intent and implementation
Whether scenarios are automated or remain as living documentation depends on the nature of the project. Automation is optional; clarity is not.
Relationship Between Models and Delivery
Models and executable specifications are used to support delivery, not to delay it.
They are introduced:
when uncertainty is high
when multiple interpretations exist
when behavior must be agreed before implementation
Once their purpose is fulfilled, they are maintained only as long as they remain useful.
Governance and Approval
Models and executable specifications that influence scope, behavior, or delivery approach are subject to the same approval and decision management principles as other documentation artefacts.
Approval confirms shared understanding, not technical correctness.
Practical Restraint
Not every project requires modeling or executable specifications.
Where documentation and analysis are straightforward, written descriptions are sufficient and preferred. Modeling is applied deliberately, not habitually.
This restraint ensures that effort is spent where it adds real value.
Design Principle
Models exist to answer questions.
When the question has been answered and understanding is shared, the model has done its job.