仕様書メモ
機能仕様書考察
まとめ
顧客 <-> 設計者 <-> 実装者
- 顧客と実装者はまったく違うことを考えていると見なして考える
要求 <-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～ 仕様書のアンチパターン
Chromium Project Design Documents
WebKit WebSocket design doc
JAXAのケース
地上ソフトウェア開発標準
要求仕様作成
抽出された要求に基づき、実現可能性および整合性を確認し、対象システムに対する要求仕様、外部インタフェース仕様を定義、文書化すること。また、要求仕様について、その外部システムの接続先組織と相互に内容の解釈を含めて合意を得ること。 なお、要求仕様の根拠を明確化し、対象システムへの要求とのトレーサビリティを評価すること。
システム設計標準
スコープ
本設計標準で記述する「システム設計」は、ミッション要求段階の概念検討からシステム要求書/仕様書作成段階までの設計を主な範囲とする。但し、基本設計以降のフェーズ（段階）で活かす技術要素、運用設計にも触れている。
制約条件・前提条件を管理する
- プロジェクト
- 予算、スケジュール、搭載ハード、他プロジェクトの状況、信頼性要求など
- 開発環境
- 運用環境
- 規制
- 国内法、電波周波数管理規定、国内外の輸出管理規定、工業規格、社内規格・規定 など
- 考慮すべきミッション要求・ミッション機器がシステムに与える主な制約条件
- 所要電力
- 寿命要求
- ディスプレイサイズ
信頼性要求
信頼性要求は、主に下記の項目からなる。
- H/W寿命と残存性
- 運用の連続性・継続性
6. システム設計（狭義）
ミッションが提案された時点では、目的と手段が混合している場合が多い。ミッションの本来の目的を明確にしていくことが重要であり、ステークホルダーの識別と分析が目的の明確化にあたっての有効な方法である。
また、第三者が判断できるようなミッション目標の達成度合の基準（サクセスクライテリア）についても、ミッション要求分析の対象とする。
7.3 システム要求への反映
前項までで上げた作業をシステム要求書に反映する。 反映された「システム要求」や、それに付随する「ハードウェアイメージ」を用いて、ミッション要求を満足していることを確認する。「ミッション要求」の実現が技術的に困難と判断されれば、ミッション要求変更を提案し、要求元（ステークホルダー）と調整する。 ここまでの作業を何度か繰り返した後、ミッション要求からシステム要求が整合性が取れれば、次の設計フェーズに進む。 - 問題があればステークホルダーと整合をきちんと取る
8. 検証・妥当性確認
宇宙機のサブシステムやコンポーネントは、打ち上げ前に、検証、妥当性確認として要求される機能・性能が満たされることを確認する必要がある。実績のあるサブシステム・コンポーネントは検証、妥当性確認方法が明確であるが、新規に開発するものは、どのような方法で確認するかを明確にしておかないと、システム開発・製造に大きな影響を与える可能性がある。 そのため、検証、妥当性確認は、宇宙機のシステム設計と独立に作成されるものではなく、早い段階から、システム設計の一環として、要求されるミッションや仕様の設定と検証方法はセットで行われるべきものである。 検証、妥当性確認は、4 章から 7 章で述べるシステム設計の各作業結果として作成される製品・成果物が要求事項と合致しているかを確認する行為であり、単独の確認行為ではなく、一連の戦略性のあるものとしてシステム開発の個々のステップにおいて実施するものである。 - 機能仕様書とその評価を行なうテストは表裏一体！
参考リンク
レビュー時の心得
昔書いたメモが出てきたので忘れないようにここに記録しておく
レビュー時の心得
- 全体 -> 詳細の順で説明する
- レビューしてもらうポイントを絞る(絞らなくて全体を見てもらうことも当然ある) なぜそのような実装・設計にしたのか意図を明確にする
- レビュー後指摘事項を反映させる / 反映した指摘修正事項を指摘者に確認してもらう
- 指摘前と指摘後が比較できる状態にする
設計レビュー
<全体説明>
モジュール構成図を用いて登場モジュールとそれらの間でやり取りされるメッセージを説明する
<詳細>
クラス図などを用いてモジュールの内部構造を明らかにする
クラス図/コンポーネント図のレビュー
- 各クラス・モジュールの責務を明確にする
- メインユースケースがクラス図から辿ることができるか
3.1 必要なクラスは存在しているか
3.2 必要なメソッドが存在しているか
3.3 必要なパラメータが存在しているか
- 依存しているインスタンスの生成タイミング・保持の仕方を考える(new or getInstance or DI)
- Thread数を意識する
5.1. Threadの数は
5.2. どのクラス・モジュールがどのThreadで動作しているのか
潰瘍性大腸炎と食事と記録
つい先日潰瘍性大腸炎の確定診断が下りました。 直腸型の再燃寛解型です。まだなりたてなのでよくわかってないですがまぁ一番楽なタイプだと思っています。
発症自体は昨年の4月なのですが、その時は確定診断がもらえずとりあえず経過をみるということで特に治療も行ってきませんでした。 しかし、去年の暮れぐらいから軽く体調を崩し（なんか怠い・食欲が出ない）今年の1月になってから血便がみられ確定診断という流れです。 今は特になんともなく、ただ軟便気味なぐらいで普通に生活して仕事をしています。 4月時点である程度覚悟はできていたので特にショックはなかったですが、やっぱり少し落ち込みました。
でも、一時的には寛解するということは風邪と同様で何かきっかけがあって再発するということなんだと思っています。 そして、そのきっかけの大きな要因として
- 食事
- ストレス
- 睡眠
が挙げられているのだろうと ならばそれらを毎日記録して自分なりの発生要因を探ろうと思います。 また、毎日の食事を記録することで新たな潰瘍性大腸炎ビギナーの安心のタネになればいいかなぁと思っています。
ちょっと見辛い形式になっていますがご容赦下さい。
ブラウザごとの自己証明書を用いる場合に警告を抑制する方法
CNが実際のブラウザと異なる自己証明書を用いる場合に警告を抑制したかったので調査した。
前提として、自己証明書を使用しているので、何も対処を行なわなければ警告は必ず出る。
警告の抑制方法
IE
証明書をルート証明書期間にインストールする インターネットオプションから証明書のアドレス不一致について警告するのチェックを外す
FireFox
警告画面に表示されるエラー内容ボタンを押下し出現する、例外を追加を押下し、表示されるダイアログ内の次回以降にもこの例外を有効にするにチェックを入れて、セキュリティ例外を承認ボタンを押下する。
Chrome
警告ページに表示されるx.x.x.xにアクセスする(安全ではありません)を押下する。
Safari
警告ページに表示される証明書を表示するを押下して表示される証明書を常に信頼するをチェックして信頼する
Andorid
警告を無視してページにアクセスすると次回以降警告が表示されない
iOS
警告を無視してページにアクセスすると次回以降警告が表示されない
参考情報
ポインタレシーバーと値レシーバー
最近Goは全く触っていないです。 ただ、寝れなくなったのでGoを学習していた時によく分かっていなかったことを少し調べてみました。
それはコイツらです。
type Person struct { Name string } //値レシーバー func (p Person) hello() { fmt.Printf("Hi, my name is %s", p.Name) } //ポインタレシーバー func (p *Person) hello() { fmt.Printf("Hi, my name is %s", p.Name) }
これらをどう使い分けるのか？よく分かっていませんでした。 ぶっちゃけよく分かっていなくても練習問題は解けたので気にもしてませんでした。
正直今も正しく理解できているか謎ですが、下記のブログを読んで理解したことを意識低くメモします。
値レシーバーはメソッド定義された型の値をコピーして呼び出されます。 なので、下記のようなNewNameを定義しても呼び出し元の値は変化しません。
type Person struct { Name string } func (p Person) NewName(newName string) { p.Name = newName } func main(args string...) { p := Person{ Name : taro } p.NewName fmt.Printf("My name is %s", p.Name) //My name is taro }
逆にポインタレシーバーの場合は変化します。 つまり、呼び出し元のフィールド値を書き換えたいような場合はポインタレシーバーを使用して、 呼び出し元を変化させたくない（immutable）場合は値レシーバーを使用します。
また、値レシーバーは呼び出し元を丸っとコピーするので大きな構造体に対する呼び出しは高コストになるため避けたほうが良いです。
開発環境のバージョンって大事だね
Unityをいじってて最近ブチ当たったのがバージョンの問題 dllを追加しようとしたら.NET4.xだからダメで〜す的なメッセージが表示された訳です
全く意識してなかったのですが、UnityのバージョンによってサポートしているC#, .NETのバージョンは異なる訳で...
決まり切った環境と言語だとこの辺は気にすることや対処法は染み付いているのですが、新しい環境だと何がどういうバージョンでどうなっているのか全くわからないので事前にキチンと調べておくことが大事ですね。
Unityと.NET from AimingStudy
www.slideshare.net
