1 Inżynieria systemów informacyjnychWYKŁAD I dr inż. Krzysztof Michalak

2 Plan wykładu Tematy wykładów Literatura przedmiotu Zasady zaliczeniaPodstawowe definicje

3 Tematy wykładów Wykład I – sprawy organizacyjne, podstawowe definicje w zakresie systemów informacyjnych Wykład II – zarządzanie wymaganiami Wykład III – zarządzanie wymaganiami Wykład IV – modelowanie procesów biznesowych BPMN Wykład V – modelowanie procesów biznesowych BPMN Wykład VI – Elementy UML’a Wykład VII – metodyki prowadzenia projektów Prince2, Agile, Scrum Wykład VIII – zaliczenie wykładów termin 0

4 Literatura „Inżynieria systemów informacyjnych” Paul Beynon-Davies„Oprogramowanie szyte na miarę. Jak rozmawiać z klientem, który nie wie, czego chce” Michał Bartyzel „Zrozumieć BPMN modelowanie procesów biznesowych” Szymon Drejewicz „Język UML 2.0 w modelowaniu systemów informatycznych” Stanisław Wrycza, Bartosz Marcinkowski, Krzysztof Wyrzykowski

5 Zasady zaliczenia przedmiotuLaboratoria Wejściówki Dokumentacja projektowa systemu informatycznego Wykłady Egzamin pisemny w formie testu wyboru Ocena za przedmiot (ocena z wykładów + ocena z laboratoriów)/2

6 Podstawowe pojęcia System System informacyjny System informatycznyDane Informacja Projekt Uzasadnienie biznesowe Wymagania

7 Podstawowe pojęcia – SystemPodejście filozoficzne Systemem to zbiór tez i twierdzeń stanowiących pewną spójną całość ale również zasady organizacji czegoś – zbiór przepisów lub reguł obowiązujących w danej dziedzinie. Podejście psychologiczne Systemem jest nazywany zbiór elementów, powiązanych ze sobą relacjami w taki sposób, że stanowią one całość zdolną do funkcjonowania w określony sposób. Podejście cybernetyczne System jest to zbiór elementów i zachodzących między nimi relacji.

8 Podstawowe pojęcia – SystemSystem – obiekt fizyczny lub abstrakcyjny, w którym można wyodrębnić zespół lub zespoły elementów wzajemnie powiązanych w układy, realizujących jako całość funkcję nadrzędną lub zbiór takich funkcji (funkcjonalność). Z uwagi na fakt, że wyodrębnienie wszystkich elementów przynależących do systemu bywa w praktyce niekiedy bardzo trudne, do badania systemów wykorzystuje się modele uproszczone. Elementy przynależące do jednego systemu nie mogą jednak stanowić jednocześnie elementów przynależnych do innego systemu.

9 Podstawowe pojęcia – SystemSystem jest układem wzajemnie powiązanych elementów. Powiązanie elementów polega na oddziaływaniu jednego konkretnego elementu na inne elementy. Analizując system jako układ widzimy pewną strukturę sprzężeń szeregowych i zwrotnych. Cybernetyka definiuje system jako układ: składający się z wielu elementów, strukturalnie zróżnicowany szczególnie złożony sprzężony, sterowalny, dynamiczny – podlegający zmianom w czasie, ultrastabilny,

10 Podstawowe pojęcia – System informacyjnyW teorii zarządzania system informacyjny to zespół środków materialnych, finansowych, algorytmów i ludzi, zapewniający sprawne zarządzanie przedsiębiorstwem. Ekonomika informacji definiuje system informacyjny jako kompleks powiązanych ze sobą procesów informacyjnych. System informacyjny jest specyficznym systemem społeczno-gospodarczym, w którym obok procesów informacyjnych zawsze występują zasoby oraz informacja.

11 Podstawowe pojęcia – System informacyjnySystem informacyjny jest wielopoziomową strukturą, która pozwala użytkownikowi takiego systemu na transformowanie określonych informacji wejścia na pożądane informacje wyjścia za pomocą odpowiednich modeli i procedur (Kisielnicki, Sroka). SI = {P, I, T, O, M, R} SI – system informacyjny P – zbiór podmiotów użytkujących dany system I – zbiór informacji o sferze realnej T – zbiór narzędzi technicznych O – zbiór rozwiązań systemowych stosowanych w danej organizacji (stosowana formuła zarządzania) M – zbiór metainformacji

12 Podstawowe pojęcia – System informacyjnyWedług Paula Beynon-Davies’a systemy można podzielić na trzy grupy: Techniczne, Formalne, Nieformalne.

13 Podstawowe pojęcia – System informacyjnyFormalny system informacyjny - W formalnych systemach informatycznych określone są zasady działania, a kontrola jest wykonywana z pomocą formalnej hierarchii. Komunikacja w takich systemach z reguły odbywa się w kierunku pionowym, informacje niezbędne do podjęcia decyzji przekazywane są w „górę”, a decyzje przekazywane są w „dół”. Formalne systemy informacyjne występują w przedsiębiorstwach. Stopień ich sformalizowania jest bardzo różny, zależny od wielu czynników. Komunikacja w formalnych systemach we współczesnych przedsiębiorstwach odbywa się w różnych kierunkach.

14 Podstawowe pojęcia – System informacyjnyNieformalny system informacyjny - zbiór oczekiwań co do sposobu komunikowania się ludzi w pewnych okolicznościach. Techniczny system informacyjny - reprezentacja części formalnego systemu informacyjnego przy użyciu technologii informacyjnej. Techniczny system informacyjny to inaczej system informatyczny

15 Podstawowe pojęcia – SystemPodstawowe pojęcia – System informacyjny Otoczenie systemu System granice systemu U2(a2,a3) U1(a1) Wejście, zasilenie Wyjście U3(a4,a5,a6)

16 Podstawowe pojęcia – System informacyjnySystemem informacyjnym  nazywamy parę: Obiektów (U – uniwersum) Atrybutów (A – atrybuty) SI=(A,U) Prezentacja systemu informacyjnego w postaci tablicy SI = (U,A) A1 A2 A3 U1 1950cm3 9l/100km 8,4s U2 1758cm3 7,5l/100km 10,1s U3 1645cm3 5,7l/100km 12,0s U4 1490cm3 4,5l/100km 14,5s

17 Podstawowe pojęcia – System informacyjnyCzy to jest prezentacja systemu informacyjnego ???

18 Podstawowe pojęcia – System informatycznySystem informatyczny – zbiór powiązanych ze sobą elementów, którego funkcją jest przetwarzanie danych przy użyciu techniki komputerowej. System informatyczny – reprezentacja części formalnego systemu informacyjnego przy użyciu technologii informacyjnej (techniczny system informacyjny – Beynon Davies).

19 Podstawowe pojęcia – System informatycznyFormalnie system informatyczny danej organizacji można przedstawić w postaci złożenia siedmiu uporządkowanych elementów : SI = {P, I, T, O, M, R, N} P – personel korzystający z systemu I – dane i informacje T – zbiór urządzeń i narzędzi technologii informatycznej O – zbiór stosowanych rozwiązań organizacyjnych M – zbiór metainformacji R – relacje pomiędzy elementami systemu informatycznego N – infrastruktura i otoczenie systemu informatycznego

20 Podstawowe pojęcia – System informatycznyPersonel korzystający z systemu – P = {Pz, Pi, Pu} personel szczebla zarządzającego i kierowniczego. personel informatyczny. pozostali użytkownicy systemu informatycznego. Dane i informacje – I = {Ie, Ip, Im} zasoby informacyjne w postaci elektronicznej. zasoby informacyjne w postaci papierowej. zasoby informacyjne w postaci wiedzy określonych osób. Zbiór urządzeń i narzędzi technologii informatycznej – T = {Ts, To, Tk} sprzęt (urządzenia komputerowe) oprogramowanie telekomunikacja

21 Podstawowe pojęcia – System informatycznyZbiór stosowanych rozwiązań organizacyjnych – O = {Os, Oz, Or, Op, Ob, … } strategia rozwoju systemu informatycznego zarządzenia, rozporządzenia i wytyczne regulujące kwestie związane z utworzeniem, funkcjonowaniem i rozwojem systemu informatycznego. regulaminy dotyczącego zasad użytkowania systemu. procedury ochronne i procedury awaryjne. dokument polityki bezpieczeństwa. Zbiór metainformacji – M = {Me, Mp, Mm} metainformacje w postaci elektronicznej. metainformacje w postaci papierowej. metainformacje zgromadzone w pamięci osób.

22 Podstawowe pojęcia – System informatycznyRelacje pomiędzy elementami systemu informatycznego – R = {Rp-p, Rp-t, Rt-i, Rp-i} relacje pomiędzy personelem systemu. relacje pomiędzy personelem systemu a urządzeniami technologii informatycznej. relacje pomiędzy urządzeniami a zasobami informacyjnymi. relacje pomiędzy personelem a zasobami informacyjnymi Infrastruktura i otoczenie systemu informatycznego – N = {Nw, Nz, Nw-z} infrastruktura wewnętrzna przedsiębiorstwa infrastruktura zewnętrzna przedsiębiorstwa relacja pomiędzy infrastrukturą wewnętrzna a zewnętrzną przedsiębiorstwa

23 Podstawowe pojęcia – Klasyfikacja systemów informatycznychKlasyfikacja SI według zadań realizowanych przez system Systemy biurowe Systemy inżynierskie Systemy wspierające zarządzanie

24 Podstawowe pojęcia – Klasyfikacja systemów informatycznychSystemy biurowe Systemy powszechnego użytku Edytory tekstu Arkusze kalkulacyjne Bazy danych Systemy pracy grupowej (Groupware) Poczta elektroniczna Terminarze grupowe Systemy wspierające zarządzanie projektami Systemy zarządzania obiegiem dokumentów (Workflow) Grupowa praca nad dokumentami Sterowany i kontrolowany obieg dokumentów i czynności Systemy inżynierskie Systemy CAD/CAM (Computer Aided Design/Manufacturing) Systemy informacji przestrzennej GIS (Geographical Information Systems) Systemy CASE (Computer Aided Software Engineering)

25 Podstawowe pojęcia – Klasyfikacja systemów informatycznychSystemy informacyjne wspierające zarządzanie Systemy transakcyjne (Trascaction Processing Systems – TPS) Systemy nowoczesnego biura (Office Automation Systems – OAS) Systemy informacyjne zarządzania (Management Information Systems – MIS) Systemy wspomagania decyzji (Decision Support Systems – DSS) Systemy informacyjne kierownictwa (Executive Information Systems – EIS) Systemy wspomagające kierownictwo (Executive Support Systems – ESS) Systemy ekspertowe (Expert Systems – ES)

26 Podstawowe pojęcia – System informatycznyEIS ESS DSS MIS TPS, OAS strategia decyzje informacja dane

27 Podstawowe pojęcia – Klasyfikacja systemów informatycznychSystemy CIM (Computer Integrated Manufacturing) – zintegrowane zarządzanie i sterowanie całym procesem produkcyjnym projektowanie i przygotowanie produkcji CAD (Computer Aided Design) komputerowe wspomaganie projektowania CAM (Computer Aided Manufacturing) komputerowe wspomaganie produkcji łączące planowanie wykonania produkcji i projektowania procesów produkcyjnych MRP II (Manufacturing Resource Planning) – zarządzanie zasobami FMS (Flexible Manufacturing Systems) – sterowanie elastycznymi liniami produkcyjnymi

28 Podstawowe pojęcia – Klasyfikacja systemów informatycznychRozwój systemów MRP MRP (Material Requirements Planning) – planowanie potrzeb materiałowych MRP II (Manufacturing Resource Planning) – planowanie zasobów produkcyjnych ERP (Enterprise Resource Planning) – jest rozwinięciem MRP II o procedury finansowe (cash flow, rachunek kosztów działań) ERP II – pełne wykorzystaniem technologii internetowych oraz rozwiązań mobilnych

29 Podstawowe pojęcia – Klasyfikacja systemów informatycznychKlasyfikacja wg rodzaju przetwarzania danych Systemy transakcyjne OLTP (On Line Transaction Processing) Systemy analizy danych OLAP (On Line Analytical Processing) Systemy czasu rzeczywistego (real-time) Systemy projektowe Systemy multimedialne

30 Podstawowe pojęcia – Klasyfikacja systemów informatycznychKlasyfikacja SI według liczby użytkowników Systemy personalne Systemy dla grup roboczych Systemy departamentalne Systemy dla wielkich organizacji Klasyfikacja wg dostępu Systemy lokalne (LAN) Systemy wewnątrzorganizacyjne (Intranet) Systemy dostępne publicznie (Internet) Klasyfikacja wg architektury Systemy jednostanowiskowe Systemy wielodostępne terminalowe Systemy sieciowe peer-to-peer Systemy klient-serwer Systemy rozproszone:

31 Podstawowe pojęcia – Fazy życia systemów informatycznychFazy życia systemu informatycznego Planowanie Analiza Projektowanie Implementacja Testowanie Wdrożenie Eksploatacja Wycofanie

32 System komputerowy System komputerowy – system składający się ze współdziałających dwóch elementów: Sprzęt komputerowy Oprogramowanie, Coraz częściej niezbędnym trzecim elementem w systemie komputerowym jest sieć. Czy system komputerowy działać bez udziału człowieka?

33 System komputerowy Struktura systemu komputerowego: SprzętSystem operacyjny Programy narzędziowe Programy użytkowe Użytkownicy Sprzęt – możliwości obliczeniowe (cpu), zasoby (pamięć, urządzenia wejścia/wyjścia). System operacyjny – kontroluje i koordynuje działanie zasobów sprzętowych przez zastosowanie różnych programów użytkowych dla różnych użytkowników. Oprogramowanie narzędziowe – dogodne interfejsy użytkowe wspomagające zarządzanie zasobami sprzętowymi oraz usprawniające, modyfikujące oprogramowanie systemowe. Oprogramowanie użytkowe – określają sposoby użycia zasobów systemowych do rozwiązywania problemów obliczeniowych zadanych przez użytkownika (kompilatory, systemy baz danych, gry, oprogramowanie biurowe) . Użytkownicy – ludzie, maszyny, inne komputery.

34 Dane, informacje, wiedzaPierwsze próby definiowania czym jest Informacja podjęte zostały przez Hartleya i Shannona. Według Shannona podstawową cechą Informacji jest zmniejszanie entropii czyli niepewności lub niewiedzy odbiorcy. Shannon utożsamiał informację z danymi – takie podejście jest właściwe dla teorii kodów i teletransmisji. Ilość informacji – definiowana jest jako wielkość przedstawiająca ilościowo właściwość zmniejszania niepewności.

35 Dane, informacje, wiedzaIlość informacji otrzymanej przy zajściu zdarzenia xi (entropia tego zdarzenia, entropia indywidualna, samoinformacja komunikatu) (Hartley): 𝐼 𝑖 = ℎ 𝑖 = log 𝑟 1 𝑝 𝑖 =− log 𝑟 𝑝 𝑖 gdzie: Ii – ilość informacji otrzymanej przy zajściu zdarzenia xi, pi – prawdopodobieństwo zajścia zdarzenia xi, r – podstawa logarytmu. Przy podstawie logarytmu: r = 2 – jednostką informacji jest bit r = e – jednostką informacji jest nat (nit) r = 10 – jednostką informacji jest dit

36 Dane, informacje, wiedzaInformacja według Langeforsa Infologiczna teoria Langeforsa rozróżnia informację od danych i kładzie znaczący akcent na uwzględnienie wymagań użytkowników informacji. Informacja może jedynie powstać w umyśle człowieka jako proces interpretacji danych. Równania infologiczne Langeforsa I = i(D, S, t) gdzie: I – informacja i – proces interpretacji D – dane S – przedwiedza t -- czas

37 Dane, informacje, wiedzaAutorzy Definicje danych Definicje informacji Avison and Fitzgerald (1995) Dane reprezentują nieustrukturyzowane fakty Informacja ma znaczenie... pochodzi z wyselekcjonowania danych, ich podsumowania i prezentacji w taki sposób, by były użyteczne dla odbiorcy Clare and Loucopoulos (1987) Fakty zgromadzone z obserwacji lub zapisów dotyczących zjawisk, obiektów lub ludzi Wymagana do podejmowania decyzji. Informacje są produktem istotnego przetwarzania danych Galland (1982) Fakty, koncepcje lub wyniki w postaci, która może być komunikowana i interpretowana Informacje to to, co powstaje w wyniku pewnych działań myślowych człowieka (obserwacji, analiz) z sukcesem zastosowanych do danych by odkryć ich istotę lub znaczenie

38 Dane, informacje, wiedzaAutorzy Definicje danych Definicje informacji Hicks (1993, 3rd Ed) Reprezentacja faktów, koncepcji lub instrukcji w sposób sformalizowany, umożliwiający komunikowanie, interpretację lub przetwarzanie przez ludzi lub urządzenia automatyczne Dane przetworzone tak, by miały znaczenie dla decydenta w konkretnej sytuacji decyzyjnej Knight and Silk (1990) Numery reprezentujące obserwowalne obiekty lub zagadnienia (fakty) Znaczenie dla człowieka związane z obserwowanymi obiektami i zjawiskami Laudon and Laudon (1991) Surowe fakty, które mogą być kształtowane i formowane by stworzyć informacje Dane, które zostały ukształtowane lub uformowane przez człowieka w istotną i użyteczną postać

39 Dane, informacje, wiedzaAutorzy Definicje danych Definicje informacji Maddison (red.) (1989) Język naturalny: podane fakty, z których inni mogą dedukować, wyciągać wnioski. Informatyka: znaki lub symbole, w szczególności w transmisji, w systemach komunikacji i w przetwarzani,u w systemach komputerowych; zwykle choć nie zawsze reprezentujące informacje, ustalone fakty lub wynikająca z nich wiedza; reprezentowane przez ustalone znaki, kody, zasady konstrukcji i struktury Zrozumiała, użyteczna, adekwatna komunikacja w odpowiednim czasie; jakikolwiek rodzaj wiedzy o rzeczach i koncepcjach w świecie dyskusji, która jest wymieniana pomiędzy użytkownikami; to treść, która ma znaczenie, a nie jej odwzorowanie Martin and Powell (1992) Surowce życia organizacji; składają się z rozłącznych numerów, słów, symboli i sylab odwołujących się do zjawisk i procesów biznesu Informacje pochodzą z danych, które zostały przetworzone tak, by stały się użyteczne w podejmowaniu decyzji w zarządzaniu Źródło: Checkland P., Holwell S., „Information, Systems and Information Systems: making sense of the field”

40 Dane, informacje, wiedzaDane, informacja, wiedza według Beynona-Daviesa Dana jest to jeden lub kilka symboli, użytych do reprezentowania czegoś. Dane to fakty. Informacja to zinterpretowane dane. Informacje to dane umieszczone w znaczącym kontekście. Informacja ma charakter subiektywny. Informacja musi być zawsze rozpatrywana w kontekście jej odbiorcy. Te same dane mogą być różnie interpretowane przez różnych ludzi w zależności od posiadanej wiedzy. Wiedza jest otrzymywana z informacji przez jej zintegrowanie z wiedzą istniejącą.

41 Dane, informacje, wiedzaWiedza według Davenporta i Prusaka to płynne połączenie ukształtowanego doświadczenia, wartości, informacji kontekstowej i ekspertyzy, które zapewniają model oceny oraz pozwalają wcielić nowe doświadczenia i informacje. Swój początek i odniesienie znajduje w umysłach ludzi posiadających wiedzę. Jest osadzona w dokumentach, repozytoriach, procedurach, procesach, praktykach i normach organizacyjnych.”

42 Dane, informacje, wiedzaCechy informacji: Celowość – informacja musi komuś i czemuś służyć, musi istnieć racjonalna przesłanka, gromadzenia i wykorzystywania informacji Rzetelność – dotyczy prawdziwości zarówno źródła informacji jak i jej zawartości Aktualność – informacja musi dotyczyć okresu decyzyjnego i być dostarczona w odpowiednim czasie Kompletność – informacja nie może być wyrywkowa, musi uwzględniać kontekst decyzyjny Wszechstronność – powinna przedstawiać sytuację decyzyjną z wielu różnych punktów widzenia Odpowiednia dokładność – nie za szczegółowa i nie za ogólna Uzasadnione nakłady finansowe – wykorzystanie informacji musi przynosić korzyści przynajmniej pokrywające nakłady poniesione na jej zdobycie Źródło: O’Shaughnessy P., „Organizacja zarządzania w przedsiębiorstwie” Kemball–Cook, R.B., „Luka organizacyjna”

43 Dane, informacje, wiedzaWedług COBIT (Control Objectives for Information and related Technology opracowany przez ISACA oraz IT Governance Institute) – będącego zbiorem dobrych praktyk wykorzystywanym przez audytorów systemów informatycznych, informacja powinna spełniać następujące kryteria: Efektywność – zapewnienie informacji istotnej, stosownej i użytecznej, oraz dostarczenia jej na czas w poprawnej i spójnej formie Wydajność– dostarczenie informacji wykorzystując dostępne zasoby w sposób optymalny (ekonomiczny) Poufność – dotyczy ochrony informacji przed nieuzasadnionym ujawnieniem i użyciem

44 Dane, informacje, wiedzaIntegralność – dotyczy dokładności i kompletności informacji oraz jej poprawności w odniesieniu do oczekiwań biznesowych Dostępność – sprawia, że informacja jest dostępna dla określonego procesu biznesowego uwzględniając również aspekt czasowy (teraz i w przyszłości). Dotyczy również ochrony koniecznych zasobów i przypisanych im cech i funkcji. Zgodność – uwzględnia wymagania narzucone na organizację przez podmioty zewnętrzne, prawo, rozporządzenia, umowy, oraz określone wymagania i polityki wewnętrzne Wiarygodność – ma na celu zapewnienie odpowiedniej informacji zarządowi, po to, aby ten mógł wywiązać się ze zobowiązań wynikających z zasad ładu korporacyjnego.

45 Dane, informacje, wiedzaMądrość Wiedza Informacja Dane Wiedza spersonalizowana Wiedza skodyfikowana

46 Dane, informacje, wiedzaRodzaje wiedzy: Wiedza deklaratywna – inaczej „wiem że“, dotyczy konkretnych faktów dotyczących obiektów jak i zdarzeń Wiedza proceduralna – „wiem jak“ opisuje jak wykonywać pewne zadania, realizować pewne czynności, zazwyczaj trudniejsza do werbalizacji Metawiedza – inaczej „wiem, że wiem“, to wiedza o tym, co wiemy Wiedza jawna – może być wyrażona w słowach i liczbach, łatwa do przekazania Wiedza niejawna - inaczej wiedza ukryta, lub też wiedza milcząca, oznacza wiedzę, o której nie wiemy, że ją posiadamy, często jest intuicyjna

47 Projekt Projekt jest złożonym działaniem o charakterze jednorazowym, które jest podejmowane dla osiągnięcia z góry określonych celów. Złożoność projektu wynika z tego, że aby osiągnąć wyznaczony cel należy wykonać wiele działań w określonej kolejności. Jednorazowość projektu jest jednym z jego kluczowych atrybutów, nie możemy bowiem nazwać projektem działania powtarzalnego. W przypadku działań powtarzalnych mówimy raczej o operacjach lub procesach. Inna definicja projektu to: zorganizowany ciąg działań ludzkich zmierzających do osiągnięcia założonego wyniku, realizowanych w skończonym przedziale czasu z wyróżnionym początkiem i końcem, najczęściej zespołowo, z wykorzystaniem skończonej ilości zasobów.

48 Projekt Podstawowe atrybuty projektu: zdefiniowanie w czasie,niepowtarzalność (jednorazowość), złożoność, celowość. Metodyki zarządzania projektami: PRINCE2 PMI / PMBOK Six sigma Scrum RUP Extreme project management (XP) XPrince

49 Uzasadnienie biznesoweDlaczego warto realizować projekt? Uzasadnienie opisuje potencjalne korzyści z realizacji projektu ale również odnosi się do kosztów i zagrożeń. Uzasadnienie biznesowe jest dokumentem, który jest tworzony na początku projektu i przez cały cykl życia projektu jest sprawdzane czy jest aktualne. Jeśli w trakcie projektu uzasadnienie biznesowe przestanie być aktualne projekt powinien zostać przerwany.

50 Uzasadnienie biznesoweUzasadnienie biznesowe powinno składać się z następujących punktów: Powody uzasadniające uruchomienie projektu Możliwe warianty realizacji Oczekiwane korzyści z realizacji projektu Zagrożenia dla realizacji projektu Koszty realizacji projektu Terminy realizacji całego projektu jak i jego części Ocena opłacalności inwestycji

51 Wymagania na podstawie Ian Sommerville Software Engineering wyd. 9

52 Wymagania Wymagania do systemu są to opisy tego co powinien system robić, jakie usługi powinien zapewniać oraz opis ograniczeń dla systemu. Wymagania odzwierciedlają potrzeby użytkowników systemu, który udostępnia przykładowo takie funkcjonalności, jak: kontrola urządzenia, złożenie zamówienia, lub wyszukiwanie informacji. Proces poszukiwania, analizowania, dokumentowania oraz weryfikacji usług i ograniczeń nazywa inżynierią wymagań.

53 Wymagania W inżynierii systemów i oprogramowania termin wymagania nie jest stosowany konsekwentnie. Może oznaczać: Bardzo ogólny opis usługi, która ma być świadczona przez system lub ograniczenia Formalna, szczegółowa definicja funkcji w systemie. Wymagania definiują „co” system powinien robić!!! Wymagania nie definiują „jak” system powinien to coś robić!!!

54 Wymagania Według Davies’a – dualność wymagań można wytłumaczyć w następujący sposób. W przypadku gdy firma – klient chce zamówić opracowanie nowego systemu informatycznego, musi określić swoje wymagania w odpowiednio abstrakcyjny sposób, tak aby nie definiować gotowego rozwiązania – wymagania użytkownika. Dzięki ogólnemu poziomowi wymagań potencjalni wykonawcy mogą zaoferować różne sposoby realizacji systemu. Po wybraniu dostawcy powinien on doprecyzować definicję systemu, podając więcej szczegółów, aby klient mógł zrozumieć i zweryfikować to, co system będzie robił – wymagania systemowe.

55 Wymagania Wymagania użytkownika to wyrażenia w języku naturalnym wraz z schematami (diagramami), które opisują jakich usług (funkcjonalności) użytkownik oczekuje od systemu oraz opis ograniczeń w ramach, których system musi działać. Wymagania systemowe są bardziej szczegółowymi opisami funkcjonalności, usług oraz ograniczeń systemu informatycznego. Dokument z wymaganiami systemowymi (specyfikacja funkcjonalna) powinien dokładnie określić, co to jest do realizacji.

56 Wymagania Wymaganie użytkownikaSystem powinien umożliwiać wystawienie faktury VAT Wymaganie systemowe 1.1. Użytkownik powinien mieć możliwość wystawienia faktury VAT 1.2. Użytkownik powinien mieć możliwość zastosowania dostępnych dla klienta rabatów 1.3. Użytkownik powinien mieć możliwość wybrania dostępnych dla klienta form płatności 1.4. W przypadku płatności przeterminowanych faktura powinna być wystawiona z płatnością „gotówka” 1.5. System powinien umożliwiać dodanie do faktury wiele razy tego samego produktu

57 Wymagania Wymagania użytkownika Wymagania systemoweMenadżerowie klienta Użytkownicy końcowi klienta Inżynierowie klienta Menadżerowie wykonawcy Architekci systemu Wymagania systemowe Programiści

58 Wymagania funkcjonalne, niefunkcjonalne i dziedzinoweWymagania funkcjonalne to informacje o: Usługach jakie system powinien zapewnić Jak system powinien reagować na określone dane wejściowe Jak system ma reagować w określonych sytuacjach Czego system nie powinien robić Wymagania niefunkcjonalne to: Ograniczenia dotyczące usług lub funkcji oferowanych przez system. Ograniczenia czasowe Ograniczenia dotyczące procesu wytwarzania Ograniczenia nałożone przez normy – specyfika dziedziny Wymagania niefunkcjonalne często odnoszą się do systemu jako całości, a nie pojedynczych funkcjonalności lub usług systemu.

59 Wymagania funkcjonalne, niefunkcjonalne i dziedzinoweWymagania dziedzinowe – nie wywodzą się z potrzeb użytkowników lecz z dziedziny dla której opracowywany jest system informatyczny. Wymagania dziedzinowe mogą generować nowe wymagania funkcjonalne, mogą generować ograniczenia dla wymagań funkcjonalnych lub też mogą określać jakie obliczenia powinny zostać przeprowadzone (jakich użyć algorytmów). Problemy świata IT w zakresie wymagań dziedzinowych: Brak zrozumienia dziedziny w której system ma działać Możliwość pominięcia istotnych wymagań Możliwość wystąpienia konfliktów pomiędzy wymaganiami

60 Wymagania funkcjonalneWymagania funkcjonalne opisują co system powinien robić. Wymagania funkcjonalne zależą od: Typu systemu, który będzie opracowywany Potencjalnych użytkowników systemu Ogólnego podejścia przyjętego przez organizację podczas tworzenia specyfikacji wymagań

61 Wymagania funkcjonalneWymagania funkcjonalne wyrażone w postaci wymagań użytkownika z reguły są opisane w sposób ogólny tak, aby były zrozumiałe przez użytkowników systemu. Wymagania funkcjonalne wyrażone w postaci wymagań systemowych są bardziej szczegółowe, opisują dokładnie funkcjonalności systemu, wejścia, wyjścia, wyjątki itp. Problem – przejście z wymagań użytkownika do wymagań systemowych może odbywać się na różnych poziomach szczegółowości.

62 Wymagania funkcjonalneProblemy wynikające z niedoprecyzowania wymagań. Niedoprecyzowane wymaganie zostanie zinterpretowane przez developera w taki sposób aby uprościć implementację. Brak satysfakcji klienta Konieczność zdefiniowania nowego wymagania Opóźnienie w realizacji projektu

63 Wymagania funkcjonalneWymagania funkcjonalne powinny być kompletne i spójne. Kompletność wymagań oznacza, że wszystkie wymagane przez użytkownika od systemu usługi zostały zdefiniowane. Spójność oznacza, że wymagania nie powinny mieć sprzecznych definicji.

64 Wymagania funkcjonalneW dużych, złożonych systemach nie jest możliwe osiągnięcie zarówno kompletności jak i spójności wymagań. Powody: Łatwość popełniania błędów i zaniechań podczas pisania specyfikacji dla złożonych systemów Duża liczba interesariuszy z różnymi potrzebami, które często nie są spójne. Niespójność i niekompletność są wręcz wpisane w pierwsze specyfikacje wymagań. Problemy związane z niespójnościami mogą wyłonić się w wyniku dokładniejszej analizy lub w momencie uruchomienia systemu.

65 Wymagania niefunkcjonalneWymagania niefunkcjonalne nie są bezpośrednio związane z konkretnymi usługami świadczonymi użytkownikom przez system. Mogą one dotyczyć takich właściwości systemu, np: Niezawodność Czas reakcji Zajętość pamięci Mogą to również być ograniczenia dotyczące wdrożenia systemu, np: Możliwości urządzeń wejścia wyjścia Reprezentacji danych wykorzystywanych w interfejsach wymiany danych z innymi systemami Ograniczenia finansowe!!!

66 Wymagania niefunkcjonalneWymagania niefunkcjonalne są często dużo ważniejsze niż indywidualne wymagania funkcjonalne. Użytkownicy systemu mogą zwykle znaleźć sposoby obejścia niedziałających bądź brakujących funkcji systemu. Nie spełnienie niefunkcjonalnego wymagania może oznaczać, że cały system jest niezdatny do użytku.

67 Wymagania niefunkcjonalneStosunkowo łatwo jest zidentyfikować, które komponenty systemu realizuj wymagania funkcjonalne. W przypadku wymagań niefunkcjonalnych jest to dużo trudniejsze. Wymagania te mogą być rozproszone po całym systemie. Wynika to z: Wymagania niefunkcjonalne mogą dotyczyć architektury systemu a nie poszczególnych elementów. Pojedyncze wymaganie niefunkcjonalne może generować wiele wymagań funkcjonalnych lub może generować ograniczenia dla wymagań funkcjonalnych

68 Wymagania niefunkcjonalne Wymagania produktowe UżytecznośćEfektywność Szybkość Zajętość pamięci Niezawodność Bezpieczeństwo Wymagania organizacyjne Środowiskowe Operacyjne Implementacyjne Wymagania zewnętrzne Certyfikacyjne Etyczne Prawne Ustawa o rachunkowości Bezpieczeństwo i ochrona informacji

69 Wymagania niefunkcjonalneWymagania produktowe Użyteczność Efektywność Szybkość Zajętość pamięci Niezawodność Bezpieczeństwo Wymagania produktowe – definiują lub ograniczają zachowanie systemu.

70 Wymagania niefunkcjonalneWymagania organizacyjne Środowiskowe Operacyjne Implementacyjne Wymagania organizacyjne – wynikają z procedur obowiązujących w organizacji klienta i dostawcy systemu.

71 Wymagania niefunkcjonalneWymagania zewnętrzne Certyfikacyjne Etyczne Prawne Ustawa o rachunkowości Bezpieczeństwo i ochrona informacji Wymagania zewnętrzne – obejmują wszystkie wymagania pochodzące od czynników zewnętrznych mające wpływ zarówno na system jak i na proces wytwórczy.

72 Wymagania niefunkcjonalnePodstawowym problemem przy definiowaniu wymagań niefunkcjonalnych jest to, że są one wyrażane często jako ogólne cele np.: Łatwość użycia Zdolność do szybkiego uruchomienia po awarii Zdolność do szybkiej reakcji na działania użytkownika Tak zdefiniowane cele pozostawiają pole do swobodnej interpretacji i częstych sporów po dostarczeniu systemu.

73 Wymagania niefunkcjonalneWymaganie niefunkcjonalne przedstawione jako cel ogólny System powinien szybko generować wszystkie raporty na żądanie użytkownika. Wymaganie niefunkcjonalne przedstawione w sposób mierzalny (umożliwiający obiektywną weryfikację) Czas generowania każdego raportu w systemie (dla danych z maksymalnie 12 miesięcy) nie powinien przekraczać 30 sekund

74 Wymagania niefunkcjonalneSzybkość Liczba przetworzonych transakcji na sekundę Czas reakcji na zdarzenie lub aktywność użytkownika Czas odświeżania ekranu Rozmiar Liczba MB Ilość układów pamięci ROM Łatwość użytkowania Czas potrzebny na szkolenia Liczba kontaktów z helpdeskiem Niezawodność Średni czas między awariami Prawdopodobieństwo niedostępności systemu Częstotliwość występowania błędów Gwarantowany czas dostępności systemu Solidność Czas potrzebny na uruchomienie po awarii Procent zdarzeń powodujących awarię Prawdopodobieństwo utraty danych w wyniku awarii

75 Dokument specyfikacji wymagań oprogramowaniaCechy poprawnej dokumentacji wymagań wg IEEE Poprawna Jednoznaczna Kompletna Spójna Uporządkowana wg ważności/spójności Możliwa do weryfikacji Modyfikowalna Umożliwiające śledzenie powiązań

76 Dokument specyfikacji wymagań oprogramowaniaPoprawność dokumentacji Dokumentacja jest poprawna jeśli każde określone w niej wymaganie musi być spełnione przez system. Nie ma żadnych narzędzi lub procedur, które gwarantują poprawność dokumentacji. W celu zapewnienia poprawności dokumentacji wymagań należy ją porównywać z innymi dokumentami wytworzonymi w projekcie. Alternatywnym rozwiązaniem zapewniającym poprawność dokumentacji jest weryfikacja dokumentacji pod kątem aktualnych potrzeb przez klienta.

77 Dokument specyfikacji wymagań oprogramowaniaJednoznaczność dokumentacji Dokumentacja jest jednoznaczna gdy każde określone w niej wymaganie ma tylko jedną interpretację. Każde wymaganie powinno mieć również unikalny identyfikator.

78 Dokument specyfikacji wymagań oprogramowaniaKompletność dokumentacji Dokumentacja jest kompletna gdy zawiera: Wszystkie istotne wymagania (funkcjonalne, wydajnościowe, ograniczenia projektowe, cechy produktu, specyfikacje interfejsów zewnętrznych, …). W szczególności każde zewnętrzne wymaganie powinno mieć wpływ na specyfikację systemu. Definicję reakcji systemu na wszystkie możliwe zasilenia w różnych możliwych sytuacjach. Dokumentacja powinna zwierać reakcję systemu zarówno na zasilenia danymi poprawnymi jak i niepoprawnymi. Odwołania do wszystkich diagramów, tabel, wykresów, definicję wszystkich terminów (pojęć) i jednostek miar.

79 Dokument specyfikacji wymagań oprogramowaniaSpójność dokumentacji Spójność dotyczy wewnętrznej spójności dokumentacji. Jeśli dokumentacja nie jest zgodna z dokumentami nadrzędnymi to oznacza, że jest ona niepoprawna a nie niespójna. Typowe niespójności w dokumentacji: Określone cechy obiektów rzeczywistych mogą być sprzeczne Konflikty logiczne lub dotyczące kolejności działań Dwa lub więcej wymagań opisują ten sam obiekt rzeczywisty używając różnych nazw dla tego obiektu.

80 Dokument specyfikacji wymagań oprogramowaniaUporządkowanie dokumentacji wg ważności/spójności Polega na przyporządkowaniu do każdego wymagania priorytetów określających ważność lub niezbędną stabilność konkretnego wymagania. Oznaczenie wymagań w taki sposób umożliwia: Zwrócenie przez klientów większej uwagi na wymagania, dzięki czemu możliwe będzie uniknięcie ukryty założeń. Podjęcie przez programistów prawidłowych decyzji projektowych oraz poświęcenie właściwego poziomu uwagi na różne części produktu. Do określania priorytetów wymagań można użyć metody MoSCoW: Must have Should have Coudl have Won’t have

81 Dokument specyfikacji wymagań oprogramowaniaMożliwość weryfikacji spełnienia wymagań Wszystkie wymagania w dokumentacji powinny być weryfikowalne. Wymaganie jest weryfikowalne jeśli istnieje skończony opłacalny proces, za pomocą którego człowiek lub maszyna może sprawdzić czy produkt spełnia wymaganie. Wszelkie niejednoznaczne wymagania są nieweryfikowalne

82 Dokument specyfikacji wymagań oprogramowaniaModyfikowalność dokumentacji Dokumentacja jest modyfikowalna jeśli jej struktura i styl umożliwiają wprowadzenie zmian w sposób prosty, kompletny i spójny przy zachowaniu struktury i stylu dokumentacji. Modyfikowalność wymaga od dokumentacji aby: Posiadała spójny i łatwy do użycia spis treści, indeks oraz mechanizm odwołań Nie była redundantna Określała każde wymaganie oddzielnie

83 Dokument specyfikacji wymagań oprogramowaniaMożliwość śledzenia powiązań Każde wymaganie w dokumentacji powinno mieć określone pochodzenie a dokumentacja powinna zawierać mechanizmy umożliwiające odwoływanie się do wymagań. Śledzenie powiązań może być dwukierunkowe: Wymaganie może odwoływać się do źródeł we wcześniejszych dokumentach (Backward traceability). Wymaganie może zawierać odwołanie do wszystkich dokumentów które powstały na podstawie dokumentacji wymagań (Forward traceability).

84 Dokument specyfikacji wymagań oprogramowaniaDokument zawierający specyfikację wymagań oprogramowania (SRS – software requirements specification) to oficjalna informacja co powinno zostać wytworzone przez programistów. SRS składa się zarówno z wymagań użytkownika jak wymagań systemowych

85 Dokument specyfikacji wymagań oprogramowaniaKlienci Definiują wymagania oraz weryfikują je aby sprawdzić czy pokrywają ich potrzeby. Klienci są również odpowiedzialni za zmiany w wymaganiach Menadżerowie Używają dokumentacji wymagań do przygotowania zamówienia/przetargu na dostawę systemu oraz zaplanowania procesu wdrożenia Inżynierowie systemowi Używają dokumentacji wymagań aby zrozumieć jaki system powinien zostać wytworzony Inżynierowie testów Używają dokumentacji wymagań do opracowania scenariuszy testów Inżynierowie utrzymania systemu Używają dokumentacji do zrozumienia systemu oraz relacji pomiędzy jego częściami

86 Dokument specyfikacji wymagań oprogramowaniaRóżnorodność użytkowników dokumentacji wymagań oznacza, że powinna ona być tak napisana aby z jednej strony wymagania były zrozumiałe dla klienta a z drugiej strony aby wymagania były opisane szczegółowo dla programistów i testerów. Dokumentacja powinna również zawierać informacje o możliwych kierunkach rozwoju systemu. Takie informacje umożliwią projektantom systemu uniknąć restrykcyjnych decyzji w trakcie projektowania co pomoże inżynierom odpowiedzialnym za utrzymanie systemu jego modyfikacje w celu spełnienia nowych wymagań.

87 Dokument specyfikacji wymagań oprogramowaniaPoziom szczegółowości dokumentacji wymagań zależy od: Typu systemu Sposobu wytwarzania oprogramowania

88 Dokument specyfikacji wymagań oprogramowaniaPrzedmowa Zawiera informację o: adresatach dokumentacji, historię wersji dokumentu, uzasadnienia dla tworzenia nowych wersji, podsumowanie zmian każdej wersji Wstęp We wstępie powinny być w skrócie opisane potrzeby systemu, integracja z innymi systemami. Wstęp powinien również zawierać opis w jaki sposób system ma realizować cele strategiczne organizacji Słownik pojęć Zawiera definicję pojęć/terminów używanych w dokumentacji

89 Dokument specyfikacji wymagań oprogramowaniaDefinicja wymagań użytkownika Opisuje usługi dostarczane przez system użytkownikom. Zawiera zarówno opis wymagań funkcjonalnych jaki niefunkcjonalnych. Powinna być napisana w języku naturalnym oraz zawierać diagramy oraz symbole zrozumiałe dla klienta. Zawiera również opis standardów dotyczących procesów i produktów, które powinny zostać spełnione. Architektura systemu Powinna zawierać ogólny opis przewidywanej architektury systemu, obrazując umiejscowienie poszczególnych funkcjonalności w modułach systemu. Specyfikacja wymagań systemowych Powinna zawierać bardziej szczegółowy opis wymagań funkcjonalnych i niefunkcjonalnych. W zależności od potrzeb może zawierać dodatkowe wymagania niefunkcjonalne (takie które nie pojawiły się w wymaganiach użytkownika). W rozdziale tym mogą również być zdefiniowane interfejsy wymiany danych z innymi systemami.

90 Dokument specyfikacji wymagań oprogramowaniaModele systemu Może zawierać graficzne modele systemu prezentujące relacje pomiędzy elementami systemu oraz pomiędzy systemem a jego otoczeniem. Rozwój systemu Powinien zawierać opis podstawowych założeń na których bazuje system oraz przewidywane zmiany w zakresie sprzętu, wymagań użytkowników, itp. Dzięki temu rozdziałowi architekci systemowi mogą uniknąć podjęcia decyzji projektowych ograniczających przyszłe możliwe zmiany systemu. Załączniki Powinien zawierać szczegółowe informacje powiązane z wytwarzanym systemem (np. specyfikacja sprzętu i systemu bazodanowego). Wymagania sprzętowe powinny definiować minimalną i optymalną konfigurację sprzętu. Wymagania bazodanowe definiują logiczną organizację danych i powiązania pomiędzy danymi. Skorowidz Do dokumentu można dołączyć kilka indeksów. Poza indeksem alfabetycznym mogą być spisy diagramów, tabel, itp.

91 Dokument specyfikacji wymagań oprogramowaniaSpecyfikacja wymagań wg standardu IEEE Wstęp 1.1. Przeznaczenie dokumentu 1.2. Zakres produktu 1.3. Definicje, akronimy i skróty 1.4. Odwołania 1.5. Przegląd pozostałej części dokumentu 2. Ogólny opis 2.1. Wizja produktu 2.2. Funkcje produktu 2.3. Charakterystyka użytkowników 2.4. Ograniczenia 2.5. Założenia i zależności 3. Szczegółowe wymagania 4. Dodatki 5. Skorowidz

92 Dokument specyfikacji wymagań oprogramowania1. Wstęp 1.1. Przeznaczenie dokumentu 1.2. Zakres produktu 1.3. Definicje, akronimy i skróty 1.4. Odwołania 1.5. Przegląd pozostałej części dokumentu Wstęp powinien zawierać przegląd całej specyfikacji wymagań

93 Dokument specyfikacji wymagań oprogramowania1. Wstęp 1.1. Przeznaczenie dokumentu 1.2. Zakres produktu 1.3. Definicje, akronimy i skróty 1.4. Odwołania 1.5. Przegląd pozostałej części dokumentu Na przeznaczenie dokumentu składają się: Nakreślenie celu specyfikacji wymagań Określenie odbiorców dokumentacji (dla kogo jest przeznaczona dokumentacja wymagań)

94 Dokument specyfikacji wymagań oprogramowania1. Wstęp 1.1. Przeznaczenie dokumentu 1.2. Zakres produktu 1.3. Definicje, akronimy i skróty 1.4. Odwołania 1.5. Przegląd pozostałej części dokumentu Na zakres produktu składa się: Identyfikacja produktu (systemu informatycznego), który ma zostać wytworzony – w tym podanie jego nazwy. Wyjaśnienie co produkt ma robić oraz jeśli to niezbędne określenie czego ma nie robić. Opis sposobu wykorzystania specyfikowane systemu oraz wskazanie korzyści i celów do osiągnięcia Zakres produktu powinien być spójny z kolejnymi rozdziałami np. specyfikacją wymagań systemowych.

95 Dokument specyfikacji wymagań oprogramowania1. Wstęp 1.1. Przeznaczenie dokumentu 1.2. Zakres produktu 1.3. Definicje, akronimy i skróty 1.4. Odwołania 1.5. Przegląd pozostałej części dokumentu Podrozdział powinien zawierać definicje wszystkich terminów, akronimów i skrótów, których znajomość i jednoznaczność jest wymagana w celu właściwej interpretacji specyfikacji wymagań. Informacje w tym rozdziale mogą prowadzić do załączników specyfikacji wymagań lub odnosić się do innych dokumentów.

96 Dokument specyfikacji wymagań oprogramowania1. Wstęp 1.1. Przeznaczenie dokumentu 1.2. Zakres produktu 1.3. Definicje, akronimy i skróty 1.4. Odwołania 1.5. Przegląd pozostałej części dokumentu Podrozdział powinien: Zawierać kompletną listę wszystkich dokumentów do których odwołuje się specyfikacja wymagań. Każdy dokument powinien być identyfikowany przez tytuł, numer, datę, dane wydawcy. Zawierać spis źródeł z których można pozyskać dokumenty do których odwołuje się specyfikacja wymagań.

97 Dokument specyfikacji wymagań oprogramowania1. Wstęp 1.1. Przeznaczenie dokumentu 1.2. Zakres produktu 1.3. Definicje, akronimy i skróty 1.4. Odwołania 1.5. Przegląd pozostałej części dokumentu Podrozdział powinien: Zawierać opis tego co zawiera pozostała część dokumentu specyfikacji wymagań. Wyjaśniać jaka jest struktura dokumentu.

98 Dokument specyfikacji wymagań oprogramowania2. Ogólny opis 2.1. Wizja produktu 2.2. Funkcje produktu 2.3. Charakterystyka użytkowników 2.4. Ograniczenia 2.5. Założenia i zależności Rozdział powinien zawierać opis czynników ogólnych mających wpływ na produkt oraz jego wymagania. Rozdział ten nie opisuje konkretnych wymagań. Rozdział ten dostarcza kontekstu (tła) ułatwiającego zrozumienie wymagań opisanych w rozdziale 3.

99 Dokument specyfikacji wymagań oprogramowania2. Ogólny opis 2.1. Wizja produktu 2.2. Funkcje produktu 2.3. Charakterystyka użytkowników 2.4. Ograniczenia 2.5. Założenia i zależności W tym podrozdziale produkt powinien zostać osadzony w środowisku innych powiązanych systemów. Jeśli produkt ma być samodzielny i całkowicie niezależny to powinno to być wyraźnie stwierdzone w tym rozdziale. Jeśli dokumentacja opisuje produkt będący częścią większego systemu to należy odnieść się do wymagań tego systemu oraz określić interfejsy pomiędzy opisywanym produktem a systemem. Pomocne mogą być diagramy prezentujące: główne komponenty tego większego systemu, powiązania wewnętrzne oraz interfejsy zewnętrzne.

100 Dokument specyfikacji wymagań oprogramowania2. Ogólny opis 2.1. Wizja produktu 2.2. Funkcje produktu 2.3. Charakterystyka użytkowników 2.4. Ograniczenia 2.5. Założenia i zależności W tym podrozdziale powinno się również opisać jak oprogramowanie działa w odniesieniu do różnych ograniczeń dotyczących np.: Interfejs systemu Interfejs użytkownika Interfejs sprzętu Interfejs oprogramowania Interfejs komunikacyjny Ograniczenia pamięciowe Operacje (działania) Wymagania adaptacyjne

101 Dokument specyfikacji wymagań oprogramowania2.1. Wizja produktu Interfejs systemu … Ograniczenia dotyczące interfejsów systemu powinny zawierać listę interfejsów systemowych. Powinny identyfikować funkcjonalności oprogramowania, które należy spełnić zgodnie z wymagania systemowymi.

102 Dokument specyfikacji wymagań oprogramowania2.1. Wizja produktu … Interfejs użytkownika Logiczna charakterystyka interfejsu pomiędzy oprogramowaniem a użytkownikiem np.: Wymagany format ekranu Layout strony lub okna Zawartość raportów Dostępność programowalnych klawiszy funkcyjnych. Wszystkie aspekty związane z optymalizacją UI dla osób, które będą korzystały z systemu. Lista jak system powinien i nie powinien wyglądać.

103 Dokument specyfikacji wymagań oprogramowania2.1. Wizja produktu … Interfejs sprzętu Logiczna charakterystyka interfejsów pomiędzy oprogramowaniem a sprzętowymi komponentami systemu. Obejmuje cechy konfiguracyjne np.: Liczba portów Zestaw instrukcji, itp. Powinna dostarczać również informacji jakie urządzenia będą obsługiwane, w jaki sposób będą wspierane.

104 Dokument specyfikacji wymagań oprogramowania2.1. Wizja produktu … Interfejs oprogramowania Powinien opisywać wykorzystanie oraz interfejsy do innych wymaganych systemów oprogramowania np. DBMS System operacyjny Pakiet bibliotek dostarczających funkcji matematycznych

105 Dokument specyfikacji wymagań oprogramowania2.1. Wizja produktu … Interfejs komunikacyjny Powinien opisywać różnorakie interfejsy komunikacyjne np. protokoły sieci lokalnej.

106 Dokument specyfikacji wymagań oprogramowania2.1. Wizja produktu … Ograniczenia pamięciowe Powinny określać wszelkie właściwości (cechy) oraz ograniczenia dla pamięci.

107 Dokument specyfikacji wymagań oprogramowania2.1. Wizja produktu … Operacje (działania) Powinien określać standardowe i specjalne działania wymagane przez użytkownika np.: Różne warianty realizacji działań użytkowników w organizacji. Okresy działań interaktywnych oraz automatycznych. Funkcje wspomagające przetwarzanie danych Operacje tworzenia i odzyskiwania kopii zapasowych.

108 Dokument specyfikacji wymagań oprogramowania2.1. Wizja produktu … Wymagania adaptacyjne Definiują wymagania dla dowolnych danych lub sekwencji inicjalizacyjnych specyficznych dla danej strony, konkretnego celu lub sposobu działania. Określają miejsca lub funkcje, które powinny być zmienione aby dopasować system do konkretnego wdrożenia.

109 Dokument specyfikacji wymagań oprogramowania2. Ogólny opis 2.1. Wizja produktu 2.2. Funkcje produktu 2.3. Charakterystyka użytkowników 2.4. Ograniczenia 2.5. Założenia i zależności Zawiera spis głównych funkcji realizowanych przez system bez ich szczegółowego opisu. Przez wzgląd na zrozumienie: Funkcje powinny być ułożone w taki sposób aby cała lista funkcji była zrozumiała dla klienta lub kogokolwiek, kto pierwszy raz będzie czytał dokumentację. Do przedstawienia różnych funkcji i relacji pomiędzy nimi można używać opisów zarówno słownych jaki i graficznych.

110 Dokument specyfikacji wymagań oprogramowania2. Ogólny opis 2.1. Wizja produktu 2.2. Funkcje produktu 2.3. Charakterystyka użytkowników 2.4. Ograniczenia 2.5. Założenia i zależności Zawiera opis użytkowników dla których przeznaczony będzie produkt łącznie z takimi informacjami jak poziom wykształcenia, doświadczenie i zaawansowanie technologiczne. Rozdział ten nie służy do określania konkretnych wymagań ale może dostarczać uzasadnienia dla konkretnych wymagań zdefiniowanych w dalszej części dokumentacji.

111 Dokument specyfikacji wymagań oprogramowania2. Ogólny opis 2.1. Wizja produktu 2.2. Funkcje produktu 2.3. Charakterystyka użytkowników 2.4. Ograniczenia 2.5. Założenia i zależności Zawiera ogólny opis pozostałych czynników ograniczających: Akty prawne Ograniczenia dotyczące sprzętu Interfejsy do innych systemów Działania zrównoleglające Funkcje kontrolne Wymagania pochodzące od języków programowania Protokoły uzgadniania sygnałów Wymagania dotyczące niezawodności Wymagania krytyczne dla systemu Wymagania dotyczące bezpieczeństwa

112 Dokument specyfikacji wymagań oprogramowania2. Ogólny opis 2.1. Wizja produktu 2.2. Funkcje produktu 2.3. Charakterystyka użytkowników 2.4. Ograniczenia 2.5. Założenia i zależności Zawiera listę wszystkich czynników, które mają wpływ na wymagania określone w dokumentacji. Czynniki te nie są ograniczeniami ale jakakolwiek zmiana ich może mieć wpływ na wymagania.

113 Dokument specyfikacji wymagań oprogramowania3. Szczegółowe wymagania Rozdział powinien zawierać wszystkie wymagania do oprogramowania opisane na takim poziomie szczegółowości aby: Projektanci mogli zaprojektować system spełniający wszystkie wymagania Testerzy mogli sprawdzić czy system zaspokaja wszystkie wymagania Specyfikacja wymagań powinna zawierać przynajmniej minimalny opis wszystkich „wejść do systemu/zasileń”, „wyjść/reakcji” oraz wszystkich funkcji realizowanych przez system w odpowiedzi na zasilenie lub w celu wygenerowania odpowiedzi z systemu.

114 Dokument specyfikacji wymagań oprogramowania3. Szczegółowe wymagania Ponieważ jest to najważniejszy rozdział w całej dokumentacji wymagań powinien on spełniać następujące reguły: Wymaganie powinno być wyrażone w taki sposób aby spełniało właściwości wymagań przedstawionych wcześniej Wymaganie powinno zawierać odwołania do wcześniejszych dokumentów, jeśli ich dotyczy Wszystkie wymagania powinny być jednoznacznie identyfikowalne Szczególną uwagę należy zwrócić na to aby sposób organizacji wymagań zwiększał ich czytelność.

115 Dokument specyfikacji wymagań oprogramowania3. Szczegółowe wymagania Interfejsy zewnętrzne Specyfikacja wymagań powinna zawierać szczegółowy opis wszystkich wejść i wyjść z systemu. Opis taki powinien zawierać: Nazwę obiektu (interfejsu) Opis celów Źródło dla zasileń lub miejsce przeznaczenia dla wyjścia systemu Zakres prawidłowych wartości, dokładność, tolerancja odchyleń Jednostka miary Czasy reakcji Relacje do innych wejść/wyjść Sposób organizacji ekranu Sposób organizacji okna Format danych Format poleceń Komunikat kończący

116 Dokument specyfikacji wymagań oprogramowania3. Szczegółowe wymagania Funkcjonalności Wymagania funkcjonalne powinny opisywać podstawowe działania, które muszą być realizowane przez system w procesie akceptacji i przetwarzania danych wejściowych w dane wyjściowe. Najczęściej jest to wyrażane za pomocą zwrotu „System będzie/powinien …” Opis funkcjonalności powinien zawierać: Warunki poprawności danych wejściowych Dokładną kolejność operacji Sposób reakcji na sytuacje awaryjne (przeciążenia, problemy komunikacyjne, obsługa błędów i odzyskiwanie sprawności po błędzie) Opis parametrów oraz ich wpływ na funkcjonalność Opis relacji pomiędzy wejściem a wyjściem systemu

117 Dokument specyfikacji wymagań oprogramowania3. Szczegółowe wymagania Wymagania wydajnościowe Powinny określać zarówno statyczne jak i dynamiczne policzalne wymagania nakładane na system lub interakcję pomiędzy system a użytkownikiem.

118 Dokument specyfikacji wymagań oprogramowania3. Szczegółowe wymagania Wymagania logiczne dotyczące danych Logiczne wymagania dla danych, które będą zapisywane w bazie danych np.: Typy danych używane przez różne funkcje Częstotliwość użycia Możliwość dostępu do danych Encje i relacje między encjami Ograniczenia integralności Wymagania odnośnie retencji danych

119 Dokument specyfikacji wymagań oprogramowania3. Szczegółowe wymagania Ograniczenia projektowe Opisuje ograniczenia projektowe, które mogą wynikać z innych standardów, ograniczeń sprzętu itp.

120 Dokument specyfikacji wymagań oprogramowania3. Szczegółowe wymagania Cechy oprogramowania Wiele cech systemu może posłużyć jako wymagania – istotne jest to aby wymaganie było wyrażone w sposób możliwy do obiektywnej weryfikacji np.: Niezawodność - Wskaźniki określające wymaganą niezawodność systemu Dostępność - Wskaźniki określające wymaganą dostępność np. 24h/7dni. czasy odzyskiwania po awarii, czasy restartu

121 Dokument specyfikacji wymagań oprogramowania3. Szczegółowe wymagania Cechy oprogramowania Bezpieczeństwo - Techniki i metody, które chronią oprogramowanie przed przypadkowym lub celowym dostępem, wykorzystaniem, modyfikacją, zniszczeniem lub ujawnieniem danych Łatwość konserwacji - Cechy oprogramowania, które odnoszą się do łatwości utrzymania samego oprogramowania. Mogą to być wymogi dotyczące pewnej modularności, interfejsów, złożoność, itp. Przenośność – Odnosi się do łatwości przenoszenia (portowania) systemu na inne urządzenia i/lub systemy operacyjne.

122 Dokument specyfikacji wymagań oprogramowania3. Szczegółowe wymagania Sposób organizacji wymagań Z uwagi na to, że specyfikacja wymagań nie należy do dokumentów trywialnych i często może być bardzo rozległa należy przykładać istotną wagę do sposobu organizacji wymagań.

123 Dokument specyfikacji wymagań oprogramowaniaSposób organizacji wymagań – wg trybu pracy systemu Stosowany gdy system zachowuje się różnie w zależności od trybu pracy. Na przykład systemy kontroli mogą mieć różne zestawy funkcji, w ​​zależności od trybu: szkolenia, normalny lub awaryjny.

124 Dokument specyfikacji wymagań oprogramowania3. Specific requirements 3.1 External interface requirements User interfaces Hardware interfaces Software interfaces Communications interfaces 3.2 Functional requirements Mode Functional requirement n Functional requirement 1.n Mode m Mode m 3.2.m.1 Functional requirement m m.nFunctional requirement m.n 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements 3.1. Functional requirements Mode External interfaces User interfaces Hardware interfaces Software interfaces Communications interfaces Functional requirements Functional requirement nFunctional requirement n Performance Mode m Mode m 3.2 Design constraints 3.3 Software system attributes 3.4 Other requirements

125 Dokument specyfikacji wymagań oprogramowaniaSposób organizacji wymagań – wg typów użytkowników Stosowany gdy system oferuje różne zestawy funkcji dla różnych klas użytkowników. Na przykład system sterowania windą prezentuje różne możliwości dla pasażerów, pracowników obsługi technicznej i strażaków.

126 Dokument specyfikacji wymagań oprogramowania3. Specific requirements 3.1 External interface requirements User interfaces Hardware interfaces Software interfaces Communications interfaces 3.2 Functional requirements User class Functional requirement n Functional requirement 1.n User class m User class m 3.2.m.1 Functional requirement m m.nFunctional requirement m.n 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements

127 Dokument specyfikacji wymagań oprogramowaniaSposób organizacji wymagań – wg obiektów Wymagania mogą być zorganizowane według obiektów ze świata rzeczywistego, które mają swoje odwzorowanie w systemie informatycznym. Dla takich obiektów definiowane są ich atrybuty i usługi (funkcje). Przykładami takich obiektów mogą być: Księgowy Kadrowy Rejestrator czasu pracy …

128 Dokument specyfikacji wymagań oprogramowania3. Specific requirements 3.1 External interface requirements User interfaces Hardware interfaces Software interfaces Communications interfaces 3.2 Classes/Objects Class/Object Attributes (direct or inherited) Attribute nAttribute n Functions (services, methods, direct or inherited) Functional requirement mFunctional requirement 1.m Messages (communications received or sent) Class/Object p Class/Object p 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements

129 Dokument specyfikacji wymagań oprogramowaniaSposób organizacji wymagań – wg funkcji systemu Funkcja (funkcjonalność) to pożądana usługa w systemie, która może wymagać sekwencji danych wejściowych w celu wywołania pożądanego efektu. Funkcje są najczęściej opisane jako sekwencja bodziec – reakcja. Przykładami takich funkcji mogą być: Przyjęcie przelewu do realizacji Powiadomienie o wypływie środków na rachunek Autoryzacja użytkownika …

130 Dokument specyfikacji wymagań oprogramowania3. Specific requirements 3.1 External interface requirements User interfaces Hardware interfaces Software interfaces Communications interfaces 3.2 System features System Feature Introduction/Purpose of feature Stimulus/Response sequence Associated functional requirements Functional requirement nFunctional requirement n System feature m System feature m 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements

131 Dokument specyfikacji wymagań oprogramowaniaSposób organizacji wymagań – wg bodźców Niektóre systemy mogą być najlepiej opisane, poprzez specyfikację funkcji systemu na bodźce. Na przykład, funkcje ESP czy ABS mogą być opisane przez bodźce: Zablokowanie kół przy hamowaniu Poślizg boczny pojazdu Uślizg kół …

132 Dokument specyfikacji wymagań oprogramowania3. Specific requirements 3.1 External interface requirements User interfaces Hardware interfaces Software interfaces Communications interfaces 3.2 Functional requirements Stimulus Functional requirement n Functional requirement 1.n Stimulus m Stimulus m 3.2.m.1 Functional requirement m m.nFunctional requirement m.n 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements

133 Dokument specyfikacji wymagań oprogramowaniaSposób organizacji wymagań – wg pożądanych reakcji Niektóre systemy mogą być najlepiej opisane, poprzez specyfikację pożądanych reakcji (odpowiedzi) systemu. Przykładowymi reakcjami/odpowiedziami systemu mogą być: Uniemożliwienie zablokowania kół przy hamowaniu Przyhamowanie koła Obniżenie momentu obrotowego przy ruszaniu …

134 Dokument specyfikacji wymagań oprogramowania3. Specific requirements 3.1 External interface requirements User interfaces Hardware interfaces Software interfaces Communications interfaces 3.2 Functional requirements Response Functional requirement n Functional requirement 1.n Response m Response m 3.2.m.1 Functional requirement m m.nFunctional requirement m.n 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements

135 Dokument specyfikacji wymagań oprogramowaniaSposób organizacji wymagań – wg hierarchii funkcjonalności Jeżeli żaden z powyższych systemów organizacji wymagań nie jest pomocny to można je zorganizować hierarchicznie według funkcjonalność pogrupowanych z uwagi na: Wspólne wejścia Wspólne wyjścia Dostęp do wspólnych danych wewnętrznych

136 Dokument specyfikacji wymagań oprogramowania3. Specific requirements 3.1 External interface requirements User interfaces Hardware interfaces Software interfaces Communications interfaces 3.2 Functional requirements Information flows Data flow diagram Data entities Pertinent processes Topology Data flow diagram Data entities Pertinent processes Topology n Data flow diagram n IEEE SOFTWARE REQUIREMENTS SPECIFICATIONS Std Copyright © 1998 IEEE. All rights reserved n.1 Data entities n.2 Pertinent processes n.3 Topology Process descriptions Process Input data entities Algorithm or formula of process Affected data entities Process Input data entities Algorithm or formula of process Affected data entities mProcess m m.1 Input data entities m.2 Algorithm or formula of process m.3 Affected data entities Data construct specifications Construct Record type Constituent fields Construct Record type Constituent fields p Construct p p.1 Record type p.2 Constituent fields Data dictionary Data element Name Representation Units/Format Precision/Accuracy Range Data element Name Representation Units/Format Precision/Accuracy Range q Data element q q.1 Name q.2 Representation q.3 Units/Format q.4 Precision/Accuracy q.5 Range Std IEEE RECOMMENDED PRACTICE FOR 26 Copyright © 1998 IEEE. All rights reserved. 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements

137 Dokument specyfikacji wymagań oprogramowaniaSpecyfikacja wymagań wg standardu IEEE Wstęp 1.1. Przeznaczenie dokumentu 1.2. Zakres produktu 1.3. Definicje, akronimy i skróty 1.4. Odwołania 1.5. Przegląd pozostałej części dokumentu 2. Ogólny opis 2.1. Wizja produktu 2.2. Funkcje produktu 2.3. Charakterystyka użytkowników 2.4. Ograniczenia 2.5. Założenia i zależności 3. Szczegółowe wymagania 4. Dodatki 5. Skorowidz

138 Dokument specyfikacji wymagań oprogramowania4. Dodatki Informacje dodatkowe mają za zadanie sprawić aby dokumentacja wymagań był łatwiejsza w użytkowaniu. Składają się na nie: Spis treści Indeksy Załączniki: Przykłady formatu danych wejściowych/wyjściowych Informacje dodatkowe, które mogą pomóc użytkownikom zrozumieć dokumentację Opis problemu, który ma być rozwiązany przez system …

139 Sposoby tworzenia specyfikacji wymagańWyrażenia w języku naturalnym Wymagania są opisywane za pomocą zdań w języku naturalnym. Każde wyrażenie powinno opisywać jedno wymaganie. Wymagania powinny być ponumerowane. Strukturalny język naturalny Wymagania są opisane za pomocą języka naturalnego na standardowym formularzu lub szablonie. Każde pole w szablonie dostarcza informacji o wybranym aspekcie wymagania. Języki do opisu projektów Podejście to wykorzystuje języki podobne od języków programowania ale z bardziej abstrakcyjnymi funkcjami umożliwiającymi określenie wymagań oraz zdefiniowanie modelu systemu. Języki te są obecnie rzadko stosowane, można je wykorzystywać do opisu interfejsów.

140 Sposoby tworzenia specyfikacji wymagańNotacja graficzna Do zdefiniowania wymagań funkcjonalnych systemu wykorzystywane są modele graficzne uzupełnione opisami np. UML – diagramy przypadków użycia, diagramy sekwencji, itp. Formalizacja z wykorzystaniem matematyki Specyfikacja wymagań tworzona jest w oparciu o automaty skończone lub teorie zbiorów. Pomimo, że taka notacja prowadzi do redukcji niejednoznaczności w dokumentacji wymagań nie jest ona często wykorzystywana ze względu na brak zrozumienia takiej formalnej specyfikacji przez klientów.

141 Sposoby tworzenia specyfikacji wymagańPrzykład opisu wymagań za pomocą języka strukturalnego Funkcja: Obliczenie dawki insuliny dawki insuliny do wstrzyknięcia Opis: Obliczenie dawki insulina która ma zostać dostarczona do pomy insulinowej Wejście: Bieżący odczyt poziomu cukru (r2) oraz dwa poprzednie odczyty (r0 i r1) Źródło: Bieżący odczyt z sensora, pozostałe z pamięci Wyjście: obliczona wielkość dawki insuliny Działanie: Dawka insuliny jest równa zero, jeśli poziom cukru jest stabilny lub spada oraz gdy poziom wzrasta, ale tempo wzrostu maleje. Jeśli poziom cukru rośnie i tempo wzrostu rośnie, dawka insuliny jest obliczana przez podzielenie przez 4 różnicy pomiędzy obecnym i poprzednim poziomem cukru. Wynik jest zaokrąglany. Jeśli wynik jest zaokrąglony do zera, to dawka insuliny jest ustawiana na najmniejszą jaka może być dostarczona. Wymagania: Dostępne dwa poprzednie odczyty poziomu cukru dzięki, którym można obliczyć szybkość zmian poziomu cukru Warunek wstępny: Zbiornik z insuliną zwiera przynajmniej jedną maksymalną dawkę insuliny Stan końcowy: r0 jest zastępowane przez r1 a r1 przez r2 Efekty uboczne: Brak

142

143 Koniec