5 Projekt ogólny

Rozdział ten prezentuje…

5.1 Specyfikacja wymagań funkcjonalnych i niefunkcjonalnych

Podrozdział w Projekt ogólny. Specyfikacja wymagań jest fragmentem SRS — Software Requirements Specification. Szczegółowe informacje na temat dokumentu SRS dostępne są tutaj (PDF). Specyfikacja wymagań funkcjonalnych zawiera opis funkcji udostępnianych przez system. Np. Otwarcie istniejącego raportu, Utworzenie nowego raportu, Edycja ustawień, itp. Funkcje systemu odpowiadają zazwyczaj przypadkom użycia występującym na diagramie Use Case (PDF), taki diagram jest mile widziany jako element specyfikacji wymagań funkcjonalnych. Poszczególne wymagania mogą być prezentowane w postaci listy numerowanej lub bardziej szczegółowo w postaci tabeli. Wymagania niefunkcjonalne dotyczą aspektów systemu nie przekładających się bezpośrednio na akcje wykonywane przez system, dotyczą takich aspektów jak architektura, bezpieczeństwo, wydajność, ergonomia interfejsu użytkownika, kolorystyka. Wystarczy prezentacja wymagań niefunkcjonalnych w postaci listy numerowanej.

W przypadku osób przyzwyczajonych do pracy z wykorzystaniem metodyk zwinnych, można przedstawić specyfikację funkcji systemu w postaci historii użytkownika.

5.2 Architektura systemu

Podrozdział w Projekt ogólny. Określamy jakiego rodzaju będzie system (system klasy desktop, mobilny, internetowy). W zależności od danego rodzaju systemu określamy czy będzie podzielony na podsystemy, elementy, warstwy, moduły, określamy gdzie będą one ulokowane i jak będą ze sobą współpracować. Przykład: “System będzie trójwarstwową aplikacją internetową. Warstwa kliencka działać będzie w środowisku przeglądarki, będzie ona się komunikować z warstwą usług serwerowych za pośrednictwem API REST. API będzie korzystało z bazy danych umieszczonej na osobnym, dedykowanym serwerze”. Dalej następują rysunki ideowe ilustrujące architekturę aplikacji, ogólny opis przeznaczenia oraz roli poszczególnych elementów aplikacji, metod komunikacji pomiędzy nimi.

5.3 Metody i narzędzia realizacji

Podrozdział w Projekt ogólny. Opierając się na znanych już wymaganiach oraz znanej architekturze systemu dokonujemy krótkiego przeglądu możliwych metod oraz narzędzi jego realizacji, wybieramy jedną wersję oraz uzasadniamy wybór (o ile nie dokonano tego w rozdziale dotyczącym koncepcji rozwiązania technologicznego). Przedstawiamy krótką charakterystykę narzędzi z uszczegółowieniem wersji którą planujemy wykorzystać. Uwaga: nie wstawiamy tutaj rozbudowanych opisów narzędzi, nie opisujemy języków programowania i wszystkich ich mechanizmów, nie robimy tutorialu z serwerów baz danych, innymi słowy nie robimy “lania wody”, ma być krótko, konkretnie i kompetentnie, a zatem jeżeli wybieramy PHP, to uzasadniamy dlaczego, jeżeli wybieramy konkretny framework dla PHP to piszemy dlaczego ten właśnie, i której wersji planujemy użyć. Przechodzimy do szczegółów jedynie wtedy, gdy są one istotne dla projektu w fazie projektu ogólnego, np. jeżeli istotnym elementem wpływającym na wybór biblioteki Qt jest mechanizm slotów i sygnałów, to można napisać parę zdań na ten temat, co ułatwi wskazanie uzasadnienia wybory tejże biblioteki.

5.4 Koncepcja przechowywania danych

Podrozdział w Projekt ogólny. Zazwyczaj systemy informatyczne potrzebują danych przechowywanych trwale. Wykorzystuje się do tego najczęściej bazy danych, zwykle trzeba je zaprojektować. W tym podrozdziale należy przedstawić jak będziemy zapisywać dane trwałe, jeżeli stosujemy bazę danych to należy określić jej model oraz przedstawić szczegóły modelu. W przypadku baz relacyjnych podajmy model konceptualny, logiczny i fizyczny, w przypadku gdy merytorycznie one się istotnie nie różnią, podajemy model najbardziej pełny. Ilustracją wybranego modelu są najczęściej diagramy, np. diagramy ERD opisane tutaj (PDF).
Uwaga, zamieszczenie samych diagramów nie wystarcza, należy przedstawić również opis przeznaczenia poszczególnych tabel, wraz z informacjami o kluczach głównych i obcych. Dla baz nierelacyjnych podajemy adekwatne dla tych baz formy ilustracji metody organizacji danych. W przypadku, gdy bazy danych nie są wykorzystywane w projektowanym systemie, przedstawiamy przyjętą koncepcję przechowywania informacji (pliki serializacyjne, pliki tekstowe, pliki CSV, pliki XML, pliki binarne), oraz szczegóły ich reprezentacji, przyjęte formaty.

5.5 Projekt interfejsu użytkownika

Podrozdział w Projekt ogólny. Prezentacja koncepcji organizacji interfejsu użytkownika, przyjmująca postać rysunków wraz ze stosownym komentarzem. rysunki mogą zawierać szkice interfejsu (również odręczne, skany), makiety z odpowiednich programów do modelowania interfejsu użytkownika. Uwaga — nie umieszczamy tutaj finalnych elementów gotowego systemu, przecież go jeszcze nie ma! Jeżeli aplikacja mam być responsywna i w różny sposób “wyglądać” na różnych urządzeniach, należy przedstawić szkice interfejsu dla każdego z przewidywanych trybów pracy.