To znaczy, że specyfikacja powinna być napisana językiem naturalnym, którego używa się na co dzień?

Ależ skąd! Język naturalny ma to do siebie, że jest bardzo daleki od precyzji. Interpretacja tego samego zdania przez dwie różne osoby może być istotnie różna. Rozumienie języka naturalnego zależy bowiem od rozumienia informacji kontekstowych.

Kiedyś poproszono mnie o konsultację przy projekcie opracowania oprogramowania, przeznaczonego do sterowania elektrownią atomową. Było ono tam przez 6 lat testowane. Wydawało się, że działa idealnie. Tymczasem udało mi się znaleźć kolejny poważny błąd - przyznaję, że przez przypadek - w ciągu 2 godzin! Jego powodem było właśnie mylne zrozumienie zapisu ze specyfikacji. Ten, kto napisał to zdanie, miał co innego na myśli, niż zrozumieli to informatycy, którzy je odczytali!

Czy jednak przejście od języka naturalnego do opisu formalnego nie spowoduje nieciągłości, która dzieli użytkowników (odbiorców systemu) oraz informatyków (jego wykonawców) na dwa z trudem komunikujące się światy? Jeśli zaczniemy specyfikację zapisywać w postaci formuł logicznych, której to notacji nie sposób odmówić precyzji, to dla użytkownika będą to tylko "robaczki", nawet jeśli ten formalizm będzie przekształcony do postaci pewnego informatycznego zapisu tworzenia specyfikacji. Profesor Jan Madej stwierdził kiedyś, że ta nieciągłość jest podstawową przyczyną, dla której informatyka jest tak trudną dziedziną.

Tak i nie. Musimy posługiwać się formalizmami, ale nie muszą to być abstrakcyjne formuły matematyczne. Musimy je tak rozpisać, żeby nie tylko matematyk mógł je zrozumieć. Weźmy dla przykładu wypełnianie deklaracji podatkowej - cały algorytm wyliczania należnego podatku dochodowego można by przedstawić za pomocą skomplikowanych formuł, z których nikt by niczego nie rozumiał. A te same formuły rozpisane na stronach deklaracji podatkowej, w której poszczególne punkty wymagające jedynie odpowiedzi tak, nie, czy prostych obliczeń na kalkulatorze, są już znacznie łatwiejsze do ogarnięcia. To nie matematyka jest winna, ale niewłaściwe jej zastosowanie.

To pewien ideał, żeby podobnie można było postępować w przypadku konstruowania systemów informatycznych. Jednocześnie precyzyjnie i zrozumiale.

Kiedyś mi się to udało, gdy przygotowywałem specyfikację dla oprogramowania, które miało znaleźć się w samolocie A7. Piloci, którzy ją czytali, znaleźli 500 błędów! To może głupio zabrzmi, ale jestem z tego dumny. Przecież mogłem tę specyfikację napisać tak, że piloci nie byliby jej w stanie zrozumieć. Wówczas te błędy trzeba by było wychwycić na etapie testowania. Niektóre - być może - dopiero w powietrzu...

Byłem świadom, że piloci byli tak naprawdę jedynymi ludźmi, którzy faktycznie wiedzieli, do czego ma służyć to oprogramowanie.