・要件定義 成果物は「経営者が参画する要求品質の確保」に記述されている 表4．3「役割分担と成果物例」にならい分類・表示している。 方向性と計画についてはこちら
超上流から攻めるIT化の事例集：要件定義 | アーカイブ | IPA 独立行政法人 情報処理推進機構
・要件定義 成果物は「経営者が参画する要求品質の確保」に記述されている 表4．3「役割分担と成果物例」にならい分類・表示している。 方向性と計画についてはこちら
システム設計の流れ - Qiita
昔のメモを整理してると出てきました。今となっては心底どうでもいい。 上流工程に関するあれこれ 大まかな流れ 基本的な流れとしては要件定義→外部設計→内部設計→開発の流れが採用される。 ここで外部設計は基本設計、内部設計は詳細設計とも呼ばれる。 一般にウォーターフォールモデルでの考え方では外部設計までが上流工程と考えられるようだ。 要件定義 要求開発(超上流工程) [ 業務フロー ] 業務とその流れを表現するもの。素人にもわかるように → アクティビティ図 業務機能関連図 [ 業務モデル ] 業務を静的に表現する。 → ERD クラス図 要件定義 システムの範囲を決定する。何を作って何を作らないかを明確にすること。 1.機能要件 ユースケース一覧 機能一覧 2.非機能要件(FURPS+) >機能 機能要求 >使用性 UIの指針、ユーザ教育、マニュアル >信頼性 管理、監視、保守、復旧 >性能
ペロリ流 開発要件のまとめ方 - peroli Developer's Blog
2016 - 07 - 22 ペロリ流 開発要件のまとめ方 開発プロセス list Tweet こんにちは。開発部のマネージャーをやっている mizushimac です。 今回は開発するモノの要件のまとめ方についてペロリ開発部が実践している内容を少しご紹介したいと思います。みなさんの会社やプロジェクトではどうやって開発するモノの要件をまとめていますか？ パワポ ですか？ spreadsheet ですか？ 流れ行く slack や github issue で議論しながらコメントに埋もれていき誰かが箇条書きでまとめますか？ きっとカオスなことが多いかなと思いますのでこのエントリーが少しでもご参考になればと思います。 ちなみに、ペロリはカオスを楽しめる人を求めていますw 開発要件のまとめ方って色々あって難しい 私が学生の時に所属していた ベンチャー企業 では、数十MBもある パワポ に画面イメ
PART5 セキュリティ要件の決め方
対策は流行に捉われやすいが、本来は順序立てて検討していくことが重要だ。要件を決める方法として、情報セキュリティのフレームワークを活用した手順を解説する。Webシステム向けの対策や、ロードマップの策定方法も見ていこう。 セキュリティ対策は本来、守りたいものや対策の目的によって多様な選択肢がある。だが、経営層や顧客への説明がしやすいことから、流行りのソリューションに陥りがちだ。インターネット イニシアティブの根岸征史氏（サービスオペレーション本部 セキュリティ情報統括室 シニアエンジニア）は「特定ポイントだけのソリューションに依存するのはよくない。その他の脅威にも対応できるように、バランスよく対策する必要がある」と指摘する。 流行に惑わされないためには、現状分析や目的の明確化など、順序立てて考える。手順としては、IPAが提示する作業項目が参考になる（図1）。実施フェーズは要件定義からテストまで
[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG
「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に立つ。 原理原則 17箇条 ユーザとベンダの想いは相反する 取り決めは合意と承認によって成り立つ プロジェクトの成否を左右する要件確定の先送りは厳禁である ステークホルダ間の合意を得ないまま、次工程に入らない 多段階の見積りは双方のリスクを低減する システム化実現の費用はソフトウェア開発だけではない ライフサイクルコストを重視する システム化方針・狙いの周知徹底が成功の鍵となる 要件定義は発注者の責任である 要件定義書はバイブルであり、事あらばここへ立ち返るもの 優れた要件定義書とはシステム開発を精緻にあらわしたもの 表現されない要件はシステムとして実現されない 数値化されない要
![[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG](https://cdn-ak-scissors.b.st-hatena.com/image/square/bfb41ba2bfefb166491d5d3e83380136f2017ab2/height=288;version=1;width=512/http%3A%2F%2Foshiire.to%2Fwp-content%2Fuploads%2F2015%2F01%2F17principles-300x212.png)
状態遷移表を使用した要求分析モデル
実際に、要求仕様から状態遷移表を作成するプロセスを紹介する。モデリングを行いながら、要求仕様書で定義されていない曖昧な部分を検討し、明確化。上流工程の段階でモデルを洗練しておくことで、無駄のない最適なソースコードを作成できる。 はじめに 組み込みソフトウェアが抱える一番の課題は「設計品質の向上」です。本連載の主役「状態遷移表」であれば、“イベント”と“状態”の全ての組み合わせを捉えることができるため、「モレ」「ヌケ」のない品質の良い設計が可能です。そして、不具合発生による手戻りコストの削減や開発効率の向上にも役立ちます。 こうした理由から、組み込みソフトウェア開発の世界では、長年、状態遷移系モデルで設計が行われています。 さて、前回は“なぜ状態遷移表を使うと、品質の良い開発ができるのか”を紹介しました。今回は「状態遷移表を使用した要求分析モデル」をテーマに、具体的に要求仕様から状態遷移表を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
