山本 修一郎 (Shuichiro Yamamoto) - マイポータル - researchmap
1977年名古屋工業大学情報工学科卒業．1979年名古屋大学大学院工学研究科情報工学専攻修了。同年日本電信電話公社入社．2002年（株）NTTデータ 技術開発本部 副本部長．2007年同社初代フェロー，システム科学研究所 所長．2009年東京工業大学 統合研究院 医療情報プロジェクト 特任教授．同年名古屋大学 情報連携統括本部 情報戦略室 教授． 2016年 名古屋大学大学院情報科学研究科 教授。2020年名古屋大学名誉教授．同年電子情報通信学会フェロー．2021年名古屋国際工科専門職大学 工科学部 情報工学科 学科長． ソフトウェア工学，要求工学，ICカードプラットフォーム,ユビキタスコンピューティング，知識創造デザイン，ディペンダビリティ, エンタープライズアーキテクチャ(EA)，デジタル変革(DX)の研究に従事． 情報処理学会業績賞，電子情報通信学会業績賞，逓信協会前島賞など受賞．博
話題沸騰ポット 要求仕様書
■ 話題沸騰ポット GOMA-1015型 要求仕様書 電子ポットを題材にした組込みシステム分析・設計のための要求仕様書です。この要求仕様書をもとに電子ポットシステムを分析・設計してみることで組込みソフトウェア技術者の実践的教育を行うことができます。 話題沸騰ポット要求仕様は、SESSAMEが開催するセミナーで使用する資料です。本要求仕様書は、版によって想定している用途が異なります。 【第１版～第６版】 現実の開発現場でよく見受けられる曖昧さを含んだ仕様書として作成しました。曖昧部分に気づき、要求仕様書はどこまで詳細に分析し、明確に表現すべきかを考えていただくための教材です。 【第７版】 できる限り曖昧さをなくした仕様書の例として作成しました。なお、SESSAMEでは要求分析の最終段階ではこの記述のレベルまで仕様を明確にすることを期待しています。 本要求仕様書は雑誌『Software Peo
ET ロボコン 2010 モデル座談会（前編）～ゴールドモデラーが明かす、モデリングの秘訣～ ｜オブジェクトの広場
［レポート］ ET ロボコン 2010 モデル座談会（前編） ～ゴールドモデラーが明かす、モデリングの秘訣～ 目次 1. はじめに 1.1 ETロボコンとは 1.2 座談会の参加者プロフィール 2. モデルシート全体に関する工夫 2.1 分かりやすい見出しで書き手のスタンスを明示した 2.2 モデルの読みやすさを意識してトレーサビリティを向上させた 2.3 複数のダイアグラムを読みやすくする工夫を施した 2.4 2009年と2010年の競技規約の差分に着目して分析した 2.5 性能面を走破戦略と技術要素の2つの視点に分けて分析した 3. 要求分析 3.1 ドメイン分析では、エリアごとに並行して戦略を検討できることを意識した 3.2 ユースケース分析では、アクターへの価値提供を強く意識した 3.3 要求図は、要求分析と構造分析をつなぐ目的で描いた 3.4 要求図の見方 3.4.1 包含はME
非機能要求とは何か
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 本特集「非機能要求の鉄則3カ条」では、IPA（独立行政法人情報処理推進機構）の協力の下、情報システム開発における「非機能要求」の重要性を4回に渡って解説していく。 本稿をご覧になっている読者の方であれば、あらためて非機能要求という言葉を説明されなくても概要を把握している方が多いのではないかと思うが、第1回目となる今回は、今一度、なぜ非機能要求が重要なのか、そしてなぜ非機能要求を適切に設定することが難しいのかについて触れていきたい。 非機能要求グレード検討会の発足 2008年4月、NTTデータ、富士通、NEC、日立製作所、三菱電機インフォメーションシステムズ（MDIS）、OKIといった日本を代表するSIer6社が共同で「システム基盤の発注
上流工程-要件定義---目次：ITpro
富士通製メインフレームは残り650台、アルムナイ活用しモダナイゼーション要員を拡充 2024.06.12
「3匹の子豚」から学ぶ品質の優先順位付け
『雨風をしのぐ』という機能要件であれば、藁（わら）の家で十分。時間とお金をかけてレンガ造りの家を建てることは“過剰品質”といえる 大混乱したソフトウェア開発プロジェクトを生き抜く有望な方法の1つとして、「トリアージュ（野戦病院方式）」があります。 前回のコラム「サボりのモジュール化・サボる部分の独立化」では、ソフトウェア開発でトリアージュを適用する際に必要となる“開発する機能の優先順位付け”について解説しました。今回は、各機能の“品質の優先順位付け”について説明したいと思います。 品質の優先順位と『3匹の子豚』 最前線の野戦病院では、医者や看護師、薬、ベッドの数が限られており、この限られたリソースだけで、次々に運び込まれる負傷兵の治療をしなければなりません。必然的に負傷兵の優先順位、すなわち「すぐに手当てをしないと死亡する」「重傷」「軽傷」を考慮して、限られた医療リソースを割り当てることに
書き手だけが知っている - rabbit2goのブログ
セミナーや人の話を聞いて新しい知識を学んだ時には、その感想とかコメントを簡単にまとめて記録に残すようにしている（ブログに載せている情報もその一例だ）。また、会議や講演のように後から情報を読み直せないものは、話の内容を延々とメモした上で、それを振り返りつつ要点をまとめるようにしている。読書の感想文、出張報告書とか、開発プロジェクト報告書なども同じで、手間と時間はかかるけど必ず文章という形で保存している。 私見だけど、他人の話でもそれを自分でノートに取ることで記憶に刻み込まれ、より理解が深まるように思う。1時間にも及ぶ話を聞いて理解するのは簡単だけど、その内容を全部覚えるのは大変だ。その直後なら話の印象が残っているのでアレコレと感想を言えても、1週間経って同じ話を出来る人はそう多くないだろう。だからこそ、話の内容をメモにとって確実に記憶へ残す手続きが必要になるのだ。自分の手を動かしてノートを取
難しい仕様は要らない - rabbit2goのブログ
ソフトウェア仕様の打合せを行うと「あの仕様は難しくてね」とか「この仕様書は内容が難しいから...」と自慢気に話をする人がいるけれど、そもそも仕様はそんなに難しくて良いものなのだろうか？確かに要求内容に矛盾があるとか不足があるというには（残念ながら）当たり前のことだけど、その内容を噛み砕き、理路整然と整理してまとめたものが仕様のはずだ。難しい要求を、素直にそのまま難しい仕様に変換しているだけでは、そもそも要求を取りまとめる意味がない。仕様とは簡潔にして明快なものであるべきだし、仮にその中に何らかの難しさを抱えているとすれば、それは要求を全て理解した上で仕様をとりまとめる作業に失敗している気がしてならない。仕様の難しさを自慢するのではなく、その難しさをいかにシンプルな仕様にまとめ上げたのかを自慢して欲しいものだ。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
要求工学:Requirements Engineering(月刊ビジネスコミュニケーション)