非機能要件を設計やコードに反映する

非機能要件というものがプロジェクトにはあります。
しかし、非機能「要件」をコードにするときに何を書いたらよいのか悩みます。

そもそも「非」機能とはどのようなものがあるのでしょうか。

IPAが定めている非機能要件の大まかな区分けは以下です。

• 可用性
• 性能・拡張性
• 運用・保守性
• 移行性
• セキュリティ
• システム環境・エコロジー

「非機能」よりは具体性が上がるかもしれませんけども、
まだ、どのようなコードにすればよいのか想像しづらいですね。

今回は「非機能要件とはなんぞや」とい方向けに、簡単にいくつか紹介します。

プロジェクトごとに非機能要件は変わるものなので、ひとつの参考として見ていただければと思います。

非機能要件を満たすときコードが必要とは限らない

というのも、実際問題としてコードではなく別のレイヤーで非機能要件を対応することが多いからです。

例えば可用性です。

「日本で災害が起きてもサービス継続したい」という要件であれば、
海外という地理やサーバの冗長化や仮想化というインフラで解決します。

また、移行性においては、移行スケジュールや移行方法を決めますし、
運用保守性においても、稼働した時のサービスの運用手順を手順書として
資料にします。

このように、コードの入りこむ余地が無いものも非機能要件にはあります。

非機能要件にコードが必要な場面はある

それでは、プログラム書くときに非機能要件は無視してよいのかと言われると
そんなことはありません。

非機能要件がコードレベルまで必要とされることは、やはりあります。

WEBアプリケーションに限定にはなりますけども
実際に非機能要件をコード（もしくは詳細設計）に反映した経験を紹介したいと思います。

可用性はトランザクションを意識する

障害がおこったとき、可用性が高く求められているのであれば、
インフラレベルで速やかに復旧するシステムになっています。

しかしながら、トランザクションが無いと中途半端な状態になりデータが欠損します。
このデータ欠損が起きるとWEBページを表示するためのデータが足りず、結果として可用性が落ちます。
これでは、せっかくインフラを復旧させても意味がありません。

当たり前の話ではありますが、データを更新するときはトランザクションを管理することが大切です。

ただ一方で、APIを利用したデータ保存も活発になったため、DBのトランザクションだけでデータ整合性を担保することは難しくなりました。

そのような場合は、トランザクションを補完するTry Confirm/Cancelの実装を検討します。

性能はリソースの効率化を行う

性能についてはコードの書き方が直接性能に影響するので
他の非機能要件に比べるとイメージしやすい方です。

• メモリの確保：不要なインスタンスが残らないように削除
• CPUリソースの利用：非同期処理と並列処理を入れる
• ループの最小化：無駄なループを排除し時間の節約

などなど。

拡張性は同じプログラムを複数動かせるかで考える

拡張性は「WEBサーバが増えても問題なく動くか」で考えます。
言い換えると「プログラムを複数動かしても動くか」です。

ポイントはWEBアプリケーション側でデータを保持しないことです。

データを保持する機能としてWEBアプリケーションではセッション情報があります。

WEBサーバAがビジーになったので、WEBサーバBを投入した場面を想定してみてください。

WEBサーバAでセッション情報を保持してしまうと、せっかくWEBサーバBを投入しても情報は反映されません。

これでは拡張性が高いとは言えないですね。

そこで、WEBサーバにデータを保存するようなコードは避けてKVSやDBに保存する設計やコードにします。

WEBサーバ以外にデータを保存しているので、
WEBサーバを何台投入しても同じ状態にできます。

運用・保守性

ログです。ログをきちんと出します。

セキュリティはコーディングで失われる可能性があるため要注意

• XSS
• CSRF
• SQLインジェクション

この３つの対策をコードレベルで入れたいところです。

WEBアプリケーションには多くの攻撃がきます。
ただ、コードレベルで対応するよりは、サーバーやサーバのミドルウェアの領分で対策していることが多いです。

しかし、XSS、CSRF、SQLインジェクションの３つは、
エンジニア自身が脆弱性を作りだしてしまいがちなので注意したいです。

特にSQLインジェクションは、データを不正に取得もしくは書き換えられるためリスクが大きいです。

おわりに

以上でコードで非機能要件を意識した例の紹介は終わりになります。
WEBアプリケーションを作られている方の参考になれば幸いです。

ちなみに、

移行性・システム環境・エコロジーについてはコードに落した経験がないので紹介できませんでした。

ただ最近では「持続可能」が叫ばれているので、いずれ自然に優しいコード、
消費電力の少ないコード、が称賛される時代がくるかもしれませんね。