1.1. Czym są wymagania oprogramowania?

Wymagania oprogramowania stanowią uszczegółowienie wymagań użytkownika. Na tym poziomie piramidy wymagań, przypadki użycia zdefiniowane podczas formułowania wymagań użytkownika są opisywane w szczegółach, poprzez m.in. zdefiniowanie interakcji pomiędzy aktorami a systemem w postaci scenariuszy przypadków użycia. Powstają również tzw. scenopisy, które łączą opis działania przypadków użycia z wyglądem poszczególnych „scen”, czyli elementów wyświetlanych użytkownikowi. Podsumowując rolę wymagań oprogramowania, można powiedzieć, że dają one odpowiedź na trzy pytania:

• Jakie są szczegóły funkcjonowania systemu?
• Jakie dane będą przetwarzane przez system?
• Jakie inne szczegółowe cechy powinien mieć system?

Tego typu szczegóły są bardzo podatne na zmiany w miarę postępów prac nad systemem. Dlatego też, zazwyczaj formułuje się je bezpośrednio przed implementacją wybranego fragmentu funkcjonalności systemu. W cyklu iteracyjnym, dopiero po wybraniu zestawu przypadków użycia (lub historii użytkownika) do realizacji w danej iteracji, dokonuje się ich szczegółowego wyspecyfikowania.

1.2. Podstawowe składniki wymagań oprogramowania

Jednym z istotnych aspektów definiowania wymagań oprogramowania jest uzupełnienie przypadków użycia zdefiniowanych w wymaganiach oprogramowania kompletnymi scenariuszami. Scenariusze określają w sposób precyzyjny interakcję użytkownika z systemem prowadzącą do osiągniecia celu biznesowego określonego przez dany przypadek użycia. Scenariusze na poziomie wymagań oprogramowania powinny określać wszystkie zidentyfikowane alternatywne ścieżki wykonania przypadku użycia oraz obsługę sytuacji wyjątkowych (np. spowodowanych wystąpieniem błędu podczas wykonania przypadku). Przypadek użycia jest zbiorem scenariuszy, co ilustruje rysunek 1.1. Istotnym warunkiem jest tutaj, aby scenariusze te prowadziły do tego samego celu, niezależnie od tego, czy kończą się powodzeniem (osiągnięciem celu) czy porażką. Scenariusze przypadku użycia powinny definiować wszystkie alternatywne przebiegi obsługujące reakcje systemu na różne zdarzenia, w tym sytuacje wyjątkowe.

Rysunek 1.1: Przypadek użycia ze zbiorem jego scenariuszy

Kolejnym elementem, który składa się na precyzyjną specyfikację wymagań oprogramowania jest szczegółowy model danych. Pojęcia dziedziny problemu zamieniamy w precyzyjnie wyspecyfikowane klasy w modelu danych, co ilustruje rysunek 1.2.

Rysunek 1.2: Klasa w modelu danych a pojęcie w słowniku dziedziny

W trakcie specyfikacji wymagań oprogramowania powstają także nowe pojęcia – klasy uzupełniające model danych. Podczas uszczegóławiania wymagań (np. pisania szczegółowych scenariuszy) odkrywane są pojęcia reprezentujące np. elementy interfejsu użytkownika które służą do komunikacji użytkownika z systemem lub pojęcia dotyczące konfiguracji systemu. Rysunek 1.3 przedstawia model danych w postaci diagramu klas wraz z klasami reprezentującymi elementy interfejsu użytkownika oraz parametry konfiguracyjne systemu. Są one oznaczone odpowiednio stereotypami <<UI window>> i <<configuration>>.

Rysunek 1.3: Klasy uzupełniające model danych

Scenariusze wraz ze zidentyfikowanymi elementami interfejsu użytkownika są podstawą do stworzenia projektu interfejsu użytkownika oraz scenopisów. Dla kolejnych kroków scenariuszy należy uzgodnić z klientem i zaprojektować wygląd (w tym – treść) poszczególnych elementów ekranowych. Tak zaprojektowane elementy ekranowe układają się w odpowiednią sieć definiującą możliwość nawigacji poprzez interfejs użytkownika oraz realizację celów zadanych przypadkami użycia.

1.3. Wymagania oprogramowania w cyklu życia

W cyklu iteracyjnym produkty wymagań oprogramowania powstają w każdej iteracji. Jednocześnie, na podstawie tych produktów powstają inne, istotne produkty procesu wytwórczego. Zależność głównych produktów pracy dla wymagań oprogramowania od innych produktów pracy na ścieżce do kodu przedstawia rysunek 1.4. Wymagania oprogramowania uszczegóławiają wymagania zamawiającego, a ich celem jest “przetłumaczenie” zakresu systemu w modele architektoniczne (projektowe) systemu. Wymagania funkcjonalne zapisane w postaci przypadków użycia lub historii użytkownika są opisywane w szczegółach za pomocą scenariuszy i scenopisów. To stanowi podstawę dla stworzenia odpowiednich modeli dynamiki systemu. Z kolei słownik dziedziny jest zamieniany w szczegółowy model danych. To jest podstawą do zdefiniowania statycznych modeli architektury. Uzupełnienie tego opisu o rozbudowane wymagania jakościowe i ograniczenia techniczne pozwala na podjęcie decyzji architektonicznych i technologicznych prowadzących do zrealizowania systemu w pełni zgodnego z realnymi potrzebami zamawiającego.

Rysunek 1.4: Źródła i cel dla wymagań oprogramowania

2.1. Czym są scenariusze przypadków użycia?

Na poziomie wymagań oprogramowania konieczne jest bardzo szczegółowe zdefiniowanie sposobu działania systemu, gdyż na tej podstawie zespół deweloperski musi zaprojektować i zaimplementować system. Konieczne jest zatem sformułowanie szczegółowych scenariuszy działania systemu, które pokazują perspektywę użytkowników (ogólnie: aktorów) oraz ich interakcji (dialogu) z systemem.

Scenariusze określają w sposób precyzyjny interakcję użytkownika z systemem prowadzącą do osiągnięcia określonego celu biznesowego. Scenariusze na poziomie wymagań oprogramowania powinny określać wszystkie zidentyfikowane alternatywne ścieżki wykonania przypadku użycia oraz obsługę sytuacji wyjątkowych. Scenariusz przypadku użycia powinien spełniać trzy cechy:

• opisywać sekwencję interakcji między aktorem i systemem,
• zaczynać się od interakcji aktora (w większości przypadków)
• kończyć się, kiedy zostanie osiągnięty cel przypadku użycia, lub kiedy na drodze do tego celu nastąpiła porażka.

Przypadek użycia jest zbiorem scenariuszy prowadzących do tego samego celu, w tym tych zakończonych porażką. Scenariusze przypadku użycia powinny definiować wszystkie alternatywne przebiegi obsługujące sytuacje wyjątkowe, z wyjątkiem tych najbardziej oczywistych.

Pierwsze zdanie scenariusza jest w większości przypadków akcją inicjującą sekwencję współpracy pomiędzy użytkownikiem a systemem. Sekwencja taka jest zawsze inicjowana przez aktora dla głównych przypadków użycia. Dla przypadków użycia połączonych relacjami z innymi przypadkami użycia możliwa jest sytuacja, kiedy pierwszą akcją jest akcja wykonywana przez system.

Przykłady scenariuszy przypadku użycia spełniające powyższe zasady widzimy na rysunku 2.1. Zdania scenariuszy w tym przykładzie pisane są w prostej kontrolowanej gramatyce, która z jednej strony jest wystarczająca do kompletnego opisania interakcji aktor-system, a z drugiej na tyle prosta, aby scenariusze były przejrzyste i jednoznaczne.

Rysunek 2.1: Przykładowe scenariusze przypadku użycia

2.2. Notacja dla scenariuszy

Podstawowym typem zdania scenariusza w gramatyce kontrolowanej jest zdanie typu POD(D) (Podmiot, Orzeczenie, Dopełnienie bliższe, opcjonalne Dopełnienie dalsze).  Przykłady takich zdań widzimy na rysunku 2.2. Zdanie POD(D) składa się z podmiotu określającego wykonawcę akcji, orzeczenia określającego wykonaną akcję oraz dopełnień określających pojęcia, których ta akcja dotyczy

Rysunek 2.2: Gramatyka dla zdań POD(D)

Zwróćmy uwagę na to, że podmiotem zdań POD(D) jest zawsze system bądź aktor (z reguły aktor główny, lecz może to być również aktor poboczny biorący udział w interakcji). Biorąc to pod uwagę, zdania typu POD(D) możemy podzielić na trzy kategorie ze względu na nadawcę i odbiorcę komunikatu:

• zdania aktor-system; są to komunikaty od aktora do systemu (z reguły wprowadzenie danych bądź naciśnięcie przycisku),
• zdania system-aktor; są to komunikaty od systemu do aktora, np. wyświetlenie formularza bądź okienka komunikatu,
• zdania system-system; opisują wewnętrzne operacje systemu jak np. walidację danych wprowadzonych przez użytkownika lub wykonanie przetwarzania danych.

Oprócz zdań w gramatyce kontrolowanej, opisujących sekwencje wymiany komunikatów pomiędzy systemem a użytkownikiem, w scenariuszu mogą występować również zdania sterujące.

Zdania sterujące warunkowe pozwalają na kontrolowanie przebiegu scenariuszy przypadków użycia. Użycie zdania warunkowego pozwala na rozgałęzienie sterowania w zależności od spełnienia bądź niespełnienia danego warunku. Warto zwrócić uwagę na to, że wszystkie zdania występujące przed zdaniem warunkowym są identyczne dla scenariusza pierwotnego  i alternatywnego. Aby jednak nie dokonywać niepotrzebnych powtórzeń zdań, w scenariuszu alternatywnym można się odwołać do zdań w scenariuszu pierwotnym.

Zdania powrotu pozwalają na ponowne połączenie rozgałęzionych scenariuszy bądź zdefiniowanie powtarzanych interakcji (pętli). Definiując powrót trzeba określić scenariusz i numer zdania, które nastąpi po wykonaniu wszystkich zdań danego scenariusza. Jeśli na końcu scenariusza nie ma zdania powrotu, to sterowanie po ostatnim zdaniu wraca do wywołującego przypadku użycia lub następuje powrót do ekranu głównego.

Zdania warunków rozpoczęcia i zakończenia określają dopuszczalny stan system przed i po zakończeniu wykonania scenariuszy. Odpowiedni przykład takich zdań ilustruje rysunek 2.3. Widzimy tutaj zdanie oznaczone frazą „Pre”, które stanowi warunek rozpoczęcia. Takie zdanie jest jedno dla całego przypadku użycia i zawiera wyrażenie, pod rygorem którego możliwe jest jego wykonanie.

Rysunek 2.3: Scenariusze ze zdaniami warunków rozpoczęcia i zakończenia

O ile warunek rozpoczęcia może być najwyżej jeden, to warunków zakończenia może być wiele. Warunki zakończenia możemy umieścić na końcach scenariuszy, które nie posiadają zdań powrotu (patrz wyżej). Każdy warunek zakończenia stanowi określenie stanu systemu, który jest wymagany po zakończeniu działania przypadku użycia zgodnie z danym scenariuszem. W naszym przykładzie mamy tylko dwa warunki zakończenia (oznaczone frazą „Post”). Ich znaczenie jest dosyć oczywiste – określają możliwe stany bazy modeli w przypadku zakończonego sukcesem usunięcia modelu oraz, gdy operacja zostanie anulowana.

Zdania wywołania (ang. invoke) określają krok scenariusza, w którym uruchamiany jest inny przypadek użycia. Mogą one mieć charakter zarówno warunkowy, jak i bezwarunkowy. Zdania tego typu możemy na przykład oznaczyć stereotypem «invoke», opcjonalnym warunkiem (w nawiasach kwadratowych) i nazwą przypadku użycia. Po wykonaniu wywołanego przypadku użycia sterowanie powraca do bieżącego przypadku i wykonanie przypadku jest kontynuowane od miejsca wywołania. Przykład scenariusza przypadku użycia zawierającego takie zdania został przedstawiony na rysunku 2.4.

Rysunek 2.4: Przykładowy scenariusz przypadku użycia ze zdaniami wywołań

2.3. Graficzna reprezentacja scenariuszy

Alternatywnym sposobem przedstawiania scenariuszy przypadków użycia jest prezentacja graficzna za pomocą diagramów czynności. Pozwala to na przedstawienie wielu scenariuszy na jednym diagramie, co w wielu przypadkach pomaga lepiej zrozumieć logikę działania danej aplikacji. Przykład takiej reprezentacji logiki przypadku użycia został przedstawiony na rysunku 2.5. Wykorzystana została standardowa notacja diagramów czynności języka UML.

Rysunek 2.5: Przykład reprezentacji scenariusza przypadku użycia na diagramie czynności

Opisy scenariuszy i dokładne modele (słowniki) dziedziny nie dostarczają kompletu informacji dla zaprojektowania i zaimplementowania systemu. Wiemy jaka jest logika aplikacji (scenariusze) oraz jakie dane podlegają przetwarzaniu i wizualizacji (model dziedziny), ale nie wiemy, w jaki sposób te dane będą konkretnie wizualizowane. Dlatego też, najczęściej konieczne jest zdefiniowanie wyglądu elementów interfejsu użytkownika. Definicja ta może być wykonana na rożnym poziomie szczegółowości. W najprostszym przypadku może to być tzw. szkielet interfejsu użytkownika (ang. wireframe), który polega na naszkicowaniu prostymi kreskami układu elementów ekranowych (okienka z zawartymi w nich polami, przyciskami itp.). Jeśli potrzebna jest bardziej dokładna definicja, wykonujemy tzw. makietę interfejsu użytkownika (ang. mockup). Najbardziej dokładny jest prototyp interfejsu użytkownika (ang. UI prototype), który często wykonywany jest w docelowym narzędziu, w którym będzie implementowany cały system.

Tworzenie prototypu ma na celu łatwiejsze zrozumienie zasad realizacji funkcjonalności oraz przedstawienie propozycji sposobu interakcji pomiędzy użytkownikami i systemem. Prototyp opiera się na modelu statycznym wymagań (słownik dziedziny, model interfejsu użytkownika) i służy do zobrazowania modelu dynamicznego (przypadki użycia, scenariusze) z uwzględnieniem cech systemu oprogramowania (wymagania jakościowe). Prototypy pozwalają zilustrować ciągi stanów interfejsu użytkownika, które w dalszej części tego rozdziału będą nazywane scenami. Powiązanie scen z krokami scenariuszy przypadków użycia daje w wyniku scenopisy. Scenopis przedstawia ważne elementy systemu charakterystyczne dla kroków scenariusza przypadku użycia – swego rodzaju „komiks”.

3.1 Projektowanie graficznego interfejsu użytkownika

Graficzny interfejs użytkownika jest sposobem prezentacji informacji przez komputer oraz interakcji z użytkownikiem. Interfejs graficzny został po raz pierwszy opracowany przez firmę Xerox w latach 70. XX wieku. Podczas projektowania serii komputerów Alto, zespół kierowany przez Merzougi Wilbertsa zaproponował i zrealizował nowy paradygmat interakcji z użytkownikiem. Paradygmat ten nazwano  skrótem WIMP (windows, icons, menus, pointers). Wszyscy wielcy producenci komputerów, zainspirowani osiągnięciami firmy Xerox, rozpoczęli prace nad stworzeniem własnych rozwiązań interfejsów graficznych użytkownika. Dzięki tym działaniom GUI stało się dostępne dla wszystkich korzystających z komputerów.

W przypadku interakcyjnych systemów oprogramowania dla zastosowań biznesowych i domowych graficzne interfejsy użytkownika są obecnie normą. Głównymi zaletami tych interfejsów są:

• Łatwość nauki obsługi i łatwość użytkowania. Użytkownicy bez doświadczeń z komputerami mogą nauczyć się używania interfejsu w ciągu krótkiego szkolenia.
• Nawigacja między oknami. Użytkownik ma kilka ekranów (okien) do interakcji z systemem. Dzięki temu może przejść od jednego zadania do innego bez utraty oglądu informacji przygotowanej w trakcie pierwszego zadania.
• Szybkość interakcji. Pełny ekran daje dostęp do wszystkich informacji na nim zawartych.

Obecnie miliony ludzi posługują się przeglądarkami WWW, które przetwarzają język definicji stron (HTML) w postaci tekstowych znaczników (tagów) na graficzny interfejs użytkownika. Na stronie WWW można umieścić zarówno przyciski, pola, formularze oraz tabele, jak i obiekty multimedialne dające dostęp do dźwięków, nagrań, filmów i ekranów rzeczywistości wirtualnej. Ze względu na powszechną dostępność przeglądarek WWW oraz siłę rozwiązań webowych i związane z nimi możliwości przetwarzania, coraz więcej interfejsów użytkownika ma postać interfejsów WWW. Dzięki realizacji idei hiperłączy (linków), graficzny interfejs użytkownika uzyskał możliwość automatycznej nawigacji między różnymi oknami systemu oprogramowania. Powszechne na stronach WWW odnośniki znajdują także zastosowanie w systemach desktopowych, umożliwiając użytkownikowi swobodne poruszanie po zasobach systemu.

Aby poddać projekt graficznego interfejsu ocenie, należy stworzyć jego wizualizację. Tworzenie projektów graficznych interfejsów na papierze jest bardzo niewygodne. Dlatego też współcześnie w powszechnym użyciu są różnego rodzaju narzędzia do projektowania interfejsu użytkownika. Z uwagi na popularność interfejsów WWW, wiele narzędzi tego typu stanowi aplikacje WWW. Przykład takiej aplikacji (Figma) widzimy na rysunku 3.1. Pozwala ona na projektowanie szczegółowego wyglądu interfejsu użytkownika na poziomie makiety. Możliwe jest również symulowanie działania systemu poprzez możliwość nawigacji między projektowanymi ekranami. Ułatwia to znacznie komunikację z użytkownikiem oraz z zespołem implementującym system.

Rysunek 3.1: Przykład systemu do projektowania interfejsów WWW - Figma

W przypadku konieczności prototypowania bardziej zaawansowanych interfejsów, wykorzystuje się specjalne zestawy narzędziowe, w skrócie zwane UIDS (ang. user-interface developement system). Narzędzia te często wyposażone są w biblioteki gotowych składników i obiektów, z których można budować okna, systemu menu, mechanizmy interakcji z urządzeniami, komunikaty o błędach, polecenia i wiele innych elementów interaktywnego środowiska. Generatory interfejsów są systemami graficznego projektowania ekranów, w ramach których komponenty interfejsu wybierane są z przybornika i umieszczane w interfejsie.

Wsparcie projektowania graficznego interfejsu użytkownika może być realizowane w różnych typach narzędzi wspomagających proces wytwórczy oprogramowania. Mogą to być odpowiednie moduły dostępne w ramach zintegrowanych środowisk programistycznych, takich jak NetBeans czy Microsoft Visual Studio. Mamy również możliwość skorzystania z szerokiego wyboru narzędzi desktop, dedykowanych do projektowania interfejsów użytkownika. Proste szkielety interfejsu użytkownika pozwalają również projektować narzędzia do modelowania takie jak np. Enterprise Architect czy Visual Paradigm.

3.2 Tworzenie scenopisów i prototypów

Warto zauważyć, że wybrany stan interfejsu użytkownika stanowi swego rodzaju scenę. Poszczególne kroki scenariuszy przypadków użycia mogą powodować przejście do kolejnej sceny, czyli np. wyświetlenie kolejnego okienka. Takie sekwencje scen możemy nazwać scenopisami (ang. storyboard). Wiele narzędzi do projektowania interfejsu użytkownika pozwala na rysowanie scenopisów, a nawet na animację ich wykonania. Przykład scenopisu dla przypadku użycia przedstawia rysunek 3.2. Numery na diagramie odpowiadają numerom kroków w scenariuszach tego przypadku użycia.

Rysunek 3.2: Przykładowy scenopis

Aby zachować spójność, scenopis powinien być oznaczony nazwą przypadku użycia z opcjonalnie wyróżnionymi krokami scenariuszy. Zasadniczą część scenopisu stanowią „zdjęcia ekranu”, czyli jego sceny, oraz przejścia między nimi. Scena przedstawia stan systemu w kroku scenariusza, który definiuje ważne z punktu widzenia interfejsu użytkownika elementy (tutaj: ekran początkowy i kroki 2, 6 i 5a). Dla interfejsu graficznego są to okna, dla tekstowego interfejsu – stan konsoli, dla interfejsu dźwiękowego – opis dźwięku. Przejście między scenami odpowiada krokowi scenariusza, który opisuje operacje wykonane przez aktora i powodujące zmianę sceny (tutaj: kroki 1, 3 i 6a). Przejście zwykle wyzwalane jest przez użycie pewnego elementu sceny (np. naciśnięcie przycisku „Dodaj”) i oznaczone strzałką, prowadzącą z wybranego elementu jednej sceny do kolejnej sceny.

Aby wykorzystać wszystkie możliwości scenopisu, można wykonać połączenie scenariusza z reprezentacją graficzną. Taka forma może okazać się bardziej zrozumiała zarówno dla twórców oprogramowania, jak i dla przyszłych użytkowników, którzy niekoniecznie posiadają wiedzę techniczną. Rysunek 3.3 przedstawia przykładową notację scenopisu w takiej formie. Scenopis zawiera nazwę przypadku użycia z opcjonalnie wyróżnionym scenariuszem. Dzięki temu łatwo zidentyfikować dany scenopis. Sceny, podobnie jak poprzednio, przedstawiają stan systemu w kroku scenariusza, który definiuje ważne z punktu widzenia interfejsu użytkownika elementy (dla przedstawionego przypadku, kroki 1, 2 i 4).

Rysunek 3.3: Notacja scenopisu powiązanego ze scenariuszem

Taka ilustracja scenariuszy przypadków użycia daje pełny obraz przejścia przez wszystkie kroki scenariusza przypadku użycia. Dla każdego przypadku użycia może być zdefiniowanych tyle scenopisów, ile jest scenariuszy. Często jednak tworzy się jeden scenopis dla scenariusza głównego. Dla scenariuszy alternatywnych można rozwinąć główny scenopis o alternatywne ścieżki – podobnie jak w przypadku diagramów czynności, gdzie warunki przejścia do alternatywnego scenariusza oznaczane są na rozgałęzionych strzałkach. Różnica polega na przedstawieniu w scenopisie niektórych akcji jako strzałki (przejścia między scenami). Na diagramie czynności wszystkie akcje przedstawiane są jako elipsy.

Z punktu widzenia całego procesu inżynierii oprogramowania, tworzenie scenopisów jest podstawą dla procesu prototypowania. Prototyp jest początkową wersją systemu oprogramowania, która służy do prezentacji założeń i wypróbowania wariantów projektu. Ogólnie można powiedzieć, że prototyp służy do coraz lepszego poznawania problemu i jego możliwych rozwiązań. Szybkie stworzenie prototypu umożliwia panowanie nad kosztami i umożliwia eksperymentowanie wspólnie z przyszłymi użytkownikami już we wczesnych fazach procesu wytwarzania oprogramowania. Istnieją dwa rodzaje prototypowania: zamknięte (z porzuceniem) i otwarte (ewolucyjne).

Prototyp zamknięty służy tylko do ogólnego przedstawienia wymagań stawianych systemowi oprogramowania – jest prototypem jednokrotnego użycia. Po jego wykorzystaniu wyrzuca się go, a ostateczną wersję oprogramowania tworzy się od podstaw innymi metodami. Dzięki takiemu podejściu można w łatwy sposób, po ocenie i potrzebnych modyfikacjach, udoskonalić i zatwierdzić wymagania oprogramowania. Ocena prototypu inspiruje opracowywanie szczegółowej specyfikacji wymagań.

Prototyp otwarty pomaga nie tylko w fazie analizowania, ale także w fazie projektowania i jest podstawą implementacji ostatecznej postaci oprogramowania. Dzięki takiemu podejściu prototyp jest wielokrotnie używany poprzez przedstawianie użytkownikowi kolejnych niekompletnych wersji systemu. Realizacja najlepiej rozpoznanych i najważniejszych wymagań, a następnie ich ocenianie, modyfikowanie i uzupełnianie o nowe dobrze rozpoznane funkcjonalności sprawia, że wymagania użytkowników stają się jasne i w pełni odzwierciedlone w tworzonym oprogramowaniu.

W podejmowaniu decyzji, jaki typ prototypu stworzyć, należy brać pod uwagę kilka istotnych kwestii związanych z jakością specyfikacji wymagań:

• W przypadku kiedy wymagania są znane i stabilne, lepiej stworzyć prototyp wielokrotnego użycia. Pozwoli to na wczesne rozpoczęcie prac związanych z wytworzeniem ostatecznej wersji oprogramowania.
• Kiedy wymagania są niejasne, lub kiedy występują w nich sprzeczności, prototyp jednokrotnego użycia będzie bezpieczniejszą alternatywą. Ostateczna wersja oprogramowania nie będzie obarczona błędami spowodowanymi złą specyfikacją wymagań.

Inne ważne rozróżnienie między tymi podejściami leży w zarządzaniu jakością systemów. Czas życia prototypów porzucanych jest z definicji krótki. W czasie jego budowania musi istnieć możliwość wprowadzenia bardzo szybkich zmian, nie jest natomiast wymagana zdatność do długoterminowej pielęgnacji. Mała efektywność i niezawodność są akceptowane w wypadku prototypu porzucanego, jeśli spełnia on swą podstawową funkcję pomocy w rozpoznawaniu i prezentacji wymagań. Prototypy, które ewoluują w kierunku gotowych systemów, powinny być budowane zgodnie z takimi samymi standardami firmowymi jak inne oprogramowanie. Powinny mieć prężną architekturę, która umożliwi ich wieloletnią pielęgnację.