Inynieria systemw informacyjnych WYKAD I dr in Krzysztof

Inżynieria systemów informacyjnych WYKŁAD I dr inż. Krzysztof Michalak

Plan wykładu • • Tematy wykładów Literatura przedmiotu Zasady zaliczenia Podstawowe definicje

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

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

Zasady zaliczenia przedmiotu Laboratoria • 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

Podstawowe pojęcia • • System informacyjny System informatyczny Dane Informacja Projekt Uzasadnienie biznesowe Wymagania

Podstawowe pojęcia – System Podejś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.

Podstawowe pojęcia – System – 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.

Podstawowe pojęcia – System 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,

Podstawowe pojęcia – System informacyjny W 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łecznogospodarczym, w którym obok procesów informacyjnych zawsze występują zasoby oraz informacja.

Podstawowe pojęcia – System 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

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

Podstawowe pojęcia – System informacyjny Formalny 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.

Podstawowe pojęcia – System informacyjny Nieformalny 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

Podstawowe pojęcia – System informacyjny granice systemu Wejście, zasilenie U 2(a 2, a 3) U 1(a 1) System U 3(a 4, a 5, a 6) Otoczenie systemu Wyjście

Podstawowe pojęcia – System informacyjny Systemem informacyjnym nazywamy parę: • Obiektów (U – uniwersum) • Atrybutów (A – atrybuty) SI=(A, U) Prezentacja systemu informacyjnego w postaci tablicy SI = (U, A) A 1 A 2 A 3 U 1 1950 cm 3 9 l/100 km 8, 4 s U 2 1758 cm 3 7, 5 l/100 km 10, 1 s U 3 1645 cm 3 5, 7 l/100 km 12, 0 s U 4 1490 cm 3 4, 5 l/100 km 14, 5 s

Podstawowe pojęcia – System informacyjny Czy to jest prezentacja systemu informacyjnego ? ? ?

Podstawowe pojęcia – System 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).

Podstawowe pojęcia – System informatyczny Formalnie 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

Podstawowe pojęcia – System informatyczny Personel 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

Podstawowe pojęcia – System informatyczny Zbió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.

Podstawowe pojęcia – System informatyczny Relacje pomiędzy elementami systemu informatycznego – R = {Rp-p, Rp-t, Rt-i, Rp-i} • 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

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

Podstawowe pojęcia – Klasyfikacja systemów informatycznych Systemy 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)

Podstawowe pojęcia – Klasyfikacja systemów informatycznych Systemy 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)

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

Podstawowe pojęcia – Klasyfikacja systemów informatycznych Systemy 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

Podstawowe pojęcia – Klasyfikacja systemów informatycznych Rozwó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

Podstawowe pojęcia – Klasyfikacja systemów informatycznych Klasyfikacja 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

Podstawowe pojęcia – Klasyfikacja systemów informatycznych Klasyfikacja SI według liczby użytkowników • Systemy personalne • Systemy dla grup roboczych • Systemy departamentalne • Systemy dla wielkich organizacji Klasyfikacja wg dostępu • Systemy personalne • 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:

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

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?

System komputerowy Struktura systemu komputerowego: • Sprzęt • System 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.

Dane, informacje, wiedza Pierwsze 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.

Dane, informacje, wiedza •

Dane, informacje, wiedza Informacja 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

Dane, informacje, wiedza Autorzy 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

Dane, informacje, wiedza Autorzy Definicje danych Definicje informacji Hicks (1993, 3 rd 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ć

Dane, informacje, wiedza Autorzy 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ę Informacje pochodzą z danych, które z rozłącznych numerów, słów, symboli zostały przetworzone tak, by stały się i sylab odwołujących się do zjawisk użyteczne w podejmowaniu decyzji i procesów biznesu w zarządzaniu Źródło: Checkland P. , Holwell S. , „Information, Systems and Information Systems: making sense of the field”

Dane, informacje, wiedza Dane, 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ą.

Dane, informacje, wiedza Wiedza 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. ”

Dane, informacje, wiedza Cechy 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”

Dane, informacje, wiedza Wedł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

Dane, informacje, wiedza • Integralność – 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.

Dane, informacje, wiedza Wiedza spersonalizowana Mądrość Wiedza Informacja Dane Wiedza skodyfikowana

Dane, informacje, wiedza Rodzaje 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

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.

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

Uzasadnienie biznesowe Dlaczego 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.

Uzasadnienie 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

Wymagania na podstawie Ian Sommerville Software Engineering wyd. 9

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ń.

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ć!!!

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.

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.

Wymagania Wymaganie użytkownika 1. System 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

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

Wymagania funkcjonalne, niefunkcjonalne i dziedzinowe Wymagania 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.

Wymagania funkcjonalne, niefunkcjonalne i dziedzinowe Wymagania 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

Wymagania 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ń

Wymagania 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ątki itp. Problem – przejście z wymagań użytkownika do wymagań systemowych może odbywać się na różnych poziomach szczegółowości.

Wymagania funkcjonalne Problemy 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

Wymagania 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.

Wymagania funkcjonalne W 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.

Wymagania 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!!!

Wymagania 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.

Wymagania niefunkcjonalne Stosunkowo ł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

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

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

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

Wymagania niefunkcjonalne Certyfikacyjne Wymagania zewnętrzne 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.

Wymagania niefunkcjonalne Podstawowym 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.

Wymagania niefunkcjonalne Wymaganie 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

Wymagania niefunkcjonalne Szybkość 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 Niezawodność Średni czas między awariami Liczba kontaktów z helpdeskiem 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

Dokument specyfikacji wymagań oprogramowania Cechy poprawnej dokumentacji wymagań wg IEEE 830 -1998 • 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ń

Dokument specyfikacji wymagań oprogramowania Poprawność 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.

Dokument specyfikacji wymagań oprogramowania Jednoznaczność 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.

Dokument specyfikacji wymagań oprogramowania Kompletność 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.

Dokument specyfikacji wymagań oprogramowania Spó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 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.

Dokument specyfikacji wymagań oprogramowania Uporzą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 Mo. SCo. W: • Must have • Should have • Coudl have • Won’t have

Dokument specyfikacji wymagań oprogramowania Moż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

Dokument specyfikacji wymagań oprogramowania Modyfikowalność 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

Dokument specyfikacji wymagań oprogramowania Moż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).

Dokument specyfikacji wymagań oprogramowania Dokument 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

Dokument specyfikacji wymagań oprogramowania Klienci 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

Dokument specyfikacji wymagań oprogramowania Róż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ń.

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

Dokument specyfikacji wymagań oprogramowania Przedmowa 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

Dokument specyfikacji wymagań oprogramowania Definicja 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.

Dokument specyfikacji wymagań oprogramowania Modele 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.

Dokument specyfikacji wymagań oprogramowania Specyfikacja wymagań wg standardu IEEE 830 -1998 1. 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

Dokument specyfikacji wymagań oprogramowania 1. 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ń

Dokument specyfikacji wymagań oprogramowania 1. 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ń)

Dokument specyfikacji wymagań oprogramowania 1. 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.

Dokument specyfikacji wymagań oprogramowania 1. 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.

Dokument specyfikacji wymagań oprogramowania 1. 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ń.

Dokument specyfikacji wymagań oprogramowania 1. 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.

Dokument specyfikacji wymagań oprogramowania 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 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.

Dokument specyfikacji wymagań oprogramowania 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 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.

Dokument specyfikacji wymagań oprogramowania 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 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

Dokument specyfikacji wymagań oprogramowania 2. 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.

Dokument specyfikacji wymagań oprogramowania 2. 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ć.

Dokument specyfikacji wymagań oprogramowania 2. 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.

Dokument specyfikacji wymagań oprogramowania 2. 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

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

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

Dokument specyfikacji wymagań oprogramowania 2. 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.

Dokument specyfikacji wymagań oprogramowania 2. 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.

Dokument specyfikacji wymagań oprogramowania 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 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.

Dokument specyfikacji wymagań oprogramowania 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 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.

Dokument specyfikacji wymagań oprogramowania 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 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

Dokument specyfikacji wymagań oprogramowania 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 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.

Dokument specyfikacji wymagań oprogramowania 3. 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.

Dokument specyfikacji wymagań oprogramowania 3. 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ść.

Dokument specyfikacji wymagań oprogramowania 3. 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

Dokument specyfikacji wymagań oprogramowania 3. 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

Dokument specyfikacji wymagań oprogramowania 3. 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.

Dokument specyfikacji wymagań oprogramowania 3. 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

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

Dokument specyfikacji wymagań oprogramowania 3. 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. 24 h/7 dni. czasy odzyskiwania po awarii, czasy restartu

Dokument specyfikacji wymagań oprogramowania 3. 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.

Dokument specyfikacji wymagań oprogramowania 3. 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ń.

Dokument specyfikacji wymagań oprogramowania Sposó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.

Dokument specyfikacji wymagań oprogramowania 3. Specific requirements 3. 1 External interface requirements 3. 1. 1 User interfaces 3. 1. 2 Hardware interfaces 3. 1. 3 Software interfaces 3. 1. 4 Communications interfaces 3. 2 Functional requirements 3. 2. 1 Mode 1 3. 2. 1. 1 Functional requirement 1. 1. 3. 2. 1. n Functional requirement 1. n 3. 2. 2 Mode 2. 3. 2. m Mode m 3. 2. m. 1 Functional requirement m. 1. 3. 2. m. n. Functional requirement m. n 3. 3 Performance requirements 3. 4 Design constraints 3. 5 Software system attributes 3. 6 Other requirements 3. Specific requirements 3. 1. Functional requirements 3. 1. 1 Mode 1 3. 1. 1. 1 External interfaces 3. 1. 1 User interfaces 3. 1. 1. 1. 2 Hardware interfaces 3. 1. 1. 1. 3 Software interfaces 3. 1. 1. 1. 4 Communications interfaces 3. 1. 1. 2 Functional requirements 3. 1. 1. 2. 1 Functional requirement 1. 3. 1. 1. 2. n. Functional requirement n 3. 1. 1. 3 Performance 3. 1. 2 Mode 2. 3. 1. m Mode m 3. 2 Design constraints 3. 3 Software system attributes 3. 4 Other requirements

Dokument specyfikacji wymagań oprogramowania Sposó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.

Dokument specyfikacji wymagań oprogramowania 3. Specific requirements 3. 1 External interface requirements 3. 1. 1 User interfaces 3. 1. 2 Hardware interfaces 3. 1. 3 Software interfaces 3. 1. 4 Communications interfaces 3. 2 Functional requirements 3. 2. 1 User class 1 3. 2. 1. 1 Functional requirement 1. 1. . 3. 2. 1. n Functional requirement 1. n 3. 2. 2 User class 2. . 3. 2. m User class m 3. 2. m. 1 Functional requirement m. 1. . 3. 2. m. n. Functional requirement m. n 3. 3 Performance requirements 3. 4 Design constraints 3. 5 Software system attributes 3. 6 Other requirements

Dokument specyfikacji wymagań oprogramowania Sposó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 • …

Dokument specyfikacji wymagań oprogramowania 3. Specific requirements 3. 1 External interface requirements 3. 1. 1 User interfaces 3. 1. 2 Hardware interfaces 3. 1. 3 Software interfaces 3. 1. 4 Communications interfaces 3. 2 Classes/Objects 3. 2. 1 Class/Object 1 3. 2. 1. 1 Attributes (direct or inherited) 3. 2. 1. 1. 1 Attribute 1. 3. 2. 1. 1. n. Attribute n 3. 2. 1. 2 Functions (services, methods, direct or inherited) 3. 2. 1 Functional requirement 1. 1. 3. 2. 1. 2. m. Functional requirement 1. m 3. 2. 1. 3 Messages (communications received or sent) 3. 2. 2 Class/Object 2. 3. 2. p Class/Object p 3. 3 Performance requirements 3. 4 Design constraints 3. 5 Software system attributes 3. 6 Other requirements

Dokument specyfikacji wymagań oprogramowania Sposó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 • …

Dokument specyfikacji wymagań oprogramowania 3. Specific requirements 3. 1 External interface requirements 3. 1. 1 User interfaces 3. 1. 2 Hardware interfaces 3. 1. 3 Software interfaces 3. 1. 4 Communications interfaces 3. 2 System features 3. 2. 1 System Feature 1 3. 2. 1. 1 Introduction/Purpose of feature 3. 2. 1. 2 Stimulus/Response sequence 3. 2. 1. 3 Associated functional requirements 3. 2. 1. 3. 1 Functional requirement 1. 3. 2. 1. 3. n. Functional requirement n 3. 2. 2 System feature 2. 3. 2. m System feature m. 3. 3 Performance requirements 3. 4 Design constraints 3. 5 Software system attributes 3. 6 Other requirements

Dokument specyfikacji wymagań oprogramowania Sposó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ół • …

Dokument specyfikacji wymagań oprogramowania 3. Specific requirements 3. 1 External interface requirements 3. 1. 1 User interfaces 3. 1. 2 Hardware interfaces 3. 1. 3 Software interfaces 3. 1. 4 Communications interfaces 3. 2 Functional requirements 3. 2. 1 Stimulus 1 3. 2. 1. 1 Functional requirement 1. 1. 3. 2. 1. n Functional requirement 1. n 3. 2. 2 Stimulus 2. 3. 2. m Stimulus m 3. 2. m. 1 Functional requirement m. 1. 3. 2. m. n. Functional requirement m. n 3. 3 Performance requirements 3. 4 Design constraints 3. 5 Software system attributes 3. 6 Other requirements

Dokument specyfikacji wymagań oprogramowania Sposó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 • …

Dokument specyfikacji wymagań oprogramowania 3. Specific requirements 3. 1 External interface requirements 3. 1. 1 User interfaces 3. 1. 2 Hardware interfaces 3. 1. 3 Software interfaces 3. 1. 4 Communications interfaces 3. 2 Functional requirements 3. 2. 1 Response 1 3. 2. 1. 1 Functional requirement 1. 1. 3. 2. 1. n Functional requirement 1. n 3. 2. 2 Response 2. 3. 2. m Response m 3. 2. m. 1 Functional requirement m. 1. 3. 2. m. n. Functional requirement m. n 3. 3 Performance requirements 3. 4 Design constraints 3. 5 Software system attributes 3. 6 Other requirements

Dokument specyfikacji wymagań oprogramowania Sposó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

Dokument specyfikacji wymagań oprogramowania 3. Specific requirements 3. 1 External interface requirements 3. 1. 1 User interfaces 3. 1. 2 Hardware interfaces 3. 1. 3 Software interfaces 3. 1. 4 Communications interfaces 3. 2 Functional requirements 3. 2. 1 Information flows 3. 2. 1. 1 Data flow diagram 1 3. 2. 1. 1. 1 Data entities 3. 2. 1. 1. 2 Pertinent processes 3. 2. 1. 1. 3 Topology 3. 2. 1. 2 Data flow diagram 2 3. 2. 1 Data entities 3. 2. 1. 2. 2 Pertinent processes 3. 2. 1. 2. 3 Topology. 3. 2. 1. n Data flow diagram n IEEE SOFTWARE REQUIREMENTS SPECIFICATIONS Std 830 -1998 Copyright © 1998 IEEE. All rights reserved. 25 3. 2. 1. n. 1 Data entities 3. 2. 1. n. 2 Pertinent processes 3. 2. 1. n. 3 Topology 3. 2. 2 Process descriptions 3. 2. 2. 1 Process 1 3. 2. 2. 1. 1 Input data entities 3. 2. 2. 1. 2 Algorithm or formula of process 3. 2. 2. 1. 3 Affected data entities 3. 2. 2. 2 Process 2 3. 2. 2. 2. 1 Input data entities 3. 2. 2 Algorithm or formula of process 3. 2. 2. 2. 3 Affected data entities. 3. 2. 2. m. Process m 3. 2. 2. m. 1 Input data entities 3. 2. 2. m. 2 Algorithm or formula of process 3. 2. 2. m. 3 Affected data entities 3. 2. 3 Data construct specifications 3. 2. 3. 1 Construct 1 3. 2. 3. 1. 1 Record type 3. 2. 3. 1. 2 Constituent fields 3. 2 Construct 2 3. 2. 1 Record type 3. 2. 2 Constituent fields. 3. 2. 3. p Construct p 3. 2. 3. p. 1 Record type 3. 2. 3. p. 2 Constituent fields 3. 2. 4 Data dictionary 3. 2. 4. 1 Data element 1 3. 2. 4. 1. 1 Name 3. 2. 4. 1. 2 Representation 3. 2. 4. 1. 3 Units/Format 3. 2. 4. 1. 4 Precision/Accuracy 3. 2. 4. 1. 5 Range 3. 2. 4. 2 Data element 2 3. 2. 4. 2. 1 Name 3. 2. 4. 2. 2 Representation 3. 2. 4. 2. 3 Units/Format 3. 2. 4 Precision/Accuracy 3. 2. 4. 2. 5 Range. 3. 2. 4. q Data element q 3. 2. 4. q. 1 Name 3. 2. 4. q. 2 Representation 3. 2. 4. q. 3 Units/Format 3. 2. 4. q. 4 Precision/Accuracy 3. 2. 4. q. 5 Range IEEE Std 830 -1998 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

Dokument specyfikacji wymagań oprogramowania Specyfikacja wymagań wg standardu IEEE 830 -1998 1. 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

Dokument specyfikacji wymagań oprogramowania 4. 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 • …

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.

Sposoby tworzenia specyfikacji wymagań Notacja graficzna Formalizacja z wykorzystaniem matematyki Do zdefiniowania wymagań funkcjonalnych systemu wykorzystywane są modele graficzne uzupełnione opisami np. UML – diagramy przypadków użycia, diagramy sekwencji, itp. 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.

Sposoby tworzenia specyfikacji wymagań Przykład opisu wymagań za pomocą języka strukturalnego Funkcja: Obliczenie dawki insuliny do wstrzyknięcia Opis: Obliczenie dawki insulina która ma zostać dostarczona do pomy insulinowej Wejście: Bieżący odczyt poziomu cukru (r 2) oraz dwa poprzednie odczyty (r 0 i r 1) Ź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: r 0 jest zastępowane przez r 1 a r 1 przez r 2 Efekty uboczne: Brak

Koniec