Control case approach to record and model non-functional requirements

Abstract

While the functional requirements of a system can be effectively modeled through the use case driven approach, there is no standard or de facto method for modeling non-functional requirements (NFR) of the system architecture. Often such requirements are dealt with in a reactive manner, rather than proactively. Yet increasingly a contributing factor in project difficulty and failure are the NFR imposed on the solution architecture. This paper outlines a control case approach to record and model NFR. This technique enables the control case to represent the NFR from different perspectives, most typically the various operating conditions. We also propose an extension to the ''4 + 1'' view model for depicting software architecture by adding the control case view. In addition, a detailed control case modeling example is illustrated to demonstrate how these techniques may be applied during development. Taken together, we suggest that the combination of both the use case and control case views thus reflects the complete requirements across the collective system life cycle views: design, process, implementation and deployment.

Reducing complexity using an interaction room

“…[8], [9], [10], [11]). However, our annotations aim to identify critical issues within a process or system, rather than precisely specifying a particular functional or non-functional aspect (e.g.…”

Eliciting dependability requirements: a control cases based approach

“…Besides the goal oriented approach, the use cases approach has also been extended to address NFRs in some papers [18][19][20][21][22]. In [18][19][20], the misuse cases are proposed to define the scenario that a threat initiator interacts with the systems to achieve some malicious intentions.…”

Control Cases during the Software Development Life-Cycle

“…This was proposed as additional artifacts that may be applied during requirements design that complements the use case. This work was further refined and expanded upon in [15]. Subsequently, the applicability of the control case and operating condition in business process design has also been outlined [9].…”

“…These constructs are now briefly described in order to provide a fundamental understanding of how to apply these tools in the remainder of this paper. For a more complete definition of the control case and operating condition, refer to [15].…”

“…The associated risks are defined by operating conditions that apply to the various process tasks. Using the elicitation technique proposed in [15], two operating conditions are identified that may expose risks to process activities; illustrated in Figure 5.…”