SW wykład 14 - Slajd2
Systematyczne konstruowanie programów Inżynieria wymagań Walidacja specyfikacji Strukturalne języki specyfikowania Zadanie programisty Uszczegóławianie Uszczegóławianie, c.d. Dekompozycja Wyzwanie
Każda specyfikacja systemu pełni przede wszystkim rolę pośrednika między (przyszłym) użytkownikiem tego systemu a jego realizatorem. (UWAGA: mówiąc o użytkownikach systemu, nie mamy na myśli tylko "prawdziwych użytkowników", ale także programistów wykorzystujących dany system --- lub dany moduł --- do budowy kolejnych systemów.) Oznacza to, że każdą specyfikację można czytać dwojako, z dwóch różnych punktów widzenia.
Po pierwsze, dla użytkownika, specyfikacja przedstawia te wszystkie własności systemu, na których może polegać jego użytkownik. Ważne dopowiedzenie: i tylko na własnościach zawartych w specyfikacji systemu użytkownik może polegać. Inne zauważane przez użytkownika własności można rozumieć jako własności przypadkowe, które mogą się zmienić, gdy na przykład powstanie kolejna wersja systemu, albo wręcz przez być może nieobserwowalne bezpośrednio przez użytkownika efekty działania systemu w czasie.
Po drugie, dla realizatora systemu, specyfikacja przedstawia te wszystkie własności, które budowany system musi spełniać. I znów ważne dopowiedzenie: i tylko te własności musi zapewnić realizator. Jeśli jakaś własność nie jest konsekwencją specyfikacji, może ona nie być przez realizację systemu zapewniona.
Już z powyższego widać, że budowa dobrej specyfikacji systemu jest zadaniem bardzo ważnym, a jednocześnie na ogół bardzo złożonym. Jest to przedmiot znaczącej dziedziny, często określanej jako inżynieria wymagań: jak zbudować dobrą specyfikację (jak zebrać, sformalizować i przedstawić w precyzyjny, a jednocześnie zrozumiały i jasny sposób wszystkie niezbędnie wymagane własności systemu) i jak potem przekonać się, że wszystkie oczekiwane i tylko oczekiwane własności systemu zostały w specyfikacji zawarte.
