Although dependent on a particular design model, a software development process (i.e., software life cycle) generally includes tasks such as developing requirements, designing and testing models and developing code. In general, a requirement is a documented need of how a particular product or service should perform. More particularly, a requirement is a statement that identifies a necessary attribute, capability, characteristic or quality of a system. Requirements are used as inputs into the design stages of a product development process and illustrate what elements and functions are necessary for a particular application.
A requirements development phase may be preceded by a feasibility study or a requirements gathering stage wherein requirements are elicited from customers, users or other stakeholders. The requirements phase may be also be broken down into analysis, specification and verification stages wherein the requirements are documented and checked for consistency, completeness, correctness and potential ambiguities.
Developing requirements, also referred to as requirements engineering, is a critical step in the development process of a software intensive system. It is well established among those skilled in the art of software design that a large percentage of defects in a system can be traced back to defects in the requirements specification. The cost of fixing requirement errors increases exponentially over the design, implementation and testing stages of system engineering.
Requirements engineering sits at the boundary between system design and user expectations and is responsible for ensuring the quality of a requirements specification. To this end, requirements engineering should be implemented in a way that ensures that the requirements specification is precise, unambiguous, consistent, and complete, and meets the expectations of the stakeholders.
There are a number of tools and methods that have been developed for supporting requirements engineers in developing quality requirements specifications. The tools vary in functionality and range from providing repositories for storing specifications to providing analysis engines based on formal methods for analyzing specifications. A number of tools also provide capabilities for configuration management and version management of specifications, and also for supporting traceability of requirements across different stages of the systems engineering life cycle. What is needed, however, is an automated system configured to provide an iterative development process that directly incorporates formal analysis results into the developmental stages of the requirements specification.
A method for developing a specification includes receiving a plurality of requirements that define the functionality of the specification, wherein the plurality of requirements are expressed using a formal model. The method further includes simulating the plurality of requirements using formal analysis and determining if the plurality of requirements satisfies a predetermined set of criteria. The method further includes generating a summary of the formal analysis and modifying at least one of the plurality of requirements if at least one of the predetermined set of criteria is not satisfied.
Additional features will become apparent from the following description and appended claims, taken in conjunction with the accompanying drawings.
The embodiments described herein relate generally to a system and process for developing a requirements specification and, more particularly, to a method for directly incorporating formal analysis results into the developmental stages of the requirements specification. The system includes a software development tool configured to implement an iterative development process that tightly integrates formal analysis algorithms into a feedback-loop enabling the results of the analysis to be incorporated into the specification.
Using this approach, the analysis algorithms and the specification formalism are complementary to one another in that the data-structures representing the analysis results are the same as the data-structures for the specification clauses. This allows analysis results to be directly used as a specification mechanism or item. In other words, a user can specify an intended result for performing a particular analysis on the specification. This system provides a very close interaction between the activities of the specification and analysis. This close interaction enables a closed-loop iterative process for specification and analysis.
The method transforms textual requirements into a formal model of requirements that are provably consistent and complete. The method bridges a gap between informal requirements and formal design models, such as statecharts that are generally used in model-based software design. Since the method internally uses formal models, it enables rapid iterative development of the requirements specification, supported by analysis algorithms operating on the specification. The overall method includes developing the specification in small increments. Each increment of the specification is followed by an application of various analysis algorithms that are designed to provide feedback to the user by either summarizing the specification at any given point in the development process, or by identifying logical defects in the specification. The summary information generated by the analysis algorithms can be incorporated into the specification as a requirement, thereby reinforcing and refining the specification.
The requirements 14 can be expressed using a variety of different design languages supported by the requirements specification. Design languages, which are often referred to as formalisms, may be graphical or textual in nature and may include, without limitation, transition systems (e.g., state machines), event sequence charts (e.g., scenario or sequence diagrams) and structured English programming. In this way, the user 16 has the capability to develop requirements 14 using different formalisms. This in turn allows the specification to involve interaction between components of a system specified by different formalisms and be stored as one unified model allowing simplified import and export to other system tools. The requirements may be stored and/or processed by a database 18.
The formal models are evaluated by analysis engines 20, which include a plurality of algorithms configured to simulate the specification requirements 14 as represented by the formal models (i.e., formalisms). The analysis engines 20 are configured to explore the consequences of what the requirements have specified at any given point in the specification development process. In particular, the analysis engines 20 evaluate the specified requirements for a predetermined set of criteria. The results of the analysis are summarized and returned to the user 16 who can then chose to inspect the results and add them to the specification, or declare upfront that all analysis results are to be added to the requirements specification as a new specification item. Adding analysis results specifies additional constraints to the specification so that the results of any further analyses have to agree with the analysis result (and additional constraint) being added, thereby refining the specification. The ability to review and modify the analysis result and refine the specification based on the results of the analysis creates a feedback loop that provides a closed-loop process for developing a requirements specification. Thus, errors or defects in the specification are identified at the developmental stage of the process and can be corrected by amending the requirements, as discussed further below.
In one approach, the set of criteria includes checking the requirements for defects relating to correctness, completeness, consistency and ambiguity. The specification being correct refers to the whether the documented requirements accurately reflect the requirements of the stakeholders (i.e., anyone who has an interest in the system, such as users, testers, development team, management, etc.). A complete specification clearly identifies its scope and completely specifies all requirements within that scope with no missing information.
A specification is consistent when there are no portions of the specification that contradict one another and the specification is fully consistent with all authoritative external documentation. In other words, a logical inconsistency in a specification may define two actions for one condition wherein the actions themselves are inconsistent. For example, in an automotive system one requirement may specify that condition “A” results in action “X,” wherein X is a braking function, while another requirement may specify that condition “A” results in action “Y,” which is an accelerating function. Since an automobile cannot accelerate while braking, the two requirements are logically inconsistent.
For a specification to be unambiguous, it should be precise and leave no room for multiple interpretations by different people. The requirements should be concisely stated without recourse to technical jargon, undefined acronyms, or other esoteric verbiage. The specification should express objective facts and be subject to only one interpretation. Vague subjects, adjectives, prepositions, verbs, subjective phrases, negative statements and compound statements are avoided. In general, formally defined languages and mathematics are definitive and non-ambiguous.
Upon providing the analysis results, the software development tool 12 provides the user 16 with the capability to “focus” on a particular portion of the specification that has been identified with a defect. By focusing on the defective portion of the specification, the user 16 has the ability to isolate and analyze the root cause of the defect. The user 16 may then generate an alternative model that corrects the defect. This model, which in essence modifies a condition associated with a requirement, can be incorporated back into the specification and re-analyzed checking for any further defects.
The following is a specific example of a process for developing a requirements specification using state-machines. The specifications are developed using a Structured Transition Systems (STS) formalism, which is introduced by example below. The method presented addresses each of the criteria for requirements set forth above. By virtue of having a formally defined language for the specification, the attribute of being precise and unambiguous is already met. The method uses analysis algorithms for automatically detecting inconsistencies and incompleteness in the specification.
The following illustrates a method using a fragment of the requirements for an embedded controller. The fragment focuses on the failure and recovery behavior of a controller. The high-level requirements are summarized as follows. The feature has two modes of operation: a) Manual Mode and b) Automatic Mode. The feature has the following states of operation: a) Disabled; b) Off; c) Engaged; and d) Failed. The feature is initially in the Off state of operation and the user has to be notified of a failure in the feature. Once a failure occurs, the feature has to be reset to recover and resume normal operations. The reset event will re-initialize the feature to its initial state.
The above modes and states of operation are representative of the sort of requirements specifications encountered in some automotive applications. The method begins by first identifying the events in the specification and classifying them as either input or output events. In the above case, we can identify the following events: 1) fail, which is an input event; 2) reset, which is an output event; and 3) notify, which is an output event. As part of this example, an output event ε is added to indicate that no action needs to be taken by the feature.
The next step in the method is to identify all the valid states in the specification. In this example, only the modes of operation and states of operation of the feature are of interest. In this specification each combination of Mode and State values is permissible. Therefore, there are 4×2=8 valid states for this specification as shown below:
In this example, we refer to particular valuations of state-variables values as states, and represent such states as a tuple of values, the state-variables in question being clear from the context. For example, the tuple <MANUAL, DISABLED> represents the state where the state-variable Mode has value MANUAL, and the state-variable State has the value DISABLED.
The STS language provides a number of language constructs to specify state transition behavior. These constructs can be used to express the textual feature requirements. One of the requirements can be expressed as a transition to a FAILED state on occurrence of the fail event. Once in a FAILED state, transitions on the fail should remain in the FAILED state. This can be expressed using the STS construct for simple transitions as shown below.
to stand for the above specification, where the predicate fail identifies all states where the State variable evaluates to FAILED.
The feature being initially in the Off state is expressed by an initialization construct of STS.
Once a failure occurs, the feature has to be reset to recover and resume normal operations. The reset event will re-initialize the feature to its initial state. This behavior on the reset event is modeled using the simple transition:
to stand for the above specification. At this state, all the requirements given in the textual specification have been formalized using the constructs of the STS language.
A number of different analyses can be performed on the specification, the most important of which is to check for consistency and completeness. These analysis algorithms have been implemented in the software development tool to provide interactive feedback to the user as the specification is being developed.
First checking for consistency, we find that the specification as it stands is consistent. However, checking for incompleteness, the analysis reports that the event fail, in the state <MANUAL,ENGAGED>, can result in a transition to either <MANUAL,FAILED> or <AUTOMATIC,FAILED>.
The incompleteness analysis has revealed that the specification is not complete with respect to changes in the Mode state-variable when specifying the transition on event fail. In fact, this information is missing from the informal specification given earlier.
At this point, the specification can be analyzed by focusing on the state-variable Model. The result of the focus operation is a “summary” state-machine whose states are just the different valuations of the Model state-variable and whose transitions specify the behavior with respect to just the Mode state-variable—in other words, it is a predicate-abstraction of the specification. The result of focusing on Mode is shown in
However, a more sensible behavior is to require that a transition cause by fail should not change the Mode state-variable. In other words, the result of focusing on Mode is expected to be the state-machine of FIG. 4—where there is not transition between manual and automatic on the event fail.
The STS language allows the user to specify this as part of the specification by importing the state-machine specified in
At this point, the consistency and completeness analyzes evaluation reports that the specification is both consistent and complete. However, at this point, the specification may be incorrect—the user might have unwillingly specified the wrong behavior. There is no general algorithm for detecting incorrectness in a specification, as there is no other formal model against which the specification can be compared—only the user's mental model to an informal written specification. The best that is possible is to analyze the specification and visualize it from different perspectives and ensure that each perspective matches with the behaviors that the user desired to capture.
In our illustration, we will simulate the specification and try various scenarios to ensure the correctness of the specification. A couple of scenarios that are expected are:
From an Init state, the sequence
In many domains, a Disabled state signifies that the component should not operate, and a special event is required make it operational. In particular, events such as failure and reset should not be allowed to change the state component if it is Disabled. Therefore, the above scenario is an anti-scenario.
The STS language allows the specification of such anti-scenarios, and it is possible to perform the above simulation and mark the simulation trace as an anti-scenario. In our case, when we perform this step, the algorithms immediately point out an inconsistency in the specification. This is because, earlier in the specification, we have specified the clauses:
which specify a transition on the fail and reset events from all states. In order to be consistent with the anti-scenario, these clauses have to be changed to:
Further, clauses have to be added to specify the behavior in the Disabled state, in order to make the specification complete:
At this stage, the specification is consistent, complete and presumably correct. The hierarchical nature of textual STS specifications are represented using a tree where the non-leaf nodes of the specification are either zoom or focus clauses that contain a sub-specification. The prototype tool supports all the analyses that we have described in the paper. Each analysis can be performed at the top level of the specification or with respect to particular sub-specifications corresponding to a zoom or focus clause.
It is to be understood that the above description is intended to be illustrative and not restrictive. Many alternative approaches or applications other than the examples provided would be apparent to those of skill in the art upon reading the above description. The scope of the invention should be determined, not with reference to the above description, but should instead be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. It is anticipated and intended that further developments will occur in the arts discussed herein, and that the disclosed systems and methods will be incorporated into such further examples. In sum, it should be understood that the invention is capable of modification and variation and is limited only by the following claims.
The present embodiments have been particular shown and described, which are merely illustrative of the best modes. It should be understood by those skilled in the art that various alternatives to the embodiments described herein may be employed in practicing the claims without departing from the spirit and scope of the invention and that the method and system within the scope of these claims and their equivalents be covered thereby. This description should be understood to include all novel and non-obvious combinations of elements described herein, and claims may be presented in this or a later application to any novel and non-obvious combination of these elements. Moreover, the foregoing embodiments are illustrative, and no single feature or element is essential to all possible combinations that may be claimed in this or a later application.
All terms used in the claims are intended to be given their broadest reasonable construction and their ordinary meaning as understood by those skilled in the art unless an explicit indication to the contrary is made herein. In particular, use of the singular articles such as “a”, “the”, “said”, etc. should be read to recite one or more of the indicated elements unless a claim recites an explicit limitation to the contrary.