Zio-09-wyk-Slajd14
Standard ISO 9126
W przypadku wymagań funkcjonalnych zadanie stworzenie specyfikacji wydaje się proste. W 1998 roku IEEE zaproponowało omawiany podczas poprzedniego wykładu standard IEEE 830:1998 „IEEE recommended practice for software requirements specifications”. W przypadku wymagań pozafunkcjonalnych zadanie jest trudniejsze, bo opis powinien uwzględniać specyfikację nie tyle konkretnych funkcji systemu, ale raczej jego ogólnych właściwości, jako kompletnego rozwiązania – wytworzonego przez producenta i dostarczonego użytkownikowi.
Specyfikacja wymagań pozafunkcjonalnych nabiera bardzo istotnego znaczenia. Cytując I. Sommerville’a: „Użytkownicy zwykle znajdują sposób na obejście ograniczeń funkcjonalnych systemu, które nie spełnią ich oczekiwań. Jednakże niespełnienie wymagań pozafunkcjonalnych może uczynić aplikację niezdolną do użytkowania.” W skrajnym przypadku (np. dla systemu czasu rzeczywistego) nie spełnienie wymagań wydajnościowych oznacza, że system jest bezużyteczny, a wręcz groźny dla wykorzystujących go osób.
Pierwszą próbę podjął Barry Boehm. W artykule opublikowanym w 1976 roku na Drugiej Międzynarodowej Konferencji Inżynierii Oprogramowania (ICSE) wraz z J. R. Brownem i M. Lipowem zaproponował hierarchiczny model opisywania charakterystyk jakościowych (dziś możemy także powiedzieć: wymagań pozafunkcjonalnych).
Wychodząc od ogólnego pojęcia „użyteczności produktu” programistycznego zdefiniowano trzy podstawowe grupy cech oprogramowania: przenośność, łatwość użytkowania (rozróżniającą niezawodność, wydajność i inżynierię humanistyczną) oraz łatwość konserwacji (wyróżniającą łatwość testowania, łatwość zrozumienia produktu oraz łatwość wprowadzania modyfikacji do aplikacji).
