Linter cleanup

Use-Case-Format.md

@@ -1,6 +1,8 @@
 
 ##### Related Documents
+
 - [SRS](SRS) > [Use Case Suite](Use-Case-Suite) > Use Case Format
+
 ---
 
 **Process impact:** This reference page documents the format of use
@@ -13,26 +15,28 @@ document. Anything you mention here will apply to all use cases in that
 file.*
 
 ---
+
 ### Aspects common to all use cases
 
-#### Direct Actors:
+**Direct Actors:**
+
 - ::User: end-user in any role
 - ::System: The system being built
 - ::When actors are not listed, assume User is doing it.
 - ::Items beginning with "see" indicate that System has presented a new screen.
 
-#### Stakeholders:
+**Stakeholders:**
 ::The user who is entering the data, and those who will read it
 
-#### Prereq:
+**Prerequisite:**
 ::Project is set up
 
-
 *TODO: Copy and paste this use case template as many times as needed in
 your [Use Cases](Use-Cases) document. Only use those fields that
 are not the same as the default for all use cases.*
 
 ---
+
 ### UC-00: USE CASE NAME
 
 **Summary:**
@@ -55,7 +59,7 @@ are not the same as the default for all use cases.*
 
 ::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER
 
-**Prereq:**
+**Prerequisite:**
 
 - ::PRECONDITION
 - ::PRECONDITION
@@ -75,30 +79,34 @@ are not the same as the default for all use cases.*
 - ::If CONDITION, then ALTERNATIVE STEPS.
   - ::NOTES or DETAILS.
 
-**Notes and Questions**
- 
+**Notes and Questions:**
+
 - ::NOTE
 - ::NOTE
 - ::QUESTION
 - ::QUESTION
 
 ---
+
 ### Format of Use Case Steps
 
 Try to start each step with one of these action words:
 
 #### login \[as ROLE or USER\]
+
 Log into the system with a given user or a user of the given type.
 Usually usually only stated explicitly when the test case involves a
 workflow between different users.
 
 #### visit LOCATION
+
 Visit a page or GUI window. State the user's intention, don't say
 too much about UI choices that could change later. E.g., WRONG:
 "Press the 'Advanced...' button on the File | Page Setup dialog".
 RIGHT: "Visit the page margin configuration dialog".
 
 #### enter INFORMATION
+
 Fill in specific information. Try to state the information in
 some detail. E.g., WRONG: "Enter customer information." RIGHT:
 "Enter customer shipping address and discount code." Don't commit to
@@ -106,6 +114,7 @@ details of a particular UI, i.e., don't name specific UI fields that
 might change later.
 
 #### COMMAND
+
 Describe a command that the user can tell the system to do. State
 the user's intent, not the label on a particular UI widget. This
 will usually be followed by a "see" step where the user sees a
@@ -113,6 +122,7 @@ confirmation of their action. E.g., WRONG: "Control-P, OK". RIGHT:
 "Print the current document with default settings".
 
 #### see CONTENT
+
 The user should see the specified information on the currently
 presented web page or GUI window. Try to be specific about the
 information that is seen, but try not to refer to specific
@@ -121,6 +131,7 @@ supposed to notice on that page?) RIGHT: "see list of users with the
 newly added user in the list".
 
 #### perform USE-CASE-NAME
+
 This is like a subroutine call. The user will do all the steps of
 the named use case and then continue on with the next step of this
 use case.