紹介文 :
Blogなどの不特定多数の人が利用するサービスにおいては、誰がどんな目的で利用するのか把握することは難しいですが、コミュニケーション（多い・少ない）と読み手（特定・不特定）の２軸により整理することでうまく整理しています。ターゲットユーザーを想定する際の試行錯誤の過程も提示してあるので、ペルソナ法をどのように適用すべきか、１つの事例として参考になります。

紹介文 :
仕様というソフトウェアの核となる成果物の品質向上については、様々なアプローチが議論されています。このため、それぞれの特徴や役割分担を明確に踏まえ、問題に応じて選択し、組み合わせ活用することが重要です。本論文は、形式仕様記述手法と要求記述手法に関し、この観点から位置づけの整理を試みています。

紹介文 :
今日、単に機能面の品質が良いというだけでは買ってもらえない。コスト（価格）や「プラスα」の何かが必要。そこでサービス品質を、この「プラスα」のひとつとして捉える。しかしなから、サービス品質は一様ではないため、お客様の要求を掴むためのプロセスの明確化とサービス要求の定量化が必要になる。 本報告書では、サービス品質をお客様の満足度で捉えている。このお客様満足度を掴むプロセスの一つとして「アンケート調査」があるが、これは集計までの時間がかかることと、そこから具体的なアクションを引き出しにくいという欠点がある。そ

紹介文 :
開発期間が短い派生開発において、追加機能の要求仕様書が短期間に精度の高いものが書けることは重要だ。そこで仕様モレが少ない表記法として「USDM」を導入しようとしたが、従来の書き方に慣れた人たちにとってギャップが障壁となった。そこで慣れない現場の人たちを誘導するために何が必要かを「現場の目線」から探り出し、初心者向けにUSDMガイドラインを作成した。このような障壁は新しい方法を導入しようとするときにつきものであるが、その解決方法として今回のような優しく誘導するという取り組み方は、ガイドラインを作成することで推進者自身がその手法を理解することになり、いろんなケースに応用できる取り組み方である。

紹介文 :
予め指摘難易度の異なる欠陥を埋め込んだ仕様書を被験者にレビューさせ、的確に指摘ができるかを見るという興味深い実験をしている。実験結果として、難易度が一番簡単な欠陥は有意に指摘率が高かった。指摘率と被験者の開発経験には有意な関係は見られなかった。実験結果は部分的な成果ではあったが、要求から仕様に落とす際のパターンをモデル化し、その難易度を設定した「要求分析スキルモデル」はスキル評価以外にも大いに活用できるであろう。

紹介文 :
要求仕様書の品質を上げるための施策を3つ提案している．一つはWモデルの考えで，要求仕様書とテスト設計書を同時作成し，テスト設計書から要求仕様書にフィードバックをかけるとうもの．もう一つは，仕様書にハイパーテキストを使って，仕様書間の矛盾を発見しやすくしたもの．最後は，記載漏れを防ぐためのチェックリストを提案している．

紹介文 :
機能追加時に追加機能と既存機能との組み合わせテストを実施するにあたり、重要な組み合わせを絞り込むために、類語辞典（シソーラス）を用いて、追加機能の説明文に含まれるキーワードの類似語や反対語を含む既存機能を関連機能として抽出する手法を提案しています。手軽に実施できる可能性がある点がよく、また着眼点として、テストケースの絞り込みにあたり役立てられる可能性があります。

紹介文 :
2001年時点での「創造的なシステム開発」の方法（＝情報システムにおける要求分析の方法）について述べている。論点は、情報システム発注者の「欲しいもの」だけでなく、発注者の先にいる利用者の「欲しいはずのもの」までを捕えるというところにある。この考え方は、2013年時点では当たり前になっているが、実現の度合いから言うと難しい問題として残っている。

紹介文 :
プロトタイプを用いることでお客様の真の要求を掴み、サービス品質を高めることで、CS(Customer Satisfaction)を超えるCD(Customer Delight)：顧客歓喜を実現するプロセスが提案されています。業績向上、従業員満足度向上につながるサイクルも提示され、経営者にとっても魅力的な研究内容になっています。

紹介文 :
サービス品質(含：顧客満足（CS)、および従業員満足（ES)）に関する研究論文。特にCSとCD（Customer Delight）について考察し、さらにはCDに関するプロセスについて言及している点がテーマとして特筆に値する。主たる顧客満足において「感動」の重要性を考察している。 特にマーケティングの父：フィリップ・コトラーの顧客満足度の４段階、およびカール・アルブレヒトのホッケースティック・ロイヤリティを引用しながらサービス品質に必要な「感動」を解説している点がユニークである。

紹介文 :
「一般的な言語 対 ドメイン特化言語」、「上流での実装詳細の捨象の程度」など、記述方式の特化性はソフトウェア開発における難しい問題です。本論文は、フレームワークを用いた開発における形式仕様記述の活用に関し、この問題について様々な観点からの試行と議論を試みています。

紹介文 :
現場の開発者がUX手法の本来の目的をしっかりと理解し、かつ手法の効果があがるように展開するためには、UX手法の有識者によるサジェストが有効であると提案している。UX手法の組織導入・展開を行う場合に有益な示唆を与えてくれる内容である。検証実験で使用したサンプルも付録に掲載されているので参考になる。

紹介文 :
派生開発では、依頼された変更に対して隠れた変更箇所を見極めにくいことが見積りを難しくしている。その中に変更依頼の内容が具体的すぎるケースがあることに気付いた。 そこでこの問題の解決方法として、「USDM」の「仕様」から「要求」を探る方法に着目したが、この研究のポイントは、届いた変更依頼が「仕様」レベルであるかどうかの「判断」の方法を考案したことであり、これによって、隠れた変更の存在に気付く方法を模索したものである。 この方法に習熟することで見積りのズレが大幅に解消されることが期待できる。 逆にいうと、一般の単純な箇条書きの要求仕様の表現では、この具体的すぎる変更依頼から隠れた変更箇所に気付くことは難しいのかもしれない。

紹介文 :
仕様というソフトウェアの核となる成果物の品質向上については，様々なアプローチが議論されています．このため，それぞれの特徴や役割分担を明確に踏まえ，問題に応じて選択し，組み合わせ活用することが重要です．本論文は，形式仕様記述手法と要求記述手法に関し，以前の位置づけ整理を踏まえ，具体的な手法確立に向けた試行を行っています．

紹介文 :
研究会の研究員へのアンケート実施を通して、研究活動に対するニーズと満足度を把握する取り組みになっています。「満足度」をどのように評価すればよいか、考え方と手順が参考になります。

紹介文 :
専門的なソフトウェアについて、利用者も気づいていない要求を抽出するために、該当ソフトウェアの初心者が熟練者に弟子入りして学ぶ様子を観察しています。 要求を実現する画面案と実機を組み合わせた簡易プロトタイプで評価することで、要求の妥当性検証を短期間・低コストで実施できるよう工夫されています。

紹介文 :
1)リスクを低減するプロジェクト計画についての一考察 要求分析工程のデザインレビューの評価結果から、成功/失敗を予測するモデル「プロジェクト失敗予測モデル」を提案しています。 2)『ソフトウェア開発プロセス点検』の実践と考察 点検の実施結果を定量的に可視化する指標「開発プロセス良好率」を提案しています。 3)4アイテム要求モデルによる要求分析 簡単に導入できる要求分析の手法として、4アイテム（現在の状態、望まれる状態、解決されるべき問題、要求）モデルによる分析方法を提案しています。

紹介文 :
1)要求の評価方法の研究 要求の具体的な検証方法として、「貢献度評価による、妥当性及び完全性の評価」を提案しています。 2)形式仕様記述言語による派生開発でのモデル検証 組み込みソフトウェアの派生開発において、スペックアウトした仕様を形式仕様記述言語を用いて整理した事例が紹介されています。 3)プロジェクト管理における統合モデルの提案 特性の異なるプロジェクトに対して統一的な概念で評価およびフィードバックを行うためのプロジェクト管理フレームワークを提案しています。

紹介文 :
仕様というソフトウェアの核となる成果物の品質向上について、「形式手法（形式仕様記述）」と「テスト」といった、視点や参加者が異なるコミュニティーにおいて、閉じた視点で別々に議論されてしまっていることが多くあります。本論文では、それらを一つの系統的な視点から比較、議論することを試みています。

紹介文 :
複数の組織がソフトウェアシステムを共有する状況で、届けられた変更依頼が「共通仕様」における変更かどうかを判断できずに変更モレを起こすケースが少なくない。このようなケースでは「人（熟練者）」に依存することが多いが、この研究では、共通仕様に関する変更情報を１箇所に集約して「共有」したことと、共通仕様の判断が困難なときは無理に判断せずに一時「保留」する仕組みを取り入れ、そこに熟練者が判断する機会を集中させたことで、熟練者の負荷を下げているという方法を取った。もう一つの特徴は、共通仕様から「USDM」への展開を自動化したことである。これによって、関係部門に対して同じフォームで展開できるというメリットがある。「熟練者」が関わる部分と「自動化」する部分をうまく使い分けている。