結局の所，コンポーネントの再利用やプログラムの自動化技術が予想通り進んだ後で，何が残るだろう．ソフトウェア工学は，年老いていく．そのとき，ソフトウェア工学に残っているのは，要求工学だけではないだろうか 1
たまたま，ACMのSoftware Engineering notes 2を見ていたら，トップ10ダウンロード論文の紹介で，Lamsweerdeさんの論文が2位に入っていたので，ちょうど2章が終わったところでもあり，この論文を紹介したい．ちなみに，5位までは次のようになっている．
- Requirements Engineering: a Roadmap – 2000, Bashar Nuseibeh, Steve Easterbrook. Downloaded 187 (198) times
- Requirements Engineering in the year 00: a Research Perspective – 2000, Axel van Lamsweerde. Downloaded 144 (New) times
- Architecture-based Analysis of performance, reliability and security of software systems – 2005, Vibhu Saujanya Sharma, Kishor S. Trivedi. Downloaded 118 (New) times
- View of 20th and 21st Century Software Engineering – 2006, Barry Boehm. Downloaded 104 (117) times
- Theme: An Approach for Aspect-Oriented Analysis and Design – 2004, Elisa Baniassad, Siobhan Clarke. Downloaded 103 (New) times
一位も要求工学に関係している．全体に将来予測のものが多いので，そういう時期のデータだったのかもしれない．ちなみに，現在の順位は次から見ることができる．
http://dl.acm.org/sig.cfm?id=SP950
タイトルの通り2000年を起点として，過去25年の要求工学のふりかえりと，今後25年の予測を試みている．ICSEでの発表内容で，研究者向けである．
幾つかのアプリケーション領域では，複雑でカスタマイズ可能なパッケージが選ばれている．要求から（カスタマイズ）用のパラメータを設定することに関して，調査が必要かもしれない．
インターネット利用者が増えると共に，ソフトウェアも個別化するかもしれない．そのとき，唯一の利害関係者としてのエンドユーザに対する小さな要求工学の研究が，必要になるかもしれない．
要求工学と形式仕様記述の研究の狭間は，埋める必要がある．前者は，深い抽象モデルを作る．後者は，深い分析を提供する．ツールも進化している．両者を繋ぐ道を見つけるべきであろう．
問題領域と要求モデルには，より多くの知識が含まれるべきである．要求工学プロセス中に含まれる様々な側面・懸念・アクティビティについての知識である．
エージェントのモデル化は，もう一つの関心領域である．伝統的に要求工学は，世界をソフトウェアとそれを取り巻く環境に二分してきた．しかし，実際は複雑で，その中には複数のソフトウェア・人間・物理的なコンポーネントがある．間違った信念・非協力・間違った前提といったものが問題の大きな原因となっている．エージェントのモデル化支援というのが，特に，エージェントへの責務の割当に関して，重要になる．
現在分かっている代替策と将来の起こりうる変化に対する見通しに関して，余り注意が払われていない．しかし，要求工学における中心的な課題であり，将来取り組むべき領域である．
新しい言語や，記法に関して更に研究を進めるべきである．そういった言語を用いて，複雑な人工物を作る時期に来ている．しかし，非形式性から部分的な形式性，そして完全なる形式性にいつ移るべきかを明らかにする必要がある．シナリオから要求モデルへシフトするタイミングと方法に関しても同様．衝突がある見方から一貫した文書への時期と方法についも同様である．
要求のリエンジニアリングもまた研究すべき領域である．既存のドキュメントが適切に記述されていない場合がある．そのとき，開発と保守が問題になる．抽象と再構築はこの場面において，有益である．
言語自身に関して云えば，システムの複数の側面を把握するための複数言語を，意味的に統合すべきである．同一言語の複数フォーマットについても同様である（テキスト，表形式・図形式）．
ツールに関して云えば，要求工学に特化したツールには多くのチャンスがある．求められるツールの例を挙げる．要求分析の結果，最終的に作られるのは，多くの場合自然言語で書かれた文書である．ここには，指示的文と願望的文が含まれる．しかし，インタビューなど仕様を定めるために利用した要求と，その分析に関するものは含まれない．望まれるツールは，要求の構造を保持したまま，仕様を生成できるものである．或いは，必要に応じて，インタビューのビデオなどにアクセスできること．もう一つのツールは，アプリケーション完成後に，利用状況を監視することによって，要求を進化させるようなツールである．
早くも，次の25年の中間地点を過ぎた．彼の予測は当たっているだろうか．
（nil）