Change: use definition list for requirements

1 files changed, 45 insertions, 32 deletions

diff --git a/fable-arch.md b/fable-arch.md
index 532ab3a..6c63b7f 100644
--- a/fable-arch.md
+++ b/fable-arch.md
@@ -104,38 +104,51 @@ Fable](#acceptance).
 Each requirement here is given a unique mnemnoic id for easier
 reference in discussions.
 
-* **UnderstadableTests:** Acceptance tests should be possible to express in
-  a way that's easily understood by non-programmers.
-
-* **EasyToWriteDocs:** The markup language for writing documentation
-  should be easy to write.
-
-* **AidsComprehension:** The formatted human-readable documentation
-  should use good layout and typography to enhance comprension.
-
-* **CodeSeparately:** The code to implement the acceptance tests
-  should not be embedded in the documentation source, but be in
-  separate files. This makes it easier to edit without specialised
-  tooling.
-
-* **AnyProgammingLanguage:** The developers implementing the
-  acceptance tests should be free to use a language they're familiar
-  and comfortable with. Fable should not require them to use a
-  specific language.
-
-* **FastTestExecution:** Executing the acceptance tests should be
-  fast.
-
-* **NoDeployment:** The acceptance test tooling should assume the
-  system under test is already deployed and available. Deploying is
-  too big of a problem space to bring into the scope of acceptance
-  testing, and there are already good tools for deployment.
-
-* **MachineParseableResults:** The tests should produce a machine
-  parseable result that can be archived, post-processed, and analyzed
-  in ways that are of interest to the project using Fable. For
-  example, to see trends in how long tests take, how often tests fail,
-  to find regressions, and to find tests that don't provide value.
+**UnderstadableTests**
+
+: Acceptance tests should be possible to express in a way that's
+  easily understood by non-programmers.
+
+**EasyToWriteDocs**
+
+: The markup language for writing documentation should be easy to
+  write.
+
+**AidsComprehension**
+
+: The formatted human-readable documentation should use good layout
+  and typography to enhance comprension.
+
+**CodeSeparately**
+
+: The code to implement the acceptance tests should not be embedded in
+  the documentation source, but be in separate files. This makes it
+  easier to edit without specialised tooling.
+
+**AnyProgammingLanguage**
+
+: The developers implementing the acceptance tests should be free to
+  use a language they're familiar and comfortable with. Fable should
+  not require them to use a specific language.
+
+**FastTestExecution**
+
+: Executing the acceptance tests should be fast.
+
+**NoDeployment**
+
+: The acceptance test tooling should assume the system under test is
+  already deployed and available. Deploying is too big of a problem
+  space to bring into the scope of acceptance testing, and there are
+  already good tools for deployment.
+
+**MachineParseableResults**
+
+: The tests should produce a machine parseable result that can be
+  archived, post-processed, and analyzed in ways that are of interest
+  to the project using Fable. For example, to see trends in how long
+  tests take, how often tests fail, to find regressions, and to find
+  tests that don't provide value.
 
 # Fable architecture