Inżynieria systemów informacyjnychWYKŁ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 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

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• System informacyjny• System informatyczny• Dane• Informacja• Projekt• Uzasadnienie biznesowe• Wymagania

Podstawowe pojęcia – SystemPodejście filozoficzneSystemem 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 cybernetyczneSystem jest to zbiór elementów i zachodzących między nimi relacji.

Podstawowe pojęcia – System

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 – 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,

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.

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 informacyjnyP – zbiór podmiotów użytkujących dany systemI – zbiór informacji o sferze realnejT – zbiór narzędzi technicznychO – 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 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.

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

Podstawowe pojęcia – System

Otoczenie systemu

System

granice systemu

U1(a1)U2(a2,a3)

U3(a4,a5,a6)

Wejście, zasilenie

Wyjście

Podstawowe pojęcia – System informacyjny

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

Podstawowe pojęcia – System informacyjny

Czy to jest prezentacja systemu informacyjnego ???

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

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 systemuI – dane i informacjeT – zbiór urządzeń i narzędzi technologii informatycznejO – zbiór stosowanych rozwiązań organizacyjnychM – zbiór metainformacjiR – relacje pomiędzy elementami systemu informatycznegoN – infrastruktura i otoczenie systemu informatycznego

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

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.

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

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

Podstawowe pojęcia – System informatyczny

EIS ESS

DSSMIS

TPS, OAS

strategia

decyzje

informacja

dane

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

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

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

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 informatycznychFazy życia systemu informatycznego• Planowanie• Analiza• Projektowanie • Implementacja• Testowanie• Wdrożenie• Eksploatacja• Wycofanie

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?

System komputerowyStruktura 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, wiedzaIlość informacji otrzymanej przy zajściu zdarzenia xi (entropia tego zdarzenia, entropia indywidualna, samoinformacja komunikatu) (Hartley):

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

Dane, informacje, wiedzaInformacja według LangeforsaInfologiczna 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 LangeforsaI = i(D, S, t)

gdzie: I – informacja i – proces interpretacji D – dane S – przedwiedza t -- czas

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

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ć

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”

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

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, 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”

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

Mądrość

Wiedza

Informacja

Dane

Wiedza spersonalizowana

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

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

ProjektPodstawowe 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

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

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

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

WymaganiaWedł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

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.

WymaganiaWymaganie użytkownika1. System powinien umożliwiać wystawienie faktury VAT

Wymaganie systemowe1.1. Użytkownik powinien mieć możliwość wystawienia faktury VAT1.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ści1.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

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

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

Wymagania funkcjonalne

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

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ś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

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

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

Wymagania niefunkcjonalne

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

Wymagania niefunkcjonalne

Wymagania produktowe

Użyteczność

EfektywnośćSzybkość

Zajętość pamięciNiezawodność

Bezpieczeństwo

Wymagania organizacyjne

Środowiskowe

Operacyjne

Implementacyjne

Wymagania zewnętrzne

Certyfikacyjne

Etyczne

Prawne

Ustawa o rachunkowości

Bezpieczeństwo i ochrona informacji

Wymagania niefunkcjonalne

Wymagania produktowe – definiują lub ograniczają zachowanie systemu.

Wymagania produktowe

Użyteczność

EfektywnośćSzybkość

Zajętość pamięciNiezawodność

Bezpieczeństwo

Wymagania niefunkcjonalne

Wymagania organizacyjne – wynikają z procedur obowiązujących w organizacji klienta i dostawcy systemu.

Wymagania organizacyjne

Środowiskowe

Operacyjne

Implementacyjne

Wymagania niefunkcjonalne

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 zewnętrzne

Certyfikacyjne

Etyczne

Prawne

Ustawa o rachunkowości

Bezpieczeństwo i ochrona informacji

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 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 awariamiPrawdopodobieństwo niedostępności systemuCzęstotliwość występowania błędówGwarantowany 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ść dokumentacjiDokumentacja 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ść dokumentacjiDokumentacja 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ść dokumentacjiDokumentacja 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ść dokumentacjiSpó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.

Dokument specyfikacji wymagań oprogramowania Uporządkowanie dokumentacji wg ważności/spójnościPolega 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

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ść dokumentacjiDokumentacja 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-19981. Wstęp

1.1. Przeznaczenie dokumentu1.2. Zakres produktu1.3. Definicje, akronimy i skróty1.4. Odwołania1.5. Przegląd pozostałej części dokumentu

2. Ogólny opis2.1. Wizja produktu2.2. Funkcje produktu2.3. Charakterystyka użytkowników2.4. Ograniczenia2.5. Założenia i zależności

3. Szczegółowe wymagania4. Dodatki5. Skorowidz

Dokument specyfikacji wymagań oprogramowania 1. Wstęp

1.1. Przeznaczenie dokumentu1.2. Zakres produktu1.3. Definicje, akronimy i skróty1.4. Odwołania1.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 dokumentu1.2. Zakres produktu1.3. Definicje, akronimy i skróty1.4. Odwołania1.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 dokumentu1.2. Zakres produktu1.3. Definicje, akronimy i skróty1.4. Odwołania1.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ęciaZakres produktu powinien być spójny z kolejnymi rozdziałami np. specyfikacją wymagań systemowych.

Dokument specyfikacji wymagań oprogramowania 1. Wstęp

1.1. Przeznaczenie dokumentu1.2. Zakres produktu1.3. Definicje, akronimy i skróty1.4. Odwołania1.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 dokumentu1.2. Zakres produktu1.3. Definicje, akronimy i skróty1.4. Odwołania1.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 dokumentu1.2. Zakres produktu1.3. Definicje, akronimy i skróty1.4. Odwołania1.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 produktu2.2. Funkcje produktu2.3. Charakterystyka użytkowników2.4. Ograniczenia2.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 opis2.1. Wizja produktu2.2. Funkcje produktu2.3. Charakterystyka użytkowników2.4. Ograniczenia2.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 opis2.1. Wizja produktu2.2. Funkcje produktu2.3. Charakterystyka użytkowników2.4. Ograniczenia2.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 produktu2.2. Funkcje produktu2.3. Charakterystyka użytkowników2.4. Ograniczenia2.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 produktu2.2. Funkcje produktu2.3. Charakterystyka użytkowników2.4. Ograniczenia2.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 opis2.1. Wizja produktu2.2. Funkcje produktu2.3. Charakterystyka użytkowników2.4. Ograniczenia2.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 produktu2.2. Funkcje produktu2.3. Charakterystyka użytkowników2.4. Ograniczenia2.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

wymaganiaSpecyfikacja 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. 24h/7dni. 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 requirements3.1 External interface requirements3.1.1 User interfaces3.1.2 Hardware interfaces3.1.3 Software interfaces3.1.4 Communications interfaces3.2 Functional requirements3.2.1 Mode 13.2.1.1 Functional requirement 1.1.3.2.1.n Functional requirement 1.n3.2.2 Mode 2.3.2.m Mode m3.2.m.1 Functional requirement m.1.3.2.m.nFunctional requirement m.n3.3 Performance requirements3.4 Design constraints3.5 Software system attributes3.6 Other requirements3. Specific requirements

3.1. Functional requirements3.1.1 Mode 13.1.1.1 External interfaces3.1.1.1.1 User interfaces3.1.1.1.2 Hardware interfaces3.1.1.1.3 Software interfaces3.1.1.1.4 Communications interfaces3.1.1.2 Functional requirements3.1.1.2.1 Functional requirement 1.3.1.1.2.nFunctional requirement n3.1.1.3 Performance3.1.2 Mode 2.3.1.m Mode m3.2 Design constraints3.3 Software system attributes3.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 requirements3.1 External interface requirements3.1.1 User interfaces3.1.2 Hardware interfaces3.1.3 Software interfaces3.1.4 Communications interfaces3.2 Functional requirements3.2.1 User class 13.2.1.1 Functional requirement 1.1..3.2.1.n Functional requirement 1.n3.2.2 User class 2..3.2.m User class m3.2.m.1 Functional requirement m.1..3.2.m.nFunctional requirement m.n3.3 Performance requirements3.4 Design constraints3.5 Software system attributes3.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 requirements3.1 External interface requirements3.1.1 User interfaces3.1.2 Hardware interfaces3.1.3 Software interfaces3.1.4 Communications interfaces3.2 Classes/Objects3.2.1 Class/Object 13.2.1.1 Attributes (direct or inherited)3.2.1.1.1 Attribute 1.3.2.1.1.nAttribute n3.2.1.2 Functions (services, methods, direct or inherited)3.2.1.2.1 Functional requirement 1.1.3.2.1.2.mFunctional requirement 1.m3.2.1.3 Messages (communications received or sent)3.2.2 Class/Object 2.3.2.p Class/Object p3.3 Performance requirements3.4 Design constraints3.5 Software system attributes3.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 requirements3.1 External interface requirements3.1.1 User interfaces3.1.2 Hardware interfaces3.1.3 Software interfaces3.1.4 Communications interfaces3.2 System features3.2.1 System Feature 13.2.1.1 Introduction/Purpose of feature3.2.1.2 Stimulus/Response sequence3.2.1.3 Associated functional requirements3.2.1.3.1 Functional requirement 1.3.2.1.3.nFunctional requirement n3.2.2 System feature 2.3.2.m System feature m.3.3 Performance requirements3.4 Design constraints3.5 Software system attributes3.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 requirements3.1 External interface requirements3.1.1 User interfaces3.1.2 Hardware interfaces3.1.3 Software interfaces3.1.4 Communications interfaces3.2 Functional requirements3.2.1 Stimulus 13.2.1.1 Functional requirement 1.1.3.2.1.n Functional requirement 1.n3.2.2 Stimulus 2.3.2.m Stimulus m3.2.m.1 Functional requirement m.1.3.2.m.nFunctional requirement m.n3.3 Performance requirements3.4 Design constraints3.5 Software system attributes3.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 requirements3.1 External interface requirements3.1.1 User interfaces3.1.2 Hardware interfaces3.1.3 Software interfaces3.1.4 Communications interfaces3.2 Functional requirements3.2.1 Response 13.2.1.1 Functional requirement 1.1.3.2.1.n Functional requirement 1.n3.2.2 Response 2.3.2.m Response m3.2.m.1 Functional requirement m.1.3.2.m.nFunctional requirement m.n3.3 Performance requirements3.4 Design constraints3.5 Software system attributes3.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 requirements3.1 External interface requirements3.1.1 User interfaces3.1.2 Hardware interfaces3.1.3 Software interfaces3.1.4 Communications interfaces3.2 Functional requirements3.2.1 Information flows3.2.1.1 Data flow diagram 13.2.1.1.1 Data entities3.2.1.1.2 Pertinent processes3.2.1.1.3 Topology3.2.1.2 Data flow diagram 23.2.1.2.1 Data entities3.2.1.2.2 Pertinent processes3.2.1.2.3 Topology.3.2.1.n Data flow diagram nIEEESOFTWARE REQUIREMENTS SPECIFICATIONS Std 830-1998Copyright © 1998 IEEE. All rights reserved. 253.2.1.n.1 Data entities3.2.1.n.2 Pertinent processes3.2.1.n.3 Topology3.2.2 Process descriptions3.2.2.1 Process 13.2.2.1.1 Input data entities3.2.2.1.2 Algorithm or formula of process3.2.2.1.3 Affected data entities3.2.2.2 Process 23.2.2.2.1 Input data entities3.2.2.2.2 Algorithm or formula of process3.2.2.2.3 Affected data entities.3.2.2.mProcess m3.2.2.m.1 Input data entities3.2.2.m.2 Algorithm or formula of process3.2.2.m.3 Affected data entities3.2.3 Data construct specifications

3.2.3.1 Construct 13.2.3.1.1 Record type3.2.3.1.2 Constituent fields3.2.3.2 Construct 23.2.3.2.1 Record type3.2.3.2.2 Constituent fields.3.2.3.p Construct p3.2.3.p.1 Record type3.2.3.p.2 Constituent fields3.2.4 Data dictionary3.2.4.1 Data element 13.2.4.1.1 Name3.2.4.1.2 Representation3.2.4.1.3 Units/Format3.2.4.1.4 Precision/Accuracy3.2.4.1.5 Range3.2.4.2 Data element 23.2.4.2.1 Name3.2.4.2.2 Representation3.2.4.2.3 Units/Format3.2.4.2.4 Precision/Accuracy3.2.4.2.5 Range.3.2.4.q Data element q3.2.4.q.1 Name3.2.4.q.2 Representation3.2.4.q.3 Units/Format3.2.4.q.4 Precision/Accuracy3.2.4.q.5 RangeIEEEStd 830-1998 IEEE RECOMMENDED PRACTICE FOR26 Copyright © 1998 IEEE. All rights reserved.3.3 Performance requirements3.4 Design constraints3.5 Software system attributes3.6 Other requirements

Dokument specyfikacji wymagań oprogramowania

Specyfikacja wymagań wg standardu IEEE 830-19981. Wstęp

1.1. Przeznaczenie dokumentu1.2. Zakres produktu1.3. Definicje, akronimy i skróty1.4. Odwołania1.5. Przegląd pozostałej części dokumentu

2. Ogólny opis2.1. Wizja produktu2.2. Funkcje produktu2.3. Charakterystyka użytkowników2.4. Ograniczenia2.5. Założenia i zależności

3. Szczegółowe wymagania4. Dodatki5. 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 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.

Sposoby tworzenia specyfikacji wymagań

Przykład opisu wymagań za pomocą języka strukturalnegoFunkcja: Obliczenie dawki insuliny dawki insuliny do wstrzyknięciaOpis: 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ęciWyjście: obliczona wielkość dawki insulinyDział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 cukruWarunek wstępny: Zbiornik z insuliną zwiera przynajmniej jedną maksymalną dawkę insulinyStan końcowy: r0 jest zastępowane przez r1 a r1 przez r2Efekty uboczne: Brak

Koniec