ソフトウェア仕様化技法(立命館2022春講義)

35338

教科書

https://cover.openbd.jp/9784320027825.jpg

キーワード

目次

1回目

「要求とはなにか？」

目標

良いソフトウェア要求仕様とはどうあるべきか？を判断できる

良いソフトウェア要求仕様を作成できる

関連する諸概念を説明できる

ソフトウェア生産技術

ソフトウェアを作成したり保守したりする技術

更に分化して

ソフトウェア開発技術

ソフトウェア保守技術

ソフトウェア管理技術

ソフトウェア仕様

ソフトウェア設計仕様

ソフトウェアプログラム仕様

requirement(s)

要求，要件，要求要件

実現しようとするソフトウェア製品の以下などを文章化したもの

機能

性能

設計制約

利用者の特性

真の要求を引き出す

失敗事例から見えてくること，以下が死んでいる

的確な要求獲得

早期の仕様確定

妥当な開発期間

プログラムの十分なテスト

2回目

1, ユーザや顧客にとって目的を達成したり問題を解決するための特性

2, 契約書や標準規約，仕様書の制約を満たすためにすステムが持つべき特性

計算機システムを特に，直接操作したりするような人々

発注者である

顧客とユーザが同じであるときも違うときもある

2タイプのソフトウェア

1, 開発者がユーザのニーズを予測し，それに満足するソフトウェア製品を開発し，大量に売る

2, ユーザ側がニーズを開発者側に伝え，開発者がニーズを分析，それを満足するソフトウェア製品を開発する，単品の場合が多い

工業製品とソフトウェアの違い

工業製品（例：自動車）

ユーザも開発者も大体それがなにかは理解している

変なニーズが出ない，要求獲得は容易かつ正確

ソフトウェア

ユーザも開発者もニーズを見誤ることがある

以下の点で異なっていると言える

1, システム境界

一般の工業製品はシステム化の対象や範囲は固定されている

ソフトウェアは可変（ハードウェア化，ソフトウェア化）

ハード側が決まっていることも，決まっていないことも

2, システム規模

ソフトウェアは構成要素の数が多い

3, ニーズ予測，分析

4, 機能変更，機能追加

ソフトウェアへの機能追加や変更を，顧客側が当然のように要求してしまう

また，実際出来てしまう

5, 多様なニーズと解

似たような業務でも異なるソフトウェアになる

6, ニーズ自体の誤り

ユーザや顧客自身が何が問題かを十分に把握していない

ユーザと顧客で矛盾したニーズが出ることもある

ユーザ側にとっては当たり前のことは伝えられない（漏れがある）

7, 対象の範囲，領域

従来考えられなかった対象をソフトウェアとして実現しなければならならくなってきた

8, 開発方法

開発の成否が，開発者や開発組織の能力に依存してしまう

非専門家でもソフトウェアが作れてしまう

要求は立場に依って異なる可能性がある

要求は誤っている可能性がある

要求は変わる可能性がある

ソフトウェア要求を正しくまとめるための技術や技法の集大成

3回目

以下の目的で作られる

顧客や利用者による使用の確認

開発者による使用の検査

設計に必要な情報の提供

開発スケジュールやコストの見積もり

ソフトウェア開発の契約書の一部

誰が書くか？

理想論としては開発者とユーザの双方が書くのが良い

実際は開発者がユーザから聞き取った情報を元に書くことが多い

数式など

文法や語彙をいくつか制限した自然言語

ユーザの要求を満足させるために製品が持つべき特性

ディスプレイの品質特性は例えば

表示領域

解像度

画素数

重さ

コネクタ規格

妥当性（正当性）

利用者や顧客が確認する

非曖昧性

要求仕様に書かれる要求は，一意に解釈されなければならない

完全性

仕様に書かれた要求は，すべての可能性や要件を漏れなく（また重複なく）記載しなければならない

無矛盾性

仕様に書かれている複数の要求が一貫している（矛盾していない）必要がある

重要度のランク付け

要求間で重要度をランク付けできなければならない

例えば

必須

あると望ましい

なくてもよい

検証可能性

要求を満たしているかを検証する方法がなければならない

定性的なものは検証できない！

定量的なものに変換する

変更可能性

仕様の構造を保持したまま，容易，完全，無矛盾で仕様を変更可能

要求仕様より前に書かれた，要求の起源を参照できるように

「この要求ってなんで書いたんだっけ？」

要求仕様から派生して書かれたすべての文章からその要求を参照できるように

運用や保守の段階でソースコードや設計を変えるとき，その変更がどの要求に影響を与えるかを洗い出すときに有用

実現可能性

それ本当にできる？

例えば，技術的制約，コスト，スケジュール，法律など

要求仕様の章立て

次のように書くべき

1, はじめに

2, 要求仕様の全体説明

全体像

主要な起用

利用者の一般的な特性

制約事項

要求に影響を与える仮定と依存事項

3, 詳細な仕様

次のことを記載すべき

外部インタフェース要求

ソフトウェアへの全入出力の詳細

まさに実行する機能についての要求

システム/ソフトウェアが実行する機能を表した要求

入力データのバリデーション

運用の順序

異常系

入出力の関連

性能要求

定量的に書くべき

論理データベース要求

設計制約

設計/実装上の制約

標準規約，ハードウェア，関連システム上の規約など…

最終的な品質要求

要求仕様の構成

コメント

4, 付録

5, 索引

4回目

1, 信頼性

2, 使用性

3, セキュリティ

4, 効率性

5, 保守性

6, 移植性

6回目

現状のニーズの問題点を洗い出す

一般に問題は否定形で表され，ニーズは肯定形で表される

一般の問題解決にも利用可能

ビューポイント

要求を捉える際の立場/見方

これが異なると互いに矛盾する要求になりうる

解が複数ある場合に有用

ファクターの重要度を客観的に数量化する

各々の要素を突き合わせる，その際に評価の重みといったものを考える

https://gyazo.com/e61da9a0128fa981d31d91a513428133

1, 評価軸同士の重みを設定する

2, 各々の評価軸について2者を比較する

あるグループ人々について，同じ質問をし続ける

ただし，質問の答えに根拠を述べてもらい，質問にフィードバックさせる

最終的に一つの回答に絞り込んでいく

ゴール

開発対象システムが達成すべき目標

これが曖昧だったり矛盾したりすることがある

ソフトゴール

代表的なゴール指向分析

Non-Functional Requirements framework

9回目

システム全体を１つの機能と見なすところから始める

• システムの外側にある利用者や他システムを明確にする

基本的にアクタ間のつながりに関してはシステムが全く関与しないので書かない

11回目

1, ソフトウェアの事前条件と事後条件を定め，事前から事後を証明するための公理や推論規則を仕様とする

事前条件：機能の入力

事後条件：機能の出力

と考えて良い

2, データ型に対する操作，操作間の制約を代数で記述する

対象システムを集合や写像でモデル化

12回目

ホーア式を用いて仕様/プログラムの正当性の証明が出来る

$ P_0 \{ x:= f\} P

$ a + b > y + 5 \{ x:= a + b\} x > y + 5

$ P \{S;T\}R = P\{S\}Q,Q\{T\}R

$ P \{\text{if $Q$ then $S$ else $T$}\} R = P\land Q \{S\}R, P \land \lnot Q \{ T \} R

繰り返し文の変換規則

$ P \{\text{while $B$ do $S$}\} \lnot B \land P = P \land B \{ S\} P

帰結規則

$ P \{ Q\} R , S \to P \implies S \{Q\}R

13回目

構成

集合の上の演算

演算同士の制約を表す等式

手順

これは再利用出来る

変更と評価の演算が必要

演算の制約から公理を導く

例

code:Coord

# 既にあるInteger（整数）, Boolean（ブール値）に成り立つ公理は再利用する

sort Coord imports Integer, Boolean

# 作成演算

Create :: Integer: Integer: Coord

# 評価演算

X :: Coord: Integer # definition

X(create(x,y)) = x # axiom

Y :: Coord: Integer

Y(create(x,y)) = y

Eq :: Coord: Coord: Boolean

Eq(create(x1,y1), create(x2,y2)) = x1 == x2 && y1 == y2

メモ

誤りに関する品質特性(4)

仕様書の詳細な構成

外部インターフェース要求

機能要求

性能要求

論理データベース要求

設計制約

ソフトウェア属性

仕様の構成，コメント

プロトタイピング

対象

ユーザインタフェースプロトタイプ

紙芝居みたいな感じで…

機能型プロトタイプ

計算機のや処理機能も含めて実装

タイミング

発見型プロトタイピング

要求定義段階で行い，利用者が使用の妥当性を確認

性能型プロトタイピング

設計段階で行う，目標性能が達成できるかを開発者がチェック

最終製品

使い捨てプロトタイピング

進化形プロトタイピング

プロトタイプをそのまま製品として改良する

利点

欠点

プロトタイプで無視した性能やセキュリティを実装に持ち込むのが難しすぎる