3.1. Sposób opisu wymagań jakościowych

Wymagania jakościowe można klasyfikować w różny sposób. Każda klasyfikacja dzieli takie wymagania na różne typy. Przykładowo, klient może wymagać odpowiednio krótkiego czasu odpowiedzi systemu, odpowiedniego poziomu dokładności obliczeń czy też łatwości wykonywania określonych czynności. Z uwagi na wielość klasyfikacji i typów wymagań jakościowych nie istnieje jednolity, sformalizowany sposób ich zapisu. Najczęściej wymagania tego typu tworzone są jako fragmenty tekstu wyrażone w języku naturalnym. Nazwy wymagań jakościowych najczęściej formułuje się w postaci prostych zdań zawierających orzeczenia modalne oparte o czasowniki takie jak musieć, być, zawierać. Oto kilka przykładowych zdań tego typu, zapisanych w formie „System będzie/może/musi/powinien …”:

• System będzie przechowywał dane osobowe w formie zaszyfrowanej
• System musi pokazywać wartości wagowe z dokładnością do 1mg
• System powinien wyświetlać mapę terenu przeciętnie w 2 sekundy

Struktura opisu wymagania jakościowego na poziomie wymagań użytkownika może być podobna do opisu wymagania funkcjonalnego. Istotną różnicą jest konieczność zdefiniowania zobiektywizowanej metryki wymagania. Metryka powinna określać sposób walidacji spełnienia wymagania oraz definiować możliwie obiektywne kryteria akceptacji. O metrykach wymagań jakościowych piszemy bardziej szczegółowo w dalszej części niniejszego rozdziału. Ogólnie, możemy wyróżnić następujące elementy kompletnego opisu wymagania jakościowego: nazwa wymagania, standardowe atrybuty wymagania, rodzaj wymagania, opis wymagania, metryka wymagania.

Na 3.1 pokazujemy kilka przykładowych fiszek wymagań jakościowych. Jak widzimy, metryki wymagań są przedstawione w sposób zobiektywizowany, ale bez wchodzenia zbytnio w szczegóły procedury testowania, przy czym zależą w bardzo istotny sposób od rodzaju wymagania. Dla przykładu, wymaganie JU012 na rysunku 3.1 jest rodzaju „użyteczność-operacyjność” i metryka dotyczy pomiaru czasy wykonania scenariusza przypadku użycia. Z kolei, wymaganie JK023 jest rodzaju „kompatybilność-interoperacyjność” i metryka jest już innego rodzaju. Dotyczy ona prawidłowości przesyłania danych z systemem zewnętrznym.

ID: JU012	Nazwa: System powinien umożliwiać szybkie dodawanie samochodów
Wersja: 1.0	Waga klienta: ważne		Waga wykonawcy: średnie
STATUS	Trudność: 2	Wydanie: 0.21	Odpowiedzialny: Magda
Rodzaj: użyteczność – operacyjność
Opis: Średni czas dodania do systemu nowego samochodu nie powinien przekroczyć 2 minut, a maksymalnie może być dwa razy wyższy. Dotyczy przypadku użycia PU076.
Sposób pomiaru: Mierzymy czas, jaki zajmie magazynierowi dodanie nowego samochodu, czyli przejście przez główny scenariusz PU076. Pomiaru dokonujemy na próbie 10 osób po 30 minutach przeszkolenia. Każda osoba dodaje po 10 samochodów.
Możliwy wynik pomiaru: Czas mierzymy z dokładnością do 5 sekund w zakresie od 5 sekund do 10 minut (powyżej 10 minut uznaje się, że magazynier nie był w stanie dodać samochodu).
Oczekiwane wartości: Średni czas dla całej grupy wynosi mniej niż 2 minuty. Najgorszy czas wynosi poniżej 4 minut.

 

ID: JE021	Nazwa: System musi szybko wyświetlać ekran podsumowania czynności magazynowych
Wersja: 1.1	Waga klienta: kluczowe		Waga wykonawcy: średnie
STATUS	Trudność: 7	Wydanie: 0.21	Odpowiedzialny: Stefan
Rodzaj: efektywność wydajnościowa – czas
Opis: Czas, w którym system wyświetla ekran podsumowania czynności magazynowych musi wynosić średnio poniżej 2 sek. Magazynier nie powinien czekać dłużej niż 5 sekund przy najgorszym obciążeniu systemu. Dotyczy przypadku użycia PU081, krok 5.
Sposób pomiaru: Mierzymy czas od momentu wybrania opcji wyświetlania ekranu podsumowania (krok 4) do momentu pełnego wyświetlenia ekranu (krok 5). Pomiaru dokonujemy przy różnych poziomach obciążenia systemu zgodnie z zasadą OB011. Wyniki mierzymy dla 100 prób na każdy poziom obciążenia.
Możliwy wynik pomiaru: Czas mierzymy z dokładnością do 0,1 sekund w zakresie od 0,1 sekund do 1 minuty (powyżej 1 minuty uznaje się, że system nie wyświetlił prawidłowo ekranu).
Oczekiwane wartości: Średni czas dla wszystkich poziomów obciążenia wynosi mniej niż 2 sekundy. Najgorszy czas dla poziomu obciążenia 5 wynosi mniej niż 5 sekund.

 

ID: JK023	Nazwa: System musi umożliwiać współpracę z systemem CEPiK
Wersja: 1.0	Waga klienta: kluczowe		Waga wykonawcy: trudne
STATUS	Trudność: 21	Wydanie: 0.21	Odpowiedzialny: Stefan
Rodzaj: kompatybilność – interoperacyjność
Opis: System będzie umożliwiał wymianę danych o sprowadzanych i sprzedawanych samochodach z systemem CEPiK. Wymiana odbywać się będzie poprzez API dostarczane przez system CEPiK. Dotyczy wszystkich przypadków użycia w relacji z aktorem System CEPiK.
Sposób pomiaru: W trakcie testów akceptacyjnych (TA056 do TA071) sprawdzamy działanie systemu pod kątem współpracy z API systemu CEPiK. Sprawdzamy prawidłowość przesyłu danych o pojazdach oraz rejestracjach pojazdów. Przesył danych sprawdzamy dla różnych prędkości łącza oraz dla różnych poziomów obciążenia.
Możliwy wynik pomiaru: Liczba prawidłowo przesłanych rekordów w stosunku do wszystkich prób, w rozbiciu na prędkości łącza oraz poziomy obciążenia (0-100%).
Oczekiwane wartości: Dla prędkości łącza powyżej 1Mb/s oraz poziomu obciążenia poniżej 3, poziom przesyłu wynosi 100%. Dla niższych prędkości oraz od 3 poziomu w górę, poziom przesyłu wynosi co najmniej 98%. W przypadku przesyłów nieprawidłowych, błąd jest zarejestrowany we wszystkich przypadkach.

Rysunek 3.1: Przykładowe fiszki wymagań jakościowych

3.2. Rodzaje wymagań jakościowych

Tak jak wspomnieliśmy w pierwszych rozdziałach podręcznika, bardzo istotną cechą dobrej jakościowo specyfikacji wymagań jest jej kompletność. W przypadku wymagań jakościowych konieczne jest uwzględnienie szerokiego zakresu różnych rodzajów wymagań. Dwa podstawowe ujęcia, dotyczą kwestii wykonywania programu oraz kwestii ewolucji systemu. Przy pierwszym podejściu wymienia się najczęściej wydajność, użyteczność, bezpieczeństwo oraz przenośność. Druga perspektywa identyfikuje parametry związane z utrzymaniem systemu, takie jak koszt zmian, skalowalność, testowalność, łatwość analizy, stabilność czy dojrzałość. Na przestrzeni lat, praktycy inżynierii wymagań zauważyli, że bardzo łatwo jest pominąć niektóre rodzaje wymagań jakościowych. Aby temu zaradzić zaproponowano różne klasyfikacje (taksonomie) wymagań, których istotą jest stworzenie pewnego rodzaju listy kontrolnej.

Najbardziej chyba szczegółową i wyczerpującą klasyfikacją wymagań jakościowych jest klasyfikacja zawarta w normie ISO/IEC 25010:2011 - Systems and software engineering, Systems and software Quality Requirements and Evaluation (SQuaRE), System and software quality models (Inżynieria systemowa i oprogramowania, Wymagania i ocena jakości systemów i oprogramowania, Modele jakości systemów i oprogramowania). Model ten zawiera podział na osiem grup. Dla każdej z tych grup określimy podgrupy oraz podamy po kilka przykładowych nazw wymagań.

Przydatność funkcjonalna (ang. Functional suitability) dotyczy spełniania przez system, używany w określonych warunkach, wyrażonych lub domniemanych potrzeb. Obszar ten obejmuje w szczególności określenie stopnia i dokładność pokrycia oczekiwanej funkcjonalności.

• kompletność funkcjonalna(ang. functional completeness) – stopień, w jakim zbiór funkcji pokrywa wszystkie wyspecyfikowane zadania oraz cele użytkowników,
• poprawność funkcjonalna (ang. functional correctness) – stopień, w jakim system zapewnia prawidłowe rezultaty z wymaganym poziomem dokładności,
• adekwatność funkcjonalna (ang. functional appropriateness) – stopień, w jakim funkcje ułatwiają wykonanie zadań i osiągnięcie celów.

Efektywność wydajnościowa (ang. Performance efficiency) obejmuje zbiór atrybutów opisujących powiązania między poziomem wydajności oprogramowania, a wykorzystywanymi zasobami (konfiguracji sprzętu i oprogramowania oraz materiałów eksploatacyjnych) przy spełnieniu określonych warunków. Obejmuje on wymagania dotyczące czasu reakcji, zużycia zasobów i wielkości zadań, z którymi musi radzić sobie system.

• czas (ang. time behaviour) – stopień, w jakim czasy odpowiedzi (przetwarzania danych) i wskaźniki przepustowości systemu podczas wykonywania jego funkcji spełniają wymagania,
• zużycie zasobów (ang. resource utilization) – stopień, w jakim ilości różnych typów zasobów (technologicznych) używanych przez system podczas wykonywania jego funkcji, spełniają wymagania,
• pojemność (ang. capacity) – stopień, w jakim maksymalne limity parametrów systemu (liczba przechowywanych elementów, liczba jednoczesnych użytkowników, rozmiar przestrzeni danych itp.) spełniają wymagania.

Kompatybilność (ang. Compatibility) dotyczy zdolności do wymiany informacji z innymi produktami, systemami lub komponentami i/lub wykonywania zadanych funkcji współdzieląc ten sam sprzęt lub środowisko software’owe. Ogólnie zatem, dotyczy współpracy z innymi systemami oprogramowania.

• współistnienie (ang. co-existence) – stopień, w jakim system może efektywnie wykonywać swoje funkcje podczas dzielenia wspólnego środowiska i zasobów z innymi systemami, bez negatywnego wpływu na działanie,
• interoperacyjność (ang. interoperability) – stopień, w jakim dwa lub więcej systemów mogą wymieniać i używać wymieniane informacje.

Użyteczność (ang. Usability) dotyczy dostosowania sposobu użycia systemu do potrzeb użytkowników. Oznacza to kwestie jakości wrażeń użytkownika z użytkowania systemu od pierwszych kontaktów z systemem, poprzez naukę korzystania do efektywności współdziałania.

• rozpoznawalność odpowiedniości (ang. appropriateness recognizability) – możliwość rozpoznania przez użytkowników czy produkt jest odpowiedni dla ich potrzeb; np. rozpoznanie na podstawie pierwszego wrażenia z użycia, dostarczonej dokumentacji, demonstracji, strony webowej,
• łatwość nauczenia (ang. learnability) – miara wysiłku, jaki musi włożyć użytkownik do nauczenia się nieznanych lub nowych funkcji aplikacji w celu osiągnięcia niezbędnej efektywności działania i/lub satysfakcji,
• operacyjność (ang. operability) – nakład pracy użytkownika niezbędny do obsługi i kontroli funkcji realizowanych przez oprogramowanie,
• zabezpieczenie przed błędami użytkownika (ang. user error protection) – stopień, w jakim system zapobiega popełnianiu błędów przez użytkowników,
• estetyka interfejsu użytkownika (ang. user interface aesthetics) – stopień, w jakim system zapewnia przyjemne i satysfakcjonujące współdziałanie użytkownika z systemem,
• przystępność (ang. accessibility) – stopień dostosowania systemu do potrzeb użytkowników ze specjalnymi potrzebami (np. osoby niepełnosprawne).

Niezawodność (ang. Reliability) dotyczy zapewnienia określonego poziomu działania systemu w określonym czasie przy założonych zasobach. Wymagania te opisują stopień odporności systemu na nieprzewidziane sytuacje, związane ze zdarzeniami zewnętrznymi oraz spowodowanymi przez system.

• dojrzałość (ang. maturity) – poziom zapewnienie niezawodnego działania (brak defektów) systemu w normalnych warunkach,
• dostępność (ang. availability) – poziom dostępności i operacyjności działania systemu, kiedy jego działanie jest wymagane,
• odporność na błędy (ang. fault tolerance) – zdolność do stabilnego funkcjonowania nawet w przypadku wystąpienia błędu lub niestabilnego działania sprzętu lub oprogramowania systemowego,
• odtwarzalność (ang. recoverability) – zdolność oprogramowania do przywrócenia stabilnego i wydajnego działania po awarii oraz przywrócenia stanu danych sprzed awarii.

Bezpieczeństwo (ang. Security) dotyczy ochrony danych przez system. Obejmuje stopień zabezpieczenia danych przez system, który umożliwia do nich dostęp odpowiedni do rodzajów uprawnień użytkowników lub innych systemów.

• poufność (ang. confidentiality) – zapewnienie dostępu do danych tylko dla jednostek do tego autoryzowanych,
• integralność (ang. integrity) – uniemożliwienie nieautoryzowanej możliwości zmiany programów i danych,
• niezaprzeczalność (ang. non-repudiation) – zapewnienie możliwości dowiedzenia wykonania akcji, tak, aby nie można im było zaprzeczyć w przeszłości,
• odpowiedzialność (ang. accountability) – zapewnienie identyfikacji jednostki odpowiedzialnej za akcje,
• autentyczność (ang. authenticity) – zapewnienie identyfikacji tożsamości jednostki (osoby).

Łatwość utrzymania (ang. Maintainability) dotyczy nakładów pracy koniecznych podczas utrzymywania systemu w eksploatacji. Obejmuje to wymagania związane z koniecznością aktualizacji systemu, rozszerzania jego funkcjonalności w przyszłości czy też poprawiania ewentualnych błędów znajdowanych podczas eksploatacji.

• modularność (ang. modularity) – poziom podziału na rozdzielne komponenty i ich wzajemnego wpływu,
• reużywalność (ang. reusability) – możliwość wykorzystania zasobu w więcej niż jednym systemie,
• łatwość analizy (ang. analysability) – nakład pracy konieczny do identyfikacji niedoskonałości, przyczyn defektów lub wskazania tych części oprogramowania, które powinny zostać poddane modyfikacji,
• łatwość zmiany (ang. modifiability) – nakład pracy konieczny do implementacji zmiany, usunięcia zidentyfikowanego błędu lub dostosowania aplikacji do nowego środowiska,
• testowalność (ang. testability) – nakład pracy potrzebny do weryfikacji poprawności działania aplikacji po wprowadzeniu do niej modyfikacji.

Przenośność (ang. Portability) dotyczy możliwości działania, instalacji i zamiany oprogramowania na różnych środowiskach sprzętowych, systemowych i software’owych.

• adaptowalność (ang. adaptability) – możliwość dostosowania oprogramowania do różnych, wyspecyfikowanych środowisk, bez konieczności realizacji dodatkowych czynności lub środków poza tymi, które są obecne w samym oprogramowaniu,
• łatwość instalowania (ang. installability) – nakład pracy konieczny do instalacji oprogramowania w danym środowisku,
• łatwość zamiany (ang. replaceability) – zdolność oprogramowania, do zastąpienia innej, konkretnej aplikacji w jej środowisku.

3.3. Formułowanie metryk dla wymagań jakościowych

Zdefiniowanie sposobów dokonywania pomiarów wymagań jakościowych jest kwestią bardzo istotną, gdyż może mieć decydujący wpływ na wycenę realizacji systemu. Dlatego też, konieczne jest określenie metryk wymagań jakościowych, które pozwolą na dokonanie możliwie precyzyjnego szacowania rozmiarów systemu i kosztu jego implementacji. Aby szacowanie było możliwe, metryka powinna posiadać trzy elementy:

• Przedstawienie sposobu pomiaru – opis procedury pomiarowej, uwzględniający najważniejsze elementy procesu ustalania wartości mierzonej wartości, czyli dokonywania pomiaru.
• Określenie zbioru możliwych wartości pomiaru – opis jednostek, w jakich będzie dokonywany pomiar (fizycznych, logicznych, symbolicznych) oraz możliwy zakres pomiarowy.
• Określenie oczekiwanych wartości pomiaru – opis wartości pomiaru, które są oczekiwane, wraz z charakterystyką możliwych błędów, przy czym wartości te mogą być różne w zależności od warunków dokonywania pomiaru.

Podczas formułowania metryki najważniejsze jest znalezienie właściwej procedury pomiaru dla dennego wymagania jakościowego. Ogólnie można rozróżnić kilka podstawowych klas tego typu procedur.

• Dokonanie bezpośredniego pomiaru parametrów systemu (eksperyment). Parametrami mogą być m.in. czas, liczba transakcji w czasie, zajętość pamięci, czy też procent wykorzystanych zasobów fizycznych (papier, tusz). Pomiar dokonywany jest przy pomocy odpowiednich narzędzi pomiarowych.
• Przeprowadzanie audytów przez zewnętrzne jednostki audytujące lub odpowiednie oprogramowanie. Audyty mogą dotyczyć takich elementów jak kod systemu, projekt architektury systemu, bezpieczeństwa, zgodności z normami. Rezultatem audytu może być miara spełnienia określonych warunków jakościowych lub zaklasyfikowania systemu do określonej kategorii.
• Wykonanie ankietyzacji wśród interesariuszy. Głównie dotyczy to osób stykających się bezpośrednio z systemem. Ankieta jest wypełniana przez jej uczestników w trakcie lub bezpośrednio po kontakcie z systemem. Ankiety dotyczą głównie elementów użyteczności systemu, takich jak satysfakcja użytkowników, zrozumienie działania systemu, wysiłek włożony w wykonanie działania lub nauczenie się funkcjonowania systemu.
• Przeprowadzenie sprawdzianów wśród użytkowników. Sprawdziany umożliwiają obserwację współdziałania użytkowników z systemem. Najczęściej wykonuje się je w postaci różnego rodzaju testów sprawności używania systemu
• Symulowanie zdarzeń. Tego typu procedury polegają na sztucznym wywoływaniu nieprawidłowych sytuacji dotyczących różnych aspektów systemu. Jedną z klas takich procedur jest tzw. wstrzykiwanie błędów do systemu. „Wstrzyknięcie” błędu w kodzie polega na dokonaniu modyfikacji kodu powodującej jego nieprawidłowe działanie.

Powyższe typy procedur pomiarowych stosujemy w odpowiedni sposób do różnych kas wymagań jakościowych przedstawionych w poprzedniej sekcji. Najbardziej chyba oczywistymi do zmierzania są wymagania odnoszące się do dynamiki systemu, czyli wymagania wydajności. Efektywność, będąca miarą związku miedzy zasobami (mocą obliczeniową) a wynikami szybkości działania osiąganymi przez program łatwo wyrazić liczbowo mierząc czas wykonania pewnych operacji, czas odpowiedzi przy założeniu pewnych sygnałów itd.

W przypadku wymagań użyteczności, najczęściej chcielibyśmy zmierzyć wysiłek jaki użytkownicy systemu wkładają w korzystanie z jego funkcjonalności. Użyteczność podlega najczęściej weryfikacji poprzez ocenę użytkowników systemu oraz ekspertów ergonomii systemów informatycznych. Możliwa procedura pomiarowa może wykorzystywać audyt przeprowadzany przez określoną jednostkę lub eksperta od „doświadczenia użytkownika”  (ang. user experience, UX). W ramach takiego audytu mogą być badane na przykład następujące kryteria: zgodność ze standardami i regułami komunikacji człowiek-komputer, intuicyjność, spójność, elastyczność, wygoda, poprawność. Innym, często wykorzystywanym sposobem na mierzenie użyteczności systemu są ankiety. Przy pomocy ankiet możemy mierzyć wiele różnych parametrów, których źródłem są przede wszystkim użytkownicy systemu i ich opinie o systemie. Takimi parametrami mogą być: miara wysiłku użytkownika (ang. Customer Effort Score, CES), miara satysfakcji klienta (ang. Customer Satisfaction Score, CSAT), miara chęci promowania (ang. Net Promoter Score, NPS).

Można również mierzyć użyteczność sytemu poprzez przeprowadzenie sprawdzianów różnego rodzaju. Efektem sprawdzianów może być określenie następujących miar: współczynnik powodzenia wykonania zadań (ang. Task Success Rate), czas przeznaczony na wykonanie zadania (ang. Time spent on task), miara błędów użytkownika (ang. User Errors).

Zupełnie inne metryki niż użyteczność dotyczą wymagań bezpieczeństwa. Testowanie bezpieczeństwa systemów często dotyczy testów całych środowisk wykonawczych. Testy polegają na weryfikacji czy operacje dotyczące danych spełniają określone standardy i założenia, a także na badaniu ścieżek przepływu komunikacji aktorzy-system (pod kątem np. przekroczenia uprawnień). Przetwarzanie danych przez system należy ocenić ze względu na zachowanie ich integralności, poufność przesyłu i wymiany, poziomy dostępu, czy sposób monitorowania zmian. Częstym sposobem jest zatem przeprowadzenie audytów przez wyspecjalizowane organizacje (np. kontrolowana próba „włamania” do sytemu). Efektem takiego audytu jest często uzyskanie certyfikatu bezpieczeństwa określonego rodzaju.

Podobne podejście może dotyczyć weryfikacji spełnienia wymagań kompatybilności. Duże możliwości daje tutaj wirtualizacja systemów operacyjnych i sprzętu. Korzystając ze środowisk-emulatorów można zbadać działanie systemu w różnych konfiguracjach sprzętowych i programowych oraz na różnych platformach. Innym sposobem weryfikacji jest sprawdzenie zgodności systemu z odpowiednimi standardami wymiany danych poprzez interfejsy systemowe. Istnieją tutaj odpowiednie zasady uzyskiwania certyfikatów zgodności i przejście przed odpowiednią procedurę certyfikacyjną może być elementem metryki tego typu wymagań. Podobne procedury weryfikacji można zastosować dla wymagań przenośności.

Zupełnie inne podejście należy zastosować dla wymagań łatwości utrzymania. Zadaniem jest najczęściej oszacowanie kosztu (wysiłek, czas) różnych czynności związanych z utrzymaniem – poprawienia błędu, rozszerzenia o nową funkcję czy też bieżącej obsługi systemu. Estymację taką możemy oprzeć na analizie kosztów zmian w systemie oraz testowania tych zmian, dokonywanych jeszcze w trakcie projektu konstrukcji tego systemu. Inną metodą jest przeprowadzenie audytów architektury oraz kodu systemu. Audyty takie przeprowadzane są najczęściej przez doświadczonych deweloperów.

3.4. Ograniczenia techniczne i środowiskowe

Osobnym składnikiem piramidy wymagań są ograniczenia techniczne i środowiskowe. Często tego typu charakterystyki systemu są traktowane jak wymagania jakościowe, jednak są one zasadniczo od nich różne. Bardzo istotnym wyróżnikiem ograniczeń jest sposób ich weryfikacji. Nie mamy tutaj określonych procedur weryfikacyjnych, gdyż ograniczenia są narzuconymi cechami warsztatu deweloperskiego lub otoczenia systemu. Są to zatem niezmienniki, rządzące procesem wytwarzania danego systemu oprogramowania.

Ograniczenia techniczne dotyczą technologii, jakie zespół deweloperski musi zastosować podczas budowy systemu. Ograniczają one stopień swobody w wyborze architektury, sprzętu czy narzędzi programistycznych. Ograniczenie nie jest wymaganiem w pełni tego słowa znaczeniu, gdyż nie zaspokaja konkretnej potrzeby klienta z punktu widzenia jego działalności. W związku z tym, dla ograniczeń nie definiujemy metryk z oczekiwanymi wartościami oznaczającymi ich spełnienie.

Jak się wydaje, brakuje jednolitego standardu definiującego rodzaje ograniczeń technicznych. Mimo to spróbujemy podać najważniejsze grupy tego typu charakterystyk systemu.

• Ograniczenia dotyczące języków programowania. Ograniczenie togo typu dotyczy sytuacji, kiedy klient wyraźnie narzuca konkretny język lub języki, w których musi być napisany kod sytemu. Dotyczy to również konieczności zastosowania określonych szkieletów programistycznych (frameworków) opartych na określonych językach.
• Ograniczenia dotyczące środowiska deweloperskiego. Ograniczenie tego typu dotyczy sytuacji, kiedy klient narzuca określony zestaw narzędzi, które muszą być wykorzystywane podczas budowy systemu. Dotyczyć to może całego procesu wytwórczego oraz procesu zarządzania projektem.
• Ograniczenia dotyczące stosowanego sprzętu. Ograniczenie tego typu związane jest z koniecznością wykorzystania określonych istniejących zasobów sprzętowych. Może to dotyczyć różnych elementów sprzętowych, takich jak stacje robocze, serwery, sieci, urządzenia peryferyjne.
• Ograniczenia dotyczące stosowanych komponentów programowych. Ograniczenia tego typu dotyczy konieczności zastosowania określonych gotowych komponentów jako składowych systemu. Najczęstszą sytuacją jest zastosowanie konkretnego komponentu bazodanowego lub technologii bazodanowej. Inne sytuacje obejmują komponenty odpowiedzialne za komunikację w systemie.

Podobnie możemy określić najważniejsze rodzaje ograniczeń środowiskowych.

• Ograniczenia dotyczące parametrów fizycznych środowiska. Parametrami środowiska mogą być m.in. temperatura, wilgotność, przejrzystość powietrza.
• Ograniczenia dotyczące zachowań i możliwości użytkowników. Zakres takich ograniczeń jest dosyć szeroki i może dotyczyć ograniczeń fizycznych, którym podlegają użytkownicy systemu, ograniczeń możliwości wykorzystywanie określonych funkcji sytemu lub ograniczeń umiejętności.
• Ograniczenia dotyczące infrastruktury nieinformatycznej. Przeważnie tego typu ograniczenia dotyczą kwestii zasilania systemu w energię. Mogą też dotyczyć innych aspektów infrastruktury, takich jak rozmiary pomieszczeń, sposoby kontroli dostępu do pomieszczeń, sposoby ustawienia stanowisk roboczych.