Automating Requirement and Specification Tracking (Week 4)

Author: Will McCoy

I’m happy to report that I am officially the Web-Master of the Road Watch team. When I was reviewing the roles, this one stuck out to me because of my hobby in maintaining a personal website (https://willmccoy.xyz) and my experience with Git. The other role that caught my attention was Team Leader; I have had past positive leadership experiences, mostly in High School when I did Boy Scouts and played baseball. My only concern was that I may not devote enough time to the role because of all my other classes. However, my team decided to divide that position evenly among all team members by periodically rotating it, so I will be the leader eventually.

This week I was introduced to tracking requirements and specifications. Essentially, a requirement is a qualitative description of an aspect of a product, and a specification is a quantitative metric which supports a requirement. Every requirement must have some associated specifications. What I thought was most interesting about this system is that every requirement and specification are given a unique identifying number, so that none are lost or forgotten. This immediately reminded me of relational databases, which also use keys (unique numbers) to identify entries and store the relationships (associations) between them; in fact, many professional Product Requirement Software programs use relational databases to manage requirements and specifications.

In my past work experience, my management’s expectations about projects would change over time. Therefore, I wanted to make a robust system for managing our group’s requirements and specifications, so that when the sponsor inevitably requests a new feature everything can be recorded in an organized way. I spent a few hours in Excel creating what is essentially a bare bones relational database, which records the requirements and specifications, and automatically computes the House of Quality and Technical Performance Measures (TPMs). I have noticed in some of my previous projects that features are often lost when tracking is disorganized, and I hope with this system to avoid that for Road Watch.

A logo I designed. However, the team (and I) preferred our current logo, so we went with that one instead.

Leave a Reply

Your email address will not be published. Required fields are marked *