Requirements are a lifelong commitment
At the start of a contract, stakeholders set out their vision for what they want from the delivered application. The project team then works to represent that vision as a set of requirements from which development can begin. The requirements should act as a blueprint for development, with each high-level software requirement mapping to a lower-level requirement, design and implementation. However, all too often, the team’s efforts diverge from this blueprint over time, resulting in an application that doesn’t align with the requirements. At best the stakeholder is disappointed. At worst, the development team opens itself up to litigation and costly remedial work.
Additional challenges arise with new applications for connected cars, interactive medical devices or industrial IoT applications that call into question when the development process comes to an end. Any newly discovered vulnerability or system compromise implies an additional requirement to counter it, bringing with it a new emphasis on traceability even into the product-maintenance phase.
This is where the lifelong commitment begins. By constructing trace links between requirements and development components from the very beginning of a project, problems such as missing or non-required functionality can be discovered earlier, making it easier and less costly to remedy. Implementing a comprehensive, strategic and automated requirements traceability process can significantly impact project deadlines and budgets, can avoid gaps between the stakeholder’s vision of the application and what is ultimately delivered, and results in an effective support vehicle for deployed connected systems.
The Art of Requirements
If all stakeholders are to share a common commitment to requirements then they must be understandable, unambiguous and precise. There are two common approaches to defining requirements, each with advantages and disadvantages:
|Uses natural language so requires no special training||
Stakeholder may prefer layman’s language while contractor leans towards technical jargon
Language is inherently imprecise and prone to ambiguity
One approach to overcoming disadvantages is to apply rules when writing requirements in much the same way as the MISRA standards are applied to C and C++ code, for example:
Use paragraph formatting to distinguish requirements from non-requirement text
List only one requirement per paragraph
Use the verb “shall”
Avoid “and” in a requirement by refactoring as multiple requirements or specifying in more general terms
Avoid conditional language such as “unless” or “only if” that are likely to lead to ambiguous interpretation
The use of key words also helps if some members of the development team are less fluent in the chosen requirements language than others.
Reduced dependence on natural language is ideal for international teams that do not share a common language
Graphical representation switches the angle of analysis from a line-by-line, itemized list of desired features to a user-focused view of how the system will interact with external elements and what value it will deliver
|Not everyone involved in the project will understand the nuances of use case diagrams|
Each use case or user story comprises several scenarios. The first scenario as illustrated in Figure 1 is always the “basic path” or “sunny-day scenario” in which the actor and system interact in a normal, error-free way.
click for larger image
Figure 1 - This example of a “sunny-day” scenario from an “allow authorized access” use case shows how a system is expected to behave when a valid key card is swiped. (Source: LDRA)
Requirements Traceability and Management
Requirements traceability is widely accepted as a development best practice to ensure that all requirements are implemented and that all development artifacts can be traced back to one or more requirements. Standards such as DO-178C, IEC 61508, ISO 26262 and IEC 62304 require bi-directional traceability and put a constant emphasis on the need for the derivation of one development tier from the one above it. Paragraph 5.5 c of DO-178C typifies this:
“Trace data, showing the bi-directional association between low-level requirements and source code, is developed. The purpose of this trace data is to:
Enable verification that no source code implements an undocumented function.
Enable verification of the complete implementation of the low-level requirements.”
The level of traceability required by standards such as this vary, dependent on the criticality of the application. For example, less-critical avionics applications designated DO-178C level (or DAL) D are known as “black box,” meaning that there is no focus on how the software has been developed. That means there is no need to have any traceability to the source code or software architecture. It is only required that the system software requirements are traced to the high-level requirements and then to the test cases, test procedures and test results.
For the more demanding DO-178C levels B and C, the source code development process is considered significant and so evidence of bi-directional traceability is required from the high-level requirements to the low-level requirements and then to the source code. Level A projects require traceability beyond the source code down to the executable object code.
While bi-directional traceability is a laudable principle, last-minute changes of requirements or code made to correct problems identified during test tend to put such ideals in disarray. Many projects fall into a pattern of disjointed software development in which requirements, design, implementation and testing artifacts are produced from isolated development phases, resulting in tenuous links between the requirements stage and the development team.
Processes like the waterfall and iterative examples show each phase flowing into the next, perhaps with feedback to earlier phases. Traceability is assumed to be part of the relationships between phases; however, the mechanism by which trace links are recorded is seldom stated. The reality is that, while each individual phase may be conducted efficiently thanks to investment in up-to-date tool technology, these tools seldom contribute automatically to any traceability between the development tiers. As a result, the links between them become increasingly poorly maintained over the duration of projects.
The answer to this conundrum lies in the “trace data” between development processes that sits at the heart of any project. Whether or not the links are physically recorded and managed, they still exist. For example, a developer creates a link simply by reading a design specification and using that to drive the implementation. The collective relationships between these processes and their associated data artifacts can be viewed as a requirements traceability matrix (RTM). When the RTM becomes the center of the development process, it impacts on all stages of safety critical application development from high-level requirements through to target-based testing.
Figure 2 reflects the importance that should be attached to the RTM. Project managers must place the same priority on RTM construction and maintenance as they do on requirements management, version control, change management, modeling and testing.
click for larger image
Figure 2 - RTM sits at the heart of the project defining and describing the interaction between the design, code, test and verification stages of development. (Source: LDRA)