システムが保証しなければならないサービスの信頼性はエンジニアが担保しなければならない。
要件定義書をまとめる際、重要なことを欠落する事がないようポイントを記載。
30秒で読めるようにざっくり書く。
機能要件
システムで何をやりたいのか。
非機能要件
- システムの提供時間
- セキュリティ
- 非機能要件を実現している大部分がインフラ
- 非機能要求はアプリケーションの快適さを表す
RASIS
実現したい要求である機能要件以外の機能が、正しく動作する仕組みを定義。
非機能要件の一部。
| 項目 | 略称 | 概要 | 一例 |
|---|---|---|---|
| Relibility | (R)信頼性 | 障害の発生しにくさ | 稼働時間当たりの障害発生回数で表す |
| Availability | (A)可用性 | 障害が発生した際の復旧 | SPOFの排除などで対策 |
| Serviceability | (S) 保守性 | 保守や修理のし易さ | メンテナンスの容易なソースコードに保つ |
| Integrity | (I) 保全性 | 過負荷時や障害時のデータの破壊 | 矛盾を排除する。データベースだとACID属性 |
| Security | (S) 安全性 | 外部からの侵入・改ざんや機密漏洩の起きにくさ | 不正アクセス対策 |
リリース後、機能を追加する時にゼロから作り直したほうが早いと感じられるシステムは保守性が低いと言える。
一方で、既存のシステムを再利用して新しい機能を追加したり、既存のシステムを改修する事が可能であれば保守性が高いと言える。
参考情報
http://blog.father.gedow.net/2012/08/14/system-reliability-indicator-rasis/
https://bongineer.net/entry/rasis/