In previous blogs we talk about Why do my requirements keep changing and Controlling and Managing Change during product or system development. Change can also be addressed from the perspective of change that happens after the product or system is put into operations. From this perspective the question to be addressed is: “Can the product or system meet its intended purpose in its operational environment (definition of system validation) in spite of changes to the environment or mission that may occur during operations?
These changes could be a change in inputs, a change in operational environment, an unexpected threat, an unexpected opportunity, or a change because of a failure or degraded performance of the system. Change could also result because assumptions made while defining the scope of the project turned out to be invalid. For example, the system was designed based on certain key assumptions, but after the system was put into operations, some of those assumptions turned out to be wrong. Perhaps the range of parameter inputs, the volume of inputs, or the operating environment is different than was assumed. Change can be the result of uncertainties associated with both the known-unknowns as well as the unknown-unknowns.
In light of these possible changes and uncertainties, will we be able to accomplish what needs to be accomplished? If a system is for the military or one of NASA’s exploration missions, can the need, goals, and objectives for the mission still be achieved? Can the defined mission be successfully completed?
To be successful in this type of operational environment where uncertainties and resulting change are the norm, a different, more flexible approach to product definition and design is needed.
Agile Systems vs Agile Development
I was recently made aware of the concept of “agile systems” by Rick Dove, who is chair of the INCOSE Agile Systems Systems Engineering Working Group. Rick sent me a copy of a paper on Fundamentals of Agile Systems Engineering Parts 1 & 2 that talks about both agile systems as well as agile development. You can read his paper at: https://www.parshift.com/s/140630IS14-AgileSystemsEngineering-Part1&2.pdf. What follows is my interpretation of what an agile system is and its characteristics based on the contents of the Rick’s paper coupled with my experiences.
When you see the term “agile”, the most common use is describing an approach or philosophy for the development of software systems, although there is no reason agile development cannot be applied to the development of any system as long as the appropriate organizational prerequisites are in place to support an agile development approach.
However, “agile” can also be used to refer to an attribute of the system itself. Thus agile systems-engineering and agile-systems engineering are two different things. The focus of this article is on “agile systems”.
What is an Agile System?
In Rick’s paper he defines an agile system as a system that is able to “thrive in an uncertain and unpredictably evolving environment; deploying effective response to both opportunity and threat, within mission.” “Effective response has four metrics:
- timely (fast enough to deliver value),
- affordable (at a cost that can be repeated as often as necessary),
- predictable (can be counted on to meet the need), and
- comprehensive (anything and everything within the system mission boundary).”
Of particular interest is “uncertain and unpredictably evolving environment”. In order for a system to be agile, it needs to be resilient and composable in order for it to be able to respond both reactively and proactively to new, unpredictably evolving environmental conditions. Resilience provides “the ability to repair, replace, patch, or otherwise reconstitute lost capability or performance (and hence effectiveness), at least in part and over time, from misfortune, damage, or a destabilizing perturbation in the environment.” Composable allows the system to be “reshaped” and system resources to be reconfigured as needed to respond effectively to changes due to a new threat or opportunity. In the movie “The Martian”, both of these concepts were clearly demonstrated.
Rick states: “A reactive response is a compulsory systemic counter to a threatening change in the environment, with purpose to maintain or restore competitive functional performance. A proactive response is a non-compulsory systemic initiation enabled by a change in the environment, with purpose to improve competitive functional performance.”
Dealing with Change
In my other blogs on change, I make the point that one way to address change is to “design for change”. In Rick’s paper he states: “Agile systems are designed for change. They can be augmented with new functional capability. They can be restructured with different internal relationships among their subsystems. They can be scaled up or down for economic delivery of functional capability. They can be reshaped to regain compatibility or synergy with an environment that has changed shape. These types of changes are structural in nature, and require an architecture that accommodates structural change.”
Designing for change can be accomplished by several approaches:
- design the system so that it can be changed,
- size it for more capability than is currently needed,
- include adequate margins based on risk assessment,
- rather than “hard coding” a constant, make it a variable that can be changed, and
- use a modular approach to system architecture.
Modularity is a key concept for agile systems. When using a modular approach, the system infrastructure needs to allow the modules to be interconnected as well as allow the infrastructure to be reconfigured or expanded as needed to “effectively respond” to an “unpredictably evolving environment”. In the reference paper, Rick lists ten common design principles grouped in three categories that need to be considered by the design team when designing an agile system with modularity. (See Rick’s paper for these design principles.) In Rick’s paper he provides NASA’s CubeSat program as an example of an agile system.
Requirements for an agile system
Developing requirements for an agile system is done using common systems engineering best practices.
First, a comprehensive problem analysis needs to be performed so it is clear what the purpose/mission of the agile system is. From the problem analysis a need statement can be generated along with goals and objectives for the system. For example, the Need statement may be: “An affordable, safe, and agile system architecture that allows human exploration of Mars.” Then expectations for an affordable, safe, and agile system can to be documented in the goals and objectives. Stakeholders in the mission will be involved in the definition of the problem statement and development of the goals and objectives. Drivers and constraints that need to be considered in defining the architecture are identified.
Next, various concepts for each of the lifecycle stages need to be formulated, out of which, at least one feasible (cost, schedule, technology) concept will be able to be defined. These efforts result in a scope to be defined and stakeholder expectations to be documented and baselined.
In order to define the expectations for an agile system, it is important the stakeholders involved in the project understand what the mission is, what the operational environment is, what the risks are, along with acceptance that there are uncertainties in this knowledge.
The system concepts need to address this uncertainty for each lifecycle stage. A good approach to take is based on the definition of use cases. Use cases state the “actors”, the initial conditions, the function to be performed, a nominal scenario for accomplishing the function, alternate nominal scenarios for accomplishing the function, off-nominal scenarios for each of the nominal and alternate nominal scenarios, and the final condition or state.
One thing that differentiates many traditional systems vs agile systems is the attention spent in defining alternate nominal and off-nominal scenarios. (All too often systems are defined to a very narrow set of assumed operating environments with inadequate attention to uncertainties, alternate nominal scenarios, and off-nominal scenarios because of budget or schedule considerations.)
When developing an agile system, it is important to recognize the uncertainties and risks and acknowledge the need for a system that has an architecture that can “deal with uncertainties and risks associated with operating in an uncertain and unpredictably evolving environment and being able to effectively respond to both opportunity and threat, within the defined mission parameters.”
Stakeholder expectations will evolve from this effort. These expectations will be baselined as part of the scope definition.
With a baselined scope, requirements will be derived in a top/down fashion per normal system engineering processes. Note that requirements development is an engineering activity and evolve layer by layer. Requirements at the architecture layer will be developed focusing on the needed capabilities, functionality, performance, and quality. The focus is on what, not how. These requirements will reflect the both the nominal, alternate-nominal, and off-nominal expectations for an agile system defined in the baselined scope. For more guidance on turning system lifecycle concepts into requirements, see my blog: Going from system concepts to requirements – Part 1.
The developers, following the agile design guidelines will define an architecture that meets these expectations. Then the requirements will flow down (be allocated) to the next layer of the defined architecture and the organizations responsible for the elements that make up the architecture will follow the same process to define and develop their elements that include “agility” as one of the attributes of their system of interest.
Risk Management
To me, the main value in adopting an agile system approach to systems engineering is risk management. Allowing a mission to succeed in spite of an uncertain and unpredictably evolving environment involves being able to deal with threats as well as pursue opportunities as they reveal themselves.
Is an agile system going to cost more to develop? Perhaps. However, what is the cost of a lost or failed mission? Developing an agile system could make the difference between a successful mission and a failed one. For the example need statement above about human exploration of Mars, an agile system could be the difference between the lost a crew and/or mission or a crew that accomplishes the mission and is able to return safely back to Earth. Again, this was very clearly illustrated in the movie “The Martian”.
Comments to this blog are welcome.
If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.
