Projektuje aplikację

Dlaczego tak

Wymagania funkcjonalne opisują, co system robi — jakie operacje udostępnia i komu — dlatego przeglądanie, ograniczenie widoku do własnych wyników i eksport do PDF są funkcjonalne. Wymaganie niefunkcjonalne określa, jak dobrze system ma działać: wydajność, dostępność, bezpieczeństwo, użyteczność. Czas ładowania ekranu poniżej 2 s jest wymaganiem wydajnościowym, które projektant musi uwzględnić w architekturze, choć nie dodaje żadnej nowej funkcji.

Dlaczego tak

Specyfikacja techniczna zamienia ogólne życzenie klienta na wymagania jednoznaczne i sprawdzalne: wiadomo, po jakich polach się wyszukuje, jak traktowana jest wielkość liter i jaki czas odpowiedzi trzeba osiągnąć, więc tester może napisać do tego przypadki testowe. Określenia „intuicyjna”, „łatwo i szybko” powtarzają tylko słowa klienta i każdy programista zrozumie je inaczej. Pozostawienie decyzji programiście przenosi ryzyko na koniec projektu, gdy klient odrzuci rozwiązanie.

Dlaczego tak

Przyciski opcji połączone w grupę pozwalają zaznaczyć tylko jedną pozycję — wybranie kolejnej automatycznie odznacza poprzednią, a wszystkie możliwości są cały czas widoczne. Pola wyboru działają niezależnie od siebie, więc użytkownik mógłby zaznaczyć dwa lub trzy poziomy naraz. Pole tekstowe wymusza wpisywanie i nie ogranicza odpowiedzi do trzech wartości, a pasek postępu jedynie pokazuje stan operacji i nie przyjmuje danych.

Dlaczego tak

Dobry projekt formularza mówi użytkownikowi, co jest źle i jak to naprawić, w miejscu, którego błąd dotyczy, np. „Hasło musi mieć co najmniej 12 znaków”. Sygnalizacja samym kolorem nie dotrze do osoby z daltonizmem ani do użytkownika czytnika ekranu i nie wyjaśnia przyczyny błędu. Ogólne okno „Błąd” też nie wskazuje pola ani przyczyny, a czyszczenie formularza zmusza do ponownego wpisywania wszystkich danych.

Dlaczego tak

Palec jest znacznie mniej precyzyjny niż kursor myszy, dlatego wytyczne Material Design zalecają obszar dotyku co najmniej 48 × 48 dp, a wytyczne Apple — 44 × 44 pt, z odstępami między elementami. Podpowiedzi po najechaniu kursorem nie działają na ekranie dotykowym, bo nie ma tam stanu „najechania”. Skróty klawiaturowe nie pomogą na telefonie bez fizycznej klawiatury, a mniejsze przyciski tylko zwiększą liczbę pomyłek.

Dlaczego tak

Paradygmat obiektowy łączy dane i operacje na nich w klasy: obiekt Ksiazka przechowuje własny stan (tytuł, dostępność), a metody, np. wypozycz(), zmieniają go w kontrolowany sposób, dzięki hermetyzacji niewidoczny z zewnątrz. Rozbicie funkcji na mniejsze to nadal programowanie strukturalne, bo dane pozostają oddzielone od kodu i dostępne dla każdego. Zmienne globalne są wręcz przeciwieństwem hermetyzacji.