1PODSTAWY INŻYNIERII WYMAGAŃ
Ten rozdział składa się z dwóch podrozdziałów: "Wprowadzenie do wymagań" oraz "Standardy i normy". W pierwszym są podane podstawowe informacje na temat wymagań, ich atrybutów, kategoryzacji i podstawowych typów oraz wyjaśnienia, dlaczego wymagania są ważne dla sukcesu projektu i jakie konsekwencje wynikają z zaniedbywania jakości wymagań. Jest tu również ogólnie wyjaśnione, na czym polega proces inżynierii wymagań oraz jego podprocesy: opracowywanie wymagań i zarządzanie wymaganiami.
W drugim podrozdziale zostały opisane najważniejsze normy i standardy, które mają zastosowanie w dziedzinie inżynierii wymagań, aby umożliwić odniesienie się do najlepszych praktyk i standardów pozwalających na zwiększenie jakości i skuteczności procesu inżynierii wymagań oraz jego produktów.
Wyjaśnione są następujące pojęcia:
- inżynieria wymagań - kryteria jakości dla wymagań - krytyczność - ograniczenia biznesowe - ograniczenia techniczne - ograniczenie - opracowywanie wymagań - priorytet - problem biznesowy - produkt - rozwiązanie - system - walidacja - weryfikacja - wymagania funkcjonalne - wymagania niefunkcjonalne - wymagania produktowe - wymaganie - zarządzanie wymaganiami - zobowiązanie -
1.1. Wprowadzenie do wymagań
Celem tego podrozdziału jest zrozumienie znaczenia wymagań oraz wyjaśnienie podstawowych definicji i terminów niezbędnych do dalszej lektury i nauki.
1.1.1. Pojęcie problemu, rozwiązania i produktu
Punktem startowym w inżynierii wymagań są problemy, potrzeby i/lub cele biznesowe. Problem biznesowy przedstawia potrzeby klienta lub pomaga je opisać (zarówno zewnętrznego, jak i wewnętrznego), co oznacza, że można go uznać za jedną z głównych informacji wejściowych dla inżynierii wymagań.
Definicja 1.1. Problem biznesowy
Problem biznesowy (ang. business problem) opisuje to, co chce zrobić klient w celu realizacji swoich procesów biznesowych lub ich usprawnienia.
Jednym z głównych celów inżynierii wymagań jest znalezienie rozwiązań dla zidentyfikowanych problemów biznesowych, zaspokojenie potrzeb czy wskazanie celów biznesowych.
Definicja 1.2. Rozwiązanie
Rozwiązanie (ang. solution) jest odpowiedzią na potrzeby klienta.
Potrzeby interesariuszy są zwykle wyrażone jako wysokopoziomowe wymagania biznesowe i są kolejną informacją wejściową dla inżynierii wymagań. Rozwiązaniem określonych problemów czy zaspokojeniem potrzeb może być system lub komponent systemu, nowe funkcje lub modyfikacja tych już istniejących, zmiana konfiguracji, usprawnienie wniesione do procesu itp. Ogólnie rzecz biorąc, rozwiązanie można uznać za rozwinięcie wymagań wyższego poziomu.
Szczególnie ważne jest to, aby mieć świadomość istnienia kilku (a czasem nawet kilkunastu) różnych rozwiązań umożliwiających zaspokojenie potrzeb biznesowych klienta. Na przykład, jeśli klient wymaga zwiększenia efektywności przetwarzania dokumentów w organizacji, rozwiązaniem może być:
- zmiana procedur związanych z przetwarzaniem dokumentów;
- zastosowanie systemu wspierającego przepływ pracy;
- opracowanie i wdrożenie własnego systemu dostosowanego do pracy zgodnie z procesami wykonywanymi w danej organizacji;
- szkolenie personelu w obszarze optymalizacji procesów związanych z przetwarzaniem dokumentów.
Ponieważ istnieje wiele sposobów zaspokojenia jednego wymagania biznesowego, należy mieć pewne środki umożliwiające podjęcie decyzji dotyczącej wyboru optymalnego rozwiązania. Dlatego jednym z celów inżynierii wymagań jest opracowanie i dostarczenie propozycji rozwiązania, która byłaby najlepszym sposobem zaspokojenia potrzeb klienta w danych okolicznościach i pod określonymi warunkami.
Rozwiązania są tworzone podczas procesu wytwarzania (realizacji). Wynikiem procesu realizacji jest produkt. Typowymi produktami są: rozwiązania programowe lub sprzętowe, usługi, procesy biznesowe, dokumentacja itd.
Definicja 1.3. Produkt
Produkt (ang. product) to wynik procesu realizacji.
W omówionym powyżej przykładzie produktem może być:
- dokumentacja optymalizacji procesów biznesowych;
- system przepływu pracy wraz z jego dokumentacją;
- materiały szkoleniowe.
1.1.2. Definicja i klasyfikacja wymagań
"Chcę, żeby system automatyzował pewne czynności wykonywane przez moich pracowników". "Chcę, żeby system automatycznie generował raporty". "Chcę, by kopia zamówienia była przesyłana automatycznie do działu finansowego".
Za każdym razem, kiedy mówimy o oczekiwaniach i potrzebach klienta dotyczących oprogramowania (lub innego rozwiązania), mówimy o wymaganiach. Czym więc jest wymaganie? Dowolnym życzeniem klienta? Nie do końca. Wymaganie jest czymś, czego klient oczekuje od rozwiązania. To coś musi stanowić pewną wartość - w większości przypadków wartość umożliwiającą poprawienie wyników biznesowych danej firmy.
A zatem, co jest wymaganiem? Podążając za definicją zawartą w IEEE 610, możemy zdefiniować wymaganie w następujący sposób:
Definicja 1.4. Wymaganie
Wymaganie (ang. requirement):
(1) Warunek lub zdolność potrzebna intersariuszom do rozwiązania danego problemu lub osiągnięcia celu.
(2) Warunek lub zdolność, które muszą być spełnione lub posiadane przez system lub składnik systemu, aby wypełnić zapisy umowy, standardu, specyfikacji lub innych formalnie nałożonych dokumentów.
(3) Udokumentowana reprezentacja warunku lub zdolności opisanych w (1) i (2).
Innymi słowy, wymaganie jest pewnym opisem rozwiązania (jego charakterystyką) - zbiorem jego cech wymaganych przez użytkownika, klienta lub innego interesariusza do osiągnięcia założonego celu. To bardzo ważne: wymaganie musi być czymś, co pozwala na osiągnięcie określonego celu lub rozwiązanie zdefiniowanego problemu. Implikacją tego stwierdzenia jest to, iż cel zgłoszenia wymagania powinien być znany i zdefiniowany. Wymaganie bez celu i kontekstu biznesowego nie jest dobrze sformułowane.
Wymagania mają różnorodne znaczenie i cele w kontekście całości procesu realizacji. Jednym z najważniejszych celów wymagań jest wyrażenie oczekiwań i potrzeb klienta oraz innych interesariuszy. Na podstawie deklaracji wymagań dostawcy rozwiązań są w stanie oszacować nakłady prac i środków oraz ocenić możliwości zbudowania rozwiązania zaspokajającego potrzeby klienta.
Wymagania stanowią również podstawę do oceny, planowania, realizacji i monitorowania działań projektowych. Wstępne wymagania klienta służą do oszacowania czasu trwania danego projektu i wysiłku, który zostanie włożony w jego realizację; pozwalają ustalić wstępny plan projektu, jego zakres i harmonogram. Podczas realizacji projektu wymagania i wynikłe z nich szacunki i plany umożliwiają monitorowanie postępów w stosunku do uzgodnionego planu.
Wymagania określają ponadto granice rozwiązania, zakresu procesu wytwarzania lub usług kontraktowych. Tym samym pozwalają kontrolować prace wykonywane w trakcie realizacji projektu. Szczególnie ważnym aspektem w pracy z wymaganiami jest to, aby postrzegać je jako element umowy, zamówienia, planu projektu, ponieważ są podstawą rozliczania prac. Wymagania biznesowe (wysokopoziomowe wymagania stanowiące podstawę koncepcji projektu) powinny być określone w umowie między dostawcą a klientem w sposób umożliwiający obu stronom zrozumienie zakresu i treści rozwiązania stanowiącego przedmiot zamówienia.
Kolejnym ważnym aspektem związanym z podstawami inżynierii wymagań jest klasyfikacja wymagań. Ogólnie rzecz biorąc, istnieją dwa podstawowe rodzaje wymagań (rys. 1.1).
Rysunek 1.1. Klasyfikacja wymagań
Definicja 1.5. Rodzaje wymagań
Rodzaje wymagań:
- ograniczenia (ang. constraints),
- wymagania produktowe (ang. product requirements).
Ograniczenia to pewne warunki limitujące możliwości procesu projektowania, działania rozwiązania lub jego cyklu życia.
Istnieją dwa rodzaje ograniczeń: ograniczenia biznesowe i ograniczenia techniczne. Ograniczenia biznesowe wyrażają restrykcje nałożone na możliwości projektu do realizacji żądanego rozwiązania (np. ograniczenia finansowe lub czasowe, limity nałożone na liczbę dostępnych zasobów, umiejętności zespołu projektowego, inne ograniczenia organizacyjne, uwarunkowania prawne, normy i przepisy wpływające na realizację projektu).
Ograniczenia techniczne to wszelkiego rodzaju limity, które odnoszą się do architektury rozwiązania (np. platformy sprzętowe i programowe, język lub technologia programowania, oprogramowanie, które ma być używane wraz z rozwiązaniem, rozmiar bazy danych, wykorzystanie zasobów, rozmiar wiadomości i czas dostarczenia, rozmiar oprogramowania, maksymalna liczba i rozmiar plików, dokumentacji i elementów danych).
Ograniczenia mają wpływ na sposób, w jaki rozwijane jest rozwiązanie. Mogą one być związane z:
- kosztem wytworzenia - ile organizacja klienta jest w stanie zapłacić za wytworzenie rozwiązania; koszt może znacząco ograniczyć pewne procesy;
- organizacją procesu wytwarzania - jakie podejście do wytwarzania należy przyjąć, ponieważ klient może zażądać zastosowania określonych metodologii bądź użycia specjalnych narzędzi lub technologii;
- dokumentacją - ile i jaka dokumentacja jest niezbędna do zaspokojenia potrzeb klienta? Czy potrzebna jest pełna dokumentacja, czy tylko podstawowe artefakty? Wymagania dotyczące ilości i formy dokumentacji mogą wynikać z wymagań związanych z organizacją procesu wytwarzania - niektóre metodologie oraz podejścia do wytwarzania oprogramowania i innych produktów precyzyjnie określają liczbę i rodzaje niezbędnych dokumentów.
Druga główna kategoria wymagań to wymagania produktowe. Są to cechy związane z jakością produktu. Wymagania produktowe obejmują wymagania funkcjonalne i wymagania niefunkcjonalne. Oba typy wymagań produktowych mogą być postrzegane z różnych punktów widzenia: z punktu widzenia użytkownika lub klienta (zewnętrzny punkt widzenia), lub z punktu widzenia zespołu realizującego produkt (wewnętrzny punkt widzenia). Ma to swoje uzasadnienie w tym, że dla klienta ważne są inne właściwości i atrybuty niż dla zespołu projektowego.
Wymagania funkcjonalne opisują funkcje (zachowanie) produktu. Określają one to, co rozwiązanie powinno robić, najczęściej z punktu widzenia użytkownika (funkcje, usługi itp.).
Wymagania niefunkcjonalne opisują atrybuty jakościowe systemu. Są one często nazywane "jakościami" rozwiązania i określają sposób, w jaki rozwiązanie ma realizować swoje funkcje.
Różnica między wymaganiami funkcjonalnymi a niefunkcjonalnymi może być wyrażona za pomocą następujących stwierdzeń:
- Wymagania funkcjonalne opisują to, co robi system.
- Wymagania niefunkcjonalne opisują to, jak działa system.
Przykład 1.1. Wymagania produktowe i ograniczenia
Wymagania produktowe:
- System powinien sprawdzać, czy operator banku ma możliwość dostępu do określonego raportu.
- System powinien autoryzować użytkownika przed uzyskaniem dostępu do aplikacji.
Ograniczenia:
- Program ma być napisany w Javie.
- Projekt ma być realizowany zgodnie z podejściem Prince2.
Przykład 1.2. Wymagania funkcjonalne i niefunkcjonalne
Wymagania funkcjonalne z punktu widzenia użytkownika i klienta:
- System musi umożliwiać użytkownikowi wyszukiwanie klienta przy użyciu identyfikatora.
- System ma generować raporty analizy trendu na postawie danych pozyskanych z transakcji.
Wymagania funkcjonalne z punktu widzenia zespołu wytwórczego:
- System musi wymieniać informacje z zewnętrzną bazą danych klientów.
Wymagania niefunkcjonalne z punktu widzenia użytkownika i klienta:
- System musi umożliwiać przeprowadzenie do 10 000 transakcji dziennie.
- Klient musi mieć dostęp do konta 24 godziny na dobę, 7 dni w tygodniu.
Wymagania niefunkcjonalne z punktu widzenia zespołu wytwórczego:
- System będzie niedostępny od 0:00 do 1:00 celem tworzenia kopii zapasowych.
Powyższa klasyfikacja dzieli wymagania ze względu na obszary, których dotyczą. Wymagania można jednak również klasyfikować, opierając się na poziomach abstrakcji reprezentujących różne etapy rozwoju rozwiązania.
Podstawowe rodzaje wymagań:
- wymagania biznesowe (ang. business requirements),
- wymagania rozwiązania/systemu (ang. solution/system requirements),
- wymagania produktu/komponentu (ang. product/component requirements).
Klasyfikacja ta może być przedstawiona w formie graficznej (rys. 1.2) obrazującej zależności między różnymi rodzajami wymagań.
Podczas pracy z wymaganiami na różnych poziomach abstracji szczególnie istotne jest zdefiniowanie i utrzymywanie śledzenia powiązań.
Definicja 1.6. Możliwość śledzenia
Możliwość śledzenie (ang. traceability) to stopień, w jakim można ustanowić relację między dwoma lub więcej produktami procesu wytwarzania, w szczególności produktami mającymi w stosunku do siebie relację następca-poprzednik lub nadrzędny-podrzędny [18].
Najprościej koncepcję możliwości śledzenia można wyjaśnić jako powiązanie, które istnieje między różnymi artefaktami projektowymi. Powiązania te mogą łączyć artefakty o podobnych rodzajach, lecz istniejące na różnych poziomach abstrakcji (np. relacja między wymaganiami biznesowymi a wymaganiami rozwiązania) lub też różne rodzaje artefaktów istniejących na tym samym poziomie abstrakcji (np. relacja między wymaganiami systemowymi a przypadkami testowymi dla testów systemowych).
Jednym z głównych celów śledzenia jest przedstawienie sposobu rozwijania systemu. Może to być wyrażone przez dokładne wskazanie, jakie wymagania niższego poziomu uszczegóławiają (czy też stanowią rozwinięcie w kolejnym kroku procesu realizacji) konkretne wymaganie wyższego poziomu. Śledzenie powiązań wspomaga proces zapewnienia, że wymagania są prawidłowo i całkowicie analizowane i zarządzane na różnych poziomach abstrakcji, czyli na różnych etapach analizy zmierzającej do opracowania koncepcji projektu docelowego rozwiązania.
Rysunek 1.2. Poziomy wymagań
W tabeli 1.1 opisano charakterystyki różnych poziomów wymagań. Podano również najpopularniejsze synonimy używane do definiowania określonych rodzajów wymagań. Klasyfikacja ta jest proponowanym przez REQB? rozwiązaniem dla organizacji wymagań, należy jednak uwzględnić to, że w przypadku mniej skomplikowanych rozwiązań, mniejszych organizacji lub specyficznych metod wytwarzania produktu (np. metod zwinnych zakładających mniej formalne podejście do inżynierii wymagań), dość powszechne jest pomijanie niektórych poziomów abstrakcji.
Tabela 1.1. Podstawowe poziomy wymagań
Typ
Synonimy
Opis
Wymagania biznesowe
wymagania klienta
wymaganie interesariuzy
potrzeby biznesowe zdefiniowane np. przez właściciela produktu lub procesu, sponsora lub innych interesariuszy ze strony biznesu, marketingu, sprzedaży i obsługi klienta; jest to wymaganie wysokiego poziomu, określające, co biznes chce osiągnąć
Wymagania rozwiązania/ systemu
wymagania systemu
wymagania produktu
stanowią rozwinięcie wymagań biznesowych w postaci warunków technicznych, które mogą być użyte w procesie podejmowania decyzji odnośnie do projektu (technicznego) rozwiązania; mogą być postrzegane jako dalsze uszczegółowienie i doprecyzowanie wymagań biznesowych, ponieważ są opisem różnych aspektów rozwiązania z uwzględnieniem przyjętego na tym etapie rozwoju kierunku; wymagania rozwiązania opisują jeden z kilku możliwych sposobów implementacji określonych wymagań biznesowych, mogą odnosić się do systemu informatycznego lub dotyczyć innych obszarów (np. zmian wymaganych w procesach biznesowych lub strukturze organizacyjnej)
Wymagania produktu/komponentu
wymagania funkcjonalne
założenia projektowe
dotyczą produktu/komponentu i są kompletną specyfikacją elementów produktu, włączając w to dopasowanie, postać, funkcję, wydajność i inne szczegółowe cechy
Rozważmy kilka przykładów.
Przykład 1.3. Wymagania na różnych poziomach
Wymagania biznesowe:
- Wysokopoziomowe wymaganie przedstawicieli biznesu dotyczące opisu problemu biznesowego (np. "należy zautomatyzować procesy raportowania").
Wymagania rozwiązania/systemu:
- Wymaganie opisujące funkcjonalności rozwiązania niezbędne do spełnienia wymagań biznesowych (np. "dane niezbędne do sporządzenia raportów muszą być pobierane z modułu CRM").
Wymagania produktu/komponentu:
- Szczegółowy opis wymagań systemu (np. "system generuje raport zawierający następujące informacje:... w następującym formacie...").
Jak widać, wymagania istnieją na różnych poziomach abstrakcji reprezentujących obszar zainteresowania albo biznesu ("co chcemy osiągnąć"), albo rozwiązania ("jak to osiągnąć"). Te poziomy abstrakcji odzwierciedlają zarazem różne poziomy analizy wymagań (np. dość popularny podział analizy na analizę biznesową i analizę systemową).
Kolejnym ważnym zagadnieniem jest kwestia źródła wymagań. Która z ról interesariuszy jest odpowiedzialna za wymagania na poszczególnych poziomach?
Rysunek 1.3. Obszary inżynierii wymagań
- Wymagania biznesowe są zazwyczaj dostarczane przez klienta lub interesariuszy reprezentujących tak zwany "biznes" (są to np. analityk biznesowy, właściciel produktu, właściciel procesu, personel marketingu). W niektórych przypadkach klient może być wspierany przez analityka biznesowego ze strony producenta lub przez niezależnego konsultanta.
- Wymagania rozwiązania/systemu opracowuje zwykle inżynier wymagań o wysokiej wiedzy w danej dziedzinie biznesowej. Rola ta jest często określana mianem analityka biznesowego IT. Analityk biznesowy jest odpowiedzialny za uszczegółowienie i poddanie analizie potrzeb oraz wymagań klienta i określenie na tej podstawie wymagań rozwiązania.
- Wymagania produktu/komponentu są bardziej "techniczne" i przy ich opracowywaniu potrzebna jest dość duża wiedza na temat technologii. Wymaganie te opracowuje inżynier wymagań o kompetencjach w zakresie inżynierii systemowej - rola ta jest często nazywana mianem analityka systemowego lub projektanta. Jest to osoba odpowiedzialna za przekształcenia wymagań rozwiązania/systemu w szczegółowe wymagania, zbliżone do projektu rozwiązania, co obejmuje np. aspekt integracji danych pomiędzy systemami i inne zagadnienia techniczne dotyczące planowanego rozwiązania.
Należy pamiętać o tym, że wymagania nie opisują szczegółów implementacji rozwiązania, lecz stanowią podstawę do jego projektowania. Wymagania biznesowe są uszczegóławiane, analizowane i odwzorowywane na wymagania rozwiązania, które pozwolą na zaspokojenie potrzeb określonych przez klienta.
Celem procesów inżynierii wymagań jest określenie biznesowej koncepcji rozwiązania problemu danej organizacji. Rozwiązanie jest odpowiedzią na potrzeby biznesowe klienta (lub - bardziej precyzyjnie - potrzeby interesariuszy). Te potrzeby są zwykle wyrażone jako wymagania biznesowe (wymagania wysokopoziomowe) i służą jako dane wejściowe do dalszych działań inżynierii wymagań.
Przy opracowywaniu rozwiązania bardzo ważne jest, aby mieć na względzie to, że rozwiązanie to nie tylko system. Może to być również realizowana wraz z systemem informatycznym zmiana procesu biznesowego, zmiana organizacyjna czy proceduralna itp. Wymaganie reprezentujące daną potrzebę biznesową może być powiązane z wieloma aspektami funkcjonowania organizacji, nie tylko z infrastrukturą IT. Bardzo często celem organizacji jest wdrożenie systemu informatycznego a jednocześnie zmiana niektórych procesów biznesowych lub ich fragmentów. W tym przypadku oprogramowanie będzie tylko częścią całego rozwiązania. Istotne jest to, by zarówno inżynier wymagań, jak i inne kluczowe osoby z zespołu projektowego miały świadomość i rozumiały kontekst biznesowy danego projektu (czyli umiejscowienie wymagań biznesowych w procesach, powiązania i zależności między procesami, wymagania proceduralne oraz specyfikę pracy w danej organizacji). W przeciwnym razie zespół rzadko będzie w stanie zaproponować rozwiązanie, które naprawdę wspiera istniejące w przedsiębiorstwie klienta procesy i umożliwia spełenienie określonych potrzeb.
1.1.3. Atrybuty wymagań
W tym punkcie są opisane najważniejsze atrybuty wymagań. Atrybuty stanowią informację uzupełniającą samą treść wymagań o dane umożliwiające określenie kontekstu i szerszego znaczenia danego wymagania. Każde wymaganie wysokiego poziomu powinno mieć co najmniej minimalny zestaw niezbędnych atrybutów, by umożliwić ocenę względnej ważności i pilności dla klienta.
REQB? wskazuje następujące główne atrybuty wymagań:
- zobowiązanie,
- priorytet,
- krytyczność.
Powyższa lista jest bardzo ograniczona - wymaganie może mieć również inne atrybuty, takie jak typ, ryzyko, źródło, autor itp. Najczęściej stosowane atrybuty wymagań zostaną podane na końcu tego punktu.
Pierwszym atrybutem wymagania jest zobowiązanie.
Definicja 1.7. Poziom zobowiązania
Poziom zobowiązania (ang. commitment) jest stopniem zobowiązania się do spełnienia wymagania.
Zobowiązanie jest zwykle definiowane za pomocą słów kluczowych przypisywanych do wymagań wysokiego poziomu. Do wyrażenia poziomu zobowiązania można stosować następujące słowa kluczowe:
- "musi", "powinien", "mógłby", "może" zazwyczaj odnoszą się one do wymagań biznesowych i są definiowane podczas określania początkowego zakresu planowanego rozwiązania i zarazem zakresu umowy pomiędzy producentem a klientem. Poziom zobowiązania dla wymagań biznesowych definiuje zamawiający (klient), ponieważ to klient określa, które cechy i aspekty muszą być niezbędnym składnikiem rozwiązania, a które są opcjonalne.Dość często stosowanym sposobem wyrażenia poziomu zobowiązania dla wymagań wysokiego poziomu jest notacja MoSCoW (ang. Must have, Should have, Could have, Won't have this time but will have in the future), która określa je następująco: M - musi mieć, S - powinien mieć, C - mógłby mieć, W - nie będzie mieć tym razem, ale będzie mieć w przyszłości.
- "ma", "będzie" są zwykle używane już po uzgodnieniu i akceptacji wymagań biznesowych i dotyczą wymagań niższego poziomu. Określają one stopień zobowiązania bardziej rygorystycznie.
Należy zauważyć, że do opisu wymagań przed i po akceptacji wymagań biznesowych oraz po ustaleniu punktu odniesienia[1] są używane różne słowa kluczowe. Powodem takiego stanu rzeczy jest to, że na etapie definiowania oczekiwań i potrzeb, przed ustaleniem finalnego zakresu projektu, można pozwolić sobie na określony poziom braku prezycji, aby mieć pewną elastyczność w wyborze docelowego i ostatecznego zbioru cech planowanego rozwiązania. Ma to na celu umożliwienie ukierunkowania działań związanych z projektowaniem rozwiązania na spełnienie cech absolutnie wymaganych oraz włączenie pewnych cech opcjonalnych, o ile pozwolą na to zasoby, warunki i możliwości projektu. Na dalszym etapie, gdy wymagania są uzgodnione i odzwierciedlają już poziom rozwiązania, określenie zobowiązania musi być ścisłe i jednoznaczne.
Wymaganie systemowe opisane słowem [system] "będzie" oznacza, że jest ono niezbędne w docelowym rozwiązaniu i będzie jego składnikiem. Podczas definiowania wymagań rozwiązania/systemu stanowczo odradza się używania słów "mógłby", "może", ponieważ na tym etapie zakres i treść rozwiązania powinien być określony jednoznacznie i mierzalnie. Wymagania wysokiego poziomu przed ustaleniem finalnego zakresu prac mogą być opisane mniej restrykcyjnie, ponieważ będą przedmiotem dalszej analizy i szczegółowej dekompozycji, które to działania ujawnią, które cechy rozwiązania są niezbędne, a które nie.
Poziom zobowiązania dla wymagań biznesowych powinien być uzgodniony pomiędzy klientem a dostawcą przed rozpoczęciem prac projektowych, tak by obie strony miały pełną świadomość wymaganego zakresu prac i minimalnego zestawu cech docelowego produktu.
Wymagania mogą ulec zmianie podczas realizacji projektu. Jest to wynikiem naturalnego procesu uszczegóławiania i rozwoju wymagań. W miarę uszczegóławiania wymagań uzyskanie i potwierdzenie stopnia zobowiązania co do wymagań od uczestników projektu (zwykle mniej formalne i realizowane podczas przeglądów wymagań) zapewnia, że potwierdzają oni obecne wymagania i wynikające z nich ewentualne zmiany w planach projektowych, działaniach oraz produktów pracy.
Przykład 1.4. Zobowiązania odnośnie do wymagań
Wymaganie biznesowe: "Transakcje finansowe przeprowadzane w oddziałach banku muszą być zautomatyzowane".
Wymaganie systemowe wyłonione na podstawie powyższego wymagania biznesowego: "System umożliwia operatorowi wykonywanie wpłaty środków pieniężnych na rachunek klienta w banku".
Oprócz stopnia zobowiązania wymagania powinny mieć określony priorytet i krytyczność. Te atrybuty umożliwiają ocenę ważności i pilności danego wymagania.
Definicja 1.8. Priorytet
Priorytet (ang. priority) określa ważność biznesową/pilność wymagania.
Zgodnie ze standardowym podejściem [46], zasadniczo, im wyższy priorytet, tym wymaganie jest bardziej istotne dla realizacji ogólnych celów projektu. Priorytet zwykle określa się słownie, np. wysoki, średni, niski, lub przy użyciu skala liczbowej: 1, 2, 3 itd. Wysoki priorytet oznacza ni mniej, ni więcej, jak duża jest pilność realizacji wymagania - co implikuje, że podczas analizy i projektowania wymaganie to powinno być rozważane jako pierwsze (lub jedno z zestawu pierwszych), tak by było zaimplementowane możliwie najszybciej.
Przy definiowaniu priorytetu ważne jest dążenie do zrównoważenia kosztów rozwijania rozwiązania względem możliwości projektowych.
Przykład 1.5. Priorytety wymagań
Wymaganie biznesowe: "Transakcje finansowe przeprowadzane w oddziałach banku muszą być zautomatyzowane"
Priorytet: wysoki
Kolejny atrybut wymagania to krytyczność.
Definicja 1.9. Krytyczność
Krytyczność (ang. criticality) określa ryzyko/szkodę w przypadku niespełnienia wymagania.
Krytyczność, podobnie jak priorytet, wyraża się za pomocą skal - wyższy poziom krytyczności oznacza, że brak spełnienia wymagania będzie bardziej dotkliwy dla całości rozwiązania (rozwiązanie nie będzie mogło być pełne).
Krytyczność jest często mylona z priorytetem wymagań. Atrybuty te są podobne, jednak nie wyrażają tej samej informacji. Priorytet to ocena pilności; krytyczność to ocena znaczenia wymagania dla funkcjonowania całości rozwiązania. Zazwyczaj wysoki priorytet łączy się z wysoką krytycznością, gdyż to, co kluczowe, powinno być implementowane najszybciej, jednak istnieją pewne wyjątki. Rozważmy np. wspominany już wcześniej system bankowy. Z bieżącej potrzeby biznesowej może wynikać pilne wymaganie implementacji generowania potwierdzenia realizacji transakcji dla klienta w postaci SMS. Wymaganie to będzie miało wysoki priorytet, jednak niską krytyczność, gdyż brak potwierdzenia SMS-owego w żaden sposób nie przeszkadza w realizacji transakcji, które są najistotniejszym elementem biznesu banku.
Atrybuty wymagań można wyrazić nie tylko standardowymi skalami. Ciekawy sposób kategoryzacji wymagań jest zalecany w ramach modelu Kano. Model ten umożliwia podział cech produktu w następujący sposób:
- atrybuty podstawowe (ang. threshold/basic attributes) - cechy podstawowe, które produkt musi mieć, aby zaspokoić bezpośrednio stwierdzone potrzeby klientów;
- atrybuty operacyjne (ang. performance attributes) - umiejętności, wiedza, zdolności lub cechy behawioralne, które wiążą się ze sposobem, w jaki produkt dostarcza swoje możliwości (funkcje itd.) dla użytkownika. Atrybuty operacyjne zwiększają satysfakcję klienta;
- atrybuty emocji (ang. excitement attributes) - cechy nieprzewidziane przez klienta (czasami nazywane "potrzebami nieuświadomionymi lub ukrytymi"), które mają być odkryte przez dostawcę. Ich obecność wzbudza zachwyt klienta i może mu zapewnić znaczącą przewagę konkurencyjną.
Model Kano może być użyty do wyrażenie zarówno priorytetu, jak i zobowiązania.
Opisane trzy podstawowe atrybuty wymagań: zobowiązanie, priorytet i krytyczność, mają o wiele większe znaczenie niż ich bezpośrednie zastosowanie do wyrażenia pewnych informacji związanych z opisem wymagania. Atrybuty te wiążą się z odpowiedzialnością prawną związaną z jakością produktu. Poziom zobowiązania określa zakres umowy pomiędzy dostawcą a klientem - niespełnienie wymagań opisanych jako "musi mieć" może doprowadzić do odrzucenia wytworzonego produktu przez klienta lub nałożenia na dostawcę określonych w umowie kar. Podobnie jest w przypadku krytyczności i priorytetu - problemy z implementacją wymagań zgodnie z warunkami określonymi przez ich atrybuty mogą powodować poważne konsekwencje dla dostawcy. Dodatkowym aspektem regulowanym przez umowę a wynikającym z artybutów wymagań (które określają w istocie ważność wymagania) jest jakość implementacji wymagań. Przykładowo, wymaganie oznaczone jako "krytyczne" i obowiązkowe w produkcie musi być zrealizowane z zachowaniem odpowiedniego poziomu jakości, który może być wyrażony jako brak defektów określonego rodzaju. Niespełnienie tego warunku może również oznaczać wystąpienie pewnych konsekwencji np. kar za błędy wykryte przy lub po odbiorze produktu i konieczność ich naprawy w ściśle określonym czasie.
Dodatkowym elementem do rozważenia na etapie formułowania wymagań wysokopoziomowych jest kwestia dziedziny biznesowej i wynikających z tego warunków. Niektóre branże mogą nakładać obowiązek spełnienia wymagań prawnych lub umownych lub też zgodność ze standardami branżowymi.
Przykład 1.6. Wymagania specyficzne dla dziedziny biznesowej
Oprogramowanie dla urządzeń medycznych musi być zgodne ze standardem IEC 62304:2006 Oprogramowanie dla urządzeń medycznych - Procesy cyklu życia oprogramowania (ang. Medical device software - Software lifecycle processes). Producent jest odpowiedzialny za zapewnienie zgodności z założeniami normy i wymaganiami, które wynikają z jej zapisów.
Jak wspomniano wyżej, odpowiedzialność prawna odnosi się nie tylko do konieczności spełnienia określonych wymagań i standardów, ale i jakości wykonania produktu. Jednym z głównych tematów do uzgodnienia i udokumentowania w treści umowy między klientem a dostawcą jest odpowiedzialność w razie wystąpienia defektów.
Typowe umowy zwykle określają odpowiedzialność w przypadku wykrycia defektów już po wdrożeniu systemu w środowisku produkcyjnym, jednak mogą również ustalać procedury, koszty i inne konsekwencje obowiązujące w przypadku defektów odkrytych we wcześniejszych fazach projektu (np. podczas testów akceptacji UAT (ang. User Acceptance Testing)).
Oprócz opisanych powyżej atrybutów wymagania mogą (i powinny) być klasyfikowane przez następujące informacje (ISO/IEC/IEEE 29148:2011, wcześniej IEEE 1233):
- identyfikator,
- wykonalność,
- ryzyko,
- źródło,
- typ.
Pełny opis wymagań powinien zawierać wszystkie powyższe informacje - wtedy możliwe jest określenie pełnego kontekstu i znaczenia danego wymagania.
Przykładowy szablon do opisu wymagania, obejmujący minimalny zestaw kluczowych informacji, przedstawiono w tab. 1.2.
Tabela 1.2. Szablon opisu wymagania
ID
Nazwa
Priorytet
Krytyczność
Wykonalność
Ryzyko
Źródło
Właściciel
Typ
1.1.4. Jakość wymagań
Wymagania są podstawą do projektowania i rozwoju rozwiązania, dlatego ich jakość ma bezpośredni wpływ na jakość produktu końcowego. Większość głównych czynników powodzenia (lub porażki) projektu jest związana z jakością wymagań. Z tego powodu, aby zapewnić najlepszą możliwą jakość produktu końcowego i uniknąć typowych problemów związanych z wymaganiami, które mogą pojawić się podczas realizacji projektu, dla każdego wymagania stosuje się następujące kryteria jakości [48]. Każde wymaganie musi być:
- poprawne (ang. correct),
- wykonalne (ang. feasible),
- niezbędne (ang. necessary),
- uporządkowane pod względem ważności (ang. prioritized),
- jednoznaczne (ang. unambiguous),
- weryfikowalne (ang. verifiable),
- pojedyncze (ang. singular),
- niezależne od implementacji (abstrakcyjne) (and. design inpendent/abstract).
Poprawność wymagania oznacza, że wymaganie dokładnie i adekwatnie opisuje cechę/wartość, która ma być przez nie dostarczona. Punktem odniesienia do oceny poprawności jest źródło wymagania (np. klienci lub wymaganie wyższego poziomu). Innymi słowy, poprawność oznacza spójność między wymaganiem a jego źródłem.
Wykonalność oznacza, że wymaganie musi być możliwe do realizacji w ramach znanych możliwości lub ograniczeń projektu, systemu i środowiska. Wysokopoziomowe wymagania biznesowe należy poddać analizie w celu ustalenia, czy będą wykonalne w ramach inicjowanego projektu. Szczegółowe wymagania rozwiązania analizuje się pod kątem ustalenia wykonalności w ramach wybranej technologii i możliwości. Kryterium wykonalności jest bardzo ważne, ponieważ wymagania, które nie są wykonalne, nie są również testowalne (możliwe do sprawdzenia), nie ma więc żadnych realnych szans, aby sprawdzić sposób, czy w ogóle fakt, ich realizacji. Aby zminimalizować ryzyko problemów w realizacji wymagania, inżynierowie wymagań odpowiedzialni za opracowanie koncepcji rozwiązania powinni współpracować z deweloperami, projektantami i architektami w celu ustalenia możliwych problematycznych zagadnień i sposobu ich rozwiązania na wczesnym etapie (np. przez zaproponowanie innej koncepcji rozwiązania).
Konieczność wymagania oznacza, że każde wymaganie dokumentuje to, i tylko to, co jest istotne i potrzebne interesariuszom w celu zrealizowania zewnętrznych wymagań (np. potrzeby biznesowej), zapisów określonego przepisu czy standardu itp. Zalecaną zasadą jest implementacja tych wymagań, które niosą ze sobą konkretną wartość i korzyści.
Wymagania powinny być również opatrzone priorytetem. Priorytet jest informacją, która pozwala na zaplanowanie efektywnego procesu rozwijania wymagań oraz planowanie poszczególnych wydań produktu, ponieważ określa on kolejność implementacji danego wymagania.
Jednoznaczność wymagania oznacza, że treść wymagania powinna być interpretowana tylko w jeden sposób. Opis wymagania powinien mieć to samo znaczenie dla różnych czytelników (odbiorców) i być tak samo przez nich rozumiany. Innymi słowy, wymagania powinny być interpretowane w taki sam sposób przez klienta, inżynierów wymagań, programistów, testerów i inne osoby. Jednoznaczność zapisu pozwala uniknąć poważnych problemów, takich jak różna interpretacja wymagania przez zespół programistów oraz przez autora (inżyniera wymagań), czego wynikiem może być to, że realizacja wymagania nie będzie zgodna z "prawdziwymi" intencjami i zamierzeniami, co z kolei spowoduje konieczność zmiany implementacji i związany z tym dodatkowy (i całkowicie zbędny) nakład prac (a także kosztów).
Wymaganie o wysokiej jakości powinno być weryfikowalne (inaczej testowalne). Kryterium to oznacza, że musi być możliwość sprawdzenia, czy zostało ono prawidłowo zrealizowane. Popularnymi technikami weryfikacji są: inspekcje i przeglądy dokumentacji (w tym specyfikacji wymagań) oraz testy dynamiczne produktu. Jeśli wymaganie nie jest weryfikowalne, nie można ocenić, czy zostało prawidłowo zaimplementowane, czyli zwiększa się ryzyko dostarczenia produktu niezgodnego z potrzebami interesariuszy.
Generalna zasada związana z jakością wymagań mówi, że wymagania, które nie są wzajemnie spójne, wykonalne lub jednoznaczne, nigdby nie będą możliwe do zweryfikowania. Pojawi się bowiem problem interpretacji.
Kryterium pojedynczości wymaga, by opis deklaracji jednego wymagania nie zawierał wielu wymagań. W każdym dokumencie wymagania (opisanym np. przy użyciu szablonu podobnego do podanego w tab. 1.2) należy opisać tylko jedno wymaganie (czyli jeden "cel"). Niezbędne jest zachowanie takiej granularności (szczegółowości) opisu, by każdy obiekt zidentyfikowany jako wymaganie w istocie opisywał jedno wymaganie. Wymagania, które nie są pojedyncze, nie są łatwe do analizy, śledzenia, zmiany, wdrożenia ani przetestowania.
Ostatni atrybut jakości jest związany z niezależnością wymagania od sposobu implementacji. Wymaganie powinno być niezależne od sposobu rozwiązania, powinno być opisem, "czego potrzebujemy", nie zaś wyjaśnieniem, "jak to zrobić". Wymagania mają opisywać pożadany z perspektywy biznesu wynik, ale nie szczegóły wykonania produktu.
Przykład 1.7. Jakość wymagań
Wymaganie systemowe: "System będzie użyteczny".
Problemy z wymaganiem są następujące:
- Wymaganie jest niejednoznaczne: co oznacza "użyteczny"? Różni interesariusze postrzegają "użyteczność" w odmienny sposób.
- Wymaganie nie jest weryfikowalne: sprawdzenie, czy gotowy produkt jest użyteczny, nie jest możliwe, ponieważ brakuje mierzalnych kryteriów pozwalającyh określić pożądany poziom użyteczności.
- Z powyższych powodów wymaganie nie będzie ani wykonalne, ani testowalne.
Powyższe kryteria jakości dotyczyły pojedynczych wymagań. Na etapie analizy wymagań tworzony jest dokument opisujący zakres i treść problemu biznesowego lub obszar rozwiązania. Dokument ten nosi nazwę specyfikacji i również musi spełniać pewne kryteria jakości.
Specyfikacja musi być:
- kompletna,
- spójna,
- możliwa do modyfikacji,
- możliwa do śledzenia powiązań.
Kompletność specyfikacji oznacza, że w dokumencie nie pominięto żadnego wymagania ani innej informacji niezbędnej do opisania całości zagadnienia. Kompletność jest również wyrażona w postaci wymaganych charakterystyk poszczególnych wymagań i ich poziomu szczegółowości.
Spójność specyfikacji oznacza, że opisane w specyfikacji wymagania nie mogą być w sprzeczności z innymi wymaganiami związanymi z danym rozwiązaniem (w tym tymi opisanymi w danej specyfikacji) lub z wymaganiami czy celami wyższego poziomu (np. celami biznesowymi systemu lub firmy).
Specyfikacja musi być możliwa do modyfikacji. Zmiany w wymaganiach to naturalna część procesu analizy i specyfikacja powinnna być zbudowana w sposób umożliwiający wprowadzenie zmian. Przekłada się to np. na wyraźną strukturę dokumentu i brak redundantności (nadmiarowości, powtórzeń) w opisie wymagań. Dodatkowo, należy utrzymywać historię zmian dla każdego wymagania oraz samego dokumentu specyfikacji.
Ostatnim aspektem jakości specyfikacji jest zapewnienie możliwości śledzenia powiązania. Każde wymaganie opisane w specyfikacji musi być powiązane ze swoim źródłem (np. wymagania opisane w specyfikacji wymagań szczegółowych (SRS) powinny być śledzone do wymagań systemowych wyższego poziomu lub/i wymagań biznesowych) i innymi powiązanymi artefaktami projektowymi (np. elementami projektu rozwiązania, kodem źródłowym lub przypadkami testowymi).
Kryteria jakości, zarówno wymagań, jak i specyfikacji, służą jako pomoc przy tworzeniu odpowiednich artefaktów. Innym ich zastosowaniem jest kontrola jakości wymagań i specyfikacji. Kryteria jakości są środkiem często używanym do walidacji i weryfikacji artefaktów (V & V).
1.1.5. Problemy związane z wymaganiami
Efektywna identyfikacja i zarządzanie wymaganiami mają badzo istotne znaczenie dla powodzenia projektu. Aby mieć pewność tego, że rozwiązanie usatysfakcjonuje klienta, należy poznać i określić jego oczekiwania, a do tego służy identyfikacja wymagań - co z kolei umożliwia zamodelowanie projektu rozwiązania spełniającego określone potrzeby.
Stworzenie rozwiązania spełniającego wymagania wszystkich interesariuszy nie jest łatwym zadaniem. Klient zgłasza początkowe potrzeby i oczekiwania, jednak to nie wystarczy, aby opracować koncepcję całego finalnego rozwiązania. Inżynierowie wymagań muszą zgłębić te potrzeby, odkryć wymagania pośrednie i ukryte, przezanalizować wszystkie zgromadzone wymagania, uwzględniając potrzeby różnych interesariuszy oraz potencjalne konflikty i na tej podstawie określić propozycję rozwiązania. W procesie tym należy wziąć pod uwagę wiele czynników i zależności. Nawet w dobrze zarządzanym procesie inżynierii wymagań mogą pojawić się pewne problemy i błędy. Najczęstsze problemy związane z wymagania są następujące:
- Niejasne cele projektu. Jeśli nie znamy wartości biznesowej, jaką projekt ma dostarczyć, i nie wiemy, jaka jest rola planowanego produktu w poprawie wydajności organizacji klienta, istnieje ryzyko, że nie będziemy w stanie prawidłowo określić wymagań. Zabraknie celu, który ukierunkuje czynności inżynierii wymagań. W konsekwencji produkt nie będzie realizował zamierzonych funkcji i celów biznesowych.
- Problemy komunikacyjne. Bardzo często pomiędzy klientem a dostawcą pojawiają się problemy dotyczące komunikacji i wymiany informacji. Zdarza się, że klient nie jest w stanie odpowiednio precyzyjnie wyrazić swoich potrzeb i prawdziwych celów. Jeśli zespół producenta nie zdoła określić tych potrzeb i pomóc klientowi w identyfikacji wymagań, projekt narażony będzie na ryzyko niepowodzenia. Problemy komunikacyjne mogą pojawić się podczas całego projektu - klient może nie informować dostawcy o zmianach w obszarze biznesowym (np. zmiana przepisu), infrastrukturze informatycznej itd., co znacznie ograniczy możliwości producenta do dostarczenia odpowiedniego produktu w zakładanym czasie.
- Bariery językowe. Problem ten jest szczególnie widoczny w przypadku międzynarodowych projektów angażujących zespoły z różnych krajów. Nawet posługując się tym samym językim, ludzie mają problemy z wzajemnym porozumieniem, chociażby ze względu na akcent czy regionalizmy.
- Bariery wiedzy. Klient nie musi posiadać wiedzy na temat rozwoju oprogramowania ani innych produktów. Mogą z tego wynikać problemy związane z niezrozumieniem złożoności procesu wytwarzania i roli klienta w tym procesie. Dostawca zaś może nie mieć wystarczającej wiedzy o dziedzinie biznesowej, w której funkcjonuje organizacja klienta. W konsekwencji nie będzie w stanie ani zaproponować rozwiązania optymalnie spełniającego potrzeby klienta, ani - co gorsza - nie będzie w stanie ocenić wymagań dostarczonych przez klienta pod kątem możliwości implementacji.
- Niejasne sformułowania wymagań. Wymagania muszą być jasne i zrozumiałe. Należy stosować zasadę "mniej, znaczy lepiej" oraz zasadę prostoty i opisywać wymagania za pomocą precyzyjnie dobranych słów i prostych sformułowań. Złożone struktury składniowe, zdania wielokrotnie złożone, niejednoznaczne skróty itp. mogą spowodować, że pojawią się trudności ze zrozumieniem istoty wymagania. W przypadku gdy używane są skróty lub specyficzne dla danej dziedziny terminy, powinny być one wyjaśnione (np. w słowniczku).
- Zmienność wymagań. Problem wysokiego stopnia zmienności wymagań może wynikać z niskiej jakości procesu identyfikacji i analizy wymagań. Jeśli na początkowych etapach nie określono wszystkich ważnych wymagań, ograniczeń i założeń, co implikuje, że w dalszej kolejności nie poddano ich odpowiedniej analizie i włączeniu w zakres rozwiązania, może pojawić się konieczność wprowadzenia rozległych zmian (w tym logicznych i biznesowych) na późnych etapach projektu. Innym powodem zmienności wymagań może być sama dziedzina biznesowa organizacji. Niektóre obszary biznesowe ulegają ciągłym zmianom, ponieważ muszą dostosowywać się do zmieniających się potrzeb klientów lub rynku. Może to spowodować, że określone i uzgodnione na początku projektu wymagania przestają w jakimś zakresie obowiązywać lub zmienia się ich treść lub charakterystyki (np. priorytet). W takich przypadkach warto odnieść się do celów biznesowych danego projektu, gdyż daleko idące zmiany mogą spowodować to, że założenia projektu przestają być spójne z pierwotnymi celami i wizją. Należy uwzględnić to, iż zmienność wymagań nie jest postrzegana jako problem w środowiskach zwinnych, ponieważ metody zwinne zakładają elastyczność i otwartość na zmiany, wychodząc z założenia, że w początkowych etapach projektu rzadko można określić wymagania, które będą niezmiennie ważne do końca projektu.
- Niska jakość wymagań. Jakość wymagań wpływa bezpośrednio na jakość produku. Wszędzie tam, gdzie atrybuty jakości wymagań nie są spełnione, czyli wymagania są niejasne, niemożliwe lub sprzeczne, implementacja i późniejsze testowanie będą trudne lub nawet niemożliwe. Niska jakość wymagań najczęściej wynika z napiętego harmonogramu fazy wymagań, braku wystarczających umiejętności analityka lub braku kontroli jakości.
- Niewystarczające zaangażowanie interesariuszy. Większość wymagań wynika z potrzeb interesariuszy. Na wczesnych etapach projektu (w fazie koncepcji projektu i wczesnych fazach inżynierii wymagań) mamy do czynienia z wymaganiami wysokiego poziomu. Muszą one być przanalizowane, ocenione oraz uszczegółowione podczas fazy identyfikacji i analizy wymagań. Identyfikacja wymagań i ich dalsza analiza wymaga bezpośredniej współpracy z interesariuszami - w innym przypadku określenie rzeczywistych potrzeb i stworzenie optymalnego projektu rozwiązania realizującego oczekiwania wszystkich zaangażowanych stron staje się niemożliwe. Brak zaangażowania interesariuszy w procesie inżynierii wymagań może spowodować stworzenie rozwiązania, które nie spełni wymagań i potrzeb biznesowych. Istnieje również ryzyko tego, że przy braku współpracy z interesariuszami niektóre wymagania mogą nie zostać odkryte, co będzie stwierdzone na późnych etapach projektu i będzie wymagało wprowadzania rozległych zmian.
- Pominięte klasy interesariuszy. Ten problem jest najcześciej spowodowany niekompletną identyfikacją interesariuszy, co powinno być jednym z pierwszych kroków w inżynierii wymagań. Jeśli nie określono wszystkich kluczowych uczestników projektu i ich punktu widzenia na rozwiązanie, istnieje ryzyko, że produkt nie będzie miał wszystkich wymaganych cech, możliwości, funkcji lub nie będzie realizował procesów biznesowych. Przykładem pominięcia interesariuszy jest nieuwzględnienie osób odpowiedzialnych za utrzymanie docelowego systemu (np. za aktualizacje i zarządzanie bazami danych, konfigurację). Brak zaangażowania tych interesariuszy w proces opracowywania wymagań może spowodować, że nie wszystkie funkcje wymagane do pełnego wsparcia procesu biznesowego zostaną określone i włączone do zakresu rozwiązania. Pominięcie pewnych klas interesariuszy może nastąpić w następstwie niepełnej analizy użytkowników - braku określenia praw i przywilejów dla różnych typów użytkowników, np. admnistratorów, kierowników, operatorów. W tym przykładzie admnistratorzy czy kierownicy będą mieli inne uprawnienia i dostęp do innych elementów rozwiązania niż użytkownicy w roli operator.
- Błędne planowanie. Jest to jeden z najczęściej spotykanych problemów pojawiających się zarówno w kontekście samej inżynierii wymagań, jak i w całym przedsięwzięciu. W niektórych przypadkach wymagania wysokiego poziomu określone przez klienta w ramach umowy dotyczącej realizacji produktu są błędnie przeanalizowane i oszacowane przez dostawcę - często z powodu niskiej precyzji tych wymagań. W wyniku tego dostawca może dojść do wniosku, że szczegółowa analiza wymagań oraz projektowanie, implementacja i testowanie rozwiązania zajmie mniej czasu, niż jest wymagane naprawdę. Powoduje to, że czas przeznaczony na dalsze czynności projektowe, w tym analizę wymagań i projektowanie rozwiązania, jest zbyt krótki i istnieje poważne ryzyko dostarczenia produktu o niskiej jakości.
- Niewystarczająca specyfikacja wymagań/rozwiązania. W niektórych przypadkach organizacje zajmujące się wytwarzeniem produktów, zwłaszcza oprogramowania, nie przygotowują wystarczająco dokładnej specyfikacji produktu, koncentrując się raczej na implementacji. Powodem tego może być zwyczajne zaniedbywanie inżynierii wymagań i brak świadomości odnośnie do wartości tego procesu dla dalszych czynności wytwórczych. Innym powodem jest presja czasu i dążenie do jak najszybszego (i przy możliwie najniższym koszcie) dostarczenia produktu. W wielu przypadkach analiza i specyfikacja wymagań oraz ustalenie koncepcji rozwiązania ogranicza się do opracowania specyfikacji na bardzo wysokim poziomie ogólności i ustnych ustaleniach z klientem. W rezultacie istnieje poważne ryzyko tego, że produkt końcowy nie będzie spełniać oczekiwań klienta w dopuszczalnym stopniu - zabraknie bowiem pełnej analizy wymagań. Pojawi się również problem z zarządzaniem zmianą - jeśli brak specyfikacji wymagań, rozwiązania i samego produktu lub istnieje minimalna, niepełna specyfikacja, to ustalenie wpływu danej zmiany na inne elementy rozwiązania jest bardzo trudne. Co gorsza, może być problem w samym określeniu, co jest zmianą, a co nie (ponieważ zabraknie punktu odniesienia dla zmian). Kolejny problem jest związany z dalszym utrzymaniem systemu, które bez dokładnej specyfikacji jest bardzo trudne, zwłaszcza jeśli prace utrzymaniowe realizuje inny zespół niż zespół realizujący projekt wytwórczy.
1.1.6. Walidacja i weryfikacja
Jak już wspomniano przy okazji kryteriów jakości wymagań i specyfikacji, walidacja i weryfikacja pozwalają sterować jakością wymagań i kontrolować ją.
Definicja 1.10. Walidacja
Walidacja jest procesem potwierdzenia poprzez ocenę i dostarczenie obiektywnych dowodów, że spełnione są wymagania określone dla danego zastosowania [23].
Inna definicja opisuje walidację jako proces potwierdzenia, że specyfikacja danej fazy lub całego produktu spełnia wymagania klienta. Warta wspomnienia jest też interpretacja CMMI?, która mówi, że walidacja polega na sprawdzeniu, czy produkt lub jego komponent umożliwia wykonywanie zamierzonych operacji, kiedy umieści się go w docelowym środowisku.
W kontekście pracy z wymaganiami walidacja odbywa się zazwyczaj przy wsparciu klienta oraz interesariuszy biznesowych i ma na celu potwierdzenie, że wymagania lub ich specyfikacja odzwierciedlają i prawidłowo opisują potrzeby klienta.
Ogólnie walidacja ma na celu upewnienie się, że budowany jest "właściwy" (to jest zgodny z potrzebami) produkt. Jako że klienci i interesariusze biznesowi często opisują wymagania w niezbyt precyzyjny i dokładny sposób, walidacja kolejnych produktów inżynierii wymagań pomaga zrozumieć, co jest potrzebne do implementacji rozwiązania spełniającego oczekiwania i potrzeby interesariuszy. Typowe techniki i narzędzia służące do walidacji obejmują scenariusze i przypadki użycia (aby przedstawić interakcje rozwiązania z użytkownikiem), prototypowanie (w celu egzaminowania opcji i alternatywnych rozwiązań i podejść) oraz przeglądy (aby zbadać zgodność produktów inżynierii wymagań z celami interesariuszy).
Definicja 1.11. Weryfikacja
Weryfikacja jest procesem potwierdzenia poprzez ocenę i dostarczenie obiektywnych dowodów, że zostały spełnione określone wymagania [23].
Weryfikacja jest porównaniem produktu pośredniego z jego specyfikacjami. Tym samym wykonuje się kontrolę poprawności procesu realizacji - weryfikacja polega na sprawdzeniu, czy produkt jest wytwarzany zgodnie z wymaganiami, które zostały określone w poprzedniej fazie.
W interpretacji CMMI? weryfikacja dostarcza punktów kontrolnych, w których wybrane produkty końcowe lub pośrednie (np. specyfikacje) są sprawdzane pod kątem spełnienia wymagań w stosunku do produktów. Czynności weryfikacji polegają na iteracyjnym sprawdzaniu i potwierdzaniu poprawności implementacji wymagań; umożliwiają wczesną i systematyczną kontrolę projektu rozwiązania pod kątem zgodności z wymaganiami.
Przykład 1.8. Walidacja i weryfikacja
Walidacja:
- Demostracja prototypu aplikacji klientowi w celu zebrania informacji zwrotnej na temat stworzonych funkcji/użyteczności i ich zgodności z oczekiwaniami.
- Sesje użyteczności prowadzone przez klienta na wstępnej wersji systemu.
Weryfikacja:
- Testowanie aplikacji oparte na specyfikacji wymagań.
- Przegląd specyfikacji wymagań w celu sprawdzenia kompletności i poprawności specyfikacji względem produktów wcześniejszych faz.
Różnicę między walidacją a weryfikacją można wyrazić następująco: weryfikacja to sprawdzenie, czy tworzymy produkt właściwie, podczas gdy walidacja to sprawdzenie, czy tworzymy właściwy produkt.
Typowe techniki walidacji i weryfikacji to przegląd, demostracja projektu rozwiązania lub jego części interesariuszom, badanie kryteriów jakości przy użyciu list kontrolnych oraz testy dynamiczne.
1.1.7. Inżynieria wymagań, zarządzanie wymaganiami i opracowywanie wymagań
Czas zdefiniować dyscyplinę będącą przedmiotem niniejszego przewodnika. Według jednej z popularnych definicji inżynieria wymagań stanowi obszar inżynierii oprogramowania zorientowany na rzeczywiste cele biznesowe, funkcje i ograniczenia systemów oprogramowania. Dziedzina ta zajmuje się również powiązaniem wymienionych elementów z dokładną specyfikacją zachowania oprogramowania oraz ich zmianami i rozwojem zachodzącym w miarę upływu czasu [50].
Inna definicja, uznana przez REQB?, określa inżynierię wymagań następująco:
Definicja 1.12. Inżynieria wymagań
Inżynieria wymagań (ang. Requirements Engineeering, RE) jest podrzędną dyscypliną inżynierii oprogramowania koncentrującą się na określaniu wymagań dotyczących systemów sprzętowych i programowych i zarządzaniu nimi.
Inżynieria wymagań obejmuje kilka procesów podrzędnych: pozyskiwanie wymagań, analizę i negocjowanie wymagań (włączając priorytetyzację), specyfikację, modelowanie rozwiązania, walidację i weryfikację. Procesy te mogą się częściowo pokrywać, np. modelowanie systemu może być częścią zarówno analizy, jak i specyfikacji wymagań, a nawet w niektórych przypadkach - czynności identyfikacji wymagań.
Konkretne działania wchodzące w skład ogólnego procesu inżynierii wymagań obejmują:
- identyfikację wymagań,
- analizę wymagań,
- specyfikację wymagań,
- walidację i weryfikację,
- śledzenie wymagań,
- zarządzanie konfiguracją i zmianami,
- zapewnienie jakości.
Proces inżynierii wymagań jest uporządkowanym zbiorem wyżej wymienionych procesów. Są one zorganizowane w ramach procesu zarządzania wymaganiami lub opracowywania wymagań w zależności od celu i fazy wytwarzania rozwiązania. Kompletny opis procesu inżynierii wymagań powinien zawierać powiązania z innymi dyscyplinami i obszarami rozwijania produktu (np. z analizą biznesową lub testowaniem), informacje i produkty wejściowe i wyjściowe poszczególnych czynności działalności, informacje na temat odpowiedzialności co do określonych zadań oraz definicję rezultatów wykonywanych czynności, wymagane kompetencje i narzędzia wspierające.
Struktura procesu inżynierii wymagań zależy od wielu czynników, takich jak kultura organizacyjna i poziom dojrzałości, stosowany model procesu wytwarzania. Z tego powodu można wyróżnić następujące warianty tego procesu:
- ogólny proces inżynierii wymagań (ang. Generic Requirements Engineering process);
- proces inżynierii wymagań w modelach i podejściach do wytwarzania i utrzymania produktu (ang. Requirements Engineering process in development and maintenance models and approaches);
- proces inżynierii wymagań w modelach dojrzałości (ang. Requirements Engineering process in maturity models).
Ogólny proces inżynierii wymagań może być postrzegany jako punkt wyjścia dla każdej organizacji zaangażowanej w wytworzenie rozwiązania lub jego utrzymanie, ponieważ dostarcza on najbardziej istotnych procesów do obsługi i przetwarzania wymagań oraz przekształcania ich w koncepcję rozwiązania. Powinien on być oczywiście dostosowany do specyficznych potrzeb organizacji i uwzględniać możliwości stosowanego modelu procesu wytwarzania/utrzymania. Wynikiem tej adaptacji jest proces inżynierii wymagań w modelach i podejściach do wytwarzania i utrzymania produktu.
Oprócz modeli procesu wytwarzania istnieją modele dojrzałości procesów. Są one stosowane głównie do oceny bieżącej dojrzałości danej organizacji oraz do określenia i wprowadzania usprawnień mających na celu zwiększenie efektywności organizacji w wybranym zakresie. Inżynieria wymagań to w przypadku znacznego odsetka organizacji jeden z głównych obszarów potencjalnie wymagających usprawnienia, toteż większość modeli dojrzałości dostarcza konkretnych wymagań, zasad i praktyk które mają być wdrożone, by poprawić obecny proces inżynierii wymagań. W związku z tym możemy zdefiniować inny wariant ogólnego procesu inżynierii wymagań - proces inżynierii wymagań w modelach dojrzałości.
Definicja 1.13. Zarządzanie wymaganiami
Zarządzanie wymaganiami (ang. Requirements Management (RM)) jest to ciągły proces dokumentowania, analizowania, śledzenia, priorytetyzacji, komunikowania, uzgadniania oraz zarządzania zmianami wymagań. Obejmuje więc procesy służące do całościowego zarządzania wymaganiami.
Zarządzanie wymaganiami ustanawia i definiuje ramy działań dla procesu inżynierii wymagań oraz jej powiązania z innymi obszarami, takimi jak zarządzanie projektem, zarządzanie konfiguracją i zarządzanie jakością.
Celem etego procesu jest zarządzanie wymaganiami dla produktów i ich komponentów w danym projekcie, aby zapewnić spójność między tymi wymaganiami a planami projektu i produktami prac przez cały cykl życia produktu (co obejmuje cykl wytwarzania oraz cykl utrzymania).
Zarządzanie wymaganiami jest dyscypliną, którą można postrzegać jako proces zarządczy, ponieważ ustala pewne ramy dla innych, bardziej praktycznych zadań inżynierii wymagań, dostarcza środków do kontroli i monitorowania procesu oraz procesów pomocniczych wspierających pracę z wymaganiami. Wspominane "bardziej praktyczne zadania inżynierii wymagań" ujęte są w ramach procesu zwanego opracowywaniem wymagań.
Definicja 1.14. Opracowywanie wymagań
Opracowywanie (rozwój) wymagań (ang. Requirements Development (RD)) to zbiór czynności, zadań, technik i narzędzi służących do identyfikacji, analizy i walidacji wymagań.
Opracowywanie wymagań polega na identyfikacji, analizie, dokumentowaniu oraz walidacji wymagań na różnych poziomach abstrakcji. Obejmuje to proces przekształcania potrzeb w wymagania oraz rozwój tych wymagań (uszczegółowienie wymagań wysokiego poziomu) w koncepcję rozwiązania.
Opracowywanie wymagań można postrzegać jako implementację procesu ustalonego w ramach zarządzania wymaganiami.
1.1.8. Znaczenie inżynierii wymagań
Inżynieria wymagań ma zasadnicze znaczenie dla sukcesu każdego projektu IT. Wiele z głównych powodów niepowodzeń lub problemów w realizacji projektów jest związanych z wymaganiami. Zaniedbywanie poprawnej implementacji procesu inżynierii wymagań może spowodować, że wymagania pozostają nieprecyzyjne, sprzeczne, nie spełniają potrzeb interesariuszy - jednym słowem, mają niską jakość, co uniemożliwia opracowanie dobrego rozwiązania. W związku z tym staranny i dobrze zorganizowany proces inżynierii wymagań jest niezbędną częścią każdego projektu i należy go traktować jako element zarządzania projektem.
Powody zaniedbywania inżynierii wymagań mogą być następujące:
- Presja czasu - co prowadzi do skrócenia czasu przeznaczonego na identyfikację i analizę wymagań i powoduje, że produkty inżynierii wymagań są niskiej jakości.
- Presja osiągania szybkich rezultatów - czyli dążenie do wytworzenia produktu jak najszybciej. W wielu przypadkach organizacje zajmujące się rozwojem produktów, zwłaszcza oprogramowania, postrzega inżynierię wymagań jako proces bez żadnej wartości dodanej dla wytwarzania systemu. Organizacje takie koncentrują się na dostarczeniu "pożądanego rezultatu" rozumianego jako działający (dowolnie) produkt i minimalizacji wszelkich prac, których bezpośrednim rezultatem nie jest "końcowy produkt".
- Presja finansowa. Problem ten często wiąże się z aspektem opisanym powyżej. Niektóre organizacje traktują inżynierię wymagań jako proces zbędny dla wytworzenia produktu lub też stosują wyłącznie minimalny zestaw działań związanych z pracą z wymaganiami. Inżynieria wymagań jest przez nie traktowana jako zbędny koszt. Firmy te wychodzą z błędnego założenia, że wymagania biznesowe dostarczają wystarczającej informacji, by móc opracować i zaimplementować rozwiązanie.
- Uwzględnianie tylko wymagań funkcjonalnych i pomijanie wymagań niefunkcjonalnych. W punkcie 5.2.7 "Wymagania funkcjonalne i niefunkcjonalne" jest szczegółowo wyjaśnione znaczenie i trudności związane z oboma typami wymagań produktowych. Wymagania niefunkcjonalne są trudne do opisania. Klienci zazwyczaj nie potrafią ich wyrazić w mierzalny, precyzyjny sposób, czego konsekwencją jest to, że są one niejednoznaczne i nietestowalne. W rezultacie dostawca produktu może nie wziąć tych wymagań pod uwagę podczas projektowania rozwiązania lub nieprawidłowo je zrealizować.
- Niezrozumienie i brak świadomości znaczenia inżynierii wymagań dla powodzenia projektu. Jak już wspomniano powyżej, niektóre (zwykle mało dojrzałe) organizacje kładą minimalny nacisk na działania związane z inżynierią wymagań. Nie są świadome faktu (lub go ignorują), iż słaby proces obsługi wymagań zwiększa ryzyko niepowodzenia projektu.
Należy pamiętać, że jakikolwiek błąd w inżynierii wymagań ma wpływ na dalsze etapy projektu - produkty tego procesu są bowiem podstawą większej części prac związanych z projektowaniem i wytwarzaniem produktu. Ponadto defekty wynikające ze słabej jakości procesu inżynierii wymagań i/lub jej produktów są szczególnie kosztowne w naprawie i obarczone sporym ryzykiem, ponieważ ich naprawa zwykle oznacza konieczność zmiany podstaw, na których jest oparty produkt.
Możliwe konsekwencje zaniedbywania inżynierii wymagań są następujące:
- wymagania o niskiej jakości;
- wymagania, które często się zmieniają w trakcie opracowywania produktu;
- wymagania, które nie spełniają kryteriów akceptacji klienta;
- wymagania, które nie dostarczają żadnych wartości dla interesariuszy;
- brak pewnych wymagań.
Powyższe problemy są bardzo istotne, ponieważ w prosty sposób mogą prowadzić do niepowodzenia realizacji projektu. W związku z tym inżynieria wymagań powinna być zawsze przedmiotem starannego planowania. Skuteczny i dostosowany do potrzeb, możliwości i ograniczeń danego projektu proces inżynierii wymagań oraz użycie odpowiednich narzędzi i technik minimalizuje ryzyko niepowodzenia projektu.
Po przeczytaniu tego podrozdziału powinieneś:
LO-1.1.1
Wyjaśnić koncepcję problemu, rozwiązania i produktu (K2).
LO-1.1.2
Wyjaśnić koncepcję wymagania oraz jego klasyfikacji (wymagania produktowe i ograniczenia) (K2).
LO-1.1.3
Wyjaśnić różnicę pomiędzy różnymi poziomami wymagań (np. wymagania biznesowe, wymagania rozwiązanie (systemu) i wymagania produktu (komponentu)) oraz ich znaczenie dla inżynierii wymagań (K2).
LO-1.1.4
Wyjaśnić koncepcję atrybutów wymagań (np. zobowiązanie, priorytet i krytyczność) (K2).
LO-1.1.5
Zrozumieć typowe problemy związane z wymaganiami i wyjaśnić rolę walidacji, weryfikacji i kryteriów akceptacji w kontekście poprawy jakości wymagań (K2).
1.2. Standardy i normy
Celem tego podrozdziału jest dostarczenie podstawowych informacji na temat standardów i norm mających zastosowanie w inżynierii wymagań.
Opisane poniżej standardy i normy są wzmiankowane w planie nauczania REQB?. Należy jednak mieć świadomość tego, że istnieje znacznie więcej standardów i innych źródeł wiedzy i dobrych praktyk.
Definicja 1.15. Standard
Standard jest formalnym, czasem obowiązkowym, zestawem wymagań opracowanych i używanych w celu określenia spójnego podejścia do sposobu pracy lub zapewnienia wytycznych.
Istnieje co njamniej kilka uznanych na całym świecie organizacji standaryzujących. Wymienimy poniżej kilka z nich.
- ISO (ang. International Organization for Standardization) to międzynarodowa organizacja normalizacyjna stanowiąca różnego rodzaju standardy. W jej skład wchodzą przedstawiciele różnych narodowych organizacji normalizacyjnych. Oprócz standardów (np. seria ISO 9000) ISO publikuje również raporty i specyfikacje techniczne, sprostowania techniczne i przewodniki.
- IEEE (ang. Institute of Electrical and Electronics Engineers) to stowarzyszenie non-profit mające na celu rozwijanie innowacji technologicznych związanych z elektrotechniką, elektroniką i informatyką. Jest to jedna z czołowych instytucji normalizacyjnych na świecie (w ramach IEEE działa Stowarzyszenie ds. standardyzacji IEEE-SA (ang. IEEE Standards Association)). Standary opracowane przez IEEE dotyczą m.in.: technologii informacyjnej, elektroniki, biomedycyny i zdrowia, telekomunikacji, transportu, nanotechnologii.
- IEC (ang. International Electrotechnical Commission) jest pozarządową organizacją non-profit opracowującą międzynarodowe standardy w dziedzinie elektrotechniki i elektroniki.
1.2.1. Standardy związane z wymaganiami
ISO 9000 - Zarządzanie jakością (ang. Quality management)
ISO 9000 jest rodziną norm związanych z systemami zarządzania jakością. Zawiera zarówno zbiór standardów i wytycznych, jak i standardy wspomagające.
Jednym z najbardziej znanych standardów z rodziny ISO 9000 jest ISO 9001.
ISO/IEC 25000: Inżynieria oprogramowania - wymagania dotyczące jakości i oceny produktu informatycznego (SquaRE). Przewodnik po SquaRE (ang. Software Engineering - Software product Quality Requirements and Evaluation) ISO/IEC 25000 to przewodnik do międzynarodowych standardów określonych mianem SQuaRE - wymagań dotyczących jakości i oceny produktu informatycznego. Celem tego przewodnika jest dostarczenie ogólnego przeglądu zawartości SQuaRE, wprowadzenie wspólnych definicji jako modelu referencyjnego oraz wyjaśnienie relacji między dokumentami.
IEEE 610-1990: Standardowy słownik terminologii używanej w inżynierii oprogramowania (ang. Standard Glossary of Software Engineering Terminology) IEEE 610 określa pojęcia i terminy stosowane w dziedzinie inżynierii oprogramowania.
IEEE 830-1998: Zalecane praktyki dla specyfikacji wymagań na oprogramowanie (ang. Recommended Practice for Software Requirements Specifications)
Standard opisuje treść i cechy jakościowe dobrej specyfikacji wymagań dotyczącej oprogramowania (ang. Software Requirements Specification, SRS) oraz zalecane podejście do opracowywania specyfikacji wymagań związanych z oprogramowaniem. Standard zawiera również kilka przykładowych szablonów SRS oraz cenne wskazówki pozwalające na tworzenie jednoznacznego i pełnego dokumentu specyfikacji.
IEEE 1233-1996: Przewodnik do opracowania specyfikacji wymagań na system (ang. Guide for Developing of System Requirements Specifications)
IEEE 1233 obejmuje wytyczne dotyczące opracowywania specyfikacji wymagań co do systemu (ang. System Requirements Specification, SyRS) w tym aspekty identyfikacji, organizacji, prezentacji i modyfikacji wymagań. Standard opisuje ponadto niezbędne cechy i atrybuty jakościowe poszczególnych wymagań oraz całego ich zestawu oraz warunki, które należy włączać do specyfikacji koncepcji operacyjnych, ograniczeń projektowych i wymagań konfiguracji projektu.
IEEE 1362-1998: Przewodnik technologii informatycznych - definicja systemu - dokument koncepcji operacji biznesowych (ConOps) (ang. Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document)
Standard opisuje format i zawartość dokumentu o nazwie "Koncepcja operacji" [biznesowych] (ang. Concept of operation, ConOps), który zawiera opis cech systemu z punktu widzenia użytkowników. Dokument ConOps ma umożliwić przekazanie informacji o cechach ilościowych i jakościowych systemu pomiędzy użytkownikiem, klientem, programistą i innymi interesariuszami. Dokument zawiera również opis organizacji użytkownika, misji i celów organizacyjnych z punktu widzenia zintegrowanych systemów.
Uwaga: IEEE 830, IEEE 1233 i IEEE 1362 zostały zastąpione przez ISO/IEC/IEEE 29148:2011.
SWEBOK: Przewodnik do obszaru wiedzy inżynierii oprogramowania (raport techniczny ISO 19759) (ang. The Guide to the Software Engineering Body of Knowledge)
SWEBOK opisuje ogólnie przyjętą wiedzę z obszaru inżynierii oprogramowania. Dokument ten obejmuje 10 obszarów wiedzy podsumowujących podstawowe koncepcje inżynierii oprogramowania. Każdy rozdział zawiera odniesienie do szczegółowych informacji (np. odpowiednich norm).
1.2.2. Normy procesowe
Normy procesowe odnoszą się do modeli procesów (wytwarzania, dojrzałości itd.). Standardy te dostarczają wzorców różnych modeli procesów, np. procesów cyklu życia. Dokładna definicja modelu procesu jest podana w rozdz. 6 ". Modele procesów".
ISO 12207:2008: Standard dla procesu cyklu życia oprogramowania (ang. Software Lifecycle processes)
Standard ISO 12207 określa proces cyklu życia oprogramowania, w tym procesy i czynności nabycia i konfiguracji usług systemu. Każdy proces ma zdefiniowany zestaw związanych z nim wyników. Definiuje on 43 procesy dotyczące systemu i oprogramowania.
Wyróżniono pięć głównych procesów związanych z tworzeniem oprogramowania:
- nabycie,
- dostawa,
- rozwój,
- działanie,
- utrzymanie.
ISO 15288: Proces cyklu życia systemu (ang. System Life Cycle Process)
ISO/IEC 15288 jest standardem dla inżynierii systemowej, który obejmuje procesy oraz etapy cyklu życia.
Standard definiuje procesy podzielone na cztery kategorie: procesy technologiczne, procesy projektowe, procesy akceptacji i procesy organizacyjne. Dla każdego procesu są określane następująca informacje: cel, wynik i czynności.
Dokument opisuje przykładowe etapy cyklu życia systemu informatycznego: fazę koncepcji, rozwijania, wytwarzania, działania, wsparcia po wprowadzeniu na rynek oraz wycofania.
ISO 15288 może być powiązany z wieloma istniejącymi podejściami do inżynierii systemowej, w tym CMMI i ISO 12207.
ISO/IEC 15504: Model określania zdolności i doskonalenia procesów oprogramowania (SPICE) (ang. Software Process Improvement and Capability Determination)
SPICE to zestaw norm technicznych dotyczących procesu rozwoju oprogramowania oraz powiązanych z nim funkcji zarządczych. Standard został opracowany przez ISO oraz IEC.
CMMI (ang. Capability Maturity Model Integration)
CMMI jest modelem procesu służącym do oceny możliwości organizacji oraz doskonalenia procesu wparcia organizacji w zwiększeniu ich wydajności. Model może służyć do poprawy procesów w całej organizacji lub usprawnieniu procesów w określonym dziale lub konkretnym projekcie. Podobnie jak SPICE CMMI definiuje model złożony z kilku poziomów dojrzałości.
Po przeczytaniu tego podrozdziału powinieneś:
LO-1.2.1
Wyjaśnić możliwe korzyści i zastosowanie norm związanych z inżynierią wymagań (K2)
1.3. Przykładowe pytania
Pytanie 1.1. LO-1.1.1
Które z poniższych stwierdzeń definiujących rozwiązanie jest zawsze prawdziwe?
[A] Rozwiązanie jest odpowiedzią na potrzeby klienta.
[B] Rozwiązanie jest implementacją wymagań w postaci systemu oprogramowania.
[C] Tworzenie rozwiązania wymaga przekształcenia problemu biznesowego na rozwiązanie przy użyciu formalnej notacji do modelowania.
[D] Zadaniem inżynierii wymagań jest implementacja rozwiązania.
LO-1.1.1. Wyjaśnić koncepcję problemu, rozwiązania i produktu (K2).
Odpowiedź: A
Pytanie 1.2. LO-1.1.2
Które z poniższych stwierdzeń nie jest prawdziwe?
[A] Wymaganie to warunek lub zdolność potrzebne użytkownikowi, aby rozwiązać dany problem lub osiągnąć określony cel.
[B] Wymagania to oczekiwania i potrzeby interesariuszy wyrażone zarówno w postaci udokumentowanej, jak i nieudokumentowanej.
[C] Wymagania mogą być związane z procesem wytwarzania oprogramowania.
[D] Jednym z najważniejszych źródeł wymagań są interesariusze projeku.
LO-1.1.2 Wyjaśnić koncepcję wymagania oraz jego klasyfikacji (wymagania produktowe i ograniczenia) (K2).
Odpowiedź: B
Pytanie 1.3. LO-1.1.2
Jakiego rodzaju wymaganie jest wyrażone za pomocą następującego zdania?
"Projekt powinien być zarządzany przy użyciu metodyki PRINCE2".
[A] Ograniczenie.
[B] Wymaganie produktowe.
[C] Wymaganie użytkownika.
[D] To nie jest wymaganie.
LO-1.1.2 Wyjaśnić koncepcję wymagania oraz jego klasyfikacji (wymagania produktowe i ograniczenia) (K2).
Odpowiedź: A
Pytanie 1.4. LO-1.1.5
Które z następujących stwierdzeń nie jest typowym błędem związanym z inżynierią wymagań?
[A] Niejasność celów biznesowych projektu.
[B] Problemy komunikacyjne pomiędzy interesariuszami.
[C] Zdefiniowane i utrzymywane na bieżąco śledzenie powiązań.
[D] Niestabilność wymagań biznesowych.
LO 1.1.5 Zrozumieć typowe problemy związane z wymaganiami i wyjaśnić rolę walidacji, weryfikacji i kryteriów akceptacji w kontekście poprawy jakości wymagań (K2).
Odpowiedź: C
Pytanie 1.5. LO-1.2.1
Która z następujących norm będzie najlepszym wyborem dla wsparcia procesu tworzenia specyfikacji wymagań na oprogramowanie?
[A] IEEE 610: Standardowy słownik terminologii inżynierii oprogramowania.
[B] IEEE 830: Zalecane praktyki dla specyfikacji wymagań na oprogramowanie.
[C] IEEE 1362-1998: Przewodnik dla technologii informatycznych - definicja systemu - dokument koncepcji operacji biznesowych (ConOps).
[D] ISO 12207: Standard dla procesu cyklu życia oprogramowania.
LO-1.2.1. Wyjaśnić możliwe korzyści i zastosowanie norm związanych z inżynierią wymagań (K2).
Odpowiedź: B
