Dr Karolina Muszyńska Opracowano na podstawie: Wiegers K., Beatty J., Specyfikacja oprogramowania. Inżynieria wymagań, Helion, 2014.

Prezentacja na temat: "Dr Karolina Muszyńska Opracowano na podstawie: Wiegers K., Beatty J., Specyfikacja oprogramowania. Inżynieria wymagań, Helion, 2014."— Zapis prezentacji:

1 Dr Karolina Muszyńska Opracowano na podstawie: Wiegers K., Beatty J., Specyfikacja oprogramowania. Inżynieria wymagań, Helion, 2014

2  SRS określa funkcjonalności oraz możliwości, które musi realizować system oprogramowania, a także definiuje charakterystyki oraz ograniczenia, które system powinien uwzględniać.  SRS w wystarczającym stopniu powinien opisywać zachowania systemu w różnych warunkach, jak i pożądane charakterystyki systemu, takie jak wydajność, bezpieczeństwo i użyteczność.  SRS jest podstawą przyszłego planowania, projektowania i kodowania projektu, a także stanowi bazę dla testów systemu oraz dokumentacji użytkownika. 2

3  Klientom, żeby wiedzieć jakiego produktu mogą się spodziewać  Menedżerom projektu do szacowania harmonogramów, nakładów oraz zasobów  Zespołom programistycznym, aby wiedzieć, co mają zbudować  Testerom w celu opracowywania testów, ich planowania, a także definiowania procedur testowych  Serwisantom oraz obsłudze technicznej w celu zrozumienia, co powinna robić każda część produktu  Autorom dokumentacji do opracowania podręczników oraz ekranów pomocy  Szkoleniowcom w celu tworzenia materiałów edukacyjnych  Działowi prawnemu aby sprawdzić czy wymagania są zgodne z odpowiednimi przepisami i regulacjami. 3

4  Kolejne niepowtarzalne numery - brak jakiegokolwiek grupowania i uporządkowania, z etykiet nie wynika czego dotyczy dane wymaganie (np. WF-24)  Numerowanie hierarchiczne – hierarchia może się mocno rozrosnąć, numery nie przekazują żadnej informacji na temat celu danego wymagania, a dodanie nowego wymagania powoduje przenumerowanie kolejnych wymagań (np. 3.4.4, 3.4.4.1, itd.)  Hierarchiczne znaczniki tekstowe – są ustrukturyzowane, niosą ze sobą treść i nie ma na nie wpływu dodawanie, usuwanie i przenoszenie innych wymagań (np. Drukuj.PotwierdźKopie); pełny i niepowtarzalny identyfikator każdego wymagania jest tworzony przez dołączenie etykiety każdego wiersza do nadrzędnej etykiety wiersza poprzedniego; mogą być jedynie problemy z wymyślaniem sensownych, niepowtarzalnych nazw, szczególnie jeżeli nad dokumentem pracuje jednocześnie wiele osób 4

5 Dołączanie projektów interfejsu użytkownika do SRS ma swoje zalety i wady  Zalety: ◦ wymagania stają się namacalne zarówno dla użytkowników, jak i programistów ◦ są to wydajne techniki służące do pozyskiwania i weryfikowania wymagań ◦ jeśli użytkownicy mają swoje oczekiwania dotyczące wyglądu i działania określonych elementów produktu i będą rozczarowani, jeśli nie zostaną one uwzględnione, to oczekiwania te należy uważać za wymagania  Wady: ◦ obrazy ekranów oraz architektura interfejsu użytkownika opisują rozwiązania i w rzeczywistości mogą nie definiować wymagań ◦ odraczanie tworzenia bazowego SRS do czasu, w którym gotowy będzie interfejs użytkownika, może spowolnić prace nad projektem ◦ niebezpieczeństwo że wymagania zostaną podporządkowane projektom graficznym, co z kolei może prowadzić do powstania luk funkcjonalnych 5

6 6

7  Cel ◦ identyfikacja produktu/aplikacji; opis grup czytelników, dla których przeznaczony jest dokument  Konwencje użyte w dokumencie ◦ opis standardów i konwencji typograficznych użytych w dokumencie  Zakres projektu ◦ opis specyfikowanego oprogramowania oraz jego celu, wraz z odniesieniem do celów użytkowników albo firmy oraz do celów i strategii biznesowych  Materiały uzupełniające ◦ lista wszystkich załączników do SRS wraz z odnośnikami 7

8  Perspektywa produktu ◦ opis kontekstu produktu i jego pochodzenia, ewentualny związek z innymi systemami (można dołączyć diagram kontekstowy lub mapę ekosystemu)  Klasy oraz charakterystyki użytkowników ◦ definicja różnych klas użytkowników i opis ich cech (klasy uprzywilejowane)  Środowisko operacyjne ◦ opis środowiska, w którym oprogramowanie będzie funkcjonować (platforma sprzętowa, systemy operacyjne, serwery, bazy danych)  Ograniczenia projektu oraz implementacji ◦ opis ograniczeń limitujących opcje dostępne dla programistów (np. konkretny język programowania, biblioteki kodu itp.)  Założenia i zależności ◦ opis przyjętych założeń dotyczących funkcjonalności systemu ◦ identyfikacja zależności systemu od czynników zewnętrznych 8

9  Wymagania funkcjonalne pogrupowane według określonego sposobu ◦ wg funkcjonalności systemu, obszarów funkcjonalności, przepływów procesów, przypadków użycia, trybów działania, klas użytkowników, bodźców i reakcji  Każda funkcjonalność powinna mieć zdefiniowaną nazwę, opis i priorytet  Dla każdej funkcjonalności wymienione są związane z nią wymagania funkcjonalne, czyli możliwości oprogramowania, które powinny zostać zaimplementowane, zanim użytkownik będzie mógł skorzystać z tej funkcjonalności albo zrealizować przypadek użycia ◦ należy dołączyć również opis tego jak produkt powinien reagować na możliwe do przewidzenia błędy oraz niewłaściwe dane wprowadzane przez użytkownika i jego nieprawidłowe zachowania 9

10  Logiczny model danych ◦ wizualna reprezentacja obiektów i zbiorów danych, które system będzie przetwarzać, oraz relacji, jakie między nimi zachodzą, np. diagram związków encji lub klas  Słownik danych ◦ definicja budowy struktur danych oraz znaczenie, typy, długości, formaty i dozwolone wartości danych tworzące te struktury  Raporty ◦ definicja i opis właściwości raportów, które będą generowane przez system, ewentualne szablony  Pozyskiwanie, integralność, przechowywanie i usuwanie danych ◦ opis tego, jak w systemie są pozyskiwane i przetwarzane dane, jakie są wymagania odnośnie potrzeby ochrony integralności danych ◦ identyfikacja koniecznych technik, np. tworzenie kopii bezpieczeństwa, kopii zapasowych itp. 10

11  Interfejsy użytkownika ◦ opis logicznych właściwości każdego interfejsu użytkownika (m.in. standardy dotyczące czcionek, obrazów, schematu kolorów, itd.)  Interfejsy oprogramowania ◦ opis połączeń między rozwijanym produktem a pozostałymi składnikami oprogramowania (m.in. sposób przenoszenia danych z jednego systemu do drugiego, rodzaje wymaganych usług, itp.) ◦ określenie wymagań pozafunkcjonalnych mających wpływ na interfejs, takich jak czasy i częstotliwości reakcji oraz procedury i ograniczenia związane z bezpieczeństwem  Interfejsy sprzętowe ◦ opis właściwości interfejsów łączących składniki programowe systemu ze składnikami sprzętowymi (np. lista kompatybilnych urządzeń, itp.)  Interfejsy komunikacyjne ◦ opis wymagań funkcji komunikacyjnych, w tym poczty elektronicznej, przeglądarek internetowych, protokołów sieciowych oraz formularzy elektronicznych. 11

12  Użyteczność ◦ opis wymagań użytecznościowych, które mają związek z łatwością uczenia się, prostotą korzystania, omijaniem błędów, powracaniem do stanu używalności, sprawnością interakcji oraz dostępnością.  Wydajność ◦ opis wymagań wydajnościowych dotyczących różnych operacji przeprowadzanych w systemie  Bezpieczeństwo ◦ określenie wymagań dotyczących kwestii bezpieczeństwa i prywatności, które mają wpływ na ograniczenie dostępu do produktu albo korzystania z niego (bezpieczeństwo danych i oprogramowania oraz fizyczne)  Zagrożenia ◦ definicja środków bezpieczeństwa lub działań, które należy podjąć, a także potencjalnych niebezpiecznych zachowań, którym należy zapobiegać  Inne – ważne dla klienta cechy produktu (dostępność, modyfikowalność, skalowalność, prostota instalacji, itp.) 12

13  Wymagania międzynarodowe i lokalizacyjne gwarantują, że z produktu będą mogły korzystać różne narodowości, pochodzące z innych kręgów kulturowych i położeń geograficznych niż te, w których produkt został stworzony  Tego typu wymagania mogą dotyczyć różnic w walutach; formatowaniu dat, liczb, adresów i numerów telefonów; językach, w tym różnych pisowni w obrębie tego samego języka; stosowanych symbolach i zestawach liter; kolejności imion i nazwisk; strefach czasowych; przepisach i regulacjach; kwestiach kulturowych i politycznych; stosowanych rozmiarach papieru; jednostkach miar i wag; napięciach elektrycznych, kształtach wtyczek i wielu innych. 13

14  Mogą to być wymagania mające na celu zachowanie zgodności produktu z przepisami prawnymi, regulacjami finansowymi lub standardami; m.in. wymagania związane z instalacją produktu, jego konfiguracją, uruchamianiem i zamykaniem, logowaniem, monitorowaniem i logowaniem zdarzeń systemu. 14

15 Dla poszczególnych wymagań:  Kompletność  Poprawność  Wykonalność  Niezbędność  Priorytet  Jednoznaczność  Weryfikowalność Dla zbiorów wymagań dodatkowo:  Spójność  Modyfikowalność  Możliwość śledzenia 15

16  Perspektywa systemu czy perspektywa użytkownika - wymagania funkcjonalne można pisać z perspektywy tego, co robi system, albo z perspektywy tego, co może robić użytkownik – oba podejścia są prawidłowe, ale należy używać konsekwentnie jednego rodzaju zwrotu, np. „System powinien…” lub „Użytkownik powinien…”, po którym następuje czasownik opisujący czynność oraz spodziewany wynik tej czynności. Przedtem powinien znaleźć się warunek, który spowoduje, że system zachowa się w określony sposób  Styl pisania wymagań - najważniejszą cechą dobrze napisanych wymagań jest łatwość ich czytania i zrozumienia, czyli trzeba zachować jasność i zwięzłość wypowiedzi; dobrze jest konsekwentnie stosować słowo „powinien”, wypowiedzi w stronie czynnej, nie łączyć kilku wymagań w jednym zdaniu  Poziom szczegółowości – zależy m.in. od wiedzy, doświadczenia i zaangażowania zespołu 16

17 17

18 18

19 19

20 20

21 21

22 22

23 23

24 24

25 25

26 Dr Karolina Muszyńska Opracowano na podstawie: Wiegers K., Beatty J., Specyfikacja oprogramowania. Inżynieria wymagań, Helion, 2014

27  Mianem atrybutu jakościowego można nazwać kilkadziesiąt rożnych cech produktu  Jeden ze sposobów klasyfikowania atrybutów jakościowych opiera się na odróżnieniu właściwości widocznych podczas działania oprogramowania - jakość zewnętrzna (ważna przede wszystkim dla użytkowników) od właściwości, które są wówczas niewidoczne - jakość wewnętrzna (ważna dla programistów i serwisantów, chociaż pośrednio wpływa też na zadowolenie klienta, sprawiając, że produkt jest łatwiejszy do wzbogacania, poprawiania, testowania oraz w przenoszeniu na nowe platformy) 27

28 28

29 29

30  Dostępność - przewidywany czas, podczas którego usługi systemu będą dostępne oraz w pełni sprawne System powinien być dostępny przez co najmniej 95% czasu w dni powszednie od godziny 6.00 do północy czasu środkowoeuropejskiego oraz przez co najmniej 99% czasu w dni powszednie między 15.00 a 17.00 czasu środkowoeuropejskiego.  Integralność – to zapobieganie utracie informacji oraz zachowanie spójności danych wprowadzonych do systemu; dane należy chronić przed takimi zagrożeniami jak: ich przypadkowa utrata lub zniszczenie; fizyczne uszkodzenie nośników danych; przypadkowe skasowanie pliku lub nadpisanie danych przez użytkownika; umyślne ataki mające na celu zniszczenie lub kradzież danych; integralność to także określnie formatów pól danych, ograniczanie danych przyjmowanych w polach do określonego typu lub długości, gwarantowanie, że elementy danych mają poprawne wartości, itd. 30

31  Wydajność - prędkość reagowania systemu na różne działania użytkowników 31

32  Wytrzymałość - określa, w jakim stopniu system może prawidłowo działać, gdy otrzyma niepoprawne dane, wystąpi awaria we współpracującym oprogramowaniu lub sprzęcie, nastąpi atak z zewnątrz lub pojawią się nieprzewidziane warunki pracy. Inne określenia związane z wytrzymałością to tolerancja na błędy czy przywracalność Jeśli w edytorze tekstów wystąpi awaria, zanim użytkownik zdoła zapisać plik, w chwili ponownego uruchomienia aplikacji system powinien odzyskać zawartość edytowanego pliku w postaci, jaką miał on najwyżej na minutę przed awarią.  Ochrona – dotyczy zapobiegania wyrządzaniu przez system urazów u jego użytkowników oraz szkód w ich własności Urządzenie do naświetleń terapeutycznych powinno zezwalać na naświetlenia tylko wtedy, gdy zamontowany jest odpowiedni filtr. 32

33  Użyteczność – odnosi się do wielu aspektów określanych przyjaznością dla użytkownika, prostotą użycia lub projektowaniem pod człowieka 33

34  Modyfikowalność – określa, jak łatwo można zrozumieć, zmieniać i rozszerzać projekt oprogramowania oraz jego kod 34

35  Przenośność – określa możliwości przenoszenia oprogramowania z jednego środowiska roboczego do innego (np. różne systemy operacyjne, urządzenia mobilne); do przenośności zalicza się również możliwości związane z internacjonalizacją oraz lokalizacją produktu  Skalowalność – określa możliwości poszerzenia aplikacji w taki sposób aby mogła ona przyjąć więcej użytkowników, danych, serwerów, lokalizacji geograficznych, transakcji, ruchu sieciowego, wykonać więcej operacji szukania lub innych usług bez pogorszenia wydajności i przy zachowaniu poprawności działania  Weryfikowalność – inaczej mówiąc testowalność, czyli możliwość sprawdzenia, czy poszczególne elementy produktu lub produkt traktowany jako całość funkcjonuje zgodnie z oczekiwaniami. 35