Co zawiera specyfikacja programu ?

0. Wprowadzenie 1. Opis ogólny 2. Wymagania funkcjonalne Opis ogólny Nowe pojęcia i ich znaczenie Podobne funkcje Podobne potrzeby Potencjalne konflikty 3. Opis funkcji od strony użytkownika Zmiany ekranu Zmiany zestawień Aspekty użyteczności 4. Potencjalne problemy i alternatywy 5. Rozwiązania wewnętrzne Architektura oprogramowania Podstawowe algorytmy Zmiany w modelu danych Obsługa błędów i sytuacji wyjątkowych 6. QA Aspekty poprawności, niezawodności, bezpieczeństwa 7. Dokumentowanie nowej funcji 8. Zależność od polityki nowych wydań, wersji, aktualizacji ? 9. Tematy powiązane Patrz też dalej: Brief projektowy 10. Dodatek: Brief projektowy 10.1 Brief projektowy. Charakterystyka 10.2 Brief projektowy a specyfikacja oprogramowania ************************************************************************

0. Wprowadzenie

Specyfikacja oprogramownia

W ujęciu ogólnym: Specyfikacja to jest dokładny, formalny opis wymagań dotyczących jakiegoś produktu, usługi, procesu lub systemu. Zawiera ona precyzyjne informacje i standardy, które muszą być spełnione, aby dany element był uznany za zgodny ze specyfikacją. Specyfikacja oprogramowania, specyfkacja wymagań (en: Program Specification) to jest dokument opisujący, co oprogramowanie będzie robić i jakie będzie oczekiwane działanie. Opisuje także funkcjonalność, jakiej potrzebuje produkt, aby zaspokoić potrzeby wszystkich użytkowników. Specyfikacja oprogramowania jest elementem dokumentacji, która towarzyszy powstawaniu systemu informatycznego. W szczególności, realizacja zleconej funkcjonalności odbywa się w oparciu o uzgodnioną specyfikację. Patrz: RI Rozwiązania indywidualne. Kastomizacja RI Rozwiązania indywidualne

Dokumentacja systemu. Elementy

* Analiza biznesowa Business Req Specification * Analiza systemowa System Req Specification * Projekt ogólny High Level Design * Projekt szczegółowy Low Level Design * Kodowanie Coding

1. Opis ogólny

Jakie problemy lub potrzeby chce się rozwiązać ?

2. Wymagania funkcjonalne

Zestawienie (lista)

Jakie funkcje ma realizować program ?

Nowe pojęcia i definicje

Opis nowych pojęć i znaczeń, które będą używane w programie Czy nowe pojęcia i znaczenia mają powiązanie z już używanymi ?

Podobne funkcjonalności

Jakie podobne funkcje już są w programie ?

Podobne oczekiwania (wymagania)

Jakie potrzeby, podobne do opisywanej, zostały zgłoszone

Potencjalne konflikty

Z jakimi już istniejącymi funkcjami, ta projektowana może być w konflikcie Jak uniknąć konfliktu ?

3. Funkcjonalność w 'oczach' użytkowników

Jak nowa funkcja będzie widziana i używana przez użytkownika

Ekrany, formatki. Projektowane zmiany

Jakie będą nowe ekrany, jakie zmiany istniejących ekranów ? Opisać elementy ekranów, ich znaczenie i funkcje Opisać pola, przyciski, funkcje myszy, klawiszy, itd.

Reporty. Zestawienia. Projektowane zmiany

Opisać nowe lub zmienione zestawienia (wydruki, raporty)

Użyteczność rozwiązania

W jakim stopniu nowa funkcja wpłynie na użyteczność istniejących funkcji Jakie nowe nieoczekiwane sytuacje czekają użytkownika. Jak program pomoże użytkownikowi w nieoczekiwanej sytuacji ?

4. Problemy i alternatywy

Jakie problemy może stwarzać nowa funkcja Jakie można zastosować inne rozwiązania, aby uniknąć problemów Jakie są Pro i Con tych rozwiązań ? Jakie wnioski ?

5. Szczegóły projektowe

Architektura oprogramowania

Ogólny opis wewnętrznej struktury funcji. Jakie elementy, jakie powiązania

Podstawowe algorytmy

Opisać podstawowe algorytmy. Jeżeli opis jest w pseudo-kodzie, to linia nie powinna zawierać więcej niż 80 znaków

Model bazy danych

Jakie są niezbędne zmiany w bazie danych ? Nowe zbiory (tabela), pola (kolumny), widoki (views) ?

Obsługa błędów

Jakie mogą wystąpić błędy ? Jaka będzie strategia reagowania na błędy, tak aby użytkownika nie obarczać koniecznością ich rozwiązywania ?

6. Kwestie jakości rozwiązań

Czy wymagane są specjalne narzędzia do testowania ? Czy trzeba przygotować dane do testowania ? Które obszary programu wymagają specjalnej uwagi ?

7. Kwestie dokumentacji

Jaka dokumentacja powinna towarzyszyć rozwiązaniu ?

8. Polityka wydań i aktualizacji

Zależność od polityki nowych wydań, wersji, aktualizacji ? Otoczenie funkcji może się zmieniać. Jak synchronizować rozwój funkcji standardowych z rozwojem tego rozwiązania

9. Tematy powiązane

RI Rozwiązania indywidualne Usługi Tres. Opis ogólny Konfiguracja programu Procesy gospodarcze Baza danych. Słownik Utrzymanie instalacji IT

10. Dodatek: Brief projektowy

10.1 Brief projektowy. Charakterystyka

Co to jest brief projektowy ?

Brief projektowy to dokument, który zawiera kluczowe informacje dotyczące projektu i służy jako punkt wyjścia dla zespołu pracującego nad projektem. Jest to narzędzie komunikacyjne, które pomaga w zrozumieniu celów, oczekiwań i zakresu projektu, zarówno dla klientów, jak i dla zespołu projektowego.

Elementy briefu projektowego

* Opis projektu: Krótkie wprowadzenie do projektu, jego tło i kontekst. * Cele projektu: Jasne określenie, co projekt ma osiągnąć. * Zakres projektu: Szczegółowy opis, co jest zawarte w projekcie, a co nie. * Grupa docelowa: Informacje o odbiorcach końcowych projektu. * Wymagania techniczne: Specyfikacje techniczne i narzędzia, które będą używane. * Harmonogram: Terminy realizacji poszczególnych etapów projektu. * Budżet: Dostępne środki finansowe na realizację projektu. * Kluczowe punkty kontaktowe: Osoby odpowiedzialne za poszczególne aspekty projektu.

Przykład struktury briefu projektowego

* Opis projektu Projekt obejmuje stworzenie nowej strony internetowej dla firmy XYZ. Strona ma być responsywna, nowoczesna i łatwa w nawigacji. * Cele projektu Zwiększenie liczby konwersji (np. zakupów, rejestracji) * Zakres projektu Projekt graficzny strony Kodowanie i wdrożenie strony Testowanie i optymalizacja Szkolenie zespołu do zarządzania stroną * Grupa docelowa Osoby w wieku 25-45 lat, zainteresowane produktami firmy XYZ Przedsiębiorcy szukający rozwiązań oferowanych przez firmę * Wymagania techniczne Strona musi być responsywna i działać na wszystkich urządzeniach Integracja z systemem CRM firmy ... Optymalizacja pod kątem SEO * Harmonogram Start projektu: 1 luty 20xx Zakończenie projektu: 1 maj 20xx * Budżet Całkowity budżet na projekt wynosi ..... PLN. * Kluczowe punkty kontaktowe Kierownik projektu: Jan Nowak Grafik: Anna Kowalska Programista: Piotr Wiśniewski Taki dokument pozwala na jasne zrozumienie wymagań i celów projektu, co zwiększa szanse na jego sukces.

10.2 Brief projektowy a specyfikacja oprogramowania

Czy wymienione elementy briefu powinny być także elementami specyfikacji oprogramowania ? Elementy briefu projektowego mogą częściowo pokrywać się z elementami specyfikacji oprogramowania, ale specyfikacja oprogramowania zazwyczaj jest bardziej szczegółowa i techniczna. Brief projektowy jest dokumentem o ogólnym zakresie, który zawiera ogólne cele i założenia projektu, natomiast specyfikacja oprogramowania skupia się na szczegółowych wymaganiach technicznych i funkcjonalnych, które muszą być spełnione.

Elementy wspólne dla briefu projektowego i specyfikacji oprogramowania

* Opis projektu: Krótkie wprowadzenie do projektu i jego kontekst. * Cele projektu: Co projekt ma osiągnąć. * Zakres projektu: Co jest zawarte w projekcie, a co nie. * Wymagania techniczne: Specyfikacje techniczne i narzędzia, które będą używane. * Harmonogram: Terminy realizacji poszczególnych etapów projektu. * Kluczowe punkty kontaktowe: Osoby odpowiedzialne za poszczególne aspekty projektu.

Dodatkowe elementy specyfikacji oprogramowania

* Funkcjonalności: Szczegółowy opis funkcjonalności, które ma mieć oprogramowanie. * Wymagania niefunkcjonalne: Wymagania dotyczące wydajności, bezpieczeństwa, skalowalności, itp. * Diagramy i modele: Diagramy przypadków użycia, diagramy przepływu danych, modele klas, itp. * Interfejs użytkownika: Opis interfejsu użytkownika i interakcji. * Integracje: Wymagania dotyczące integracji z innymi systemami. * Testowanie i walidacja: Procedury testowania, wymagania dotyczące testów akceptacyjnych. * Zarządzanie wersjami: Informacje o zarządzaniu wersjami oprogramowania i aktualizacjach. * Dokumentacja użytkownika: Opis dokumentacji, która będzie dostarczona razem z oprogramowaniem.

Przykład struktury specyfikacji oprogramowania

* Opis projektu Projekt obejmuje stworzenie nowej strony internetowej dla firmy XYZ, która będzie responsywna i nowoczesna. * Cele projektu Zwiększenie widoczności firmy w internecie Poprawa doświadczeń użytkowników Zwiększenie liczby konwersji * Zakres projektu Projekt graficzny strony Kodowanie i wdrożenie strony Testowanie i optymalizacja Szkolenie zespołu do zarządzania stroną * Wymagania funkcjonalne Strona główna z dynamicznymi treściami Formularz kontaktowy System zarządzania treścią (CMS) Integracja z CRM * Wymagania niefunkcjonalne Responsywność na różnych urządzeniach Wysoka wydajność (czas ładowania strony poniżej 3 sekund) Bezpieczeństwo danych użytkowników * Diagramy i modele Diagram przypadków użycia Diagram przepływu danych * Interfejs użytkownika Mockupy i prototypy interfejsu użytkownika * Integracje Integracja z systemem CRM * Testowanie i walidacja Testy jednostkowe Testy integracyjne Testy akceptacyjne * Harmonogram Start projektu: 1 luty 20xx Zakończenie projektu: 1 maj 20xx * Zarządzanie wersjami Plan wydania wersji Procedury aktualizacji * Dokumentacja użytkownika Podręcznik użytkownika Dokumentacja techniczna * Kluczowe punkty kontaktowe Kierownik projektu: Jan Nowak Grafik: Anna Kowalska Programista: Piotr Wiśniewski Specyfikacja oprogramowania jest bardziej szczegółowa i techniczna niż brief projektowy, dlatego oba dokumenty pełnią różne, ale komplementarne role w procesie tworzenia oprogramowania.