記事へのコメント41

    • 注目コメント
    • 新着コメント
    michael-unltd
    事業>業務>システム

    その他
    REV
    要求:「かっこよく」→「かっこよくした」 要求:「展示スペースは広く」→「広くした」  できたアートスペース→階段が二人がすれ違うのがやっとの狭さ  ※安藤忠雄の悪口ではありません

    その他
    lanius
    要望、要求、要件。

    その他
    nanoha3
    「現状のシステムそのままでお願いします!!!!!」

    その他
    emt0
    木を見て森を見ずになると失敗確定。客側窓口の情シスが業務フローとか出さず末端のシステム仕様のみ決めようとしてきたら早めに提示求める。キレて他の業者にされても結構。情シス思った以上に社内の確認取らなすぎ

    その他
    TakayukiN627
    リレーションシップ駆動要件分析(RDRA)

    その他
    yamaguchi7073xtt
    要件次第🙃

    その他
    derby
    機能の2階層を別の名前で呼ぼうとしてたけど両方とも機能と呼ぶのいいですね

    その他
    quick_past
    いいんだけどWikipediaをソースにするのはやめよう

    その他
    kazukan
    嫌いな四字熟語は「現行踏襲」。大概の場合、現行の要件がなにか、ユーザー側が理解できていない

    その他
    Samuraijap
    ユーザーが何を作りたいのかはっきりしてないからな。家の例え話のとおり「安くて」「楽で」「快適に」「使いやすい」とかふんわりしたことしか言わん。平屋にしたいのか2階建てにしたいのかすら決められてない。

    その他
    ch1248
    要点押さえた上でよくまとまっていて良い。「要求部分が曖昧で炎上」とか「運用設計考慮してなくて稼働後に業務が爆発」とかよくある。

    その他
    nabinno
    いきなりシステムの話から入ると失敗する。まずBSCなどの戦略を共有した上でその業務目標を達成するために、課題解決として業務をシステム化する手順を踏むべき。要求定義以前の問題が山積していることが多い。

    その他
    tettekete37564
    社内ですら要求要件のラフを求めただけでキレられてプロジェクトから追い出されるしなあ。なんか本人は頻繁に質問や矛盾や問題が起きて忙しく振る舞う事で俺はデキる男感を演出して悦に入ってる風。同人制作みたいに

    その他
    mz_bee
    mz_bee 機能以外でデータ、非機能、外部IF、例外処理を抑えてれば、そんなに大コケはしないと思う。あとは、「要件定義とは何か。我々は何を決めて、何を合意しないといけないか」を顧客に最初に説明するのが大事

    2023/04/30 リンク

    その他
    lorenz_sys
    ブクマ数からして要件定義が何であるか知りたいブクマカがそれなりに多いようだけど何でみんなこんなに要件定義が分からないまま仕事してるんだろう?ある程度以上のポジションに立っていれば経験するものなんじゃ?

    その他
    HDPE
    要するに当人も認識していないなんかいい感じにしてもらうやつ

    その他
    shikiarai
    shikiarai 要求定義をベンダに任せてくれる企業はほぼないけど素人が要求定義をするのでこの世のIT投資はみんなコケる。住みたい家はよく分からんけど私が住みやすい家にして!と言って後からトランペット吹きたいとか言い出し

    2023/04/30 リンク

    その他
    kenzy_n
    時として移り変わるもの

    その他
    hsattaka0820
    こういうたいそうな資料をいくら読んだところで机上の話でしかなく、具体的に書けない人が多いのが現状。こういうの読んで役に立った事ないです。

    その他
    circled
    circled 「でも、それってスケールするのかしら?」

    2023/04/30 リンク

    その他
    shibainu1969
    shibainu1969 開発側が経験豊富であるのに対し、要件を出す側は初めてであることが多い。開発側が直観で分かる困難を言語化するのが難しい。頑張って説明して「分かんないけど、この人なんか頑張ってる」で納得してもらう。

    2023/04/30 リンク

    その他
    tamaso
    発注者は受注者の事情も言葉も理解できないし、受注者は発注者の言葉も現場も理解できない。ただし、これは上司・部下の関係でもあることだし、行政・市民の関係でもあること。

    その他
    gyampy
    gyampy 要求と要件は分けて考える。というのは何かに書いてあった。要件は具体的な実装方法のことだと理解しているが、この場合は要求がそれにあたるのかな。要求と要件の違いがピンとこない。

    2023/04/30 リンク

    その他
    gairasu
    gairasu ごちゃごちゃ考えるとこんがらがるので、要件定義はスコープであって願望などのなりたい姿ではないってことだけ理解してれば良い

    2023/04/30 リンク

    その他
    mon_sat
    なるほど、理解が深まった。要求を要望と要件に意識して分割するのは大切だ

    その他
    hideki5793
    要件定義書ってわかりにくいですよね。自分はシステムが持つべき機能や性能、操作性、セキュリティ等の要件を明確に定義し、システム開発に必要な情報を開発者やクライアントに提供するためのものって理解です。

    その他
    prjpn
    要望の半分は妄想である。

    その他
    hatakazu93
    技術

    その他
    nghrk
    nghrk 要件定義より重要なのは要求定義なんだよなぁ。苦労するプロジェクトはほとんどの場合、ここができてない。

    2023/04/30 リンク

    その他

    注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

    アプリのスクリーンショット
    いまの話題をアプリでチェック!
    • バナー広告なし
    • ミュート機能あり
    • ダークモード搭載
    アプリをダウンロード

    関連記事

    要件定義とはそもそも何か

    BPStudy#188〜要件定義を学ぼう。ChatGPTを添えて( https://bpstudy.connpass.com/event/281289/ ) の登...

    ブックマークしたユーザー

    • toriwatashun2025/07/07 toriwatashun
    • klov2025/05/27 klov
    • Hakuja2025/03/09 Hakuja
    • tksmrkm2024/12/26 tksmrkm
    • frtk2024/12/15 frtk
    • shimojyu2024/12/09 shimojyu
    • oldperfume2024/12/09 oldperfume
    • afukuhara2024/09/28 afukuhara
    • michael-unltd2024/09/18 michael-unltd
    • kituneudon972024/09/17 kituneudon97
    • imyutaro2024/08/21 imyutaro
    • tanaka_shi2024/07/31 tanaka_shi
    • takashipene2024/07/17 takashipene
    • lilpacy2024/07/17 lilpacy
    • matsuoshi2024/07/01 matsuoshi
    • kgrdk2024/07/01 kgrdk
    • zakiy2024/06/30 zakiy
    • um-mtt2024/06/30 um-mtt
    すべてのユーザーの
    詳細を表示します

    同じサイトの新着

    同じサイトの新着をもっと読む

    いま人気の記事

    いま人気の記事をもっと読む

    いま人気の記事 - テクノロジー

    いま人気の記事 - テクノロジーをもっと読む

    新着記事 - テクノロジー

    新着記事 - テクノロジーをもっと読む

    同時期にブックマークされた記事

    いま人気の記事 - 企業メディア

    企業メディアをもっと読む