JP4601998B2 - System development support system - Google Patents
System development support system Download PDFInfo
- Publication number
- JP4601998B2 JP4601998B2 JP2004174233A JP2004174233A JP4601998B2 JP 4601998 B2 JP4601998 B2 JP 4601998B2 JP 2004174233 A JP2004174233 A JP 2004174233A JP 2004174233 A JP2004174233 A JP 2004174233A JP 4601998 B2 JP4601998 B2 JP 4601998B2
- Authority
- JP
- Japan
- Prior art keywords
- requirement
- basic
- child
- function
- requirements
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Stored Programmes (AREA)
Description
この発明はシステム開発支援システムに係り、特に、情報処理システムの開発に際し、システムに求める要件の開発及びその管理、システムが備えるべき機能や仕様の設計及びその管理を支援する技術に関する。 The present invention relates to a system development support system, and more particularly, to a technology for supporting development of requirements required for the system and its management, design of functions and specifications to be provided in the system, and management thereof when developing an information processing system.
情報処理システムの開発プロジェクトを成功に導くためには、発注者側の要求を業務要件として明確に定義し、これらをシステムの仕様や機能設計に確実に反映させていくことが重要であり、業務要件が曖昧なまま開発に着手すると後々トラブルの原因となり易い。
このため、システム開発者は発注者と何度もミーティングを重ね、その都度、発注者から引き出した業務要件や自ら提案した業務要件を議事録や課題管理表、ＱＡ等の形で文書化することが実践されている。
In order to lead an information processing system development project to success, it is important to clearly define the requirements of the client as business requirements and ensure that these are reflected in the system specifications and functional design. Starting development with vague requirements tends to cause trouble later on.
For this reason, the system developer should repeatedly meet with the client and document the business requirements drawn from the client and the business requirements proposed by the client in the form of minutes, issue management table, QA, etc. Is practiced.
ところが、システムの仕様や機能構成を規定する段になると、開発担当者の頭の中で必要な仕様や機能が組み立てられ、概要設計書や基本設計書としてまとめられることが多く、設計書の内容として上記の業務要件が正確に反映される保証がないのが実状である。
このため、これらの設計書に従ってコーディングされた各種プログラムは、開発者の思い込みや誤解により、発注者の要求との間に大きなズレが生じる可能性が高いものであった。
また、概要設計書や基本設計書はシステムの機能を中心に記述されており、発注者の要求は各機能の説明中に散在しているため、発注者は自己の要求が設計書中に正確に反映されているか否かを事前に確認することが困難である。
さらに、発注者の要求に変更が生じた場合、それが設計書中のどの機能や仕様に影響するのかを特定することが困難であり、場合によっては設計書を逐一チェックする必要が生じる。
However, at the stage of defining system specifications and functional configurations, necessary specifications and functions are often assembled in the head of the developer, and are often compiled as a summary design document or basic design document. As a matter of fact, there is no guarantee that the above business requirements are accurately reflected.
For this reason, the various programs coded according to these design documents have a high possibility of causing a large deviation from the orderer's request due to the developer's assumptions and misunderstandings.
In addition, the outline design document and basic design document are described mainly in terms of system functions, and the orderer's requirements are scattered throughout the description of each function. It is difficult to confirm in advance whether or not it is reflected in.
Further, when a change occurs in the request of the orderer, it is difficult to specify which function or specification in the design document affects, and in some cases, it is necessary to check the design document one by one.
このような状況に鑑み、いくつかの欧米系ベンダーから要件管理ツールが提供されている。
確かに、上記のような既存のツールを用いることにより、開発者は発注者の要求項目をコンピュータを用いて管理することが可能となり、各要件間の構造や各要件と機能との関連性を定義したり、これをビジュアルに表示したりすることが可能となる。 Certainly, by using the existing tools as described above, the developer can manage the requirements of the orderer using a computer, and the relationship between each requirement and the relationship between each requirement and function can be determined. It can be defined and displayed visually.
しかしながら、既存の要件管理ツールの場合、予め業務要件が発注者の側によって明確に定義されていることが前提となっており、要件を一から定義していく用途、すなわち要件開発まではサポートしていない。
そもそも、これらの要件管理ツールは欧米における軍需関連システムや航空機関連システムなど、発注者側に高度の専門知識があり、システムに対する要求が発注段階で細かく規定されている分野におけるシステム開発を念頭においており、開発側（受注側）はこれらを上記のツールにそのまま入力することが前提となっている。
これに対し、スーパーマーケットの物流管理システム等のように、より一般的な業務システムの開発においては、発注者側の要件が極めて曖昧な状態で開発を受注し、その後何度もミーティングを重ねることによって徐々に要件を明確化していくパターンが多く、また同じ業種であっても発注者によって業務処理が大きく相違し、システムに求める要求項目もまちまちとなるため、ある程度完成され、かつ類型化された要件定義の存在を前提とした既存ツールはあまり役に立たないのが実状であった。
すなわち、一口に要件定義と言ってもその内容や成熟度、粒度（レベル）はまちまちであり、各開発担当者が自己判断で要件をシステムに入力していくと、全体としての整合性が取れなくなり、肝心の要件管理が破綻することが予想される。
However, in the case of existing requirement management tools, it is assumed that business requirements are clearly defined in advance by the orderer, and support is provided until the requirements are defined from the beginning, that is, requirements development. Not.
In the first place, these requirement management tools have advanced expert knowledge on the ordering party side, such as military-related systems and aircraft-related systems in Europe and the United States, and are considering system development in fields where requirements for systems are finely defined at the ordering stage. It is assumed that the development side (order receiving side) inputs these directly into the above tools.
On the other hand, in the development of more general business systems, such as supermarket logistics management systems, orders are received with the requirements of the orderer being very vague, and meetings are repeated many times thereafter. There are many patterns in which requirements are gradually clarified, and even in the same industry, business processing varies greatly depending on the orderer, and the required items for the system vary, so the requirements that have been completed to some extent and categorized The reality is that existing tools based on the existence of definitions are not very useful.
In other words, the content, maturity, and granularity (level) of a requirement definition vary, and if each developer enters requirements into the system at their own discretion, overall consistency can be achieved. It is expected that critical requirements management will fail.
この発明は、上記した従来の問題点を解決するためになされたものであり、システムの各開発担当者が比較的容易に粒度が揃った業務要件や仕様、機能等のオブジェクトをデータベースに登録でき、しかも各オブジェクト間の構造化をも比較的容易に実現可能な支援ツールを提供することを目的としている。 The present invention has been made to solve the above-mentioned conventional problems, and each developer in the system can register objects such as business requirements, specifications, functions, etc. that have relatively uniform granularity in a database. In addition, an object is to provide a support tool that can relatively easily realize structuring between objects.
上記の目的を達成するため、請求項１に記載したシステム開発支援システムは、開発対象システムに対する発注者側の上位概念的な要求事項である基本要件を、開発対象システム毎に複数登録しておく基本要件ＤＢと、特定の基本要件に従属する下位概念的な要求事項である子要件を登録しておく子要件ＤＢと、開発対象システムが備えるべき基本機能を、開発対象システム毎に複数登録しておく基本機能ＤＢと、特定の基本機能を具体化したソフトウェア仕様を登録しておくソフトウェア仕様ＤＢと、上記子要件とソフトウェア仕様とのリンク情報を登録しておく子要件−仕様ＤＢと、ディスプレイと、入力装置と、画面生成部と、データ更新部とを備えたシステム開発支援システムであって、上記画面生成部は、上記基本要件の内容及びタイトルを入力するための基本要件更新フォームを生成し、上記のディスプレイに表示させる処理と、上記子要件の内容及び当該子要件が従属する基本要件を特定する基本要件IDを入力するための子要件更新フォームを生成し、上記のディスプレイに表示させる処理と、上記基本機能の内容及び名称を入力するための機能更新フォームを生成し、上記のディスプレイに表示させる処理と、上記ソフトウェア仕様の内容、当該ソフトウェア仕様が従属する基本機能を特定する機能ID、及び当該ソフトウェア仕様が関連する基本要件を特定する基本要件IDを入力するためのソフトウェア仕様更新フォームを生成し、上記のディスプレイに表示させる処理と、特定の子要件とソフトウェア仕様とを対応付けるための子要件・ソフトウェア仕様登録フォームを生成し、上記のディスプレイに表示させる処理を実行し、上記データ更新部は、上記基本要件更新フォームを通じて入力された基本要件の内容及びタイトルを、固有の基本要件IDに関連付けて上記基本要件ＤＢに登録する処理と、上記子要件更新フォームを通じて入力された子要件の内容及び基本要件IDを、固有の子要件IDに関連付けて上記子要件ＤＢに登録する処理と、上記機能更新フォームを通じて入力された基本機能の内容及び名称を、固有の機能IDに関連付けて上記基本機能ＤＢに登録する処理と、上記ソフトウェア仕様更新フォームを通じて入力されたソフトウェア仕様の内容、機能ID及び基本要件IDを、固有の仕様IDに関連付けて上記ソフトウェア仕様ＤＢに登録する処理と、上記子要件・ソフトウェア仕様登録フォームを通じて入力された特定の子要件とソフトウェア仕様とのリンク情報を上記子要件−仕様ＤＢに登録する処理を実行することを特徴としている。
上記の「基本要件」は、開発対象システムに対する要求項目を少なくとも上位、下位の二階層構造で観念する場合における上位概念的な要件を指し、「子要件」はその下位概念的な要件を指しているのであり、必ずしも基本要件、子要件の名称に限定する趣旨ではない。例えば、基本要件を上位要件に、子要件を下位要件に置き換えることもできる。
上記の「基本機能」は、開発対象システムが備えるべき機能項目を少なくとも上位、下位の二階層構造で観念する場合における上位概念的な機能を指し、「ソフトウェア仕様」はその下位概念的な機能を指しているのであり、必ずしも基本機能、ソフトウェア仕様の名称に限定する趣旨ではない。例えば、基本機能を上位機能に、ソフトウェア仕様を下位機能に置き換えることもできる（請求項２においても同様）。
In order to achieve the above object, the system development support system according to claim 1 registers a plurality of basic requirements, which are high-level conceptual requirements on the orderer side for the development target system, for each development target system. For each development target system, register a basic requirement DB, a child requirement DB that registers child requirements that are subordinate conceptual requirements subordinate to a specific basic requirement, and a basic function that the development target system should have. A basic function DB, a software specification DB for registering software specifications embodying a specific basic function, a child requirement-specification DB for registering link information between the child requirements and the software specifications, and a display A system development support system comprising an input device, a screen generation unit, and a data update unit, wherein the screen generation unit includes the contents of the basic requirements and A child requirement for generating a basic requirement update form for entering an ittle and displaying it on the above display, and a basic requirement ID for identifying the content of the child requirement and the basic requirement on which the child requirement depends. A process for generating an update form and displaying it on the display, a process for generating a function update form for inputting the content and name of the basic function, and displaying it on the display, the contents of the software specification, A process for generating a software specification update form for inputting a function ID for specifying a basic function to which the software specification depends and a basic requirement ID for specifying a basic requirement to which the software specification is related, and displaying the form on the display; Child requirement / software specification registration format for associating specific child requirements with software specifications The data update unit associates the content and title of the basic requirement entered through the basic requirement update form with a unique basic requirement ID, and executes the process of generating the program and displaying it on the display. The process of registering in the DB, the process of registering the content of the child requirement and the basic requirement ID input through the child requirement update form in the child requirement DB in association with the unique child requirement ID, and the input through the function update form The process of registering the basic function contents and name in the basic function DB in association with the unique function ID and the software specification contents, function ID and basic requirement ID entered through the software specification update form Through the process of registering in the software specification DB in association with the specification ID of the child and through the child requirement / software specification registration form Is characterized by executing a process of registering the specification DB - link information with specific child requirements and software specifications entered said child requirements.
The above “basic requirements” refer to the upper conceptual requirements when the requirements for the development target system are considered at least in the upper and lower two-layer structure, and “child requirements” refer to the lower conceptual requirements. It is not necessarily intended to limit the names of basic requirements and child requirements. For example, the basic requirement can be replaced with a higher requirement and the child requirement can be replaced with a lower requirement.
The above “basic function” refers to the upper conceptual function when the function items to be included in the development target system are considered at least in the upper and lower two-layer structure, and “software specification” refers to the lower conceptual function. It is not necessarily intended to limit the names of basic functions and software specifications. For example, the basic function can be replaced with a higher function, and the software specification can be replaced with a lower function (the same applies to claim 2).
請求項２に記載したシステム開発支援システムは、開発対象システムに対する発注者側の上位概念的な要求事項である基本要件を、開発対象システム毎に複数登録しておく基本要件ＤＢと、特定の基本要件に従属する下位概念的な要求事項である子要件を登録しておく子要件ＤＢと、特定の子要件をより具体化させた要求事項であるシステム対応を登録しておくシステム対応ＤＢと、開発対象システムが備えるべき基本機能を、開発対象システム毎に複数登録しておく基本機能ＤＢと、特定の基本機能を具体化したソフトウェア仕様を登録しておくソフトウェア仕様ＤＢと、上記子要件とシステム対応とのリンク情報を登録しておく子要件−対応ＤＢと、上記システム対応とソフトウェア仕様とのリンク情報を登録しておく対応−仕様ＤＢと、ディスプレイと、入力装置と、画面生成部と、データ更新部とを備えたシステム開発支援システムであって、上記画面生成部は、上記基本要件の内容及びタイトルを入力するための基本要件更新フォームを生成し、上記のディスプレイに表示させる処理と、上記子要件の内容及び当該子要件が従属する基本要件を特定する基本要件IDを入力するための子要件更新フォームを生成し、上記のディスプレイに表示させる処理と、上記システム対応の内容及び当該システム対応が従属する基本要件を特定する基本要件IDを入力するためのシステム対応更新フォームを生成し、上記のディスプレイに表示させる処理と、上記基本機能の内容及び名称を入力するための機能更新フォームを生成し、上記のディスプレイに表示させる処理と、上記ソフトウェア仕様の内容、当該ソフトウェア仕様が従属する基本機能を特定する機能ID、及び当該ソフトウェア仕様が関連する基本要件を特定する基本要件IDを入力するためのソフトウェア仕様更新フォームを生成し、上記のディスプレイに表示させる処理と、特定の子要件とシステム対応とを対応付けるための子要件・システム対応登録フォームを生成し、上記のディスプレイに表示させる処理と、特定のシステム対応とソフトウェア仕様とを対応付けるためのシステム対応・ソフトウェア仕様登録フォームを生成し、上記のディスプレイに表示させる処理を実行し、上記データ更新部は、上記基本要件更新フォームを通じて入力された基本要件の内容及びタイトルを、固有の基本要件IDに関連付けて上記基本要件ＤＢに登録する処理と、上記子要件更新フォームを通じて入力された子要件の内容及び基本要件IDを、固有の子要件IDに関連付けて上記子要件ＤＢに登録する処理と、上記システム対応更新フォームを通じて入力されたシステム対応の内容及び基本要件IDを、固有の対応IDに関連付けて上記システム対応ＤＢに登録する処理と、上記機能更新フォームを通じて入力された基本機能の内容及び名称を、固有の機能IDに関連付けて上記基本機能ＤＢに登録する処理と、上記ソフトウェア仕様更新フォームを通じて入力されたソフトウェア仕様の内容、機能ID及び基本要件IDを、固有の仕様IDに関連付けて上記ソフトウェア仕様ＤＢに登録する処理と、上記子要件・システム対応登録フォームを通じて入力された特定の子要件とシステム対応とのリンク情報を、上記子要件−対応ＤＢに登録する処理と、上記システム対応・ソフトウェア仕様登録フォームを通じて入力された特定のシステム対応とソフトウェア仕様とのリンク情報を、上記対応−仕様ＤＢに登録する処理を実行することを特徴としている。
上記の「基本要件」は、システムに対する要求項目を少なくとも上位、中位、下位の三階層構造で観念する場合における上位概念的な要件を指し、「子要件」はその中位概念的な要件を、また「システム対応」は下位概念的な要件を指しているのであり、必ずしも基本要件、子要件、システム対応の名称に限定する趣旨ではない。例えば、基本要件を上位要件に、子要件を中位要件に、システム対応を下位要件に置き換えることもできる。
The system development support system according to
The above “basic requirements” refer to the upper conceptual requirements when the requirements for the system are considered at least in the upper, middle, and lower three hierarchical structures, and the “child requirements” refer to the intermediate conceptual requirements. In addition, “system correspondence” refers to subordinate conceptual requirements and is not necessarily limited to basic requirements, child requirements, and system correspondence names. For example, the basic requirement can be replaced with a higher requirement, the child requirement can be replaced with a middle requirement, and the system correspondence can be replaced with a lower requirement.
請求項３に記載したシステム開発支援システムは、請求項１または２のシステムを前提とし、特定の基本要件に係る関連情報を登録しておく関連情報のＤＢをさらに備え、上記画面生成部が、上記関連情報の内容及び当該関連情報が従属する基本要件を特定する基本要件IDを入力するためのフォームを生成し、上記のディスプレイに表示させる処理を実行し、上記データ更新部が、上記フォームを通じて入力された関連情報の内容及び基本要件IDを、固有のIDに関連付けて上記ＤＢに登録する処理を実行することを特徴としている。
上記の関連情報として、例えばシステムに対する制約事項、ＱＡデータ、検討事項、課題、ユースケースなどが該当する。
The system development support system described in claim 3 is premised on the system of
Examples of the related information include system restrictions, QA data, considerations, issues, use cases, and the like.
請求項４に記載したシステム開発支援システムは、請求項１〜３のシステムを前提とし、データ出力部をさらに備え、上記画面生成部が、出力すべきドキュメントの種類を選択するためのフォームを生成し、上記ディスプレイに表示させる処理を実行し、上記データ出力部が、このフォームを通じて選択されたドキュメントを生成するのに必要なデータを、上記の各種ＤＢから抽出する処理と、抽出したデータを所定のテンプレートに充填して出力用のドキュメントファイルを生成する処理を実行することを特徴としている。
A system development support system according to claim 4 is based on the system according to
請求項１に記載のシステム開発支援システムにあっては、システムに対する要求項目を基本要件及び子要件の階層構造で登録すること、及びシステムが備えるべき機能項目を基本機能及びソフトウェア仕様の階層構造で登録することが前提であり、子要件の登録時には必ず上位概念である基本要件を特定することが求められ、ソフトウェア仕様の登録時には必ず上位概念である基本機能を特定することが求められるため、開発担当者はそれぞれのフォームに必要情報を入力することにより、比較的粒度が揃い、かつ構造化された要件オブジェクトや機能オブジェクトを各記憶手段内に登録することが可能となる。
しかも、子要件とソフトウェア仕様との間のリンク情報を登録することにより、基本要件と基本機能との連続性が担保されるため、基本要件や子要件に変動が生じた場合でも、影響の及ぶソフトウェア仕様や基本機能を容易に特定することが可能となる。また、発注者の要求項目がソフトウェア仕様や基本機能として具現化されているか否かが一目瞭然となり、要求項目の漏れを事前にチェックすることができる。
In the system development support system according to
In addition, by registering link information between child requirements and software specifications, continuity between basic requirements and basic functions is guaranteed, so even if basic requirements and child requirements change, it will have an impact. Software specifications and basic functions can be easily specified. Further, it becomes obvious at a glance whether or not the request item of the orderer is embodied as a software specification or a basic function, and it is possible to check in advance whether the request item is missing.
請求項２に記載のシステム開発支援システムによれば、システムに対する要求項目が基本要件、子要件及びシステム対応の３層構造として登録されるため、開発担当者はより高度に構造化され、かつ粒度の揃った要件オブジェクトを開発することが可能となる。
この場合も、子要件とシステム対応間のリンク情報、及びシステム対応とソフトウェア仕様間のリンク情報を登録することにより、基本要件と基本機能との連続性が担保されるため、基本要件や子要件、システム対応に変動が生じた場合でも、影響の及ぶソフトウェア仕様や基本機能を容易に特定することが可能となる。また、発注者の要求項目がソフトウェア仕様や基本機能として具現化されているか否かが一目瞭然となり、要求項目の漏れを事前にチェックすることができる。
According to the system development support system of the second aspect , since the requirement items for the system are registered as a three-layer structure corresponding to the basic requirement, the child requirement, and the system, the person in charge of development is more highly structured, and the granularity It is possible to develop a requirement object with a complete set.
In this case as well, continuity between basic requirements and basic functions is ensured by registering link information between child requirements and system compatibility, and link information between system compatibility and software specifications. Even if the system compatibility fluctuates, it is possible to easily identify the affected software specifications and basic functions. Further, it becomes obvious at a glance whether or not the request item of the orderer is embodied as a software specification or a basic function, and it is possible to check in advance whether the request item is missing.
請求項３に記載のシステム開発支援システムによれば、制約事項やＱＡデータ、ユースケース等の関連情報を基本要件に紐付けした形で登録することが可能となり、開発担当者が特定の基本要件に係る子要件やシステム対応、ソフトウェア仕様を登録する際に、これらの必要情報を容易に参照することが可能となる。 According to the system development support system described in claim 3 , it becomes possible to register related information such as restrictions, QA data, use cases, etc. in association with the basic requirements, and the person in charge of development can specify specific basic requirements. It is possible to easily refer to these necessary information when registering the child requirements, system compatibility, and software specifications related to.
請求項４に記載のシステム開発支援システムによれば、各記憶手段内に登録された要件オブジェクトや機能オブジェクトの中から必要なものを抽出し、これを各種ドキュメントとしてプリントアウトすることが可能となる。 According to the system development support system of the fourth aspect , it is possible to extract necessary objects from the requirement objects and function objects registered in each storage means and print them out as various documents. .
図１は、この発明に係るシステム開発支援システム10の構成を示すブロック図であり、画面生成部12と、データ出力部14と、データ更新部16と、オブジェクトＤＢ群18と、キーボードやマウス等の入力装置20と、ディスプレイ22とを備えている。
上記画面生成部12、データ出力部14、及びデータ更新部16は、パソコン等のコンピュータ24のCPUが、OS及び専用のアプリケーションプログラムに従って必要な処理を実行することによって実現される。
FIG. 1 is a block diagram showing the configuration of a system
The
また、上記オブジェクトＤＢ群18はコンピュータ24のハードディスク内に設けられており、図２に示すように、基本要件ＤＢ30、子要件ＤＢ31、ユースケースＤＢ32、課題ＤＢ33、ＱＡ ＤＢ34、制約ＤＢ35、検討ＤＢ36、子要件−対応ＤＢ37、システム対応ＤＢ38、対応−仕様ＤＢ39、ソフトウェア仕様ＤＢ40、基本機能ＤＢ41が含まれている。
The
基本要件ＤＢ30には、発注者の業務に係る上位概念的な要求項目である「基本要件」等のデータ項目が、固有の基本要件IDに関連付けて登録されている。
子要件ＤＢ31には、特定の基本要件の下位概念的な要求項目である「子要件」等のデータ項目が、固有の子要件ID及び自らが従属する基本要件のIDに関連付けて登録されている。
ユースケースＤＢ32には、特定の基本要件に係る「ユースケース」等のデータ項目が、固有のユースケースID及び関係する基本要件のIDに関連付けて登録されている。
課題ＤＢ33には、特定の基本要件に係る「課題」等のデータ項目が、固有の課題ID及び関係する基本要件のIDに関連付けて登録されている。
ＱＡＤＢ34には、特定の基本要件に係る「ＱＡ（質問及び回答データ）」等のデータ項目が、固有のＱＡID及び関係する基本要件のIDに関連付けて登録されている。
制約ＤＢ35には、特定の基本要件に係る「制約条件」等のデータ項目が、固有の制約ID及び関係する基本要件のIDに関連付けて登録されている。
検討ＤＢ36には、特定の基本要件に係る「検討内容」等のデータ項目が、固有の検討ID及び関係する基本要件のIDに関連付けて登録されている。
システム対応ＤＢ38には、特定の子要件をシステム向けにより具体的かつ詳細に記述した要件である「システム対応」等のデータ項目が、固有の対応ID、関係する子要件のID、及び基本要件のIDに関連付けて登録されている。
基本機能ＤＢ41には、開発対象であるシステムの「機能内容」等のデータ項目が、固有の機能ID、機能名称に関連付けて登録されている。
ソフトウェア仕様ＤＢ40には、開発対象であるソフトウェアのより具体的な機能オブジェクトである「仕様」が、固有の仕様ID、関係する基本要件のID、従属する基本機能のIDに関連付けて登録されている。
子要件−対応ＤＢ37は、特定の子要件と一又は複数のシステム対応とをリンクさせるためのデータベースであり、子要件ID、対応ID、基本要件ID等のデータ項目を備えている。
対応−仕様ＤＢ39は、特定のシステム対応と一又は複数のソフトウェア仕様とをリンクさせるためのデータベースであり、対応ID、仕様ID、基本要件ID等のデータ項目を備えている。
In the
In the
In the
In the
In the
In the
In the
In the
In the
In the
The child requirement-
The correspondence-
図３は、各ＤＢに登録されたオブジェクト間の関係を図示したものであり、一つの基本要件に対し複数の子要件と、制約、ＱＡ、検討、ユースケース、課題の各オブジェクトが従属している構造が描かれている。
また、一つの子要件には子要件−対応ＤＢ37を介して複数のシステム対応が関連付けられており、一つのシステム対応には対応−仕様ＤＢ39を介して複数のソフトウェア仕様が関連付けられている。
また、各基本機能は、複数のソフトウェア仕様に関連付けられている。
さらに、各基本要件には大分類及び中分類が関連付けられており、一つの基本要件がこの階層構造の小分類に相当している。
FIG. 3 illustrates the relationship between objects registered in each DB. A plurality of child requirements and constraints, QA, examination, use case, and task objects are subordinate to one basic requirement. The structure is drawn.
A plurality of system correspondences are associated with one child requirement via a child requirement-
Each basic function is associated with a plurality of software specifications.
Furthermore, each basic requirement is associated with a large classification and a medium classification, and one basic requirement corresponds to a small classification of this hierarchical structure.
例えば、大分類＝「単品管理支援」、中分類＝「発注」に属する基本要件(1)「加食（加工食品）・デイリー商品の発注を行う」は、子要件(1)「パートさんは発注作業中に売場にて商品情報を参照する」を含んでおり、システム対応(1)「パートさんは売場にて商品情報を参照することができる」、ソフトウェア仕様(1)「発注メンテの画面上に商品のマスタ属性を表示する」及びソフトウェア仕様(2)「発注メンテの画面上に商品の企画情報を表示する」を介して基本機能(1)「発注メンテナンス機能」に関連付けられている。 For example, the basic requirement (1) “Order food (processed food) and daily products” that belongs to the major category = “single item management support” and the middle category = “order” is the child requirement (1) “ `` Refer to product information at the sales floor during ordering work '' and system support (1) `` Parts can refer to product information at the sales floor '', software specifications (1) `` Order maintenance screen It is related to the basic function (1) “Order Maintenance Function” via “Display Product Master Attributes on” and Software Specification (2) “Display Product Planning Information on Order Maintenance Screen”.
図４は、複数の基本要件と基本機能との関係を図示したものであり、基本要件(1)に属する子要件(a)は、システム対応(a)及びソフトウェア仕様(a)を通じて基本機能(1)に関係し、子要件(b)は、システム対応(b)及びソフトウェア仕様(b)を通じて基本機能(3)に関係している様子を表現している。
また、基本要件(2)に属する子要件(c)は、システム対応(c)及びソフトウェア仕様(c)を通じて基本機能(2)に関係し、子要件(d)は、システム対応(d)及びソフトウェア仕様(d)を通じて基本機能(4)に関係している。
また、基本要件(3)に属する子要件(e)は、システム対応(e)及びソフトウェア仕様(e)を通じて基本機能(1)に関係し、子要件(f)は、システム対応(f)及びソフトウェア仕様(f)を通じて基本機能(4)に関係している。
さらに、基本要件(4)に属する子要件(g)は、システム対応(g)及びソフトウェア仕様(g)を通じて基本機能(3)に関係し、子要件(h)は、システム対応(h)及びソフトウェア仕様(h)を通じて基本機能(3) に関係している様子が示されている。
FIG. 4 illustrates the relationship between a plurality of basic requirements and basic functions. The child requirement (a) belonging to the basic requirement (1) is defined by the basic function (a) and the software specification (a). In relation to 1), child requirement (b) expresses how it is related to basic function (3) through system compatibility (b) and software specification (b).
The child requirement (c) belonging to the basic requirement (2) is related to the basic function (2) through the system compatibility (c) and the software specification (c), and the child requirement (d) is related to the system compatibility (d) and It is related to the basic function (4) through the software specification (d).
The child requirement (e) belonging to the basic requirement (3) is related to the basic function (1) through the system compatibility (e) and the software specification (e), and the child requirement (f) is related to the system compatibility (f) and It is related to the basic function (4) through the software specification (f).
Furthermore, the child requirement (g) belonging to the basic requirement (4) is related to the basic function (3) through the system compatibility (g) and the software specification (g), and the child requirement (h) is related to the system compatibility (h) and The state related to the basic function (3) is shown through the software specification (h).
図示の便宜上、図４においては各子要件とシステム対応が一対一で対応しており、また各システム対応とソフトウェア仕様が一対一で対応している例が描かれているが、実際には図３に示したように、各子要件に対して複数のシステム対応を関連付けると共に、各システム対応に対して複数のソフトウェア仕様を関連付けることが可能である。
また、図４においては、一つの基本要件が複数の基本機能との間で関連性を有すると共に、一つの基本機能が複数の基本要件との間で関連性を有することが表現されているが、基本要件と基本機能とを一対一の関係で対応させることも可能である。
For convenience of illustration, FIG. 4 shows an example in which each child requirement and system correspondence correspond one-to-one, and each system correspondence and software specification correspond one-to-one. As shown in FIG. 3, a plurality of system correspondences can be associated with each child requirement, and a plurality of software specifications can be associated with each system correspondence.
In FIG. 4, it is expressed that one basic requirement has a relationship with a plurality of basic functions and one basic function has a relationship with a plurality of basic requirements. The basic requirements and the basic functions can be associated with each other in a one-to-one relationship.
以上の結果、ある基本要件あるいは子要件について変更が生じた場合に、これに関連付けられたシステム対応及びソフトウェア仕様を辿ることにより、影響が及ぶ基本機能を特定することが可能となり、必要な修正を施すことができる。 As a result, when a change occurs in a basic requirement or a child requirement, it is possible to identify the affected basic function by tracing the system compatibility and software specifications associated with it, and make necessary corrections. Can be applied.
つぎに、このシステムを用いた各オブジェクトの登録手順について説明する。
まず開発担当者は、パソコン上に専用のアプリケーションプログラムを起動させる。
この結果、図５に示すように、メニュー画面50がディスプレイ22上に表示される。
ここで開発担当者が「要件オブジェクト」の「基本要件」ボタン51をクリックすると、画面生成部12によって「基本要件更新フォーム」が生成され、図６に示すように、ディスプレイ22に表示される。
Next, the registration procedure of each object using this system will be described.
First, the developer in charge starts a dedicated application program on the personal computer.
As a result, a
Here, when the person in charge of development clicks the “basic requirement”
この基本要件更新フォーム52に対し、開発担当者は基本要件タイトル、大分類、中分類、基本要件内容、優先度等の各項目に必要事項を入力する（基本要件IDには、システムの側で自動採番されているため、入力する必要はない）。
各項目の中、「基本要件内容」の入力欄には、開発対象であるシステムに対し発注者が求める基本的な要求事項が記述される。
必要事項の入力を終えた開発担当者は、「新規レコードの追加」ボタンをクリックする。
これを受けたデータ更新部16は、開発担当者が入力したデータを基本要件ＤＢ30に格納する。また、新たな基本要件IDが採番された基本要件更新フォーム52が画面生成部12によって生成され、ディスプレイ22に表示される。
なお、基本要件更新フォーム52における必須項目、例えば基本要件タイトル、大分類、中分類、基本要件内容等の入力欄に入力漏れがある場合、データ更新部16がこれを検知し、エラーメッセージがディスプレイ22に表示され、その登録が拒絶される。
一旦登録した基本要件が不要となった場合、開発担当者は「レコード削除」ボタンをクリックする。これを受けたデータ更新部16は、該当のレコードを基本要件ＤＢ30から削除する。
必要な基本要件の入力や削除を終えた開発担当者は、「フォームを閉じる」ボタンをクリックし、図５のメニュー画面50に戻る。
For this basic
Among the items, the basic requirement items required by the orderer for the system to be developed are described in the “basic requirement content” input field.
After completing the necessary information, the developer in charge clicks the “Add new record” button.
Receiving this, the
In addition, when there are omissions in input fields such as basic requirement title, major category, middle category, basic requirement contents, etc. in the basic
Once the basic requirements once registered are no longer needed, the developer clicks the “Delete Record” button. Receiving this, the
The developer in charge who has finished inputting or deleting necessary basic requirements clicks the “close form” button and returns to the
つぎに開発担当者が「要件オブジェクト」の「子要件」ボタン53をクリックすると、画面生成部12によって「子要件更新フォーム」が生成され、図７に示すように、ディスプレイ22に表示される。
この子要件更新フォーム54には、子要件ID、基本要件ID、子要件、優先度等の入力項目が左半分に設けられると共に、右半分には登録済みの基本要件リスト55が表示されている。
そこで開発担当者は、まず基本要件リスト55中から子要件を従属させる基本要件をマウスポインタで選択する。例えば、「売上計画」という基本要件を開発担当者が選択すると、基本要件ID欄に該当の基本要件IDである「BR010」が自動的に入力される。
つぎに開発担当者は、子要件、優先度、難易度、安定度等の入力欄に必要情報を入力する（「子要件ID」欄には、システムの側で自動採番されているため、入力する必要はない）。
各項目の中、「子要件」の入力欄には、当該基本要件の下位概念に含まれるより具体的な要求事項が記述される。
必要事項の入力を終えた開発担当者は、「新規レコードの追加」ボタンをクリックする。
これを受けたデータ更新部16は、開発担当者が入力したデータを子要件ＤＢ31に格納すると共に、新たな子要件IDが採番された子要件更新フォーム54が画面生成部12によって生成され、ディスプレイ22に表示される。
子要件更新フォーム54における必須項目、例えば基本要件ID欄や子要件の入力欄に入力漏れがある場合、データ更新部16がこれを検知し、エラーメッセージがディスプレイ22に表示され、その登録が拒絶される。
一旦登録した子要件が不要となった場合、開発担当者は「レコード削除」ボタンをクリックする。これを受けたデータ更新部16は、該当のレコードを子要件ＤＢ31から削除する。
必要な子要件の入力や削除を終えた開発担当者は、「フォームを閉じる」ボタンをクリックし、図５のメニュー画面50に戻る。
Next, when the person in charge of development clicks the “child requirement”
In this child
Therefore, the developer in charge selects a basic requirement to subordinate the child requirement from the
Next, the person in charge of development inputs necessary information in the input fields such as child requirement, priority, difficulty, stability, etc. (Because the “child requirement ID” field is automatically numbered by the system side, No need to enter).
In each item, a more specific requirement included in the subordinate concept of the basic requirement is described in the “child requirement” input field.
After completing the necessary information, the developer in charge clicks the “Add new record” button.
Upon receiving this, the
If there is an input omission in a required item in the child
Once the registered child requirements are no longer needed, the developer in charge clicks the “Delete Record” button. Receiving this, the
The developer in charge who has finished inputting or deleting the necessary child requirements clicks the “close form” button and returns to the
つぎに開発担当者が「要件オブジェクト」の「システム対応」ボタン56をクリックすると、画面生成部12によって「システム対応更新フォーム」が生成され、ディスプレイ22に表示される（図示省略）。
このシステム対応更新フォームは上記の子要件更新フォーム54と類似の構成を備えており、対応ID、基本要件ID、システム対応、分類等の入力項目が左半分に設けられると共に、右半分には登録済みの基本要件リストが表示されている。
そこで開発担当者は、まず基本要件リスト中からシステム対応を従属させる基本要件をマウスポインタで選択する。この結果、基本要件ID欄に該当の基本要件IDが自動的に入力される。
つぎに開発担当者は、システム対応、分類等の入力欄に必要情報を入力する（「対応ID」欄には、システムの側で自動採番されているため、入力する必要はない）。
各項目の中、「システム対応」の入力欄には、特定の子要件をより詳細化、具体化した内容の文章が記述される。
必要事項の入力を終えた開発担当者は、「新規レコードの追加」ボタンをクリックする。
これを受けたデータ更新部16は、開発担当者が入力したデータをシステム対応ＤＢ38に格納すると共に、新たな対応IDが採番されたシステム対応更新フォームが画面生成部12によって生成され、ディスプレイ22に表示される。
システム対応更新フォームにおける必須項目、例えば基本要件ID欄やシステム対応の入力欄に入力漏れがある場合、データ更新部16がこれを検知し、エラーメッセージがディスプレイ22に表示され、その登録が拒絶される。
一旦登録したシステム対応が不要となった場合、開発担当者は「レコード削除」ボタンをクリックする。これを受けたデータ更新部16は、該当のレコードをシステム対応ＤＢ38から削除する。
必要なシステム対応の入力や削除を終えた開発担当者は、「フォームを閉じる」ボタンをクリックし、図５のメニュー画面50に戻る。
Next, when the person in charge of development clicks the “system correspondence”
This system compatible update form has a similar configuration to the child
Therefore, the developer in charge selects the basic requirement for subordinate system correspondence from the basic requirement list with the mouse pointer. As a result, the corresponding basic requirement ID is automatically entered in the basic requirement ID column.
Next, the person in charge of development inputs necessary information in the input fields for system correspondence, classification, etc. (the “corresponding ID” field is automatically numbered on the system side, so there is no need to input it).
In each item, in the “system compatible” input column, a sentence that describes a specific child requirement in more detail and form is described.
After completing the necessary information, the developer in charge clicks the “Add new record” button.
In response to this, the
If there is an input omission in a required item in the system update form, for example, the basic requirement ID field or the system input field, the
Once the registered system is no longer required, the developer in charge clicks the “Delete Record” button. Receiving this, the
The developer in charge who has finished inputting and deleting the necessary system, clicks the “close form” button and returns to the
開発担当者は、メニュー画面50における「要件オブジェクト」の「制約」ボタン57、「課題」ボタン58、「ＱＡ」ボタン59、「検討」ボタン60、「ユースケース」ボタン61をクリックすることにより、特定の基本要件に係る制約、課題、ＱＡ、検討、ユースケースの各関連情報を、それぞれ制約ＤＢ35、課題ＤＢ33、ＱＡ ＤＢ34、検討ＤＢ36、ユースケースＤＢ32内に登録することもできる。
この場合、画面生成部12によって各関連情報登録用の更新フォームが生成され、ディスプレイ22に表示される（図示省略）。
これらの更新フォームは上記の子要件更新フォーム54と類似の構成を備えており、システム10によって自動採番されるID表示項目の他、従属する基本要件のID表示欄、各関連情報の入力欄及び基本要件リストの表示欄が設けられている。
そこで開発担当者は、まず基本要件リスト中から各関連情報を従属させる基本要件をマウスポインタで選択する。この結果、基本要件ID欄に該当の基本要件IDが表示される。
つぎに開発担当者は、制約条件、課題等の関連情報入力欄に必要情報を入力する。
必要事項の入力を終えた開発担当者が「新規レコードの追加」ボタンをクリックすると、データ更新部16が入力データを該当のＤＢに格納すると共に、新たなIDが採番された更新フォームが画面生成部12によって生成され、ディスプレイ22に表示される。
各更新フォームにおける必須項目、例えば基本要件ID欄や各関連情報の入力欄に入力漏れがある場合、データ更新部16がこれを検知し、エラーメッセージがディスプレイ22に表示され、その登録が拒絶される。
一旦登録した関連情報が不要となった場合、開発担当者は「レコード削除」ボタンをクリックする。これを受けたデータ更新部16は、該当のレコードを対応のＤＢから削除する。
必要な関連情報の登録を終えた開発担当者は、「フォームを閉じる」ボタンをクリックし、図５のメニュー画面50に戻る。
The developer in charge clicks the “restriction”
In this case, the
These update forms have a similar configuration to the child
Accordingly, the developer in charge first selects a basic requirement for making each related information subordinate from the basic requirement list with a mouse pointer. As a result, the corresponding basic requirement ID is displayed in the basic requirement ID column.
Next, the person in charge of development inputs necessary information in the related information input fields such as constraint conditions and issues.
When the developer in charge who has entered the necessary information clicks the “Add New Record” button, the
If there is an input omission in a required field in each update form, such as the basic requirement ID field or each related information input field, the
If the related information once registered is no longer necessary, the developer in charge clicks the “Delete Record” button. Receiving this, the
The developer in charge who has registered the necessary related information clicks the “close form” button and returns to the
つぎに開発担当者がメニュー画面50における「機能オブジェクト」の「基本機能」ボタン62をクリックすると、画面生成部12によって「機能更新フォーム」が生成され、図８に示すように、ディスプレイ22に表示される。
この機能更新フォーム63には、機能ID、機能名称、機能内容、分類、区分等の入力項目が設けられており、開発担当者は各項目の入力欄に必要事項を入力する（但し、機能ID項目に関してはシステムによって自動採番されるため、入力する必要はない）。
機能名称には、「発注メンテナンス」や「マスタ管理」、「仕入管理」等が入力され、機能内容には当該機能の概要が記述される。
必要事項の入力を終えた開発担当者は、「新規レコードの追加」ボタンをクリックする。
これを受けたデータ更新部16は、開発担当者が入力したデータを基本機能ＤＢ41に格納すると共に、新たな機能IDが採番された基本機能更新フォーム63が画面生成部12によって生成され、ディスプレイ22に表示される。
機能更新フォーム63における必須項目、例えば機能名称や機能内容の入力欄に入力漏れがある場合、データ更新部16がこれを検知し、エラーメッセージがディスプレイ22に表示され、その登録が拒絶される。
一旦登録した基本機能が不要となった場合、開発担当者は「レコード削除」ボタンをクリックする。これを受けたデータ更新部16は、該当のレコードを基本機能ＤＢ41から削除する。
必要な基本機能の入力や削除を終えた開発担当者は、「フォームを閉じる」ボタンをクリックし、図５のメニュー画面50に戻る。
Next, when the person in charge of development clicks the “fundamental function”
This
“Order maintenance”, “Master management”, “Purchase management”, and the like are input as the function name, and an outline of the function is described in the function content.
After completing the necessary information, the developer in charge clicks the “Add new record” button.
Upon receiving this, the
If there is an input omission in the required items in the
Once the registered basic functions are no longer needed, the developer in charge clicks the “Delete Record” button. Receiving this, the
The developer in charge who has finished inputting or deleting necessary basic functions clicks the “close form” button to return to the
つぎに開発担当者がメニュー画面50における「機能オブジェクト」の「ソフトウェア仕様」ボタン64をクリックすると、画面生成部12によって「ソフトウェア仕様更新フォーム」が生成され、図９に示すように、ディスプレイ22に表示される。
このソフトウェア仕様更新フォーム65には、基本要件ID、機能ID、ソフトウェアID、ソフトウェア仕様、顧客ステータス等の入力項目が設けられており、開発担当者は各項目の入力欄に必要事項を入力する（但し、ソフトウェアID項目に関してはシステムによって自動採番されるため、入力する必要はない）。
基本要件ID欄には、当該ソフトウェア仕様が従属する基本要件のIDを直接キーボードでタイプ入力する。あるいは、「基本要件IDの選択」項目の▼ボタンをクリックすると登録済み基本要件のリストがプルダウン表示されるため、その中の一つを選択してもよい。この場合、基本要件ID欄に当該基本要件のIDが自動的に充填される。
また、機能ID欄にも、当該ソフトウェア仕様が従属する基本機能のIDを直接キーボードでタイプ入力するか、「機能IDの選択」項目の▼ボタンをクリックし、プルダウン表示される登録済み基本機能のリスト中から一つを選択する。
「ソフトウェア仕様」の入力欄には、当該基本機能を実現するためにソフトウェアが備えるべき具体的な仕様が記述される。
必要事項の入力を終えた開発担当者は、「新規レコードの追加」ボタンをクリックする。これを受けたデータ更新部16は、開発担当者が入力したデータをソフトウェア仕様ＤＢ40に格納すると共に、新たなソフトウェアIDが採番されたソフトウェア仕様更新フォーム65が画面生成部12によって生成され、ディスプレイ22に表示される。
ソフトウェア仕様更新フォーム65における必須項目、例えば基本要件ID欄や機能ID欄、ソフトウェア仕様欄等の入力欄に入力漏れがある場合、データ更新部16がこれを検知し、エラーメッセージがディスプレイ22に表示され、その登録が拒絶される。
また、一旦登録したソフトウェア仕様が不要となった場合、開発担当者は「レコード削除」ボタンをクリックする。これを受けたデータ更新部16は、該当のレコードをソフトウェア仕様ＤＢ40から削除する。
必要なソフトウェア仕様の入力や削除を終えた開発担当者は、「フォームを閉じる」ボタンをクリックし、図５のメニュー画面50に戻る。
Next, when the person in charge of development clicks the “software specification”
This software
In the basic requirement ID column, the ID of the basic requirement on which the software specification depends is typed directly on the keyboard. Alternatively, when a “▼” button of the “Select basic requirement ID” item is clicked, a list of registered basic requirements is displayed in a pull-down manner, and one of them may be selected. In this case, the basic requirement ID column is automatically filled with the ID of the basic requirement.
Also, in the function ID column, type the ID of the basic function to which the software specification depends directly on the keyboard, or click the ▼ button of the “Select function ID” item and select the registered basic function that will be displayed in a pull-down list. Select one from the list.
In the “software specification” input field, specific specifications that the software should have in order to realize the basic function are described.
After completing the necessary information, the developer in charge clicks the “Add new record” button. Upon receipt of this, the
If there are omissions in the required fields on the software
If the registered software specification is no longer necessary, the developer in charge clicks the “Delete Record” button. Receiving this, the
The developer in charge who has finished inputting or deleting necessary software specifications clicks the “close form” button to return to the
つぎに開発担当者がメニュー画面50における「その他」の「子要件＿システム対応＿リンク」ボタン66をクリックすると、画面生成部12によって「子要件・システム対応登録フォーム」が生成され、図１０に示すように、ディスプレイ22に表示される。
この子要件・システム対応登録フォーム67に対し開発担当者は、まず「大分類」の選択欄において大分類を選択した後、「中分類」の選択欄において当該大分類に属する中分類の一つを選択する。
この結果、「基本要件」欄に当該中分類に属する全ての基本要件がリスト表示される。
ここで、開発担当者が特定の基本要件にマウスポインタを合わせてクリックすると、「子要件」欄及び「システム対応」欄に当該基本要件に関連付けられた子要件及びシステム対応がそれぞれリスト表示される。
Next, when the person in charge of development clicks a “child requirement_system correspondence_link”
In response to this child requirement /
As a result, all basic requirements belonging to the middle category are displayed in a list in the “basic requirements” column.
Here, when the developer in charge places the mouse pointer on a specific basic requirement and clicks, the child requirement and system correspondence associated with the basic requirement are listed in the “Child requirement” column and the “System correspondence” column, respectively. .
これに対し、開発担当者が特定の子要件をクリックによって選択した状態で任意のシステム対応を選択し、「プレビュー」ボタンをクリックすると、その左側に配置された「クロステーブル＿子要件＿対応」欄に対応関係が表示される。
この際、開発担当者は一つの子要件について複数のシステム対応を選択することができる。
対応関係に間違いがないことを確認した開発担当者が「登録」ボタンをクリックすると、これを受けたデータ更新部16は、開発担当者が選択入力したリンクデータを子要件−対応ＤＢ37に格納する。
必要なリンク付けを終えた開発担当者は、「フォームを閉じる」ボタンをクリックし、図５のメニュー画面50に戻る。
On the other hand, when the developer selects a specific child requirement by clicking on it and selects an arbitrary system correspondence, and clicks the “Preview” button, “Cross Table_Child Requirement_Correspondence” arranged on the left side thereof is selected. Correspondence is displayed in the column.
At this time, the person in charge of development can select a plurality of systems corresponding to one child requirement.
When the developer who has confirmed that there is no mistake in the correspondence, clicks the “Register” button, the
After completing the necessary linking, the developer in charge clicks the “close form” button to return to the
つぎに開発担当者がメニュー画面50における「その他」の「システム対応＿ソフトウェア仕様＿リンク」ボタン68をクリックすると、画面生成部12によって「システム対応・ソフトウェア仕様登録フォーム」が生成され、ディスプレイ22に表示される。
図示は省略したが、この「システム対応・ソフトウェア仕様登録フォーム」は上記の「子要件・システム対応登録フォーム」と類似の構成を備えており、開発担当者が「大分類」の選択欄において大分類を選択した後、「中分類」の選択欄において当該大分類に属する中分類の一つを選択すると、「基本要件」欄に当該中分類に属する全ての基本要件がリスト表示される。
ここで、開発担当者が特定の基本要件にマウスポインタを合わせてクリックすると、「システム対応」欄及び「ソフトウェア仕様」欄に当該基本要件に関連付けられた子要件及びシステム対応がそれぞれリスト表示される。
Next, when the person in charge of development clicks the “system compatible_software specification_link”
Although not shown, this “system compatibility / software specification registration form” has a similar structure to the above “child requirement / system compatibility registration form”. After selecting a category, if one of the medium categories belonging to the major category is selected in the “medium category” selection column, all the basic requirements belonging to the middle category are listed in the “basic requirement” column.
Here, when the developer in charge places the mouse pointer on a specific basic requirement and clicks, the child requirements and system correspondence associated with the basic requirement are displayed in a list in the “system correspondence” column and “software specification” column, respectively. .
これに対し、開発担当者が特定のシステム対応をクリックによって選択した状態で任意のソフトウェア仕様を選択し、「プレビュー」ボタンをクリックすると、その左側に配置された「クロステーブル＿対応＿仕様」欄に対応関係が表示される。
この際、開発担当者は一つのシステム対応について複数のソフトウェア仕様を選択することができる。
対応関係に間違いがないことを確認した開発担当者が「登録」ボタンをクリックすると、これを受けたデータ更新部16は、開発担当者が選択入力したリンクデータを対応−仕様ＤＢ39に格納する。
必要なリンク付けを終えた開発担当者は、「フォームを閉じる」ボタンをクリックし、図５のメニュー画面50に戻る。
On the other hand, when a developer selects an arbitrary software specification in a state where it is selected by clicking on a specific system, and clicks the “Preview” button, the “Cross Table_Supported_Specification” column arranged on the left side of the software specification The corresponding relationship is displayed in.
At this time, the person in charge of development can select a plurality of software specifications for one system.
When the developer in charge confirming that there is no mistake in the correspondence relationship, clicks the “Register” button, the
After completing the necessary linking, the developer in charge clicks the “close form” button to return to the
以上要するに、開発担当者はシステム開発に際し基本的な要求及び機能を予め基本要件及び基本機能としてデータベースに登録しておき、それぞれのより詳細かつ具体的な内容を子要件、システム対応、ソフトウェア仕様という異なった内容及びレベル（粒度）を備えた複数種のオブジェクトに分けて登録することが求められるため、これらのオブジェクトを登録する過程を通じて、強く意識することなく自然に、構造化されかつ粒度の揃った要件オブジェクトや機能オブジェクトを形成することが可能となる。
また、各オブジェクト間のリンク情報を後から修正することも容易であるため、各オブジェクトを取り敢えず思い付くままに登録しておき、後から各オブジェクト間の関連付けを見直すことも可能である。
In short, the person in charge of development registers basic requirements and functions in the database as basic requirements and basic functions in advance for system development, and each of these details is called child requirements, system compatibility, and software specifications. Since it is required to divide and register multiple types of objects with different contents and levels (granularity), the process of registering these objects is naturally structured and uniform in size without being strongly conscious. Requirement objects and function objects can be formed.
In addition, since it is easy to correct the link information between the objects later, it is possible to register each object as it comes to mind and to review the association between the objects later.
もちろん、多くの開発担当者がシステム開発に関与する場合には、事前に基本要件や子要件、システム対応、ソフトウェア仕様、基本機能として記述すべき内容について確認しておく必要はある。
しかしながら、全く白紙の状態で各オブジェクトを各自が登録する場合に比べ、例えば上記のように子要件、システム対応、ソフトウェア仕様を登録する際には必ず関連する基本要件の入力が求められるとか、ソフトウェア仕様を登録する際には基本機能の特定が求められるというように一定の登録規制が働くため、ある程度粒度が揃い、かつ構造化されたオブジェクトの開発が可能となる。
Of course, when many developers are involved in system development, it is necessary to confirm in advance the contents that should be described as basic requirements, child requirements, system compatibility, software specifications, and basic functions.
However, compared to the case where each object is registered in a completely blank state, for example, as described above, when registering child requirements, system compatibility, and software specifications, it is always necessary to input related basic requirements, When registering a specification, a certain registration restriction is applied so that the specification of a basic function is required. Therefore, it is possible to develop a structured object with a certain degree of granularity.
このシステム10は、オブジェクトＤＢ群18に登録された各種データを印刷またはファイル出力する機能を備えている。
すなわち、開発担当者がディスプレイ22に表示されたメニュー画面で「要件オブジェクトの印刷」を選択すると、画面生成部12によって印刷オプション設定フォームが生成され、ディスプレイ22に表示される（図示省略）。
このフォームにおいて開発担当者が印刷すべき要件オブジェクトの範囲やデータ項目を限定するためのフィルタ条件を設定し、プレビュー実行ボタンをクリックすると、データ出力部14がオブジェクトＤＢ群18から子要件やシステム対応等のオブジェクトにおける必要なデータ項目を抽出し、これらを所定のテンプレートに充填することによってソフトウェア要求仕様書が生成される。なお、上記印刷オプション設定フォームにおいて開発担当者がフィルタ条件を特に設定しない場合には、データ出力部14が予め定義された必要最小限のデータをオブジェクトＤＢ群18から抽出し、ソフトウェア要求仕様書を生成する。
このソフトウェア要求仕様書は、画面生成部12を介してディスプレイ22に表示される（図示省略）。
このプレビュー画面をチェックし、内容に問題がないことを確認した開発担当者が画面中の「印刷」ボタンをクリックすると、データ出力部14はプリンタ70を介して当該ソフトウェア要求仕様書をプリントアウトする。
This
That is, when the developer in charge selects “print requirement object” on the menu screen displayed on the
In this form, the developer sets filter conditions to limit the range of requirement objects and data items to be printed, and when the preview execution button is clicked, the
This software requirement specification is displayed on the
When the developer who checks this preview screen and confirms that there is no problem in the content clicks the “print” button in the screen, the
また、開発担当者がディスプレイ22に表示されたメニュー画面で「機能オブジェクトの印刷」を選択すると、画面生成部12によって印刷オプション設定フォームが生成され、ディスプレイ22に表示される（図示省略）。
このフォームにおいて開発担当者が印刷すべき機能オブジェクトの範囲やデータ項目を限定するためのフィルタ条件を設定し、プレビュー実行ボタンをクリックすると、データ出力部14がオブジェクトＤＢ群18から基本機能やソフトウェア仕様等のオブジェクトにおける必要なデータ項目を抽出し、これらを所定のテンプレートに充填することによってソフトウェア設計書が生成される。上記印刷オプション設定フォームにおいて開発担当者がフィルタ条件を特に設定しない場合には、データ出力部14が予め定義された必要最小限のデータをオブジェクトＤＢ群18から抽出し、ソフトウェア設計書を自動生成する。
このソフトウェア設計書は、画面生成部12を介してディスプレイ22に表示される（図示省略）。
このプレビュー画面をチェックし、内容に問題がないことを確認した開発担当者が画面中の「印刷」ボタンをクリックすると、データ出力部14はプリンタ70を介して当該ソフトウェア設計書をプリントアウトする。
When the person in charge of development selects “print function object” on the menu screen displayed on the
In this form, when the developer sets filter conditions for limiting the range of function objects and data items to be printed and clicks the preview execution button, the
This software design document is displayed on the
When the developer in charge who checks the preview screen and confirms that there is no problem in the content clicks the “print” button in the screen, the
このシステム10はさらに、オブジェクトＤＢ群18に登録された各種データをCSVやExcel（登録商標）等の形式でファイル出力することもできる。
この場合も上記と同様、開発担当者がディスプレイ22に表示された設定フォーム（図示省略）においてファイルに落とすべきデータ項目やオブジェクトの範囲を指定すると、データ出力部14がオブジェクトＤＢ群18から必要なデータを抽出し、帳票ファイル71を生成する。
The
Also in this case, as described above, when the developer in charge specifies a data item or a range of objects to be dropped in the file on the setting form (not shown) displayed on the
開発担当者は、プリントアウトされた上記のソフトウェア要求仕様書、ソフトウェア設計書、あるいは帳票ファイル71の内容をチェックすることにより、基本要件や子要件、システム対応、基本機能、ソフトウェア仕様の適否や欠落の有無を確認することができる。
特に、リンク情報の出力リストをチェックすることにより、子要件とシステム対応との関連付けの適否、あるいはシステム対応とソフトウェア仕様との関連付けの適否を確認することができ、リンク漏れの有無も一目瞭然となる。
これらの成果物の提供を受けた発注者側においても、自己の要求が全て要求仕様書やソフトウェア設計書中に反映されているか否かを事前チェックすることが可能となる。
しかも、上記のチェック過程を通じて問題を発見した場合、例えば子要件の修正が必要となった場合には、子要件−対応ＤＢ及び対応−仕様ＤＢのリンク情報を辿っていくことにより、影響が生じるソフトウェア仕様及び基本機能を的確に特定することができ、これらのオブジェクトに対して適切な修正を施すことが可能となる。
By checking the contents of the above-mentioned software requirement specifications, software design document, or
In particular, by checking the output list of link information, it is possible to confirm whether or not the association between the child requirement and the system correspondence is appropriate, or the association between the system correspondence and the software specification, and it is also obvious at a glance whether there is a link leak. .
The orderer who receives these deliverables can also check in advance whether or not all of their own requirements are reflected in the requirement specifications and software design documents.
In addition, when a problem is found through the above check process, for example, when it is necessary to correct a child requirement, there is an effect by following the link information of the child requirement-corresponding DB and the corresponding-specification DB. Software specifications and basic functions can be accurately identified, and appropriate modifications can be made to these objects.
上記の実施形態においては、要件オブジェクトが基本要件、子要件、及びシステム対応の三階層構造を備えており、最下位概念であるシステム対応を介して機能オブジェクトのソフトウェア仕様と子要件とがリンクされる例を示したが、この発明はこれに限定されるものではない。
すなわち、要件オブジェクトを基本要件及び子要件からなる二階層構造として構成し、子要件とソフトウェア仕様とを「子要件−ソフトウェア仕様ＤＢ」を介してリンクさせることも可能である。
この場合、画面生成部12によって図１０の子要件・システム対応登録フォームと類似の構成を備えた登録フォームが生成され、ディスプレイ22に表示される。
開発担当者がこのフォームにおいて必要な情報を選択・入力すると、データ更新部16によって当該リンクデータが子要件−ソフトウェア仕様ＤＢに格納される。
In the above embodiment, the requirement object has a three-layer structure of basic requirement, child requirement, and system correspondence, and the software specification of the functional object and the child requirement are linked through the system correspondence that is the lowest concept. However, the present invention is not limited to this example.
That is, it is possible to configure the requirement object as a two-layer structure composed of a basic requirement and a child requirement, and link the child requirement and the software specification via the “child requirement-software specification DB”.
In this case, a registration form having a configuration similar to the child requirement / system-compatible registration form in FIG. 10 is generated by the
When the person in charge of development selects / inputs necessary information in this form, the
また、要件オブジェクトを基本要件及び子要件からなる二階層構造、あるいは基本要件及、子要件及びシステム対応からなる三階層構造として構成しつつ、基本要件とソフトウェア仕様とを、間に子要件やシステム対応を介することなく直にリンクさせた状態でこのシステム10を運用することも可能である。
すなわち、図９に示したように、ソフトウェア仕様更新フォームには基本機能IDの入力のみならず基本要件IDの入力が義務付けられ、ソフトウェア仕様ＤＢ40には基本要件IDが登録されているため、開発担当者が「子要件−システム対応−ソフトウェア仕様」間のリンク付けを行う状態（三階層構造の場合）、あるいは「子要件−ソフトウェア仕様」間のリンク付けを行う状態（二階層構造の場合）でなくても、少なくとも基本要件とソフトウェア仕様間の関連付けが担保されており、基本要件と基本機能との連続性が確保されている。
In addition, while configuring the requirement object as a two-layer structure consisting of basic requirements and child requirements, or as a three-layer structure consisting of basic requirements, child requirements, and system correspondence, the basic requirements and software specifications are interleaved with child requirements and systems. It is also possible to operate this
That is, as shown in FIG. 9, the software specification update form requires not only the input of the basic function ID but also the input of the basic requirement ID, and the basic requirement ID is registered in the
上記基本要件と子要件との間に、階層構造を形成する１または複数の中間的な要件オブジェクトを設けることもできる。
例えば、基本要件の下位概念である第１次中間要件、第１次中間要件の下位概念である第２次中間要件、第２次中間要件を具体化した第３次中間要件を基本要件と子要件との間に設け、システム対応を合わせて全部で六階層の要件オブジェクト構造を形成することもできる。
この場合、各中間要件及び子要件の更新フォームにおいては、基本要件及び直近の上位要件の入力が求められ、各中間要件のデータベース及び子要件ＤＢにそのリンク情報が格納される。あるいは、リンク付け専用のフォームを通じて各中間要件間あるいは子要件とのリンクを設定し、専用のデータベースにリンク情報を登録するようにしてもよい。
One or a plurality of intermediate requirement objects that form a hierarchical structure may be provided between the basic requirement and the child requirement.
For example, the primary intermediate requirement that is a subordinate concept of the basic requirement, the secondary intermediate requirement that is a subordinate concept of the primary intermediate requirement, and the tertiary intermediate requirement that materializes the secondary intermediate requirement are the basic requirement and child It is also possible to form a requirement object structure with a total of six layers in combination with the requirements and to match the system correspondence.
In this case, in the update form of each intermediate requirement and child requirement, input of the basic requirement and the latest upper requirement is requested, and the link information is stored in the database of each intermediate requirement and the child requirement DB. Alternatively, links between intermediate requirements or child requirements may be set through a form dedicated to linking, and link information may be registered in a dedicated database.
同様に、上記基本機能とソフトウェア仕様との間に、階層構造を形成する１または複数の中間的な機能オブジェクトを設けることもできる。
例えば、基本機能の下位概念である第１次中間機能、第１次中間機能の下位概念である第２次中間機能、第２次中間機能を具体化した第３次中間機能を基本機能とソフトウェア仕様との間に設け、全部で五階層の機能オブジェクト構造を形成することもできる。
この場合、各中間機能及びソフトウェア仕様の更新フォームにおいては、基本機能及び直近の上位機能の入力が求められ、各中間機能のデータベース及びソフトウェア仕様ＤＢにそのリンク情報が格納される。あるいは、リンク付け専用のフォームを通じて各中間機能間あるいはソフトウェア仕様とのリンクを設定し、専用のデータベースにリンク情報を登録するようにしてもよい。
Similarly, one or a plurality of intermediate function objects forming a hierarchical structure may be provided between the basic function and the software specification.
For example, a primary intermediate function that is a subordinate concept of a basic function, a secondary intermediate function that is a subordinate concept of a primary intermediate function, and a tertiary intermediate function that embodies a secondary intermediate function are defined as a basic function and software. It is also possible to form a functional object structure having a total of five layers by providing it between the specifications.
In this case, in the update form for each intermediate function and software specification, the input of the basic function and the latest higher-level function are required, and the link information is stored in the database of each intermediate function and the software specification DB. Alternatively, links between intermediate functions or software specifications may be set through a dedicated link form, and link information may be registered in a dedicated database.
10 システム開発支援システム
12 画面生成部
14 データ出力部
16 データ更新部
18 オブジェクトＤＢ群
20 入力装置
22 ディスプレイ
24 コンピュータ
30 基本要件ＤＢ
31 子要件ＤＢ
32 ユースケースＤＢ
33 課題ＤＢ
35 制約ＤＢ
34 ＱＡ ＤＢ
36 検討ＤＢ
37 子要件−対応ＤＢ
38 システム対応ＤＢ
39 対応−仕様ＤＢ
40 ソフトウェア仕様ＤＢ
41 基本機能ＤＢ
50 メニュー画面
52 基本要件更新フォーム
54 子要件更新フォーム
55 基本要件リスト
63 基本機能更新フォーム
65 ソフトウェア仕様更新フォーム
67 子要件・システム対応登録フォーム
70 プリンタ
71 帳票ファイル
10 System development support system
12 Screen generator
14 Data output section
16 Data update part
18 Object DB group
20 Input device
22 display
24 computers
30 Basic requirement DB
31 Child requirement DB
32 Use Case DB
33 Assignment DB
35 Constraint DB
34 QA DB
36 Study DB
37 Child Requirement-Correspondence DB
38 System compatible DB
39 Correspondence-Specification DB
40 Software specification DB
41 Basic function DB
50 Menu screen
52 Basic Requirements Update Form
54 Child requirement update form
55 Basic Requirements List
63 Basic function update form
65 Software specification update form
67 Child Requirements / System Registration Form
70 Printer
71 Form file
Claims (4)
上記画面生成部は、上記基本要件の内容及びタイトルを入力するための基本要件更新フォームを生成し、上記のディスプレイに表示させる処理と、
上記子要件の内容及び当該子要件が従属する基本要件を特定する基本要件IDを入力するための子要件更新フォームを生成し、上記のディスプレイに表示させる処理と、
上記基本機能の内容及び名称を入力するための機能更新フォームを生成し、上記のディスプレイに表示させる処理と、
上記ソフトウェア仕様の内容、当該ソフトウェア仕様が従属する基本機能を特定する機能ID、及び当該ソフトウェア仕様が関連する基本要件を特定する基本要件IDを入力するためのソフトウェア仕様更新フォームを生成し、上記のディスプレイに表示させる処理と、
特定の子要件とソフトウェア仕様とを対応付けるための子要件・ソフトウェア仕様登録フォームを生成し、上記のディスプレイに表示させる処理を実行し、
上記データ更新部は、上記基本要件更新フォームを通じて入力された基本要件の内容及びタイトルを、固有の基本要件IDに関連付けて上記基本要件ＤＢに登録する処理と、
上記子要件更新フォームを通じて入力された子要件の内容及び基本要件IDを、固有の子要件IDに関連付けて上記子要件ＤＢに登録する処理と、
上記機能更新フォームを通じて入力された基本機能の内容及び名称を、固有の機能IDに関連付けて上記基本機能ＤＢに登録する処理と、
上記ソフトウェア仕様更新フォームを通じて入力されたソフトウェア仕様の内容、機能ID及び基本要件IDを、固有の仕様IDに関連付けて上記ソフトウェア仕様ＤＢに登録する処理と、
上記子要件・ソフトウェア仕様登録フォームを通じて入力された特定の子要件とソフトウェア仕様とのリンク情報を上記子要件−仕様ＤＢに登録する処理を実行することを特徴とするシステム開発支援システム。 A basic requirement DB for registering multiple basic requirements, which are higher-level conceptual requirements on the orderer side for the development target system, for each development target system, and a lower-level conceptual requirement subordinate to the specific basic requirements Register the child requirement DB for registering child requirements, the basic function DB for registering multiple basic functions that the development target system should have for each development target system, and the software specifications that materialize the specific basic functions. Development of a system including a software specification DB, a child requirement-specification DB for registering link information between the child requirements and the software specification, a display, an input device, a screen generation unit, and a data update unit A support system,
The screen generation unit generates a basic requirement update form for inputting the content and title of the basic requirement, and displays the display on the display.
A process for generating a child requirement update form for inputting a basic requirement ID for specifying a content of the child requirement and a basic requirement on which the child requirement is subordinate, and displaying the child requirement update form on the display;
A process for generating a function update form for inputting the contents and name of the basic function and displaying it on the display;
Generate a software specification update form for entering the contents of the software specification, the function ID that identifies the basic function to which the software specification depends, and the basic requirement ID that specifies the basic requirement to which the software specification relates. Processing to be displayed on the display;
Generate a child requirement / software specification registration form for associating a specific child requirement with the software specification, and execute the process to be displayed on the display above.
The data update unit is a process of registering the basic requirement contents and title input through the basic requirement update form in the basic requirement DB in association with a unique basic requirement ID,
A process of registering the content of the child requirement and the basic requirement ID input through the child requirement update form in the child requirement DB in association with the unique child requirement ID,
Processing for registering the content and name of the basic function input through the function update form in the basic function DB in association with a unique function ID;
A process of registering the software specification content, function ID, and basic requirement ID input through the software specification update form in the software specification DB in association with a specific specification ID;
A system development support system that executes a process of registering link information between a specific child requirement and a software specification entered through the child requirement / software specification registration form in the child requirement-specification DB .
上記画面生成部は、上記基本要件の内容及びタイトルを入力するための基本要件更新フォームを生成し、上記のディスプレイに表示させる処理と、
上記子要件の内容及び当該子要件が従属する基本要件を特定する基本要件IDを入力するための子要件更新フォームを生成し、上記のディスプレイに表示させる処理と、
上記システム対応の内容及び当該システム対応が従属する基本要件を特定する基本要件IDを入力するためのシステム対応更新フォームを生成し、上記のディスプレイに表示させる処理と、
上記基本機能の内容及び名称を入力するための機能更新フォームを生成し、上記のディスプレイに表示させる処理と、
上記ソフトウェア仕様の内容、当該ソフトウェア仕様が従属する基本機能を特定する機能ID、及び当該ソフトウェア仕様が関連する基本要件を特定する基本要件IDを入力するためのソフトウェア仕様更新フォームを生成し、上記のディスプレイに表示させる処理と、
特定の子要件とシステム対応とを対応付けるための子要件・システム対応登録フォームを生成し、上記のディスプレイに表示させる処理と、
特定のシステム対応とソフトウェア仕様とを対応付けるためのシステム対応・ソフトウェア仕様登録フォームを生成し、上記のディスプレイに表示させる処理を実行し、
上記データ更新部は、上記基本要件更新フォームを通じて入力された基本要件の内容及びタイトルを、固有の基本要件IDに関連付けて上記基本要件ＤＢに登録する処理と、
上記子要件更新フォームを通じて入力された子要件の内容及び基本要件IDを、固有の子要件IDに関連付けて上記子要件ＤＢに登録する処理と、
上記システム対応更新フォームを通じて入力されたシステム対応の内容及び基本要件IDを、固有の対応IDに関連付けて上記システム対応ＤＢに登録する処理と、
上記機能更新フォームを通じて入力された基本機能の内容及び名称を、固有の機能IDに関連付けて上記基本機能ＤＢに登録する処理と、
上記ソフトウェア仕様更新フォームを通じて入力されたソフトウェア仕様の内容、機能ID及び基本要件IDを、固有の仕様IDに関連付けて上記ソフトウェア仕様ＤＢに登録する処理と、
上記子要件・システム対応登録フォームを通じて入力された特定の子要件とシステム対応とのリンク情報を、上記子要件−対応ＤＢに登録する処理と、
上記システム対応・ソフトウェア仕様登録フォームを通じて入力された特定のシステム対応とソフトウェア仕様とのリンク情報を、上記対応−仕様ＤＢに登録する処理を実行することを特徴とするシステム開発支援システム。 A basic requirement DB for registering multiple basic requirements, which are higher-level conceptual requirements on the orderer side for the development target system, for each development target system, and a lower-level conceptual requirement subordinate to the specific basic requirements The child requirement DB for registering child requirements, the system correspondence DB for registering system correspondence, which is a requirement that materializes specific child requirements, and the basic functions that the development target system should have include A basic function DB to be registered for each system, a software specification DB to register a software specification that embodies a specific basic function, and a child requirement to register link information between the above child requirements and system correspondence -Correspondence DB, correspondence correspondence for registering link information between the above system correspondence and software specifications-Specification DB, display, input device, screen generator, A system development support system that includes a data updating unit,
The screen generation unit generates a basic requirement update form for inputting the content and title of the basic requirement, and displays the display on the display.
A process for generating a child requirement update form for inputting a basic requirement ID for specifying a content of the child requirement and a basic requirement on which the child requirement is subordinate, and displaying the child requirement update form on the display;
A process for generating a system compatible update form for inputting a basic requirement ID for specifying a basic requirement on which the system correspondence is dependent and a basic requirement on which the system correspondence is dependent, and displaying on the display;
A process for generating a function update form for inputting the contents and name of the basic function and displaying it on the display;
Generate a software specification update form for entering the contents of the software specification, the function ID that identifies the basic function to which the software specification depends, and the basic requirement ID that specifies the basic requirement to which the software specification relates. Processing to be displayed on the display;
A process for generating a child requirement / system registration form for associating a specific child requirement with a system correspondence and displaying it on the display,
Generate a system compatibility / software specification registration form for associating specific system compatibility with software specifications, and execute the process to display on the above display,
The data update unit is a process of registering the basic requirement contents and title input through the basic requirement update form in the basic requirement DB in association with a unique basic requirement ID,
A process of registering the content of the child requirement and the basic requirement ID input through the child requirement update form in the child requirement DB in association with the unique child requirement ID,
A process of registering the system correspondence content and basic requirement ID input through the system correspondence update form in the system correspondence DB in association with a unique correspondence ID;
Processing for registering the content and name of the basic function input through the function update form in the basic function DB in association with a unique function ID;
A process of registering the software specification content, function ID, and basic requirement ID input through the software specification update form in the software specification DB in association with a specific specification ID;
A process of registering link information between a specific child requirement and system correspondence entered through the child requirement / system correspondence registration form in the child requirement-correspondence DB;
A system development support system for executing a process of registering link information between a specific system correspondence and software specification entered through the system correspondence / software specification registration form in the correspondence-specification DB .
上記画面生成部が、上記関連情報の内容及び当該関連情報が従属する基本要件を特定する基本要件IDを入力するためのフォームを生成し、上記のディスプレイに表示させる処理を実行し、
上記データ更新部が、上記フォームを通じて入力された関連情報の内容及び基本要件IDを、固有のIDに関連付けて上記ＤＢに登録する処理を実行することを特徴とする請求項１または２に記載のシステム開発支援システム。 It further includes a related information DB for registering related information related to specific basic requirements,
The screen generation unit generates a form for inputting a basic requirement ID that specifies the content of the related information and the basic requirement on which the related information depends, and executes a process of displaying the form on the display.
The said data update part performs the process which links | relates the content and basic requirement ID of the related information input through the said form with unique ID, and registers them in said DB . System development support system.
上記画面生成部が、出力すべきドキュメントの種類を選択するためのフォームを生成し、上記ディスプレイに表示させる処理を実行し、
上記データ出力部が、このフォームを通じて選択されたドキュメントを生成するのに必要なデータを、上記の各種ＤＢから抽出する処理と、
抽出したデータを所定のテンプレートに充填して出力用のドキュメントファイルを生成する処理を実行することを特徴とする請求項１〜３の何れかに記載のシステム開発支援システム。 A data output unit;
The screen generator generates a form for selecting the type of document to be output, and executes a process for displaying on the display.
A process for the data output unit to extract data necessary for generating a document selected through the form from the various DBs;
The system development support system according to any one of claims 1 to 3, wherein a process for generating a document file for output by filling the extracted data in a predetermined template is executed .
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2004174233A JP4601998B2 (en) | 2004-06-11 | 2004-06-11 | System development support system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2004174233A JP4601998B2 (en) | 2004-06-11 | 2004-06-11 | System development support system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2005352869A JP2005352869A (en) | 2005-12-22 |
| JP4601998B2 true JP4601998B2 (en) | 2010-12-22 |
Family
ID=35587298
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004174233A Expired - Fee Related JP4601998B2 (en) | 2004-06-11 | 2004-06-11 | System development support system |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4601998B2 (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4893122B2 (en) * | 2006-06-22 | 2012-03-07 | 富士電機株式会社 | Software requirement description support system and method |
| JP4905119B2 (en) * | 2006-12-26 | 2012-03-28 | 富士電機株式会社 | Specification creation support apparatus and method |
| JP2008210076A (en) * | 2007-02-26 | 2008-09-11 | Nippon Telegr & Teleph Corp <Ntt> | Software deliverable management system and its method and program |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000066885A (en) * | 1998-08-21 | 2000-03-03 | Hitachi Ltd | Device and method for supporting request specification design and record medium |
| JP2000353082A (en) * | 1999-04-06 | 2000-12-19 | Nippon Steel Corp | Demand specifications description support device, method therefor and recording medium |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH08249168A (en) * | 1995-03-14 | 1996-09-27 | Fujitsu Ltd | Sortware request specification verifying method |
| JPH0934936A (en) * | 1995-07-24 | 1997-02-07 | Fujitsu Ltd | System developing process management method and device |
-
2004
- 2004-06-11 JP JP2004174233A patent/JP4601998B2/en not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000066885A (en) * | 1998-08-21 | 2000-03-03 | Hitachi Ltd | Device and method for supporting request specification design and record medium |
| JP2000353082A (en) * | 1999-04-06 | 2000-12-19 | Nippon Steel Corp | Demand specifications description support device, method therefor and recording medium |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2005352869A (en) | 2005-12-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7031955B1 (en) | Optimization using a multi-dimensional data model | |
| US7600182B2 (en) | Electronic data capture and verification | |
| US20060190275A1 (en) | Intellectual property management system | |
| US20110016448A1 (en) | System and method for rapid development of software applications | |
| US20060184918A1 (en) | Test manager | |
| US20070094306A1 (en) | Method and model for enterprise system development and execution | |
| MXPA06010977A (en) | A forms development platform. | |
| Blumöhr et al. | Variant configuration with SAP | |
| JP2010015458A (en) | Program correction support system, program correction support method, and program correction support program | |
| JP4601998B2 (en) | System development support system | |
| JP5619642B2 (en) | Business application component device | |
| US20040193634A1 (en) | Managing regulatory information | |
| Molina et al. | Specifying conceptual interface patterns in an object-oriented method with automatic code generation | |
| JP2004318208A (en) | Product data management system and program | |
| Buwalda et al. | Integrated Test Design and Automation: Using the Test Frame Method | |
| JP2012159998A5 (en) | ||
| Sukaviriya et al. | Model-driven approach for managing human interface design life cycle | |
| CN108021367B (en) | UI development system and method based on metadata framework | |
| JP4476233B2 (en) | Batch system resource management method | |
| JPH04137038A (en) | Application software generation device | |
| JP2007034806A (en) | Information processor and program | |
| JP6747668B2 (en) | Business application construction support system and program | |
| JP6425672B2 (en) | Design document input / output device, design document input / output system and design document input / output method | |
| Gray | A Demo Modelling Tool that Facilitates Semi-Automatic Demo-to-BPMN Transformations | |
| JP2006146677A (en) | Application development support system, data format generation method using the same, and data processing system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070328 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20100405 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100713 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100823 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100914 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100929 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131008 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |