Merge pull request #27 from erniep888/develop

#22 - Corrected the grammar in the statement about Constraints.

README.md

@@ -17,7 +17,7 @@ There have been several different implementations of this web application but no
 > * **WHEN** is it being created?
 
 > ### **WHAT** is being created? ###
-> The completeness of the answer to the "WHAT question" usually varies based on the project management methodology.  For example, a project following an Agile or Rapid methodology, tends to work on detailed requirements and design throughout the application implementation process.  Conversely, a Waterfall Model strives to figure out requirements and design before one line of code has been written.  In all cases there should at least be a skeleton of the entire proposed application.  When there is no forethought about what is being requested, there will be little chance of success.  Therefore, ScrumTime expects **Requirements** to be gathered and **Features** to be documented that address each requirement.  It is possible for one Feature to address multiple requirements.  Each level supports hierarchical relationships to allow for further breakdown to the lowest desired detail.  In other words, a Requirement may be a child of another Requirement and a Feature may be the child of another Feature. **Constraints** are also associated with "What" is being built.  A Constraint may include budget, time, people, hardware, or other.  When defined "What" and application is to be, Constraints must be considered.
+> The completeness of the answer to the "WHAT question" usually varies based on the project management methodology.  For example, a project following an Agile or Rapid methodology, tends to work on detailed requirements and design throughout the application implementation process.  Conversely, a Waterfall Model strives to figure out requirements and design before one line of code has been written.  In all cases there should at least be a skeleton of the entire proposed application.  When there is no forethought about what is being requested, there will be little chance of success.  Therefore, ScrumTime expects **Requirements** to be gathered and **Features** to be documented that address each requirement.  It is possible for one Feature to address multiple requirements.  Each level supports hierarchical relationships to allow for further breakdown to the lowest desired detail.  In other words, a Requirement may be a child of another Requirement and a Feature may be the child of another Feature. **Constraints** are also associated with "What" is being built.  A Constraint may include budget, time, people, hardware, or other.  When defining "What" an application is to be, Constraints must be considered.
 
 > ### **HOW** is it being created? ###
 > The "HOW question" addresses the **Epics**, **Stories**, and **Tasks** that derive from the "WHAT question." The **Epics** are created to address Features, **Stories** are created to breakdown Epics, and **Tasks** breakdown Stories.  Each level may have a hierarchy for further breakdown to the lowest desired detail.  For example, an Epic may have one or more Epic children or Story children. But, an Epic may have only one Epic parent.  Likewise, a Story may have only one Epic or Story parent and a Task may have only one Story or Task parent. **Bugs** are also tracked as part of "How" and they may be tied to an Epic, Story, or Task.