Tworzenie planu zarządzania wymaganiami inżynieryjnymi

Javier Alcina Espigado
|  Utworzono: listopad 27, 2024
Tworzenie planu zarządzania wymaganiami inżynieryjnymi

Identyfikacja i ustalenie zestawu wymagań na początkowym etapie każdego projektu jest kluczowe dla osiągnięcia sukcesu. Ten artykuł, w prosty sposób, ma na celu wprowadzenie Cię do tworzenia planu zarządzania wymaganiami w projektach inżynierskich poprzez kilka podstawowych pojęć oraz wykorzystanie Altium 365 Requirements & Systems Portal.

Ten blog jest przeznaczony dla inżynierów, profesjonalistów, kierowników projektów, menedżerów produktu oraz każdego, kto potrzebuje zrozumieć, jak stworzyć plan zarządzania wymaganiami.

Co to jest wymaganie?

Chociaż to oczywiste, warto zastanowić się nad kwestią 'co to jest wymaganie?'. Wymaganie, według słownika, to 'konieczny warunek lub okoliczność dla czegoś'. W świecie inżynierii, wymagania są sposobem komunikacji między użytkownikami lub klientami a twórcami projektu. Czasami, szczególnie w dużych projektach, jest to jeden z niewielu możliwych sposobów, w jaki użytkownicy mogą powiedzieć twórcom, czego chcą.

Przykład wymagania w projekcie motoryzacyjnym:

'Użytkownicy powinni być w stanie podróżować automatycznie z predefiniowanymi prędkościami za pomocą tempomatu.'

Dlaczego wymagania są tak ważne?

Mówi się, że: "słaba definicja i zarządzanie wymaganiami mogą kosztować fortunę i prowadzić do niepowodzenia w realizacji projektu."

Definicja wymagań jest tak ważna, że zazwyczaj stanowią one podstawę umów między klientami a dostawcami. To, co jest zdefiniowane w wymaganiach, powinno być uwzględnione w projekcie i może być wymagane przez klienta, jednak to, co nie pojawi się w definicji wymagań, nie może być wymagane w fazie dostawy projektu.

Dlatego, jeśli jesteśmy odpowiedzialni za pisanie wymagań, powinniśmy:

  • Zorientować się dokładnie, jakie są potrzeby klienta.
  • Utworzyć dokument o jasnej strukturze i dobrze zorganizowanych wymaganiach.
  • Zorganizować spotkanie z klientem, aby zweryfikować, czy obie strony mają spisane interesy (umowę).
  • Zapewnić, że przyjęte rozwiązanie jest zgodne z wymaganiami w miarę postępu projektu.
  • Weryfikować i testować zgodność z wymaganiami.

Ta grupa działań jest znana jako plan zarządzania wymaganiami. Bardzo ważne jest, aby w organizacji był menedżer lub zespół zarządzający, który identyfikuje, definiuje i śledzi wymagania przez całe życie projektu.

Jak Powinno Być Napisane Wymaganie?

Pisanie wymagań nie jest takie proste i oczywiste, jak mogłoby się wydawać. To dokument, który musi spełniać określone kryteria. Dlatego wymaganie musi:

  • Być jasne, precyzyjne i konkretne: musi jasno i dokładnie opisywać, czego potrzeba.
  • Być zwięzłe: używać jak najmniej słów.
  • Używać prostego języka: unikać mylenia czytelnika terminami technicznymi lub skomplikowanymi słowami.

Przykład dobrze napisanego wymagania:

  • Wszystkie komponenty (SMD i przewlekane) muszą być umieszczone na górnej stronie.

Przykład źle napisanego wymagania:

  • Komponenty SMD muszą być umieszczone po tej samej stronie, i należy zapewnić, że lutowanie komponentów przewlekanych jest po przeciwnej stronie do lutowania komponentów SMD.

W powyższym przykładzie, dobrze napisane wymaganie jest zwięzłe i doskonale definiuje bez żadnej niejasności, czego wymaga się, podczas gdy źle napisane wymaganie ma zbyt wiele tekstu, który nie wnosi niczego, myli czytelnika i jest nieprecyzyjne (nie określa, po której stronie powinny być umieszczone komponenty).

Wymagania są zawsze obowiązkowe i dlatego powinny być zapisywane przy użyciu słowa "musi". Gdy wymagania są preferencjami lub życzeniami (nieobowiązkowymi), można użyć słowa "powinno" do ich określenia, a nawet "może", gdy jest to sugestia lub udzielone pozwolenie.

Podstawowe zasady definiowania wymagania

Dodatkowo, definiując wymaganie, musi ono spełniać kilka podstawowych zasad:

  • Musi posiadać unikalne ID.
  • Powinno być zrozumiałe samo w sobie, bez dodatkowych informacji.
  • Musi być spójne z pozostałymi wymaganiami.
  • Zawsze musi być aktualne (kontrola wersji).
  • Musi być wykonalne (unikaj niemożliwych wymagań).
  • Jego implementacja musi być zweryfikowana poprzez inspekcję, demonstrację lub testowanie.

Identyfikacja wymagań

Każde zdefiniowane wymaganie musi posiadać unikalne ID, aby można było się do niego odwoływać podczas definiowania i przeglądu wymagań, jak również w dowolnym momencie podczas realizacji projektu. Przykład identyfikacji wymagań pokazano, używając Altium 365 Requirements and Systems Portal.

Identification of Requirements in Altium 365 Requirements and Systems Portal

Jakie typy wymagań istnieją i jak są klasyfikowane?

Podstawowo istnieją dwa typy wymagań:

  • Wymagania Funkcjonalne: Określają funkcjonalność systemu.
  • Wymagania Niefunkcjonalne: Nakładają ograniczenia lub wymagania na rozwiązanie (środowiskowe, niezawodność, kompatybilność elektromagnetyczna, bezpieczeństwo, obowiązujące przepisy, wymagania kosztowe, harmonogramy itp.).

Połączenie tych wymagań funkcjonalnych i niefunkcjonalnych stanowi to, co jest znane jako specyfikacja systemu. W specyfikacji systemu wymagania są grupowane zgodnie z następującymi poziomami:

  • Wymagania wstępne lub klienta
  • Wymagania systemowe
  • Wymagania podsystemów

Wymagania wstępne lub klienta to te, które są bezpośrednio dostarczane przez klienta lub użytkownika przed rozpoczęciem projektu. Są one kluczowe, ponieważ odzwierciedlają potrzeby klienta i tym samym służą jako punkt wyjścia do tworzenia naszej macierzy wymagań. Następnie specyfikacja systemu organizuje wymagania w oparciu o poziom szczegółowości odpowiedni dla każdej części projektu. W ten sposób mamy wymagania systemowe, które dotyczą całego systemu, oraz wymagania podsystemów, które dotyczą tylko określonych części systemu. Zilustrujmy to na przykładzie.

Załóżmy, że rozwijamy projekt, w którym ma powstać nowy smartwatch. Wymagania systemowe są więc takie, które dotyczą całego zestawu (patrz poniższe przykłady):

  • REQ-01: Powinien być zaprojektowany dla dorosłych użytkowników.
  • REQ-02: Powinien wyświetlać wszystkie informacje na ekranie.
  • REQ-03: Powinien być ładowalny.
  • REQ-04: Powinien posiadać przyciski lub inne mechanizmy do nawigacji użytkownika po menu.

Po zdefiniowaniu wymagań systemowych, pozostałe wymagania są dzielone na różne podsystemy.

Podążając za przykładem projektu rozwoju smartwatcha, przykłady podsystemów obejmują:

  • Podsystem 1 – Pasek
  • Podsystem 2 – Wyświetlacz
  • Podsystem 3 – Zasilanie
  • Podsystem 4 – Komunikacja
  • Podsystem 5 – Interfejs użytkownika

W związku z tym, definicja wymagań podsystemów mogłaby wyglądać następująco:

  • STRAP-01: Powinny być użyte materiały nadające się do recyklingu.
  • STRAP-02: Powinien być możliwy do zamocowania magnetycznie.
  • DISPLAY-01: Wyświetlacz powinien mieć 2 cale.
  • DISPLAY-02: Rozdzielczość powinna wynosić 368 x 448 pikseli.
  • POWER-01: Powinien być zasilany z akumulatora ładowalnego.
  • POWER-02: Żywotność baterii powinna wynosić co najmniej 48 godzin.
  • COMMS-01: Powinien być zdolny do komunikacji Bluetooth.
  • COMMS-02: Powinien być zdolny do komunikacji Wi-Fi.
  • UI-01: Powinien posiadać boczny przycisk w formie pokrętła do nawigacji po menu.

Strukturalna organizacja wymagań pozwala na łatwiejsze definiowanie, śledzenie i zarządzanie.

Smartwatch requirements example

Śledzenie wymagań

W planie zarządzania wymaganiami, śledzenie wymagań jest niezbędne; oznacza to śledzenie lub obserwację ewolucji implementacji wymagań na przestrzeni projektu.

Kontynuując przykład projektu smartwatcha, po zaprojektowaniu schematów produktu, inżynierowie i menedżerowie muszą przeprowadzić tyle spotkań, ile jest konieczne, aby zweryfikować, czy zaprojektowane rozwiązanie spełnia zdefiniowane wymagania przed przejściem do następnego kroku, w tym przypadku układu PCB.

Portal Wymagań i Systemów wspomaga to zadanie, ponieważ zapewnia widoczność wymagań zdefiniowanych bezpośrednio w Altium 365. Oznacza to, że menedżerowie i inżynierowie mogą teraz śledzić wymagania w projekcie w czasie rzeczywistym, za pomocą przeglądarki internetowej, co pozwala im dodawać komentarze, przydzielać zadania członkom zespołu i zapewniać bieżącą widoczność zmian w wymaganiach dla inżynierów projektowych, tym samym całkowicie przekształcając tradycyjny paradygmat projektowania i przeglądu.

Jak zarządzane są wymagania?

Istnieje wiele sposobów zarządzania wymaganiami. Firmy dysponujące mniejszymi zasobami finansowymi i niezależni profesjonaliści często używają prostych i niedrogich narzędzi, takich jak arkusze kalkulacyjne z kontrolą wersji, podczas gdy większe firmy zazwyczaj wykorzystują specjalistyczne oprogramowanie do zarządzania wymaganiami, takie jak DOORS, Valispace, Confluence, ReqView, wśród innych. Altium nabyło Valispace i teraz integruje narzędzie do zarządzania wymaganiami w ekosystem Altium 365 poprzez Portal Wymagań i Systemów.

Procedura Planowania Zarządzania Wymaganiami

Na podstawie poprzednich sekcji, można zdefiniować plan zarządzania wymaganiami jako zestaw działań, przez które firma definiuje, zarządza, weryfikuje i waliduje potrzeby lub wymagania interesariuszy na przestrzeni realizacji projektu, od koncepcji po komercjalizację. Następujący obraz ilustruje schemat blokowy standardowego planu zarządzania wymaganiami.

A flowchart of a standard requirements management plan
Schemat blokowy standardowego planu zarządzania wymaganiami

Wnioski

Znaczenie posiadania planu zarządzania wymaganiami

Każdy projekt inżynierski musi posiadać plan zarządzania wymaganiami, który zapewnia, że zespół deweloperski w pełni rozumie potrzeby klienta oraz wszystkie wymagania systemu i podsystemów.

Wiedzieć, jak napisać, zdefiniować i zidentyfikować wymaganie poprawnie

Podstawowe zasady muszą być przestrzegane podczas pisania i definiowania wymagań. Podobnie, istotne jest zrozumienie rodzajów wymagań, które istnieją i jak je prawidłowo klasyfikować, jak również zrozumienie, czym jest śledzenie wymagań.

Śledzenie wymagań

Wymagania zostały napisane, aby zostały spełnione, dlatego obserwowanie i śledzenie ich podczas realizacji projektu jest bardzo ważne, ponieważ im wcześniej zostanie wykryte odstępstwo lub niezgodność, tym mniejszy wpływ będzie miało na projekt.

Użyj odpowiedniego oprogramowania

Wykorzystaj portal Wymagań i Systemów, aby maksymalizować jego potencjał w połączeniu z Altium 365. Umożliwia to znacznie bliższą interakcję między inżynierią wymagań a inżynierią rozwojową, zmniejszając prawdopodobieństwo odchyleń projektowych i skracając czas rozwoju.

Zacznij korzystać z nowoczesnego i opartego na AI zarządzania wymaganiami już dziś!

About Author

About Author

Javier Alcina Espigado is an electronics engineer with more than 20 years of experience in electronic design. He has worked in different industrial sectors such as consumer electronics, automotive, security and aerospace.

He has developed his professional career as a hardware and PCB design engineer, even he has also participated in other disciplines such as firmware development for microcontrollers and management of multidisciplinary teams, such as mechanical (enclosure) design, software development, test and verification, electromagnetic compatibility which has allowed him to acquire a global knowledge in product development, from the idea or conception to its production covering all life cycling of the design.

He has participated in projects with important companies developing electronics in applications such as AR/VR headsets and he was the principal electrical engineer in a project Co-founded by European Union (Horizon 2020) in 2016 (Wardiam Perimeter), which was awarded at the Las Vegas ISC West (International Security Conference) for the best perimeter security product in 2017.

Currently, he is working as PCB Designer in a multinational company, developing electronics for aerospace industry and also provides design services as independent consultant.

Powiązane zasoby

Powiązana dokumentacja techniczna

Powrót do strony głównej
Thank you, you are now subscribed to updates.