The first phase of a successful software project is the requirements phase. In this phase, the relevant stake-holders dream about cool features. Those folks include accountants, administrators, executives, I.T. workers, knowledge workers, managers, marketing, sales, subject matter experts, support, users, and web masters. It takes empathy and people skills to be good at capturing requirements. Requirements can depend on other requirements. They are also linked to design personas through a hierarchy of needs. The types of requirements include story boards, scenarios, walk-throughs, and user stories. There are also marketing, business, and technical requirements.

Requirements must be analyzed for their merit so that they can be prioritized according to how much or how well each requirement advances the project towards its stated goals. Analysts study the requirements and build use-cases from them. A requirement is fairly unstructured and creative whereas its correpsonding use-case is very structured and more technical. Use-cases have actors, pre conditions, post conditions, normal course, alternative courses, exceptions, and business rules. They can also include or extend other use-cases. A good analyst is someone who can tease apart a complex story into smaller, more cognitively manageable sections.

Once the proper set of requirements have been chosen for the next release of the project and the corresponding use-cases have been approved, then a design of a solution that satisfies the requirements can proceed. Designs are very technical. They detail the necessary changes to the database and to every affected software asset (i.e. code file). A design must specify the impact that it has on the entire application and contain enough details to show how each part of the use-cases, that cover each requirement in this release, will be implemented. It's a tricky balancing act because the design shouldn't be too detailed, just detailed enough for the coder to be able to know what to do. Mentally speaking, a good designer is just the opposite of an analyst. Whereas the analyst pulls things apart, the designer is a synthesist who puts things back together.

Once the design has been approved, then the software can be coded to implement the approved solution. The developers make the changes to the software assets as proscribed by their approved designs. Here is where a really good source code version control system is necessary. In a subsequent release, Code Roller will come with a simple version control system built into it. The ability for Code Roller to integrate with Subversion will also be made available. Coders must be good at following not only the letter of the instructions but also the spirit. Good coders also have to be good problem solvers. They must also be capable of sustaining long periods of intensly focused attention.

Once the application has been developed, it must be tested to make sure that it is working to expectations. Once the use-cases have been approved, the Quality Assurance engineers build test plans that are used to verify the correctness of the application. After the code has been written, those same engineers test the application by following the test plans. A defect gets written up whenever the application's behavior differs from that of the test plans. Each test plan is a collection of test steps. Each test step links to a part of a use-case and documents the expected results. Each defect links to the relevant test step and provides the actual outcome. A good QA engineer has a detective mind. She is good at spotting and documenting clues that will help the developer find the bug in the code.

Finally, the finished application must be deployed to where it can be used by its intended audience. This usually involves some kind of build process that converts the software assets into a deployable form. Actually, this build process should be periodically ran as another form of quality assurance. How can you tell when the release is ready? When no more defects can be created from all of the test plans for this release whose configuration type matches the target deployment. Actually, it is not so much a question of when the release is ready as it is a question of which build of the release will get deployed. A good release engineer knows how to build the product and who to contact when the build fails. Also, a little paranoia never hurts.