LOS ANGELES AIR FORCE BASE, Calif. --
It is often said within the acquisition community that it needs to be more agile, especially with respect to software; but, what about requirements being agile too? Requirements are traditionally codified, and users establish key performance parameters – processes rarely to be revisited or updated for years despite evolving threats.
Requirements are specify what is needed by the warfighter to counter threats in space and on the ground, and those requirements go through an onerous, multi-year process that, once approved, are rarely reviewed again for several years. While this makes more sense for weapon systems like aircraft or ships, it is not responsive enough for things like software development that needs feedback on a much tighter schedule.
Col. Michael Kleppe, Air Force Space Command Space Capabilities Division chief, agrees.
“When a program builds something, it could be addressing a need from five or 10 years ago’ he said. “When the product is delivered that satisfies those requirements, especially if it’s software, it is often obsolete and outdated. We needed to have a process where the requirements are more frequently updated to match to the organization’s objectives.”
SMC is driving forward with ways to respond quickly to emerging and changing threats by pushing the requirements process below the Joint Requirements Oversight Council (JROC)-approved Capabilities Development Document level. Having a CDD is still valid, but it should be at a high level and describe the mission area that is being addressed.
One program that exemplifies how agile requirements work is Space Command and Control (Space C2). Space C2 efforts, which consists of Space Situational Awareness and Battle Management Command and Control mission areas, have whole-heartedly adopted the new requirements approach … and it’s working.
“Since the test case was initiated in August 2018, Air Force Space Command has run three iterations of the agile requirements process with much success,” said Kleppe. “This has significantly improved our ability to produce relevant software capabilities the operators need for Space C2.”
How Agile Requirements Work
In essence, a Requirements & Planning Council (R&PC) was formed consisting of operators, AFSPC and acquirers to execute the process that goes as follows:
First, high level requirements, dubbed “Epics,” are codified that describe the overarching elements needed to fight in the mission area. An example of an Epic within Space C2 is Indications & Warnings. Once an Epic is identified, it’s broken down into manageable, solvable pieces called “Features,” such as a Change Detection Alert.
Features are deemed flexible and can evolve over time as software user feedback received or threats change. The list of Features is called a Priority Backlog and is addressed as resources allow. Different levels of the R&PC meet quarterly, monthly, or weekly based on the level of discussions that need to take place.
“The information flow and cooperation during this process has been incredible,” said Kleppe. “Operators are being heard and having their true issues addressed. The acquirers fully understand what needs to be delivered and are delivering capabilities that make sense. We at the MAJCOM are better equipped to allocate resources and priorities based on this constant feedback loop and we are looking for other opportunities to implement this agile requirements process.”
For more information on the Space C2 and the Space Superiority Systems Directorate, media representatives can contact the SMC Public Affairs office at email@example.com.