Add words of wisdom pages

Words-of-Wisdom-All-in-One-Project-Summary.md

@@ -0,0 +1,49 @@
+# All-in-one Project Summary
+
+Line-by-line Instructions
+What business problem does this project address?
+Use 2-4 sentences to describe the problem that your potential users are having right now. Focus on business problems, not technical problems. If you are trying to solve a technical problem, describe the business need that makes that technical problem important enough to solve. Do not say anything about your solution here.
+What is the goal of this project?
+Write 2-4 sentences or bullets on your main goal for the project. Briefly, name your target audience and mention key benefits that your customers will gain by using your product.
+What is the scope of this project?
+Give 2-4 sentences or bullets that summarize what you intend to do as part of this project. A good scope paragraph helps you avoid feature creep later.
+Status
+Briefly indicate what the team has recently accomplished and what they will do next. Write the details in the status reports, not here.
+Customization: If you do not want to use status report documents, you can select some parts of the status report template and paste them here in the "Status" section of the all-in-one template.
+What are the deadlines for this project?
+List key deadlines. Consider using dates relative to project kickoff so that your commitments can be kept, even if the start of the project is delayed.
+Who is working on this project?
+List the team members working on this project. Include the percentage of time that each person will work on this project.
+What capital resources are allocated to this project?
+List the capital resources that will be used by this project. Capital resources are hardware, software, and other materials that must be purchased or allocated before they can be used.
+What are the main legal concerns for this project?
+Briefly address basic legal concerns. See the checklist in the "legal" template to help identify other relevant legal issues.
+Who are the project stakeholders?
+Project stakeholders are people who care deeply about the success of the project and want it to succeed. Losing the support of key stakeholders could cancel the project. Identifying stakeholders is the first step toward aligning their interests, expectations, and evaluations of the project.
+What user needs have you gathered?
+Link to another document with user stories or interview notes.
+Customization: If you choose not to maintain separate documents for user stories and interview notes, select key parts from the user-needs and interview-notes templates and paste them here.
+What are the requirements specifications?
+Link to one or more documents with details of your software requirements specification. Or, use the more detailed sections below this question to link to individual use cases, feature descriptions, and details of other requirements.
+What are your ranked design goals?
+Think about the importance of each of the sample design goals to your project. Add, delete, or edit them to fit your project. Order them from most important to least important. Explicitly setting the design goals will help you in making and evaluating design decisions.
+Where are your design documents?
+Link to UML design documents or other design documents. Consider the detailed design document templates for more information about the content of design documents.
+What are your ranked quality goals?
+Think about the importance of each of the sample quality goals to your project. Add, delete, or edit them to fit your project. Order them from most important to least important. Explicitly setting the quality goals will help you in making and evaluating QA decisions.
+What QA activities will you use?
+List the QA activities that you will use on this project. Choose QA activities based on their relevance to your quality goals. See the qa-plan template and standard glossary for more information on QA activities.
+Where are the test cases?
+Link to your test cases.
+Where is the release checklist or sign-off document?
+Every release requires a final checklist or sign-off to be sure that each project stakeholder is satisfied with the release. Link to that document here.
+How is the product packaged and deployed?
+Write a few sentences on how you expect this product to be packaged and deployed to users. Link to the project release notes.
+How is the product installed?
+Briefly outline the installation process. Write these steps in enough detail that one of your target customers could actually install the product.
+Where is the user documentation?
+Link to the user guide and user FAQ. See the userguide and FAQ templates for help with these documents.
+How can users get technical support or report problems?
+List the email addresses or phone numbers that users will use for technical support. Also, briefly describe the way that customers can report problems, e.g., an on-line defect reporting tool or a simple email address.
+Glossary
+Define any project-specific technical terms in enough detail that a new team member could understand them.

Words-of-Wisdom-Architecture.md

@@ -0,0 +1,27 @@
+# Design 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?
+Name the software architecture style that best describes your system.
+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?
+Link to UML component diagrams or list the major components of the system.
+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?
+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?
+Describe your load balancing strategy.
+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?
+Describe your choice of inter-process communication mechanism.
+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
+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
+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

@@ -0,0 +1,19 @@
+# Demo Script
+
+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?
+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?
+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?
+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?
+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
+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
+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
+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

@@ -0,0 +1,15 @@
+# Design
+
+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?
+INSTRUCTIONS
+What are the prioritized goals of this design?
+INSTRUCTIONS
+UML Structural Design
+INSTRUCTIONS
+UML Behavioral Design
+INSTRUCTIONS
+UML Design Checklist
+INSTRUCTIONS

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

@@ -0,0 +1,5 @@
+# FAQ
+
+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-Feature-Set.md

@@ -0,0 +1,10 @@
+# Feature Set
+
+Line-by-line Instructions
+Features by Release and Priority
+The advantage of this feature set organization is that it visualizes the overall sequence of work on features across releases. It also provides a visually clear way to manage the scope of a release by slipping features into a later release: the lowest priority features in one release are simply moved down the list into a later release.
+Features by Release and Risk
+This feature set organization helps to visualize and manage the risk to the success of the project that is inherent in the scope of each release. If a given release has too many risky features, it will be impossible to have confidence in the schedule. It is better to understand the amount of risk in each release and slip some risky features to later releases.
+Features by Feature Area
+This is a logical organization of features into feature areas. Each feature area is a group of features that help users accomplish a related set of tasks that support a claimed benefit of the product. For example, if one of the claimed benefits of page layout application is the ability to import and export graphics in standard formats, then all of the individual import and export features will be in the "import/export" feature area.
+It is useful to visualize features by feature area as a way to estimate the amount of support given for each claimed benefit. Continuing the page layout application example, if there are no import/export features, then the claimed benefit is not supported. Likewise, if there are far too many import/export features, that indicates that a redesign may be needed.

Words-of-Wisdom-Glossary-and-Data-Dictionary.md

@@ -0,0 +1,6 @@
+# Glossary
+
+Line-by-line Instructions
+Project-specific Terms
+Briefly define project-specific terms. Write the definitions in enough detail that a new member of the project team could understand all the terms. Writing project-specific definitions in the glossary helps to keep other project documents short and precise while still being understandable.
+The glossary document can also serve as a simple data dictionary.

Words-of-Wisdom-Implementation-Notes.md

@@ -0,0 +1,15 @@
+# Implementation Notes
+
+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
+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
+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
+These are step by step instructions for common tasks that the operations engineers may need to do.
+Security
+List things that the operations engineers should do to keep the system secure.
+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

@@ -0,0 +1,21 @@
+# Install
+
+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
+Clearly indicate the user's technical support options.
+Introduction
+Give a very brief description of this release.
+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?
+List prerequisite software that must be installed before your product can be installed.
+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?
+Likewise, write the uninstall steps in enough detail for a user to actually follow.
+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-Interview-Notes.md

@@ -0,0 +1,13 @@
+# Interview Notes
+
+Line-by-line Instructions
+Interviewer(s)
+List the person or people who conducted the interview.
+Interviewee(s)
+List the person or people who responded during the interview.
+Interview Questions and Answers
+Use the interview checklist document to help plan these questions. Use the interview-notes document to record the questions and answers for later reference.
+Action Items
+Note any action items that result from this interview. These include following up to answer questions that could not be answered during the interview. Make sure to track any actions items in your issue tracking tool.
+Other Interview Notes
+Use this part of the interview notes template for any other information that was obtained during the interview.

Words-of-Wisdom-Legal-Issues.md

@@ -0,0 +1,9 @@
+# Legal
+
+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
+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
+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

@@ -0,0 +1,39 @@
+# Design Persistence
+
+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?
+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?
+Link to your logical database design and add addition notes as needed.
+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?
+Briefly describe your approach to object-relational mapping.
+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?
+Briefly explain which applications are expected to use this system's database.
+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?
+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?
+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?
+If you use cookies or client-side caches, describe those here.
+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?
+Evaluate how well your design achieves its stated goals.
+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?
+Evaluate how well your design achieves its stated goals.
+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?
+Evaluate how well your design achieves its stated goals.
+Interoperability: To what extent has this been achieved?
+Evaluate how well your design achieves its stated goals.

Words-of-Wisdom-Postmortem-Report.md

@@ -0,0 +1,14 @@
+# Postmortem
+
+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?
+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
+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
+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
+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-Overview.md

@@ -0,0 +1,14 @@
+# Project Overview
+
+Line-by-line Instructions
+What business problem does this project address?
+Use 2-4 sentences to describe the problem that your potential users are having right now. Focus on business problems, not technical problems. If you are trying to solve a technical problem, describe the business need that makes that technical problem important enough to solve. Do not say anything about your solution here.
+What is the goal of this project?
+Write 2-4 sentences or bullets on your main goal for the project. Briefly, name your target audience and mention key benefits that your customers will gain by using your product.
+What is the scope of this project?
+Give 2-4 sentences or bullets that summarize what you intend to do as part of this project. A good scope paragraph helps you avoid feature creep later.
+Status
+Briefly indicate what the team has recently accomplished and what they will do next. Write the details in the status reports, not here.
+Customization: If you do not want to use status report documents, you can select some parts of the status report template and paste them here in the "Status" section of the all-in-one template.
+Development Documents
+These are simply links to all the development documents. Feel free to add more links, or remove links that you are not using.

Words-of-Wisdom-Project-Plan.md

@@ -0,0 +1,41 @@
+# Plan
+
+Line-by-line Instructions
+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?
+Explicitly state the names of the people who are responsible for the success of this project.
+What authority does the project manager have?
+Consider the sample list of project manager areas of authority. Edit the list to fit your project. If the project manager does not have the authority to do what is needed, then the manager must request more authority, negotiate with others who have the authority, or scale back the scope of the project.
+What planning lessons were learned in previous releases?
+State some of the lessons learned in planning past releases or similar past projects. Explicitly stating these lessons here will help avoid repeating past mistakes.
+How is this project plan organized?
+The sample text should be reusable on most projects.
+Customization: if you customize the plan template, you may wish to update this paragraph.
+What are the most important facts that a project stakeholder should know about this plan?
+Briefly highlight the most important things that a project stakeholder should know about your project plan. Focus on managing the expectations of project stakeholders who might otherwise misunderstand the project plan.
+What general development approach will be used?
+Name and briefly describe the software development method that you will use on this project. If you have the software development methodology template, read it for ideas and reusable sample text. The following prompts ask you to describe more specific parts of the methodology.
+How will the project team be organized?
+List the groups within the overall project team, and the people in each group.
+What development and collaboration tools will be use?
+List the tools that you will use during this development cycle. If there is a tool that you want to use, you may need to plan time for acquisition, installation, and training.
+How will changes be controlled?
+Change control is key to actually finishing a project. Consider the sample change control mechanisms, then add, edit, or delete them to fit your development process.
+How will this plan be updated?
+Plans will always change over the course of the project. Changes that are not recorded as changes to the plan document can lead to uncoordinated efforts. It is important to explicitly identify the person responsible for updating the plan document and explicitly commit to the change notification process.
+Planning Goals
+Project planning can be viewed as a system of goals with different degrees of flexibility. For example, you might say that quality must be exactly as specified, whereas schedule could vary somewhat. The prioritization of these planning goals will help to guide individual management decisions later in the project. E.g., should we ship this release with a particular known defect or take the time to fix the defect?
+Work Breakdown Structure and Estimates
+Consider the sample list of tasks in the template. Add, edit, or delete tasks to fit your project. If you cannot confidently estimate the duration of a task, try to break it down into smaller parts. Consult with the person who is likely to actually work on the task when making estimates.
+Deliverables in this Release
+List the deliverables that will be produced during this release cycle. Include both external and internal deliverables. Manage the delivery dates by giving specific dates when possible, or ranges of dates, or dates that are relative to milestones. E.g., the userguide will be ready 10 days after the application has been handed off to the QA group.
+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
+Project risks are listed on the risk management worksheet.
+If you are not using the risk management worksheet, read that worksheet to understand common project risks and then simply list relevant risks in this section.
+Project Planning Checklist
+Use this checklist to help check your work on the project plan. Any question that cannot be answered positively may indicate that you should revise the plan until you are satisfied.

Words-of-Wisdom-QA-Plan.md

@@ -0,0 +1,21 @@
+# QA Plan
+
+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?
+This is reusable sample text that helps motivate the QA plan as a necessary project document.
+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?
+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?
+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
+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
+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
+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
+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

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

Words-of-Wisdom-Release-Notes.md

@@ -0,0 +1,23 @@
+# Release Notes
+
+Line-by-line Instructions
+Release Number
+This is the external release number (the one that customers see).
+Release Date
+Note the date of the official release.
+Customer Support
+Give clear contact information in the release notes.
+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?
+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
+Link to the installation instructions. Include any urgent warnings here.
+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
+Include this section if there are important things that users must know about the compatability of files produced by previous releases.
+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
+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

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

Words-of-Wisdom-Review-Meeting.md

@@ -0,0 +1,9 @@
+# Review Report
+
+Line-by-line Instructions
+Documents and Code Reviewed at this Meeting
+List the documents that were reviewed at this meeting.
+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
+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

@@ -0,0 +1,10 @@
+# Risks
+
+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
+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
+Use this built-in checklist to check your work on the risk management worksheet.

Words-of-Wisdom-SRS.md

@@ -0,0 +1,33 @@
+# SRS
+
+Line-by-line Instructions
+Introduction
+This section provides a brief introduction to the software requirements specification. To keep this section brief, the background information on the project goals and scope and the recorded user needs are linked rather than duplicated here.
+Use Cases
+Use cases are a very important part of the SRS. They are written in a special format in their own use case document.
+Functional Requirements
+Feature specifications are a very important part of the SRS. They are written in a special format in their own features document.
+What are the usability requirements?
+List any specific usability requirements here. Refer to existing standards documents and write new requirements in as "shall" (sentences that use the word "shall").
+What are the reliability and up-time requirements?
+List any specific reliability and up-time requirements here. Refer to existing standards documents and write new requirements in as "shall" (sentences that use the word "shall").
+What are the safety requirements?
+List any specific safety requirements here. Refer to existing standards documents and write new requirements in as "shall" (sentences that use the word "shall").
+What are the security requirements?
+List any specific security requirements here. Refer to existing standards documents and write new requirements in as "shall" (sentences that use the word "shall").
+What are the performance and scalability requirements requirements?
+List any specific performance requirements here. Refer to existing standards documents and write new requirements in as "shall" (sentences that use the word "shall").
+What are the maintainability and upgradability requirements?
+List any specific maintainability and upgradability requirements here. Refer to existing standards documents and write new requirements in as "shall" (sentences that use the word "shall").
+What are the supportability and operability requirements?
+List any specific supportability and operability requirements here. Refer to existing standards documents and write new requirements in as "shall" (sentences that use the word "shall").
+What are the business lifecycle requirements?
+List any specific business lifecycle requirements here. Refer to existing standards documents and write new requirements in as "shall" (sentences that use the word "shall").
+What are the system hardware requirements?
+List any specific system hardware requirements here. These are the true minimum requirements. You might present somewhat higher system requirements to customers to give a margin of extra capacity.
+What are the pre-installed software requirements?
+List any specific pre-installed software requirements here.
+What programmatic interfaces must be provided?
+List any specific API requirements here. Refer to existing standards documents. Do not write API specs directly in this document.
+What are the data import and export requirements?
+List any specific import and export requirements here. Refer to existing standards documents and write new requirements in as "shall" (sentences that use the word "shall").

Words-of-Wisdom-Security.md

@@ -0,0 +1,17 @@
+# Design Security
+
+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?
+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?
+Consider the sample physical security strategy bullets and adjust them to fit your project.
+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?
+Consider the sample operating system security strategy bullets and adjust them to fit your project.
+What application security mechanisms will be used?
+Consider the sample application security strategy bullets and adjust them to fit your project.
+Security Checklist
+Use this checklist to help evaluate how well your selected security mechanisms will achieve your stated goals.

Words-of-Wisdom-Software-Development-Method.md

@@ -0,0 +1,10 @@
+# SDM
+
+Line-by-line Instructions
+How is this document organized?
+This is reusable sample text that describes the organization of the software development methodology documents.
+Customization: if you reorganize these documents, make sure to update this paragraph.
+Briefly, what is the overall process?
+Name and briefly describe the process. This is usually done by choosing the process model that is closest to your actual process and then noting a few important differences.
+What are the most important principles of our software development process?
+Consider how the sample principles relate to your development process. Add, edit, or delete principles to fit your process. Order them from most important to least important.

Words-of-Wisdom-Source-Organization.md

@@ -0,0 +1,15 @@
+# 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?
+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?
+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
+List each directory and breifly describe its purpose and contents.
+Build Targets
+List each build system target and describe its purpose.
+Build Configuration Options
+List each build system configuration option and describe its purpose.
+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

@@ -0,0 +1,21 @@
+# Status Report
+
+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
+This is a one-line executive summary of the status of the project.
+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
+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
+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
+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
+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
+Briefly describe what the team will do next.
+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-Target-and-Benefits.md

@@ -0,0 +1,15 @@
+# Target and Benefits
+
+Line-by-line Instructions
+What market segment is this product in?
+Simply name the market segment that this product falls into. If you cannot name the market segment, then you probably do not know enough about the overall market yet. If your product bridges two market segments, list them both. If your product is so novel that it does not fit any existing market segment, name a new market segment using a combination of terms that describe current segments, or choose the market segment that your potential customers will think that your product falls into (until the learn more about it).
+What is the target market for this product?
+Define the population of potential customers.
+What is the size of the total available market?
+Estimate the size of the population of potential customers in terms of number of customers or total dollars. Estimate the entire market, including customers currently served by competitors, but do not count customers who could never buy your product.
+What are some other customer options or leading products that address the same needs?
+List your competition and other alternatives that potential customers have.
+Benefits
+Consider the sample text describing types of benefits to customers. Add, edit, or delete benefits to fit your product.
+Potential Downside
+Consider the sample text describing potential downsidest to customers of this product. Add, edit, or delete downsides to fit your product.

Words-of-Wisdom-Test-Run-Log.md

@@ -0,0 +1,5 @@
+# Test Runs
+
+Line-by-line Instructions
+Test Case Template
+Each record in this document describes a test that was carried out by the QA team.

Words-of-Wisdom-Test-Suite.md

@@ -0,0 +1,11 @@
+# Test Suite
+
+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)
+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
+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
+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-Use-Case-Suite.md

@@ -0,0 +1,11 @@
+# Use Case Suite
+
+Line-by-line Instructions
+Use Cases by Feature Area
+This organization of the use case suite is useful because it visually shows coverage of the set of features. Any feature area that is too few use cases may be under-specified and need more work to fully specify it.
+Use Cases by Stakeholder
+This organization of the use case helps to make sure that you have understood the needs of all classes stakeholders and users. If there is any class of user that doe not have as many use cases as you feel are needed, you can clearly see that and realize that you must add more use cases.
+Use Cases by Priority
+This use case suite organization highlights the most important use cases for this release. Development, documentation, and quality assurance efforts could be focused on these use cases.
+Use Cases by Business Object and Actor
+This grid organization helps you to visually recognize missing use cases. For each cell in the table, ask youself "what does user X do with business object Y?". If the answer is "nothing", then write "N/A". If the answer is something, note down the names of some use cases. If the user does do something with that business object, but you don't know what that is, write "TODO" as a reminder to come back to that cell.

Words-of-Wisdom-User-Guide.md

@@ -0,0 +1,5 @@
+# Userguide
+
+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

@@ -0,0 +1,32 @@
+# Design UI
+
+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?
+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?
+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?
+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?
+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?
+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?
+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
+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?
+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?
+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?
+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
+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.

Words-of-Wisdom-User-Needs-and-Stories.md

@@ -0,0 +1,19 @@
+# User Needs
+
+Line-by-line Instructions
+Agreed Goals
+This should be a summary of product goals agreed to by both users and developers. You might have a draft of this at the beginning of the project if you were given a problem statement by the customer. More likely, you would arrive at this statement after you have completed requirements gathering. In either case, you might revise this statement as you learn the details of the problem and work through your solution. You should not have to revise it often, because details are best tracked in the use cases and feature specifications.
+What is the system's business environment?
+A "business environment" is the overall business setting in which the system will be used. Describe who will use the system, the organization where those users work, who they work with, and which business processes the system affects.
+What is the system's physical environment?
+Describe where the server will be located. And, describe where users will be located. Briefly note the physical characteristics of these environments affect the system's performance or usability.
+What is the system's technology environment (hardware and software)?
+Describe the hardware and software that the system depends on, or interoperates with. Note compatability features that users expect.
+Stakeholders / Actors
+Start by listing different types of stakeholders and users. Use the greater-than notation to indicate subtypes of stakeholders and users. Then, come back to describe each class of stakeholder / user in detail. Use the sample text to prompt you to think of details and key needs of each class of stakeholder. As you go, make a note of key needs of that all stakeholders have in common. Review your interview and brainstorming notes and user stories to get more ideas.
+Notes from Interviews and Brainstorming
+Link to interview notes, notes from brainstorming meetings, or other sources of information on user needs.
+User Stories
+Write a few user stories to sketch out how users could use the system. User stories should be very short, simple, and concrete.
+Performance and Capacity Needs
+If potential customers or users have stated performance or capacity needs, capture that here. These will be reconciled with other user needs and development team priorities when the SRS is written.