SPECYFIKACJA WYMAGAŃ

Podobne dokumenty
<Nazwa firmy> <Nazwa projektu> Specyfikacja wymagań projektu. Wersja <1.0>

<Nazwa firmy> <Nazwa projektu> Specyfikacja dodatkowa. Wersja <1.0>

Zasady organizacji projektów informatycznych

Spis treúci. 1. Wprowadzenie... 13

Projekt aplikacji internetowej specyfikacja wymagań (cz.1)

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017

Inżynierski Projekt Zespołowy

Diagramy przepływu danych I

UML cz. III. UML cz. III 1/36

Dokument Detaliczny Projektu

Podrozdziały te powinny zawierać informacje istotne z punktu widzenia przyjętego celu pracy

MODELOWANIE SYSTEMU INFORMATYCZNEGO WSPOMAGAJĄCEGO DZIAŁALNOŚĆ USŁUGOWĄ W ŚRODOWISKU OBIEKTOWO ZORIENTOWANYM.

Diagramy przypadków użycia. WYKŁAD Piotr Ciskowski

PROJEKT INTERFEJSU UśYTKOWNIKA PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

SPECYFIKACJA WYMAGAŃ

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu

Inżynieria oprogramowania II

Jak opisać wymagania zamawiającego wybrane elementy

MiASI. Modelowanie systemów biznesowych. Piotr Fulmański. 7 stycznia Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska

Jerzy Skalski s9473, grupa WIs I.6-11c. System wspierający obsługę klienta dla firm sprzedających na Allegro

Załącznik nr 1. Do zapytania ofertowego nr 1/UE/2013

Dokument Detaliczny Projektu

Diagram przypadków użycia

Projektowanie oprogramowania

Aplikacja serwerowa Platformy Prezentacyjnej Opis produktu

FORMULARZ OFERTOWY. 8. Społeczeństwo informacyjne zwiększanie innowacyjności gospodarki

Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Innowacyjna Gospodarka

Łódź, dnia r. DOA-ZP-I

Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło

INFORMATYCZNE SYSTEMY ZARZĄDZANIA

INFORMATYCZNE SYSTEMY ZARZĄDZANIA

Metodyka wdrożenia. Bartosz Szczęch. Starszy Konsultant MS Dynamics NAV

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Mechatronika i inteligentne systemy produkcyjne. Modelowanie systemów mechatronicznych Platformy przetwarzania danych

Wykład 1 Inżynieria Oprogramowania

ZAPYTANIE OFERTOWE. Zamawiający. Przedmiot zapytania ofertowego. Wrocław, dnia r.

KONTROLA JAKOŚCI Zapewnienie jakości w projekcie tworzenia oprogramowania

Diagramy przypadków użycia

Szablon Planu Testów Akceptacyjnych

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

M O N I T O R I N G

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

Warszawa, dnia 4 maja 2010r. Wykonawcy ubiegający się o udzielenie zamówienia publicznego

Podstawy inżynierii oprogramowania

PROJEKT Z BAZ DANYCH

Specyfikacja usług. 1. Zakup usług informatycznych dla realizacji dostępu do systemu dla obsługi relacji B2B.

OPIS PRZEDMIOTU ZAMÓWIENIA

1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI

ZAMAWIAJĄCY. CONCEPTO Sp. z o.o.

PRZEDMIOT ZAMÓWIENIA 1. Przedmiotem zamówienia jest budowa, dostawa, konfiguracja, wdrożenie i uruchomienie zintegrowanego systemu zarządzania

Projektowanie oprogramowania

Aplikacja (oprogramowanie) będzie umożliwiać przygotowanie, przeprowadzenie badania oraz analizę wyników według określonej metody.

Galileo - encyklopedia internetowa Plan testów

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

PRZEWODNIK PO PRZEDMIOCIE

ZAPYTANIE OFERTOWE. nr 1/UE/2014. z dnia r. w związku z realizacją projektu pn.

Specyfikowanie wymagań przypadki użycia

PolishAPI. Proces zarządzania zmianami. Dokument opracowany przez Grupę Projektową ds. PolishAPI. 24 czerwca 2019 Wersja 1.1


Michał Adamczyk. Język UML

Specyfikacja Wymagań. System Obsługi Zgłoszeń Serwisowych Polfa Warszawa S.A. Załącznik nr 1

Dokument Detaliczny Projektu Temat: Księgarnia On-line Bukstor

Faza Określania Wymagań

Specyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach)

Modelowanie i analiza systemów informatycznych

INŻYNIERIA OPROGRAMOWANIA. laboratorium

Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1

Uniwersytet w Białymstoku Wydział Ekonomiczno-Informatyczny w Wilnie SYLLABUS na rok akademicki 2012/2013

Plan zarządzania projektem

Sukces vs porażka. Sukces. Porażka

Cele przedsięwzięcia

HARMONOGRAM WARSZTATÓW z Zarządzania treścią strony internetowej w systemie CMS

Załącznik Nr 1. Istotne warunki zamówienia do przetargu nieograniczonego na wykonanie pakietu usług programistycznych

Metodyka projektowania komputerowych systemów sterowania

System generacji raportów

MiASI. Modelowanie analityczne. Piotr Fulma«ski. 18 stycznia Wydziaª Matematyki i Informatyki, Uniwersytet Šódzki, Polska

1. Zakres modernizacji Active Directory

Zapytanie ofertowe. I. Przedmiot zamówienia specyfikacja zgodnie z załącznikiem nr 1 do zapytania

Tytuł pracy: PRACA MAGISTERSKA AUTOR: KRAKÓW, Marzec 2011 Promotor pracy :

Modelowanie i Programowanie Obiektowe

Usługa: Testowanie wydajności oprogramowania

PRZEWODNIK PO PRZEDMIOCIE

Aplikacje internetowe i mobilne w zarządzaniu

Egzamin / zaliczenie na ocenę*

Tworzenie warstwy zasobów projektowanie metodą strukturalną

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

Automatyczne decyzje kredytowe, siła szybkiego reagowania i optymalizacji kosztów. Roman Tyszkowski ING Bank Śląski S.A. roman.tyszkowski@ingbank.

Jarosław Żeliński analityk biznesowy, projektant systemów

Ełk, dn r. DOMSET Marcin Brochacki. ul. Wojska Polskiego 43 lok. 3, Ełk. Nip ZAPYTANIE OFERTOWE

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.

1. Prace rozwojowe usługi informatyczne w zakresie opracowania prototypu oprogramowania serwisowo-instalatorskiego dla systemu testowego

III ZAPYTANIE OFERTOWE

Szczególne problemy projektowania aplikacji internetowych. Jarosław Kuchta Projektowanie Aplikacji Internetowych

DOTACJE NA INNOWACJE

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Wstęp, czyli jak, kto i dlaczego? Jak zorganizowany jest ten kurs? Dlaczego taka forma?... 7

Transkrypt:

<Nazwa systemu> <data> SPECYFIKACJA WYMAGAŃ <nazwa_tworzonego_systemu> Autorzy: <autor1> <email1> <autor2> <email2> <...> Wersja: <numer_wersji_dokumentu>

2 Historia zmian dokumentu Osoba <imię oraz nazwisko osoby wprowadzającej zmianę> Data <data wprowadzenia zmiany> Komentarz <komentarz do wprowadzonej zmiany> Wersja <numer wersji dokumentu po wprowadzonej zmianie>

Spis treści Wprowadzenie Cel dokumentu 2. Przyjęte zasady i konwencje 3. Literatura 2. Opis ogólny 2. Perspektywa produktu 2.2. Funkcje produktu 2.3. Ograniczenia 2.4. Dokumentacja użytkownika 2.5. Założenia i zależności 3. Model procesów biznesowych 3. Aktorzy i charakterystyka użytkowników 3.2. Obiekty biznesowe 3.3. Procesy biznesowe 3.4. Reguły biznesowe 4. Wymagania funkcjonalne 4.x. <Nazwa MODUŁU funkcjonalnego> 4.x. Opis i priorytet 4.x.2. Przypadki użycia 5. Charakterystyka interfejsów 5. Interfejs użytkownika 5.2. Interfejsy zewnętrzne 5.2. Interfejsy sprzętowe 5.2.2. Interfejsy programistyczne 5.2.3. Interfejsy komunikacyjne 6. Wymagania pozafunkcjonalne 7. Inne wymagania 3 3

4 Wprowadzenie Cel dokumentu W tym rozdziale należy określić produkt lub aplikację, której dotyczy ten dokument. Jest to również miejsce dla pełnej listy potencjalnych czytelników dokumentu. Należy opisać sposób, w jaki dokument ten jest skonstruowany oraz gdzie należy szukać określonych informacji. 2. Przyjęte zasady i konwencje Aktorzy - Ux - użytkownicy (x = 1.. n) - Sx - systemy Przypadki użycia - BCx - biznesowe - UCx - użytkownika - UFx - podfunkcji Poziomy priorytetów - bardzo ważny (80-100%> - ważny (60-80%> - średnio ważny (40-60%> - mało ważny (20-40%> - bardzo mało ważny <0-20%> Opis aktorów: ID: <nazwa aktora> <opis> Opis obiektu biznesowego: <nazwa obiektu> <opis> Opis dokumentacji: <nazwa dokumentu> Zawartość: <zawartość dokumentu> Standardy: <standardy> Format: <format> Język: <język>

5 Opis procesu biznesowego: ID: <tytuł procesu biznesowego> Główni aktorzy: Wspierający aktorzy: Poziom: biznesowy Wyzwalacze: Warunki wstępne: Warunki końcowe: Artefakty wejściowe: Artefakty wyjściowe: Prolog: Główny scenariusz: Alternatywny scenariusz i rozszerzenia: Wyjątki: Dodatkowe wymagania: Opis reguły biznesowej: ID Definicja Rodzaj Źródło <id> <zakres reguły> <fakt, ograniczenie, wyzwalacz, propozycja, obliczenia> <dynamiczne, statyczne> 5

6 Opis przypadku użycia (wymagania funkcjonalne): ID: <nazwa przypadku użycia> Główni aktorzy: Wspierający aktorzy: Poziom: {użytkownik, system} Priority: <priorytet> Wyzwalacze: Warunki wstępne: Warunki końcowe: Główny scenariusz: Alternatywny scenariusz i rozszerzenia: Wyjątki: Dodatkowe wymagania: Opis wymagań niefunkcjonalnych: ID: <nazwa> Priorytet: <priorytet> Trudność: <trudność> 3. Literatura W miejscu tym należy zamieścić listę dokumentów lub innych zasobów, do których specyfikacja wymagań się odwołuje. 2. <...> <...>

7 2. Opis ogólny 2. Perspektywa produktu Rozdział ten służy przedstawieniu ogólnej perspektywy tworzonego systemu, jego otoczenia oraz genezy. Mile widziany jest diagram kontekstowy prezentujący aktorów w interakcjach z systemem. 2.2. Funkcje produktu W rozdziale tym należy przedstawić przegląd i ogólny opis kluczowych funkcji tworzonego produktu. 2.3. Ograniczenia Ten rozdział powinien przedstawiać wszystkie ograniczenia, które zawężają swobodę wykonawcy w zakresie sposobu realizacji produktu. Do ograniczeń implementacyjnych należą na przykład: ograniczenie środowiskowe, komunikacyne, bazodanowe itp. Ograniczenie projektowe dotyczą m.in. czasu realizacji. 2.4. Dokumentacja użytkownika Rozdział służy opisowi wymagań dotyczących dokumentacji użytkownika tworzonego systemu, która powinna zostać dostarczone wraz z systemem. Do opisu dokumentacji wykorzystujemy wzorzec z punktu 2.: <nazwa dokumentu> Zawartość: <zawartość dokumentu> Standardy: <standardy> Format: <format> Język: <język> 2.5. Założenia i zależności W rozdziale tym należy przedstawić założenia (np. czy aplikacja lokalna/internetowa, dostęp ograniczony/nieograniczony, przez kogo itd.) i czynniki mające wpływ na przedstawione w dokumencie wymagania (np. pobieranie danych uzależnione od webserwisu). Założenia: <...> Zależności: <...> 7

8 3. Model procesów biznesowych 3. Aktorzy i charakterystyka użytkowników W rozdziale tym należy przedstawić charakterystyki poszczególnych aktorów oraz klas użytkowników końcowych. Szablon opisu aktora tożsamy z wzorcem w punkcie 2.: ID: <nazwa aktora> <opis> 3.2. Obiekty biznesowe W rozdziale tym należy przedstawić opisy poszczególnych obiektów biznesowych. Szablon opisu obiektu biznesowego, jak w punkcie 2.: <nazwa obiektu> <opis> 3.3 Procesy biznesowe Rozdział ten jest miejscem opisu procesów biznesowych. Szablon, jak w punkcie 2. ID: <tytuł procesu biznesowego> Główni aktorzy: Wspierający aktorzy: Poziom: biznesowy Wyzwalacze: Warunki wstępne: Warunki końcowe:

9 Artefakty wejściowe: Artefakty wyjściowe: Prolog: Główny scenariusz: Alternatywny scenariusz i rozszerzenia: Wyjątki: Dodatkowe wymagania: 3.4. Reguły biznesowe: Zawieramy tutaj informacje o regułach biznesowych. Szablon, jak w punkcie 2. ID Definicja Rodzaj Źródło <id> <zakres reguły> <fakt, ograniczenie, wyzwalacz, propozycja, obliczenia> <dynamiczne, statyczne> 9

10 4. Wymagania funkcjonalne Rozdział zawiera spis wymagań funkcjonalnych dla tworzonego produktu informatycznego. Do opisu wymagań funkcjonalnych wykorzystujemy szablony przypadków użycia: 4.x. <Nazwa MODUŁU funkcjonalnego> Nazwa modułu może być wyznaczona przez określenie aktora, którego dotyczyć będą podległe wymagania funckjonalne (x enumeracja modułów): 4.x. Opis i priorytet W miejscu tym należy umieścić krótki przegląd funkcji wchodzących w skład opisywanego modułu funkcjonalnego. 4.x. 2. Przypadki użycia W tej sekcji opisane są przypadki użycia związane z danym modułem, zgodnie z szablonem w punkcie 2. ID: <nazwa przypadku użycia> Główni aktorzy: Wspierający aktorzy: Poziom: {użytkownik, system} Wyzwalacze: Warunki wstępne: Warunki końcowe: Główny scenariusz: Alternatywny scenariusz i rozszerzenia: Wyjątki: Dodatkowe wymagania: Priority: <priorytet>

11 5. Charakterystyka interfejsów W tym rozdziale należy przedstawić wymagania odnośnie interfejsów, z jakimi tworzone oprogramowanie ma się komunikować, lub jakie powinno udostępniać. 5. Interfejs użytkownika W rozdziale tym należy opisać wymagania dotyczące interfejsu użytkownika w tworzonym oprogramowaniu. Do opisu wymagań dotyczących interfejsu użytkownika można wykorzystać szablon: ID Wymaganie <treść wymagania> Priorytet <priorytet> 5.2. Interfejsy zewnętrzne Rozdział ten służy opisowi interfejsów zewnętrznych, z którymi tworzony system ma współpracować. Określamy tutaj charakterystykę, podstawowe informacje o sprzęcie serwerowym, środowisku uruchomieniowym, a także interfejsach komunikacji. 5.2. Interfejsy sprzętowe 5.2.2. Interfejsy programistyczne 5.2.3. Interfejsy komunikacyjne 11

12 6. Wymagania pozafunkcjonalne Jest to miejsce opisy wymagań pozafunkcjonalnych tworzonego systemu. Następujący szablon może zostać wykorzystany do specyfikacji wymagań pozafunkcjonalnych (jak w punkcie 2.): ID: <nazwa> Priorytet: <priorytet> Trudność: <trudność>

13 7. Inne wymagania W rozdziale tym należy umieścić wymagania, które nie pasują do żadnego z pozostałych rozdziałów specyfikacji wymagań. 13