sapislab開発記録 - 要件定義
では要件を明確にするところから始めましょう。
やりたいことは「状態制御をAPIサービスとして提供する」です。
とても明確なゴールですが、このままでは「言っている本人しか具体的なことは分からない」状態ですね。
システム開発の現場ではお客様のゴールを達成する事が基本的な価値の提供になる訳ですが、初期にゴールが明確になる事は稀であり引き出す事から始まるのが常だと思います。
お客様も一枚岩ではなく、利害関係などから意見が割れる事もあるでしょう。そこをなんとか調整しつつ目指すのです。
さて、今回は私自身がお客様なので不要かもしれません。
それでも全体を俯瞰する事は重要なので要件をまとめていきましょう。
全体像が分からない状態でプログラムを書いていると気づきが減って危ういのです。
まず「APIサービスとして提供する」とはどういう事でしょうか。 この場合、PCやスマホ・電子機器などのHTTPアクセスが出来る環境からHTTPリクエストを送り、そのリクエストを受け付けるAPIサーバーを開発・維持・管理するという事と理解できます。
では誰でも使えて良いのでしょうか。利用者を区別する仕組みが無いと「状態」を不特定多数が書き換える可能性があり、使い物になりません。 なので「利用者を区別できること」という要件が追加になります。
また「状態」をどのように管理するかも検討が必要です。
既に提供しているプログラムを置き換えられるように、今回は単純なKeyとValueを記憶させるだけにします。
このValueは文字列とし、ここに状態の名前を保持することでやり取りできるようにします。
これ以上の細かい部分は省略しますが、こういう感じで幹となるゴールと必要な枝葉を付けて問題無い形に仕上げていくのです。 実際にはこのフェーズで完全な形にはならず、大いに問題を含んだ状態で次の工程に進む事が多いですが「やりたいこと」の幹がずれていない事の意識合わせは最低限終わらせたいものです。
ではsapislabの初期段階の要件は以下になります。 ※実際の要件定義書に比べるとかなり情報が不足していますので鵜吞みにしないよう注意！
- 利用者の登録が出来ること（サインアップ）
- 利用規約に同意させること
- 不正利用判定（ロボット判定）ができること
- メール認証ができること
- 管理者と利用者がログインできる管理画面があること
- 管理画面の機能
- APIサービスの機能
- KeyValueの一覧・詳細・登録・編集・削除ができること
なんとなく形が見えてきたでしょうか。
インフラは？非機能要件は？監視体制は？バックアップは？
完全形を目指すにはまだまだ足りないものがたくさんありますが、まずはここから始めていきましょう。
