0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Kotlinでの機能作成#1(要件編)

0
Posted at

Kotlinで画面(Android)とバックエンド開発

作成するもの

Androidアプリ画面から入力を行い、バックエンドでDB登録を行う申請機能の作成

要件

1. 文書情報

項目 内容
目的 Android アプリ、Java API、データベースを連携した申請管理アプリを学習・実装する
対象バージョン MVP(最小実用版)
想定利用者 学習用の単一利用者。実在する個人情報は扱わない
構成 Android アプリ → HTTPS/JSON → Java API → データベース

2. 背景・目的

利用者が Android アプリから申請情報を登録し、登録済みの申請を一覧・詳細で確認できるようにする。クライアント、API、DBを一貫して設計し、入力検証、エラー処理、データ永続化の基本を学ぶ。

3. スコープ

3.1 MVP に含める

  • 申請情報の新規登録
  • 申請一覧の表示
  • 申請詳細の表示
  • 入力値の検証と、利用者に分かるエラー表示
  • API と DB 間の保存・取得
  • 通信中、通信失敗、データなしの画面表示

3.2 MVP に含めない

  • ログイン、ユーザー管理、権限管理
  • 承認・差し戻しなどのワークフロー
  • 申請の編集・削除・取消
  • 添付ファイル
  • プッシュ通知、メール通知
  • 本番環境への公開、実在の個人情報の保存

4. 利用者と利用シナリオ

利用者

  • 申請者:申請を登録し、登録済み申請を閲覧する。

MVP は学習用のため、認証を行わず、登録済みデータはアプリ利用者全員が閲覧できる前提とする。実運用に転用する場合は、認証と申請者ごとのアクセス制御が必須となる。

主なシナリオ

  1. 利用者が申請一覧を開き、登録済み申請を新しい順に確認する。
  2. 利用者が申請作成画面で申請者名と申請内容を入力し、送信する。
  3. 入力に問題があれば、該当項目と修正方法を画面に表示する。
  4. 登録に成功したら、完了を表示し、登録された申請の詳細を確認できる。
  5. 通信やサーバーに問題があれば、入力内容を保持して再試行できる。

5. 機能要件

ID 要件
FR-01 アプリは申請一覧を取得して表示できること。
FR-02 一覧には申請者名、申請内容の冒頭、申請日時を表示すること。
FR-03 一覧は申請日時の降順(新しい順)で表示すること。
FR-04 利用者は一覧の項目を選択し、申請者名、申請内容、申請日時を詳細表示できること。
FR-05 利用者は申請者名と申請内容を入力して申請を登録できること。
FR-06 申請者名と申請内容は必須とし、空白だけの入力は受け付けないこと。
FR-07 入力不備は送信前にアプリで案内し、API 側でも同じ条件を検証すること。
FR-08 登録成功時、API は発行した申請 ID と保存済みの申請情報を返すこと。
FR-09 登録成功時、アプリは成功を案内し、登録内容を確認できること。
FR-10 一覧が空の場合、データがないことと登録方法を案内すること。
FR-11 通信中は処理中であることを表示し、送信ボタンの連続操作を防ぐこと。
FR-12 通信失敗時は内容を保持し、利用者が再試行できること。
FR-13 API は不正なリクエストに対して、項目と理由が分かるエラーを返すこと。

6. 画面要件

6.1 申請一覧画面

  • 申請を新しい順に表示する。
  • 各行に申請者名、申請内容の冒頭、申請日時を表示する。
  • 行をタップすると詳細画面を開く。
  • 「申請する」操作から申請作成画面を開ける。
  • 読み込み中、空状態、読み込み失敗を区別して表示する。

6.2 申請作成画面

  • 申請者名入力欄
  • 申請内容入力欄
  • 送信ボタン
  • 入力エラー、送信中、送信成功、送信失敗を表示する。
  • 送信失敗時に入力値を消さない。

6.3 申請詳細画面

  • 申請 ID、申請者名、申請内容、申請日時を表示する。
  • MVP では編集・削除操作を表示しない。

7. データ要件

7.1 申請(Application)

項目 型(論理型) 必須 制約・説明
id UUID または採番 ID ○ サーバー側で発行し、一意であること
applicant_name 文字列 ○ 前後空白を除去後、1〜100 文字
description 文字列 ○ 前後空白を除去後、1〜2,000 文字
created_at 日時 ○ サーバー側で設定し、UTC で保存すること
  • DB のテーブル名は applications とする。
  • id を主キーとする。
  • 一覧取得に備え、created_at にインデックスを設定する。
  • 日時は API で ISO 8601 形式(例:2026-11-01T03:00:00Z)により送受信する。

8. API 要件

ベースパス例:/api/v1

8.1 申請登録

POST /api/v1/applications

リクエスト例:

{
  "applicantName": "山田太郎",
  "description": "備品購入を申請します。"
}

成功時:201 Created

{
  "id": "9de4ad4a-b298-4c74-87ef-65211d54821a",
  "applicantName": "山田太郎",
  "description": "備品購入を申請します。",
  "createdAt": "2026-11-01T03:00:00Z"
}

8.2 申請一覧取得

GET /api/v1/applications

  • createdAt の降順で返す。
  • MVP は少量のデータを想定し、ページングは後続対応とする。
  • 成功時:200 OK
{
  "items": [
    {
      "id": "9de4ad4a-b298-4c74-87ef-65211d54821a",
      "applicantName": "山田太郎",
      "description": "備品購入を申請します。",
      "createdAt": "2026-11-01T03:00:00Z"
    }
  ]
}

8.3 申請詳細取得

GET /api/v1/applications/{id}

  • 存在する ID には 200 OK と申請情報を返す。
  • 存在しない ID には 404 Not Found を返す。

8.4 エラー形式

{
  "code": "VALIDATION_ERROR",
  "message": "入力内容を確認してください。",
  "fieldErrors": {
    "applicantName": "申請者名を入力してください。"
  }
}
HTTP ステータス 用途
400 JSON 不正、入力値不正
404 指定された申請が存在しない
500 想定外のサーバーエラー

エラー応答にスタックトレース、SQL、秘密情報を含めない。

9. 非機能要件

9.1 セキュリティ

  • API 通信は HTTPS を使う。開発時のローカル接続設定は本番設定と分離する。
  • DB の接続情報を Android アプリに含めない。DB へは Java API だけが接続する。
  • API で入力値を検証し、SQL はプレースホルダー等を使って安全に実行する。
  • ログに申請内容や秘密情報を不用意に出さない。
  • MVP は認証なしのため、個人情報・機密情報・実データを登録しない。

9.2 信頼性・運用

  • DB 保存に失敗した場合、成功として応答しない。
  • API の想定外エラーは共通形式で返し、詳細はサーバーログに記録する。
  • DB の日時は UTC で保存し、画面表示時に端末のローカル時刻へ変換する。
  • アプリは通信エラー時に再操作でき、二重送信を起こしにくい UI とする。

9.3 保守性

  • Android、API、DB の責務を分ける。
  • API の入出力モデルと DB の永続化モデルを必要に応じて分ける。
  • 設計判断と環境ごとの設定を文書化する。

10. 受け入れ条件

  • 正しい申請者名と申請内容を送信すると、API が 201 を返し、DB に一件保存される。
  • アプリを再起動しても、一覧から登録済み申請を確認できる。
  • 一覧は新しい申請が先に表示される。
  • 空欄、空白だけ、文字数上限超過の入力は拒否され、該当項目のエラーが分かる。
  • 存在しない ID の詳細取得は 404 となる。
  • API またはネットワークが利用できない場合、アプリは入力内容を保持してエラーと再試行手段を示す。
  • Android アプリから DB に直接接続していない。

11. 前提・未決事項

実装開始時に以下を決め、README などに記録する。

  • Android の実装方式(Kotlin または Java)
  • Java API のフレームワーク(例:Spring Boot)
  • DB(学習時はローカルで起動しやすいもの、本番想定では要件に合うもの)
  • 開発環境での API 配置方法
  • ID 方式(UUID または採番)
  • 利用者認証を追加する時期と方式

12. 将来拡張候補

MVP 完成後、必要性に応じて追加する。

  • ログインと申請者ごとのアクセス制御
  • 申請状態(申請中、承認、差し戻し)と承認履歴
  • 申請の編集・取消
  • 一覧のページング、検索、絞り込み
  • API・DB の自動テスト、Android の画面テスト
  • ログ、メトリクス、アラート、バックアップと復旧手順
  • クラウド環境への配置と CI/CD
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?