Dokumentacja techniczna opisuje działanie i parametry techniczne stanowiące istotę wprowadzenia produktu finalnego, np. budowli, systemu, instalacji, itp. Uwzględnia wszystkie dane niezbędne do wykonania danego wyrobu. Na podstawie dokumentacji technicznej można sprecyzować czas realizacji poszczególnych etapów projektowania, a nawet przedstawić kosztorys realizacji projektu, co zmniejsza ryzyko realizacji nietrafionych inwestycji. Przy projektowaniu i wdrażaniu sklepu internetowego istotne jest, aby przed stworzeniem dokumentacji technicznej dokonać specyfikacji funkcjonalnej, która umożliwi dobranie właściwej technologii jego wykonania.

Dokumentacja techniczna to podstawowy element projektów z dziedziny informatyki. Dla osób, które nie poświęciły jej wystarczającej uwagi wiele projektów kończy się fiaskiem. Warto zaznaczyć, że profesjonalne i skomplikowane, a tym samym najbardziej kosztowne projekty posiadają bardzo rozbudowany pakiet dokumentacji technicznej, dzięki któremu działają one poprawnie i z reguły nigdy nie zawodzą.

Specyfikacja wymagań oprogramowania – oferta

Dokumentacja techniczna powinna zawierać:

– opis metod konstrukcyjnych

– charakterystykę materiałową

– notyfikację na temat projektowanych cech użytkowych danego wyrobu

– określenie warunków zastosowania wyrobu

– instrukcję obsługi

– instrukcję właściwej eksploatacji

Zależnie od przypadku zawartość dokumentacji technicznej może być ograniczona i obejmować tylko niektóre, najbardziej potrzebne dokumenty, np. recepturę, opis poszczególnych etapów procesu technologicznego, warunki techniczne, w których powinna przebiegać produkcja, itp.

Inne rodzaje dokumentacji związane z dokumentacją techniczną

Dokumentacja wdrożeniowa – sporządzana na potrzeby wprowadzenia produktu końcowego. Różni się ona od dokumentacji technicznej tym, że zawiera znacznie mniej informacji na temat wewnętrznych związków i elementów, ale obejmuje szczegółowy materiał dotyczący środowiska pracy produktu. Sporządzenie tego typu dokumentacji bywa niezbędne w przypadku, gdy wdrażaniem produktu zajmują się osoby, które na co dzień nie należą do zespołu projektowego.

Dokumentacja użytkownika – przeznaczona dla użytkowników końcowych. Dokument ten jest niezbędny w przypadku gdy rozwiązanie nie jest intuicyjne lub gdy sam przebieg pracy cechuje się wysokim stopniem skomplikowania i wymaga dodatkowej instrukcji.

Dokumentacja projektu – powstająca na podstawie dokumentacji funkcjonalnej i uwzględniająca opis użycia, procesy biznesowe i przepływ pracy w formie tekstu, obrazów i diagramów UML. W przypadku kiedy opis funkcjonalności jest skonstruowany w formie pisemnej można powołać na rynek wyrób, którego cechy odpowiadają wszystkim tezom projektu. Wymienić można wiele technik pozyskiwania wymagań funkcjonalnych, np. use cases (przypadek użycia) lub user stories (historie użytkowników). Nie ulega wątpliwości, że projekt sprowadzony do formy dokumentacji, w której ujęte są mniejsze moduły łatwiej wdrożyć.

Za wstępną formę dokumentacji przyszłego produktu IT uznaje się specyfikację projektu, która opisuje jego istotne cechy, koncepcję i zadania. Jest ona niezwykle istotna, kiedy mamy do czynienia z rozwiązaniami cechującymi się dużym zasięgiem, których poprawne wprowadzenie ma znaczący wpływ dla działalności całego przedsiębiorstwa. Staranne przedstawienie pracownikom wstępnego zarysu projektu sprawia, że współpraca z firmą, która wykonuje zlecenie przebiega sprawnie i bez zastrzeżeń. Warto więc wiedzieć jak sporządzić taką specyfikację i jakie informacje powinny się w niej znaleźć.

Definicja Specyfikacji Wymagań Oprogramowania

Specyfikacja Wymagań Oprogramowania (Software Requirements Specification, SRS) to przydatny dokument analityczny zawierający zarówno zidentyfikowane, jak i funkcjonalne i poza-funkcjonalne wymagania istotne dla użytkowników. W kompletnej formie przekazuje ona programistom w sposób precyzyjny i zrozumiały rzeczywiste założenia produktu, który powstaje na podstawie określonego projektu.

Podstawą SRS jest seria analitycznych wywiadów z klientami, menedżerami, udziałowcami, itp. Kolejny etap to analiza dokumentacji wraz z powiązanymi z projektem kwestiami prawnymi. Dzięki takiemu rozwiązaniu zespół może odnieść się do dokumentu, który ma za zadanie pomóc przygotować dobry jakościowo produkt.

Treść specyfikacji projektu

Na typową specyfikację składa się przede wszystkim ogólny opis projektu obejmujący zakres określonych działań. Uwzględnia ona również dodatkowe załączniki, np. linki prowadzące do tekstów, obrazów albo modeli. Niezbędne są również wymagania techniczne dla przygotowania produktu. Specyfikacja powinna wskazywać przeznaczenie oprogramowania (określenie urządzeń i systemów operacyjnych) oraz rodzaj integracji, z których może ono korzystać (np. CRM, system fakturowy, magazynowy, itp.). Najlepiej dokładnie opisać sposób działania tych połączeń i typ danych, które mają być między sobą wymieniane.

Zaprojektowanie całego systemu będzie łatwiejsze jeśli sprecyzuje się, który rodzaj danych wysyłanych na serwer krytycznie wpłynie na działanie aplikacji. Potrzebna będzie tutaj komunikacja warstwy wizualnej, którą użytkownik widzi w przeglądarce / aplikacji (front-end) z częścią serwerową, operacyjną (back-end).

W specyfikacji powinny znaleźć się również zaawansowane funkcje aplikacji, tzw. moduły składowe (akcje i informacje) oraz inne niestandardowe elementy dodatkowe niewchodzące w podstawowy zakres projektu. Są one związane zazwyczaj z pracą innych zatrudnionych podmiotów, które zajmują się np. obsługą hardware.

Specyfikacja projektu jest potrzebna

Praca nad projektem oprogramowania, aplikacji, systemów lub stron internetowych bez opracowania specyfikacji to nie najlepszy pomysł. Błąd ten wynika najczęściej z zaniedbań związanych z brakiem dostatecznego zaangażowania, nieodpowiedniego zaplanowania zadań lub postawienia na nieodpowiednie rozwiązania technologiczne i narzędzia. Głównym problemem bywa tutaj jednak niedostateczna komunikacja inwestora z wykonawcą. To wszystko wpływa na niemożność przygotowania dobrej dokumentacji projektu. Do tego typu sytuacji prowadzi zazwyczaj zachowanie klienta, który nie potrafi sformułować swoich oczekiwań, a najważniejsze założenia swojego produktu zachowuje dla siebie, nie dzieląc się nimi z zespołem wykonawczym. Warto pamiętać, że należy odpowiednio sformułować zadania i instrukcje w sporządzonej specyfikacji, ponieważ ma to szczególny wpływ na komunikację między klientem a wykonawcami i późniejszymi użytkownikami, co może negatywnie odbić się na wdrażanym później produkcie.

Co można zawrzeć w SRS?

Specyfikacja Wymagań Oprogramowania powinna być wynikiem nakreślenia głównych założeń całego projektu. W jej treści musi znaleźć się kilka ważnych aspektów uwzględniających cel opracowywanego oprogramowania, czy działanie interfejsów zewnętrznych. Pod uwagę bierze się również oczekiwania co do wydajności produktu, a także jego główne funkcje. W specyfikacji powinny znaleźć się zakładane usprawnienia, np. ułatwiające dostęp do pomocy technicznej lub zwiększające bezpieczeństwo użytkowników. Duże znaczenie mają też wytyczne inwestora, które mogą być związane np. z obowiązującymi w jego firmie standardami.

SRS – dlaczego warto?

Poprawnie sformułowana specyfikacja wymagań oprogramowania jest kompletnym źródłem wiedzy i solidnym fundamentem dla umowy, która powinna być zawarta przed rozpoczęciem pracy. Na jej podstawie można zaplanować terminy i koszty realizacji, a także znacząco ograniczyć konieczność przeprowadzania prac dodatkowych poprzez software house. Pomaga również zaplanować zespołowi pracę, określić własne wymagania i oczekiwania oraz ograniczyć do minimum konieczność edytowania i wprowadzania korekty w kodzie. Specyfikacja służy również inwestorowi do przedstawienia własnego pomysłu dotyczącego interfejsu oprogramowania, łącznie z uwzględnieniem szczegółowego opisu każdego modułu. Doskonale sprawdza się tutaj zaprojektowanie ścieżek działań dla użytkowników, które pomagają poznać oczekiwania klientów dotyczące np. funkcjonalności.