Adopting Spec-Driven Development (SDD) does not require a team to overhaul their current processes, traceability models, or approval workflows. Governance efforts like those mentioned will come to the forefront for every engineer, helping teams stay aligned and ready for any audits, design reviews, or other major milestones.
This is especially true in the Aerospace and Defense industry where teams already author detailed requirements for their hardware, software, and integrated systems.
These detailed software requirements are, in fact, the essence of a specification for SDD. Therefore, A&D teams are already prepared to adopt an SDD approach for single features or broad development efforts.
Why SDD Adoption Looks Different in Aerospace & Defense
Before we take a deeper look at how and why Spec-Driven Development adoption is unique within the Aerospace and Defense industry, we should examine the challenges commonly facing teams that Spec-Driven Development mitigates.
One of the most critical challenges teams face is meeting increasingly short deadlines set by customers like the military agencies of most governments. These tight deadlines lead to scaled back products to ensure feasibility. However, with increased product velocity due to Spec-Driven Development, teams can continue to offer the full products they have grown accustomed to creating while still meeting deadlines.
Second, teams regularly face requirement and product dissociation within the development lifecycle. This is nearly nullified with automations that Spec-Driven Development enables when utilizing an intelligent engineering management platform like Jama Connect® as the centerpiece for requirements, architecture, verification, and system development.
In many industries, software developers are not as tightly beholden to a requirements specification like they are in A&D. This gives an A&D team a strong starting point for their initial Spec-Driven Development efforts and deployment.
Regulations, processes, and other forms of governing engineering development also play a large role in how A&D teams can adopt SDD.
First and foremost, when adopting this approach within Jama Connect, teams can largely keep their overall processes the same, while also reinforcing their development documentation and processes through things like Implementation Summaries generated with their code. Together, the original processes and new, more detailed development documentation paint an incredibly powerful picture of how the systems were designed and developed.
With all of this in mind, Jama Connect also provides hands-on human governance through the Review Center. Many A&D teams already practice deep review processes, meaning no major changes are needed with respect to this either.
A&D teams are uniquely poised to grasp the SDD bull by its proverbial horns and quickly adopt fast paced development while maintaining their standard engineering practices. As we dive deeper throughout this article, I hope to shed light with personal anecdotes and tangible approaches to getting started with SDD in the A&D industry.
You May Already Have Much of the Foundation SDD Requires
One of the first aspects a team must consider when proposing to adopt SDD centers around how much reuse of the current processes can feasibly be attained. As discussed earlier, it might be more than one initially considered possible. Consider the following questions.
- Does your team operate from a guiding set of Stakeholder Needs or Requirements? What about a top-level Concept of Operations or Design Reference Missions? If yes, your team is already able to provide guiding context to an LLM on why each requirement may matter to the grand scheme of an overarching system.
- Additionally, regardless of your response to the first question, does your team create system level requirements that dictate what the system shall do from a functional perspective? If yes, your team already generates the top level of a specification that is useful for dictating the overall functionality in a way that is friendly to coding agents.
- Does your team find itself refining the top-level requirements down to requirements that are atomic, unique, and independently verifiable? Even if this is simply to adhere to and show compliance to a customer’s requirement specification, then your team is ready to give SDD a trial run to see where velocity increases and code quality improves.
- When authoring requirements, completing verifications, or other governed processes within Jama Connect, does your team rely on the Review Center? If yes, you will likely see no change other than the addition of Implementation Summaries into your reviewed content.
There is also a somewhat pedantic and to some, silly, question that is worth considering. If your team struggles with writing a requirement that is too prescriptive at the lower levels, then they will be happy to hear that in many cases the AI agents appreciate those much more than humans do when using requirements to develop code.
So what do all these yes and no questions really mean?
To those who predominantly answered yes or leaned that way, there is very little to change within your organization’s requirements processes. Your Systems Engineers, Software Developers, Safety experts, and others will all speak one unified requirements-centered language that becomes the single source of truth for development.
Where SDD Fits Into the Existing A&D Development Process
Now of course, those questions do not lead us to an exact process or tactical way to implement SDD. However, from my experience, if a team is leaning towards yes for many or most of the questions above, they can simply make minor modification to their item types currently in use and integrate an Implementation Summary item type into the traceability model to tie the final bow on the process.
The addition of an Implementation Summary sounds like more work for the end user, when in fact, it is the exact opposite. A well-crafted SDD prompt to an agent encourages that the agent itself gathers evidence of what was completed and publishes that into Jama Connect.
This eliminates the need for a user to examine the code and provide documentation after it is developed. These Implementation Summaries can be defined as to what an organization believes is most important for their process, but typically include:
- Which requirements and upstream material was used for the development of the code.
- What trouble or implementation nuances were included in the generated code.
- Where there might be a technical defect due to things like no API endpoints, no known information around a specific topic, or lack of integrated hardware to do initial proof of concept confirmation.
- The date and time of this development and even, in some cases, a table of updated files, functions, and other technical call outs.
Why the Traceability Model Matters
Making a minor addition to the Traceability Information Model (TIM) allows for deeper live traceability and visibility into what code is being developed. Below are two Traceability Information Models. One is the core of a simple SDD approach, while the other is a standard Airborne approach to configuring Jama Connect.
Click the image to enlarge.
As shown, most of the SDD TIM maps directly to one or more item types within the Airborne TIM. The only major addition is the need to include a new item type for the Implementation Summary. Once modifications are complete, using the Trace View and other methods like Live Trace Explorer™ allows teams to quickly view where code is impacting requirements and vice versa.
Start With One Feature, Not the Entire Program
But where should a team really start? Throughout my career, adoption of new techniques, tools, and processes is best done with evidence. So, start small.
Pilot one Design Reference Mission down to the code and show teams how swiftly and accurately it was developed. Then move to another Design Reference Mission and execute it to prove repeatability. Prove to the team the first effort was not just a fluke, but a new method for engineering development.
Then scale an entire subsystem’s code, or if there is an eager program, and entire system’s code. This methodology has been used time and time again to bring Agile into hardware systems, adopt new techniques for welding, and approve new processes for code reviews.
My expectation is that soon it will be the same method that moves many engineering teams forward to software development with SDD.
What Good SDD Adoption Looks Like
Of course, adoption needs to be measured. To prove something to a room of engineers (read skeptics), one must provide evidence and objective data that tells the story.
Start with a few simple facts:
- Requirements will remain the authoritative source of truth, determining how a system behaves and meets safety regulations.
- Humans will remain in the driver’s seat through review and approval of requirements as well as review and approval of implementation summaries and test data.
- Impacts will be traced within Jama Connect. With those ground rules and assumptions listed, begin to gather data to prove there is meaningful improvement for the team. Measure the following:
- Time spent from pen to paper for requirements to tested code
- Hours spent debugging vs. hours spent refining a specification
- Number of major and minor defects identified in production ready code
Once this data is gathered, your team will be ready to demonstrate that SDD has increased product velocity and improved code quality.
For many teams this results in large swings in product velocity. From my experience, a sub-set of a program can see as much as a 50% increase in product velocity if staffing is left the same and buy-in is agreed to in advance. As teams expand their use of Spec-Driven Development this number can, and should, continue to grow as the process normalizes and the idiosyncrasies of the organization implementing it are synergized.
Adopt SDD Without Starting Over
Finally, it is important to take a step back and summarize what can be accomplished with SDD in the confines of the A&D industry.
First and foremost, teams are more ready to adopt an SDD approach than they may realize. Requirements and specifications are predominantly already defined and ready to be used as initial attempts at SDD code development.
Second, teams face reduced risk by proving out SDD for small features or systems before rolling the approach out to entire program.
Lastly, Jama Connect industry expert engineering consultants are here to ensure adoption goes smoothly with best practices and pitfall avoidance techniques gathered through our own anecdotal utilization of SDD, as well as lessons learned from customers that were early adopters.
Get Started Today
Explore Jama Connect for Aerospace & Defense to see how your team can pilot Spec-Driven Development while maintaining the traceability, governance, and human oversight mission-critical programs demand.
