みっきーさん「『お客様との議論』が受け入れられない現場がある理由は、『情報は伝えた。オマエら専門家なんだから答えを持ってこい』という(一緒にプロジェクトをやらない)お客様が少なからずいるから。 そういうお客様でもレビューはしてくださる。同じ内容なんだけどね。」 #語る夕べ
2018-07-18 20:20:27Q 要求のゴールをどう決めるのかが見当たらない A 書いてないです。 Q 要求エンジニア向けの書籍でおすすめのものは? A 要求向けでなくIT戦略(CIO)向けの本。システム投資をどうするか?など目的や価値判断の本。チェックリストなどがあるが、逆に言うとそれを作れば良い(ゴールとなる) #語る夕べ
2018-07-18 20:20:47みっきーさん「業務に関心が無い開発者がいます。そういう人はお客様が業務要求についてお話しされていても『それは良いです。どういうシステムが欲しいのですか』とやってしまう。RDRAでは、そういう人に対して業務要求の重要さを説く。」 #語る夕べ
2018-07-18 20:26:34みっきーさん「RDRAというと、モデル化に目が行きがちだけれど、そっちは別の所で学べば良くて、それよりも『要件定義の4つの構成要素』が大切。」 #語る夕べ
2018-07-18 20:28:16@krsna_sub 神崎さん、ビジネスモデルキャンバスからRDRAする方法は紹介してますね
2018-07-18 20:30:03みっきーさん「4つとは ・システムを使って生み出す価値 ・システムを取り巻く環境 ・システムとの接点 ・システムそのもの この4つをモデルを使って繋いでいく。」 #語る夕べ
2018-07-18 20:32:06みっきーさん「要求を獲得する時に教科書通りに『目的はなんですか?』と初っ端に聞くのは悪手です。 『何をどう実現するか?』といった手段を先にお客様に話し尽くしてもらって、その後、ゴール(目的)をまとめる。詳しい方法はリザルトチェーンを勉強してね。」 #語る夕べ
2018-07-18 20:42:32みっきーさん「神崎さんのアプローチは、『ヒアリングした言葉を“要件定義の4つの構造モデル”に当てはめる』方式。 要求工学では『モデルを元にしてヒアリングをしていく』方式。」 #語る夕べ
2018-07-18 20:52:00RDRAのみでは業務全体で抜けがないかは確認しきれないから、他の図表も使ってますよ。
2018-07-18 20:55:30みっきーさん「RDRAでは要求がシステムに網羅的に反映されていることを確認することを重視します。 何故なら(オブジェクト指向を勉強した実践経験が少ない)開発者にはTo-Beモデルの素晴らしさに引っ張られて、お客様の要求を蔑ろにしてしまう人がいるから。」 #語る夕べ
2018-07-18 20:57:37みっきーさん「ドキュメント間の関係性を図示してまとめることはとても大切です。書かなくてはならないドキュメント一覧はあってもそのフローが書かれていない事が多いから」 #語る夕べ
2018-07-18 21:01:56「 時間の経過とともにバラバラ(粒度が)になる。」とはなにか? • (そこで)T字形テクニック ○ 最初は浅く全部やれ 深くやるところを見つけて掘り下げてから横展開しろ #語る夕べ
2018-07-18 21:06:25みっきーさん「モデル間もドキュメントフローと同じように、モデル間のトレーサビリティが取れる関係線を描き全体像を明らかにすること。」 #語る夕べ
2018-07-18 21:09:19みっきーさん「理解ためにはビジネスルールとプロトコルモデルをつなぐものが必要。 イベント系のエンティティの状態遷移モデルを理解すること」 #語る夕べ
2018-07-18 21:15:05みっきーさん「プロトコルモデルはシステムレベルのモデルだけど、業務レベルのモデルの理解が必要なのに、業務レベルの話が書いていないので分からない人が多いかもしれないと思った。」 #語る夕べ
2018-07-18 21:19:55みっきーさん「業務シナリオテストを作る時に、業務の状態遷移とシステムの状態遷移を抑えて置くとビシバシバグが見つかります。」 #語る夕べ
2018-07-18 21:23:29みっきーさん「業務シナリオテストでは、バグを指摘するのではなく仕様通りであっても、『この業務シナリオを通らないなら使えねーんだよ』って問題を指摘する。」 #語る夕べ
2018-07-18 21:35:01