3.2K Views
June 14, 22
スライド概要
私は就業以来、組込みソフトウェア開発をしてきました。
要求仕様の理解に時間がかかったり、要求仕様を誤って解釈し検証してしまったために作業の出戻りが発生したり・・・と失敗をしてきました。
この資料では【要求仕様を正しく理解する】ために気をつけることを共有させてください。
Qiitaの記事はこちらです。
https://qiita.com/juraruming/items/0fecf339735c86fdc2a1
組込みソフトウェアエンジニア。 技術バックボーンはC言語・ベアメタル。 CQ EVカートのオーナーで、ハード・ソフトウェアの改造を通じて自身のスキルアップを日々考え中・・・。 LAPRASポートフォリオ: https://lapras.com/public/k-abe GitHub: http://github.com/grace2riku Qiita: https://qiita.com/juraruming Zenn: https://zenn.dev/k_abe よろしくね。
組み込みソフトウェア基礎 【連続講座 #1】要求仕様を正しく理解す るには? 2022/5/171 パーソルテクノロジースタッフ株式会社 阿部耕二 [email protected]
目次 • 自己紹介 • 参加者一言コメント • 講座開催の背景・目的 • 本日のテーマ【要求仕様を正しく理解するには?】 • 参加者感想 • 次回予告 2
自己紹介 • 阿部 耕二(あべ こうじ) • 技術本部 機電技術部 首都圏2G • [email protected] • 医療機器開発 • 組込みソフトウェア開発。C言語、ベアメタルの開発業務経験がほとん ど。 3
参加者一言コメント ご自由に一言コメントいただけますとありがたいです。 例) お名前 例) 今回の講座に期待すること 例) お仕事内容(話せる範囲で) 例) ソフトウェア開発担当工程(要求仕様の定義?設計?実装?テスト?) 4
講座開催の背景・目的 • なにかテーマを決めて、ソフトウェア開発の上流工程から下流工程まで説明 する講座を開催し、スキルアップを図る。 ■要求仕様の理解 ★いまここ ■要求仕様の仕様化 ■設計 ■テスト ■実装 5
講座開催の背景・目的 テーマ: 【既存組込み製品のマイコンを移植す る】 ※今回はテーマに依存しない内容です。 6
講座開催の背景・目的 テーマ:【既存組込み製品のマイコンを移植する】 対象装置:CQ EVカート 背景: ・講師が持っており、対象装置のドメイン知識を理解している。 ・ソフトウェアの構造を理解している。 ・対象装置のマイコンが生産中止になった。 ⇛学習・スキルアップのため別マイコンに移植してみよう!!! 7
本日のテーマ 【要求仕様を正しく理解するには?】 • まずは用語の定義から。 ・【要求仕様】 ・【仕様】 この用語をどう認識していますか? 8
本日のテーマ 【要求仕様を正しく理解するには?】 この講座では次の定義をします。 ■【要求仕様】:装置・システムが実現したい目的 ● 〜したい、など要求を示す言葉で表現する。 ■【仕様】:要求仕様を実現するための具体的手段 9
本日のテーマ 【要求仕様を正しく理解するには?】 ■要求仕様を正しく理解しないことで起きる弊害 ●要求仕様を理解するために時間を使う:工数の増加 ●作業の出戻り:工数の増加 ●要求仕様定義側-要求仕様読み手の関係性悪化:品質の低下 良いものを作るという思いは両者で一致しているはずなのに・・・ 10
本日のテーマ 【要求仕様を正しく理解するには?】 ■こんな要求仕様の定義は嫌だ 要求仕様の理解で苦しんだ経験から解決案を共有させてください。 11
本日のテーマ 【要求仕様を正しく理解するには?】 ■こんな要求仕様の定義は嫌だ 1) 要求仕様の重複記載 2) ドメイン知識の属人化 3) 情報不足 4) 記載の粒度 5) 表記の揺れ 6) 目的ではなく手段が記載 7) 仕様書の体裁 12
本日のテーマ 【要求仕様を正しく理解するには?】 ■こんな要求仕様の定義は嫌だ 1) 要求仕様の重複記載 2) ドメイン知識の属人化 3) 情報不足 4) 記載の粒度 5) 表記の揺れ 6) 目的ではなく手段が記載 7) 仕様書の体裁 13
本日のテーマ 【要求仕様を正しく理解するには?】 ■こんな要求仕様の定義は嫌だ 1) 要求仕様の重複記載 ■現象 ●要求仕様の記載が複数の仕様書に重複して記載されている。 ・仕様書のメンテ忘れにより要求仕様に矛盾が生じる。 ・複数仕様書のメンテが大変。 ■解決策 要求仕様は重複しないように記載する。 ⇛DRY原則と同じですね。 仕様書の構成をどうするか?は開発チームのルール決めが必要かと思う。 14
本日のテーマ 【要求仕様を正しく理解するには?】 ■こんな要求仕様の定義は嫌だ 1) 要求仕様の重複記載 2) ドメイン知識の属人化 3) 情報不足 4) 記載の粒度 5) 表記の揺れ 6) 目的ではなく手段が記載 7) 仕様書の体裁 15
本日のテーマ 【要求仕様を正しく理解するには?】 ■こんな要求仕様の定義は嫌だ 2) ドメイン知識の属人化 ■現象 対象ソフトウェアのドメイン知識・要求仕様がチームに共有されておらず、特定の人の頭の中にしかな い。 ■解決策 ●属人化している理由(※)を明確にした後、特定の人のドメイン知識を共有する場を設ける。 ※特定の人が業務過多であれば業務の調整を行うなど 関係者がドメイン知識を共有できるナレッジ・wikiなどを整備する。 16
本日のテーマ 【要求仕様を正しく理解するには?】 ■こんな要求仕様の定義は嫌だ 1) 要求仕様の重複記載 2) ドメイン知識の属人化 3) 情報不足 4) 記載の粒度 5) 表記の揺れ 6) 目的ではなく手段が記載 7) 仕様書の体裁 17
本日のテーマ 【要求仕様を正しく理解するには?】 ■こんな要求仕様の定義は嫌だ 3) 情報不足 ■現象 要求の理由・背景がわからないため仕様化できない。 ■解決策 仕様化、設計が進められる粒度で要求仕様を整理・記載する。 18
本日のテーマ 【要求仕様を正しく理解するには?】 ■こんな要求仕様の定義は嫌だ 3) 情報不足 ■事例 ●要求仕様の記載例:xx通信のデータを1秒間送信してください(※)。 前提としてxx通信のデータの送信周期は400ms。 ●事例の解決策 1秒間超過で良いのか、超過してはいけないのか、1秒間の範囲を明確にする。 (800msで良いのか?それとも1.2sでも良いのか?それとも1sec±xx msecじゃないと駄目なのか ※要求仕様の段階で通信データの周期まで定義することは具体的すぎてふさわしくない気がするが事例 の説明ということで。要求の仕様化のフェーズで上記の送信時間の仕様を明確にするのが妥当かもしれ ない。 ) 19
本日のテーマ 【要求仕様を正しく理解するには?】 ■こんな要求仕様の定義は嫌だ 1) 要求仕様の重複記載 2) ドメイン知識の属人化 3) 情報不足 4) 記載の粒度 5) 表記の揺れ 6) 目的ではなく手段が記載 7) 仕様書の体裁 20
本日のテーマ 【要求仕様を正しく理解するには?】 ■こんな要求仕様の定義は嫌だ 4) 記載の粒度 ■現象 記述の粒度・抽象度が統一されていない。 ■解決策 記述の粒度・抽象度を要求仕様書を記載する前に決めておく。 21
本日のテーマ 【要求仕様を正しく理解するには?】 ■こんな要求仕様の定義は嫌だ 1) 要求仕様の重複記載 2) ドメイン知識の属人化 3) 情報不足 4) 記載の粒度 5) 表記の揺れ 6) 目的ではなく手段が記載 7) 仕様書の体裁 22
本日のテーマ 【要求仕様を正しく理解するには?】 ■こんな要求仕様の定義は嫌だ 5) 表記の揺れ ■現象 類似の要求仕様の記載が統一されていない。そのために要求仕様の解釈・確認 に時間がかかる。 ■解決策 要求仕様の解釈が一意になるよう記載する。 23
本日のテーマ 【要求仕様を正しく理解するには?】 ■こんな要求仕様の定義は嫌だ 5) 表記の揺れ ■事例 ●不等号 ・xx-1 要求仕様: 100以上でxxが発生。 ・xx-2 要求仕様: 200未満でxxが発生。 xx-1とxx-2の要求仕様で条件のしきい値が異なっている。 意図しているのか?それとも誤記なのか? 対策として仕様書の冒頭で要求仕様決定の理由・ポリシーを明記する、不等号で要求仕様を記載するなど。 24
本日のテーマ 【要求仕様を正しく理解するには?】 ■こんな要求仕様の定義は嫌だ 5) 表記の揺れ ■不等号の事例 以上、未満、超過で動きに問題ないことは予想していたが、検証する側 は仕様が揺れていたら検証できない。 25
本日のテーマ 【要求仕様を正しく理解するには?】 ■こんな要求仕様の定義は嫌だ 1) 要求仕様の重複記載 2) ドメイン知識の属人化 3) 情報不足 4) 記載の粒度 5) 表記の揺れ 6) 目的ではなく手段が記載 7) 仕様書の体裁 26
本日のテーマ 【要求仕様を正しく理解するには?】 ■こんな要求仕様の定義は嫌だ 6) 目的ではなく手段が記載 ■現象 要求仕様が【目的】ではなく【実現手段】が書かれている。 ■解決策 目的ベースの表現(〜したい)で要求仕様書を記載する。 27
本日のテーマ 【要求仕様を正しく理解するには?】 ■こんな要求仕様の定義は嫌だ 6) 目的ではなく手段が記載 ■事例 2値(たとえばスイッチのON・OFF)の情報を要求仕様書に表現する際に【xxxフラグ】と記 載している。 【xxxフラグ】は目的ではなく、プログラムの実装にフォーカスした表現。 要求仕様書の記載をそのまま実装でも引用しフラグにする、ということも起こるかもしれな い(設計・実装工程で検討した結果、フラグにするのが最適であればそれで良いと思う)。 フラグにするか・否か最適な実現手段は要求仕様の定義より後の工程で議論すること。 28
本日のテーマ 【要求仕様を正しく理解するには?】 ■こんな要求仕様の定義は嫌だ 1) 要求仕様の重複記載 2) ドメイン知識の属人化 3) 情報不足 4) 記載の粒度 5) 表記の揺れ 6) 目的ではなく手段が記載 7) 仕様書の体裁 29
本日のテーマ 【要求仕様を正しく理解するには?】 ■こんな要求仕様の定義は嫌だ 7) 仕様書の体裁 ■現象 要求仕様書の記載の話。 ・どこに何が書いてあるかすぐにわからない。 ■解決方法 すぐに要求仕様を見れるよう目次、見出し、リンクをつけるなどの工夫をする。 30
参加者感想 • 是非とも講座の感想を一言お願いします。 31
次回予告 次回は【6/16(木) 19:30〜20:30】で開催予定です。 【連続講座 #2】要求仕様を定義する 決めたテーマ【既存組込み製品のマイコンを移植する】の要求仕様を実際 に仕様化したいと思います。 参加の方、是非ともよろしくおねがいします。 32
終わり ご静聴ありがとう ございました。 33