Requirements & Requirements Management

Digital Transformation and the Importance of Requirements Management Within the DoD

By |

DoD

Digital Transformation and the Importance of Requirements Management Within the DoD

Looking back on a technology career that started nearly 45 years ago gives me an opportunity to reflect on the evolution of technology trends. Most notably, for me, the usability and interfaces to that technology. Let me explain…

I started out as a young man in the Marines repairing and calibrating avionics equipment, and general test instrumentation. After boot camp (basic training) the Marines saw fit to send me to a half dozen electronic schools to learn my craft. Every piece of equipment I touched had a physical reference, and user’s manual, but for the most part, if you knew what function a piece of gear was supposed to provide, you probably didn’t need a manual very often. For example, if I knew how to use a Tektronix oscilloscope, I probably didn’t need any instruction on how to use an o-scope from Hewlett Packard or Phillips. Just about everything I needed to know was obvious and accessible on the front panel (the user interface).

Over the next 15 years that paradigm stayed relatively consistent. I would see different types of equipment, work on different ‘things,’ but it was rare that training or anything other than an occasional manual was needed to be productive. Physical interfaces tended to ‘tell all’ about what I could do, or what I needed to do with a piece of electronic equipment.

It was about this time that I made a mid-career switch. It had become obvious (to me, at least) that software was going to be in EVERYTHING. Consequently, I went back to school for a Computer Science (CS) degree to help in gaining access to that world. With CS degree in hand, I took a position writing test software on a classified program for an aerospace giant. It was interesting at one level when I could see the end results of my efforts, but it could be laborious at times. I shared a large cubicle with two teammates, and we were heads down grinding on code for most of the day. I know some find this immensely rewarding, but I was not one of them.

RELATED: A Nod To MOSA: Deeper Documenting of Architectures May Have Prevented Proposal Loss

Whilst I knew this wasn’t my calling in life, the introduction to a software development organization gave me exposure to tools supporting the software development lifecycle (SDLC). Disciplines like requirements management, configuration & change management, and architectural modeling. Plus, the software development process itself: Waterfall, Spiral, Iterative, Agile to name a few. The code may be the ultimate deliverable, but there are a lot of moving parts to get the code out the door. Of course, not every team believed in all of those ‘other’ disciplines: I had one teammate that had a sign over his desk that read, “Documentation is for wimps!” I also remember a cartoon at that time that read something like (manager speaking to developers): “You start writing the code while I go upstairs and see if they have any requirements.”

I’ve spent the bulk of the past 20 years of my work life supporting and working with Federal DoD programs – the large System Integrators, and direct with programs at military installations around the country. In that time, I’ve seen the transformation of segments of programs/projects being focused on a singular discipline (e.g., requirements, code, test, etc.) to the point where they are taking the big picture view; that systems and software development is really a team sport. Instead of each discipline developing their own assets/artifacts and ‘throwing them over the wall’ the work is now being attacked in a cohesive and coordinated fashion. Essentially, a digital transformation where we’ve gone from just ensuring that each discipline has tooling to support their own work, to the point where each segment of the development lifecycle prioritizes the ability to link and trace to the upstream and downstream activities.

In the earliest of days of tracing assets across all disciplines the tool vendor who could supply an environment that supported all facets of development, and link those assets together had an advantage. However, over time, the end user became more sophisticated. They did not want to lock themselves into a single vendor with tools that were ‘good enough,’ they wanted a best-of-breed product for each of those disciplines.

I think that’s the primary reason that I’m excited to be part of the team at Jama Software®. I spent 16+ years being that single vendor with tools that were integrated and were ‘good enough.’ Now, I have a product that arguably is the centerpiece of the most important of disciplines, requirements management. For without accurate requirements, on time, on budget, and meeting the needs of the end user (or warfighter) is a difficult undertaking.

RELATED: Streamlining Defense Contract Bid Document Deliverables with Jama Connect®

At Jama Software®, we support Live Traceability™ – the ability to link and trace outside our domain of requirements, to the other best-of-breed tools that support things like coding, change management, architectural modeling, testing, etc. Jama Connect® does not lock you into a single vendor but gives you the ability to continue to use the products you currently have in your arsenal. Live Traceability gives your team the ability to see the most up to date and complete up and downstream information for any requirement, no matter what state of development it is in or how many siloed tools and teams it spans.

Being a part of the Jama Connect team has allowed me to work with the most intuitive of all tools in my career. When I say intuitive, I mean I didn’t need any training to get up and running to be productive. Additionally, Jama Connect is a cloud-based product (self-hosted is also available), so no need to worry about getting your IT team engaged. If a Jama Connect project is properly set up, it should expose the bulk of the functions needed for a person working in the requirements discipline. Notice I did not say ‘requirements manager.’ Systems/Software development is a team sport, and more roles than just a requirements manager/SME will need access to the requirements. It is rather easy for a non-requirements person to access the tool, explore its functions, and be productive with limited or no training.

I continue to support Aerospace & Defense programs in my role at Jama Software. In addition to Jama Software offering a great requirements management tool, they are industry experts, and provide expert thought leadership and best practice guidance to their clients. This level of knowledge is a key distinguishing factor when searching for a requirements management tool. I am very happy to be part of this extremely energetic, client-focused company and truly looking forward to this next phase of my career.


Gary Hayes
Latest posts by Gary Hayes (see all)