すべての始まり＝「要求」を抽出する
上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。 IT／ソフトウェア業界は厳しい時代を迎えており、われわれは自分なりに生き延びる戦略を再構築し実践する必要がある――そう前回、述べた。その出発点が、顧客の要求を認知・理解し、それらの要求に的確に応えることである。すなわち、「要求エンジニアリング」に取り組むことである。 現在はあいにく、不況に突入したばかり。「そんな余裕はない」という読者が多いかもしれない。しかし、不況に適した要求（例えば、品質が確保された低価格のITやソフトウェア、あるいはすぐに使えるシステムやソフトウェアに対するニーズ）があるだろう。要求の中身は時代や環境とともに変化しているのである。しかし、要求をどう
「すし屋の注文」とは訳が違う、要求仕様書の書き方
「すし屋の注文」とは訳が違う、要求仕様書の書き方：上を目指すエンジニアのための要求エンジニアリング入門（4）（1/3 ページ） 上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。 経済環境は依然として厳しい。換言すれば、供給量に見合った需要、つまり要求が限られている。「これは」という需要が欲しい。であれば、有効な需要につながる要求を生み出し、明確にしなければならない。 このような状況の中で、ソフトウェアビジネスに欠かせない要求仕様に取り組むことは極めて重要である。まさに、ビジネスに役立つ「真の要求」開発競争に突入しているといえよう。 要求仕様書は誰が書くべきか 第2回で、要求抽出のプロセスとして、顧客または社内からの不満
UML：オブジェクト指向設計では標準の表記方法に
設計内容表記のデファクト・スタンダードに どんな開発方法論でも、設計内容を記述する表記法が重要である。オブジェクト指向技術を利用した方法論の場合は、クラスの関連や動的な処理の流れを表現するために、図による表記が多く使われる。以前は、方法論ごとに異なるルールで図を描いていた。図のルールが標準化されないと、良いツールが登場しづらい。図を用いた記述はソフトによる支援が不可欠だけに、非常に困った状況だった。 これを打開するために、方法論を提示していた３人（最初はGrady Booch氏とJames Rumbaugh氏、後でIvar Jacobson氏が加わる）が中心となり、標準化作業を進めた。こうして出来上がったのが、UML（Unified Model Language：統一モデリング言語）だ。何種類もの図を組み合わせて、システムの設計内容を記述する。 標準的に使われるためには、開発方法論に依存し
システム開発で使う仕様書のフォーマットを探しています。…
システム開発で使う仕様書のフォーマットを探しています。汎用的なもので使いやすいものが良いです。ワードかエクセルのフォーマットでダウンロードできるサイトがあれば教えてください。
仕様書：設計内容を記述してレビューや製作に用いる
レビューやソフト作成に仕様書は必要 システム開発で設計した内容は、仕様書として記述する。設計の段階だけでなく、最初の調査や分析の結果である要求仕様など、いろいろな工程で仕様書を書く。テストに関してなら、テスト内容を記述した「テスト仕様書」や、テストシステムの仕組みや構成を説明する「テストシステム仕様書」などがある。 仕様書を作成するのは、開発を成功させたいためだ。分析や設計の内容を記述すれば、きちんとしたレビューが可能になる。設計内容を正確に記述しておけば、プログラムやデータなどを正しく作れる。また、後からシステムを変更しなければならないときも、システムの内容を把握したり、直すべき箇所を調べる作業が容易になる。全体としては、システムの有用性、信頼性、柔軟性などを高めるのに役立つ。 以上のような理由により、開発の各段階で仕様書を書くのは当然といえる。一部には、仕様書を書かずに開発を進める人も
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
