The Benefits of a Good Discovery Phase
Let me ask you a question: if you want to drive from Wilmington to Seattle how do you start? Do you grab your wallet, phone and keys, hop in the car and just start heading in a northwestern direction, or do you plan out your trip with a visit to maps? Most of us wouldn’t even think of making that drive without at least some preparation. It helps to know about when to stop for bathroom breaks or to stretch your legs, where to stop to grab a bite and probably most important, where to get gas. We have a similar process to go through when we are designing a large software project. We call it the discovery phase. The sole purpose of this is to help us map out your project from the ground up.
Requirements Gathering
The requirements gathering phase is usually started off by a kick-off meeting where the developer will meet the Subject Matter Experts (SMEs) – or clients. They describe the problem they want solved and provide pertinent information. There is usually a lot of back and forth here where the developers are trying to make sure they have a clear understanding of what is expected. Sometimes we’ll have a follow up meeting or maybe several. There might be several phone calls or emails going around as the developer works on the requirements document. Once this document is completed, it’s treated as a checklist to signoff.
Client review
Once the requirements document has been completed, it gets submitted to the client for review. This is their opportunity to clarify any misunderstandings that may be present in the document. If problems are found, it will be handed back to the developer who will in turn make corrections and resubmit for review. This cycle will continue until the client agrees that what is being described in the document is what they have in their head.
High Level Design Phase
This phase is where the developer will abstractly model the system described in the document. At this point, we’ll generally layout the database design then work on wireframes. Wireframes are (intentionally) crude drawings to kind of try to convey an idea without much commitment to the aesthetics. It’s the digital equivalent of jotting an idea on the back of a napkin! Finally we will document the business rules as conveyed to us by the SMEs. This will usually be a brief description about all of the business objects and their properties and what they do. Still no coding will occur at this point, just a brief description of the Business Objects.
Unit test plan
At this point you have a viable plan for a Data Access Layer/Business Layer and Presentation Layer. We’ll write suggested unit tests based on this. The format goes something like this: test case name, test case description, test setup steps, test execution steps, how to determine pass or fail. These are high level. For example, I recently wrote a system where the requirement was to have the data display in a list with a visual indicator in the list to determine the age of the record. Green was within 7 days, yellow was between 8 and 14 days and red was older than 14 days. The test case for that would be like this:
o Test Name: test background color test
o Test Case Description: the purpose of this test is to confirm that the background color changes based on date (day < 7 days old = green, 8 days old < day < 14 days old = yellow, day > 14 days = red)
o Test Setup
§ Create a (A) record date today.
§ Create a (B) record date today + 7
§ Create a (C) record date today + 14
o Execute Test : check records in list
o Determine Pass/Fail: A should have background color of green, B should have background color of yellow, C should have background color of red.
Submit the Design Document for review
At this point, the client will be presented again with a document which they are to review and either ask for changes, clarification, or approve. If edits are required, we go through another edit/review cycle.
Development
At this point we have a design document. This is our blue print or map to create your application. Here the developer is responsible to make sure that everything we say the end product will do actually happens. Also the developer is responsible for making sure all documented unit tests are run successfully. Anything that pops up at this point which is outside the scope of the document is considered scope creep.
Deployment
Once all unit tests are passing and all items in the design document are checked off in house and by the client, it is deployed and the Development phase is over. Features can still be added, but the process to do that runs on a smaller scale.
This is how we are sure get things right from the beginning! It really helps when you have a defined beginning and a defined ending, however you also need a good way of determining you have reached that end. And another huge bonus: the client can be as involved as they like.
