# 7. 要件定義

さて、バグの修正を中心に開発の流れを追ってきましたが、お客様からシステム化の要望を受けて開発を行う場合、実現したい機能を元に**要件定義**を行います。

これからグループワークとして、monetaの新機能を考えて、システム化の検討を行っていきましょう。今現在、お客様からは次のような要望が出ています。

- 振込手数料について、銀行別の別段預金口座に収容して、残高、明細を確認できるようにしたい。
- 残高が一定以上の先に対して、残高照会画面の下部に動きのある演出を追加したい。
- 銀行別に残高を集計して一覧表で確認したい
- 取引明細に月別グラフを追加したい
- 手数料をもっと細かく設定したい。銀行が異なる場合、支店が異なる場合で別の手数料にしたい

また、開発部門からの提案として、これ以外のテーマを選定しても構いません。グループで話し合って幾つかテーマを選定したら、バグ報告に登録します。

## リファクタリング

我々が開発したシステムは５年〜１０年と長いあいだ利用されます。その間プログラムの修正が発生するたびに、ソースコードを見て修正する場所を探したり、影響の有無を確認する作業が発生します。

プログラムの読みやすさを保つための変更は、リファクタリングと呼ばれますが、システムを安定して運用するための大事な取り組みになります。

例えば、`controllers/question_controller.rb`は使われていないように見えます。未使用のコードは混乱の元ですから、削除してしまったほうが良いはずですが、思わぬところで影響が出るかもしれません。

リファクタリングによる修正もバグ報告に登録します。

## 自動テスト

リファクタリングによる無影響を確認する場合に自動テストがあると安心です。

`controllers/question_controller.rb`を削除して、`rails test`を実行してみましょう。


全て緑ですから、全項目大丈夫です。削除した状態でステージングしましょう。

もし、テストでエラーが発生していたら、`git checkout .`で戻すことができます。

## フォームテスト

沢山テストがあるようですが、フォームのテストを見てみましょう。それぞれのエラーが発生するデータをセットして、エラー出力をテストしています。


## 要件定義レビュー

グループワークにより登録した内容について、他のグループに説明しましょう。説明を聞いた他のグループは、不明瞭な部分については質問して明確にしましょう。

指摘事項を反映して修正したら、設計者を設定します。

# 10. 振り返り

本日の成果を報告しましょう。不備・障害一覧には、担当者名で絞り込みを行う機能があります。その機能を使って、自分が担当した「報告」「設計」「開発」「検証」について振り返りを行うと良いでしょう。

慌ただしくも駆け足の対応でしたが、お疲れ様でした。