古いプロジェクトの要求分析をやりなおしてみた

# 1. 問題
3年前（2021年）、簡単なNode.jsアプリを作った。私がNode.jsで作った初めてのアプリだった。
目標と機能は以下のように設定していた。
- 目標
  - 本当はYoutubeのクローンを作りたいが、動画データの扱いが素人には難しい。
  - 「会員登録したユーザーたちが情報をお互いアップロードして共有」するというコンセプトだけは生かしてみたい。
- 機能
  - 会員登録
  - ログイン・ログアウト
  - ユーザープロフィール修正
  - 映像情報アップロード
  - 映像情報の詳細確認
  - 映像情報の修正
  - 映像情報の照会


当時は「これ必要だな」「この機能作ってみたら面白そう」と、各機能をその都度その都度思い出して作成した。機能リストもアプリを完成した後書いた。今振り返ってみると本当適当だったな。
何かのアプリを作るための計画をするとき、きっとまともで一般的な手順があるはず。
それに従ってはじめから計画しなおしてみたい。

# 2. 環境
すべてのアプリケーション計画段階。

# 3. 解決
Software工学の開発5段階のうち「要求分析」により、アプリ実装計画ができるという。
私は私の初アプリについて何を要求したいのか？改めて「要求分析」をしてみた。

# 3.1 要求事項の導出
  - 目標
    - 「多数のユーザーが好きな映像の写真と説明をみんなと共有するWeb Application」の具現。
    - Backend開発の基本概念の実習。（MVC、CRUDなど）
    - 根幹になる技術を採択。例）ViewをPUGではなくHTMLで具現。
    - ログイン機能の実装練習。<br/><br/>

  - 機能要求事項
    - 会員登録
    - ログイン・ログアウト
    - ユーザープロフィル修正
    - 映像情報（画像、テキスト）のアップロード・修正・詳細確認・照会
    - シンプルなUI <br/><br/>

  - 非機能要求事項
    - 制約事項
      - Node.js使用。
      - FrontendはGitHub Pagesに、BackendはGCP(Linux Ubuntu)にDeploy。<br/><br/>

    - 品質
      - 保安性の側面：HTTPS使用
      - 信頼性の側面：DB作動しない場合であってもユーザーにばれないこと。

# 3.2 要求事項の表現(Usecase List)
| ユーザー | 最終Usecase | その他 |
|:-|:-|:-|
| **ユーザー（未登録会員）**  | 映像情報の閲覧  | 照会  |
|   | 会員登録  | 登録  |
|   | プロフィール閲覧  | 照会  |
| **ユーザー（登録会員）**  | 映像情報の閲覧 | アップロード、修正、削除、照会  |
|   | 会員登録  | 登録、退会  |
|   | プロフィール閲覧  | 修正、照会  |
| **Admin**  | 映像情報の閲覧  | アップロード、修正、削除、照会  |
|   | プロフィール閲覧  | 照会  |

# 4. 詳細
「要求分析」とは何なのか？を説明する。

### 4.1 要求事項とは
Softwareも顧客を満足しなければならない。
そのためにはユーザーの`要求事項（requirement）`を正確に把握する必要がある。
Software開発での`要求事項`は「ユーザーが必要とする機能」である。
要求事項の把握は`要求分析`段階で行われる。

### 4.2 要求分析の理解
#### 4.2.1 定義
`要求分析（requirement analysis）`は「Software Development Life Cycleの初段階。現在の状態を把握し、ユーザーの潜在的かつ明示的な要求を把握してからSoftwareに反映するユーザーの要求を決定すること」である。

#### 4.2.2 目的
ユーザーから必要な`要求事項`を取り出し目標システムの`Model`を作り、`要求分析明細書`を作り上げるためである。

#### 4.2.3 関連する人々
発注社、経営者、発注担当者、受注社、分析家、設計者、開発者など。

### 4.3 要求分析のプロセスと種類

#### 4.3.1 プロセス
①資料収集　→　②要求事項の導出　→　③文書化　→　④検証

- `資料収集`：インタビューなどで。
- `要求事項`の導出：開発に反映する要求事項の導出。
- `文書化`：導出した要求事項を`要求分析明細書`にする。
- `検証`：要求分析明細書にユーザーの要求が正確に記録されているかなどを点検。

#### 4.3.2 要求事項の分類
- `機能要求事項`
  ユーザーが希望する、Softwareの機能のこと。<br/><br/>

- `非機能要求事項`
  Softwareが実行できる環境、品質、制約事項などのこと。

  - `制約事項`
     Softwareが実行される環境による条件のこと。
     例：Javascriptを使用して開発すること。<br/><br/>

  - `品質`
     `信頼性(reliability)`、`可用性(availability)`など。<br/><br/>
     
   
### 4.4 要求事項の表現
`要求事項`は一目で分かるように表現しなければならない。
表現には`Model`を使用する。

#### 4.4.1 Modelとは
`Model`は「複雑な対象の主なポイントを選別し一定の観点で単純化し記号やイメージで体系的に表現したもの」である。
`実際の姿`を前もって確認するためModelを使用する。
Software開発においてもModelは必要である。`オブジェクト指向(OOP：Object Oriented Programming)`では様々な`UML Diagram`により開発するSoftwareの範囲や概略的な構造と機能を理解することができる。

#### 4.4.2 Modelingとは
`Model`を制作する過程それとも作業のこと。
Software開発では`自然語`、`形式言語(formal language)`、`UML Diagram`などでModelingをする。

#### 4.4.3 Modeling Language
- 定義
Software開発でのModeling Languageは、要求事項の定義・分析・設計の結果を様々なDiagramで表現する表記方法である。
表現が一貫しているのでModelingしやすい。開発者たちが円滑なコミュニケーションができるようにもしてくれる。<br/><br/>

- 種類
どんな`開発方法`を採択しているかによって使用する`Modeling Language`が異なる。

  - 構造的方法　→　DFD、DD、mini-specification
  - 情報工学方法　→　E-R Diagram(ERD)
  - `オブジェクト指向(OOP)`　→　`UML表記法`。特に要求事項の表現には`Usecase diagram`を利用。

#### 4.4.4 Usecase Diagram
①Usecase Diagram 作成
まず`Usecase List`を作成し、それを基に`Usecase Diagram`を作成する。
<!--
Usecase List의 예시: 표 4-4 최종 유스케이스 목록 ('쉽게 배우는 소프트웨어 공학' 196페이지)
-->

②Usecase 明細書作成

### 4.5 要求事項の文書化

#### 4.5.1 要求分析明細書とは
要求分析過程の最終的な産出物。
ユーザーには契約書として、開発者には設計及び具現のための公式文書として使用される。

# 5. 関連知識
なし

# 6. まとめ	
- 古いプロジェクトの実装計画のやり直し
  - Software工学における`要求分析`で成功。
- `要求分析`とは
  - ユーザーの要求を把握しSoftwareに反映する要求を決定すること。
- 要求分析のプロセス
  - 資料収集　→　`要求事項`の導出　→　文書化（`要求分析明細書`）　→　検証
- `オブジェクト指向`における要求事項の表現
  - `Usecase Diagram`使用。

# 7. 参考
[わかりやすいソフトウェア工学（第2版）](https://www.yes24.com/Product/Goods/102487130)

# 8. 感じたこと
数年間のモヤモヤがやっと晴れた。すっきりする。