JP3887571B2 - Software design requirement extraction support method, software design requirement determination support method, software design support method, and program - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a technique for reflecting not only functional requirements but also non-functional requirements when designing software architecture.
[0002]
[Prior art]
When designing software architecture, traditionally, the focus is on functional requirements, and non-functional requirements such as high extensibility often depend on the skill of the designer to consider how much they are considered. It was not necessarily reflected in the design. If non-functional requirements are not reflected at the time of software architecture design, it is often difficult to cope with external changes such as specification changes and platform changes.
[0003]
Also, object-oriented analysis / design techniques such as the OMT method (J. Rambo et al., Translated by Eiichi Hanyuda, Object Oriented Methodology OMT Modeling and Design, 1992.7 ISBN4-8101-8527-3) The work items at the macro level, such as extracting relations, are clearly shown. However, the conventional object-oriented analysis / design technique does not clearly indicate the work items to make the configuration easy to cope with when external fluctuations occur in the future. The cost of developing software that satisfies the requirements will be high.
[0004]
[Problems to be solved by the invention]
In today's highly complex systems, it's not just a function that customers need. In addition, customer requirements themselves are ambiguous, and as development progresses, the required specifications gradually become clear. In order to be able to cope with such external changes such as changes in requirements, it is possible to clearly track where the generated factors affect the software and how it should be corrected. It is necessary to do so.
[0005]
To that end, the current design must be able to clearly explain why it is. This is because in order to be strong against specification changes, it is necessary to assume the specification change in advance and design it to reflect that, and this is the reason why it is such a design. . Therefore, when designing software, it is necessary to make it in advance so that it can cope with various variations, and this is the reason why the grounds of design must be emphasized.
[0006]
The present invention has been proposed in order to solve the above-described problems of the prior art, and its purpose is to determine which part is affected when external fluctuation occurs and how to correct it. To provide a better way to reduce the total cost of software development and to develop software with high customer satisfaction.
[0007]
In other words, the first object of the present invention is to enable efficient extraction of design requirements reflecting not only functional requirements but also non-functional requirements as design requirements to be built in regarding the configuration and structure of the software to be designed. Thus, it is to provide a software design requirement extraction support method that can reflect various non-functional requirements in the design as the basis of the design.
[0008]
The second object of the present invention is software that can efficiently determine the design requirements to be adopted by classifying and arranging the design requirements reflecting functional requirements and non-functional requirements and limiting them to only important design requirements. It is to provide a design requirement determination support method. The third object of the present invention is to provide a software design support method capable of efficiently designing a software architecture that can cope with various external variations based on design requirements reflecting functional requirements and non-functional requirements. Is to provide.
[0009]
[Means for Solving the Problems]
In order to achieve the above object, the present invention extracts events that affect the realization of functional requirement items by individually comparing the characteristics to be considered in software design for each functional requirement item, and non-functionality for each event. By comparing requirement items individually, design requirements reflecting not only functional requirements but also non-functional requirements can be efficiently extracted.
[0010]
The definitions of important terms in the present invention are as follows.
“Design requirements” are specific requirements that should be built in regarding the configuration and mechanism of the software to be designed, and in order to achieve this, the specific configuration and mechanism of the software to be designed can be determined. Information that expresses the content. For example, it is information such as providing a mechanism capable of performing the process A, a configuration capable of holding the information B, and a configuration capable of changing the part C, but the information expression format is not limited at all.
[0011]
“Function request” means a specific function required for the designed software, and is a term generally used in the field of software engineering.
“Non-functional requirements” means various requirements other than the specific functions required for the software to be designed. For example, performance requirements, restrictions on installation targets, reusability, expandability, maintainability, It is a broad concept that includes various constraints and conditions such as security and ease of use. This “non-functional requirement” is also a term commonly used in the field of software engineering.
[0012]
“Characteristics to be considered in software design” means various characteristics to be considered in general software design. For example, it is a characteristic for quality evaluation that is generally defined in the field of software engineering. It is possible to use “architecture characteristics” reconstructed based on certain “quality characteristics”. Architectural characteristics include many architectural characteristic items such as “specification stability”, each of which defines a question for inducing an event that affects the realization of the functional requirement item. “Characteristics to consider when designing software” is not limited to “architecture characteristic items”, but is a broad concept that includes other various characteristic items that have been defined or characteristic items that have been defined in advance by developers, etc. is there.
[0013]
“Events that affect the realization of functional requirement items” means any event that affects the method of realizing the target functional requirement item or that makes it difficult to implement. It is a broad concept that includes various other events.
“Software architecture” is information that expresses the relationship between the entire structure of software and the components that constitute each part, and is a design policy for the entire software. This “software architecture” is also a term commonly used in the field of software engineering.
[0014]
  The invention of claim 1A computer having an input operation unit such as a keyboard, an information storage unit such as a memory, a calculation unit that searches for and extracts information that is input or stored, and a display screen that displays information extracted by the calculation unit In the software design requirement extraction support method that supports the design of the design target software architecture,
A quality characteristic storage step for preliminarily storing in the information storage unit the quality characteristics to be considered when performing software design;
A request item receiving step of receiving input of function request items and non-function request items of the design target software from the designer via the input operation unit of the computer, and recording them in the information storage unit of the computer,
A function for the operation unit to individually compare a quality characteristic stored in the information storage unit in advance for each function request item recorded in the information storage unit and to display the comparison result on a display screen of a computer Item-quality characteristic display step;
A risk acceptance step for accepting a risk affecting the realization of each function requirement item determined by the designer based on the comparison result displayed on the display screen from the designer via the input operation unit;
Risk that the calculation unit individually compares each risk received through the input operation unit with the non-functional requirement item stored in the information storage unit, and displays the comparison result on the display screen of the computer A non-functional requirement item display step.
[0015]
According to this method, by comparing the characteristics to be considered in the software design for each function requirement item, it is possible to extract an event that affects the realization of the function requirement item based on the comparison result. Then, by comparing non-functional requirement items individually for each extracted event, design requirements reflecting not only functional requirements but also non-functional requirements can be efficiently extracted based on the comparison results. . Therefore, by adopting the design requirements obtained by this method, various non-functional requirements can be reflected in the design as the basis of the design.
[0016]
  The invention of claim 2Function request item candidates and non-function request item candidates prepared in advance based on past data are stored in the information storage unit, and prior to the request item receiving step, the calculation unit stores the information in the information storage unit. A step of displaying the function request item and the non-function request item which are displayed on the display screen.
  According to this method, if there is a corresponding candidate prepared in advance based on past data, it is possible to input a function request item and a non-function request item simply by selecting it. It is possible to efficiently input all necessary requirement items simply by creating only.
[0017]
  The invention of claim 3The risk accepting step accepts the degree of influence on the realization of the function request item for each risk, and the risk-non-functional display step extracts a risk that is equal to or higher than a preset reference value. Features.
  According to this method, only the events whose influence level is higher than the reference value are mechanically extracted from the events obtained as candidates, and the number of events to be extracted is automatically determined by removing the events with low impact level. Since the number of events can be reduced, the efficiency of event extraction can be increased and the efficiency of subsequent operations can be increased.
[0018]
  The invention of claim 4The request item accepting step accepts the degree of satisfaction for each non-functional requirement item, and the risk-non-functional requirement item display step extracts and displays a non-functional requirement item equal to or higher than a preset reference value. It is what is to be done.
  According to this method, from the design requirements obtained as candidates, only the design requirements whose non-functional requirement item satisfaction is equal to or higher than the standard value are mechanically extracted, and the design requirements with low satisfaction are removed. Since the number of design requirements to be reduced can be automatically reduced, it is possible to increase the extraction efficiency of design requirements and the efficiency of subsequent operations.
[0019]
  The invention of claim 5In addition to the invention of claim 1,
The countermeasure plan prepared by the designer based on the risk-non-functional requirement item displayed on the display screen in the risk-non-functional display step is received via the input operation unit of the computer, and this is received in the information storage unit. A countermeasure proposal receiving step to be stored in
Classification in which each countermeasure plan and importance are received from the designer via the input operation unit in a state where each countermeasure plan in the information storage unit is displayed on the display screen, and the calculation unit stores them in the information storage unit A reception step;
An importance level display step in which the calculation unit classifies and arranges each countermeasure plan received in the classification reception step according to the importance level and displays it on a display screen;
A relationship receiving step for receiving information on the relationship between the countermeasure plan and other countermeasure plans related to the countermeasure plan from the designer for each countermeasure plan having a high importance displayed in the importance display step, and storing the information in the information storage unit; ,
The calculation unit classifies and arranges each countermeasure plan stored in the information storage unit for each countermeasure plan having a predetermined relationship and displays it on the display screen, and selects design requirements for each group from the designer. A selection information receiving step of receiving information and storing the information in the information storage unit.
[0021]
According to this method, a plurality of design requirements reflecting functional requirements and non-functional requirements are classified and arranged, and a plurality of highly correlated design requirements are integrated into a higher level design requirement. The design requirements are limited to a smaller number of important design requirements by extracting currently important design requirements determined by the group, current work scope, level of detail such as work phase, concreteness, etc. can do. And about the important design requirements limited in that way, the number of design requirements can be narrowed down efficiently by sequentially selecting design requirements for each group of design requirements having a predetermined relationship. Therefore, according to this method, design requirements reflecting functional requirements and non-functional requirements are classified and limited to only important design requirements, and the limited design requirements are more efficiently based on the relationship between design requirements. Therefore, design requirements to be adopted can be determined efficiently.
[0022]
  The invention of claim 6The relationship receiving step receives a conflicting relationship that makes it difficult to adopt another countermeasure when one countermeasure is adopted, and the selection information receiving step eliminates the conflicting relationship from the designer. It is characterized in that it accepts selection information for deleting a countermeasure for this purpose.
[0023]
  The invention of claim 7The relationship receiving step is to receive a similar and / or dependent relationship that, when one countermeasure is adopted, is similar to that when another countermeasure is adopted, the selection information receiving step is a designer Therefore, it is characterized in that selection information for deleting other countermeasures that are similar and dependent on the countermeasure specified by the designer is received.
[0024]
According to these methods, when multiple design requirements are in a conflicting relationship, a selection is made to eliminate the conflicting relationship, and when multiple design requirements are in a similar relationship, the number is reduced. This sort of selection can be made. Therefore, for the design requirements extracted as important design requirements, the number of design requirements can be narrowed down appropriately and efficiently by sequentially selecting appropriately according to the relationship between the design requirements and the current importance. Therefore, only a smaller number of the most important design requirements can be easily determined as design requirements to be adopted.
[0025]
  The invention of claim 8The importance level displaying step displays a countermeasure whose current importance level of each countermeasure is equal to or higher than a predetermined reference value set in advance.
  According to this method, after classifying design requirements obtained based on functional requirements and non-functional requirements, only design requirements whose current importance level is higher than the standard value are mechanically extracted, and the importance level is increased. By removing relatively low design requirements, the number of design requirements to be extracted can be automatically reduced, so that the extraction efficiency of design requirements can be increased and the efficiency of subsequent operations can be increased.
[0028]
  In addition,The invention of claim 9 or 10 is the invention of claim 1 or 5.The method of the present invention is ascertained from the viewpoint of each program, and according to each program, the same operation as the above-described operation can be obtained for each corresponding method.
[0029]
DETAILED DESCRIPTION OF THE INVENTION
Embodiments of the present invention will be specifically described below with reference to the drawings. However, the embodiment described here does not limit the present invention at all, and merely illustrates one aspect of the present invention.
[0030]
The present invention is typically realized by controlling a computer with software. The software in this case realizes the operational effects of the present invention by physically utilizing computer hardware, and a suitable conventional technique is applied to a portion to which the conventional technique can be applied. Furthermore, specific types and configurations of hardware and software that realize the present invention, a range processed by software, and the like can be freely changed. For example, a program that implements the present invention is one aspect of the present invention.
[0031]
[1. Software design support method]
FIG. 1 is a flowchart showing an outline of a software design support method to which the present invention is applied together with a data flow. As shown in FIG. 1, requests from stakeholders such as customers, managers, project managers, etc., are classified and input by a designer into function request items D11 and non-function request items D12 (S110). ).
[0032]
Next, risk items and countermeasures for the risk items are extracted (S120). That is, for each recorded function requirement item D11, the architecture characteristic items Da prepared in advance are sequentially combined (S121), and the risk item D21 is extracted and recorded for each combination (S122). The non-functional requirement items D12 are individually compared, and the possibility D22, the tolerance D23, and the countermeasure plan D24 are extracted and recorded (S123).
[0033]
Here, “architecture characteristic item” is a reconfiguration based on the “quality characteristic” that is generally defined as a characteristic that should be considered when designing software architecture, and is considered when designing software architecture. It represents the characteristic item that should be done. In addition, “risk” is a concept included in “events that affect the realization of functional requirement items” in the present invention. Among such events, in particular, it has a great influence on the realization of the target functional requirement items. Or something more limited that seems to be difficult to implement.
[0034]
The “possibility” is information about what kind of case the risk occurs, and the “tolerance” is information about how much the risk should be considered. The “measure plan” is a concept included in the “design requirement” in the present invention. Here, in order to facilitate the response when the risk occurs, any configuration, mechanism, etc. can be provided. It is information about what to do. And when step S121-S123 are performed about all the combinations of the function requirement item D11 and the architecture characteristic item Da, it progresses to the following step S130.
[0035]
In step S130, the recorded countermeasure plan D24 is classified and sorted, and the currently important countermeasure plan D31 and the unimportant countermeasure plan D32 are extracted and recorded. Next, regarding the recorded “significant countermeasure plan” D31, it is different from taking various countermeasure plans such as conflict, similarity, dependence, etc. among various relations such as conflict, similarity, dependence, independence, etc. The relationship that has some influence on taking the countermeasure plan is extracted and recorded as “relationship of important countermeasure plan” D4 (S140).
[0036]
Here, “conflict” is a relationship in which it is difficult or impossible to take another measure when a measure is taken. “Similar” is a relationship in which when a measure is taken, another measure is taken. In addition, “dependency” is a relationship in which taking a different measure is a condition in order to take a measure. In addition, “independence” is a relationship in which even if one measure is taken, there is no influence on taking another measure.
[0037]
Subsequently, based on the recorded “Relationship between important countermeasures” D4, the countermeasures are selected for each group having a predetermined relationship, and one or more countermeasures to be adopted in the software architecture design are selected. Determine (S150). The software architecture D6 is constructed and recorded by sequentially extracting and integrating the configuration and operation principle for realizing each countermeasure based on the recorded “measure proposal to be adopted” D5 (S160). ).
[0038]
If it is determined that the details of the component group of the software architecture D6 recorded in step S160 can be examined without depending on the implementation environment (S170), each component group is targeted. The above steps S110 to S160 are repeated.
Hereinafter, details of individual steps in the software design support method will be sequentially described with reference to FIG.
[0039]
[1-1. Steps for entering functional requirement items and non-functional requirement items]
In the input step S110 of functional requirement items and non-functional requirement items, the designer extracts and organizes those belonging to functional requirements from requirements given by stakeholders such as customers, managers, and project managers. As function request items, other items are classified as non-function request items, and information about the function request items D11 and non-function request items D12 is obtained by performing an input operation using an input operation unit such as a keyboard. The data is input to a computer and recorded in a storage unit such as a memory.
[0040]
[1-2. Steps for extracting risk items and countermeasures against them]
FIG. 2 is a flowchart showing details of the extraction step S120 (steps S121 to S124) of risk items and countermeasures against the risk items together with the data flow. As shown in FIG. 2, first, a combination of one function requirement item D11 and one architecture property item Da is extracted from the function requirement item D11 recorded in the input step S110 and the architecture property item Da prepared in advance. (S201). This step S201 corresponds to step S121 in FIG.
[0041]
Then, the combination of the function requirement item D11 and the architecture characteristic item Da is sequentially presented to the designer together with the support display of the similar risk search, and the risk item input support is performed (S202). Note that various types of input support in the present embodiment is basically performed by displaying information on the screen for the designer, and voice output or the like is appropriately combined with this. When the designer performs a search request input operation and a similar risk search request is input (YES in S203), a similar risk is searched for and presented from past work data Db (S204).
[0042]
The designer examined the risk while referring to the combination of the presented function requirement item D11 and the architecture characteristic item Da, past similar data Db, etc., and performed input operations such as creation of the risk item and confirmation thereof. In the case (YES in S205), information regarding the risk item D21 is input to the computer and recorded in a storage unit such as a memory (S206). Note that these steps S202 to S206 correspond to step S122 in FIG.
[0043]
Subsequently, the recorded risk item D21 is presented to the designer to support input of possibility, tolerance, and countermeasure plan (S207). In this input support, in order to obtain a “measure plan” that satisfies the recorded non-functional requirement items, a list showing all the non-functional requirement items D12 is presented to the designer at the same time as each risk item D21. Is done. The designer examines the possibility D22, tolerance D23 and countermeasure plan D24 for the risk item D21 while referring to the presented risk item D21 and the non-functional requirement item D12, and creates and confirms such information. When the input operation is performed (YES in S208), the information is input to the computer and recorded in a storage unit such as a memory (S209). Note that these steps S207 to S209 correspond to step S123 in FIG.
[0044]
Then, each combination of the function request item D11 and the architecture characteristic item Da is sequentially extracted, and Steps S202 to S209 are repeated for each combination. Finally, when the above steps S201 to S209 are performed for all the combinations (NO in S124, NO in S210), the process proceeds to the next step S130. It should be noted that the extraction step of the risk item D21 and the countermeasure plan D24 for the risk item D21 is performed to break down the recorded non-functional requirement item D12 and to extract a potential non-functional requirement without omission. Therefore, it is desirable that the countermeasure plan D24 be extracted without omission in a wide field of view without being greatly affected by the level of detail and granularity.
[0045]
[1-3. Classification of countermeasure proposals, extraction steps for important countermeasure proposals]
FIG. 3 is a flowchart showing details of the classification and arrangement of countermeasure plans and the extraction step S130 of important countermeasure plans together with the data flow. As shown in FIG. 3, first, a list of all countermeasure plans D24 recorded in step S120 is presented to the designer for input support (S301). When the designer selects a plurality of countermeasure plans with high correlation and performs input operations such as confirmation thereof, when a plurality of countermeasure plans D24 to be integrated are designated (YES in S302), A plurality of countermeasure plans D24 are presented side by side as an integration target group, and input support for correcting the description of the countermeasure plans is performed (S303).
[0046]
The designer can modify the description of the countermeasure plan in such a manner that it integrates all the countermeasure plans included in the integration target group into a higher-level countermeasure plan while referring to the plurality of proposed countermeasure plans D24. When an input operation such as confirmation is performed (YES in S304), a plurality of countermeasure proposals of the original group are deleted from the list and replaced with a higher countermeasure proposal that encompasses them (S305).
[0047]
When the integration of countermeasure plans D24 with high correlation is completed or there is no plurality of countermeasure plans D24 to be integrated, and the integration is unnecessary (YES in S306), the designer Only the countermeasures that match the level of detail and the level of detail of the function requirement item group, the current work range, the work phase, etc. are examined. When the designer performs an input operation such as selection as a countermeasure plan to be considered in the current phase and confirmation thereof based on such examination (YES in S307), the designer selects the result according to the selection result of the designer. The countermeasure plan D24 selected by the designer is stored in a storage unit such as a memory as an “important countermeasure plan” D31, and the countermeasure plan D24 that has not been selected is stored as an “unimportant countermeasure plan” D32. It is recorded (S308).
[0048]
In other words, for the countermeasure plan that was not selected by the designer as a countermeasure plan to be considered in the current phase, the countermeasure plan depending on the environment to be implemented, or the specificity of the target functional requirement items, the current work range, A measure plan that has a higher level of detail and specificity than the level of detail and concreteness of the work phase, etc. is a measure that should not be considered in the current phase. Therefore, these countermeasure plans may be grouped as “unimportant countermeasure plans” D32 at the present time, and extracted at the time when the countermeasure plans should be considered.
[0049]
[1-4. Relationship extraction step for important measures]
FIG. 4 is a flowchart showing details of the relationship extraction step S140 of the important countermeasure plan along with the data flow. As shown in FIG. 4, first, the designer displays a selection screen showing symbols showing relations such as reciprocity, similarity, dependence, etc. together with a list showing all the currently proposed countermeasures D31 recorded in step S130. To provide input support (S401). When a designer specifies a plurality of countermeasure plans D31 having a conflicting relationship by performing input operations such as selection and confirmation of a plurality of countermeasure plans having a conflicting relationship and the relationship (YES in S402) In step S403, the plurality of countermeasure plans D31 are presented as a group of countermeasure plans having a conflicting relationship to prepare for the next input operation.
[0050]
Similarly, when a plurality of countermeasure proposals D31 having a similar relationship are designated (YES in S404), the plurality of countermeasure proposals D31 are presented as a group of countermeasure proposals having a similar relationship, and the next Prepare for an input operation (S405). In addition, when a plurality of countermeasure plans D31 having a dependency relationship are specified together with a dependency direction indicating a dependent side and a dependent side (YES in S406), the plurality of countermeasure plans D31 are determined to be dependent on each other. It is presented together with the dependency direction as a group of countermeasure proposals having the above relationship and prepared for the next input operation (S407).
[0051]
At the time when the clarification of the relationship is completed for all the countermeasure plans (YES in S408), information on the relationship of the important countermeasure plans such as conflicts, similarities, and dependencies is “Relationship of Important Measures” D4 Is recorded in a storage unit such as a memory (S409). Note that this step S140 is performed in order to facilitate examination of what measures should be taken in software architecture design, so various relations necessary from that viewpoint are extracted and recorded. .
[0052]
[1-5. Steps for deciding measures to be adopted]
FIG. 5 is a flowchart showing details of the measure plan determination step S150 to be adopted together with the data flow. As shown in FIG. 5, first, each group of “important countermeasure plans” D31 having a conflicting relationship is sequentially presented to the designer based on the “relationships of important countermeasure plans” D4 recorded in step S140. Then, input support is performed (S501).
[0053]
For each group of proposed countermeasures, a countermeasure proposal D31a that is not adopted for each group is specified by performing an input operation such as selecting or confirming a countermeasure that is not adopted in order to resolve the conflicting relationship. If it is determined (YES in S502), a countermeasure plan that is not adopted is determined based on the designated countermeasure plan D31a and deleted from the important countermeasure plan D31 (S503).
[0054]
That is, it is determined that the designated countermeasure plan D31a is not adopted, and depends on one or a plurality of other countermeasure plans D31b having a similar relationship with the designated countermeasure plan D31a and the designated countermeasure plan. It is decided not to adopt another single or plural countermeasure plans D31c, and these countermeasure plans D31a, D31b, D31c that are not employed are deleted from the important countermeasure plan D31.
[0055]
Next, among the “important countermeasure plans” D31 that remain without being deleted, each group of “important countermeasure plans” D31 having a similar relationship is sequentially presented to the designer for input support (S504). . When the designer performs the input operation such as selection and confirmation of the most important countermeasure plan for each group of the proposed countermeasure plans, the most important countermeasure plan D31d is designated in each group (in S505) YES), the designated measure plan D31d is determined as a measure plan to be adopted, and another measure plan D31e of each group is deleted from the important measure plan (S506).
[0056]
Subsequently, among the “important countermeasure plans” D31 that remain without being deleted, each group of “important countermeasure plans” D31 having a dependency relationship is sequentially presented to the designer for input support (S507). . When the designer selects the countermeasure plan D31f to be adopted for each group by performing input operations such as selection of the countermeasure plan to be adopted and confirmation thereof for each group of the presented countermeasure plans (YES in S508) Then, based on the designated countermeasure plan D31f, a countermeasure plan that is not adopted is determined and deleted from the important countermeasure plan D31 (S509).
[0057]
That is, when there is another countermeasure plan D31g on which the designated countermeasure plan D31f depends in the group, all the countermeasure plans D31g on which the countermeasure plan D31f depends are traced to the final countermeasure plan. Is determined as a countermeasure plan to be adopted, and another countermeasure plan D31h that further depends on the designated countermeasure plan D31f is deleted from the important countermeasure plan.
[0058]
Finally, from the “significant countermeasure plan” D31 that remains without being deleted, the above-mentioned countermeasure plan that is completely independent of other countermeasure plans without any conflicts, similarities, or dependencies. Provides the individual countermeasure proposals to the designer one after another and provides input support (S510). About the countermeasure plan D31i designated to be adopted by the designer by performing input operations such as the presence / absence of adoption and confirmation of each proposed countermeasure, the designated countermeasure plan D31i is designated as such (YES in S5111). For the measure plan D31j that is determined as the measure plan that adopts the measure plan D31i and is designated not to be adopted, the measure plan D31j is deleted from the important measure plan (S512).
[0059]
Then, at the time when the selection of countermeasures based on the relationship of conflict, similarity, dependence, and independence is completed (YES in S513), the “important countermeasures plan” D31 that remains without being deleted is “ It is recorded in a storage unit such as a memory as “measure plan to be adopted” D5 (S514).
[0060]
[1-6. Extraction of configuration and operation principle to realize countermeasure plan, integration step]
FIG. 6 is a flowchart showing details of the configuration and operation principle extraction and integration step S160 for realizing the countermeasure plan together with the data flow. As shown in FIG. 6, first, based on the “measure plan to be adopted” D5 recorded in step S150, a list of all “measure plan to be adopted” D5 is presented to the designer, and the priority order is shown. An input support for adding a character is performed (S601). Here, it is assumed that there are n countermeasure plans D51 to D5n as the “measure plan to be adopted” D5.
[0061]
When the priority order of n countermeasure plans D51 to D5n is designated by performing an input operation such as selection of priority order or confirmation of the proposed n countermeasure plans D51 to D5n ( (YES in S602) A configuration in which information proposal support display for an existing pattern, past work data, and the like is displayed together with countermeasure plans D51 to D5n sequentially based on the designated priority order to realize it The input support for inputting the operation principle is performed (S603). When the designer performs a search request input operation and a search request for an existing pattern or past work data is input (YES in S604), the existing architecture pattern, design pattern Dc, or past work is input. Information such as data Db is retrieved and presented (S605).
[0062]
The designer examines the configuration and operation principle for realizing the countermeasure plan D51 while referring to the information such as the presented first countermeasure plan D51, the existing pattern Dc, the past work data Db, and the like. When the information input operation is performed (YES in S606), it is determined whether or not the information regarding the configuration and the operation principle D61 is clear (S607).
[0063]
That is, in the information on the configuration and operation principle, each component needs to clearly define the role and the scope of responsibility. Therefore, when such clarity is determined and it is unclear (NO in S607). For example, prompting a re-input operation is performed. If it is clear (YES in S607), information regarding the configuration and operation principle D61 is input to the computer and recorded in a storage unit such as a memory (S608). Note that the information on the configuration and operation principle may be about the block structure diagram (macro level), and if the target is narrow, the designer may create the program language based on experience.
[0064]
Subsequently, when there is the next countermeasure plan D52 (YES in S609), the countermeasure plan D52 and information search support display are performed, and information on the acquired configuration and operation principle D61 is presented to the designer. The input support is performed (S603), and the configuration and operation principle D62 for realizing the countermeasure plan D52 are acquired through S604 to S607, and are integrated into the existing configuration and operation principle D61 (S608). In this way, the same work is performed up to the n-th countermeasure plan D5n having the lowest priority, and the configuration and operation principle are integrated. If integration is difficult, extract another configuration and operation principle for the countermeasure plan, return to the first countermeasure plan and extract another configuration and operation principle, or any other Work such as returning to the step and starting over is performed.
[0065]
Then, when the extracted and integrated configuration and operation principle become a configuration and operation principle reflecting all “measures to be adopted” (YES in S610), an operation scenario is set according to the customer's request and the like. Deriving and verifying whether or not the operation scenario can be operated without departing from the responsibility and scope of responsibility of each component on the current configuration and operation principle without departing from the operation principle ( S611). As a result, when it is determined that there is a problem (YES in S611), if it is possible to extract a non-function request item that avoids this, it is added and the process is repeated from an arbitrary step. If it is finally verified that there is no problem (NO in S611), the current configuration and operation principle are recorded as the software architecture D6 (S612).
[0066]
[1-7. Supplementary explanation of repetition steps for component groups]
In the following, a supplementary description will be given of the repetition steps of Steps S110 to S160 for the software architecture component group recorded in Step S160. First, the function requirement item D11 in step S110 is a function requirement item provided to the component group related to the target component group on the software architecture D6 constructed in step S160. These are extracted from the role and responsibility range of the target component group and the countermeasure plan D24 extracted in step S120.
[0067]
Further, in this repetitive work, for step S120, referring to the countermeasure plan D24 extracted in the same step S120 during the previous repetitive work or the countermeasure plan D32 grouped as “a measure plan that is not important at present” in step S130. To do. Step S160 is integrated with the software architecture D6 constructed in the same step S160 of the previous repetitive work.
[0068]
[2. Specific examples of software design]
Hereinafter, a specific example in which the above-described software design support method according to the present embodiment is applied to the software architecture design of the conference room reservation system will be described.
[0069]
[2-1. Steps for entering functional requirement items and non-functional requirement items]
Here, it is assumed that the following requests 1 to 6 are given as requests from the customer.
[0070]
[Table 1]
(Request 1): A system for reserving a conference room online. The user can log in to the terminal to reserve, cancel, or view the conference room.
(Request 2): When making a reservation, the user designates a date, a time zone, and a conference room. The terminal displays whether or not a reservation has been made.
(Request 3): When canceling, the user designates the reservation of the user. Cancellation can only be canceled by the user who made the reservation. The terminal displays whether or not the cancellation was successful.
(Request 4): When browsing, the user designates a conference room. The terminal displays the reservation status for the designated conference room from the date of operation until one month later.
(Request 5): The terminal screen configuration and operation specifications are arbitrary, but the user interface is intuitive and easy to understand.
(Request 6): Even if a plurality of users try to make a reservation for the same conference room at the same time at the same time, the reservation is possible and the reservation is impossible on a first-come-first-served basis.
[0071]
Functional requirements and non-functional requirements are extracted by extracting functional requirements and non-functional requirements based on these requirements 1 to 6, and the designer performs use case analysis on the functional requirements. The following items are extracted and input operations are performed. As a result, these pieces of information are input to the computer and recorded as data in a memory or the like (S110).
[0072]
[Table 2]
(Function request item 1): Browse reservations
(Function request item 2): Make a reservation
(Function request item 3): Cancel reservation
(Non-functional requirement item 1): Operability from the terminal
(Non-functional requirement item 2): Consideration for simultaneous use
(Non-functional requirement item 3): Emphasis on extensibility
[0073]
[2-2. Steps for extracting risk items and countermeasures against them]
Here, as an example, a case will be described in which a risk item and a countermeasure proposal or the like are extracted by a combination of the function request item 1 “view reservation” and the architecture characteristic item “specification stability”.
[0074]
First of all, the questions defined in the function requirement item 1 “View reservation” and the architecture characteristic item “Specification stability” are “Possibility of function expansion”, “Operating environment has been changed. A combination with each situation with a risk such as “Is there a possibility?” Is displayed on the screen for the designer (S202). In this case, support display for similar risk search is also performed. As a result, the designer can search for similar risks as necessary (S203), and search for and display similar risks from past work data (S204). It is possible to easily examine the risk while referring to the screen display at the same time.
[0075]
In this case, depending on the conference room, there is equipment that may be provided, and that information may be displayed. Alternatively, the number of items to be displayed may be adjusted depending on the user's instruction. Based on such examination, the designer extracts, for example, the next risk item and performs an input operation thereof (S205). As a result, these pieces of information are input to the computer and recorded as data in a memory or the like (S206).
[Table 3]
(Risk item 1): Displayed information varies depending on the conference room, such as equipment
(Risk item 2): Information to be displayed varies according to user's wishes
[0076]
Subsequently, the recorded risk item 1 and risk item 2 are displayed on the screen for the designer together with the non-functional requirement item 1 to the non-functional requirement item 3 described above. An input operation is supported (S207). Therefore, the designer can easily examine the possibility, tolerance, and countermeasure plan while referring to the risk item and the non-functional requirement item at the same time, and efficiently implement the countermeasure plan that reflects the non-functional requirement item. Can be extracted.
[0077]
For example, considering the possibility of risk item 1 “information such as equipment to be displayed varies depending on the conference room”, it is considered that equipment provided in the conference room is generally different, so it will be a specification in the future. A change is likely to occur. Also, considering the tolerance, it is desirable to consider the non-functional requirement item 1 “operability from the terminal” and to make it possible to respond as flexibly as possible when a similar specification change occurs. It is done. As a countermeasure, it is considered effective to provide a concept class called a conference room, conceal information and operations related to the conference room, and allow transparent access from others.
[0078]
The designer performs the extraction of the risk items as described above, and the examination of the countermeasure proposals, etc. for each combination of each of the function requirement items 1 to 3 and each architecture characteristic item, The possibility, tolerance, and countermeasure plan for each risk item are extracted and the input operation is performed (S208). As a result, these pieces of information are input to the computer and recorded as data in a memory or the like (S209). In this example, as countermeasures, for example, the following countermeasures 1 to 15 are recorded.
[0079]
[Table 4]
(Countermeasure 1): Create a concept class called “Conference Room” to allow transparent access
(Countermeasure 2): Establish a mechanism for common processing called “processing request”
(Countermeasure 3): The part related to the user's operation is completely separated from the other parts.
(Countermeasure 4): The data recording process is abstracted so that the reservation information may be held in the DBMS.
(Countermeasure 5): Isolate the OS-dependent part
(Countermeasure 6): Provide a mechanism to export reservation information and other data
(Countermeasure 7): A configuration in which reservation information can be multiplexed and held.
(Countermeasure 8): Make the search algorithm etc. replaceable
(Countermeasure 9): Consider cooperation with other systems such as employee DB
(Countermeasure 10): Establishing a mechanism to ensure consistency even if multiple users make reservations at the same time
(Countermeasure 11): Make the data holding part changeable like plug-in.
(Countermeasure 12): Provide a mechanism that can import conference rooms and user information.
(Countermeasure 13): Provide a mechanism that allows the user to define how to make reservations and cancellations
(Countermeasure 14): Provide a configuration in which the data search part and the data holding part can be exchanged.
(Countermeasure 15): Various user interfaces can be defined, and the reservation process can be handled transparently.
[0080]
[2-3. Classification of countermeasure proposals, extraction steps for important countermeasure proposals]
Here, the countermeasure plans 1 to 15 recorded as described above are classified and arranged using a technique such as the KJ method. That is, first, since the list of countermeasure plans 1 to 15 is displayed on the screen for the designer (S301), the designer can easily select an important countermeasure plan and an unimportant countermeasure plan in the current work phase. (S307). In addition, if there are a plurality of countermeasures that are important and highly correlated with important countermeasures in the current phase among the important countermeasures, they can be easily selected. When those measures for integration are designated by the designer (S302), the designated measures are displayed side by side as a group to be integrated (S303), so the designer refers to a plurality of measures at the same time. However, it is possible to easily create a high-order countermeasure plan that encompasses them.
[0081]
When the designer creates an upper countermeasure plan and confirms that it replaces the original countermeasure plan (S304), the original countermeasure plan is deleted and replaced with a higher countermeasure plan (S305). By such integration work, subsequent work can be facilitated by reducing the number of countermeasures. In this example, the scope of work targeted is the part related to the entire system, so detailed countermeasure plans should not be considered in the current phase, that is, grouped as unimportant countermeasure plans and other countermeasure plans Will be grouped as an important measure proposal. For example, the following “important countermeasure plan 1” to “important countermeasure plan 6” are recorded (S308).
[0082]
[Table 5]
(Important Measure 1): Separate the user interface from the reservation information processing part.
(Important Measure 2): Rewrite only the user interface on each platform.
(Important Measure 3): Create a common processing framework called “Process Request” so that reservation, cancellation, and browsing methods may be changed.
(Important Measure 4): Create a mechanism to ensure consistency even when multiple users request processing at the same time.
(Important Measure 5): Retain reservation information in a multiplexed manner
(Important Measure 6): Create a configuration that abstracts the processing for data within the system.
[0083]
[2-4. Relationship extraction step for important measures]
Here, the relationship between “important countermeasure plan 1” to “important countermeasure plan 6” recorded as described above is extracted. That is, the designer displays a selection screen including symbols representing the list of important countermeasure plans and the relationship to the designer (S401), so that the designer can view conflicts, similarities, dependence, independence, and the like. Thus, it is possible to easily examine and specify the relationship between countermeasures (S402, S404, S406). As shown in FIG. 7, the countermeasure plan designated by the designer and its relationship are expressed as a graphic image on the screen (S403, S405, S407), so that the designer can establish the relationship between the countermeasure plans designated by the designer. Can be easily grasped and confirmed. The relation expressed by the graphic image is recorded as “relationship of important countermeasure plan” after the contents are confirmed by the designer (S409).
[0084]
In FIG. 7, as an example, a graphic image representation including a box displaying an important countermeasure plan and a connection line as a symbol indicating the relationship is shown. That is, a straight line with a double-headed arrow connecting between boxes indicates that there is a reciprocal relationship between measures proposed by each box, and a straight line without an arrow connecting between boxes is It shows that there is a similar relationship between the proposed countermeasures. Further, when there is no line connecting the boxes, it indicates that the countermeasure proposals expressed by the boxes are independent of each other. Here, since there is no dependency relationship, it is not shown in the figure, but for example, it can be expressed by a straight line with a unidirectional arrow toward the dependency destination.
[0085]
[2-5. Steps for deciding measures to be adopted]
Here, based on the recorded “relationship between important countermeasure proposals”, a countermeasure proposal to be adopted is determined from “important countermeasure proposal 1” to “important countermeasure proposal 6”. That is, by displaying a countermeasure plan having a predetermined relationship with a graphic image as shown in FIG. 7 (S501, S504, S507, S510), the designer can easily compare the countermeasure plan having the target relationship. Therefore, it is possible to easily specify the countermeasure plan to be adopted or the countermeasure plan not to be adopted (S502, S505, S508, S511).
[0086]
In the example of FIG. 7, as a countermeasure plan group having a conflicting relationship, first, “Create a mechanism that can maintain consistency even when multiple users request processing simultaneously” and “Reserve information multiplexed” By displaying each box indicating “save” and a straight line with a bidirectional arrow connecting between the boxes (S501), the designer compares both boxes and easily designates a countermeasure plan that is not adopted. (S502). In this case, for example, from the viewpoint of cost and importance, it is assumed that it is designated as a countermeasure plan that does not employ “reserve reservation information multiplexed”. As a result, this countermeasure plan is deleted from the list of important countermeasure plans (S503).
[0087]
Next, as a countermeasure plan group having a similar relationship, the other two sets of boxes shown in FIG. 7 and a straight line connecting them are displayed (S504), so that the designer can connect each group connected by a line. By comparing these boxes, the most important countermeasure plan in each group can be easily designated (S505). In this case, for example, a common processing framework called “processing request” is used so that the method of abstracting the processing for data within the system and “reservation, cancellation, and browsing methods may be changed”. For the “Make” group, the latter is specified, and for each platform, “only the user interface needs to be rewritten” and “the user interface is separated from the reserved information processing part” The latter is assumed to be specified. As a result, the countermeasure plan that has not been designated is deleted from the list of important countermeasure plans (S506).
[0088]
In this example, the selection of the countermeasure plan is completed only by the above work (S513), so the three countermeasure plans remaining without being deleted are “measure plan 1 to be adopted” to “adopt” as follows. This is recorded as “Measure 3 to be taken” (S514).
[Table 6]
(Countermeasure plan 1 to be adopted): Create a mechanism to ensure consistency even if multiple users request processing at the same time
(Countermeasure 2 to be adopted): Create a common processing framework called “processing request” so that reservation, cancellation, and browsing methods may be changed.
(Measure 3 to be adopted): The user interface is separated from the reservation information processing part.
[0089]
[2-6. Extraction of configuration and operation principle to realize countermeasure plan, integration step]
Here, based on the recorded “measure plan to be adopted”, a configuration and an operating principle for realizing all of the measure plans are extracted and integrated to construct a software architecture. That is, first, a list of recorded “measure plan 1 to be adopted” to “measure plan 3 to be adopted” is displayed on the screen (S601), so that the designer easily compares the target measure plans. Therefore, the priority order can be easily specified (S602). In this example, for example, the following priorities are given.
[0090]
[Table 7]
(First measure to be adopted): Create a common processing framework called “processing request” so that reservation, cancellation, and browsing methods may be changed.
(Second measure to be adopted): The user interface is separated from the reservation information processing part.
(Third countermeasure plan to be adopted): Create a mechanism to ensure consistency even when multiple users request processing simultaneously
[0091]
When priorities are specified in this way, countermeasure plans are sequentially displayed to the designer according to the priorities, and information search support display for existing patterns and past work data is also performed. (S603). As a result, the designer can make a search request for existing patterns and past work data as required (S604), and search and display such information (S605). While simultaneously referring to patterns and past work data, the configuration and operation principle for realizing the countermeasure can be easily studied. In this example, for example, the following examination is performed for each countermeasure plan.
[0092]
Regarding the “first countermeasure plan to be adopted”, the design pattern visitor pattern (E. Gamma et al., Shinichi Honda, et al., Revised design pattern for object-oriented reuse, 1999.11, ISBN4-7973- It is considered effective to apply 1112-6). The request process is a Visitor, which represents all requests and conceals the process for the request, so that all requests from users can be handled in common. Also, by making this an object, reservation processing via the network can be handled transparently.
[0093]
The “second countermeasure plan to be adopted” can be realized by providing a portion that controls the user interface and delegating the processing to the request processing.
The “third countermeasure plan to be adopted” can be handled by having a configuration in which only one part of the entire system has an authority to start processing even when a plurality of request processing occurs. it is conceivable that. It is sufficient to provide one block for all the reservation information so that the request processing can be given authority to start processing.
[0094]
When the designer performs the input operation of the configuration and operation principle integrating the examination results of each of these countermeasures, the configuration and operation principle are recorded in a memory or the like as information for constructing the software architecture. (S603 to S610). In this example, when the constructed software architecture is described in UML, it is as shown in FIG. The definition of the role of each class that is a component of the software architecture is as follows.
[0095]
[Table 8]
(Screen): It has a role of accepting an operation from the user and presenting the result to the user. A process request object reflecting the user's operation is generated, the process is transferred to the process request object, and the request result is presented to the user through the screen.
(Processing request): Holds a request according to the user's operation, and operates the reservation information according to the request.
(Reservation information): Holds information such as conference rooms, users, and reservations. Only the process request object can be operated, and the operation right can be given to the process request object.
[0096]
Since it can be confirmed that the function requirement item and the non-function requirement item described above can be realized with this software architecture, this is recorded as the constructed software architecture (S611, S612). In this example, only three relatively simple countermeasures are shown, so that the configuration and operation principle can be integrated at one time. However, in reality, there are almost many countermeasures. Yes, the extraction and integration of the configuration and operating principle are sequentially performed for each countermeasure plan.
[0097]
[2-7. Software architecture built with this method]
The software architecture recorded in the above steps is composed of three components, and each component can be detailed (S170). Therefore, steps S110 to S160 are repeated for each component. In the second iteration step, the details of the function request items will be examined again based on the role defined in step S160. In this example, by repeating each step for each component and integrating the software architecture, the software architecture shown in FIG. 9 is finally obtained. The definition of the role of each class that is a component of this software architecture is as follows.
[0098]
[Table 9]
(Conference Room): Holds information specific to the conference room. The information specific to the conference room is the name, location, number of persons accommodated, facilities, etc. of one conference room.
(User): Holds user-specific information. User-specific information includes name, affiliation, title, etc.
(Reservation): Reservation information is held. The reservation information is a reserved conference room (conference room object), a reservation person (user object), and a reservation date and time.
(Date): Holds date and time information. The date / time information enables all expressions related to the date / time, such as a specific time zone on a specific day, a specific time zone on every Wednesday, and the like. A new reservation is always generated and a date / time object is created. This object expresses information related to the date and time of the reservation.
(Request window): Accepts the request object and determines the operation right for the reservation, conference room, and user objects. There is only one request window object in one system. Also serves as a proxy window for distributed environments. The request window object does not create or operate the reservation object.
(Request): This is an abstract class for expressing the contents of the request from the user and the processing corresponding to it. The request content is information related to the reservation or cancellation of the conference room. The processing includes creation, change, deletion, search, and the like of each object of reservation, conference room, and user. In this derived class, there is a class group indicating a specific request and its processing procedure.
(Request result): This is an abstract class for expressing the result of the processing performed by the request. The result is the success or failure of the request, details thereof, and the like. The request result object does not know how it is presented to the user. In this derived class, there is a class group expressing a specific request result.
(Screen): Accepts an operation from the user and presents the result to the user. In response to the user's operation, an appropriate request object is generated and passed to the request window object. Receives the request result object and presents its contents to the user through the screen.
[0099]
A typical process flow on the software architecture constructed by this method is as follows.
(1) The screen object receives a user request, generates a request object corresponding to the content, and passes this to the request window object.
(2) The request window object gives the received request object access rights to the reservation, conference room, and user objects, and delegates operations to these objects.
(3) The request object operates the reservation, conference room, and user objects according to the request contents held by itself, and generates an appropriate request result object as a result.
(4) The request result object is passed to the screen object via the request window object, and the screen object presents the result to the user according to the information held by the request result object.
[0100]
[2-8. Software architecture built using conventional methods]
Here, in order to compare with the present method, a case where a software architecture is constructed by a conventional method in response to the above requests 1 to 6 from the customer will be described.
First, the reservation is specified by specifying the date and time, the time zone, and the conference room, and the browsing is specified by specifying the conference room. Therefore, it is sufficient to add and record information on “reserved user” and “date and time zone” in the “specific conference room”.
[0101]
Since cancellation is a specification that specifies a user's reservation, it is sufficient if the above information can be specified.
Further, the actual request processing can be defined as a specification of processing specifically performed by reservation, cancellation, and browsing.
Therefore, according to the conventional method, a customer request can be satisfied with a software architecture as shown in FIG. The definition of each class of the software architecture constructed by this conventional method is as follows.
[0102]
[Table 10]
(Conference Room): Holds information specific to the conference room. The information specific to the conference room is the name, location, number of persons accommodated, facilities, etc. of one conference room. Maintain a reservation list for this conference room.
(User): Holds user-specific information. User-specific information includes name, affiliation, title, etc.
(Reservation): Reservation information is held. The reservation information is a reserved conference room (conference room object), a reservation person (user object), and a reservation date and time.
(Request window): Accepts request contents and performs operations on reservation, conference room, and user objects. The operations include creation, change, deletion, search, and the like of reservation, conference room, and user objects. There is only one request window object in one system. Also serves as a proxy window for distributed environments.
(Screen): Accepts an operation from the user and presents the result to the user. The contents are passed to the request window object according to the user's operation. Receives the contents of the request result and presents the contents to the user through the screen.
[0103]
A typical processing flow on the software architecture constructed by this conventional method is as follows.
(1) The screen object receives a user operation and passes the contents to the request window object.
(2) The request window object adjusts access rights to the reservation, conference room, and user objects, and operates these objects according to the received contents.
(3) The request window object passes the content of the request result to the screen object, and the screen object presents the result to the user according to the content of the received request result.
[0104]
[2-9. Comparison of software architecture constructed by this method and conventional method] In the following, when a specification change occurs in the software architecture of FIG. 9 constructed by this method and the software architecture of FIG. 10 constructed by the conventional method. Compare the correspondence of
Here, as an example, a case is assumed in which a specification change that enables complex processing occurs, such as “reservation is possible anywhere from 13:00 to 15:00 every Wednesday for the next three months”.
[0105]
First, the software architecture constructed by this method can be easily handled as follows.
(1) Since the method of request is added or changed, it is easily derived that the class expressing it, that is, the derived class of the abstract class of the request and the request result may be added or changed.
(2) Since the actual date and time are also created for each reservation, the date and time class can be changed or derived classes can be added as necessary to make it easier to add or change the requested class. It can correspond to.
(3) Changes in each class do not affect other classes.
(4) Since the change of the screen class is separated from the request processing, it can be corrected independently without considering the influence of others.
[0106]
On the other hand, in the case of a software architecture constructed by a conventional method, it is difficult to cope with specification changes as follows.
(1) Since the request window class is responsible for all operations related to requests, the inside of the request window class needs to be significantly changed.
(2) Depending on the size of the specification change, it can be considered that the change of the request window class becomes large, or the interface of the request window is affected. Therefore, it is necessary to make a major change to the screen class.
(3) Since the date and time is an internal attribute of the reservation class, the reservation class may be affected depending on circumstances.
[0107]
[3. Effects of the embodiment]
As described above, the software architecture constructed by the method of this embodiment is not only easy to cope with specification changes, but also can be constructed after extracting potential customer requirements, so software development It is possible to reduce the total cost of software and to develop software with high customer satisfaction. In addition, the effects of each characteristic step in this method are as follows.
[0108]
First, the effects of the extraction steps for risk items and countermeasures against them are as follows. That is, by individually comparing the architecture characteristic items for each function requirement item, it is possible to extract a risk item that greatly influences or makes it difficult to realize the function requirement item based on the comparison result. In particular, by retrieving and presenting past work data and the like, risk items can be more easily extracted using past data. Then, by comparing non-functional requirement items individually for each extracted risk item, it is possible to efficiently extract countermeasure plans reflecting non-functional requirements as well as functional requirements based on the comparison results. it can. Therefore, by adopting the countermeasure plan obtained in this step, various non-functional requirements can be reflected in the design as the basis of the design.
[0109]
Next, at the step of categorizing countermeasure proposals and extracting important countermeasure proposals, categorize and organize multiple countermeasure proposals that reflect functional requirements and non-functional requirements, and assign multiple countermeasure plans with high correlation to higher-level countermeasures. A work plan such as integration into a draft is performed, and a countermeasure plan that is highly important at the present time, which is determined based on the level of detail of the function requirement items, the current work range, the work phase, and the like, is extracted. Therefore, according to this step, it is possible to limit the countermeasures targeted in the subsequent steps to a smaller number of important countermeasures.
[0110]
Also, according to the relationship extraction step of the important countermeasure plan, it is possible to sequentially extract the conflicting, similar, dependent, and independent relationships of the important countermeasure plan, so that all the relationships that affect the adoption of the countermeasure plan are efficiently Can be extracted. In particular, by displaying the countermeasure plan and the relationship as a graphic image, the relationship can be easily grasped and confirmed, and the work efficiency can be further improved.
[0111]
In addition, in the step of determining the countermeasure plan to be adopted, the number of countermeasure proposals can be efficiently narrowed down by sequentially selecting countermeasure proposals for each group of countermeasure proposals having a predetermined relationship. Also in this case, as in the relationship extraction step, by displaying the measure plan and the relationship as a graphic image, it is possible to easily grasp the relationship of the measure plan and to select the measure plan based on it. In this step, first of all, by eliminating the conflicting choices by eliminating the conflicting relationship, one of the conflicting countermeasures is removed, and the countermeasures that are similar to the countermeasures or depend on them. In addition to being able to delete countermeasure plans mechanically, the number of countermeasure plans should be greatly reduced while appropriately selecting from the remaining countermeasure plans according to similarities and dependency relationships. Can do. Accordingly, it is possible to increase the efficiency of determining the countermeasure plan to be adopted and the efficiency of the subsequent work.
[0112]
In addition, in the extraction and integration steps of the configuration and operation principle that realizes the countermeasure plan, a narrowed number of “proposal countermeasures to be adopted” that reflect functional and non-functional requirements should be presented in order of priority. Therefore, the software architecture can be efficiently constructed by efficiently extracting and integrating the configuration and operation principle. In particular, by searching and presenting existing patterns and past work data, it is possible to more easily extract the configuration and the operating principle using such information.
[0113]
Furthermore, when the details of the components of the constructed software architecture can be examined without depending on the implementation environment, the level of detail has been increased by repeating a series of steps for each component. Software architecture can be constructed efficiently.
[0114]
[4. Other Embodiments]
Note that the present invention is not limited to the above-described embodiments, and various other forms can be implemented within the scope of the present invention.
[0115]
[4-1. Automatic presentation of existing data and use as candidates]
For example, in the above embodiment, when extracting risk items, a similar risk is searched and presented from past work data in response to a search request, but is automatically presented without a search request. Alternatively, it is possible to select a risk item by using the presented existing risk item as a candidate. In this case, since the designer only needs to create risk items that are not included in the existing risk items, the risk item extraction efficiency can be greatly improved.
[0116]
In addition, for the existing pattern and past work data in the extraction of the configuration and operation principle that realizes the countermeasure plan, the configuration and operation principle are also presented by automatically presenting such information or selecting it as a candidate. The extraction efficiency can be greatly improved. Furthermore, such a method of displaying support automatically, such as automatically presenting existing data or selecting it as a candidate, can be similarly applied when extracting a countermeasure plan for a risk item. It is obtained.
[0117]
In addition, when inputting a function request item or a non-function request item, a candidate of a function request item or a candidate of a non-function request item prepared in advance based on past data is presented and selected by the designer. Is also possible. Also in this case, it is possible to efficiently input all the request items according to the request of the customer or the like only by creating the request item having no candidate.
[0118]
[4-2. Reduction of the number with reference values prepared in advance]
On the other hand, in the above-described embodiment, all risk items created by the designer are recorded as they are, and countermeasure measures for each risk item are extracted. However, risk items using past work data or the like are used. It is also possible to set in advance a reference value regarding the degree of influence on the realization of the function request item by, and to extract a risk item exceeding the reference value.
[0119]
For example, depending on the impact level of the risk item obtained as a candidate, “impact level A” indicates that the impact level is extremely high, and “impact level B” indicates other risk items. The risk items to be recorded can be automatically reduced by automatically extracting and removing the risk items having the influence degree B. As a result, risk item extraction efficiency can be increased and the efficiency of subsequent operations can be increased. As a modified example, the risk item of “influence degree B” may not be automatically deleted, but a list of risk items that are temporarily presented to the designer may be selected.
[0120]
Similarly, with respect to a countermeasure plan, it is possible to set a reference value relating to the satisfaction degree of the non-functional requirement item in advance by using past work data and the like, and extract a countermeasure plan that exceeds the reference value. In this case, by mechanically extracting only the countermeasures with the satisfaction degree of the non-functional requirement items above the standard value from the countermeasures obtained as candidates, and removing the countermeasures with low satisfaction, The number of countermeasures to be extracted can be automatically reduced. As a result, it is possible to improve the extraction efficiency of the countermeasure plan and the efficiency of the subsequent work. Further, as a modification, the countermeasure plan with a low satisfaction degree may not be automatically deleted, but the countermeasure plan may be temporarily selected and presented to the designer.
[0121]
In addition, when deciding on an important countermeasure plan at the present time from among the extracted countermeasure plans, similarly, using the past work data, etc., work on the reference value for the current importance level of the countermeasure plan. It is possible to set in advance according to the phase, etc., and to extract a countermeasure plan exceeding the reference value as an important countermeasure plan. In this case, only countermeasures with a current importance level or higher are mechanically extracted from the countermeasure proposals obtained based on functional requirements and non-functional requirements, and countermeasures with relatively low importance. By removing the plan, the number of important countermeasures to be extracted can be automatically reduced.
[0122]
In this case, in particular, compare the current importance of each countermeasure plan within the group for each group of countermeasure proposals having a predetermined relationship such as conflicts and similarities, and make a selection according to the level of importance. Thus, the number of design requirements can be automatically reduced further. As a result, it is possible to increase the extraction efficiency of important countermeasures and increase the efficiency of subsequent operations. Further, as a modification, a countermeasure plan having a relatively high degree of importance may be presented to the designer once without being automatically deleted, and a countermeasure plan to be left as an important countermeasure plan may be selected. .
[0123]
[4-3. Promotion of automation]
In addition, “impact on the realization of functional requirement items by risk items”, “satisfaction of non-functional requirement items by countermeasures”, “important measures at present” For example, it is conceivable that a grade value or the like is given by the designer at the time of creating risk items or countermeasure proposals. Alternatively, an algorithm for calculating a value expressing the degree of influence, the degree of satisfaction, the degree of influence, and the like based on past work data may be created and automatically obtained.
[0124]
Similarly, in the above-described embodiment, each part described as an object to be examined by the designer is automatically determined by a computer by organically combining various types of related data with various statistical methods and analysis methods. Or automatic extraction. By proceeding with such automation, automatic classification of functional requirement items and non-functional requirement items, input, automatic extraction of design requirements such as events such as risk items and countermeasures against them, and automatic selection of important countermeasure plans And automatic extraction of countermeasures to be adopted, automatic determination of countermeasures to be adopted, automatic construction of software architecture that satisfies the countermeasures to be adopted, and the like. Therefore, the method of the present invention automatically extracts design requirements reflecting functional requirements and non-functional requirements by simply inputting requests from customers, etc., and satisfies such design requirements. Software architecture to be built automatically.
[0125]
【The invention's effect】
As described above, according to the present invention, the events that affect the realization of the function requirement items are extracted by comparing the characteristics to be considered in the software design for each function requirement item, and the non-functions are detected for each event. By comparing requirement items individually, design requirements that reflect not only functional requirements but also non-functional requirements can be extracted efficiently, and various non-functional requirements are reflected in the design as the basis for the design. A possible software design requirement extraction support method can be provided.
[0126]
In addition, according to the present invention, design requirements that reflect functional requirements and non-functional requirements are classified and arranged to limit only important design requirements, and software design requirement determination that can efficiently determine design requirements to be adopted It is possible to provide a support method and a software design support method that can efficiently design a software architecture that can cope with various external variations based on design requirements reflecting functional requirements and non-functional requirements. .
[Brief description of the drawings]
FIG. 1 is a flowchart showing an outline of a software design support method to which the present invention is applied together with a data flow.
FIG. 2 is a flowchart showing details of extraction steps of risk items and countermeasures against the risk items in the method shown in FIG. 1 together with a data flow;
FIG. 3 is a flowchart showing details of classification and arrangement of countermeasure proposals and extraction steps of important countermeasure proposals together with a data flow in the method shown in FIG. 1;
4 is a flowchart showing details of an important countermeasure plan relationship extraction step together with a data flow in the method shown in FIG. 1;
FIG. 5 is a flowchart showing details of a decision step of a countermeasure plan to be adopted together with a data flow in the method shown in FIG. 1;
6 is a flowchart showing details of a configuration and operation principle extraction and integration step for realizing a countermeasure plan in the method shown in FIG. 1 together with a data flow.
7 is a data display diagram showing an example of the relationship between important countermeasure plans extracted by the method shown in FIG. 1. FIG.
FIG. 8 is a structural diagram showing an example of a software architecture constructed by the method shown in FIG. 1;
9 is a structural diagram showing an example of a software architecture in which the level of detail of the software architecture shown in FIG. 8 is further increased.
FIG. 10 is a structural diagram showing an example of a software architecture constructed by a conventional method.

Claims (10)

A computer having an input operation unit such as a keyboard, an information storage unit such as a memory, a calculation unit that searches for and extracts information that is input or stored, and a display screen that displays information extracted by the calculation unit In the software design requirement extraction support method that supports the design of the design target software architecture,
A quality characteristic storage step for preliminarily storing in the information storage unit the quality characteristics to be considered when performing software design;
A request item receiving step of receiving input of function request items and non-function request items of the design target software from the designer via the input operation unit of the computer, and recording them in the information storage unit of the computer,
A function for the operation unit to individually compare a quality characteristic stored in the information storage unit in advance for each function request item recorded in the information storage unit and to display the comparison result on a display screen of a computer Item-quality characteristic display step;
A risk acceptance step for accepting a risk affecting the realization of each function requirement item determined by the designer based on the comparison result displayed on the display screen from the designer via the input operation unit;
Risk that the arithmetic unit individually compares each risk received via the input operation unit with a non-functional requirement item stored in the information storage unit, and displays the comparison result on the display screen of the computer A non-functional requirement item display step, comprising: a software design requirement extraction support method. Function request item candidates and non-function request item candidates prepared in advance based on past data are stored in the information storage unit, and prior to the request item receiving step, the calculation unit stores the information in the information storage unit. The software design requirement extraction support method according to claim 1 , further comprising a step of displaying the function request item and the non-function request item that are displayed on the display screen . The risk acceptance step is to accept the degree of influence on the realization of the function request item for each risk, and the risk-non-function display step is to extract a risk equal to or higher than a preset reference value. The software design requirement extraction support method according to claim 1 or 2, wherein The request item accepting step accepts the degree of satisfaction for each non-functional requirement item, and the risk-non-functional requirement item display step extracts and displays a non-functional requirement item equal to or higher than a preset reference value. it is intended to, software design requirement extraction support method according to any one of claims 1 to 3, characterized in that. A computer having an input operation unit such as a keyboard, an information storage unit such as a memory, a calculation unit that searches for and extracts information that is input or stored, and a display screen that displays information extracted by the calculation unit Software design requirement decision support that supports the classification and organization of multiple countermeasures obtained based on the functional requirement items and non-functional requirement items of the design target software, and the decision of one or more countermeasures to be adopted based on the classification and arrangement In the method
A quality characteristic storage step for preliminarily storing in the information storage unit the quality characteristics to be considered when performing software design;
A request item receiving step of receiving input of function request items and non-function request items of the design target software from the designer via the input operation unit of the computer, and recording them in the information storage unit of the computer,
A function for the operation unit to individually compare a quality characteristic stored in the information storage unit in advance for each function request item recorded in the information storage unit and to display the comparison result on a display screen of a computer Item-quality characteristic display step;
A risk acceptance step for accepting a risk affecting the realization of each function requirement item determined by the designer based on the comparison result displayed on the display screen from the designer via the input operation unit;
The arithmetic unit, each risk accepted through the input operation unit, wherein the information storage portion to store to and contrasted individually non-functional requirements item was, and displays the comparison result on the display screen of the computer A risk-non-functional requirement item display step;
The countermeasure plan prepared by the designer based on the risk-non-functional requirement item displayed on the display screen in the risk-non-functional display step is received via the input operation unit of the computer, and this is received in the information storage unit. A countermeasure proposal receiving step to be stored in
In a state where each countermeasure plan in the information storage unit is displayed on the display screen, each countermeasure plan and the importance are received from the designer through the input operation unit, and a classification receiving step for storing these in the information storage unit,
An importance level display step in which the calculation unit classifies and arranges each countermeasure plan received in the classification reception step according to the importance level and displays it on a display screen;
A relationship receiving step for receiving information on the relationship between the countermeasure plan and other countermeasure plans related to the countermeasure plan from the designer for each countermeasure plan having a high importance displayed in the importance display step, and storing the information in the information storage unit; ,
The calculation unit classifies and arranges each countermeasure plan stored in the information storage unit for each countermeasure plan having a predetermined relationship and displays it on the display screen, and selects design requirements for each group from the designer. A software design requirement determination support method comprising: a selection information reception step of receiving information and storing the information in the information storage unit . The relationship receiving step receives a conflicting relationship that makes it difficult to adopt another countermeasure when one countermeasure is adopted, and the selection information receiving step eliminates the conflicting relationship from the designer. 6. The software design requirement determination support method according to claim 5, wherein selection information for deleting a countermeasure for deleting is received . The relationship receiving step is to receive a similar and / or dependent relationship that, when one countermeasure is adopted, is the same as another countermeasure is adopted, and the selection information receiving step is a designer 7. The method according to claim 5 , wherein selection information for deleting other countermeasures that are similar and dependent on the countermeasure specified by the designer is received. Software design requirement determination support method. 8. The method according to claim 5, wherein the importance level display step displays a countermeasure whose current importance level of each countermeasure is equal to or greater than a predetermined reference value set in advance. 9. The software design requirement determination support method described in the above. A software design requirement extraction support program that supports the design of the architecture of the target software,
  For a computer having an input operation unit such as a keyboard, an information storage unit such as a memory, a calculation unit that searches and extracts information that is input or stored, and a display screen that displays information extracted by the calculation unit And
  A quality characteristic storage function for preliminarily storing in the information storage unit the quality characteristics to be considered when performing software design;
  A request item receiving function for receiving input of function request items and non-function request items of the design target software from the designer via the input operation unit of the computer, and recording them in the information storage unit of the computer,
  A function for the operation unit to individually compare the quality requirement items stored in the information storage unit in advance for each function requirement item recorded in the information storage unit, and to display the comparison result on the display screen of the computer Item-quality characteristic display function,
  A risk acceptance function that accepts a risk affecting the realization of each function requirement item determined by the designer based on the comparison result displayed on the display screen from the designer via the input operation unit;
  Risk that the calculation unit individually compares each risk received through the input operation unit with the non-functional requirement item stored in the information storage unit, and displays the comparison result on the display screen of the computer -A software design requirement extraction support program characterized by realizing a non-functional requirement item display function. A software design requirement determination support program that supports the classification and arrangement of a plurality of countermeasures obtained based on the functional requirement items and non-functional requirement items of the design target software, and the determination of one or more countermeasures to be adopted based on the classification and arrangement. There,
  A computer having an input operation unit such as a keyboard, an information storage unit such as a memory, a calculation unit that searches and extracts information that is input or stored, and a display screen that displays information extracted by the calculation unit ,
  A quality characteristic storage function for preliminarily storing in the information storage unit the quality characteristics to be considered when performing software design;
  A request item receiving function for receiving input of function request items and non-function request items of the design target software from the designer via the input operation unit of the computer, and recording them in the information storage unit of the computer,
  A function for the operation unit to individually compare a quality characteristic stored in the information storage unit in advance for each function request item recorded in the information storage unit and to display the comparison result on a display screen of a computer Item-quality characteristic display function,
  A risk acceptance function that accepts a risk affecting the realization of each function requirement item determined by the designer based on the comparison result displayed on the display screen from the designer via the input operation unit;
  Risk that the calculation unit individually compares each risk received through the input operation unit with the non-functional requirement item stored in the information storage unit, and displays the comparison result on the display screen of the computer -Non-functional requirement item display function;
  The countermeasure proposal prepared by the designer based on the risk-non-functional requirement item displayed on the display screen in the risk-non-functional display function is received via the input operation unit of the computer, and this is received in the information storage unit The measure proposal reception function to be stored in
  Classification in which each countermeasure plan and importance are received from the designer via the input operation unit in a state where each countermeasure plan in the information storage unit is displayed on the display screen, and the calculation unit stores them in the information storage unit Reception function and
  An importance level display function in which the calculation unit classifies and arranges each countermeasure plan received by the classification reception function according to the importance level and displays it on a display screen;
  A relation acceptance function for accepting information about the relation between the countermeasure proposal and other countermeasure proposals related to the countermeasure proposal from the designer for each countermeasure proposal having a high importance displayed by the importance display function; ,
  The calculation unit classifies and arranges each countermeasure plan stored in the information storage unit for each countermeasure plan having a predetermined relationship and displays it on the display screen, and selects design requirements for each group from the designer. A software design requirement extraction support program characterized in that a computer realizes a selection information reception function that receives information and stores it in the information storage unit.

Images