Feature Creation - slander36/IssueTrackerTraining GitHub Wiki

Feature creation is a long, arduous process which begins life as an idea and goes through many stages before implementation. While this document is going to focus on the issue tracking side, it will also touch on the basic development workflows which make implementation much easier.

It would be cool if...

So you've just had an idea and everyone has signed off on implementing it. Great! Let's follow the life of a feature from its inception, showing you how to go from initial idea into what we see in the issue tracker at the end.

Functional Specification (Func Spec)

Every new feature is a combination of many other features, and you find this out in the Func Spec. The Func Spec is a list of all possible sub-features of functionality that the major feature will encompass. For example, if you're making a "Login System" for users, they will need to be able to:

• Navigate to the login page
• Enter user information
• Issue a Login action
• Be notified login was successful/failed
• Navigate to the logout page
• Issue a Logout action
• Be notified the logout was successful/failed

This is assuming that the User system already exists, and makes no reference to the UI that may be associated with it. Already one feature has turned into a bunch of smaller features, each which have to be tested later on.

Technical Specification (Tech Spec)

After the Func Spec has been created, it's time to create the Tech Spec, which lists out the actual features which are necessary for the functions above to, well, function. These will be the specific technical requirements, so to take "issue login action" as the example from above:

• Create form with fields for "username" and "password" as well as other hidden fields, if necessary
• Async or Sync call? If async, ajax code necessary to post the login form
• Server code to deal with login
  • Accept requests with params blah
  • Securely verify username/password combination
  • Respond with accept/reject
  • Save user information in SESSION

These will be used to verify that the necessary tools are in place to accomplish the the new function (sub-feature) of the new feature.

Issue tracking

So as shown above, there are many other steps required before features can be assigned out. Once these have been completed, it's time to create your new feature issues!

Parent Issue

From the Func Spec, it's clear to see that each major feature will have many minor features assigned to it. This is great for development and testing, as it gives a clear delineation between all of the features which must be tracked. The major feature will be the parent issue for all other sub-features, and keep track of which are completed or not. The new feature is not complete until this feature has been marked as such.

Child Issues

Child issues are the sub-features of each major feature. They reference the parent issue for tracking purposes. These are the issues which the implementers will have to make sure and check off, as they are each a self-contained feature in their own right and required for the major feature to be completed.

Parent issue after attaching child

Feature Complete

Once the feature is completed, the parent issue can be closed after it's been linked to its proper build/commits. Once that is done, the feature and its children need to be added to a Checklists so that the feature can be properly tested. This assures that all features are documented and the history of their implementation maintained.