The Role of Requirements In Agile System Realization Larri Ann Rosser Raytheon
[email protected] Copyright © 2014 by Larri Rosser. Published and used by INCOSE with permission.
Abstract. Requirements play a fundamental role in the realization of systems, regardless of the methodology used. Current understanding of requirements usage is strongly influenced by traditional program lifecycle paradigms. This paper highlights the fundamental contribution of requirements to system realization, reviews typical requirements usage, quality attributes and assumptions, and identifies areas where a different perspective on requirements usage can enhance agility.
Introduction The term “agile” in the dictionary refers to physical or mental nimbleness or acuity. In a technical context, it most often describes a set of software practices associated with the Agile Manifesto including scrum, test driven development and continuous integration or agile manufacturing techniques in response to the lean manufacturing movement. In today’s environment, business pressures to “do more with without more” force organizations to take a hard look at the methods and approaches used in system realization (DoD, 2014. Better Buying Power). There is mounting evidence that traditional system realization methods, although intended to ensure planned implementation of a well understood system, do not always lead to the efficient satisfaction of user needs. For example, the Chaos Report (Standish, 2013), points out that approximately half of the features included in developed systems are seldom or never used. A recent study of the impact of requirements volatility (Pena and Valerdi, 2015) reports expected requirements volatility rates ranging from less than 10% to greater than 60% percent over the life of a project. Multiple sources (Rebentisch, 1996; Lamsweede, 2000; Standish, 2013) cite changing requirements as a significant contributor to project failure. Dr. Robert Neches identifies the need to “embrace shifting requirements and manage them” (Neches, 2012) as a key element of the DoD’s Engineered Resilient Systems thrust. Findings of this nature generate rising interest in exploring broader application of agile concepts in order to produce better value for effort. Such investigation has been done before, as when Barry Boehm’s Some Future Trends and Implications for Systems and Software Engineering Processes (Boehm, 2006) concluded in 2006 that “the techniques that enable agile methods to work well on small-to-medium size projects can become sources of difficulty when applied to larger, more mission-critical projects.” It’s worth revisiting this topic in 2015 for several reasons. Methods for scaling agile, including the Scaled Agile Framework (Leffingwell, 2014) and Disciplined Agile Delivery (Ambler, 2012) have made significant progress in effectively applying agile methods to larger and more distributed efforts. Experiments like the Wikispeed project have generated learnings around applying agile techniques to diverse, hardware intensive projects. Most recently, hybrid frameworks like SAFe LSE (Leffingwell and Koehnermann, 2015) and the agile systems engineering framework proposed in “Systems Engineering for Software Intensive Projects Using Agile Methods” (Rosser, Marbach, Osvalds & Lempia, 2014) are beginning to
articulate agile approaches that work for large projects that include significant hardware design and development. These advancements in the application of agile techniques, coupled with the need to deliver more value in the face of changing needs and technical elements suggest that this is a good time to examine the application of agile concepts to key systems engineering activities such as handling of requirements. Boehm (Boehm, 2006) refers eloquently to the barrier that “THWADI” (that’s how we’ve always done it) presents to the application of agile techniques. At the time, he was referring specifically to administrative resistance to adopting agile in the face of traditional management approaches. Today, it appears that THWADI can appear on both sides of the equation – in the processes that we have traditionally used to realize systems, and in our understanding of what it means to behave agilely In order to reap the full benefit of agility we must step back from discipline and method specific examples of agile practice, identify the fundamental characteristics of agility, and apply its principles in new areas. In Lean and Agile: Synergy, Contrast, and Emerging Structure, presented at the 1993 Defense Manufacturing Conference (Dove,1993) Rick Dove offers this general definition of agility: “We can adopt a working definition of agility as: The ability to thrive in an environment of continuous and unpredictable change. The focal point here is ‘change’ - the ability to initiate it, and the ability to respond to it. ‘Thrive’ is a key word because it implies both long term success, as opposed to a lucky response, and because it implies wielding agility both as an offensive as well as a defensive capability. ‘Continuous and unpredictable’ underscores the new long-term picture but, most importantly, distinguishes agility from mere flexibility, enabling successful change even when there is little advance notice and no prior expectation.” For the purpose of this paper, we will focus on the goals of agility identified in the definition above. This allows us to consider agility in contexts beyond that in those in which agile techniques have traditionally thrived. We must also challenge ourselves to consider the fundamental value of requirements to the system realization process, independent of specific lifecycles, program operations usage or implementation approach. For example, we will not consider requirements’ role in contracts or contractual selloff, in standard reviews or productivity measurement. Like a physicist postulating a spherical cow, we will focus on the simplest set of requirements uses - enabling the conceptualization, implementation and validation of a solution. In this paper, we refer to these activities as “system realization”. On October 1, 2014, Wikipedia (Wikipedia, 2014) defines requirements management as follows: “Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project.” In current practice, requirements are often used to scope, architect and cost a solution early in the lifecycle, with the emphasis shifting from discovery to limiting changes in order to meet commitments as implementation progresses. In this paper, we refer to this as the “traditional” application of requirements. This traditional approach is particularly prevalent in Department of Defense (DoD) and other federal projects in which a customer provides an explicit definition of need and the contractor responds with firm cost and schedule commitment, as well as to projects both commercial and government that require the development of major custom physical elements or the integration of multiple items provided by different suppliers. Our definition of agility, which includes embracing changes throughout the project, does not align with the big up-front requirements approach often applied to such projects, leaving us with the question, “What is the role of requirements in agile system realization?”
Role of requirements in system realization Analysis of documented requirements practices suggests a small set of fundamental roles for requirements in system realization, regardless of approach, along with a category of management practices that focus on maintaining quality and guiding application, which we acknowledge but do not focus on in this paper. We propose the following abstract categories of requirements uses in system realization: Definition of utility: Each requirement describes some aspect of what the system must do, be or satisfy. It can describe some function that the system must perform, some standard it must meet or some attribute it must exhibit. Underpinning of realization decisions: The set of requirements described for a solution, when analyzed, reveals essential attributes of an effective implementation and identifies studies and trades that are needed to make critical architectural and design decisions. The analysis process also highlights risks and opportunities of implementation options. Confirmation of satisfaction: As described under definition of utility, each requirement describes an expectation of the solution. This information feeds the implementation process, and is also the standard used to evaluate whether the solution meets the described need. These categories of requirements use are intentionally abstract and broad. We assert that these comprise the minimum set of uses for requirements in any system realization. We must understand the need, realize a system that meets the need, and verify that the need is satisfied. While most documented requirements approaches contain significantly more practices, we assert that all practices can be bucketed into one of the broad realization categories above, or treated as management practices. As an example, Figure 1 below shows our mapping of the macro processes from the Requirements Engineering Guide for All (REGAL) (INCOSE Requirements Working Group, 2013) to the general usage categories described above. Define Utility Analyzing Requirements Deriving Requirements Eliciting Requirements Expressing Requirements Reusing Requirements Prioritizing Requirements Justifying Requirements
Underpin Realization Decisions
Confirm Satisfaction
Designing The System Managing Risk Modeling and Simulation
Verification Validation Testing Qualification
Management Practices Establishing Traceability Managing Changes Managing the Process Reviewing Requirements Negotiating Requirements
Figure 1 – Mapping of REGAL macro processes to realization purposes In an agile project environment, these broad uses may be iterated at multiple levels of and detail and by multiple teams depending on the needs of the project. Beginning with a very simple set of uses forces the team to explicitly add additional requirements activities as needs for them emerge, thereby avoiding inclusion by negligence of unnecessary work. These three fundamental roles of requirements map onto the systems engineering Vee model as shown in Figure 2 below. This mapping applies to system realization in any lifecycle model, but in an agile paradigm, the focus and intent of the activities will be slightly different.
Figure 2 – Mapping of Realization Usage of Requirements to the Vee Model On the upper left hand portion of the Vee, requirements are used to define the utility needed from the solution - to describe what the solution must do. In traditional applications, this definition is treated as exhaustive and final - in other words, the requirements define everything the system must do, in detail, from the beginning. This approach allows for a precise definition of scope and content of the solution, a detailed Big Design Up Front, and a legalistic, enumerated approach to sell off. It appears low risk, linear and predictable. The downside of this approach is that is resistant to change, and the solutions produced by it become fragile in the face of continuous and unpredictable change. If requirements are to enable a system to thrive in an environment of continuous and unpredictable change, a different philosophy is required. In general, agile techniques move from the unknown to the known through small increments of implementation. It’s expected that each increment will enhance knowledge of realization needs, and that requirements will evolve based on greater understanding as well as changes in mission, technology and other environmental factors. In such a situation, requirements can be thought of as instructive rather than prescriptive, and should be refined and expanded to the point of adequacy rather than exhaustion. The goal is to provide sufficient understanding of needs to “sketch out” the mission space that the system must address, and to identify high priority functionality and critical attributes from which an iterative realization process can begin. Moving down the left side of the Vee, key functionality and attributes form the basis of the initial architecture and conceptual design of the system. In traditional systems engineering practice, this architecture and design strive to be definitive. Options are identified, trades performed early in the system lifecycle and decisions are finalized. The expectation is that further design and implementation will add detail, but that decisions made at a system level are complete and should not change. This approach supports predictable and measurable progress towards a well defined goal, but is not receptive to discovery and change. In agile system realization, the initial architecture is deliberately austere in both documentation and implementation, providing just enough framework to support the minimal first increments of functionality. The perspective is that the team learns as realization progresses, and that any architectural and infrastructure decisions that are not yet required should be delayed in favor of a better decision based on more knowledge later. A key systems engineering task in an agile environment is assessing which requirements need to be addressed early and which should wait. Requirements to address early include those that support initial increments of functionality, lead to knowledge discovery, reduce risk or enable efficient integration for demonstration and feedback
In the bottom portion of the Vee, requirements are primarily used to guide implementation. In traditional waterfall practice, the assumption is that requirements are complete by the time that implementation begins. Every attempt is made to implement within the constraints of the defined requirements. Requirements changes are considered disruptive and are discouraged. In agile system realization, implementation is expected to contribute to requirements understanding. The process of implementation highlights decisions to be made and options to consider, which may lead to elaboration or modification of the requirements, architecture or design of the system. In addition, implementation leads to increments of functionality that can be tested and demonstrated leading to feedback that refines understanding of existing user needs or identifies addition required user functionality that can be prioritized, implemented and presented for feedback. On the right side of the Vee, the requirements (expressed as user functionality) provide the standard against which each unit of functionality is verified and validated. In traditional system realization, this tends to happen late in the program and focus on ensuring that the functionality meets the requirement as written earlier in the life cycle. The expectation in this context is that tests should be “passed” the first time, and that failure to align with the initial requirement means that the functionality should change. In agile system realization, confirmation and validation begin as soon as the first increments of functionality exist, with a different set of expectations. The intent is to assess ways in which the functionality meets user needs, and the ways in which it does not. Identification of gaps in satisfaction of user need may result in refinement of the implementation or in modification, addition or deletion of requirements. In this paradigm, testing serves to refine understanding and increase the value and efficiency of future implementation steps as opposed to simply verifying that implementation matches a requirement as written. In an agile environment, system realization does not occur in the “big bang” of a single large Vee, but rather in a series of small Vee’s each of which builds on the knowledge and the infrastructure from those that came before, as shown in Figure 3. In this way, the project leverages what is known to discover what is unknown through implementation.
Figure 3 Traditional Waterfall and Agile Expressions of the Systems Engineering V Limiting the use of requirements to these three key purposes - definition of need, underpinning of realization, confirmation of satisfaction - does not make them less important. Well articulated stakeholder requirements are critical in order to develop a solution that meets the need. However, it does relieve the systems engineer of trying to describe completely something that does not yet exist, and focuses the SE effort more on interaction with the customer in uncovering needs and documenting them just well enough to allow them to drive
the realization process. In “Agile Requirements Best Practices” (Ambler, 2013) Scott Ambler encourages us to “[transform] the urge to write requirements documentation … into an urge to instead collaborate closely with your stakeholders and then create a consumable solution based on what they tell you”. In this way, we channel our requirements efforts into discovery, implementation and improvement rather than documentation, which leads to enhanced value delivery to the customer.
An Agile Application of Requirements (Narrative) In order to consider the application of requirements in agile project realization, we will walk through a sample requirements analysis as it might be applied in an agile project environment. The example is intentionally generic in order to provide ideas that are applicable for many domains. Follow on papers are planned to present domain specific examples. This narrative is abstracted from the experiences of the authors of and members of the SE4Agile sub-team of the INCOSE Agile Systems and Systems Engineering Working Group and the results of a survey conducted as research for “Systems Engineering for Software Intensive Projects Using Agile Methods” (Rosser, Marbach Osvalds and Lempia, 2014). The following essays also informed this narrative: Jason Moccia’s “Agile Requirements Definition and Management”(Moccia, 2012), Scott Abler’s “Best Practices for Agile/Lean Documentation” (Ambler, 2013a) and “Agile Requirements Best Practices” (Ambler 2013b) and Sherif Mansour’s “A Guide To Agile Requirements Documentation - Atlassian Blogs” (Mansour, 2013a) and “Walking the Requirements Documentation Tightrope in an Agile World - Atlassian Blogs.” (Mansour, 2013b).
Definition of Utility: Vision and CONOPS Vee models of the systems engineering process start with some variation of product definition, usually in the form of a product vision or operational concept. This applies in agile system realization as well as in more traditional models - it’s necessary to define the purpose and intent of a system to be developed. Existing systems engineering activities, such as product visioning, goals definition and operational concept definition are effective in agile system realization, although the perspective may be somewhat different. For example, when describing the product vision in agile realization, the goal is not to describe everything that may be expected of the system, but rather to clearly delineate what is within the system scope and what is not. Any specific functionality that relates to the general product vision may be considered in scope for the product, with prioritization used to determine what features and functions actually make it into the product. In this situation, clarity on the key goals of the system is more important than detail in any specific area. Typically, we approach this initial product description by soliciting input from the user. The user story, a definition and documentation construct that begin in agile software engineering, often proves effective such discussions. User stories often take this format: As a [ROLE], I want to [ACTION] in order to [GOAL] This flexible, natural language structure is simple for most users to relate to and provides the systems engineer with three pieces of useful information. Roles provide insight into various user types who will interact with the system. Actions describe operational functionality that users in some role want from the system. Goals define the intent behind the functionality that the users expect. User stories can be created by the users independently, developed in a working session guided by the systems engineer, or derived from user documents by the SE and reviewed with the user.
Taken together, a group of user stories can provide a clear picture of what benefit the system is expected to provide without predefining or constraining the implementation approach. When using this approach to eliciting needs, the user stories provided by different users will vary in terminology and granularity. A key part of the systems engineering analysis is to normalize terms and level of abstraction. For the first pass, it may be useful to roll up related stories into epics or high level stories to keep focus on the general categories of function rather than getting lost in detail. This initial elicitation can be considered “done enough” when stakeholders agree on a small set of user roles and a core of stories for each role that the users believe illustrate the general scope of the system. In agile practice, the customer, often in the role of product owner, provides prioritization input on user stories or epics from an operational or mission perspective. Initial analysis of these user stories focuses on identifying critical items for early consideration from a technical perspective, including architecture drivers, risk drivers, performance drivers, areas of uncertainty where trades or research are needed, and bootstrap capabilities required for initial demonstrations. (Leffingwell, 2013, Rosser, Marbach, Osvalds & Lempia, 2014) User stories identified as needing attention in the initial pass of realization may be decomposed into more granular stories and “spikes” or research tasks and elaborated with performance standards and acceptance criteria. The goal of this analysis is to make them sufficiently clear to support first pass realization and demonstration, which leads to acquiring additional knowledge to drive the next implementation pass. Clarifications may include additional definition documents such as personas, which describe characteristics of users in different roles, or mainfests, which describe planned or existing assets that impact the system. Figure 4 shows a user story that is sufficiently detailed for an implementation pass. Keep in mind that the purpose of this initial pass is to gain knowledge that will guide further realization passes. The first pass might focus on creating an information file to download, either manually or with very simple software and implementing a very simple download approach. Questions to be answered in the first pass might be: can the GPS communicate with the computer where the client file exists? How long does the download take? Can the GPS read the prepared file? Does the default display of the information on the GPS satisfy the user’s needs? The answers to these questions provide new stories, personae and manifests as well as refinements to existing elements.
Figure 4 – Example of a user story ready for an implementation pass In a case where there is less commercial off the shelf (COTS) hardware and software and more custom development, the first pass implementation would be more austere – perhaps as simple as proving out that there is a goes-into on the GPS for every goes-out-of on the computer, or presenting a mockup of the proposed information presentation. Even with new starts, focus on getting to a small increment of usable functionality as quickly as possible, in order to complete the feedback loop and improve understanding.
Underpinning of Realization Decisions: Architecture, Design, Implementation and Integration A key output of early realization passes in an agile environment is the identification of architectural needs and top level design constraints. These can be summarized in architectural stories or system stories and documented robustly using existing systems engineering methods and notations. Note: we avoid using the term “architectural epic” because the Scaled Agile Framework (SAFe) uses that term to describe a large technology need that requires evolution of the art to fulfil. Examples of architecture and design stories are shown in Table 1. Table 1 – System Story Examples As the Architect, I want system component boundaries aligned with technical roadmaps, so that I can replace components with more advanced capabilities as they emerge. As a System Owner, I want a system that can be updated at runtime and accredited on a modular basis, so that I can minimize customer cost and downtime when bringing on new functionality As a System Administrator, I want a system that can support a minimum of 500 concurrent users, so that I can support my current user base with room for growth. As a System Designer, I want all internal data transaction logged in a central relational database, so that I can easily produce usage reports and meet forensic requirements.
There are advantages to using the story format for architectural and design requirements, including the simple known format, identification of the source (architect, system owner, etc.) of the story, inclusion of justification and a quick and easy initial documentation approach. On the other hand, some people find the story construct awkward or constraining for describing these kinds of rules. They may choose to express them as quality attributes, principles, rules, assumptions or even traditional shalls. Regardless of the format used, mappings are often made between the architectural / design statements and the functional user stories, to indicate where the statement should be applied, and indicating what should be assessed to verify compliance. The discussion above addresses ways to communicate architectural and design decisions that have impact across the system over time. Such decisions must be documented and communicated because they are likely to impact multiple teams at multiple points in the process of realization. However, we recommend that the agile characteristic of parsimony (Miller, G. 2001) be applied to architectural and system stories, because once established, they tend to work as design constraints. In an agile paradigm, many design decisions do not require such commitment, and should be reflected in implementation rather than in either a statement of constraint or allocation of a story (requirement) to a particular component. Remember that agile projects accept a certain level of rework, called refactoring, as an intrinsic part of the realization process and a desirable way to gain and apply knowledge about the system being realized. The possibility of rework should limit freedom of design choices only when it induces an unacceptable cost or schedule risk for the system. In general, agile design decisions should be handled by transformation rather than allocation. In other words, transform the story into a working capability rather than allocating responsibility for that story to a particular set of components. Doing this quickly, in small I ncrements is often the most efficient way to uncover challenges and mismatches in a chosen design approach. While it’s easy to see how this approach is applicable to heavily software-centric systems, we assert that it can be used in much more custom hardware-centric situations. For example if your system has size, weight, power and cost (SWAP-C) requirements, an approach would be have the implementation teams do initial estimates on a draft set of components. The first demo would then consist of sharing and accumulating the size, weight, power and cost totals for all the components. This quick look gives a general idea of the challenges, quickly identify research and trades to be done, and suggests possible changes to the physical architecture of the system or user stories. In an agile project, it’s expected that requirements, architecture and design will not only become more detailed as the project progresses, but will sometimes make noticeable changes in direction. This mutability throughout the project is the trade-off for avoiding large, traumatic changes late in the lifecycle, waste based on the implementation of suboptimal choices made too early, and fragility when confronted with a change in the mission requirements or technical landscape.
Confirmation of satisfaction: Demonstration, Test and Validation Confirmation that realized capabilities meet user needs begins very early in agile project realization and continues frequently throughout the project. In many agile projects, these early confirmation events consist of demonstrations, which ideally demonstrate a working capability but in some cases may exhibit models, research results, prototypes and other informative artefacts. Customers, users and product owners are needed and welcomed at these demonstrations. Depending on the character of the specific project, release of
functionality for some level of consumer or end user usage may also occur as part of the confirmation process. Their participation provides valuable feedback for the implementation teams, and also provides a continuous level setting for customers. The realization teams are constantly reminded of users’ needs, and the users are constantly reminded of what’s technically feasible. This leads to a knowledge based collaboration between the realization teams and stakeholders, focused on delivering customer value. In addition to the virtuous cycle of feedback, expectation management and improvement, demonstrations and user try-outs provide value to the team through constant dispersion of knowledge. Exposure to other team members’ work in progress encourages questions and raises concerns early, socializes new ideas and enables focus of team effort (“swarming”) to solve high priority problems. Reaping the benefits of an agile environment requires a change in perspective on integration, confirmation and test. Integration must enable frequent and early demonstration and usage, and this means that the integration team must have input into task priorities. For example, in a stateful system, it’s difficult to demonstrate anything until the start and stop modes are available. Pause, resume, power save, and so on can wait, but it’s difficult to demonstrate anything unless you can start the system and shut it down again. This incremental approach to integration implies a certain level of refactoring of the integration as well as in design and implementation. Integration may occur with mock-ups that are replaced with models that are replaced with prototypes that are replaced with production articles, with iterations in the early stages not only accepted but expected. Confirmation in this environment focuses on fitness for purpose – does the solution do what the users need to accomplish their goals? Specific requirements are “sold off” only in the case of mutually agreed upon Key Performance Parameters (KPPs). In most cases the focus is on whether the implemented functions fulfil the mission needs. Because confirmation has been ongoing throughout the system realization, there is not a single, large comprehensive event at the end of the project. Final confirmation of satisfaction comes from end to end application of previously evaluated capabilities in a mission-realistic environment. Since functions and components have demonstrated, refined and possibly piloted throughout the project, there are fewer latent defects and minimal misunderstandings between the realization team and the stakeholders.
A Changed View of Requirements The example above describes some techniques for employing requirements in agile system realization. In addition to providing practical advice for applying requirements in agile environments, this narrative highlights some changes it the way we must think about requirements in an agile environment – their structure, the quality attributes by which we judge them and the assumptions we make about them. While we fully expect that each reader will recognize those paradigm changes most applicable to specific situations, we’d like to emphasize some that appear to have broad applicability
Requirements Structure The “shall statement” and its derivatives, “wills” and “shoulds” are a commonly accepted construct for describing requirements. They are expected to be unambiguous, clear, complete and verifiable. This approach to requirements is effective in directing and validating specific technical outcomes. In an agile environment, other constructs may better serve the goals ensuring that user needs are met while remaining robust to changes in need, evolution in technology and operations, and innovative realization approaches. For functional requirements, user stories
and related concepts like epics and features provide a richer description of the need with less constraint on implementation. Non-functional requirements (performance, reliability, etc.) may be expressed as user stories (if the focus is on the user experience of the requirement) or as shalls if the focus is on meeting a technical standard. In some cases, such expectations are better treated as quality attributes, principles or rules that are applied to the realization of the system as a whole and verified through inspection (peer reviews) and total system testing rather than as separate requirement items. In an agile environment, the intent of requirements is still to articulate the purpose of the system, but the focus shifts from directing the implementation of the technical system to ensuring the satisfaction of user needs, which leads us to value requirements descriptions that focus on user needs first, and on technical constraints that are expressed abstractly in requirements and made concrete in implementation.
Quality Attributes Requirements quality attributes may apply to a requirements set or to individual statements. At the set level, traditional waterfall projects expect requirements to be prescriptive and exhaustive, in order to provide a clear and complete description of the project scope that enables the development of a Big Design and an end to end implementation schedule. In an agile environment, a requirement set is expected to be instructive and sufficient, providing enough information to kick-start implementation, with the expectation that details will emerge as understanding grows and the system matures. There are subtle differences as well as similarities between quality attributes of traditional requirements and user stories, which form the majority of requirements for most agile projects. While they share some attributes (atomic, independent, testable) and related needs (necessary vs. provides user value) there are some areas in which the two diverge. For example, in Six Attributes of Good User Stories (Snead, 2013), Chuck Snead calls out “negotiable” as a key attribute of a good user story. This attribute is not reflected in attribute sets for traditional shall statements. The differences in quality attributes desired by requirements in agile vs non-agile projects stem largely from differences in expected usage of the requirements, as described in the assumptions discussion below.
Assumptions In a traditional waterfall project, we expect requirements to be elaborated early, frozen once and then maintained in as static as possible a state until the system is signed off by proving that we meet the specifics of the requirements as written. This approach is aligned with the goal of executing the planned implementation of a well understood system. As discussed in the introduction to this paper, this goal is often not met in practice, nor does it always achieve the desired results. In an agile paradigm in which our primary goal is to deliver maximum value to solving the user’s mission problem as efficiently as possible, we assume that we will freeze requirements incrementally. Those requirements for which there is no pressing need for finalization remain in changeable in anticipation of additional implementation-based understanding and unavoidable changes in the environment, mission and available technology. We also assume that requirements that have been defined to the best of our ability and frozen for implementation can be revisited at a later date, either as part of a planned cycle or in response to a pressing need.
In traditional waterfall models, requirements are expected to be decomposed to a leaf level, under the assumption that there is only one opportunity to unpack requirements and select a design approach. In an agile paradigm, much of the design is allowed to emerge as implementation progresses, and requirements are not expected to uncover all factors that influence design. In such an environment, requirements are decomposed sufficiently to allow implementation to begin, with the assumption that further analysis and decomposition can occur as new requirements or new aspects of existing requirements are brought into focus by implementation needs.
Conclusion When effective, agile system realization offers many benefits, including quicker initial operational capabilities and robustness to change in mission needs and technology landscape. In addition, agile realization addresses the current concern about realized but unused functionality and brings operational relevance to the forefront when evaluating satisfaction of need. Reaping the benefits of agile realization at a system level requires separation of the work we do from current project paradigms and evaluating their relevance to the fundamental process of solution realization. This paper attempts that analysis for practices associated with requirements. In an agile paradigm, requirements act as tools to define needs, guide implementation choices, and confirm satisfaction. Many existing requirements practices add value to these usages, and adapt easily to an agile paradigm through iterative application. We recommend that these processes be applied in agile environments and refined agilely as our understanding of best practices increases. Other requirements practices primarily serve current lifecycle processes and expectations. We recommend that these practices be examined for relevance and applied only when they add value. We acknowledge that in some cases, the value added will not be directly related to the solution realization, but rather to the achievement of that realization in specific circumstances or with specific customers. We recommend applying those processes that enhance the ability to realize the solution in your specific circumstances, modifying as necessary to minimize their friction with your agile cadence. Challenges in the recommended application of requirements practices fall into several categories. Some are the normal growing pains associated with operating in a changed environment. Practices, templates, tools and expectations must evolve to match that environment better. Others are related to overloaded use of requirements for contractual, estimation and measurement purposes. In these cases, we encourage you to ask these questions: “What is the fundamental goal of this activity?” “Is that goal relevant in an agile paradigm?” “If so, what is the most effective way to achieve that goal?” In some instances, these challenges are exacerbated by business or customer processes and rules that are closely coupled with more traditional waterfall style realization. These cases necessitate communication, negotiation and collaboration with customers and leaders to effect change. We intend that future papers will document case studies of requirements usage in agile system realization in specific customer environments, such as DoD, healthcare, and automotive, highlighting both commonalities with this general approach and specific activities related to customer, regulatory, and technical issues within that domain. In this way, we will increase our understanding and enhance our application of requirements to agile system realization.
References
Ambler, Scott. 2012. “Disciplined Agile Delivery.” IBM Press __________. 2013a. “Best Practices for Agile/Lean Documentation.” Best Practices for Agile/Lean Documentation. Ambysoft Inc. April 19. http://www.agilemodeling.com/essays/agileDocumentationBestPractices.htm#Needs OfActualConsumers __________. 2013b. “Agile Requirements Best Practices.” Agile Modeling. Ambysoft Inc. April 19. http://agilemodeling.com/essays/agilerequirementsbestpractices.htm Boehm, Barry. 2006 Some Future Trends and Implications for Systems and Software Engineering Processes.” gttp://sunset.usc.edu/events/2006/CSSE_Convocation/publications/BoehmFutureTren dsandImplicationsforSSEP.pdf DoD 2010. “Better Buying Power” Department of Defense http://bbp.dau.mil/ Dove, R. 1993. “Lean and Agile: Synergy, Contrast, and Emerging Structure” Defense Manufacturing Conference '93, San Francisco, CA, November 29 - December 2, 1993. http://www.parshift.com/Files/PsiDocs/Rkd93Art2.pdf INCOSE Requirements Working Group 2013. “REGAL: Requirements Guide for All” Justice, J. 2006, “Team Wikispeed” http://wikispeed.org/ Lamsweede, A. 2000 “Requirements Engineering in the Year 00: A research perspective.” Proceeding of the 22nd International conference on Software Engineering” (ICSE’2000), Limerick, Ireland, 5-19, ACM Press. Leffingwell, et al 2014. “Scaled Agile Framework 3.0.” http://www.scaledagileframework.com/ Leffingwell, D. and Koehnermann, H. 2015. “Scaled Agile Framework for Lean Systems Engineering (SAFe – LSE)” http://www.safe-lse.com/ Mansour, Sherif. 2013a. “A guide to agile requirements documentation.” Atlassian Blogs. Atlassian. http://blogs.atlassian.com/2013/07/agile-requirements-documentation-a-guide/. ______. 2013b. “Walking the Requirements Documentation Tightrope in an Agile World.” Atlassian Blogs. Atlassian. http://blogs.atlassian.com/2013/07/agile-requirements-documentation/ Miller, G. “The Characteristics of Agile Software Processes” Proceedings of the 39th Int’l Conf. and Exhibition on Technology of Object-Oriented Languages and Systems (TOOLS’01)1530-206 7/01 Moccia, Jason. 2012. “Agile requirements definition and management.” Scrum Alliance. February 10. https://www.scrumalliance.org/community/articles/2012/february/agile-requirementsdefinition-and-management. Neches, R. 2012. “Engineered Resilient Systems (ERS): Insights and Achievements within the ERS Secretary of Defense Science and Technology (S&T) Priority” 15th Annual NDIA Systems Engineering Conference San Diego, CA | October 25, 2012 http://www.dtic.mil/ndia/2012system/ttrack314773.pdf Pena, M and Valerdi, R. 2015. “Characterizing the impact of requirements volatility on systems engineering effort”, Systems Engineering Volume 18, Issue 1, pages 59–70, January 2015 Rebentisch, E. 1996. “Preliminary observations on program instability, White Paper LEAN 96±03, Lean Aerospace Initiative Working Paper.” Massachusetts Institute of Technology, 1996. Rosser, L., Marbach, P. Osvalds, G. Lempia, D. 2014 “Systems engineering for software intensive projects using agile methods” INCOSE International Symposium Las Vegas, NV, June 30–July 3, 2014 Volume 24, Issue 1, pages 729–744, July 2014
Snead, C. 2013. “Six attributes of good user stories”, Blog: The Adaptive PM https://theadaptivepm.wordpress.com/2013/05/31/six-attributes-of-good-user-stories/ Standish Group, 2013, “Chaos manifesto 2013: think big, act small” http://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf Wikipedia, 2014. “requirements management.” 2014. Wikipedia. Wikimedia Foundation. October 13. http://en.wikipedia.org/wiki/requirements_management .
Biography Larri Rosser is a Raytheon Certified Architect in Raytheon Intelligence, Information and Services. She has 30 years industry experience in aerospace, defense and computing technology, multiple patents in the area of human-computer interface and a BS in Information Systems and Computer Science from Charter Oak State College. Currently, she holds the role of Chief Engineer within in the IPx mission area, where she practices Agile Systems Engineering with a cross functional team.
