The first part of building any enterprise-grade application is to define what the application aims to do. Up to now, we know that our application is going to track bugs for the various products that are marketed by the Omega Corporation. But what things are required from our application that will prove to be useful for bug tracking? Let's take a look and try to define the requirements for the application that we are going to build.

• Support for multiple products: One of the fundamental requirements for our bug tracking system is to support the tracking of bugs for multiple products that the organization builds. This is also a required feature considering the future growth of the organization.
• Support for multiple components per product: Although we can file the bugs at the product level itself, it will be too clumsy, specifically considering that most of the organizations have a separate team working on orthogonal features of a product. To make the tracking of bugs easier based on which component they have been filed, the bug tracking system should support the filing of bugs on a component to component basis.
• Support for attachments: Many a time, the users filing a bug, or the ones involved in any way in the bug life cycle, might want to attach images showing the effect of the bug, or may want to attach patches to the bug so they can be tested before being incorporating into the product. This will require the bug tracking system to provide support for attaching files to the bug reports.
• Support for comments: Once the bug has been filed, a user who is responsible for solving that bug might require some other information about the bug, or may require some collaboration. This makes it compulsory for the bug tracking system to have support for comments. Also, not every comment can be made public. For example, if there is some patch that the developers might have attached to the bug report to be tested by the original submitter of the bug, but which has not yet been incorporated into the main product, the developers might want to keep the patch private, so that it can be seen only by people with privileged access. This makes the inclusion of functionality for private comments also a necessity.
• Support for multiple user roles: Not everyone in the organization has the same level of access to the bug tracking system. For example, only people at the director level should be able to add new components to a product, and only employees should be able to see private comments on a bug. This calls for the inclusion of role-based access as a requirement for the system.

These are some of the requirements that are specific to our bug tracking system. However, as a consequences of these, there are a few more requirements that obviously need to be included in the system. Some of these requirements are:

• Requirement for a user authentication system: The system should provide a mechanism for authenticating the users based on some simple mechanism. For example, a user should be able to sign into the system by providing their username and password, or email id and password combination.
• Web interface for filing a new bug: The application should provide a simple to use web interface that can be used by the users to file new bugs.
• Support for bug life cycle: Once a bug has been filed into the system, its life cycle starts in the NEW state. From there it may move on to the ASSIGNED state, when someone from the organization picks up the bug for validation and reproduction. From there, the bug can move into various states. This is known as a bug life cycle inside our tracking system. Our bug tracking system should provide the support for this life cycle, and how to handle it when the bug moves from one state to another.

So, with this, we finally have our requirements in place. These requirements play an important role when we move onto designing and defining how our bug tracking web application will be built. So, with the requirements in place, it's time for us to move onto defining how our code base will look.