最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多
非機能要件は，ユーザーの要求からは出てきにくい。エスエムジーの小森裕介氏（オブジェクトフレームワークディヴィジョン テクニカルコンサルタント）は「経験上，非機能要件の中でも，許容できるダウンタイムや操作性などはユーザーから比較的出てきやすい。しかし，信頼性や性能は意識的にヒアリングしないとあまり出てこない。拡張性に関してはほとんど出てこない」と指摘する。そのため情報システム部門側で主導的に洗い出す。ここからは事例を基にそのプロセスを見ていこう。 ◆どう洗い出すか？ ひな型を使い漏れ防止 要件をテンプレート化しておく 非機能要件は機能要件と異なり，項目レベルで業種や業務による違いが少ない。「性能」「保守性」「拡張性」「セキュリティ」など，どのシステムでも同じような項目が並ぶ。そこでエスエムジーは要件定義のテンプレートを用意し，非機能要件として洗い出すべき項目を列挙した。SEはその項目を埋めれ
情報システム部の存在意義は、ITサービスを通したユーザ利便性の向上にあります。ITサービスとは単一、もしくは複数のシステムによって提供されるものですから、新しいシステムを企画立案して運用に漕ぎつけるまでの流れは、情報システム部の主たる業務と言えるでしょう。 新しいシステムを構築するためには、企画段階で得た構想を要件レベルに具体化し、システム設計者に引き渡します。企画をした人間が設計・構築・テスト・リリースまで担当できるにこしたことはないのですが、上流工程を担当する人間はスキルセット上、高コスト（月単価150万円以上）であることがほとんどですし、そもそも社内でシステム実装スキルを有する人間を必要数確保できないという根本的な課題もあって、要件定義フェーズ以前と設計フェーズ以降では担当者が異なることが多いのが実情です。 そこで要件定義フェーズで整理したことを正確に設計フェーズにつなげるために用い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く