JP2010055562A - Information processor, and system construction method and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a device, method and program capable of consistently performing the analysis and design of functional specification and the implementation of a target system. <P>SOLUTION: This information processor is provided with a means for storing a result obtained by analyzing functional requirements of the system in the form of an SVO statement including: S being a role indicating a function; V being an initiative representing operation contents to an initiative target; and O being an initiative target being an operation target of the role, and generates a process list from the SVO statement about the stored functions. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to an information processing system and method, and more particularly, to a system construction technique suitable for construction of a business system such as slip processing.

<Procedure for building a system for companies>
Currently, a system (enterprise system) that supports a business of a company is constructed in the following procedure.

(S1) Creation of specifications,
(S2) Create specifications describing functions and rules based on requirements.
(S3) Create program code,
(S4) Based on the above specifications, create a program code for the extent to which it is realized on a computer.
(S5) Execution environment construction and testing / operation,
(S6) Introduction of an environment for executing program code,
(S7) Test and operation in the above environment.

  The system construction is realized by the work of writing a program code that accurately reflects the contents based on the specifications.

<Enterprise systems>
Basically, companies and companies are composed of slips and organizations that handle them. The enterprise system provides a means for controlling a slip and a rule regarding its handling to the enterprise and its related users. The means is mainly configured by using a computer system including a network or a communication means such as a manual and paper, telephone, FAX.

  However, in the actual system construction work (development project), many projects fail due to the quality problems of the specifications themselves and the mismatch between the specifications and the program code, and there is a significant delay or budget overrun. Yes.

  Note that the description in Patent Document 1 and the like is referred to as a system that enables construction and verification of a general-purpose design guideline for an information system. Patent Document 2 and the like are referred to as a system that seamlessly performs system construction, verification, and implementation.

JP 2007-188334 A JP 2003-337697 A

  The analysis results according to the present invention will be described below.

  (A) There is no consistent derivation method for description of specifications.

  (B) In addition, there is no way to consistently verify whether the specifications meet the requirements.

  (C) Also, there is no consistent method for developing program code from a specification into a form that can be constructed.

  (D) There is no consistent mechanism for verifying or guaranteeing that the specification and program code match, and there is no clear derivation relationship between the specification and the program.

  (E) Substantial verification is almost impossible until the program code, which is the final delivery, becomes operable, and costs are extremely high for testing and resolving the problems that have occurred. In particular, since there is no clear derivation relationship between the specification and the program, only the program code is modified, and there is even a situation in which the specification itself is substantially absent, in which each individual programmer knows only locally.

  The above situation is a situation in which corporate governance has not been established in companies, and in terms of costs, such as compliance with laws represented by the JSOX (Japanese version of the Sarbanes-Oxley Act) and the transformation of companies for competition It has become a big problem.

<Limitation of solutions by programming technology>
The cause of the above problem exists between the specification itself or between the specification and the program code, so it cannot be fundamentally solved by programming techniques such as programming languages and tools that have been mainstream until now. .

<Current specification description method and its problems>
Basically, it is described by text or a picture that supports it, and there is no consistent derivation method for the content in addition to strictness. The object of strictness is also related to the format, not the contents and the derived method. Or it is a template for specific industries (introduction of packages), etc., and it is not versatile.

In the absence of a strict derivation method, the result will be different for the same input by the writer, the quality is not constant, and the specification for the requirement is
Does it meet the necessary functions? (Is there any unnecessary function?)
Is it operational?
How much will it affect existing organizations and operations?
How big is the cost?
It is very difficult for the requester to verify the above.

<Conventional measures for specification description>
We have been controlling quality and content uniformity by conducting reviews with experienced and knowledgeable personnel. However, in principle, specific experience and knowledge depend on the specific business category, and in confirming the consistency between the specifications and the program, both work knowledge and knowledge of the program are required. Is very limited.

  In addition, there will be differences due to the knowledge and experience of reviewers. For this reason, if a sufficient number of reviewers cannot be prepared in a large-scale project that is difficult to handle with a small number of reviewers, the reviewers themselves may become bottlenecks, Variations in description content and quality become a problem and cannot be handled.

<Consideration on the current state of description of specifications>
The current specification description is situationally similar to the description of a particular book and the verification of its contents. The contents of the reading impressions cannot be solved by the writing tools (cannot be solved by programming techniques). Further, even if the format of the original paper to be used is determined, the content is not specified. Whether or not the description contents described by completely different contents depending on the writer even when reading the same book is consistent with the original book requires deep knowledge of the contents of the original book.

  Even if you understand the contents of the original book, it is not always possible to evaluate the explanatory text. To evaluate and verify, deep knowledge of both is necessary. As a result, even if written by an expert Japanese language teacher, the content is different, the evaluation is different, and there is no clear standard for the evaluation (score and quantification are not possible).

  In the case of explanatory texts, there is not much problem even with the above, but in the case of system construction, it is necessary to write program code that is a combination of strict commands based on it, and use it as a tool to manage actual work .

<Development from specification to program code>
The specifications are written based on the business contents in principle and are conceptual for humans, whereas the program code is an instruction to the computer, and both are fundamentally different types of deliverables. Until now, there was no consistent derivation method from a specification to a program code or a format that can be directly converted to program code. Also, the specification writer and the program code writer are classified as different types of occupations, SE and programmer, and both are usually handled by different persons. For this reason, the person in charge of the program understands the specification including the business contents and describes the program code or the product with the contents close to the program code.

  In order to support the above, efforts have been made to make everyone understand the business (or to make the business person in charge understand the structure of the program), such as drawing various business relationships. The description by pictures and the efforts to deepen the understanding of the person in charge are sound, but they all depend on the ability of the person in charge and are difficult to verify and difficult to manage changes (a lot of reference material is spent) The harder it is to reflect consistent changes).

<Requirements for consistent derivation methods>
The requirements for a consistent derivation method are:

  The same result can be obtained even if another person in charge performs the same input.

  When the derivation relationship is clear and there is a shortage in input, it is possible to clearly indicate what results are not obtained and what is lacking.

  The method of interpreting based on the current text or picture and describing another text or picture cannot realize the requirements for a consistent derivation technique.

  An object of the present invention is to provide an apparatus, a method, and a program that can be performed consistently from analysis / design of functional specifications to implementation of a target system.

In the present invention, the analysis result of the functional requirements of the system,
A role indicating S,
An initiative that represents the operation contents of V for the initiative target,
O is the initiative target that is the target of the roll operation,
Stored in the storage means in the form of an SVO statement containing
From the SVO statement relating to the function stored in the storage means, a process list defining the operation procedure for the initiative target is generated.
In the present invention, the data model of the initiative target stored in the storage means is generated.

In the present invention, the roll depends on how to handle the initiative target.
Role to create a new initiative target (ACTIVE),
The role of receiving and processing initiative targets (PASSIVE),
Role to refer to initiative target (REFERENCE),
Role to register or refer to master rules (CONTROL),
Belongs to one of the following roll types.

  In the present invention, each process in the process list includes an initiative target to be operated and a process operation. The process operation includes at least one of process preconditions and end conditions, process input, output, and search items.

  In the present invention, at least one of a model, a work item sheet handled by the system, a content, an area, and a page may be derived from the process.

  In the present invention, a sequence chart is created from the roll and the initiative target sheet, and whether or not the initiative target moves between rolls from one side to the other side based on the flow from ACTIVE to PASSIVE in the sequence chart. By checking the above, it may be verified that the derivation of roles and the exchange of initiative targets between roles are performed correctly.

  According to the present invention, analysis / design for defining specifications from functional requirements and automation of system implementation can be provided with a consistent tool.

  The present invention responds by providing an analysis / design method for defining specifications based on business requirements and a tool / environment for systematizing it.

In the present invention, the analysis result of the functional requirements of the system,
A role indicating S,
An initiative that represents the operation contents of V for the initiative target,
O is the initiative target that is the target of the roll operation,
Is stored in the storage means in the form of an SVO statement including

  FIG. 1 shows the structure of an SVO statement, which is stored in the storage means in the form of an SVO statement comprising roles, initiatives, and initiative targets.

  As shown in FIG. 2, the roll (S) belongs to a roll type.

  The initiative target (O) is an operation target of the role (S).

  The role type designates an initiative (V) that represents an operation content for the initiative target (O).

  As shown in FIG. 3, business system participants (users, organizations, departments) are associated with roles (S). In extracting the role, the participants who are the origin of the role are extracted, the initiative target operated by the participant is identified, and the role category of the participant is determined by focusing on how to handle the initiative target.

  As shown in FIG. 4, a process list that defines an operation procedure for the initiative target is generated from the SVO statement stored in the storage unit.

  Further, as shown in FIG. 5, the data model of the initiative target (for example, a form) stored in the storage unit is developed.

  The process in the process list includes an initiative target to be operated and a process operation. The process operation includes at least one of process preconditions and end conditions, process input, output, and search (sort) items.

  From the process list, expand the interface (page, area, content, screen panel), data model, service definition file (process operation for the data model), and run the system that implements the above functional requirements on the application server (engine) (See FIG. 6). A description will be given below in accordance with an embodiment.

  In the present invention, the business requirements of customers are defined by abstract nouns (labels) that do not depend on the type of business or business condition.

Conditions for applying the label,
Conditions on associations and constraints between labels,
Derivation of deliverables based on relationships and constraints between labels
Based on the above, a consistent derivation method to deliverables in a form that can be built into a system is provided.

  The present invention is based on a concept close to a physical approach. In other words, there is a process corresponding to the expansion of the following equation based on the abstract parameter of the equation and its mathematical expansion, and the acquisition of a concrete result by entering a value for the abstract parameter of the equation. Done.

  In the present invention, functions are described in English SVO format. However, the types of S that can be selected are determined in advance, and are determined by how O is handled.

  The type of V is also determined in advance, and selectable V is limited by the type of S. This is described by an abstract and unambiguous relationship such as F = MV in physics (relationship between force, mass and velocity). The derivation method in the present invention can be used universally and deductively like an equation in physics rather than prescribing only an expression method. Therefore, the same result can be obtained for the same input, and it can be verified by a person other than the creator whether it is correct.

  According to the present invention, it is possible to realize a quantitative analysis, and it is possible to manage an objective scale grasp and progress management of throughput (how much has been completed), from a series of designs to implementation of an actual system. Can be managed collectively. Moreover, according to the present invention, it is not necessary to read from the beginning to the end like documents such as design instructions and specifications.

  In the present invention, the contents to be handled are determined for each deliverable, and if the deliverable is confirmed, it can be confirmed whether or not the deliverable is there. In addition, an ID is assigned to each deliverable, managed in a list for each deliverable, and necessary materials can be pinpointed. In addition, verification of deliverables is possible.

  According to the present invention, it is possible to store a product in a DB and perform sorting by formal classification or cross-reference check based on a derivation relationship without business knowledge.

  The present invention covers a range related to analysis and design in conventional software development, and includes the following two analysis methods.

The analysis of the present invention (RIT analysis)
Define a list of features,
Do activity analysis,
Define processes for each function,
These three processes are included.

  RIT analysis converts customer requests and business details into a list of functions (SVO statements) that can be executed independently. Input includes customer functional requirements (interviews or materials), templates. Derived products include statement sheets and a list of functions that can be executed independently.

Activity analysis transforms a statement into a systematable form. The derived product (output) is
<Activity sheet (one per statement)>
Definition of process (realization procedure) for each function <business item sheet>
List of input / output items handled by the process, and definitions of their types / values and handling ranges <Model sheet>
Definitions related to the operation target (model) and the business items and rules it holds <Rule sheet>
Define the list of items that require rules based on business specifications and their details

<RIT analysis>
The customer's functional requirements are compiled into a list in English SVO format from information that has not been formulated, such as customer request forms (RFP), customer interviews and materials. A list of functions in English SVO format is called a statement, and the list is called a statement sheet.

<Statement (SVO)>
A function that describes the functions required for business execution in English SVO format.

  It consists of roll initiatives, initiative targets and statement assumptions (see Figure 1).

<S: Role> A role that is independent of a specific person or organization,
A roll belongs to one of the predetermined roll types.

  Specific people and organizations are called participants.

  A role has at least one participant.

  Participants belong to one or more roles.

<V: Initiative> For example, an operation content for a slip (initiative target).

  The available verbs are predetermined according to the role type.

<O: Initiative target> A slip operation target slip.

  Depending on the type of roll and initiative, multiple slips may be operated simultaneously.

<Statement precondition> The state of O targeted when executing a statement.

<Statement derivation procedure>
Identify participants and their slips.

  Disassemble participants into roles based on how to handle slips.

  Organize the relationship between role and initiative targets based on the linkage between roles based on role type.

  Review the initiatives held by roles based on role type and their prerequisites.

  Expand into a list of statements based on the initiatives held for each role.

<Roll extraction>
From interviews and materials, first extract participants who will be the source of the role.

  The slip (initiative target) operated by the participant is specified.

  Focusing on how to handle slips, the type of role (role category) of the participant is determined.

<Role classification (role category)>
The rolls are classified into the following three types based on how the slip is handled.
ACTIVE: Creates a slip (from nothing).
PASSIVE: I have received a voucher from someone.
REFERENCE: I'm looking at someone's slip.

<Classification of PASSIVE>
PASSIVE roles are further classified into the following subcategories based on how to handle slips.

  Processing for the same slip.

  PASSIVE_ACCEPT: Approved and accepted (pressing a stamp).

  PASSIVE_SEND, PASSIVE_RECEIVE: Handing it over to someone else.

  Check how the status of the slip has changed by processing.

  PASSIVE_PRODUCE: Another slip has been awakened.

  REFERENCE: Check what you are making from what.

  Check how the status of the derived slip changes by PRODUCE.

<Classification of REFERENCE>
The REFERENCE role is classified into the following subcategories according to how the slip is referenced.

In principle, a single slip is referenced (printed). REFERENCE_SEARCH.
A table combining multiple slips is referenced (printed). REFERENCE_PORTFOLIO.

<Role definition>
A role always belongs to only one category. When a certain character is classified into a plurality of categories, there are a plurality of roles. A character is broken down into multiple rolls. Record the organization and people of the characters as participants in each role. For each role, define a role name for which the category classification can be confirmed with respect to the target slip name (eg, quote request creator).

<Role schema>
Role name Role category initiative target (operation target slip)
In case of derivation (plural in SOURCE and DEST)
Initiative target pre- and post-operation states

<Role derivation and creation of role initiative target list>
Based on collaborations such as customer interviews, characters confirmed from materials, roles to PASSIVE for ACTIVE, and SOURCE for PASSIVE, the role initiative targets of the entire business are extracted.

<Create sequence chart and check workflow>
An initiative target is arranged with a roll on the vertical axis of the sequence chart and a box with no corners on each column, and the linkage between each roll and the initiative target (slip) is described. Each role describes the state after the operation after the initiative target name. FIG. 7 shows an example of a sequence chart. The role of the quote request applicant, quote request approver, quote request acceptor, supplier quote request sender, supplier quote request acceptor, supplier quote reply acceptor, partner quote answer sender, quote answer verifier Arranged in order from left to right, the roll type of each roll and the flow of initiative targets are shown.

  In ACCEPT, the initiative target passed between each role is the same, but the state is different. In the example of FIG. 7, in the case of ACCEPT, the initiative target passed between each role is a request for quotation and a response for quotation.

  In the case of PRODUCE, another initiative target is derived from the passed initiative target with an arrow in the same column. In the example of FIG. 7, the supplier quotation request sender sends out the supplier quotation request form from the quotation request form and sends it out (SEND) by derivation by the downward arrow in the same column. Also, the state of the SOURCE initiative target changes before and after it is passed.

  At the end of checking the multiplicity such as 1: 1, 1: N, N: 1, N: M, paying attention to the derivation relationship, the work of each role (participant = character) is established, Confirm that there are no inconsistencies such as PASSIVE without SOURCE. An example of a sequence diagram is shown in FIG.

<Development from role to statement>
The types of verbs (initiatives) available for each role category are fixed. In principle, when the above verb is expanded, the role is expanded to the subject (S) with the initiative (V) and the initiative target (O) to SVO = Statement. However, if there is a non-essential initiative relative to the above initiatives, check whether it exists.

  Check the conditions (usually linked to the state of the initiative target) for performing the Statement. The above conditions are called "statement prerequisites"

<Example statement of ACTIVE>
The order slip creator creates an order slip.

Role: Order Voucher Creator Initiative: CREATE
Initiative target: Order slip The order slip creator updates the order slip.

Role: Order Voucher Creator Initiative: UPDATE
Initiative target: Order slip The order slip creator deletes the order slip.

Role: Order Voucher Creator Initiative: REMOVE (delete)
Initiative target: Order slip

<PASSIVE_ACCEPT statement example>
The order slip receiver receives the order slip.

Role: Order Voucher Initiative: ACCEPT (Reception)
Initiative target: Order slip The order slip receiver returns the order slip.

Role: Order Voucher Initiative: UNACCEPT (Return)
Initiative target: Order slip

<Example of PASSIVE_PRODUCER statement>
The shipping slip creator creates a shipping slip.

Role: Shipping slip creator Initiative: PRODUCE
Initiative target: Order slip, shipping slip The shipping slip creator cancels the shipping slip.

Role: Shipping slip creator (Participant: Shipping manager)
Initiative Target: Shipping slip, Order slip Initiative: CANCEL (Cancellation)

<Characteristics of statement>
Based on the role type classification and its restrictions, different deliverables are not created by the principle writer. Because it is abstracted, it is not a specific industry or business category. Both business staff and system builders can understand. This is a list of functions that have the same granularity of description and do not depend on the business execution procedure (Stateless). It is easy to verify whether a business is established by a sequence chart or the like. It is a list of functions, and is a product that can be used directly in a later process.

<Application of RIT analysis>
The RIT analysis can be used for grasping the current problem even when the system is not constructed.

Project budget calculation Consultation on whether the current system should be rebuilt,
Statement is described based on the current system configuration (AsIs analysis performed),
Focus on the Statement Initiative (V),
The ratio of PASSIVE_SEND and PASSIVE_RECEIVE is acquired.
For example, when the ratio is 17%, it is a function that can be reduced by integrating the system, and it is possible to obtain the cost that can be invested in the system from the maintenance cost of 17%.

  Calculate the cost of maintenance for the above Statement from the maintenance cost for one year. It is calculated how much cost-effectiveness can be expected only by excluding PASSIVE_SEND and PASSIVE_RECEIVE. Calculate how much project cost can be spent with 5-year depreciation.

<JSOX compatible>
Consider which parts of which work should be changed in response to the JSOX Act. Write statements based on current work. The initiative target (O) to be operated by PASSIVE_ACCEPT is extracted.

  List items that have not been PASSIVE_ACCEPT (approved) for the above-described initiative target.

  Calculate the number of statements that need to be added.

  Consider the department / system responsible for the role of the above statement.

  Confirm functions that are unnecessary due to systemization (workflow introduction, etc.). At the same time as verifying whether each group company can operate from the statement sequence diagram of the BPR results above, the organization / responsibility for the role was reconfigured.

<Activity Analysis> The activity analysis is an operation for defining what procedure and item input / output are established for each statement of the product of the RIT analysis. Through activity analysis, statements are a component of the system.

Model: Data rule retention process: Model operation interface: Providing user interface to the process Rule procedure: Dynamic item value determination condition: Judgment on whether to execute or terminate the process Validation: Input value on the interface Restriction Business Item: Expanded directly into the definition of item (handling, type, multiplicity, etc.) or in a convertible format.

In principle, all systems consist of the following components:
Model process interface rule procedure: Rule condition associated with the model: Rule associated with the process Validation: Rule associated with the interface

  Systematization is realized by expanding business functional requirements (statements) into the above model, process, interface, and rules.

<Products of activity analysis>
Activity sheet: Create one for each statement and describe the procedure (process) for establishing the statement function.

  In each process, the initiative target (slip) to be operated and the operation (action) for fear, input / output items, process prerequisites (execution availability and resulting action), and end condition (because the process ends normally) Conditional expression) is described.

Business item sheet Normalized input / output items for each process in the activity sheet.
Basically, all items are independent and are uniquely recognized by the item name.
Describe meta information (item type, type, multiplicity) for each item.

<Procedure list>
Manages output business items and rule names for items that are dynamically determined by process output items and cannot be expressed by simple functions such as total and average values. Derived from activity sheet input / output mismatch. The details of each procedure are separately described using the business items in the detailed procedure specifications.

<Condition list>
Prerequisites for the process (whether or not the process can be executed and actions when false) and end conditions (conditions for terminating the process), whether there is a simple item, or a condition name that cannot be described by a value conditional expression Manage the process that applies the condition. Details of each condition are separately described using business items in the condition detail specification.

<Model>
Interface input to the list of items held by the initiative target: activity process, process input / output items, procedure

  It is created by development based on rules determined from the deliverables of the present invention. Like programming, there is no programmer's discretion. As described above, the derivation relationship with the product of the present invention is clear, and verification based on a cross-reference check or a formal checklist is possible.

The derived deliverable is verified and operated at Engine. Define an interface for users based on the results of activity analysis.
Input: Activity sheet, design contract output (derived work product):
Screen page provided to interface users (defines area information and page transition in the interface)
Area: Describes the screen components to be arranged on each page and the correspondence between screen components and content.
Content (Abstract screen functional component corresponding to the process operation of the activity process)

<Service design>
Service function = Describes the operation contents of the model for the process.
Input: Activity process output (derived product): Service (see FIG. 6).

<Database design> Add information about the table columns in the database to the model.
Input: business item sheet, model output (derived product): model sheet (see FIG. 6).

<Rule design / implementation>: In the activity sheet process, output items or items whose input items are dynamically determined by rules are described as expressions based on business items.
Input: Rule output declared in the activity sheet process: Rule definition or rule implementation class.

  It should be noted that the disclosures of the above patent documents are incorporated herein by reference. Within the scope of the entire disclosure (including claims) of the present invention, the embodiments and examples can be changed and adjusted based on the basic technical concept. Various combinations and selections of various disclosed elements are possible within the scope of the claims of the present invention. That is, the present invention of course includes various variations and modifications that could be made by those skilled in the art according to the entire disclosure including the claims and the technical idea.

It is a figure explaining the structure of the SVO statement of one Example of this invention. It is a figure explaining the SVO statement of one Example of this invention. It is a figure explaining the role and participant of one Example of this invention. It is a figure explaining one Example of this invention. It is a figure explaining one Example of this invention. It is a figure explaining one Example of this invention. It is a figure explaining one Example of this invention.

Explanation of symbols

S Role V Initiative O Initiative Target

Claims (19)

Analyzing the functional requirements of the system,
A role indicating S,
An initiative that represents the operation contents of V for the initiative target,
O is the initiative target that is the target of the roll operation,
Storage means for storing in the form of an SVO statement including:
First means for generating a process list defining a procedure of an operation on the initiative target from the SVO statement stored in the storage means;
An information processing apparatus comprising:   The information processing apparatus according to claim 1, further comprising second means for generating a data model of the initiative target stored in the storage means.   The information processing apparatus according to claim 1, wherein the process list defines an operation for the data model of the initiative target. The processes in the process list are:
Initiative target to be manipulated,
Including process operations,
The process operation is
Process prerequisites and termination conditions,
The information processing apparatus according to claim 1, comprising at least one of process input, output, and search items.   The information processing apparatus according to any one of claims 1 to 4, further comprising means for deriving at least one of a model, an item sheet of business handled by the system, a content, an area, and a page from the process. Depending on how the initiative target is handled,
Role to create a new initiative target (ACTIVE),
The role of receiving and processing initiative targets (PASSIVE),
Role to refer to initiative target (REFERENCE),
Role to register or refer to master rules (CONTROL),
The information processing apparatus according to any one of claims 1 to 5, wherein the information processing apparatus belongs to any one of the following roll types.   Create a sequence chart from the roll and the initiative target sheet, and check whether the initiative target moves between rolls from one side to the other side based on the flow from ACTIVE to PASSIVE in the sequence chart. The information processing apparatus according to claim 6, wherein verification of whether role derivation and initiative target exchange between roles is performed correctly is performed. In deriving the statement,
Identify the role and its target initiative,
Based on the handling of the initiative target, it is disassembled into rolls,
Based on the linkage between roles based on role type, association between roles and initiative targets,
Check the initiatives and assumptions held by the role, based on the role type,
The information processing apparatus according to claim 7, wherein the information processing apparatus expands a statement list based on an initiative held for each role. In extracting the role, the participants who are the origin of the role are extracted,
The information processing apparatus according to claim 8, wherein an initiative target operated by the participant is identified, and the role category of the participant is determined by focusing on how to handle the initiative target.   The information processing apparatus according to any one of claims 1 to 9, further comprising an engine that operates a system that implements the function based on the process list and / or a data model.   The information processing apparatus according to claim 5, further comprising an engine that operates a system that implements the function based on at least one of the derived model, a work item sheet, a content, an area, and a page handled by the system. . Analyzing the functional requirements of the system,
A role indicating S,
An initiative that represents the operation contents of V for the initiative target,
O is the initiative target that is the target of the roll operation,
Stored in the storage means in the form of an SVO statement containing
The system construction method which produces | generates the process list which prescribed | regulated the procedure of operation with respect to an initiative target from the SVO statement regarding the said function memorize | stored in the said memory | storage means.   The system construction method according to claim 12, wherein a data model of the initiative target stored in the storage unit is generated. The processes in the process list are:
Initiative target to be manipulated,
Including process operations,
The process operation is
Process prerequisites and termination conditions,
The system construction method according to claim 12, comprising at least one of process input, output, and search items.   15. The system construction method according to claim 12, further comprising means for deriving at least one of a model, a work item sheet, a content, an area, and a page handled by the system from the process. Depending on how the initiative target is handled,
Role to create a new initiative target (ACTIVE),
The role of receiving and processing initiative targets (PASSIVE),
Role to refer to initiative target (REFERENCE),
Role to register or refer to master rules (CONTROL),
The system construction method according to any one of claims 12 to 15, which belongs to any one of the following roll types.   Create a sequence chart from the roll and the initiative target sheet, and check whether the initiative target moves between rolls from one side to the other side based on the flow from ACTIVE to PASSIVE in the sequence chart. The system construction method according to claim 16, wherein verification of whether role derivation and initiative target exchange between roles is performed correctly is performed. Analyzing the functional requirements of the system,
A role indicating S,
An initiative that represents the operation contents of V for the initiative target,
O is the initiative target that is the target of the roll operation,
A first process of storing in the storage means in the form of an SVO statement comprising:
A program that causes a computer to execute a second process of generating a process list that defines an operation procedure for an initiative target from an SVO statement related to the function stored in the storage unit. The program according to claim 18, wherein
A program for causing the computer to execute a third process for generating a data model of an initiative target stored in the storage unit.

Images