Business Rules - Software Engineering

This document lists the fundamental business rules of the Software Engineering domain, identified with a unique BR-NNN code. Each rule is technology-independent and describes an invariant constraint on the software development process.

---

BR-001 - Every FeatureRequest becomes a traceable Requirement

Code: BR-001 Name: A FeatureRequest is translated into a Requirement with acceptance criteria Description: Every feature request is analysed and translated into a clear, verifiable Requirement with explicit acceptance criteria, before entering the Backlog. An ambiguous requirement, or one without acceptance criteria, is not ready for development. Motivation: Avoid ambiguity and rework; make every unit of work verifiable. Priority: HIGH Actors: Product Owner, Developer Traceability: glossary "Acceptance Test"; events/domain-events.md event RequirementCreated; BC-01.

---

BR-002 - New code is covered by tests

Code: BR-002 Name: Every completed UserStory includes adequate automated tests Description: Code that implements a behaviour is accompanied by unit and, where needed, integration tests. Coverage is meaningful (it tests real behaviour, not just lines). TDD is the preferred practice for new behaviour. Motivation: Prevent regressions and enable safe refactoring. Priority: HIGH Actors: Developer, Tester Traceability: glossary "Test-Driven Development (TDD)", "Unit Test", "Integration Test"; BR-005.

---

BR-003 - Every change passes through code review

Code: BR-003 Name: No code is integrated without a peer review Description: Every implemented UserStory must pass code review before merge. The review verifies correctness, readability, adherence to principles (SOLID), absence of code smells and test coverage. Motivation: Improve quality, share knowledge and reduce defects. Priority: HIGH Actors: Developer Violation: merge blocked until the review is approved. Traceability: glossary "Code Smell", "SOLID", "Refactoring"; state-machines/user-story-lifecycle.md code-review state.

---

BR-004 - Dependency direction respects Clean Architecture

Code: BR-004 Name: Business logic does not depend on infrastructure details Description: In the Codebase, the domain does not depend on frameworks, databases or UI: the dependency arrow points inward. Business logic is pure and testable in isolation (Dependency Injection, Inversion of Control). Motivation: Keep the domain testable, replaceable and technology-independent. Priority: CRITICAL Actors: Developer Traceability: glossary "Clean Architecture", "Dependency Injection (DI)", "Inversion of Control (IoC)", "Pure Function".

---

BR-005 - The build must stay green

Code: BR-005 Name: A failed build blocks integration until restored Description: The Codebase maintains Continuous Integration with always-green build and tests on the main branch. A commit that breaks the build (BuildFailed) has immediate fix priority; no new work is integrated on a broken build. Motivation: Guarantee an always-releasable main branch. Priority: HIGH Actors: Developer, Tester Violation: BuildFailed; the main branch is frozen until the build returns green. Traceability: glossary "Continuous Integration (CI)"; events/domain-events.md event BuildFailed.

---

BR-006 - The SprintGoal is the commitment unit

Code: BR-006 Name: Every sprint pursues a SprintGoal with a selected Backlog Description: Development is organised into iterations with a goal (SprintGoal) and a set of UserStory selected from the priority-ordered Backlog. The sprint scope is protected: new requests go to the backlog, not the in-progress sprint. Motivation: Guarantee focus, predictability and incremental delivery of value. Priority: MEDIUM Actors: Product Owner, Scrum Master, Developer Traceability: glossary "Bounded Context"; events/domain-events.md event SprintStarted.

---

BR-007 - Technical debt is tracked and managed

Code: BR-007 Name: Every introduced Technical Debt is recorded and planned Description: Implementation shortcuts (code smells, duplication, insufficient coverage) are made visible as technical debt, assessed and placed in the Backlog. No invisible debt accumulates that degrades the QualityMetric. Motivation: Keep the codebase maintainable over time. Priority: HIGH Actors: Developer, Product Owner Traceability: glossary "Technical Debt", "Refactoring"; events/domain-events.md event TechnicalDebtRecorded.

---

BR-008 - A release ships from a green, tested branch

Code: BR-008 Name: A ReleaseShipped comes only from a codebase with green build and tests Description: A release is produced from a Codebase state with green CI, adequate coverage and semantic versioning. Breaking changes increment the MAJOR version; the release is traceable to the requirements it satisfies. Motivation: Guarantee reliable and traceable releases. Priority: HIGH Actors: Developer, Scrum Master Traceability: glossary "Semantic Versioning (SemVer)", "Backward Compatibility"; events/domain-events.md event ReleaseShipped.