続きを読む...

折りたたむ...

要求仕様の記述はこの単位文から始まります。単位文はif構文で前件を記述し、後件をDo構文で記述します。「○○のとき、××せよ」、という２つの単位文（○○と××）の結合をif構文とDo構文で表現します。しかしifがあれば、その反対のelseがなければ、条件が漏れてしまいます。したがって、SLPでは単位文を作成の際、このif-else-endif構文を表示し、elseも必ず記述するようになっています。

以上が「構文化手法」の大まかなところです。

しかし、これだと今までの「構造化英語（Structured English）」とどこが違うの？といわれそうです。
http://en.wikipedia.org/wiki/Structured_English

SLPは単位文で文を作るところが、このような構造化英語と異なります。（だから？）

だから、if <a>{P}

　　　　　　if、、、

　　　　　　　　if、、、

　　　　　　　　　　if <a>{¬P}　（・・・“¬”は否定を意味します）

と、もし、書かれていたなら、先頭行if <a>{P}のパス（経路）は、<a>{P}∧、、、、∧<a>{¬P}と連言（“and”）で結ばれます。そして、この例ではパスに主語<a>が背反しあう述語を持っていますから（<a>{P}と<a>{¬P}）、SLPはこのような文を（形式的）矛盾として自動検出します。

またSLPでは主語は１つの述語しか持つことができない、という原則からスタートします。すると、主語<a>が述語P以外に述語Rも持っていたとしたなら、SLPは（内容的に）矛盾化もしれない（から大丈夫か）と問いを発します。オペレーターはこのような場合、OKであったなら、無矛盾辞書に登録したり、OKでなかったら、述語を正しく書き変えたり、主語を書き変えたりします。

このようにSLPでは記述を進めて行くことにより、主語が持つべき述語を定めて行くことができます。ここが構造化英語と異なります。SLPでは主語（や目的語）をメンバーと呼び、述語を状態と呼んでいます。そしてこれらを文を構成する文要素とよんでいます。

どのようなメンバーがどのような状態を持って使われているのか、SLP文書の中のすべての文要素を一覧表示できます。またこれらのデータをexcelデータとして扱うことができますので、ソート機能などを使い、名称の見直しなどを効率的に行うことができます。類似した、ちょっと違いだけの用語に悩まされたりした経験はありませんか。SLPはこのようなことを考え、用語の標記の揺れを防ぐために文要素を参照ボードに表示し、メンバー名や状態名を選択する機能も持っています。

SLPは機能内容欄も持っています。この欄には機能内容を自然言語（通常文）で自由に書くことができます。この機能の固まりを単位機能と呼んでいます。他のファイルとリンクを張ることもできます。日頃お使いのwordやexcelやパワーポイントファイルをリンクできます。

機能内容欄には項番を付与し、文書全体の機能を階層的に表現できます。項番を変更できますから、階層構造を変更できます。

その他に、機能内容欄には、意図や理由を書くことができます。意図や理由は機能内容に表現された以上に機能内容やその範囲を明確に規定する効果があります。

SLPは単位機能と要求事項の関係も表現できます。要求項目の管理の仕方は会社により様々なようですが、仮に要求事項が箇条書きのようなものから出発したとすれば、その段階からSLPで管理できます。この段階の要求事項をSLPの単位機能として書きます。要求事項の項番名なりを「原要求項目識別子」欄に記入すれば、その後単位機能が機能分割され、下位の単位機能に分かれて行ったとしても、この時点で付与された識別子は下位にも継承されることになります。SLPは要求のこのようなトレーサビリティ管理機能を持っています。

またトレーサビリティは実装でも生きていないと意味がありません。SLPは「実装時の関数名」を単位機能に対して命名することにより、ソースコードのコメントを出力することができるようになっています。このコメントの中には「原要求項目識別子」等があります。実際にプログラムを実行させるコードはご自分たちで記述してください。ただし、もうお分かりかもしれませんが、自社で十分整ったソースライブラリーをお持ちの場合には、コメントコードにライブラリーを付加できます。これにより、ソースの自動生成が時に「重い」といわれるような弊害を取り除くことができます。

もっとも、SLPの開発対象は要求です。実装までは対象外です。しかし、要求の概念を詳細に展開して行けば、設計→実装へと連続的に工程をつなげて行くことができます。実際SLPでは「工程間連携」という機能（メニュー）を設け、テストや要求のトレースを行うチェック表などを作る機能も設けています。

しかし、あらためてSLPの守備範囲を申し上げれば、以下の図の「要求の仕様化」がSLPの目的です。しかし、SLPが「要求獲得」の分類整理や章立ての機能も備えていることがお分かりと思います。また「要求分析」では意図や理由を明らかにする必要もありますし、また非機能要件も書く必要があります。SLPは意図や理由を書く欄をSLPは持っており、SLP文書の検査機能においては、それらを書いているか否かをチェックしています。

非機能要件は別途SLPで書いておけば、他のプロジェクトにても使い回しができます。ついでながら、SLPには「単位機能結合」という機能があり、他のSLP文書との統合も可能です。複数人の作業をまとめることができます。また他のファイルの文要素（メンバー名、状態名）を読む込む機能もありますので、ここでも使い回しが可能です。

稼働環境やタイミングチャートなどは図で書くのが普通です。図は分かり易く効果的です。SLPは図も書けると欲張りません。図形表現の豊かな他のソフトをお使いください。SLPではこれらのファイルとリンクを張ってもらい、これらを統合的に管理できます。

ところで、図は分かり易いのですが、意味の整合性を自動的に検査できるでしょうか？　複雑で錯綜した表現を図で表現しようとすると無理があります。よしんば、図を細かく階層的に表現できたとしても、図に書かれた用語の意味はどうなるのか、と疑問がわいてきます。

意味とはメンバー名（主語や目的語）と状態名（述語）がペアになった文が指す内容で、真や偽の判断が可能なものとSLPでは考えます。かなり優れた図の表現でも図にはほとんどが単語しか書かれていません。これでは単語の指す概念がどうなるのかという意味まで表現することはできません。われわれは図を読み、単語の示す概念を思う浮かべ、その概念とその図にふさわしい述語や主語を付け加え、個々の図を意味化し、それら意味化されたものの全体を意味の関係として理解するほかありません。つまり、この限りでは、計算機処理はできないのです。

この議論は要求仕様をどの程度の濃度で書けばよいのかとか、要求仕様の問題は濃度のことばかりではなく、むしろ要求の意図などの問題ではないか、など、興味深い議論へと進みます。当社ではこの問題こそ要求仕様論の本質ではないかと考えています。
（そう考え、いろいろ研究をしているのですが、現在の力ではこれ以上言及できません。同じような興味をお持ち位の方、一緒に研究できるといいですね。可能なら、slp-support@jfp.co.jp までご連絡ください。）

さて、元に戻ります。

また論理記述欄のif-else-endifでは、要求仕様書の表現としては、どうも（難しい）という方のために、SLPはif-else-endifを通常文に直す機能を持っています。自然言語の処理はなかなか難しく完全なものからは遠いのですが、一度論理記述欄で書いたものを自然言語ライクなもの（通常文）に戻すのですから、背反条件(else)の漏れや表記の揺れを防ぐという利点があります。

以上、SLPの主なところを紹介しました。