JP2000353082A - Requirements specification description support apparatus and method, and recording medium - Google Patents

Abstract

(57) [Summary] PROBLEM TO BE SOLVED: To facilitate generation of a scenario representing a system movement from a required specification, thereby supporting writing of an accurate required specification. A use case execution unit for sequentially executing each use case included in a requirement specification based on a requirement specification described in the form of a use case according to a predetermined standard.
And a log recording unit 5 that records the execution process of each use case and obtains a history, and records the execution process of each use case included in the required specification as a log, thereby sequentially executing the use cases. It is possible to easily generate a scenario representing the behavior of the system. By referring to the generated scenario, the user can easily confirm whether there is no use case omission or omission in the described requirement specification.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a required specification description supporting apparatus, a method thereof, and a recording medium, and is particularly suitable for use in an apparatus for supporting description of required specifications used in system development of software or the like. .

[0002]

2. Description of the Related Art Generally, a system development using a computer is finally coded through a process of defining a required specification, a basic design, a detailed design, and the like, and is debugged as required to complete the development. Among them, the definition of the required specifications has a very important meaning in developing the system. In other words, if there is an ambiguous or misleading description in the required specifications, a system designed and created based on the content is either completely unusable or not expected by the user at all. Often it will be.

If the required specifications are not properly described, it is often the case that the problem of the required definition is discovered in the system development when the design is completed or after the coding is started. It is not easy to fix mistakes at each stage, and it costs enormous development costs.
On the other hand, if the first required specifications are properly described, the reworking work that occurs thereafter can be suppressed as much as possible. Therefore, it can be said that it is extremely important to describe the required specifications properly.

[0004] Conventionally, in the pre-system development stage, the required specifications are based on the functions of the system, such as the current system and the system after the improvement, or the contents of the new system, etc. , Data output, etc., were described using human words and drawings. Recently, various methods have been used to describe required specifications, and one of them is a use case called “use case” that focuses on the purpose of use rather than the function of the system. Has also appeared.

[0005]

However, there are various methods for describing the required specifications. In any case, it is checked whether or not there is any omission or error in the system design based on the described contents. It was done manually. For example, humans look at sentences and drawings themselves described as required specifications, and use them to check various things such as data generation, usage relations, output, etc., and who inputs what and what work. I was going to judge.

However, since these checks are manually performed by humans, oversights and mistakes are likely to occur. In addition, although it is possible to check to some extent using a computer or the like, it is not clear how to perform the check accurately and easily. In particular, checking the operation of the system based on the created requirements specification is
It is important to check for errors or omissions in the description of the required specifications, but this is very troublesome and time-consuming.

The present invention has been made in view of such circumstances, and enables a scenario representing a system behavior to be easily generated from a system requirement specification described based on a predetermined standard. Accordingly, it is an object of the present invention to provide a requirement specification description support apparatus and method capable of supporting accurate description of a requirement specification.

[0008]

A requirement specification description support apparatus according to the present invention sequentially executes each use case included in the requirement specification based on the requirement specification described in the form of a use case according to a predetermined standard. And a history recording means for recording a history of execution of each use case by the use case execution means.

According to another aspect of the present invention, in a branch appearing in the process of executing the use case, a branch selecting means for allowing the user to select a use case to be executed next is provided. Each use case may be sequentially executed by a dynamic process. Further, the use case execution means automatically selects a use case to be executed next in a branch appearing in the process of executing the use case, and sequentially executes each use case included in the required specification. Is also good.

[0010] Further, there is provided condition setting means for giving conditions for executing each use case included in the requirement specification to the use case execution means, wherein the use case execution means is provided with the given condition. Within the range, a use case to be executed next may be automatically selected in a branch appearing in the process of executing the use case, and each use case may be sequentially executed.

Further, in the use case execution means, in a branch appearing in the process of executing the use case, all the possible branch destinations which can be taken as the next use case to be executed are automatically selected, and the use case is included in the required specification. Each included use case may be sequentially executed.

According to another aspect of the present invention, the predetermined sequence use case representing a basic flow and the use case of an alternative sequence representing an exceptional flow can be described in association with each other. A requirement specification description means for describing the requirement specification according to a standard is provided.

In another aspect of the present invention, for each component of the required specification described in the form of the use case,
A usage relationship that uses another component from one component, a generalization relationship that creates a new component by making a partial change to the original component, or when a specific condition is satisfied in a component There is provided structuring means for structuring each of the above components by using at least one of the extended relations for processing another component.

Here, with respect to the use relationship and the extension relationship, a relationship between an event in the use case and another use case may be structured. In addition, the use case execution unit branches from an event in one use case to another use case according to the use, generalization, and extension relationship of the use case structured by the structuring unit, and executes each use case. The execution may be performed sequentially. Also, according to the relationship established between the use case of the basic series and the use case of the alternative series,
According to the relationship between the first mode in which a use case is branched to another use case and each use case is sequentially executed, and use, generalization, and extension of the use case structured by the structuring means. There may be provided a second mode in which an event in a use case is branched to another use case and each use case is sequentially executed.

According to another aspect of the present invention, when describing the required specifications, a required specification description means for describing a processing time for each use case, and an individual use description described by the required specification description means. A total time calculating means for calculating a total processing time required to perform a series of processing indicated by the history recorded by the history recording means based on the processing time of the case.

In another aspect of the present invention, importance / usage frequency setting means for setting at least one of importance and use frequency with respect to the history recorded by the history recording means; History analysis means for analyzing a history in which at least one is set and obtaining at least one of the importance and use frequency of each use case included in the history.

Further, the requirement specification description support method of the present invention
Each use case included in the requirement specification is sequentially executed based on the requirement specification described in the form of the use case according to a predetermined standard, and the execution process is recorded.

According to another aspect of the present invention, for each component of the requirement specification described in the form of the use case, a usage relationship in which one component uses another component, and a partial relationship with respect to the original component. Each of the above-mentioned components is formed by using at least one of a generalization relationship in which a new component is added with a specific change, and an extended relationship in which another component is processed when a specific condition is satisfied in one component. Be structured.

According to another aspect of the present invention, when describing the required specifications, the processing time of each use case is described, and based on the processing time of each of the use cases described above, The total processing time required to perform a series of processing indicated by the history in which the execution process of each use case is recorded is calculated.

According to another aspect of the present invention, at least one of the importance and the frequency of use is set for the history in which the execution process of each use case is recorded, and at least one of the importance and the frequency of use is set. The history is analyzed to determine at least one of the importance and use frequency of each use case included in the history.

Further, the computer-readable recording medium of the present invention provides a use case for sequentially executing each use case included in the required specification based on the required specification described in the form of the use case according to a predetermined standard. An execution means and a program for causing a computer to function as history recording means for recording an execution process of each use case by the use case execution means and taking a history are recorded.

According to another aspect of the present invention, for each component of the requirement specification described in the form of the use case, a usage relationship in which one component uses another component, and a partial relationship with respect to the original component. Each of the above-mentioned components is formed by using at least one of a generalization relationship in which a new component is added with a specific change, and an extended relationship in which another component is processed when a specific condition is satisfied in one component. A program for causing a computer to further realize a function as a structuring unit for structuring is recorded.

According to another aspect of the present invention, when describing the required specifications, a required specification description means for describing a processing time for each use case, and an individual use description described by the required specification description means. A program for further causing a computer to function as total time calculation means for calculating a total processing time required to perform a series of processing indicated by the history recorded by the history recording means based on the processing time of the case. Record

According to another aspect of the present invention, importance / usage frequency setting means for setting at least one of importance and use frequency with respect to the history recorded by the history recording means; A program for analyzing a history in which at least one is set, and further realizing a function as history analysis means for obtaining at least one of the importance and use frequency of each use case included in the history, and recording a program for realizing the function on the computer. .

Since the present invention comprises the above technical means, in the process of sequentially executing each use case included in the requirement specification described according to a predetermined standard, the executed use cases are sequentially recorded as a history. As a result, a scenario representing the flow of execution of the use case, that is, the behavior of the system is generated. Here, the predetermined criterion is defined, for example, so that the link information between use cases is included in the description of the required specification, and the execution of the use case is, for example, the use of the link destination. Reading and displaying cases. By referring to the scenario generated in this way, the user can check whether there is no omission in the intended use case and whether there is an unexecuted use case, etc. It is possible to check whether it is written.

According to another feature of the present invention, each use case is read while reading the use case of the link destination from an event in the use case in accordance with the use, generalization, and extension of the structured use case. Run sequentially,
The execution process will be recorded as history,
As a result, a scenario is generated that represents not only the flow of use cases but also the flow of events included in each use case. As a result, the flow of processing according to each use case can be understood in more detail.

According to another feature of the present invention, the total processing time required when a series of processing is executed according to the scenario is calculated using the generated scenario. As described above, by calculating the total processing time required to execute the generated scenario, one index for determining the validity or feasibility of the analysis of the current business and the request for systemization is obtained. Obtainable.

According to another feature of the present invention, instead of setting the importance and the use frequency for each use case, the importance and the use frequency are set for the generated scenario. From the setting contents, the importance and the frequency of use of each use case are obtained. This makes it possible to simplify the work of setting the degree of importance, the frequency of use, and the like, and to make the setting easy for the user to understand.

[0029]

DESCRIPTION OF THE PREFERRED EMBODIMENTS One embodiment of the present invention will be described below with reference to the drawings.

(First Embodiment) FIG. 1 shows a first embodiment of the present invention.
It is a functional block diagram showing the elementary characteristic of the requirement specification description support apparatus by embodiment. In FIG. 1, a requirement specification description unit 1 describes a requirement specification in the form of a use case according to a predetermined format. Here, a use case refers to a series of actions (events) performed by an operator when the system is operating, in a natural language for each transaction, focusing on how the system to be developed is used in business. Say what you described.

FIG. 2 is a diagram showing an example of a required specification input screen according to the present embodiment. In FIG. 2, a tree structure display screen 21 is a screen for displaying a required specification model defined for a development project of a certain system in a tree structure. A tag 22 is displayed below the screen 21.
a and 22b are provided. When one of the tags 22a is clicked, a use case input screen is displayed as shown in FIG. 2, and when the other tag 22b is clicked,
This is a business rule input screen (not shown). Note that the business rules indicate rules that must be observed in performing a task using the developed system.

FIG. 2 shows an example of information defined as required specifications in a project for developing a programming education system. In the tree structure display screen 21, the use relationship of use cases in the project is shown. A list of actors (indicating who performs each action in the use case) is shown. That is, as the tree structure shown here,
There are “use cases” and “actors” under the “project”, and “external”,
There are “internal” and “information systems”.

Further, here, the use relation of the use case in the use case “external” is particularly shown. In other words, the use cases “Provision of exercises”, “Evaluation” and “Acquisition of XX knowledge” are used in the hierarchy below the use case “External”. In the lower hierarchy, there are further use cases of “preparation” and “publication of exercises”. Furthermore, in the hierarchy below the above “Exercise Exercise”
There is a use case called

As described above, the required specifications for one project for creating a certain business system are composed of a plurality of use cases in which individual businesses performed on the system are described in units. Here, for example, when an arbitrary use case is clicked on the tree structure display screen 21 with the mouse, an input screen 23 of the use case is displayed on the right side of the tree structure display screen 21.

The example of FIG. 2 shows a state where the use case part “exercise of exercise” is clicked. In the use case input screen 23, after the use case name is displayed, an input screen for the purpose, precondition, basic sequence, alternative sequence, postcondition and data is displayed.
In FIG. 2, the input screens for the substitute series, the postconditions, and the data are not shown, but these can be seen when the use case input screen 23 is scrolled down.

The purpose column in the use case input screen 23 defines general contents of what kind of business is to be performed in the use case. In the field of preconditions, conditions that need to be performed in advance to perform the work are defined. In the example of FIG. 2, it is defined that the exercise is open to the trainee as a precondition for submitting the answer to the exercise, which is the purpose of the “implementation of the exercise”. .

The post-condition column defines what the state will be after performing the operation defined in the use case. For example, it is divided into a case where the operation is successful and a case where the operation is unsuccessful, and defines a state in each case. Note that, for example, a use case to be executed next may be described here so that a link is made to a jump destination of the use case. In the data column, what data is input and output when performing an action (event) defined in the use case is defined.

In the column of the basic series, specific contents such as who performs what in the use case are defined. Here, for each operation, an event indicating the content of a specific operation representing the basic flow of business, an actor indicating who performs the event, and other use cases used when performing the event are described for each operation. Write in order. Note that the example of FIG. 2 shows a state in which “participant trainee” is dragged from the tree structure display screen 21 and pasted on the actor column.

In the column of the substitute series, specific contents such as who performs what in the use case are defined similarly to the column of the basic series. However, the difference is that the basic series describes an event representing a basic flow of business, while the alternative series describes an event representing an exceptional flow of business. FIG. 3 is a diagram showing an example of the input screen of this alternative series.

As shown in FIG. 3, in the column of the substitute sequence, the number of the basic sequence to be substituted, an event representing the specific operation performed in place of the event of the basic sequence, and Other use cases used when the event is performed and post-processing indicating the content of the processing after the event is ended are described in order for each operation.

In the example of FIG. 3, when performing the processing (submission of the answer) of the third basic series from the top shown in FIG. 2, if the answer is inevitable, asking the instructor a question is an alternative series. Defined as an event. Returning to the processing of the third basic sequence after the event of the question ends is defined as post-processing. As another example of the post-processing, for example, after the event of the alternative sequence ends, the process may be terminated without returning to the basic sequence, or a jump to another event of the basic sequence or the alternative sequence may be performed. Can be defined.

As described above, by describing the number of the basic sequence to be replaced and the post-processing in the column of the substitute sequence, a link is established between the use case of the basic sequence and the use case of the substitute sequence. Will be done. In this way, the part where the link is established between the basic series and the alternative series will appear as a branch point of the next use case to be executed later when a scenario representing the execution process of the use case is generated. .

The use case to be executed next is specified by describing it in the column of UC (use case) of the use case of the next higher hierarchy. After the basic series of the use case to be used is completed, the process returns to the execution of the use case of the use source. When the basic series of the use case started first is completed, one scenario is completed.

As described above, in the present embodiment, unlike the drawings and the like, the required specifications are described by inputting various kinds of information in a natural language that can be understood in the same manner by anyone. , It is possible to clarify the correspondence between the functions of the system to be developed and the tasks performed using it,
The occurrence of discrepancies can be minimized. At this time, since it is sufficient to describe a predetermined input item, the use case can be easily described and the input can be easily performed. Further, as shown in FIG. 2, the description of the input items can be made by a drag-and-drop operation, so that an input error can be prevented.

In the requirement specification description section 1 of FIG. 1, based on the format input screen shown in FIG.
In addition to sequentially inputting use cases including various information such as basic series, alternative series, and data for each business unit,
Corresponding business rules are also sequentially input for each business unit. The requirement specification storage unit 2 is for storing the information on the requirement specification input as described above. Here, information on required specifications is stored for each defined use case and business rule.

The use case execution unit 3 is described according to a certain standard determined as shown in FIG. 2, and based on the information on the required specifications stored in the required specification storage unit 2, Execute use cases sequentially. Specifically, according to the link provided at the time of describing each use case, a process of sequentially reading out the linked use cases and displaying the read use cases on the monitor is performed. At this time, if there is a branch of the use case, the options at the branch destination are displayed, and the user is made to select which use case is to be executed next. This selection is performed using the branch selection unit 4 for instructing selection of one of the displayed options using a pointing device such as a mouse.

The log recording unit 5 records the execution process of each use case by the use case execution unit 3 to obtain a history of each use case used. That is, every time a use case is read or displayed on a monitor, the use case is sequentially recorded, so that the flow of how the use case is processed on the system, that is, Generate a scenario that represents how a series of tasks on the system are realized.

The scenario generated in this way is stored in the scenario storage unit 6 composed of, for example, a database.
The scenario output unit 7 outputs the generated scenario to, for example, a monitor at the same time as the scenario is stored in the scenario storage unit 6 or at any time thereafter. By referring to the scenario displayed here, the user can easily grasp the movement of the system described as the required specification.

FIG. 4 is a view showing an example of a screen in which the requirement specification description supporting apparatus of the present embodiment is generating a scenario by interactive processing with the user. The example of FIG. 4 shows an example in which a scenario generation command is executed by designating “public exercise” (use case number: UC006). In this case, first, the use case execution unit 3
Reads the use case of “Exercise Exercise” from the requirement specification storage unit 2 and displays the preconditions and events of the basic series described in the use case.

At this time, for example, when an event of an alternative series is defined for an event of a certain basic series, a branch menu representing a branch destination option is displayed in a pop-up display. In response to this, when the user selects one of the branch destinations using the branch selection unit 4, the selected content is displayed. If there is a branch, a <branch> mark is displayed as shown in FIG. In the use case “Exercise of Exercise” in FIG. 4, a state in which a basic series of events “Exercise of Exercise” is selected from the displayed branch menu is shown.

When the branch destination is selected as described above, the next use case is stored in the requirement specification storage unit 2 in accordance with the selected branch destination according to the link defined when the requirement specification is described.
Is read from and displayed. In FIG. 4, the use case of “implementation of exercise” (use case number: UC012) is read out and displayed. In this use case, an event of an alternative series is defined for the event of the third basic series, and a branch menu representing a choice of a branch destination is displayed in a pop-up.

When each use case is sequentially executed by such interactive processing by the use case execution unit 3 and the branch selection unit 4, the log recording unit 5 stores the use case used in the execution process in a scenario storage. The information is sequentially recorded in the unit 6. FIG. 5 is a diagram illustrating an example of a generation result of such a scenario. FIG. 5 shows three scenarios 001 to 003 (listing the names of use cases used), each of which differs at a branch point generated during the use case execution process. This is generated by selecting a branch destination.

FIG. 6 is a flowchart showing the operation of the use case execution unit 3. In FIG. 6, when a specific use case is designated by the user and execution of scenario generation is instructed, the use case execution unit 3 proceeds to step S1.
Then, the designated use case is read from the required specification storage unit 2. Then, in step S2, the pre-condition described in the read use case is displayed.

Next, in step S3, it is determined whether or not an alternative sequence is defined in the use case. If not, the flow advances to step S4 to display the basic sequence. On the other hand, if there is an alternative series, step S
5 and a branch mark as shown in FIG. 4 is given and displayed, and in step S6, a plurality of options (including the event of the substitute sequence and the event of the basic sequence to be substituted) Select menu).

Then, in step S7, it is determined whether the basic sequence or the alternative sequence has been selected from the displayed options. If the basic sequence has been selected, the process proceeds to step S4, where the selected basic sequence is selected. Show events for. Further, in step S9, it is determined whether there is a use case to be used.
The process proceeds to 0 to determine the end of the use case. If not, the process returns to step S3 to execute the above operation again.

If it is determined in step S10 that the use case has been completed, the process proceeds to step S11.
It is determined whether the ended use case is the first use case started, and if it is the first started use case, the process ends. If the use case is not the first use case started, the process proceeds to step S12, returns to the execution of the original use case, which is the use case of the next higher hierarchy, and then returns to step S3 to execute the above operation again.

On the other hand, if it is determined in step S 9 that there is a use case to be used, the process returns to step S 1, and another use case is newly read from the requirement specification storage unit 2. Then, the processing after step S2 is similarly performed for the new use case.

If an alternative sequence is selected in step S7, the flow advances to step S8 to display the event of the selected alternative sequence following the previous display.
Further, in step S9, it is determined whether there is a use case to be used. If there is, use returns to step S1 to read another use case from the required specification storage unit 2 and perform the processing in step S2 and subsequent steps. Do the same for the new use case. On the other hand, when there is no use case to be used, the process proceeds to step S10, and thereafter, the above-described processing is executed.

When the operation shown in FIG. 6 is executed by the use case execution unit 3, a plurality of use cases are sequentially executed by interactive processing with the user. At this time, the log recording unit 5 of FIG. 1 records each of the executed use cases as a log in the scenario storage unit 6 each time they are executed, so that the scenario showing the execution process of the use case is automatically generated. Is generated. In other words, a scenario that represents the operation of the system can be generated only by the user selecting a branch destination as needed.

The user can easily confirm the operation of the system by looking at the generated scenario. As a result, it is easy to verify the consistency of the required specifications of the business process in the system, and the problem of the business process can be easily grasped. In addition, if there is a use case that must be passed, by checking whether it is used in the scenario, it is possible to check for omission of use cases and omission of description, etc. You can also check for cases.

Further, in addition to being able to confirm the operation of the system as a log by referring to the scenario generated as described above, in the present embodiment, each use case is sequentially processed by interactive processing with the user. Because it is executed, it is also possible to experience the behavior of the system that describes the required specifications using the use case before actually designing and implementing the system.

Therefore, the system can be simulated before entering the design and implementation of the system based on the described required specifications. If necessary, by revising the required specifications, the required specifications required for developing the system can be described so that there is no contradiction or omission finally and the user can be satisfied. As a result, it is possible to minimize the inconvenience of a reworking operation at the subsequent design stage or mounting stage, and to greatly reduce the cost of system development.

In the above embodiment, the branch point occurs where the alternative sequence is defined. However, by describing a plurality of use cases as jump destinations in the post condition column of the use case input screen, This may also be a branch point for use case execution. In this case, the branch menu representing the branch destination options is displayed not only at the place where the alternative sequence is defined but also at the place where a plurality of branch destinations are defined by the post condition.

Further, in the above embodiment, in a branch appearing in the process of executing a use case, a scenario is generated based on interactive processing with the user by allowing the user to select a use case to be executed next. But,
The present invention is not limited to such an approach.

For example, some scenarios may be automatically generated by automatically selecting the next use case to be executed at the branch point. In this case, a condition setting unit 8 is provided as shown in FIG.
Conditions for executing each use case (for example, conditions for executing the use case only with the basic sequence without skipping to the alternative sequence) are given to the use case execution unit 3 in advance, and the conditions A scenario may be generated by automatically performing branch processing within the range.

Further, when a scenario is generated by performing automatic branching as described above, one scenario or several types of patterns may be selected as a branch destination to automatically generate a scenario. Alternatively, all the scenarios of all patterns may be automatically generated by sequentially selecting all branch destinations that can be taken as use cases to be executed next.

In the above embodiment, the recorded scenario includes only the use case name and number as shown in FIG. 6, but the actors related to the use case and the input / output data are used. For example, other components constituting the use case may be displayed together. Further, in the scenario recorded in the present embodiment, it is not possible to know where and what branch was taken just by looking at it, so a log of only the branch condition may be recorded in the scenario or separately.

Further, in the above-described embodiment, the use scenario that the user must pass must be visually judged by the generated scenario, but such a use case is set in advance. Thus, the device may automatically perform the check. Further, in order to verify whether or not the scenario has been completed halfway, the apparatus may automatically check whether or not the scenario has been completed in a specific use case. Further, in these cases, an error message may be output when there is a defect.

(Second Embodiment) Next, a second embodiment of the present invention will be described. In the second embodiment, when a required specification is described in the form of a use case, a use case, an actor, and the like can be described structurally. As a method of describing structured use cases and actors, UML (Unified Modeling Language) is used here.

In the above UML, the types of use, generalization (generalization)
n) and three extensions are defined. Use includes usage between use cases, generalization includes generalization between use cases and actors, and extension includes extension between use cases. Utilization, generalization, and extension here are U
Although it is based on the definition in version 1.1 of ML, it can be replaced with the one based on the definition in version 1.3 of UML.

In this embodiment, when defining the relationship between use cases, one event constituting a basic sequence in a certain use case is structured so as to correspond to another use case. There are features. By doing so, it is possible to easily understand the detailed relationship when the use case and the actor are structured.

Here, “use” refers to a relationship in which, when there is a common sub-use case that can be commonly used among a plurality of use cases, a certain use case uses the common sub-use case. Generalization refers to the relationship of making a new use case or a new actor by partially modifying the original use case or the original actor. If another use case B is defined by inheriting the use case A and describing the difference, the use case A is said to be a generalization of the use case B. Is a specialization of use case A, and the relationship between them is called a generalization relationship. The term “extension” refers to a relationship in which, in a use case that defines a basic flow of an event, another extended use case is processed when a specific condition is satisfied.

FIG. 7 is a diagram showing an example of a use case input screen according to the present embodiment, in which a part defining a basic sequence is particularly picked up and shown. In the input column of the basic series shown in FIG. 7, specific contents such as who performs what in the use case are described in the event column 31 and the actor column 32 as in the case of FIG. At this time,
If a common sub use case is used in a specific event, the name of the common sub use case to be used is described in the use use case (use UC) column 33.

In the example of FIG. 7, “use case 5” is defined as a common sub use case used in “event 2” in the basic sequence of “use case 1”.
As a result, "use case 1" and "use case 5"
And a relationship of uses is established.

The input screen shown in FIG. 7 is provided with a use UC creation button 34, a specialization button 35, and an extension button 36. Among these, the use UC creation button 34
Is a button for designating a plurality of event strings to create a common sub use case.

For example, on the input screen shown in FIG. 7, when the event sequence to be dropped into the common sub-use case is specified and the use UC creation button 34 is clicked with the mouse, the common sub-use having the specified event sequence as an element A screen appears prompting you to enter the case name and summary (purpose). A common sub use case is created by inputting a name and an outline (purpose) of the common sub use case on this screen and pressing an OK button.

FIG. 8 is a diagram for explaining the operation when this common sub use case is created. In FIG. 8, a
When there is a use case consisting of an event sequence having contents of ~ f, there is a possibility that the contents of a ~ d may be used in multiple use cases. An example is shown.

In this case, in the original use case shown in FIG. 8A, an event sequence a to d to be a common sub use case is specified, the use UC creation button 34 is clicked, and the common sub use case is further added. Enter "Use Case" as the name of the
Is input, a common sub use case as shown in FIG. 8B is created. Also, as shown in FIG. 8C, the four event strings a to d of the original use case are 1
A use case ′ replaced with two events X (using a common sub use case) is automatically created.

After the common sub use case is created in this way, it is possible to use this common sub use case from other use cases other than the use case ′. By creating a common sub-use case and making it available to multiple use cases in this way, reuse of the use cases can be facilitated, and when the use cases are described by the operator, Work load can be reduced.

The specialization button 35 is a button for instructing creation of another use case having a generalization relationship with a certain use case. For example, when the specialization button 35 is clicked on the input screen shown in FIG. 7, a use case having an event sequence having the same content as that displayed at that time appears as another input screen. Here, after changing the desired part, inputting the name and the outline (purpose) of the new use case and pressing the OK button causes another specialization having a generalization relationship with the original use case. A use case is created.

FIG. 9 is a diagram for explaining the operation when creating this specialized use case. FIG.
When there is a use case including an event sequence having contents a to e as shown in FIG. 9A, when the specialization button 35 is pressed, as shown in FIG. The input screen for another use case appears as it is. At this time, a specialization use case is newly created, but at this stage, only information indicating that the original use case is specialized is stored in the new storage area, and the contents information is stored. Is a state in which nothing is stored.

Next, a desired portion is changed on the input screen shown in FIG. 9B. In the example of FIG. 9, the content of the event c is changed to the event x. Further, when "use case" is input as the name of the specialization use case, a specialized use case is created as shown in FIG. 9C. At this time, only the difference data of the part changed from the original use case, that is, only the data of the event x is stored in the storage area of the specialization use case. The other unchanged information is read from the storage area where the original use case is stored and displayed on the screen.

In describing various use cases, it is not uncommon for the same contents to be repeatedly input for different use cases. In this case, conventionally, all use cases have been described from the beginning, but according to the present embodiment, only some of the use cases are inherited,
Since only the definitions of the different parts need be described, the amount of work of the operator can be significantly reduced.

In the specialized use case, only the difference data from the parent use case is stored. Therefore, even if a modification is made to a common part in the parent use case, the content of the modification is changed. Is also reflected in specialized use cases, so that consistency can always be maintained correctly. Therefore, compared to the conventional case where all descriptions are manually input by the operator, omission of correction and input error can be reduced, and more accurate required specifications can be described.

The extension button 36 is a button for instructing creation of another use case that is in an extended relationship with a certain use case. For example, when the extension button 36 is clicked on the input screen shown in FIG. 7, another input screen for describing the extended use case appears. Here, the branch condition from the original use case and the event string to be executed when the condition is satisfied are input, and the branch location to branch from the original use case and after the processing of the extended use case is completed By inputting the return location of the original use case to be returned, another use case having an extended relationship with the original use case is created.

FIG. 10 is a diagram for explaining the operation when creating this extended use case. FIG.
When there is a use case including an event sequence having contents a to e as in (a), when the extension button 36 is pressed, another input screen for describing the extended use case appears. Here, for example, while inputting the event strings x to z including the contents of the branch condition, the event c is used as the branch point of the original use case, and the original use case returning after executing the event strings x to z of the extended use case By inputting event d as the return location of
An extended use case as shown in (b) is created.

FIG. 11 is a functional block diagram showing the elementary features of the requirement specification description support device according to the second embodiment, which can structure the use cases and the like as described above. In FIG. 11, components denoted by the same reference numerals as those shown in FIG. 1 have the same functions, and thus detailed description thereof will be omitted.

In FIG. 11, the required specification description section 11
Like the requirement specification description unit 1 shown in FIG. 1, the requirement specification is described in the form of a use case according to a predetermined format. The requirement specification description unit 11 of the present embodiment further includes, for each use case,
Time information indicating how long it takes to execute the business indicated by the use case (for example, at least how long it takes) is also described.

The structuring designation unit 12 designates any one of use, generalization, and extension of the requirement specification information stored in the requirement specification storage unit 2. The structuring specification unit 12 specifies not only these three types of relationships but also a range in which structuring is to be performed as necessary. The requirement specification information having a use, generalization, or extension relationship generated by the structured specification unit 12 from the original requirement specification information stored in the requirement specification storage unit 2 is also stored in the requirement specification storage unit 2.

For example, when an attempt is made to create a common sub-use case from an event string of a use case stored in the requirement specification storage unit 2, the structure specification unit 12
And specify the range of event strings to be created. Further, the required specification description section 1
By describing the necessary items (purpose, preconditions, postconditions, etc. of the common sub use case) using 1,
Information on the required specifications relating to the common sub use case is created in the required specification storage unit 2.

When specializing one use case stored in the requirement specification storage unit 2 to create another use case, the generalization relationship is designated by the structure designation unit 12. At this time, an area for storing a specialization use case is secured in the requirement specification storage unit 2, but at this stage, only information indicating that the original use case is specialized is stored. The data is stored in the new storage area.

Further, by using the requirement specification description unit 11 to correct a desired location and by describing necessary items (the purpose of the specialization use case, preconditions, postconditions, etc.), the specialization is performed. Information on the required specification relating to the use case is created in the required specification storage unit 2. At this time, the information stored in the requirement specification storage unit 2 is only difference data from the original use case stored in the requirement specification storage unit 2.

When a use case stored in the requirement specification storage unit 2 is to be extended to create another use case, an extended relationship is designated by the structure designation unit 12. Further, by describing necessary items (purpose of the extended use case, pre-conditions, basic sequence of the extended use case, post-conditions, etc.) using the requirement specification description unit 11, the information of the requirement specification relating to the extended use case can be obtained. It is created in the requirement specification storage unit 2.

The mode specifying unit 13 uses the use case execution unit 3 and the branch selection unit 4 to sequentially execute each use case included in the required specification and record the execution process.
One of a simple mode for taking a simple log and a detailed mode for taking a detailed log is designated. The mode information specified by the mode specifying unit 13 is transmitted to the use case execution unit 3 and the branch selection unit 4, and processing according to the specified mode is performed in the use case execution unit 3 and the branch selection unit 4. .

In the simple mode, as in the first embodiment, a use case from a certain use case to a use case at the link destination is sequentially determined according to a link provided between a use case of a basic series and a use case of an alternative series. In this mode, scenarios are created while reading. The scenario generated when the simple mode is designated shows only the flow between use cases as shown in FIG.

On the other hand, in the detailed mode, in addition to the link provided between the use case of the basic series and the use case of the alternative series, the use mode, generalization, and extension relation (link) of the structured use case are used. In this mode, a scenario is created while sequentially reading out use cases at the link destination from events in a certain use case. The relationship between structured use cases is, as described above, a relationship established between an event constituting a certain use case and another use case. Therefore, as shown in FIG. 12, the scenario generated when this detailed mode is designated includes not only the flow of use cases but also the flow of events included in each use case.

In the scenario 001 shown in FIG. 12, at the stage where the processing of the event 1 and the event 2 of the use case 001 are performed, the processing of the events 1 to 3 of the use case 005 is executed, and thereafter, the process returns to the use case 001 again. It is recorded as a history that the processing is continued from 3. As described above, according to the scenario of the present embodiment, the processing flow can be understood in more detail, and it can be checked whether the required specifications such as omission of use cases and unexecuted use cases are appropriately described. Can be performed in more detail.

FIG. 13 is a flowchart showing the operation of the use case execution unit 3 when generating a scenario in the detailed mode. In FIG. 13, when a specific use case is specified by the user and execution of scenario generation is instructed, the use case execution unit 3 stores the specified use case in the requirement specification storage unit 2 in step S11. read out. Then, in a step S12, it is determined whether or not an extended use case is defined for the read use case.

If an extended use case has been defined, the flow advances to step S13 to display a branch mark as shown in FIG.
In 4, a plurality of options (selection menus) including the first event in the extended use case and the event in the original use case to be extended are displayed in a pop-up.

Then, in step S15, it is determined whether or not an event of the extended use case is selected from the displayed options. The extended use case is read out from the requirement specification storage unit 2. Then, the same processing as described above is performed on the read extended use case. On the other hand, when the event of the extended use case is not selected, the process returns to the execution of the original use case in step S16, and proceeds to step S18.

If it is determined in step S12 that an extended use case has not been defined for the use case read from the requirement specification storage unit 2, the process proceeds to step S17. After displaying the described precondition, step S1
Proceed to 8.

In step S18, it is determined whether the target use case is a specialization of another use case. Here, if another use case is specialized, the process proceeds to step S19, and the difference data of the use case of the inheritance source and the use case that specializes the use case is read from the requirement specification storage unit 2. Then, in step S20, a specialized use case is created by combining the read-out inheritance source use case and the differential data of the specialized use case.

Further, in step S21, the precondition described in the specialization use case created above is displayed, and then the process proceeds to step S22. On the other hand, step S
If it is determined in step 18 that the target use case is not a specialization of another use case, the process proceeds to step S22 without performing the processes of steps S19 to S21.

In step S22, it is determined whether or not an alternative sequence is defined in the use case currently targeted. If not, the flow advances to step S26 to display the basic sequence. On the other hand, if there is an alternative sequence, the process proceeds to step S23, where a branch mark as shown in FIG. 4 is added and displayed, and at step S24,
A plurality of options (selection menus) including the event of the alternative series and the event of the basic series to be replaced are displayed in a pop-up.

Then, in step S25, it is determined whether the basic sequence or the alternative sequence has been selected from the displayed options, and if the basic sequence has been selected, the process proceeds to step S26, where the selected basic sequence Show events for. Further, in step S28, it is determined whether or not there is an extended use case.
The process returns to step S11, but if not, the process proceeds to step S29.

In step S29, it is determined whether or not there is a use case to be used.
The process proceeds to 0 to determine the end of the use case. If not, the process returns to step S22 to execute the above-described operation again.

If it is determined in step S30 that the use case has been completed, the process proceeds to step S31.
It is determined whether the ended use case is the first use case started, and if it is the first started use case, the process ends. If the use case is not the first use case started, the process proceeds to step S32, returns to the execution of the original use case that is the use case of the next higher hierarchy, and then returns to step S22 to execute the above-described operation again.

On the other hand, if it is determined in step S29 that there is a use case to be used, the process returns to step S11, and another use case is newly read from the required specification storage unit 2. Then, the processing after step S12 is similarly performed for the new use case.

If an alternative sequence is selected in step S25, the flow advances to step S27 to display the event of the selected alternative sequence following the previous display. Further, it is determined in step S28 whether or not there is an extended use case. If not, it is determined in step S29 whether or not there is a use case to be further used. If there is a use case to be used, the process returns to step S11, and another use case is newly read from the requirement specification storage unit 2, and the processing from step S12 is similarly performed on the new use case. On the other hand, if there is no use case to be used, the process proceeds to step S30, and thereafter, the above-described processing is executed.

When the use case execution section 3 executes the operation as shown in FIG. 13, events of a plurality of use cases are sequentially executed by interactive processing with the user. At this time, the log recording unit 5 of FIG. 11 records each executed use case and each event as a log in the scenario storage unit 6 each time the executed use case and each event are executed. A scenario representing the execution process is automatically generated. In other words, a detailed scenario representing the operation of the system can be generated simply by the user selecting a branch destination as needed.

Returning to the description of FIG. Total time calculation unit 14
Is, using the scenario stored in the scenario storage unit 6,
This is to calculate the total required processing time required when a series of processing is executed according to the scenario. That is, in the present embodiment, for each individual use case, the time required to execute the work of the use case is described by the requirement specification description unit 11. Therefore, the total time calculation unit 14 calculates the virtual total execution time when the task is performed as in the scenario by adding up the time required for processing of each use case included in the scenario.

As described above, by calculating the total processing time required to execute the generated scenario, it is possible to determine the validity or feasibility of the analysis of the current business and the request for the systemization. The following can be obtained. For example, if you find that it takes a lot of time to run a scenario,
It is possible to take measures such as correcting or recreating the scenario. Here, the processing time is set for each use case,
The processing time may be set for each individual event in the use case.

The importance / use frequency setting section 15 sets the importance, use frequency, and the like for the scenario stored in the scenario storage section 6. In addition, scenario analysis unit 1
Numeral 6 analyzes the importance, usage frequency, and the like set in the scenario by the importance / use frequency setting unit 15, and obtains the importance, usage frequency, and the like of each use case included in the scenario.

The scenario analysis unit 16 sets the importance, the frequency of use, and the like for each use case according to a preset logic. For example, the scenario analysis unit 16
Sets the value of the importance and the use frequency set in the scenario by the importance / use frequency setting unit 15 as it is in each use case included in the scenario. here,
In the case where the same use case is included in a plurality of scenarios, when different importance is set for each scenario, the maximum importance is set for the use case. For a use case in which the number of times of use in a plurality of scenarios is larger than a predetermined value, logic such as setting a higher importance than the importance set in the scenario including the use case may be used.

When the required specifications are created, the importance and the frequency of use are set for each use case for convenience such as checking the contents of the created required specifications later. For example, a large importance value is set for a use case that is important as a business flow, or a use case that has conventionally been manually performed and the processing is complicated, so that a demand for systematization is large.

Normally, such importance, frequency of use, etc.
The setting is made for each use case by the requirement specification description unit 11, but when the number of use cases increases, the work becomes very complicated. Further, it is not always easy for an operator who describes the required specifications to determine the importance and the use frequency for each use case.

In this embodiment, it is of course possible to set the importance and the frequency of use for each use case. However, by using the importance / use frequency setting unit 15, the scenario created On the other hand, it is possible to set the importance, the use frequency, and the like. As a result, if a scenario that covers all use cases can be realized with a smaller number than the total number of use cases, setting the importance, usage frequency, etc. for those scenarios will reduce the setting work. It can be simplified.

Further, since the importance and the frequency of use can be viewed as a whole based on a scenario showing the flow of the use case, instead of looking at each use case in detail, the importance and the frequency of use can be determined by the user. This makes it easy for the user to make these settings.

Note that the processing time, importance, and use frequency set in this embodiment are merely examples. In other words, it is easier to define (or measure) the value for each use case, and to calculate the value for the scenario based on it, and that is more meaningful as the value, or vice versa, It is easier to define (or measure) a value for a scenario and calculate the value for each use case based on it, and apply it to any value that is more meaningful. It is possible to

(Other Embodiments of the Present Invention) The requirement specification description support apparatus of the present embodiment described above is constituted by a computer CPU or MPU, RAM, ROM, or the like. Can be realized by operating a program stored in the. Therefore, the present invention can be realized by recording a program that causes a computer to perform the above function on a recording medium such as a CD-ROM, and reading the program into the computer. In addition to the CD-ROM, a floppy (registered trademark) disk, a hard disk, a magnetic tape, a magneto-optical disk, a nonvolatile memory card, and the like can be used as the recording medium.

The functions of the above-described embodiments are realized when the computer executes the supplied program, and the program is executed by an OS (operating system) or other application software running on the computer. When the functions of the above-described embodiment are realized in cooperation with the computer, or when all or a part of the processing of the supplied program is performed by a function expansion board or a function expansion unit of a computer, the functions of the above-described embodiment are realized Such a program is also included in the embodiment of the present invention.

In order to use the present invention in a network environment, all or some of the programs may be executed by another computer. For example, the screen input processing may be performed by a remote terminal computer, and various determinations and log recording may be performed by another center computer or the like.

The above-described embodiments are merely examples of embodiments for carrying out the present invention, and the technical scope of the present invention should not be interpreted in a limited manner. It must not be. That is, the present invention can be embodied in various forms without departing from the spirit or main features thereof.

[0124]

As described above, according to the present invention, each use case included in the required specification is sequentially executed based on the required specification described in the form of the use case according to a predetermined standard, and the execution process is performed. Since the recording is performed, it is possible to easily generate a scenario representing the movement of the system only by sequentially executing the use cases. By referring to the generated scenario, it is possible to confirm whether there is no omission of the use case or omission of description.

As a result, it is possible to easily check whether or not the required specifications are appropriately written, and to feed back the check results to the description of the required specifications as necessary, thereby developing a system. The required requirements can be accurately described. Therefore, it is possible to prevent inconvenience that a rework operation occurs in the subsequent design stage or mounting stage, and it is possible to greatly reduce the development cost of the system as compared with the related art.

According to another feature of the present invention, for each component of the requirement specification described in the form of a use case, each component is structured using at least one relationship of use, generalization, and extension. Therefore, according to the relationship of use, generalization, and extension of structured use cases, it is possible to record the process as a history while sequentially reading the use cases at the link destination from the events in a use case As a result, it is possible to generate a detailed scenario representing not only the flow of use cases but also the flow of events included in each use case. As a result, the flow of processing can be understood in more detail, and there is no omission of use cases or unexecuted use cases regarding required specifications required for developing the system.
It is possible to check in more detail whether the required specifications are properly described, and to accurately describe the required specifications.

According to another feature of the present invention, when describing the required specifications, the processing time is described for each use case, and a series of scenarios recorded as a history with execution of the use case are described. Since the total processing time required to perform the above processing is calculated, one index for determining whether the scenario is good or bad can be obtained. As a result, it is possible to determine the necessity of modifying the required specification based on the index, and to rewrite the required specification to a more appropriate one as necessary.

According to another feature of the present invention, at least one of the importance and the use frequency is set for the generated history, the history in which the importance and the use frequency are set is analyzed, and the history is set. The importance and use frequency of each use case included in the search are calculated, so that the importance and use frequency etc. are set compared to the case where the importance and use frequency etc. are individually set for each use case. The operation can be simplified, and the setting can be easily understood by the user, and the setting can be easily performed.

[Brief description of the drawings]

FIG. 1 is a functional block diagram showing elemental features of a requirement specification description support device according to the present invention.

FIG. 2 is a diagram illustrating an example of an input screen for a use case including a basic sequence.

FIG. 3 is a diagram illustrating an example of an input screen for an alternative sequence.

FIG. 4 is a diagram illustrating an example of a screen in which the requirement specification description support device of the present embodiment is generating a scenario through interactive processing with a user.

FIG. 5 is a diagram illustrating an example of a scenario generation result according to the first embodiment.

FIG. 6 is a flowchart illustrating an operation performed by a use case execution unit in FIG. 1;

FIG. 7 is a diagram illustrating an example of a use case input screen according to the second embodiment;

FIG. 8 is a diagram for explaining an operation when creating a common sub use case.

FIG. 9 is a diagram for explaining an operation when creating a specialized use case.

FIG. 10 is a diagram for explaining an operation when creating an extended use case.

FIG. 11 is a functional configuration block diagram illustrating elementary features of a requirement specification description support device according to a second embodiment.

FIG. 12 is a diagram illustrating an example of a scenario generation result according to the second embodiment.

FIG. 13 is a flowchart illustrating an operation performed by a use case execution unit in FIG. 11;

[Explanation of symbols]

 1 requirement specification description part 2 requirement specification storage part 3 use case execution part 4 branch selection part 5 log recording part 6 scenario storage part 7 scenario output part 8 condition setting part 11 requirement specification description part 12 structuring specification part 13 mode specification part 14 Total time calculation unit 15 Importance / use frequency setting unit 16 Scenario analysis unit 21 Tree structure display screen 22a Use case tag 22b Business model tag 23 Use case input screen 31 Event field 32 Actor field 33 Usage UC field 34 Usage UC creation Button 35 Specialization button 36 Expansion button

 ──────────────────────────────────────────────────続 き Continued on the front page (72) Inventor Masahiro Noguchi 2-6-3 Otemachi, Chiyoda-ku, Tokyo Inside Nippon Steel Corporation (72) Inventor Yoshitaka Ikeda 2-6-3, Otemachi, Chiyoda-ku, Tokyo F-term in Nippon Steel Corporation (reference) 5B076 DB07 DC02 DC09 DD02

Claims (23)

[Claims] A use case executing means for sequentially executing each use case included in the requirement specification based on a requirement specification described in the form of a use case in accordance with a predetermined standard; A requirement specification description support device comprising: a history recording unit that records an execution process of each use case to obtain a history. 2. In a branch appearing in the process of executing the use case, a branch selecting means for allowing a user to select a use case to be executed next is provided. 2. The requirement specification description support device according to claim 1, wherein the requirement specification description supporting device sequentially executes the steps. 3. The use case executing means automatically selects a use case to be executed next in a branch appearing in the process of executing the use case, and sequentially executes each use case included in the requirement specification. 2. The requirement specification description support device according to claim 1, wherein: 4. A condition setting means for giving a condition for executing each use case included in the requirement specification to the use case execution means, wherein the use case execution means is provided with 2. The requirement specification description support device according to claim 1, wherein within the range, a use case to be executed next is automatically selected in a branch appearing in the execution process of the use case, and each use case is sequentially executed. . 5. The use case execution means automatically selects, in a branch appearing in the execution process of the use case, all branch destinations that can be taken as a use case to be executed next, and sequentially selects the branch destinations in the request specification. 5. The requirement specification description support device according to claim 3, wherein each of the included use cases is sequentially executed. 6. A method according to claim 1, wherein said requirement specification is defined in accordance with said predetermined criterion in which use cases of a basic sequence representing a basic flow and use cases of an alternative sequence representing an exceptional flow can be described in association with each other. The requirement specification description support device according to any one of claims 1 to 5, further comprising requirement specification description means for describing. 7. For each component of the requirement specification described in the form of the use case, a usage relationship in which one component uses another component, and a partial change is made to the original component. Structuring means for structuring each of the above components using at least one of a generalization relationship for creating a new component, and an extended relationship for performing processing of another component when a particular component satisfies a specific condition. The requirement specification description support device according to any one of claims 1 to 6, further comprising: 8. The requirement specification description support device according to claim 7, wherein the use relationship and the extension relationship structure a relationship between an event in the use case and another use case. 9. The use case execution means uses, generalizes, uses a use case structured by the structuring means.
9. The requirement specification description support device according to claim 8, wherein an event in a use case is branched to another use case and each use case is sequentially executed in accordance with an extension relation. 10. A first method of branching from one use case to another use case and sequentially executing each use case in accordance with the relationship established between the basic series use case and the alternative series use case. According to the relationship between the mode and the use, generalization, and extension of the use case structured by the above structuring means, the event in one use case is branched to another use case and each use case is sequentially executed. 9. A mode having two modes.
Requirement description support device described in 1. 11. A requirement specification description means for describing a processing time for each use case when describing the requirement specification, and a processing time for each use case described by the requirement specification description means. 11. A total time calculating means for calculating a total processing time required to perform a series of processing indicated by the history recorded by the history recording means. Requirements specification description support device described in section. 12. An importance / usage frequency setting means for setting at least one of importance and use frequency with respect to a history recorded by the history record means, and at least one of the importance and use frequency is set. 2. A history analysis means for analyzing a history and obtaining at least one of importance and use frequency of each use case included in the history.
2. The requirement specification description support device according to claim 1. 13. A method according to claim 1, wherein each use case included in said requirement specification is sequentially executed based on a requirement specification described in the form of a use case according to a predetermined standard, and the execution process is recorded. Requirement description description support method. 14. In the branch appearing in the process of executing the use case, each use case is sequentially executed by interactive processing with the user by allowing the user to select a use case to be executed next. 14. The requirement specification description support method according to claim 13, wherein: 15. The request according to claim 13, wherein a use case to be executed next is automatically selected in a branch appearing in the process of executing the use case, and each use case is sequentially executed. Specification description support method. 16. With respect to each component of the requirement specification described in the form of the use case, a usage relationship in which one component uses another component and a partial change is made to the original component. Each of the above components is structured using at least one of a generalization relationship that creates a new component and an extended relationship that performs processing of another component when a particular component satisfies a specific condition. The requirement specification description support method according to any one of claims 13 to 15, wherein: 17. The use relationship and the extension relationship are structured by structuring a relationship between an event in the use case and another use case, and according to the use, generalization, and extension relationship of the structured use case. 17. The requirement specification description supporting method according to claim 16, wherein an event in a certain use case is branched to another use case, and each use case is sequentially executed. 18. When describing the required specifications, the processing time of each use case is described, and the execution of each of the use cases is performed based on the processing time of the described individual use case. 18. The method according to claim 13, wherein a total processing time required for performing a series of processing indicated by a history in which the process is recorded is calculated.
The requirement specification description support method according to any one of the above items. 19. At least one of importance and use frequency is set for a history in which the execution process of each use case is recorded, and the history in which at least one of the importance and use frequency is set is analyzed. 14. The method according to claim 13, wherein at least one of importance and use frequency of each use case included in the history is obtained.
19. The requirement specification description support method according to any one of Items 1 to 18. 20. A use case executing means for sequentially executing each use case included in the required specification based on a required specification described in the form of a use case according to a predetermined standard, and A computer-readable recording medium on which a program for causing a computer to function as history recording means for recording the execution process of each use case and taking a history is recorded. 21. For each component of the requirement specification described in the form of the use case, a use relationship from one component to another component and a partial change to the original component are added. Structuring means for structuring each of the above components using at least one of a generalization relationship for creating a new component, and an extended relationship for performing processing of another component when a particular component satisfies a specific condition. 21. The computer-readable recording medium according to claim 20, wherein a program for causing a computer to further realize the function as described above is recorded. 22. When describing the required specifications, a required specification description means for describing a processing time for each use case, and a processing time for each use case described by the required specification description means. Recording a program for further realizing a function as a total time calculating means for calculating a total processing time required for performing a series of processing indicated by the history recorded by the history recording means in the computer. 22. The computer-readable recording medium according to claim 20, wherein: 23. An importance / use frequency setting means for setting at least one of importance and use frequency for the history recorded by the history record means, and at least one of the importance and use frequency is set. A program for analyzing a history and recording a program for further realizing a function as history analysis means for obtaining at least one of the importance and use frequency of each use case included in the history in a computer. Item 23. A computer-readable recording medium according to any one of Items 20 to 22.