成長人生、「投資場!!」

このブログは「秋葉」と「江南」の2人で、IT・ICT系の情報や、社会人ノウハウを発信します。基本的に週一更新で記事は交互に作成しています。

【アプリ・システム開発】仕様書テンプレートの紹介と項目の解説【初心者向け】

 

皆さんこんにちは、江南です。

 

今回は、アプリの仕様書をはじめて作ってみた中で、調べたことをまとめてみたいと思います。

 

1.アプリ仕様書作ると言っても、何を書けばいいの!?

本当にはじめての仕様書の作成ですので、何をどのように書いていけば良いのか全然わかりませんでした。

 

そこで使おうと考えたのが、仕様書のテンプレートです。

 

テンプレートには、多分一通りの書くべきことが書いてあると思ったのです。

 

◯実際使ってみたのは、こちらのサイトのものです。(素晴らしいものです)

・[文書]テンプレートの無料ダウンロード 様

https://template.k-solution.info/30000/

 

 

素晴らしいテンプレートで、細かく記載項目が載っていたのですが、そこに書いてある記載項目について、知識が足りず…

 

「え、これ何書いとけば良いんだ?」

 

という項目が多数ありましたので今回はその項目について、調べたことをまとめてみました。

 

2.この項目、何書けばいいの?(機能要件・非機能要件)

今回解説するのは、上記テンプレートで言うところの、3.システム要件の部分です。

 

ちなみにそもそも「システム要件」とは…

業務要件を満たすため、ITシステムが持つべき機能要件非機能要件を定めたもの

です。

 

それではそのシステム要件の項目を見ていきましょう。

 

 

1.1 機能要求

これは、「この機能、絶対に欲しい!」「この機能がなければ、作りたいアプリじゃない!」という機能を書きます。また以降(連番の1)では、この絶対に欲しい機能についての、詳細な説明と設定をしていくことになります。

 

1.2 機能要求ID

絶対に欲しい機能を識別するための符号のことです。簡単に言えば機能名の英字や数字版です。

 

1.3 機能名

絶対に欲しい機能の名前です。

 

1.4 概要

絶対に欲しい機能についての概要です。

 

1.5 入力

どのような項目が入力できるのか、制限はついているのかを記載します。

例)生姜焼き弁当(と入力)→580円(と表示)

  焼き肉弁当(と入力)→680円(と表示)

  iPhone(と入力)→エラー(もしくはそもそも入力できない)

 

1.6 出力

出力できる項目や連携できるソフトウェア、印刷できる内容などを表記します 。

例)レシートや領収書の出力(プリントできる設定で)

 

1.7 処理

入力されたデータをどのように処理していくかを書きます。

例)「エラー処理」 一部のデータにエラーがある場合に全体を止めるかできるだけ動かすか、など

 

1.8 関連要求ID

そのままですが、関連する機能要求IDはどんなものがあるのか書きます。

 

1.9 上位要求ID

こちらは、今定義している機能要求IDの上位に存在する機能要求IDがあれば書きます。

 

1.10 利用者グループ

現在定義している機能を使う利用者を定義します。

 

1.11 備考

備考です。

 

 

2. 機能外要求

機能要求を支える、もしくは付加しなければいけない機能です。

以下が項目になります。

            

2.1 保守性

保守サービスに関する要求です。

 

2.2 拡張性

将来のシステム拡張に関する要求です。

 

 

2.3 移植性

現行システム資産の移行に関する要求です。

 

2.4 性能目標

どのような性能を目指すか書きます。

例)平常時のレスポンス3.0秒以内、ピーク時のレスポンス6.0秒以内

 

2.5 品質属性

その他の、品質属性について書きます。特に使用性について書きます。

 

2.6 制約条件

定義しているアプリやシステムに、制約条件があれば定義します。

 

2.7 セキュリティ目標

アプリやシステムの、セキュリティ項目について定義します。

 

2.8 システムのライフサイクルと維持管理

いつシステム改善を行うのか、保守についてどうするのか書きます。

 

2.9 仮定と依存関係

実行順序の依存関係を考えて書いてみます。結構この依存関係の魔の手に書かている人もいるようです。

 

3.おわりに(調べての所感〉

調べていて感じたのが、この機能要件・非機能要件というのは、ビジネスの場合、非常に厄介なものになっているということです。

顧客と製作者との間で、要件の定義の意思疎通ができておらず、成果物が顧客にとってギャップのあるものであったという失敗事例をよく目にしました。

この問題、いろいろ根深いところもあるのですが、最終的には製作者が顧客インサイトをどこまで掘り出せるかという点に尽きると思います。

もちろん製作側は、顧客の業務についての深い理解は無いわけですが、根本的に(ビジネスの場であれば)お金をもらっているという点で、顧客とのコミュニケーションを怠ったり、内なる需要を聞き出さないというわけには行きません。

まあ、費用との兼ね合いもあるのでしょうが…

 

いろいろ考え込んでしまったので、今日はここまで!

なにか間違っている点がありましたら、どしどしコメント寄せてください。

勉強させてもらいます!