Zarządzanie wymaganiami

Zarządzanie wymaganiami – dziedzina zajmująca się działaniami mającymi na celu przełożenie potrzeb lub oczekiwań użytkowników w stosunku do konstruowanej, fizycznej realizacji produktu końcowego. Pojęcie zarządzania wymaganiami w szerokim kontekście odnosi się do metod specyfikowania użytecznych cech wszelkiego rodzaju produktów (np. umów handlowych, budowli, cech urządzeń itp.).

Pojęcie zarządzania wymaganiami w inżynierii oprogramowania stanowi proces zbierania i analizowania różnych wymagań. Wymagania te mogą pochodzić od różnych podmiotów, zainteresowanych powstaniem lub modyfikacją określonego produktu (mogą to być użytkownicy, klienci, zarząd firmy). Ze względu na kontekst danego wymagania, możemy określić je jako wymaganie użytkownika, biznesowe, funkcjonalne, techniczne czy procesu wytwarzania.

Wytwarzanym produktem może być zwykła aplikacja, system świadczący jakieś usługi lub nawet serwer aplikacji czy witryna internetowa.

Podczas zbierania wymagań dotyczących produktu należy odpowiednio rozdzielić je pomiędzy dostępne klasy. Dobrze zaprojektowane systemy gromadzą wymagania w każdej z tych pięciu grup, nie powodując zbyt jednoznacznego nastawienia na jedną z nich.

W zarządzaniu wymaganiami może być zastosowany osobny język do projektowania graficznego SysML, bazujący na standardach UML.

Etapy wytwarzania oprogramowania

Realizacja zadań związanych z zarządzaniem wymaganiami w dużej mierze zależy od etapu, w jakim jest realizacja projektu. Można wyróżnić pięć podstawowych faz jego powstawania, w których zarządzanie wymaganiami ma znaczenie.

Etap rozpoznawania (investigation)

Na tym etapie są gromadzone wymagania od przewidywanych docelowych użytkowników systemu (wymagania użytkownika), określa się problemy, jakie ma rozwikłać dany produkt (wymagania biznesowe) oraz pobiera się wymagania od zespołu wytwarzania (wymagania techniczne). To tutaj określa się cele produktu, narzędzia i ogólne zarysy, możliwości i ograniczenia realizacji. Na podstawie tych zebranych wymagań jesteśmy w stanie stworzyć zarys systemu, jaki chcemy stworzyć. Dzięki temu możemy przystąpić do ustalania wymagań funkcjonalnych.

Na tym wstępnym etapie należy się liczyć z tym, iż nie da się zdefiniować wszystkich możliwych wymagań. Zebrane wymagania z pewnością ulegną zmianom, będącym skutkiem podejmowanych działań wewnątrz projektu lub wpływów zewnętrznych.

Po wykonaniu analizy wymagań, powinien powstać dokument gromadzący wymagania (nazywany specyfikacją wymagań), który będzie zaakceptowany przez wszystkich członków zespołu projektowego (również klientów). Ów dokument ma stanowić element, który będzie zapobiegał nieprzewidzianym i dziwacznym zmianom. W miarę rozwoju projektu często pojawiają się nowe super-pomysły, które tworzą całą serię kolejnych wymagań. Stworzenie takiego dokumentu będzie pozwalało na utrzymanie projektu przy początkowych założeniach i realizowanie wcześniej zaplanowanej wizji. Nie zamyka on oczywiście przed dodaniem nowych wymagań, jednak ogranicza możliwość niekontrolowanego życia projektu.

Sposoby gromadzenia wymagań są różne. W najprostszym wykonaniu może to być zwykły dokument, do którego dopisujemy lub usuwamy wymaganie. W bardziej złożonych narzędziach stosuje się bazy danych, gromadzące wymagania i pozwalające na generowanie dokumentu wymagań. Równocześnie zapewniają możliwość śledzenia zmian czynionych na wymaganiach lub tworzenia dowiązań, określających zależności pomiędzy innymi wymaganiami lub przypadki użycia.

Analiza wykonalności (feasibility)

Na tym etapie następuje najczęściej oszacowanie kosztów zrealizowania zaplanowanych wymagań, ustalenie kosztów istnienia obecnego oprogramowania oraz kosztów ich wadliwego funkcjonowania, które ma poprawić nowy produkt. Równocześnie należy oszacować dostępny budżet na realizację produktu oraz zasoby ludzkie. Ważne jest podjęcie próby oszacowania zwrotu jaki uzyska się po wprowadzeniu produktu na rynek.

Należy zadać sobie pytanie, czy posiadamy odpowiednich ludzi do zrealizowania zadań, związanych z projektem, jakie są koszty ich przeszkolenia, jakie narzędzie musimy im zagwarantować, by stworzyć odpowiednie środowisko pracy. Najlepszym rozwiązaniem, jest zapewnienie zespołowi wykonawczemu jak najlepszego stanowiska, aby zaoszczędzić czas ich pracy – zarówno pod względem posiadanego sprzętu, jak i oprogramowania.

Kluczowym aspektem, jaki trzeba rozpatrzyć, jest zadanie sobie pytania, na jakim stanowisku będzie pracował projektowany system – czy będzie konieczne postawienie serwera, zorganizowania systemu hostingowego?

Ten etap również może generować nowe wymagania, dotyczące sprzętu lub oprogramowania jaki należy zakupić dla środowiska wytwórczego lub dla przyszłego systemu, jaki ma być stworzony. Mogą to być także wymagania co do ludzi, jacy mają uczestniczyć w realizacji projektu.

Dokumentem finalnym, jaki powinien zostać przedstawiony z tego etapu, powinien być budżet projektu oraz plan rozkładu kosztów w czasie trwania projektu. Dokument pozwala na podjęcie decyzji, czy projekt warto realizować, czy stać nas na realizację wszystkich z nakreślonych wymagań.

Projektowanie (design)

Kiedy stwierdzimy, że znane są nam koszty powstania projektu i przewidziane są zyski, jakie uzyskamy, można przystąpić do etapu projektowania. Na tym etapie, podstawowym zadaniem związanym z zarządzaniem wymaganiami jest utrzymywanie powstającego projektu w zgodności z granicami, jakie zostały narzucone w wymaganiach.

Należy jednak zachować pewną elastyczność. Podczas prac projektowych może się okazać, że inne rozwiązanie jest wydajniejsze, tańsze lub lepsze. Zawsze można spróbować delikatnie zreorganizować wymagania i dostosować je do potrzeb czy zewnętrznego rynku. Jednak w najczęstszych przypadkach taki krok podejmuje się rzadko i utworzona lista wymagań powinna pozostać w formie niezmienionej. Projektanci na podstawie tego dokumentu przygotowują projekt systemu.

Konstrukcja i testowanie (construction and test)

Podstawową czynnością, wykonywaną na tym etapie w ramach zarządzania wymaganiami jest upewnienie się, że prace nad projektem zamykają się w przewidzianym kosztorysie, a powstający produkt realizuje wytyczne, ujęte w wymaganiach. Ważnymi punktami tego etapu jest tworzenie prototypowych szkieletów i testów, które będą pozwalały na szacowanie zgodności z wymaganiami i postępów prac. Dla aplikacji klienckich można stworzyć wstępny graficzny interfejs użytkownika, które będzie podlegał testowaniu, a dla którego realizacja ciała będzie wypełniana z czasem. Pozwala to na usprawnienie powstawania samego projektu.

Wypuszczenie produktu (release)

Jest to etap, który tak naprawdę nie oznacza końca zarządzania wymaganiami. Podczas pracy nad projektem mogą się pojawić nowe, dodatkowe koncepcje, lub wizja postaci produktu może ulec zmianie. Po dobrnięciu do tego etapu wykonuje się całą pracę od nowa, aby uzyskać nowy, lepszy i sprawniejszy produkt.

Przykładowe narzędzia

• komercyjne:
  • Programming Research IRqa
  • IBM Requisite Pro
• niekomercyjne z otwartym kodem:
  • Useme (Java)
  • Open Source Requirements Management Tool (Java)
  • TestLink (PHP + MySQL/PgSQL, częściowe tłumaczenia na język polski)

Linki zewnętrzne

• Portal Zarządzania: Zarządzanie wymaganiami. biznet.gotdns.org. [zarchiwizowane z tego adresu (2007-09-12)].
• Forbes Requirements Management Software Directory. software.forbes.com. [zarchiwizowane z tego adresu (2010-01-21)].
• INCOSE Requirements Tools Survey