実践的アプローチに基づく要求仕様の発注者ビュー検討会NTTデータ（国内事業会社） 企業情報 プロフィール 社長メッセージ 役員一覧 NTTデータのテクノロジー NTTデータグループ（持株会社） 企業情報 プロフィール 社長メッセージ Our Way 役員一覧 サステナビリティ 沿革 グループ会社 協賛・文化活動 取引先企業の皆様へ NTT DATA, Inc.（海外事業会社） 企業情報
- JUDEで体感UML設計ツール
UMLは、手書きすることもありますが、ここではツールを使います。 UMLを描くのになぜツールを利用するのでしょうか？主なメリットを挙げてみます。 きれいな図がかける 自動的にサイズなど調整してくれる 他人とUMLを交換・共有しやすい Undo/Redoで試行錯誤しやすい 誤った図をかくと注意される 図だけでなく、ツリーや表上でデータを編集できる データを再利用、2次利用できる データ間の関連を管理できる 初心者にとってのツールを考えてみると、4, 5が特に意味があると思います。 例えば、間違ったらいつでも簡単にやり直せますし、パッケージからクラスに関連を描こうとすると、 ツールは「そのような関連はかけません」と教えてくれます。また、クラスを抽象クラスに設定すれば、 自動的にクラス名が斜体になります。その他にも、各要素の形と名前の対応関係をツール上で常に確認できます。 ツールにUMLを教わる
“要求”とは何か
「必要である、当然であるとして強く求めること」（広辞苑 第六版） 「ほしい、必要だ、または当然の権利だとして、その実現を相手に求めること」（新明解国語辞典 第四版） 「1 必要または当然なこととして相手に強く求めること。 2 必要とすること」（goo国語辞書/デジタル大辞泉） 「要求」という言葉を辞書で引くと、こんなふうに説明されている。しかし、この説明にしたがって、システム開発の“要求”定義を行うと、とんでもないことになる。運用テストに至ったところで「こんな機能は使えない」と大幅な手戻りが発生するか、運良くリリースにこぎ着けても使われないまま放置されたり、使われはしてもビジネスの成果につながらなかったりする可能性が高い。 そもそも要求とは、もやもやしたとらえがたいものであり、それを正確にシステムに反映する作業は、ベテランのSEでも容易ではない。その容易ではない作業に光が当たり始めたのは、
だれも教えてくれなかった外部設計の「極意」---目次
外部設計書で最も大切なことは，「システム開発を依頼してきたお客様」（発注者）に読んでもらい，理解してもらうことです。外部設計書を，開発メンバーではなく，発注者に理解してもらうためには，「いかに発注者にとって分かりやすい外部設計書を作成できるか」と「レビューを通じていかに合意形成を図るか」が重要になります。本連載では，発注者が理解しやすい外部設計書の書き方とレビューの方法に関する具体的なノウハウを解説していきます。 第1回 ユーザーと意思疎通が図れない外部設計書は危ない 第2回 ［システム振舞い編］一覧表に一工夫入れることで漏れや重複をなくす 第3回 ［システム振舞い編］全体を俯瞰でき，システム化範囲が一目で分かる業務フローを作成する 第4回 ［システム振舞い編］発注者が理解しやすいシナリオの記述方法 第5回 ［画面編］見れば“わかる”「画面レイアウト」の作り方 第6回 ［画面編］画面遷移を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
