JSゆるふわめも

がっこうでべんきょうしたことをめもがきしてます

仕様書メモ

機能仕様書考察

まとめ

  • 顧客 <-> 設計者 <-> 実装者

    • 顧客と実装者はまったく違うことを考えていると見なして考える
  • 要求 <-Validation-> 仕様<-Validataion-> 設計

    • 要求が仕様に反映されているか?仕様が設計に反映されてるか検証できなければ意味がない。
    • 仕様作成と評価は一体
  • 書き方
    • 自然言語
    • State,DataRelation,LogicFlowなどのビジュアルモデル
    • 形式的仕様★(一番厳密性が高い)

ソフトウェアについて下記のことを書く - 機能 - 能力 - 特性 - 制約条件

誰が何のために機能仕様書を読むのか - 顧客・マーケティング部門・販売担当者 - PM:スケジュール - 開発:設計の元となるドキュメント - テスト区:テスト計画書・

機能仕様書のタグについて、 階層的付番 ラベル桁数が大きくなる可能性がある ラベル番号がバージョンによって変化する可能性がある(他項目の挿入削除)  これにより、他のドキュメントで番号に依存しているとズレが生じる

階層的文字タグ 暗号化 .PMT  .エラー

メリット 永続性が保たれる

デメリット タグが長くなる。 意味を持つ名前を考える必要がある

不完全な項目は T.B.Dをつけておく

ユーザーインタフェース ユーザーインタフェースを書くことはメリットとデメリットがある メリット  要求の具体化  妥当性確認の容易さ デメリット  ユーザーインタフェースは要求ではない。ソリューションの表現  文書の肥大化  要求と機能とのギャップが出来てしまう可能性(機能と相容れないUI)

ユーザーインタフェースのモックアップ・スケッチは要求意図を伝える手段であり、確定情報ではない。 画面設計者(RICOHだとデザイン区)がよりよいUIにブラッシュアップする可能性がある。

新規開発の場合不用意に制約を設けないほうが良い。 既存システムに対する追加機能の場合、既に制約条件が存在するためUIについて記載しても良い。

読者を明確化する プロジェクトスコープ 対象となるソフトウェア・目的 ユーザーや会社の目標・ビジネス目標・戦略と結びつける インクリメンタルなシステムの場合は長期的な戦略のどの位置にあるのか説明する

プロダクトの背景

ユーザークラスと特性 プロダクトを使用するユーザークラスを特定を記述する ユーザークラスは再利用性がある情報のため、マスターのユーザークラスカタログが使用できるのであれば その情報をコピーせずに参照する。

稼働環境  システムが共存するシステム  稼働環境について

設計と実装上の制約条件  使用するプログラミング言語  ライブラリ  フレームワーク

前提条件と依存関係

3.SSD暗号化 3.SSD暗号化.1 説明  機能の簡単な説明  機能の有遷移付け 3.SSD暗号化.2 機能要求  予期されるエラー条件  無効な入力  アクション   データモデル データの獲得、完全性、保持、廃棄  データ獲得維持、バックアップ、ミラーリング、キャッシュ レポート(ログ)  制約条件としてログフォーマット

品質属性  具体的・定量的・検証可能である必要がある

良い機能仕様書を書くために 機能仕様書の目的  『だれが要求を呼んでも、必ず、他の読者と同じ解釈に到達する』  『それぞれの読者の解釈が、作成者が伝えようとした意図と一致する』

要求に優先順位を付ける チェックリストの作成 10%くらいできたら即レビュー レビューが早いほどバグの混入率が下がる レビュー  全て読む必要はない  背景情報を提供する  レビューのスコープを設定する  レビューに優先順位を付ける

何故機能仕様書を書くのか

ISO/IEC/IEEE 2011

ソフトウェア要求仕様書(SRS)の規格

IPA

厳密な仕様記述入門

形式仕様記述言語を用いた厳密な要件定義の方法を説明している - VDM(Vienna Development Method) - http://monoist.atmarkit.co.jp/mn/articles/0810/20/news106_2.html - 形式的であるがゆえに解釈が一意かつ漏れが生じにくい - テストにも応用可能

Aiming

プログラマが欲しい仕様書とは

  • 最低限必要な項目
    • シナリオ
    • 対象外
      • 明らかなオーバースペック
      • 現バージョンで対応しないこと
      • 対象外のプラットフォーム
    • 概要
    • 詳細
      • 想定される状況を全て書く
      • エラーケースを全て書く
      • エラーケースの対処方法を全て書く
    • 未解決の問題
      • 何が未解決か残す
    • 用語解説
      • 一般的な単語でもドキュメント内での意味を書く
  • Note!:P38~ 仕様書のアンチパターン

Google

Chromium Project Design Documents

WebKit WebSocket design doc

JAXAのケース

地上ソフトウェア開発標準

要求仕様作成

抽出された要求に基づき、実現可能性および整合性を確認し、対象システムに対する要求仕様、外部インタフェース仕様を定義、文書化すること。また、要求仕様について、その外部システムの接続先組織と相互に内容の解釈を含めて合意を得ること。 なお、要求仕様の根拠を明確化し、対象システムへの要求とのトレーサビリティを評価すること。

システム設計標準

スコープ

本設計標準で記述する「システム設計」は、ミッション要求段階の概念検討からシステム要求書/仕様書作成段階までの設計を主な範囲とする。但し、基本設計以降のフェーズ(段階)で活かす技術要素、運用設計にも触れている。

制約条件・前提条件を管理する

  • プロジェクト
    • 予算、スケジュール、搭載ハード、他プロジェクトの状況、信頼性要求など
  • 開発環境
  • 運用環境
  • 規制
    • 国内法、電波周波数管理規定、国内外の輸出管理規定、工業規格、社内規格・規定 など
  • 考慮すべきミッション要求・ミッション機器がシステムに与える主な制約条件
    • 所要電力
    • 寿命要求
    • ディスプレイサイズ

      信頼性要求

      信頼性要求は、主に下記の項目からなる。

  • H/W寿命と残存性
  • 運用の連続性・継続性

    6. システム設計(狭義)

    ミッションが提案された時点では、目的と手段が混合している場合が多い。ミッションの本来の目的を明確にしていくことが重要であり、ステークホルダーの識別と分析が目的の明確化にあたっての有効な方法である。
    また、第三者が判断できるようなミッション目標の達成度合の基準(サクセスクライテリア)についても、ミッション要求分析の対象とする。

7.3 システム要求への反映

前項までで上げた作業をシステム要求書に反映する。 反映された「システム要求」や、それに付随する「ハードウェアイメージ」を用いて、ミッション要求を満足していることを確認する。「ミッション要求」の実現が技術的に困難と判断されれば、ミッション要求変更を提案し、要求元(ステークホルダー)と調整する。 ここまでの作業を何度か繰り返した後、ミッション要求からシステム要求が整合性が取れれば、次の設計フェーズに進む。 - 問題があればステークホルダーと整合をきちんと取る

8. 検証・妥当性確認

宇宙機のサブシステムやコンポーネントは、打ち上げ前に、検証、妥当性確認として要求される機能・性能が満たされることを確認する必要がある。実績のあるサブシステム・コンポーネントは検証、妥当性確認方法が明確であるが、新規に開発するものは、どのような方法で確認するかを明確にしておかないと、システム開発・製造に大きな影響を与える可能性がある。 そのため、検証、妥当性確認は、宇宙機のシステム設計と独立に作成されるものではなく、早い段階から、システム設計の一環として、要求されるミッションや仕様の設定と検証方法はセットで行われるべきものである。 検証、妥当性確認は、4 章から 7 章で述べるシステム設計の各作業結果として作成される製品・成果物が要求事項と合致しているかを確認する行為であり、単独の確認行為ではなく、一連の戦略性のあるものとしてシステム開発の個々のステップにおいて実施するものである。 - 機能仕様書とその評価を行なうテストは表裏一体!

参考リンク

システム要求・仕様書作成ガイドライン