Mr. Smith:
In our IT shop, we have started a new process of using traceability matrix. Our managers have asked the developers to start capturing as much functionality as possible upfront. Actually, what we are doing is that we are writing high-level business requirement first for the requested features and then making them single-line statement capturing all the specific functionality. It’s one-to-many relationship between requirement and specific functionality. For instance, the behavior of the buttons, navigation, message prompts, enabling and disabling, and so forth.
The idea of this exercise is to make sure that we capture every possible scenario for the desired feature; thus reducing the number of defects and avoiding missing features. A lot of times, testers open defects for scenarios that actually do not reflect the real world scenarios. I do understand that the design should be done in such a way that the user is unable to break the application. However, our application is highly flexible and customized for each client. Not all the functionality is applicable for the all the clients, so we find a middle ground where we see if such a scenario can happen in the client’s workflow. And, if not, then it’s the user’s training issue.
Initially, I liked the idea, thinking this process will familiarize each developer thoroughly with the specific requirements and reduce bugs that are missed during development. But as I am doing this now, it’s getting too detailed and I am finding it difficult to stay focused. Personally, I would’ve prefered the iterative process to start building something in smaller pieces, but we have strict deadlines and the scope lock is a must before the development can begin. Any delay spawns a process of deviation for the project.
Any thoughts…if this is an approach in the right direction? Or, it’s just me who is feeling lazy on Friday 
.
