Format markdown

Words-of-Wisdom-Architecture.md

@@ -1,27 +1,51 @@
 # Design Architecture
 
-Line-by-line Instructions
-What are the most important facts that a developer should know about this system architecture?
+## Line-by-line Instructions
+
+### What are the most important facts that a developer should know about this system architecture?
+
 Write 2-4 bullets or sentences that summarize the architecture. Focus on the main concept, and anything that has changed or that developers are likely to misunderstand without documentation.
-What software architecture style is being used?
+
+### What software architecture style is being used?
+
 Name the software architecture style that best describes your system.
-What are the ranked goals of this architecture?
+
+### What are the ranked goals of this architecture?
+
 Consider how the sample goals relate to your project. Add, edit, or delete goals to fit your project. Rank them from most important to least important. Explicitly stating your goals will help you make and evaluate your decisions later.
-What are the components of this system?
+
+### What are the components of this system?
+
 Link to UML component diagrams or list the major components of the system.
-How will the components be deployed to processes and machines?
+
+### How will the components be deployed to processes and machines?
+
 Outline each possible type of deployment configuration. Some products will have only one possible deployment, while others will have a few common deployments for large, medium, and small customers, or for internal (development, testing, and staging) or external (production) usage.
-What aspects/resources of their environment are shared?
+
+### What aspects/resources of their environment are shared?
+
 List resources that are shared between machines. Shared resources are potential system bottlenecks that limit scalability, and they are also points where one component of the system can potentially interfere with another component (e.g., one component completely fills a shared disk and causes other components to fail).
-How are requests allocated to redundant or load-balanced servers?
+
+### How are requests allocated to redundant or load-balanced servers?
+
 Describe your load balancing strategy.
-What alternative deployment configurations are possible?
+
+### What alternative deployment configurations are possible?
+
 If you only described one deployment configuration above, list variants here.
-How will components be integrated? Specifically, how will they communicate?
+
+### How will components be integrated? Specifically, how will they communicate?
+
 Describe your choice of inter-process communication mechanism.
-What architectural mechanisms are being used to ease future extensions or modifications?
+
+### What architectural mechanisms are being used to ease future extensions or modifications?
+
 List points in the architecture where future components can be plugged in. This may be points in the source code or in the run-time system.
-Architectural Scenarios
+
+### Architectural Scenarios
+
 Work through the steps of system-wide scenarios such as starting up the system, shutting it down, restarting it, and upgrading the system.
-Architecture Checklist
+
+### Architecture Checklist
+
 Use this checklist to help evaluate your architectural design decisions with respect to your stated goals. If any question cannot be answered positively, go back and revise the design.

Words-of-Wisdom-Demo-Script.md

@@ -1,19 +1,35 @@
-# Demo Script
+# Demo-script
+
+## Line-by-line Instructions
+
+### Who is the target audience for this demo?
 
-Line-by-line Instructions
-Who is the target audience for this demo?
 Briefly describe the audience for this demo. Understanding your demo audience will help you choose key points that are relevant to that audience.
-What is your main goal for this demo?
+
+### What is your main goal for this demo?
+
 Write 2-4 sentences describing your goal for this demo. Explicitly stating your goal will help you choose key points that are relevant to that goal.
-What main points will you use to achieve your goal?
+
+### What main points will you use to achieve your goal?
+
 Give 2-4 bullets describing the main points that you will make to achieve your goal. Do not consider the context or order of presentation of these points yet, instead list them in order of importance to you.
-How much time is available to present the demo?
+
+### How much time is available to present the demo?
+
 Note down the amount of time that you expect this demo to last. Knowing the time limit will help you choose how many points and how much contextual information to include.
-What equipment and setup is needed to give the demo?
+
+### What equipment and setup is needed to give the demo?
+
 List the equipment and setup that you will use in this demo. Sometimes available equipment is a constraint on the demo. E.g., is it difficult to clearly show how two users would collaborate if you only have one laptop for the demo.
-Demo Script
+
+### Demo Script
+
 Fill in the steps of the demo, using the sample text as a guide. Write the steps in enough detail that any sales engineer could give the demo.
-Anticipated Questions
+
+### Anticipated Questions
+
 List common customer questions and your best answers. Write the answers in enough detail that any sales engineer could give use them. Use this list to help make sure that all sales engineers give consistent answers. Add to this list over time as you gain more experience from giving this demo.
-Demo Checklist
+
+### Demo Checklist
+
 Try to answer each question in the checklist. Unclear or negative answers indicate that you should go back and revise the demo script until you are satisfied.

Words-of-Wisdom-Design-Overview.md

@@ -1,15 +1,27 @@
 # Design
 
-Line-by-line Instructions
-How is this design document organized?
+## Line-by-line Instructions
+
+### How is this design document organized?
+
 INSTRUCTIONS
-What are the most important facts that a developer should know about this design?
+
+### What are the most important facts that a developer should know about this design?
+
 INSTRUCTIONS
-What are the prioritized goals of this design?
+
+### What are the prioritized goals of this design?
+
 INSTRUCTIONS
-UML Structural Design
+
+### UML Structural Design
+
 INSTRUCTIONS
-UML Behavioral Design
+
+### UML Behavioral Design
+
 INSTRUCTIONS
-UML Design Checklist
+
+### UML Design Checklist
+
 INSTRUCTIONS

Words-of-Wisdom-FAQ-and-Troubleshooting.md

@@ -1,5 +1,7 @@
 # FAQ
 
-Line-by-line Instructions
-Questions and Answers
+## Line-by-line Instructions
+
+### Questions and Answers
+
 The goal of the FAQ is to minimize technical support calls. The set of questions and answers ultimately must be driven by the actual questions and concerns of users. You can anticipate questions ahead of time based on your knowledge of the product and the sample text in the template. Long FAQ's with dozens of questions and answers are definitely usable, so long as the questions and answers are organized into logical sections.

Words-of-Wisdom-Implementation-Notes.md

@@ -1,15 +1,27 @@
 # Implementation Notes
 
-Line-by-line Instructions
-Type of Implementation
+## Line-by-line Instructions
+
+### Type of Implementation
+
 This prompt asks you to briefly describe the most general information about the implementation of the system. The point of writing this information is so that an operations engineer who needs to investigate a problem in a running system can quickly decide whether the problem is likely to be serviceable or not. The information in this section may also be useful to another developer who is considering reusing this software as part of another product.
-Runtime Environment
+
+### Runtime Environment
+
 List the processes, config files, databases, data files, temporary files, and log files that are involved in normal system operation. This information is useful to operations engineers who need to quickly decide whether some observed system behavior is normal or not normal. It is also likely to be useful to other developers who may reuse this software.
-Implementation of Specific Features
+
+### Implementation of Specific Features
+
 Write brief descriptions of any surprizing or critical feature implementations. These are not descriptions of how to use the feature or why it is in the product, rather they should describe how the feature works. As with the sections above, this information can help an operations engineer understand the behavior of the system or help another developer during reuse.
-Operational Procedures
+
+### Operational Procedures
+
 These are step by step instructions for common tasks that the operations engineers may need to do.
-Security
+
+### Security
+
 List things that the operations engineers should do to keep the system secure.
-Performance and Scalability
+
+### Performance and Scalability
+
 List things that the operations engineers should do to keep the operating up to its full capacity.

Words-of-Wisdom-Installation-and-Quick-Start.md

@@ -1,21 +1,39 @@
 # Install
 
-Line-by-line Instructions
-Release Number
+## Line-by-line Instructions
+
+### Release Number
+
 Clearly identify the release that these instructions apply to. Otherwise, if users have multiple versions of your product, it is possible that they will confuse different versions of the installation document.
-Customer Support
+
+### Customer Support
+
 Clearly indicate the user's technical support options.
-Introduction
+
+### Introduction
+
 Give a very brief description of this release.
-Minimal System Requirements
+
+### Minimal System Requirements
+
 The minimal system requirements are stated in the release notes.
+
 Customization: you may prefer to write the minimal system requirements into these installation instructions and remove it from the release notes.
-What other software must be installed first?
+
+### What other software must be installed first?
+
 List prerequisite software that must be installed before your product can be installed.
-How do I install PRODUCT-NAME?
+
+### How do I install PRODUCT-NAME?
+
 Write the installation steps here. The steps should be written in enough detail that an actual user can follow them. You must test the installation process with actual users before shipping the release. Users who have difficulty installing the product can generate expensive calls to technical support.
-How can I uninstall PRODUCT-NAME?
+
+### How can I uninstall PRODUCT-NAME?
+
 Likewise, write the uninstall steps in enough detail for a user to actually follow.
-Getting Started
+
+### Getting Started
+
 It can be a good idea to show users how to perform a very simple tasks to prove to themselves that the product is properly installed and working. For example, the Apache webserver will show a default page that simply indicates that the server is up and working.
+
 Customization: you may choose to simply refer to the getting started section of the userguide.

Words-of-Wisdom-Legal-Issues.md

@@ -1,9 +1,15 @@
 # Legal
 
-Line-by-line Instructions
-Ownership of Intellectual Property
+## Line-by-line Instructions
+
+### Ownership of Intellectual Property
+
 List the items of intellectual property that your team is creating or reusing. For each item that you create, make sure to protect it. For each item that you reuse, make sure that you comply with the relevant terms.
-Regulatory Compliance
+
+### Regulatory Compliance
+
 Identify regulations that apply to your project and track your compliance with them. Regulations can come from the government, industry trade groups, or corporate policies.
-Legal Issues Checklist
+
+### Legal Issues Checklist
+
 Use this checklist to help check your work in the legal issues document. If there is any question that you cannot answer postively, that indicates a remaining legal issue that still needs to be addressed.

Words-of-Wisdom-Persistence.md

@@ -1,39 +1,75 @@
 # Design Persistence
 
-Line-by-line Instructions
-What are the most important facts that a developer should know about persistent data storage in this system?
+## Line-by-line Instructions
+
+### What are the most important facts that a developer should know about persistent data storage in this system?
+
 Write a few sentences or bullets indicating the most important aspects of your persistence design. Describe key decisions that are difficult for new developers to understand or that have changed over time.
-What are the ranked goals for persistence in this system?
+
+### What are the ranked goals for persistence in this system?
+
 Consider how the list of sample goals can apply to your project. Add, edit, or delete goals as needed. Order them from most important to least important.
-What is the logical database design?
+
+### What is the logical database design?
+
 Link to your logical database design and add addition notes as needed.
-What are the physical tables and views?
+
+### What are the physical tables and views?
+
 Link to your physical database design and add addition notes as needed.
-How will objects in the application be stored in the database?
+
+### How will objects in the application be stored in the database?
+
 Briefly describe your approach to object-relational mapping.
-What database access controls will be used?
+
+### What database access controls will be used?
+
 Describe the set of database users that will be used and their permissions.
-Is this application's central database accessible to other applications?
+
+### Is this application's central database accessible to other applications?
+
 Briefly explain which applications are expected to use this system's database.
-What data needs to be stored in files?
+
+### What data needs to be stored in files?
+
 List and describe all the files that the system writes to disk.
-What are the conventions for directory structure and file naming?
+
+### What are the conventions for directory structure and file naming?
+
 Write a sentence or bullet for each directory that the system uses to store user data, and one for each file naming convention.
-What file system access controls will be used?
+
+### What file system access controls will be used?
+
 Specify the operating system file access controls that will be used. E.g., certain files will be owned by certain operating system users, and each file will be readable, writeable, and/or executable by its owning user, user group, or other users.
-What information (if any) will be stored on client machines? For how long?
+
+### What information (if any) will be stored on client machines? For how long?
+
 If you use cookies or client-side caches, describe those here.
-Expressiveness: To what extent has this been achieved?
+
+### Expressiveness: To what extent has this been achieved?
+
 Evaluate how well your design achieves its stated goals.
-Ease of access: To what extent has this been achieved?
+
+### Ease of access: To what extent has this been achieved?
+
 Evaluate how well your design achieves its stated goals.
-Reliability: To what extent has this been achieved?
+
+### Reliability: To what extent has this been achieved?
+
 Evaluate how well your design achieves its stated goals.
-Capacity: To what extent has this been achieved?
+
+### Capacity: To what extent has this been achieved?
+
 Evaluate how well your design achieves its stated goals.
-Security: To what extent has this been achieved?
+
+### Security: To what extent has this been achieved?
+
 Evaluate how well your design achieves its stated goals.
-Performance: To what extent has this been achieved?
+
+### Performance: To what extent has this been achieved?
+
 Evaluate how well your design achieves its stated goals.
-Interoperability: To what extent has this been achieved?
+
+### Interoperability: To what extent has this been achieved?
+
 Evaluate how well your design achieves its stated goals.

Words-of-Wisdom-Postmortem-Report.md

@@ -1,14 +1,25 @@
 # Postmortem
 
-Line-by-line Instructions
-What are the goals of this postmortem report?
+## Line-by-line Instructions
+
+### What are the goals of this postmortem report?
+
 This is a reusable introduction to any postmortem report that helps to set a constructive tone.
-What are the most important points of this postmortem report?
+
+### What are the most important points of this postmortem report?
+
 Highlight the most important points for quick reference later. If there is one lesson learned that the team agrees should be acted on and not forgotten, make sure to list it here.
-Team Member Quotes
+
+### Team Member Quotes
+
 If any team members want to make a statement "on the record" regarding this project, include that here. It is important to allow all members of the team to be heard.
-Valuable Bi-Products
+
+### Valuable Bi-Products
+
 List reusable code, documentation, intrastructure, or process improvements that were produced as part of this project. These items are offered for reuse on later projects or later releases of this project.
-Lessons Learned and Recommendations
+
+### Lessons Learned and Recommendations
+
 List things that you learned during this release cycle. There are several prompts that ask you to think about lessons learned in different categories. Thinking back on what happened and recording what you have learned is one of the best ways to improve the software development process.
+
 There are several prompts that ask you to think of refinements to the process, the release checklist, the software development methodology, and other document templates. The postmortem meeting is a good time to gather suggestions for improvement ideas. Later, those suggestions should be evaluated and integrated into the overall process to be used in the next release cycle.

Words-of-Wisdom-Project-Plan.md

@@ -5,6 +5,7 @@
 ### What are the business problem, scope, and goal of this project?
 
 Normally, the project idea is described in the proposal. This document simply links to it.
+
 Customization: if you are not using the propsal template, copy and paste relevant prompts and sample answers from that template here and remove the link.
 
 ### Who will sponsor, manage, and lead the project?
@@ -65,6 +66,7 @@ List the deliverables that will be produced during this release cycle. Include b
 ### Schedule for this Release
 
 Use this grid to plan the number of hours needed for each task in each week. Keep in mind the dependencies between tasks and the availability of each resource.
+
 Customization: you may wish to use a spreadsheet or MS project plan instead of this table. In that case, you may still find the reusable sample text useful in that format.
 
 ### Risk Management

Words-of-Wisdom-QA-Plan.md

@@ -1,21 +1,39 @@
 # QA Plan
 
-Line-by-line Instructions
-Release Audience
+## Line-by-line Instructions
+
+### Release Audience
+
 Choose a description of your release audience that fits your goals for this release. It is common for different types of releases to have different quality goals.
-Why is this QA plan needed?
+
+### Why is this QA plan needed?
+
 This is reusable sample text that helps motivate the QA plan as a necessary project document.
-What QA lessons were learned in previous releases?
+
+### What QA lessons were learned in previous releases?
+
 If you have learned lessons from recent releases or similar projects, list some of them here. Explicitly stating lessons learned will help guide the planning of this release.
-What is the scope of this QA plan?
+
+### What is the scope of this QA plan?
+
 Some projects have a single QA plan for the entire system. Other projects use one main QA plan for the the main application, and separate plans for secondary deliverables such as bundled utilities, ports to different operating systems, or localized versions.
-What is the summary of this plan?
+
+### What is the summary of this plan?
+
 This prompt asks you to provide a brief summary of the overall plan that simply tells team members what will be done, without all the details found below. Consider how the sample text applies to your project. Work through the rest of the template before updating the summary.
-Quality Goals for this Release
+
+### Quality Goals for this Release
+
 Choose and prioritize quality goals for this release. Not every release can achieve every quality goal. Often, early releases will focus more on functional correctness. Only after functional correctness has been assured can performance and scalability be addressed. On the other hand, a very performance-sensitive product may have an early release of a working prototype that tests the feasibility of the design and leave much of the functional correctness for later internal releases.
-QA Strategy
+
+### QA Strategy
+
 Read the set of reusable sample QA strategies and select those that you wish to use on this release. Most projects will focus on just a handful of QA activities at first and then slowly add more as the product matures and the process becomes more refined.
-QA Strategy Evaluation
+
+### QA Strategy Evaluation
+
 Use this grid to help assess the set of QA activities that you selected. Certain QA activities are better at achieving certain QA goals than others. The cells in this grid hold your subjective rating of how well each QA activity assures each QA goal. If you find that you do not have enough assurance for your highest priority QA goals, you should use additional QA activities that focus on those QA goals.
-Plan of Action
+
+### Plan of Action
+
 Once you have selected your QA strategy, evaluated it, and refined it, it is then time to put the plan into action. Sample tasks are listed for several QA strategies. Consider how these relate to your QA strategy and then add, edit, or delete tasks to match. Once you have outlined the overall set of tasks that are needed to carry out your strategy, assign each task to a responsible individual using your issue tracking tool.

Words-of-Wisdom-Release-Checklist.md

@@ -1,5 +1,7 @@
 # Release Checklist
 
-Line-by-line Instructions
-Checklist Items
+## Line-by-line Instructions
+
+### Checklist Items
+
 INSTRUCTIONS

Words-of-Wisdom-Release-Notes.md

@@ -1,23 +1,43 @@
 # Release Notes
 
-Line-by-line Instructions
-Release Number
+## Line-by-line Instructions
+
+### Release Number
+
 This is the external release number (the one that customers see).
-Release Date
+
+### Release Date
+
 Note the date of the official release.
-Customer Support
+
+### Customer Support
+
 Give clear contact information in the release notes.
-Introduction
+
+### Introduction
+
 Briefly describe the product and the type of release. Letting customers know the type of release is an important way to set expections and gather needed feedback from early releases.
-What's New?
+
+### What's New?
+
 Briefly list the most important new features or user-visible changes. Each item in this list should be a potential reason for an existing customer to upgrade to this release.
-Installation and Upgrade Notes
+
+### Installation and Upgrade Notes
+
 Link to the installation instructions. Include any urgent warnings here.
-Minimum System Requirements
+
+### Minimum System Requirements
+
 List the minimal system resources needed to run the system. This information can be derived from the SRS environmental requirements.
-Version Compatibility
+
+### Version Compatibility
+
 Include this section if there are important things that users must know about the compatability of files produced by previous releases.
-Recent Changes
+
+### Recent Changes
+
 This is a more detailed list of changes in this release. These items can usually be copied from a report generated in your issue tracking tool.
-Known Problems and Workarounds
+
+### Known Problems and Workarounds
+
 Include a list of known problems and workarounds. These are problems that are already tracked in your issue tracking tool, but that have not been resolved in this release.

Words-of-Wisdom-Resource-Needs.md

@@ -1,11 +1,19 @@
 # Resource Needs
 
-Line-by-line Instructions
-Project Time-frame
+## Line-by-line Instructions
+
+### Project Time-frame
+
 INSTRUCTIONS
-Human Resource Needs
+
+### Human Resource Needs
+
 INSTRUCTIONS
-Capital Needs
+
+### Capital Needs
+
 INSTRUCTIONS
-Resource Needs Checklist
+
+### Resource Needs Checklist
+
 INSTRUCTIONS

Words-of-Wisdom-Review-Meeting.md

@@ -1,9 +1,15 @@
 # Review Report
 
-Line-by-line Instructions
-Documents and Code Reviewed at this Meeting
+## Line-by-line Instructions
+
+### Documents and Code Reviewed at this Meeting
+
 List the documents that were reviewed at this meeting.
-Meeting Minutes
+
+### Meeting Minutes
+
 Describe what happened at the meeting. Describe the progress that was made or any set-backs. Note important concerns, decisions, agreements, or discoveries.
-Action Items
+
+### Action Items
+
 It is best to put the action items into an issue tracking tool rather than putting them in this document. If you do not have an issue tracking tool, you can simply list action items and then track them manually.

Words-of-Wisdom-Risk-Management.md

@@ -1,10 +1,16 @@
 # Risks
 
-Line-by-line Instructions
-Risk Map
+## Line-by-line Instructions
+
+### Risk Map
+
 The map is a visual summary of the risks in the detailed list. Each risk is in a cell in the risk map based on the impact and likelihood of that risk. The red cells are the most dangerous to the project, the green cells are the least dangerous. A healthy project should have almost all risks outside the red region. Any project manager who sees a risk in the red region should make an effort to move it our of the red region by lowering the likelihood of the problem occuring or reducing the potential impact.
-Risk Details
+
+### Risk Details
+
 Consider how each sample risk might apply to your project. Update the position of the risk in the risk map to reflect your estimate of it likelihood and impact. Edit the risk description to fit your project.
 Risks that seem likely or that would have very harmful impacts should have mitigation strategies to lower their likelihood or impact.
-Risk Management Checklist
+
+### Risk Management Checklist
+
 Use this built-in checklist to check your work on the risk management worksheet.

Words-of-Wisdom-Security.md

@@ -1,17 +1,31 @@
 # Design Security
 
-Line-by-line Instructions
-What are the most important facts that a developer should know about the security of this system?
+## Line-by-line Instructions
+
+### What are the most important facts that a developer should know about the security of this system?
+
 Briefly describe the most important parts of your security strategy. Include any points that new developers will find hard to understand or any key decisions that have changed.
-What are the ranked goals for security in this system?
+
+### What are the ranked goals for security in this system?
+
 Consider how the sample security goals apply to your system. Add, edit, or delete goals to fit your plans. Order them from most important to least important.
-What physical security mechanisms will be used?
+
+### What physical security mechanisms will be used?
+
 Consider the sample physical security strategy bullets and adjust them to fit your project.
-What network security mechanisms will be used?
+
+### What network security mechanisms will be used?
+
 Consider the sample network security strategy bullets and adjust them to fit your project.
-What operating system security will be used?
+
+### What operating system security will be used?
+
 Consider the sample operating system security strategy bullets and adjust them to fit your project.
-What application security mechanisms will be used?
+
+### What application security mechanisms will be used?
+
 Consider the sample application security strategy bullets and adjust them to fit your project.
-Security Checklist
+
+### Security Checklist
+
 Use this checklist to help evaluate how well your selected security mechanisms will achieve your stated goals.

Words-of-Wisdom-Source-Organization.md

@@ -1,15 +1,27 @@
 # Design Source Organization
 
-Line-by-line Instructions
-What are the most important facts that a developer should know about this source code organization and build system?
+## Line-by-line Instructions
+
+### What are the most important facts that a developer should know about this source code organization and build system?
+
 Briefly highlight the most important things that another developer should know about your source code organization and build system. Focus on unconventional or difficult to understand concepts, rules that have been broken in the past, or things that have changed.
-What are the ranked goals of this source code organization and build system?
+
+### What are the ranked goals of this source code organization and build system?
+
 Consider how the sample goals relate to your project. Add, edit, or delete goals to fir your project. Order the goals from most important to least important.
-Key Directories and Files in Developer Working Copies
+
+### Key Directories and Files in Developer Working Copies
+
 List each directory and breifly describe its purpose and contents.
-Build Targets
+
+### Build Targets
+
 List each build system target and describe its purpose.
-Build Configuration Options
+
+### Build Configuration Options
+
 List each build system configuration option and describe its purpose.
-Source Code Organization and Build System Checklist
+
+### Source Code Organization and Build System Checklist
+
 Use this checklist to see how well your source code organization and build system has achieved your stated goals. If there is any question that you cannot answer, or that is answered negatively, go back and revise the design.

Words-of-Wisdom-Status-Report.md

@@ -1,21 +1,39 @@
 # Status Report
 
-Line-by-line Instructions
-Resources used this period
+## Line-by-line Instructions
+
+### Resources used this period
+
 Keep track of the number of hours of effort spent on this project so that it can be tracked against the plan.
-Status Summary
+
+### Status Summary
+
 This is a one-line executive summary of the status of the project.
-Open Issues
+
+### Open Issues
+
 Link to open issues for this release in your issue tracking tool. Group issues by type, internal milestone, or priority. These issues are the best description of the work that the team must do before the next release.
-Resolved Issues
+
+### Resolved Issues
+
 Link to resolved but unverified issues in your issue tracking tool. This list is a description of recently completed development fixes that must still be verified before they are known to be correct.
-Closed Issues
+
+### Closed Issues
+
 Link to recently closed issues in your issue tracking tool. This list is the best indication of what your team has done recently.
-Other metrics
+
+### Other metrics
+
 Track metrics such as lines of code written and test coverage to give an indication of the amount of progress that has been made toward stated goals.
-Detailed Status
+
+### Detailed Status
+
 Use 1-4 paragraphs to briefly describe the project status. List things that were done in this time period. Put the current work into the context of the overall project. If help or additional resources are needed, justify that need here.
-Upcoming Activity
+
+### Upcoming Activity
+
 Briefly describe what the team will do next.
-Tracking to Plan
+
+### Tracking to Plan
+
 Measure the team's progress relative to the plan. If you have learned that the plan was incorrect, update the plan and track to the new plan.

Words-of-Wisdom-Test-Suite.md

@@ -1,11 +1,19 @@
 # Test Suite
 
-Line-by-line Instructions
-Test Cases by Business Object and Operation
+## Line-by-line Instructions
+
+### Test Cases by Business Object and Operation
+
 The advantage of this test case organization is that it visualizes the overall set of tests in a way that helps identify missing tests.
-Detailed Test Case Grid(s)
+
+### Detailed Test Case Grid(s)
+
 Use this sub-grid to visually organize the set of tests that would fit into a single table cell in the main test grid. This level of detail helps to visualize whether all possible situations are covered. I.e., are all relevant classes of input values covered? and are all relevant system states covered?
-Test Cases by Feature Priority
+
+### Test Cases by Feature Priority
+
 This test suite visualization is useful for understanding how well specific features are being covered by the system test suite in this release. It is not uncommon to focus testing effort on the highest priority features, or the most risky features, first.
-Test Cases by Use Case Priority
+
+### Test Cases by Use Case Priority
+
 This visualization helps show which use cases are being covered by the system test suite. It is not unusual to focus on testing high priority use cases first.

Words-of-Wisdom-User-Guide.md

@@ -1,5 +1,7 @@
 # Userguide
 
-Line-by-line Instructions
-Table of Contents
+## Line-by-line Instructions
+
+### Table of Contents
+
 Read the sample userguide table of contents and consider how it could apply to your product. Choose an approach: e.g., starting with a tutorial and then providing reference material, or describing how to work with each business object or perform each of a set of common tasks. Adjust the sample outline to fit your product.

Words-of-Wisdom-User-Interface.md

@@ -1,32 +1,61 @@
 # Design UI
 
-Line-by-line Instructions
-What are the most important facts that a developer should know about the user interface of this system?
+## Line-by-line Instructions
+
+### What are the most important facts that a developer should know about the user interface of this system?
+
 Write a few sentences to point out the most important points that another developer should know about your UI design. Include any points that are likely to be misunderstood, or that have changed.
-What are the ranked goals for the user interface of this system?
+
+### What are the ranked goals for the user interface of this system?
+
 Consider how the sample UI design goals relate to your project. Add, edit, or delete goals to fit your project. Order the goals from most important to least important.
-What is the central metaphor of this UI design?
+
+### What is the central metaphor of this UI design?
+
 The central metaphor is the most general concept in the user interface. Usually, you can describe the central metaphor by naming some real world document, business tool, or physical object that your system is inspired by. E.g., a note taking application might work like an electronic notebook, a personal finance application might work like a smart checkbook, and a MP3 player might use the metaphor of a real world CD player.
-What existing systems have user interfaces similar to the UI you want to build? What specific aspects are similar?
+
+### What existing systems have user interfaces similar to the UI you want to build? What specific aspects are similar?
+
 Name a few existing systems that have an overall UI design that your project will be similar to. These might be competing systems or legacy products offered by your company.
-What UI design standards, guidelines, and styles are you following?
+
+### What UI design standards, guidelines, and styles are you following?
+
 Link to any published UI standards, guidelines, or styles that you plan to follow. These are available from the vendors of popular window systems: e.g., Apple, Microsoft, and Sun. There may also be government or corporate standards: e.g., Section 508.
-What types of users will use this system?
+
+### What types of users will use this system?
+
 The user-needs document lists out each type of user. You should simply link to it here.
+
 Customization: If you choose not to create a user-needs document, copy selected parts of the description of the users to this document.
-What types of tasks will those users perform?
+
+### What types of tasks will those users perform?
+
 The user-needs document lists out user stories. You should simply link to it here.
+
 Customization: If you choose not to create a user-needs document, copy selected parts of the user stories to this document.
-Screens
+
+### Screens
+
 First, make a list of UI zones. Each UI zone will have a set of screens that share some characteristics.
+
 Second, list the individual screens within each UI zone. Briefly describe the main purpose of each screen.
+
 Before going further, evaluate your UI model by trying to work though your use cases. A very rough UI mockup can help with this.
+
 Finally, come back to add more detail to the descriptions and mockup.
-What are your assumptions about the output devices?
+
+### What are your assumptions about the output devices?
+
 Briefly list important assumptions about the output device. If you are not making many assumptions, state that. If the software product runs on specific hardware, give the specifications of the display. If your user population has a range of popular output devices, describe the minimum, expected, and any specifically supported high-end output devices.
-What are your assumptions about the input devices that you will use?
+
+### What are your assumptions about the input devices that you will use?
+
 Document this aspect of your UI design in the same way that the output device was documented.
-What are your assumptions about the amount of time users will spend on tasks?
+
+### What are your assumptions about the amount of time users will spend on tasks?
+
 Often users expect that the product will enable them to accomplish specific tasks within a short amount of time. And, the definition of "short" keeps changing all the time. E.g., people were once very impressed with 28 Kbps modems, now they expect web pages to load within 2 seconds. Understanding and documenting user expectations about task completion times is an important part of managing customer expectations and it will drive some UI design decisions.
-User Interface Checklist
+
+### User Interface Checklist
+
 Use this checklist to help check your work and evaluate your UI design with respect to your stated goals. If there is any question that you cannot answer, or must answer negatively, go back and revise the design.