GFM changes

Design-UI.md

@@ -54,11 +54,11 @@ text as needed.*
 
 #### What types of users will use this system?
 
-::See the [user needs document](user-needs).
+::See the [user needs document](User-Needs).
 
 #### What types of tasks will those users perform?
 
-::See the [use case suite](use-case-suite).
+::See the [use case suite](Use-Case-Suite).
 
 ### Content Model / Interaction Contexts
 

Feature-Format.md

@@ -94,3 +94,10 @@ Notes and Questions:
   - A "risk factor" is a task or fact that is currently in doubt,
     but that must turn out well in order for the feature to be
     successfully implemented. See tips on managing risk below.
+
+### Further Information
+
+For more information on advice, see:
+
+Words of wisdom on [feature sets](http://readyset.tigris.org/words-of-wisdom/feature-set.html).
+Words of wisdom on [feature specifications](http://readyset.tigris.org/words-of-wisdom/features.html).

Feature-Set.md

@@ -23,14 +23,13 @@ early.
 *TODO: Before writing individual feature descriptions, list all the
 features that you think you will need. Organize them so that missing
 features appear as blanks on this page, and extra features will appear
-to be extras that don't fit anywhere. See the [feature
-format](feature-format#checklist) document for more tips on
-specifying features and feature sets.*
+to be extras that don't fit anywhere. See the 
+[feature format](Feature-Format#further-information) document for more 
+tips on specifying features and feature sets.*
 
-*TIP: Refer back to the user stories in your [user
-needs](user-needs) document and to the [use case
-suite](use-case-suite). Use them for ideas and make sure that you
-cover all of them.*
+*TIP: Refer back to the user stories in your [user needs](User-Needs) 
+document and to the [use case suite](Use-Case-Suite). 
+Use them for ideas and make sure that you cover all of them.*
 
 ### Features by Release and Priority
 

SRS.md

@@ -42,7 +42,7 @@
 **Process impact:** The SRS precisely defines the software product that
 will be built. Decisions made in writing the SRS are based on
 information in the [project proposal](proposal) and [user
-needs](user-needs) documents. The SRS sets requirements that must
+needs](User-Needs) documents. The SRS sets requirements that must
 be satisfied by the [system design](design). The SRS is verified
 and validated by activities outlined in the [QA plan](qa-plan.html).
 

Use-Case-Suite.md

@@ -29,7 +29,7 @@
 ::X.Y.Z
 
 ##### Related Documents:
-- [Project proposal](proposal) > [User needs](user-needs)
+- [Project proposal](proposal) > [User needs](User-Needs)
 - [SRS](SRS) > [Feature set](feature-set)
 - [Use case format](use-case-format)
 - ::LINK TO USE CASE DIAGRAM
@@ -50,7 +50,7 @@ visible blanks on this page if you are missing use cases. E.g., see
 show below.*
 
 *TIP: Refer back to the user stories in your [user
-needs](user-needs) document. Use them for ideas and make sure that
+needs](User-Needs) document. Use them for ideas and make sure that
 you cover all of them. Remember that use cases are more precise than
 user stories, and there may be several use cases for a given user story.*
 

Use-ases.md

@@ -19,7 +19,7 @@
 <xmp theme="readable" style="display:none;">
 <!-- Markdown content here -->
 
-# [SRS](SRS) > [Use Case Suite](use-case-suite) > Use Cases
+# [SRS](SRS) > [Use Case Suite](Use-Case-Suite) > Use Cases
 ---
 
 ##### Project:
@@ -58,7 +58,7 @@ note it's specific value to replace or add to the default.*
 ::User is logged in
 
 *TODO: For each use case listed in the [use case
-suite](use-case-suite), create an HTML anchor and heading with it's
+suite](Use-Case-Suite), create an HTML anchor and heading with it's
 unique ID, then fill in the rows of the table to specify the use case in
 detail.*