Inżynieria wymagań w rozwoju sprzętu

Bądźmy szczerzy: niewiele osób ekscytuje się wymaganiami. A jednak każdy zespół sprzętowy odczuł koszt niejasnych wymagań: późno ujawniające się poprawki albo wersję produktu, która nie spełnia tego, o co faktycznie prosili interesariusze. 

Inżynieria wymagań (RE) to dyscyplina oparta na ustrukturyzowanym procesie definiowania, dokumentowania i zarządzania wymaganiami, tak aby produkt końcowy rozwiązywał właściwy problem. Dobrze stosowana pozwala wcześnie wykrywać błędy, utrzymywać zgodność działań zespołu i daje wszystkim pewność, że do wdrożenia trafia dokładnie to, co rzeczywiście uzgodniono do zbudowania.

Jednak sam termin bywa często mylony, ponieważ ma korzenie zarówno w inżynierii oprogramowania, jak i w inżynierii systemów dla produktów sprzętowych. 

W tym artykule znajdziesz jasną definicję inżynierii wymagań oraz jej roli w rozwoju produktów sprzętowych. Omawiamy zarówno przegląd teoretyczny, jak i praktyczne ramy jej zastosowania w projekcie sprzętowym, wraz z przykładami z rzeczywistej praktyki oraz listą najczęstszych pułapek i sposobów ich unikania.

Najważniejsze wnioski

• Inżynieria wymagań pomaga zespołom sprzętowym przełożyć intencję projektową na jasne wymagania i utrzymać zgodność wszystkich członków zespołu.
• Wymagania prowadzą projekt od wczesnego planowania i projektowania, przez testy i zmiany, aż po końcową dokumentację.
• Dobrze prowadzony proces wymagań pomaga zespołom deweloperskim wcześnie wykrywać problemy, unikać kosztownych przeprojektowań i zapewniać, że finalny produkt spełnia to, co zostało uzgodnione.

Czym jest inżynieria wymagań?

Inżynieria wymagań to systematyczne i zdyscyplinowane podejście do definiowania, dokumentowania i zarządzania wymaganiami podczas rozwoju produktu sprzętowego.

Pomaga zespołom zrozumieć problem, który należy rozwiązać, doprecyzować i przeanalizować potrzeby interesariuszy, rozstrzygać konflikty i kompromisy, dokumentować to, co produkt musi osiągnąć, oraz aktualizować to rozumienie wraz z ewolucją produktu.

W praktyce wymagania tworzą wspólne zrozumienie pomiędzy interesariuszami a zespołami inżynierskimi tego, co jest budowane, dlaczego jest budowane i jak zespół rozpozna, czy produkt końcowy spełnia założenia projektowe.

Korzyści z inżynierii wymagań

Jeśli RE jest prowadzone właściwie, pomaga zapobiegać nieporozumieniom i kosztownym błędom, utrzymuje spójność działań zespołu i pomaga upewnić się, że finalny produkt spełnia swoje wymagania.

Główne korzyści z RE obejmują:

• Wspólna wizja: Utrzymuje zgodność interesariuszy, menedżerów i zespołów inżynierskich wokół tego samego rozumienia tego, co jest budowane.
• Jasno określony zakres: Wyraźnie pokazuje, co wchodzi w zakres projektu, a co nie, pomagając zapobiegać niekontrolowanemu rozszerzaniu zakresu projektu.
• Ograniczenie kosztownych błędów: Pomaga wcześnie wykrywać problemy w wymaganiach, zanim przerodzą się w kosztowne poprawki projektowe, nowe prototypy lub powtórne testy.
• Lepsze planowanie i harmonogramowanie: Daje zespołom jaśniejszy obraz tego, co trzeba zbudować, dzięki czemu łatwiej oszacować zakres prac i stworzyć realistyczne harmonogramy.
• Lepsza jakość produktu: Pomaga upewnić się, że finalny produkt robi to, co uzgodniono, i spełnia wymagane standardy jakości.

Rozwój dyscypliny inżynierii wymagań

Inżynieria wymagań ma korzenie zarówno w inżynierii systemów, jak i w inżynierii oprogramowania. Te dwa nurty rozwijały się w różnych kontekstach inżynierskich, dlatego termin ten nadal może mieć nieco inny zakres w zależności od źródła.

W kontekście inżynierii oprogramowania nacisk kładzie się przede wszystkim na wymagania dotyczące rozwoju oprogramowania: co oprogramowanie powinno robić, jak powinno się zachowywać i jakie atrybuty jakości powinno spełniać. Inżynierowie oprogramowania myślą o wymaganiach funkcjonalnych i niefunkcjonalnych dokumentowanych jako historyjki użytkownika, przypadki użycia i kryteria akceptacji. W kontekście inżynierii systemów zakres jest szerszy. Wymagania odnoszą się do całego systemu, w tym sprzętu, oprogramowania, ludzi, procesów, interfejsów, warunków pracy oraz innych cech systemu. Inżynierowie systemowi mówią o wymaganiach na poziomie systemu, rozdzielanych dalej na obszary sprzętowe, mechaniczne, elektryczne, firmware oraz czynniki bezpieczeństwa, zapisywanych w formie formalnych zapisów wymagań i macierzy śledzenia wymagań.

W rozwoju sprzętu RE łączy obie perspektywy. Łączy rygor i wielodyscyplinarny zakres inżynierii systemów, potrzebne do radzenia sobie z kosztami zestawienia materiałowego (BOM), ograniczeniami termicznymi i ograniczeniami produkcyjnymi, ze śledzalnością w całym cyklu życia stosowaną w inżynierii oprogramowania, aby wymagania pozostawały testowalne i powiązane przez cały proces rozwoju.

Dziedziny pokrewne wobec inżynierii wymagań

Inżynieria wymagań jest ściśle powiązana z innymi dyscyplinami rozwoju produktu, zwłaszcza z inżynierią systemów i zarządzaniem produktem.

Inżynieria systemów

Inżynieria systemów postrzega produkt jako kompletny system. Inżynier systemowy dba o to, aby różne części, takie jak sprzęt, oprogramowanie, elementy mechaniczne i testy, współpracowały ze sobą prawidłowo i nie wchodziły ze sobą w konflikt.

Jest to ściśle powiązane z RE, ponieważ wymagania dają wszystkim tym zespołom wspólny punkt odniesienia dla tego, co produkt musi osiągnąć.

Jeśli lubisz analogie, wyobraź sobie budowę domu. Różni specjaliści pracują nad fundamentami, instalacją elektryczną, hydrauliką i ogrzewaniem, ale ktoś nadal musi dopilnować, aby wszystkie te elementy rzeczywiście pasowały do siebie jako jedna kompletna konstrukcja. Inżynieria systemów pełni dokładnie taką rolę w rozwoju produktu.

Zarządzanie produktem

Zarządzanie produktem pomaga zdecydować, co zbudować i dlaczego. Menedżerowie produktu rozmawiają z klientami, analizują rynek, przyglądają się konkurencji i współpracują z biznesem, aby zdecydować, które problemy warto rozwiązać i które funkcje mają największe znaczenie.

To również jest powiązane z RE, ponieważ te wysokopoziomowe potrzeby klientów i cele biznesowe stają się punktem wyjścia do definiowania wymagań produktowych.

Fazy procesu inżynierii wymagań

Proces RE można organizować na różne sposoby w zależności od obszaru zastosowania, zaangażowanych osób i organizacji. W niektórych projektach działania przebiegają głównie jedno po drugim, podczas gdy w innych są powtarzane i ponownie analizowane w miarę, jak zespół dowiaduje się więcej.

Jak opisano w artykule opublikowanym w czasopiśmie Requirements Engineering, typowe podejście podręcznikowe dzieli proces RE na cztery podstawowe działania (fazy):

• Pozyskiwanie wymagań: gromadzenie wymagań od interesariuszy i z innych źródeł, aby zrozumieć, co system musi robić i w jakich warunkach ma działać.
• Analiza i specyfikacja wymagań: przegląd zebranych informacji, rozstrzyganie niejasności lub sprzeczności oraz przekształcanie ich w jasne wymagania, z których może korzystać zespół inżynierski.
• Walidacja wymagań: sprawdzanie, czy wymagania są poprawne, kompletne i czy opisują to, co system ma osiągnąć.
• Zarządzanie wymaganiami: śledzenie wymagań i zmian w nich w czasie, w tym powodów tych zmian oraz tego, jakie inne wymagania, prace projektowe lub testy mogą zostać nimi dotknięte.

Kto uczestniczy w tym procesie

W ramach RE zaangażowanych jest kilka kluczowych ról, które wspólnie definiują, co produkt powinien robić:

• Właściciel wymagań: Inżynier, który bierze nieprecyzyjne potrzeby interesariuszy, zadaje właściwe pytania i przekształca je w zestaw wymagań, z którego zespół inżynierski może realnie korzystać przy rozwoju produktu. Często jest to inżynier systemowy, główny inżynier lub osoba o podobnym zakresie odpowiedzialności.
• Techniczne kierownictwo produktu: Osoby, które komunikują się ze stroną biznesową/interesariuszami, rozumieją ich potrzeby, a następnie przekładają to zapotrzebowanie na jasny cel produktowy. Mogą to być menedżerowie produktu, menedżerowie programu lub osoby na podobnych stanowiskach.
• Inżynier wdrożeniowy: Inżynier, który wykorzystuje zdefiniowane wymagania do zaprojektowania i zbudowania produktu. Mogą to być inżynierowie elektronicy, mechanicy, programiści lub inżynierowie firmware.
• Właściciel weryfikacji: Osoba, która decyduje, w jaki sposób wymagania będą testowane, i dba o to, aby niezbędne przeglądy i testy zostały przeprowadzone. Mogą to być inżynierowie weryfikacji, inżynierowie testów lub inżynierowie QA.

Praktyczne ramy inżynierii wymagań dla rozwoju sprzętu

Choć cztery powyższe działania definiują rdzeń procesu RE, zespoły sprzętowe potrzebują praktycznego sposobu stosowania ich w całym projekcie.

Poniżej przedstawiono praktyczne ujęcie ram inżynierii wymagań dla rozwoju sprzętu, pokazujące, jak wymagania wpisują się w każdy etap.

Rozpoczęcie projektu: uchwycenie intencji

Na początku projektu liderzy techniczni zwykle otrzymują nieprecyzyjne dane wejściowe, takie jak wymagania klienta, zapytania ofertowe (RFP), cele biznesowe lub ograniczenia dotyczące kosztu, rozmiaru czy harmonogramu. Na przykład klient może poprosić o mniejsze urządzenie obsługujące konkretny przypadek użycia.

Wspólnie z właścicielem wymagań liderzy techniczni doprecyzowują, co jest potrzebne, i przekształcają te dane wejściowe w wymagania wysokiego poziomu opisujące, co produkt powinien osiągnąć.

Inżynieria wymagań: definiowanie wymagań

Wymagania wysokiego poziomu z fazy rozpoczęcia projektu są nadal zbyt ogólne do szczegółowego projektowania. W tej fazie właściciel wymagań definiuje cały system, dzieli go na części i podsystemy oraz przekształca te wymagania wysokiego poziomu w bardziej szczegółowe wymagania dla każdej części.

Sprawdza również, czy wymagania nie są ze sobą sprzeczne, czy niczego istotnego nie brakuje oraz czy każde z nich jest jasne i testowalne. Rezultatem jest uzgodniony zestaw wymagań, z którego zespół inżynierski może korzystać jako punktu wyjścia do projektowania produktu.

Implementacja: rozwój projektu

Inżynierowie wdrożeniowi wykorzystują uzgodnione wymagania do projektowania i budowy swojej części produktu, niezależnie od tego, czy oznacza to tworzenie schematu, modelowanie części 3D, czy pisanie oprogramowania lub firmware. W miarę rozwoju projektu łączą każde wymaganie z cechą projektu, która je spełnia. Powiązania te tworzą śledzalność projektu i pomagają właścicielowi wymagań zobaczyć, w jaki sposób wymagania zostały wdrożone.

Weryfikacja i walidacja: testowanie i potwierdzanie

Wymagania określają również, co należy sprawdzać podczas przeglądów i testów. Inżynier weryfikacji definiuje sposób sprawdzenia każdego wymagania i współpracuje z inżynierami wdrożeniowymi przy wykonywaniu niezbędnych przeglądów, pomiarów lub testów, a następnie zapisuje wyniki. Łączy to wymagania dotyczące tego, co produkt miał osiągnąć, z dowodami pokazującymi, czy rzeczywiście to osiągnął.

Zarządzanie zmianą: rewizja i iteracja

Wymagania i projekty produktu często zmieniają się w trakcie rozwoju. Może się okazać, że spełnienie danego wymagania jest niemożliwe, jakiś komponent może stać się niedostępny na rynku albo może pojawić się nowe ograniczenie. Kiedy tak się dzieje, właściciel wymagań śledzi, co się zmieniło, dlaczego się zmieniło oraz których wymagań, części projektu lub testów to dotyczy.

Dokumentacja i przekazanie: dostarczenie projektu

Pod koniec projektu właściciel wymagań współpracuje z inżynierem ds. weryfikacji oraz resztą zespołu, aby zamknąć wymagania, przeglądy projektu i działania weryfikacyjne. Końcowa dokumentacja powinna zapewniać możliwy do prześledzenia zapis tego, co było wymagane, co zostało zbudowane i jak to zweryfikowano. Klienci, producenci, audytorzy lub zespoły, które będą dalej pracować nad produktem, będą później potrzebować tych informacji.

Przykłady inżynierii wymagań

Inżynieria wymagań w wyrobach medycznych

Inżynieria wymagań jest stosowana w całym obszarze produktów medycznych i technologii opieki. Wymagania towarzyszą produktowi przez cały cykl rozwoju. Zespoły przekształcają potrzeby interesariuszy w uporządkowane wymagania systemowe, utrzymują powiązania między nimi wraz ze zmianami specyfikacji oraz wykorzystują je do planowania weryfikacji i dokumentowania wyników testów.

W przypadku wyrobów medycznych dochodzi dodatkowa warstwa regulacyjna. Zespoły przykładają większą wagę do identyfikowalności, weryfikacji, dokumentacji i formalności. Wspiera to uzyskanie zgodności regulacyjnej w ramach takich standardów jak FDA 21 CFR Part 820 w USA oraz ISO 13485:2016 w UE i na innych rynkach.

Ochraniacz na zęby HitIQ to przykład medycznego urządzenia ubieralnego, w którym wymagania bezpieczeństwa wyznaczają każdą specyfikację techniczną. Dowiedz się, jak to wygląda w praktyce, w pełnej historii sukcesu klienta.

Inżynieria wymagań w elektronice konsumenckiej i przemysłowej

Podstawowy proces inżynierii wymagań jest podobny w elektronice konsumenckiej i przemysłowej, ale produkty powstają w różnych warunkach. Produkty konsumenckie, takie jak urządzenia smart home lub urządzenia ubieralne, są sprzedawane w dużych wolumenach i szybko trafiają na rynek. Produkty przemysłowe, takie jak programowalne sterowniki logiczne (PLC) czy napędy silnikowe, muszą działać przez lata w trudnych warunkach.

W obu przypadkach zespoły zapisują, co produkt musi robić, łączą każde wymaganie z projektem, aktualizują wymagania, gdy coś się zmienia, i testują względem nich.

Różnica polega na tym, gdzie zespoły wkładają dodatkowy wysiłek. W elektronice konsumenckiej chodzi o nadążanie za szybkimi zmianami, ponieważ jedno źle zrozumiane wymaganie może oznaczać konieczność przeprojektowania płytki. W elektronice przemysłowej nacisk kładzie się na weryfikację, ponieważ produkt musi zostać przetestowany pod kątem długiej żywotności i pracy w trudnych warunkach, zanim trafi do sprzedaży.

Aby budować niezawodny sprzęt zgodny z przepisami bezpieczeństwa, kluczowe jest utrzymywanie powiązań między wymaganiami a zmianami w projekcie. Przeczytaj, jak MakeSafe Tools zarządza tym w pełnej historii sukcesu.

Jak unikać typowych pułapek inżynierii wymagań

Inżynieria wymagań wiąże się z pewnymi typowymi wyzwaniami. Świadomość tego, co może pójść nie tak, ułatwia wczesne wykrywanie problemów i unikanie ich podczas rozwoju produktu sprzętowego.

Oto niektóre z najczęstszych pułapek, na które warto uważać, oraz sposoby ich unikania:

Narzędzia programowe do inżynierii wymagań

Zarządzanie niewielkim zbiorem wymagań jest stosunkowo proste. Wraz z rozwojem projektu utrzymanie porządku i aktualności wymaga więcej wysiłku. W tym momencie sposób zarządzania wymaganiami zaczyna mieć większe znaczenie.

W praktyce zespoły zwykle korzystają z jednego z następujących podejść:

• Arkusze kalkulacyjne i dokumenty: Są znajome i łatwe na początek, co sprawia, że są przydatne w mniejszych projektach. Wraz z rozwojem projektu wymagają jednak więcej ręcznej pracy, aby je utrzymać.
• Dedykowane narzędzia do zarządzania wymaganiami (RM): Zapewniają większą strukturę i kontrolę, gdy projekty stają się bardziej złożone. Minusem jest to, że niektóre narzędzia wprowadzają też więcej procesów, niż może potrzebować mniejszy zespół.

Celem jest zastosowanie takiego poziomu struktury, jaki jest potrzebny projektowi, bez niepotrzebnego komplikowania zarządzania wymaganiami.

Dla mniejszych zespołów sprzętowych, które wyrosły już z arkuszy kalkulacyjnych, ale nie potrzebują rozbudowanego korporacyjnego workflow RM, Requirements Portal to praktyczna opcja warta rozważenia. Zostało zaprojektowane tak, aby zapewnić mniejszym zespołom bardziej uporządkowany sposób zarządzania wymaganiami bez narzutu typowego dla tradycyjnego systemu korporacyjnego.

Podsumowanie i kolejne kroki

Na tym etapie powinieneś już dobrze rozumieć główne pojęcia związane z inżynierią wymagań i wiedzieć, jak stosuje się je w praktyce.

Jeśli chcesz dalej zgłębiać temat inżynierii wymagań, te materiały to dobry punkt wyjścia:

• ISO/IEC/IEEE 29148:2018 przedstawia międzynarodowy standard procesów i praktyk inżynierii wymagań. Zawiera dodatkowe wskazówki dotyczące tego, jak wymagania powinny być formułowane, strukturyzowane, dokumentowane i zarządzane.
• NASA Systems Engineering Handbook zawiera praktyczne wskazówki dotyczące tego, jak wymagania są tworzone, zapisywane, sprawdzane i wykorzystywane podczas rozwoju systemu.
• Guide to the Systems Engineering Body of Knowledge (SEBoK) wyjaśnia, jak wymagania wpisują się w szerszy proces inżynierii systemów i jak różne części systemu są rozwijane wspólnie.
• Czasopismo Requirements Engineering publikuje badania, przykłady z branży i różne podejścia do inżynierii wymagań w większej szczegółowości.

Jeśli jesteś gotowy przejść od teorii do praktyki, wypróbuj Requirements Portal i zacznij już dziś pracować z ustrukturyzowanymi wymaganiami przy rzeczywistym projekcie sprzętowym — bezpłatnie i bez konieczności konfiguracji.

Często zadawane pytania

Dlaczego inżynieria wymagań jest ważna?

Inżynieria wymagań ma znaczenie, ponieważ pomaga zespołowi zbudować właściwy produkt dzięki jasnemu zrozumieniu potrzeb interesariuszy, zanim projektowanie i rozwój zajdą zbyt daleko.

Jaka jest rola inżyniera wymagań?

Inżynier wymagań przekształca potrzeby interesariuszy w jasne wymagania, z których może korzystać zespół inżynierski, oraz utrzymuje te wymagania w uporządkowanej formie wraz ze zmianami projektu. Pełni rolę pomostu między klientami a zespołami rozwojowymi. 

Jaka jest różnica między inżynierią wymagań a zarządzaniem wymaganiami?

Inżynieria wymagań to cały proces ustalania, rozumienia i zapisywania tego, co system ma robić. Zarządzanie wymaganiami to konkretny element tego procesu, który polega na utrzymywaniu tych wymagań w uporządkowanej formie i śledzeniu zmian po ich zapisaniu.