Syllabus REQB® Certyfikowany specjalista inżynierii...

Syllabus

REQB® Certyfikowany specjalista

inżynierii wymagań

Poziom podstawowy

Wersja 1.2PL

1 Grudnia 2010

Prawa autorskie ® do tej edycji syllabusa dla wszystkich języków należą do Global Association

for Software Quality, gasq

REQB® Certyfikowany specjalista inżynierii wymagao

Poziom podstawowy

2 Wersja 1.2PL

© gasq – Global Association for Software Quality

1 Grudzieo 2010

Podsumowanie zmian

Wersja Data Komentarz

0.1 17.04.2006 PIerwsza wersja syllabusa; stworzenie podstawowej struktury syl labusa

0.2 20.07.2006 Rozszerzenie wersji 0.1

0.3 04.09.2006 Dalsze rozszerzenie i rewizja wersji 0.1

0.4 10.10.2006 Rewizja wersji 0.3

0.5 15.12.2006 Rewizja wersji 0.4

0.6 07.02.2007 Kompletnie zrewidowana wersja 0.5

0.7 10.04.2007 Wersja zrewidowana dla przeglądu

0.8 15.06.2007 Wersja Alpha

0.9 01.09.2007 Wersja Beta

1.0 15.01.2008 Wydanie 1.0

1.1 29.05.2008 Zaktualizowana wersja 1.1

1.2 01.07.2008 Zaktualizowana wersja 1.2

1.2PL 01.12.2010 Tłumaczenie wersji 1.2 na język polski

Prawa autorskie ® do tego syllabusa dla wszystkich języków należą do Global Association for

Software Quality, gasq


Poziom podstawowy

3 Wersja 1.2PL


1 Grudzieo 2010

Nadrzędna idea

Głównym tematem tego syllabusa jest ciągle rosnąca złożonośd oprogramowania i nasza

zależnośd od niego. W rezultacie pojawia się wysoki poziom zależności od braku błędów w

oprogramowaniu. Requirements Engineering Qualifications Board (REQB) postanowił zatem

stworzyd jednolite międzynarodowe standardy w dziedzinie inżynierii wymagao. Standardy

są jednak jak języki - tylko wtedy, gdy je zrozumiesz, możesz pracowad efektywnie. Aby

stworzyd taki jednolity język w tak ważnej dziedzinie, jak inżynieria wymagao,

międzynarodowi eksperci zebrali się w REQB i opracowali niniejszy syllabus.

Tłumaczenie

Oryginalna wersja syllabusa została przetłumaczona przez zespół gasq.pl oraz testerzy.pl w

składzie: Michał Figarski, Dariusz Paczewski, Radosław Smilgin, Karolina Zmitrowicz.


Poziom podstawowy

4 Wersja 1.2PL


1 Grudzieo 2010

1. Spis treści Wprowadzenie ........................................................................................................................... 6

1. Podstawy ............................................................................................................................. 8

1.1. Wymaganie .................................................................................................................. 8

1.2. Standardy i normy...................................................................................................... 12

2. Procedury i procesy ........................................................................................................... 14

2.1. Modele procesowe .................................................................................................... 14

2.2. Proces inżynierii wymagao ........................................................................................ 16

3. Zarządzanie projektem i zarządzanie ryzykiem................................................................. 17

3.1. Zarządzanie projektem .............................................................................................. 17

3.2. Zarządzanie ryzykiem................................................................................................. 18

4. Odpowiedzialności i role ................................................................................................... 19

4.1. Podstawowe role ....................................................................................................... 19

4.2. Zadania w inżynierii wymagao................................................................................... 20

5. Identyfikacja wymagao ..................................................................................................... 21

5.1. Klient .......................................................................................................................... 21

5.2. Wizja i cele projektu .................................................................................................. 22

5.3. Identyfikacja interesariuszy ....................................................................................... 22

5.4. Techniki identyfikacji wymagao................................................................................. 23

5.5. Wymagania funkcjonalne i niefunkcjonalne ............................................................. 23

5.6. Opis wymagao............................................................................................................ 24

6. Specyfikacja wymagao ...................................................................................................... 26

6.1. Specyfikacja ............................................................................................................... 26

6.2. Procedura................................................................................................................... 27

6.3. Formalizacja ............................................................................................................... 27

6.4. Jakośd Wymagao........................................................................................................ 28

7. Analiza wymagao............................................................................................................... 29

7.1. Wymagania i rozwiązania .......................................................................................... 29


Poziom podstawowy

5 Wersja 1.2PL


1 Grudzieo 2010

7.2. Metody i Techniki ...................................................................................................... 30

7.3. Analiza zorientowana obiektowo .............................................................................. 30

7.4. Estymacja Kosztów .................................................................................................... 31

7.5. Priorytetyzacja ........................................................................................................... 31

7.6. Akceptacja wymagao ................................................................................................. 32

8. Śledzenie wymagao ........................................................................................................... 33

8.1. Śledzenie wymagao w projekcie................................................................................ 33

8.2. Zarządzanie zmianą.................................................................................................... 34

8.3. Metryki ....................................................................................................................... 35

9. Zapewnienie jakości .......................................................................................................... 36

9.1. Czynniki sukcesu ........................................................................................................ 36

9.2. Zapewnienie jakości poprzez testowalnośd............................................................... 36

10. Narzędzia ....................................................................................................................... 38

10.1. Zalety narzędzi........................................................................................................ 38

10.2. Kategorie narzędzi .................................................................................................. 38

11. Literatura ....................................................................................................................... 40


Poziom podstawowy

6 Wersja 1.2PL


1 Grudzieo 2010

Wprowadzenie

Cel syllabusa

Niniejszy syllabus definiuje poziom podstawowy (Foundation Level) programu szkolenia

umożliwiającego zostanie certyfikowanym specjalistą inżynierii wymagao REQB (w skrócie

CPRE - Certified Professional for Requirements Engineering). Syllabus ten został opracowany

przez REQB we współpracy z Global Association for Software Quality.

Syllabus ma służyd jako podstawa dla organizatorów szkoleo, którzy chcieliby pozyskad

akredytację trenerską. Wszystkie obszary niniejszego syllabusa muszą byd odpowiednio

włączone do materiałów szkoleniowych. Syllabus powinien jednak również służyd jako

przygotowanie do certyfikacji. Wszystkie obszary wymienione tutaj są zatem istotne dla

egzaminu, do którego można podchodzid albo po ukooczeniu akredytowanych kursów, albo

podczas egzaminów otwartych.

Certyfikacja

Egzamin na certyfikowanego specjalistę inżynierii wymagao odbywa się na podstawie

niniejszego syllabusa, dlatego wszystkie sekcje syllabusa mogą podlegad weryfikacji. Pytania

egzaminacyjne muszą byd rozdzielone na poszczególne sekcje. Jedno pytanie może odnosid

się do kilku sekcji syllabusa.

Format egzaminu to test jednokrotnego wyboru.

Do egzaminu można podejśd po uczestnictwie w akredytowanym kursie lub w bez

wcześniejszego kursu podczas otwartych egzaminów. Szczegółowe informacje dotyczące

terminów egzaminów można znaleźd na stronie internetowej gasq (www.gasq.org) lub na

stronie internetowej REQB (www.reqb.org).

Akredytacja

Dostawcy kursu na certyfikowanego specjalistę inżynierii wymagao REQB muszą byd

akredytowani przez Global Association for Software Quality. Eksperci GASQ dokonują

przeglądu dokumentacji szkoleniowej pod kątem zgodności z syllabusem. Kurs akredytowany

musi zostad uznany za zgodny z syllabusem. Na zakooczenie kursu prowadzonego na

podstawie certyfikowanych materiałów może zostad przeprowadzony oficjalny egzamin na

certyfikowanego specjalistę inżynierii wymagao (egzamin CPRE). Egzamin jest

http://www.gasq.org/

http://www.reqb.org/


Poziom podstawowy

7 Wersja 1.2PL


1 Grudzieo 2010

przeprowadzany przez niezależny instytut certyfikacji

(zgodnie z zasadami normy ISO 17024).

Akredytowane ośrodki szkoleniowe są identyfikowane

poprzez oficjalne logo akredytowanego dostawcy szkoleo

REQB.

Międzynarodowość

Niniejszy syllabus został opracowany we współpracy grupy międzynarodowych ekspertów, .

dlatego też jego zawartośd może byd postrzegana jako międzynarodowy standard. Tym

samym syllabus umożliwia szkolenie i egzaminowanie na arenie międzynarodowej na

jednakowym poziomie.

Poziomy K

Syllabus ten został podzielony na różne poziomy K. Pozwala to kandydatowi rozpoznad

„poziom wymaganej wiedzy” każdego punktu.

W obecnym syllabusie istnieją 3 K-poziomy:

K1 – zapamiętaj, rozpoznaj, przypomnij

K2 – zrozum, wyjaśnij, podaj powód, porównaj, sklasyfikuj, podsumuj

K3 – zastosuj w konkretnej sytuacji


Poziom podstawowy

8 Wersja 1.2PL


1 Grudzieo 2010

1. Podstawy

Cele nauczania

Czym jest wymaganie?

Jakie jest znaczenie i cel wymagao?

Jak można sklasyfikowad wymagania?

Jakie istnieją typy wymagao?

Jakie problemy pojawiają się przy okazji wymagao?

Jakie koncepcje są ważne w powiązaniu z wymaganiami?

Jaka jest różnica pomiędzy Zarządzaniem Wymaganiami a Inżynierią Wymagao?

Jakie istotne normy i standardy wiążą się z wymaganiami?

Dlaczego zarządzanie wymaganiami jest ważne?

1.1. Wymaganie

Definicja tego, co jest rozumiane pod pojęciem „Wymaganie” (K1)

Słownik:

IEEE 610.12: Wymaganie to warunek lub umiejętnośd potrzebna użytkownikowi do

rozwiązania problemu lub osiągnięcia celu.

Jakie jest znaczenie i cel wymagao? (K2)

Podstawa dla oceny, planowania, przeprowadzania i monitorowania czynności

projektowych

Oczekiwania klienta

Składnik umów, zamówieo, planów projektowych…

Ustanawianie granic systemu, zakresu dostawy, umownych usług serwisowych


Poziom podstawowy

9 Wersja 1.2PL


1 Grudzieo 2010

Klasyfikacja wymagao (zgodnie z Ebert05) (K 2)

Wymagania dzielimy na wymagania procesowe i wymagania produktowe.

Wymagania procesowe: koszty, marketing, czas przetwarzania, sprzedaż, dystrybucja,

organizacja, dokumentacja.

Opisują potrzeby i ograniczenia procesów biznesowych.

Wymagania produktowe składają się z funkcjonalnych i niefunkcjonalnych wymagao

produktowych.

Oba rodzaje mogą byd postrzegane z punktu widzenia użytkownika (zewnętrzne) lub klienta

oraz z punktu widzenia dewelopera (wewnętrzne).

Funkcjonalne wymagania produktowe z punktu widzenia użytkownika to: interfejs

użytkownika (UI), aplikacje, usługi.

Funkcjonalne wymagania produktowe z punktu widzenia klienta to: interfejs użytkownika

(UI), aplikacje, usługi.

Uwaga: Użytkownik i klient mogą byd różnymi osobami!

Funkcjonalne wymagania produktowe z punktu widzenia dewelopera to: architektura,

zasilanie, rozkład obciążenia.

Wymagania funkcjonalne opisują funkcje systemu.

Niefunkcjonalne wymagania produktowe z punktu widzenia użytkownika to: niezawodnośd,

wydajnośd, użytecznośd.

Niefunkcjonalne wymagania produktowe z punktu widzenia klienta to: niezawodnośd,

wydajnośd, użytecznośd.

Niefunkcjonalne wymagania produktowe z punktu widzenia dewelopera to: testowalnośd,

utrzymanie, narzędzia.

Wymagania niefunkcjonalne opisują atrybuty jakościowe systemu.


Poziom podstawowy

10 Wersja 1.2PL


1 Grudzieo 2010

Typy wymagao: wymagania klienta, wymagania systemowe lub też specyficzne dla danego

rozwiązania, wymagania produktowe/komponentowe.

Problemy związane z wymaganiami (K2):

Niejasne cele

Problemy komunikacyjne

Bariery językowe

Bariery wiedzy

Ogólnikowe sformułowania

Zbyt formalne określenia

Dwuznaczne, nadmiernie specyfikowane, niejasne, niemożliwe, sprzeczne

sformułowania

Niestabilnośd wymagao

Zła jakośd wymagao

Zbytnie „ozłocenie”

Niewystarczające zaangażowanie użytkowników

Pominięte klasy użytkownika

Nieprecyzyjne planowanie

Minimalna specyfikacja

Kryteria jakościowe dla wymagao (według Wiegers05): (K2)

1. Każde wymaganie musi byd kompletne, poprawne, wykonalne, niezbędne,

spriorytetyzowane, jednoznaczne, weryfikowalne

2. Specyfikacja wymagao musi byd kompletna, spójna, modyfikowalna i umożliwiająca

śledzenie zmian

Dla firm szkoleniowych: wyjaśnid poszczególne kryteria jakościowe.

Rozwiązanie (K1)

Rozwiązanie jest implementacją wymagao.

Zobowiązanie (K1)

Zobowiązanie jest poziomem zobligowania się do wykonania czegoś .


Poziom podstawowy

11 Wersja 1.2PL


1 Grudzieo 2010

Definiowanie zobowiązania poprzez słowa kluczowe.

Dla firm szkoleniowych: wyjaśnid słowa kluczowe.

Obserwacja aspektów prawnych, szczególnie na okolicznośd usterek.

Usterka (K1)

Odstępstwo aktualnego stanu od oczekiwanego stanu.

Priorytety wymagao (K1)

Ocena ważności/pilności.

Krytycznośd wymagao (K1)

Ocena ryzyka powiązanego z wymaganiem poprzez ocenę szkód w przypadku niespełnienia

wymagania.

Walidacja (K1)

Proces potwierdzania, że specyfikacja danej fazy lub cały system spełnia wymagania klienta .

Weryfikacja (K1)

Porównanie pośredniego produktu z jego specyfikacją. Weryfikacja jest więc ustaleniem, czy

oprogramowanie zostało przygotowane poprawnie i zgodnie ze specyfikacją przygotowaną w

poprzednich fazach.

Rozgraniczenie pomiędzy zarządzaniem a inżynierią wymagao. (K2)

Zarządzanie Wymaganiami obejmuje procesy służące identyfikacji i zarządzaniu

wymaganiami.

Inżynieria wymagao zawiera podstawowe umiejętności inżynierskie.

Dla firm szkoleniowych: rozwinąd opisy poszczególnych obszarów.


Poziom podstawowy

12 Wersja 1.2PL


1 Grudzieo 2010

1.2. Standardy i normy

ISO 9000:

Wymagania w stosunku do systemu zarządzania jakością.

Zdefiniowana podstawowa koncepcja Systemów Zarządzania Jakością (ang. Quality

Management System, QMS)

Koncepcja niezależna od domeny lub gałęzi przemysłu

ISO 9126:

Definiuje model jakości w sześciu kategoriach:

Funkcjonalnośd, niezawodnośd, użytecznośd, efektywnośd, utrzymywalnośd, przenaszalnośd.

IEEE 610:

Standardowy Słownik dla Terminologii Inżynierii Oprogramowania,

IEEE 830:

Rekomendowane Praktyki dla Specyfikacji Wymagao Oprogramowania.

IEEE 1233:

Wytyczne do Opracowywania Specyfikacji Wymagao Oprogramowania.

IEEE 1362:

Wytyczne dla Technologii Informacyjnych – Definicja Systemu.

Normy procesowe:

ISO 12207:

Standard dla Procesu Cyklu Życia Oprogramowania.

ISO 15288:

Proces Cyklu Życia Oprogramowania.


Poziom podstawowy

13 Wersja 1.2PL


1 Grudzieo 2010

ISO 15504:

Ulepszanie i określanie możliwości procesu oprogramowania (ang. Software Process

Improvement and Capability Determination (SPICE))

CMMI Zintegrowany Model Dojrzałości Zdolności (ang. Capability Maturity Model

Integrated)

Aby zdad egzamin nie trzeba znad zawartości każdej z tych norm. Ważne jest jednak (K1), by

wiedzied, które normy są istotne dla Inżynierii Wymagao.

Inżynieria wymagao ma kluczowe znaczenie, jednak nadal jest zaniedbywana.

Dla firm szkoleniowych: podkreślid wagę Inżynierii wymagao i powodów, dla których jest

często pomijana (K2).

Zaniedbywanie z powodu dużej presji czasu

Zaniedbanie ze względu na zorientowanie na szybkie rezultaty

Zaniedbanie ze względu na ograniczanie kosztów

Zaniedbanie ze względu na niewłaściwą interpretację (wiele rzeczy jest postrzeganych

tak, jak podano)

Możliwe konsekwencje zaniedbao w Inżynierii Wymagao (K2):

Wymagania stają się nieprecyzyjne

Wymagania są niejednoznaczne

Wymagania są sprzeczne

Wymagania, które się zmieniają

Wymagania niespełniające kryteriów

Wymagania, które mogą byd interpretowane w różny sposób

Brakujące wymagania


Poziom podstawowy

14 Wersja 1.2PL


1 Grudzieo 2010

2. Procedury i procesy

Cele nauczania

Jakie istnieją modele procesowe?

Czym różnią się modele?

Czym charakteryzuje się proces inżynierii wymagao?

Jakie istnieją fazy procesu inżynierii wymagao?

2.1. Modele procesowe Modele proceduralne (K2)

Niezależny od metody opis procesu wytwarzania oprogramowania.

Uwzględnione są : role, aktywności, fazy i dokumenty.

Cykl życia produktu (ang. Product life cycle (PLC)) (K2)

Podstawowe fazy: planowanie, rozwój, utrzymanie, koniec życia.

Faza planowania zawiera: wizję, strategię, biznesplan, analizę kosztów/korzyści.

Faza rozwoju zawiera: specyfikację, projekt i implementację.

Definiuje różne fazy wytwarzania produktu.

Ogólny Model V (K 2)

Fazy rozwoju oprogramowania:

Zdefiniowanie i określenie wymagao (specyfikacja wydajnościowa)

Projektowanie systemu od strony funkcjonalnej, analiza systemu (specyfikacja

funkcjonalna)

Projektowanie techniczne, projekt architektury (projekt oprogramowania)

Specyfikacja komponentów


Poziom podstawowy

15 Wersja 1.2PL


1 Grudzieo 2010

Implementacja

Dla firm szkoleniowych: wymagane graficzne przedstawienie Ogólnego Modelu V, dogłębny

opis Modelu V.

Rational Unified Process (RUP©) (K2)

Model proceduralny od IBM Rational ©

Iteracyjny proces rozwojowy:

4 fazy (powstanie, opracowanie (elaboracja), budowa, przekazanie)

9 dyscyplin (między innym - wymagania)

Dla firm szkoleniowych: graficzne przedstawienie RUP©, pogłębione e studium dyscypliny

wymagao.

Programowanie ekstremalne (K2)

Model proceduralny stworzony przez Kenta Becka

Zarządzanie wymaganiami jako główny komponent

Absolutnie bez inwestygacji (dochodzenia) wymagao

Dla firm szkoleniowych: wyjaśnid co najmniej trzy modele zwinne włączając w to Scrum i

Crystal.

Stopieo modelu dojrzałości (K2)

Identyfikacja i ulepszanie dojrzałości procesu (ocena procesu i ulepszanie procesu)

Definicja stopnia dojrzałości i powiązanej z nim specyfikacji procesowej

Dla firm szkoleniowych: pogłębid na przykładzie ISO 15504/SPICE; wraz z opisem typowych

wymagao dla Inżynierii Wymagao.


Poziom podstawowy

16 Wersja 1.2PL


1 Grudzieo 2010

2.2. Proces inżynierii wymagao

Proces nie będący procesem głównym, który dotyczy wszystkich faz rozwoju systemów:

Identyfikacja wymagao

Analiza wymagao

Specyfikacja wymagao

Zmiany w wymaganiach

Weryfikacja

Zapewnienie jakości

Opis czynników wpływających negatywnie na procesy.

Opis różnych punktów widzenia (klienta, dostawcy).

Metoda procesu inżynierii wymagao z klientem w centrum.


Poziom podstawowy

17 Wersja 1.2PL


1 Grudzieo 2010

3. Zarządzanie projektem i zarządzanie ryzykiem

Cele nauczania

Dlaczego inżynieria wymagao jest ważna w projekcie?

Jakie błędy mogą się pojawid w inżynierii wymagao?

Jakie ryzyka są powiązane z wymaganiami?

3.1. Zarządzanie projektem

Wyjaśnienie niezbędności Inżynierii Wymagao w projektach informatycznych (K2)

Inżynieria wymagao powinna wnieśd wkład do następujących obszarów: (K 1)

Koncepcji projektu

Negocjacji kontraktu

Definicji projektu

Wykonania projektu

Dla firm szkoleniowych: bardziej szczegółowy opis inżynierii wymagao w tych obszarach.

Jakie błędy mogą wystąpid w inżynierii wymagao? (K2)

Niejasne wymagania

Zmieniające się wymagania

Niestabilna podstawa produktu i projektu dla podwykonawców

Niejasne odpowiedzialności

Rozbieżnośd pomiędzy oczekiwaniami klienta i treścią projektu

Nieefektywne zarządzanie kontaktami z klientem

Definicja projektu z nieosiągalnymi kamieniami milowymi

Nieprecyzyjne oszacowanie kosztów

Nieprecyzyjne oszacowanie wpływu


Poziom podstawowy

18 Wersja 1.2PL


1 Grudzieo 2010

3.2. Zarządzanie ryzykiem

Wyjaśnij niezbędnośd zarządzania ryzykiem (K3)

Efektywne zarządzanie ryzykiem jako klucz do obniżenia ryzyka w projekcie.

Dla firm szkoleniowych: dostarcz szczegółowy opis rozwoju środków zaradczych

i technik zarządzania ryzykiem, (takich jak, na przykład, analiza przyczyn i skutków awarii

(ang. Failure Mode and Effect Analysis (FMEA)).


Poziom podstawowy

19 Wersja 1.2PL


1 Grudzieo 2010

4. Odpowiedzialności i role

Cele nauczania

Jakie są podstawowe role w inżynierii wymagao?

Kim jest interesariusz?

Jakie zadania stoją za inżynierią wymagao?

Jakie jest zadanie specjalisty inżynierii wymagao?

Co charakteryzuje specjalistę inżynierii wymagao?

4.1. Podstawowe role

Podstawowe role: (K2)

Klient

Kontraktor (= Dostawca)

Klient określa swoje potrzeby.

Dostawca dostarcza rozwiązanie.

Interesariusz

Interesariusz jest osobą (lub rolą), która jest zainteresowana projektem.

Interesariusz może byd zarówno osobą fizyczną, osobą prawną, jak i postacią abstrakcyjną.

Interesariusze często napotykają na konflikt interesów między sobą.

Dla firm szkoleniowych: opisz typowych interesariuszy (np. dyrektor zarządzający, kierownik

projektu, klient).


Poziom podstawowy

20 Wersja 1.2PL


1 Grudzieo 2010

Ważne: Identyfikacja wszystkich interesariuszy dla poprawnego rozważenia wszystkich

perspektyw.

4.2. Zadania w inżynierii wymagao

Zadania: (K2)

Analiza procesów biznesowych

Identyfikacja i analiza wymagao

Zapewnienie jakości wymagao i specyfikacji

Stworzenie specyfikacji wymagao

Analiza ryzyka

Specjalista inżynierii wymagao identyfikuje życzenia i cele.

Wiedza i charakterystyka specjalisty inżynierii wymagao: (K1)

Umiejętnośd moderowania

Pewnośd siebie

Umiejętnośd przekonywania

Umiejętności językowe

Umiejętnośd komunikowania się

Precyzja

Analityczny umysł

Zdolnośd do działania w sposób ustrukturyzowany

Kompetencje metodologiczne

Odpornośd na stres


Poziom podstawowy

21 Wersja 1.2PL


1 Grudzieo 2010

5. Identyfikacja wymagao

Cele nauczania

Co powinien zawierad kontrakt?

Co powinno byd uwzględniane przy ocenie wymagao?

Co charakteryzuje typową wizję projektową?

Jak można zidentyfikowad interesariuszy?

Jaki jest cel identyfikacji wymagao?

Jakie techniki pomagają identyfikowad wymagania?

Czym charakteryzują się wymagania funkcjonalne i niefunkcjonalne?

Czym różnią się wymagania funkcjonale i niefunkcjonalne?

Co powinno zostad zawarte w dokumentacji wymagao?

Czym charakteryzuje się dobre wymaganie?

Jak wygląda standardowa zawartośd dokumentu wymagao?

Jak zbudowane jest wymaganie?

5.1. Klient

Klient musi byd zawsze zaangażowany. Celem zaangażowania jest zrozumienie klienta i

jednoczesne stworzenie atmosfery do wzajemnego zrozumienia. Dostawca powinien zawsze

stawiad się w sytuacji klienta.

Kontrakt: (K2)

W umowie powinno byd formalnie określone i opisane to, czego chce klient.

Należy zapewnid, że interes klienta jest na pierwszym miejscu.


Poziom podstawowy

22 Wersja 1.2PL


1 Grudzieo 2010

Ważne jest, by zdefiniowad realistyczne terminy i ceny, oraz dokonad realnego

planowania projektu.

Kiedy wymagania są oceniane, należy wziąd pod uwagę różne punkty widzenia.

5.2. Wizja i cele projektu

Na początku odbywa się opracowanie wizji projektu. Jest to pierwsza faza inżynierii

wymagao.

Kluczowe jest posiadanie jasnej definicji wizji projektu.

Dla firm szkoleniowych: zaprezentowad typowe wizje projektu.

Ważne pytania dotyczące wizji projektu: (K2)

Co projekt zmieni?

Do czego projekt jest potrzebny?

Co się zdarzy kiedy projekt zostanie przerwany?

Kto zyska na projekcie?

Jakie koszty jesteśmy w stanie ponieśd?

Jakie ryzyko jesteśmy gotowi podjąd?

Dla firm szkoleniowych: zaprezentowad typowe elementy wpływające na wizje projektu

(klienci, strategia, etc.)

Dla każdego projektu, wizja musi zostad zdefiniowana na nowo

5.3. Identyfikacja interesariuszy

Wszyscy interesariusze po stronie klienta i dostawcy muszą zostad zidentyfikowani .

Interesariusze powinni byd podzieleni na grupy interesów.

Dla firm szkoleniowych: wyjaśnid identyfikację i ocenę interesariuszy.


Poziom podstawowy

23 Wersja 1.2PL


1 Grudzieo 2010

5.4. Techniki identyfikacji wymagao

Cel identyfikacji wymagao (K2)

Identyfikacja wszystkich wymaganych funkcji, charakterystyk, ograniczeo i oczekiwao

Zorientowanie wymagao w kierunku wizji projektu

Funkcje muszą byd jasno opisane

Funkcje, których klient nie chce powinny byd wykluczone

Techniki (K1)

Kwestionariusze

Wywiady

Samodzielna rejestracja

Reprezentant klienta po stronie dostawcy

Identyfikacja na podstawie istniejących dokumentów

Ponowne użycie specyfikacji z podobnych projektów

Burza mózgów

Obserwacja w terenie

Terminowanie (praktykowanie) (ang. apprenticing)

Warsztaty po każdym wymienionym procesie

Dla firm szkoleniowych: zaprezentowad techniki, włączając opis korzyści i wad.

Dla firm szkoleniowych: wyjaśnid opis metod odpytywania dla wywiadów.

5.5. Wymagania funkcjonalne i niefunkcjonalne

Wymagania funkcjonalne (K2)

Opis funkcji systemu

Wyzwalacze (uruchomienie) procesu

Wymagania niefunkcjonalne (K2)

Opisują atrybuty funkcji lub ich charakterystyki jakościowe

Trudne do opisania, dlatego często niejasno sformułowane


Poziom podstawowy

24 Wersja 1.2PL


1 Grudzieo 2010

Często trudne do śledzenia i testowania

Precyzyjny i jasny opis jest konieczny dla walidacji

Dla firm szkoleniowych: dostarczyd przykłady wymagao funkcjonalnych i niefunkcjonalnych.

Charakterystyki jakościowe zgodnie z ISO 9126: (K2)

Funkcjonalnośd, niezawodnośd, użytecznośd, efektywnośd, utrzymywalnośd, przenaszalnośd

Dla firm szkoleniowych uszczegółowid poszczególne charakterystyki jakościowe.

Dla firm szkoleniowych: opisad ograniczenia (np. specyfikacje techniczne).

5.6. Opis wymagao

Zawartośd tekstu wymagania:

Kto? Co? Jak? Kiedy? Z kim? Na co wpływa?

Ważne wskazówki do tworzenia dokumentacji wymagao: (K2)

Wymagania muszą byd jednoznaczne, precyzyjne i zrozumiałe

Należy unikad zbędnych informacji

Szablony jako pomoc do ograniczenia opisów

Standardowa zawartośd dokumentu wymagao: (K1)

Wprowadzenie

Klauzula tajności

Regulacje

Standardy

Interesariusze

Przeznaczenie produktu

Opis systemu

Wymagania funkcjonalne

Wymagania niefunkcjonalne


Poziom podstawowy

25 Wersja 1.2PL


1 Grudzieo 2010

Założenia

Zależności

Ryzyka

Wymagania bezpieczeostwa

Atrybuty jakości oprogramowania

Akceptacja

Konstruowanie wymagao (K2)

1. Określenie procesu

2. Klasyfikacja czynności systemu

3. Określenie zobowiązao prawnych

4. Poprawienie procesu

5. Ograniczenia logiczne i czasowe

Dla firm szkoleniowych: opis poszczególnych kroków w konstruowaniu wymagao.


Poziom podstawowy

26 Wersja 1.2PL


1 Grudzieo 2010

6. Specyfikacja wymagao

Cele nauczania

Czym jest specyfikacja wymagao?

Co charakteryzuje specyfikację wymagao?

Czym jest specyfikacja rozwiązania?

Co charakteryzuję specyfikację rozwiązania?

Jakie standardy są ważne dla specyfikacji wymagao i specyfikacji rozwiązao?

Jak wygląda typowa procedura w odniesieniu do specyfikowania wymagao?

Jakie istnieją poziomy formalizacji dla specyfikacji wymagao?

Jakie mogą byd konsekwencje błędów w wymaganiach?

Jak unikad błędów w wymaganiach?

6.1. Specyfikacja

W specyfikacji wymagania są opisane w ustrukturyzowany sposób i oddzielnie modelowane .

Specyfikacja służy do śledzenia i zarządzania wymaganiami.

Specyfikacja wymagao (K2)

Nazywana również specyfikacją wydajności.

Jej stworzenie powinno byd zadaniem klienta.

Specyfikacja rozwiązania (K2)

Zwana również specyfikacją funkcjonalną.


Poziom podstawowy

27 Wersja 1.2PL


1 Grudzieo 2010

Podstawa do dalszego rozwoju systemu.

Ważne standardy: (K1)

IEEE 1362 (specyfikacje wydajności systemu), IEEE 830 (specyfikacje wymagao systemu), IEEE

1233 (specyfikacje funkcjonalne systemu)

Dla firm szkoleniowych: dostarczyd bardziej szczegółowy opis specyfikacji wydajności oraz

specyfikacji funkcjonalnej.

6.2. Procedura

Specyfikacja jako czynnośd służąca formalizacji wyników analizy wymagao (K2)

Dla firm szkoleniowych: opisad kroki specyfikacji problemów i rozwiązao (określanie

przestrzeni rozwiązania, opisywanie kontaktów klienta, etc.)

Faza identyfikacji zostaje zakooczona, kiedy wszystkie niezbędne umowy zostały podpisane .

6.3. Formalizacja

Różne stopnie formalizacji

Nieformalna

Pół-formalna

Formalna

Dla firm szkoleniowych: dostarczyd opis i rozróżnienie pomiędzy stopniami formalizacji (K2)


Poziom podstawowy

28 Wersja 1.2PL


1 Grudzieo 2010

6.4. Jakość Wymagao

Błędy w wymaganiach jako przyczyna wysokich kosztów (K2)

Im później błąd zostanie znaleziony, tym większe są koszty jego naprawy.

Dlatego używamy ręcznej weryfikacji (czy właściwie produkujemy produkt?) i walidacji (czy

produkujemy właściwy produkt?).

Dla firm szkoleniowych: opisad miary ulepszania i zapewniania jakości.


Poziom podstawowy

29 Wersja 1.2PL


1 Grudzieo 2010

7. Analiza wymagao

Cele nauczania

Jaki jest cel analizy wymagao?

Jakie procedury stosowane są podczas analizy wymagao?

Jakie istnieją modele analizy wymagao?

Co charakteryzuje UML?

Co charakteryzuje SySML?

Dlaczego estymujemy koszty?

Jakie są ważne czynniki przy estymacji kosztów?

Jak wygląd procedura przyznawania priorytetów?

Co musi byd brane pod uwagę przy podejmowaniu decyzji dotyczących wymagao?

7.1. Wymagania i rozwiązania

Cel analizy wymagao: rozwiązanie dla implementacji wymagao (K2)

Procedura:

1. Analiza potrzeb

2. Opis rozwiązania

3. Estymacja kosztów i ustalenie priorytetów


Poziom podstawowy

30 Wersja 1.2PL


1 Grudzieo 2010

7.2. Metody i Techniki

Różne aspekty systemu są reprezentowane przez różne punkty widzenia.

Modele są opracowywane poprzez odpowiednie metody analizy.

Zróżnicowanie pomiędzy różnymi typami modeli (K2)

Modele wymagao

Modele rozwiązania

Dla firm szkoleniowych: dostarczyd szczegółowy opis tych dwóch typów i ich widoków.

Różne modele (K1)

Model kontekstowy

Dekompozycja funkcjonalna

Model przepływu danych

Model przejśd stanów

Sied Petriego

Model związków encji

Dla firm szkoleniowych: szczegółowy opis wymienionych modeli.

7.3. Analiza zorientowana obiektowo UML (Unified Modeling Language)

UML dostarcza diagramy dla różnych punktów widzenia systemu.

Diagramy przypadków użycia, diagramy klas, diagramy aktywności, diagramy stanów,

diagramy obiektów, diagramy komponentów, diagramy pakietów, itd.

Dla firm szkoleniowych: dostarczyd przykłady diagramów (co najmniej

diagramów przypadków użycia, klas, aktywności i stanów).

SysML (Systems Modeling Language) jako rozwinięcie UML.


Poziom podstawowy

31 Wersja 1.2PL


1 Grudzieo 2010

7.4. Estymacja Kosztów

Estymacja kosztów łączy inżynierię wymagao z zarządzaniem projektem.

Typy estymat (K2)

Koszty

Czas

Wymagania

Jakośd

Estymaty kosztów pomagają rozpoznawad koszty zmian.

Dla firm szkoleniowych: opisad czynniki determinujące koszty wytwarzania.

Procedury estymacji (K 1)

Wnioski przez analogię

Procedura algorytmiczna

Procedura punktów funkcyjnych

Konstruktywny model kosztowy

Metoda Delphi (delfijska)

Dla firm szkoleniowych: wyjaśnienie procedury estymacji.

Procedury estymacji zawsze bazują na danych historycznych i ograniczeniach środowiska.

7.5. Priorytetyzacja Procedura

1. Grupowanie wymagao

2. Analiza wymagao

3. Budowanie planu projektu

4. Testowanie przyrostowe


Poziom podstawowy

32 Wersja 1.2PL


1 Grudzieo 2010

7.6. Akceptacja wymagao

Umowy (K2)

Umowy formalne jako podstawa projektu

Lista wymagao musi byd wiążąca

Konieczny jest ciągły przegląd wymagao

Dla firm szkoleniowych: opis korzyści wynikających z wiążących alokacji.


Poziom podstawowy

33 Wersja 1.2PL


1 Grudzieo 2010

8. Śledzenie wymagao

Cele nauczania

Czym jest możliwośd śledzenia?

Dlaczego wymagania się zmieniają?

Jaki jest cel śledzenia?

Jakie są typy śledzenia?

Czym charakteryzuje się zarządzanie zmianą?

Jaki jest skład komitetu kontroli zmian?

Jakie istnieją metryki?

Co umożliwiają metryki?

8.1. Śledzenie wymagao w projekcie

Możliwośd śledzenia (K2)

Wymagania nie są stabilne i ciągle się rozwijają

Powody ciągłych zmian

Nowe spojrzenie

Nowe potrzeby klienta

Kontynuowanie prac

Nowe połączenia w ramach projektu

Możliwośd śledzenia jako rozwiązanie:

Umożliwia sprawdzenie, czy wszystkie istotne etapy procesu rozwoju zostały

przeprowadzone.


Poziom podstawowy

34 Wersja 1.2PL


1 Grudzieo 2010

Cele: analiza wpływu, analiza pokrycia, analiza użycia potencjału, dowód implementacji,

użycie wymagao, itd.

W celu zapewnienia dobrej możliwości śledzenia, ważne jest, by precyzyjnie nazywad

wymagania.

Typy możliwości śledzenia:

Śledzenie pionowe i poziome.

Dla firm szkoleniowych: opisad, czym jest śledzenie pionowe i poziome.

8.2. Zarządzanie zmianą

Zmiany w wymaganiach (zarządzanie zmianą) (K2)

Zmiany są sprawdzane, a decyzja o dalszym postępowaniu musi byd podjęta przez komitet

kontroli zmian.

Komitet podejmuje decyzję odnośnie żądao zmian.

Komitet kontroli zmian składa się z (K1)

Kierownika projektu

Członków zespołu programistów

Członków zespołu zapewnienia jakości

Menadżera biznesowego (jeśli konieczne)

Klienta (jeśli konieczne)

itd.

Dla firm szkoleniowych: przedstaw zadania komitetu kontroli zmian.

Dla zmiany wymagao konieczny jest ustrukturyzowany proces.

Ważna jest analiza znaczenia każdej zmiany. Pośpieszne rozwiązania są problematyczne.

Rozległe zmiany wymagao mogą byd na tyle poważne, że wymuszą zmiany kontraktów.

Dla firm szkoleniowych: opisad cyklu życia wymagania.


Poziom podstawowy

35 Wersja 1.2PL


1 Grudzieo 2010

Dla firm szkoleniowych: wyjaśnid wpływ zmian w wymaganiach.

Dla firm szkoleniowych: rozróżnid pomiędzy zarządzaniem błędami a zarządzaniem zmianą.

8.3. Metryki

Metryki umożliwiają wydanie mierzalnego oświadczenia odnośnie statusu i jakości projektu.

Liczby muszą zawsze byd porównane z danymi referencyjnymi .

Metryki dla wymagao: (K1)

Koszt projektu

Śledzenie projektu

Stabilnośd projektu

Ulepszanie procesu

Jakośd specyfikacji

Ilośd błędów

Typy błędów

Pomiar jakości wymagao: (K2)

Czy wymagania są poprawne?

Czy wymagania są czytelne?

Czym wyższa częstotliwośd zmian, tym wyższe ryzyko projektowe.


Poziom podstawowy

36 Wersja 1.2PL


1 Grudzieo 2010

9. Zapewnienie jakości

Cele nauczania

Jakie czynniki wpływają na inżynierię wymagao?

Jak można usprawnid zapewnienie jakości?

Czym jest kryterium akceptacji?

Jakie znamy metody zapewnienia jakości?

9.1. Czynniki sukcesu

Czynniki wpływające na sukces inżynierii wymagao: (K2)

Produkt, jaki jest wytwarzany

Środowisko, w jakim produkt zostaje wytwarzany

Przemysł

Presja czasu

Presja kosztów

Czynniki społeczne

Takie czynniki muszą byd wzięte pod uwagę w procesie zapewnienia jakości

Wyżej wymienione czynniki muszą byd wzięte pod uwagę, jeśli chodzi o zapewnienie jakości.

9.2. Zapewnienie jakości poprzez testowalność

Inżynieria wymagao jest obecna w całym cyklu życia produktu.

Inżynieria wymagao jest ściśle powiązana z testowaniem. Dobry przypadek testowy wymaga

dobrych wymagao, które mogą byd przetestowane (zaangażowanie testerów w

specyfikowaniu wymagao jest kluczowe) (K2)


Poziom podstawowy

37 Wersja 1.2PL


1 Grudzieo 2010

Kryteria akceptacji

Każde wymaganie ma przynajmniej jedno kryterium akceptacji

Stanowi podstawę do testów akceptacyjnych

Metody:

Pokrycie funkcjonalne

Podzbiory równoważności

Dla firm szkoleniowych: opisad metody.


Poziom podstawowy

38 Wersja 1.2PL


1 Grudzieo 2010

10. Narzędzia

Cele nauczania

Jak narzędzia wspierają inżynierię wymagao?

Jakie czynności związane z inżynieria wymagao mogą byd przeniesione do narzędzia?

Jakie istnieją wymagania na narzędzia do inżynierii wymagao?

Co musi byd brane pod uwagę w odniesieniu do narzędzi?

10.1. Zalety narzędzi

Narzędzia do przechowywania i administracji wymagao wspomagają inżynierię wymagao.

Mogą one automatyzowad powtarzalne czynności lub zapewnid łatwy wgląd w wymagania.

W ten sposób można utrzymywad trudne, statyczne dokumenty w spójnym i aktualnym

stanie. Wybór narzędzia musi nastąpid przed wytworzeniem produktu. W innym wypadku

może to spowodowad poważne problemy (K2)

Dla firm szkoleniowych: dostarczyd opis wymagao stawianych narzędziom w zakresie

inżynierii wymagao.

Dla firm szkoleniowych: dostarczyd opis czynności inżynierii wymagao, które mogą byd

wspierane przez wykorzystanie narzędzi.

10.2. Kategorie narzędzi

Narzędzia przetwarzające tekst, arkusze kalkulacyjne

o MS Excel, MS Word itd.

Narzędzia do modelowania

Narzędzia do zarządzania wymaganiami

Narzędzia do zarządzania defektami

Narzędzia Open Source


Poziom podstawowy

39 Wersja 1.2PL


1 Grudzieo 2010

Koszty narzędzi znacznie się różnią. Wybór narzędzia musi byd dokonany bardzo ostrożnie.

Pośpieszne decyzje mogą powodowad wysokie koszty. (K2)


Poziom podstawowy

40 Wersja 1.2PL


1 Grudzieo 2010

11. Literatura Beck, Kent: Extreme Programming. Munich 2003

Beck, Kent: Extreme Programming Explained: Embrace Change. Boston 2000

Beck, Kent: Test Driven Development. By Example. Amsterdam 2002

Beck, Kent: Refactoring: Improving the Design of Existing Code. Addison-Wesley Longman

1999

Boehm, Barry: Software Engineering Economics. Englewoods Cliffs, NJ 1981

Bundschuh, Manfred; Fabry, Axel: Aufwandschätzung von IT-Projekten. Bonn 2004

Cockburn, Alistair: Agile Software Development. Addison Wesley 2002

Cockburn, Alistair: Writing Effective Use Cases. Amsterdam 2000

DeMarco, Tom et al.: Adrenalin-Junkies und Formular-Zombies – Typisches Verhalten in

Projekten. Munich 2007

DeMarco, Tom: Controlling Software Projects: Management, Measurement and Estimates.

Prentice Hall 1986

DeMarco, Tom: The Deadline: A Novel About Project Management. New York 1997

Ebert, Christof: Systematisches Requirements Management. Anforderungen ermitteln,

spezifizieren, analysieren und verfolgen. Heidelberg 2005

Evans, Eric J: Domain-Driven Design: Tackling Complexity in the Heart of Software.

Amsterdam 2003

Graham, Dorothy et al: Foundations of Software Testing. London 2007

Gilb, Tom; Graham, Dorothy: Software Inspection. Reading, MA 1993

Hull, Elizabeth et. All: Requirements Engineering. Oxford 2005

IEEE Standard 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology

IEEE Standard 1233-1998 IEEE Guide for Developing System Requirements Specifications


Poziom podstawowy

41 Wersja 1.2PL


1 Grudzieo 2010

IEEE Standard 829-1998 IEEE Standard for Siftware Test Documentation

IEEE Standard 830-1998 IEEE Recommended Practice for Software Requirements

Specifications

IEEE Standard 1362-1998 IEEE Guide for Information Technology-System Definition –

Concept of Operations (ConOps) Document

IEEE Standard 1220-1998: IEEE Standard for Application and Management of Systems

Engineering Process

ISO 9000

ISO 9126

ISO 12207

ISO 15288

ISO 15504

Jacobsen, Ivar et al.: The Unified Software Development Process. Reading 1999

Lauesen, Soren: Software Requirements: Styles and Techniques. London 2002

Mangold, Pascal: IT-Projektmanagement kompakt. Munich 2004

McConnell, Steve: Aufwandschätzung für Softwareprojekte. Unterschleißheim 2006

Paulk, Mark, et al: The Capability Maturity Model: Guidelines for Improving the Software

Process. Reading, MA 1995

Pfleeger, Shari Lawrence: Software Engineering: Theory and Practice, 2nd edition.

Englewood Cliffs, NJ 2001

Pohl, Klaus: Requirements Engineering. Grundlagen, Prinzipien, Techniken. Heidelberg 2007

Project Management Institute: A Guide to the Project Management Body of Knowledge

(PMBOK ® Guide). PMI 2004

Robertson. Suzanne; Robertson, James: Mastering the Requirements Process, Harlow 1999


Poziom podstawowy

42 Wersja 1.2PL


1 Grudzieo 2010

Rupp, Chris: Requirements-Engineering und Management. Professionelle, Iterative

Anforderungsanalyse in der Praxis. Munich 2007

Sommerville, Ian: Requirements Engineering. West Sussex 2004

Sommerville, Ian: Software Engineering 8. Harlow 2007

Sommerville, Ian; Sawyer, Pete: Requirements Engineering: A Good Practice Guide.

Chichester 1997

Sommerville, Ian; Kotonya, Gerald: Requirements Engineering: Processes and Techniques.

Chichester 1998

Spillner, Andreas et all: Software Testing Foundations. Santa Barbara, CA 2007

Thayer, Richard H.; Dorfman, Merlin: Software Requirements Engineering, 2nd edition. Los

Alamitos, CA 1997

V-Modell® XT: http://www.vmodellxt.de/

Wiegers, Karl E.: Software Requirements. Redmond 2005

Wiegers, Karl E.: More About Software Requirements: Thorny Issues and Practical Advice.

Redmond, Washington 2006

Syllabus REQB® Certyfikowany specjalista inżynierii...

Documents

Transcript of Syllabus REQB® Certyfikowany specjalista inżynierii...