When you come to tracking this stuff, you need a place to record defects, and new OR missing features.
The best place is a SINGLE PLACE to record it all with an appropriate system of categorisation.
So you might say that a report is "feature request", "crash", "stops-getting-work-done defect", ..., "textual error" as your means of putting them into sortable, prioritisable groups.
If you have one system it makes it easy to allocate features as well as defect fixes to a build. If you do it any other way its hard to keep the scope in one place that is searchable and can show progress.
Features might be those that are desired and scheduled for a future release. They might also be features that are required for a release and not yet done. You might even choose to ship with some features incomplete or missing.
In this sense, the LACK of a feature does in fact comprise a defect: the function that should be present (by explicit requirement, or by some implicit desire) is not present.
You CAN if you choose go a step further and during initial development place all the requirements or major features [the lumps of your story... all depends on the process you use and the terminology you like] into the defect tracking system as well.
I've done this and it makes working through the feature sets toward completion go really well.
It annoys the heck out of testers who say "how can I track defects when it started with lots... and that dropped as you finished work packets". The answer is: tough... tune your reports better!