読者です 読者をやめる 読者になる 読者になる

文系男子が日和るIT開発~IT知識なしで飛び込んだIT企業

文系男子だからIT企業に就職するなんて考えてもみませんでしたが、日和ながら日々くらいついています。

(非機能要件)非機能要件のヒアリングと非機能要求グレード

お客様と新しい案件で、要件を詰めるための打ち合わせを行うことが多い。
「フラットデザインにしたいです」
「画面遷移はこうしたいです」
「ここの画像をスワイプさせたい」

新しいものを作るときには、要件を詰める・聞き出すのが最も重要なのですが、
だいたいどの案件でも非機能の要求、特に品質面の要求事項は出てこない。
それを聞きだし、要件として決めることが結構パワーがかかるし、何より、難しい。

理由を探ると、JIS X0129では、下記のような理由らしい。

設計の開始前に品質要求を完全に定義することはできない。
(1)利用者が自分の真の必要性に気づいていないことがある
(2)必要性は、明示された後に変わることがある
(3)異なった利用者は、異なった運用環境をもつことがある

 なるほど。
特に、(2)や(3)やなどは、ソフトウェア品質を決めるうえで、予測しづらいし、外部要因などによって強制的にひん曲がることもある。

じゃあどうすればいいか、というと

1.システム特性
2.性能
3.信頼性
4.運用性
5.拡張性

を決めるといいらしい

 

1.システム特性

システムや業務の規模、重要度(金銭や個人情報を取り扱うか)外部システム有無、

2.性能

レスポンスや同時アクセス数、

3.信頼性

セキュリティレベル、計画停止が可能な頻度や時期・時間帯、復旧までにかけられる時間、

4.運用性

運用監視の必要性、業務運用/システム運用のしやすさ

5.拡張性

ユーザ数や、データ量の増加予測。

 

経験の浅い担当者が非機能を決めるうえでは、非機能要求グレードというようなツールを活用してみるのが、いいのかもしれない。

非機能要求の見える化と確認の手段を実現する「非機能要求グレード」の公開:IPA 独立行政法人 情報処理推進機構

 

 

WEBアプリケーション・サーバー 設計・構築ノウハウ 第2版

WEBアプリケーション・サーバー 設計・構築ノウハウ 第2版