Dlaczego wymagania są ważne w inżynierii oprogramowania?

W tym artykule omówimy znaczenie wymagań w tworzeniu oprogramowania i powody, dla których pomijanie etapu wymagań nie jest mądrym pomysłem podczas tworzenia aplikacji.

" Działające oprogramowanie nad obszerną dokumentacją. " To część Manifestu Agile.

Na pozór to stwierdzenie może sugerować, że wymagania są nieistotne i niegodne czasu. Niektórzy programiści i ich klienci rezygnują z odpowiedniej dokumentacji. Ale to błąd.

Zacznijmy od małego wyjaśnienia, jakie są wymagania w zakresie tworzenia oprogramowania.

Jakie są wymagania dotyczące tworzenia aplikacji?

To nie jest tak, że definicja wymagań zmienia się znacząco po zastosowaniu do tworzenia oprogramowania. Wymagania po prostu określają, jakie funkcje powinien zawierać produkt i jak te funkcje powinny działać. Ważne jest to, jak do nich podchodzisz.

Zbieranie i analizowanie wymagań jest jednym z początkowych etapów procesu tworzenia oprogramowania zarówno w metodykach Agile, jak i Waterfall. W fazie wymagań na etapie walidacji pomysłu klient i deweloper muszą uzgodnić, co dokładnie powinien zrobić produkt końcowy i jak. Wymagania w tworzeniu aplikacji są zwykle dość szczegółowe.

Jak zdefiniować wymagania dotyczące oprogramowania

W tworzeniu oprogramowania może istnieć kilka rodzajów wymagań.

Wymagania biznesowe

Dlaczego klient potrzebuje aplikacji? Na pierwszy rzut oka te informacje mogą wydawać się niepotrzebne lub nawet zbędne. W końcu masz klienta, który chce Ci zapłacić za zbudowanie aplikacji. Dlaczego miałbyś dbać o ich powody?

Cóż, jeśli jesteś dumny z tego, co robisz i starasz się tworzyć produkty wysokiej jakości, powinieneś dbać o „dlaczego” tak samo, jak o to, co i jak.

Znaczenie wymagań biznesowych polega na tym, że dostarczają wizji ostatecznego celu. Mając cel na widoku, programiści mogą ustalać priorytety. Mogą również wykorzystać swoją wiedzę fachową, aby oferować lepsze rozwiązania, aby osiągnąć te cele. Nie bez powodu analiza biznesowa jest włączana w proces rozwoju w większości firm.

Bez jasnych wymagań biznesowych można podejmować złe decyzje. Decyzje, które spowolnią rozwój, zakłócą terminy i zaowocują dodatkowymi etapami rozwoju.

Wymagania Systemowe

Istnieją dwa rodzaje wymagań: funkcjonalne i niefunkcjonalne. W uproszczeniu rozróżnienie jest następujące:

Wymagania funkcjonalne to jakie wymagania — do czego służy ten system? Jak sama nazwa wskazuje, opisują one funkcjonalność oprogramowania.

Wymagania niefunkcjonalne to wymagania dotyczące sposobu — w jaki sposób ten system zrobi to, do czego został zaprojektowany? Te wymagania opisują, jak każda funkcja powinna zachowywać się w jakich warunkach, jakie powinny być ograniczenia i tak dalej.

Te dwie rzeczy idą w parze. Wymagania niefunkcjonalne uzupełniają i definiują wymagania funkcjonalne. Na przykład wyobraźmy sobie, że tworzymy aplikację do przesyłania wiadomości.

Główne wymagania funkcjonalne w tym przypadku to:

1. Aplikacja musi mieć możliwość wysyłania wiadomości.
2. Aplikacja musi obsługiwać przesyłanie plików i multimediów.
3. Itp.

Są one dość proste i łatwo zrozumieć, dlaczego wymagania funkcjonalne są ważne: określają one funkcjonalność. W tym przykładzie wymagania niefunkcjonalne mogą wyglądać następująco :

1. Usługa musi oferować pełną funkcjonalność we wszystkich głównych przeglądarkach: Microsoft Edge, Google Chrome (ostatnie dwie wersje), Mozilla Firefox (ostatnie dwie wersje), Opera, Safari (najnowsza wersja).
2. Układy mobilne muszą być obsługiwane.
3. Itp.

Jak widzisz, wymagania funkcjonalne to w zasadzie lista funkcjonalności, które muszą być zawarte w systemie . Z drugiej strony wymagania niefunkcjonalne są specyficzne. Są one niezbędne do określenia warunków rozwoju i testowania.

To prawda, że ​​iteracyjny proces Agile pociąga za sobą możliwość wprowadzania zmian na dowolnym etapie rozwoju , ale nie oznacza to całkowitego rezygnowania z wymagań. Musisz tylko uczynić je elastycznymi.

Bez sprecyzowania dokładnych parametrów niemożliwe jest zrozumienie, czy funkcja została zaprojektowana dokładnie tak, jak powinna.

Wymagania muszą być dokładnie przeanalizowane i udokumentowane. Czemu? Ponieważ tak wiele rzeczy może pójść nie tak, jeśli tak się nie stanie.

Miecz Damoklesa o nieudokumentowanych wymaganiach

Znaczenie wymagań dotyczących oprogramowania najlepiej rozumieją specjaliści ds. zapewnienia jakości. Gdy wymagania projektowe nie są właściwie określone, największy cios otrzymują osoby odpowiedzialne za zapewnienie jakości. Wyobraź sobie, że próbujesz ustalić, czy oprogramowanie jest poprawnie zaimplementowane, bez jasnych wskazówek, co powinno robić i jak powinno to robić. To totalne szaleństwo.

Jednak ten problem dotyczy nie tylko testerów. Brak oficjalnych specyfikacji oznacza:

• Nie ma jasnego zrozumienia, co stanowi gotowy produkt, a nawet cechę.
• Klient nie wie, czego się spodziewać pod koniec rozwoju i za co płaci.
• Deweloperzy pozostają w zawieszeniu, muszą zastanawiać się nad specyfiką funkcji na podstawie tego, co zostało powiedziane i jak sami to zrozumieli.
• Robaki. Są wszędzie.

Nieudokumentowane wymagania prowadzą do nieporozumień ze wszystkich stron. Nierzadko zdarza się, że klient i programista różnie rozumieją te same terminy. Zwłaszcza jeśli mówimy o outsourcingowej firmie deweloperskiej, która nie jest zaznajomiona z działalnością klienta.

Z kolei nieporozumienie wyznacza prostą drogę do ciągłych przeróbek, zmian i poprawek błędów. Jest szansa, że ​​wszystko pójdzie zgodnie z planem bez udokumentowanych wymagań, ale jest szczupła. Zwykle łańcuch ten kończy się zakłóconymi terminami i kosztami, które przechodzą przez dach.

Aby zapewnić płynny rozwój projektu, wszystkie części produktu i proces jego rozwoju muszą być rozumiane przez każdego członka zespołu w ten sam sposób. Aby upewnić się, że programiści widzą każdą funkcję produktu dokładnie tak, jak widzi klient, tworzona jest specyfikacja wymagań oprogramowania (SRS).

Diabeł tkwi w szczegółach: co składa się na dobrą specyfikację wymagań oprogramowania?

Teraz rzeczywiste specyfikacje wymagań oprogramowania mogą być wyjątkowo szczegółowe lub mogą być tylko zarysem funkcji. Poziom szczegółowości zależy od wielu czynników.

Wymagania wysokiej jakości są łatwo zrozumiałe dla wszystkich zaangażowanych w projekt. Obejmuje to klienta, który może, ale nie musi, być dobrze zorientowany w aspektach technicznych. Niektóre firmy wymagają wyjątkowo technicznej i szczegółowej listy wymagań, podczas gdy inne preferują wymagania w kategoriach laika.

Niezależnie od tego, w jakim stopniu Twoja dokumentacja będzie wypełniona technologią, istnieją ogólne zasady zarządzania wymaganiami oprogramowania. Istnieje nawet oficjalny standard: IEEE Std 830-1998, „Recommended Practice for Software Requirements Specifications”. Oto jaki powinien być dobry SRS, zgodnie ze standardem:

• Prawidłowo . Ten jest łatwy. Poprawność SRS jest weryfikowana przez klienta i dewelopera na podstawie zawartej umowy. SRS powinien być zgodny ze specyfikacjami technicznymi i całą inną obowiązującą dokumentacją projektową.

• Jednoznaczny . Jednym z głównych celów SRS jest wyeliminowanie nieporozumień. Dlatego każda specyfikacja wymagań musi być napisana tak, aby miała tylko jedną możliwą interpretację. Nie jest niczym niezwykłym, że SRS zawiera słowniczek.

• Ukończ . Im bardziej złożona aplikacja, tym bardziej szczegółowy musi być SRS. Kompletny SRS obejmuje każdą stronę, od wymagań dotyczących wydajności po funkcjonalność. Wyznacza również pewne ograniczenia w projektowaniu. Jednak nigdy nie określa dokładnego projektu. Oferuje tylko parametry.

• Konsekwentny . Spójność wewnętrzna oznacza, że ​​żadne instrukcje w SRS nie są sprzeczne z innymi instrukcjami w tym samym SRS. Jest to kolejny powód, dla którego warto dołączyć glosariusz — aby każdy obiekt, proces i specyfikacja w dokumencie był oznaczony precyzyjnym terminem.

• Ranking według ważności i/lub stabilności . W większości przypadków istnieją wymagania obowiązkowe i wymagania, które chciałbyś spełnić. Ważne jest, aby specyfikacje wymagań oprogramowania wyraźnie oznaczały oba typy. Pomoże to programistom i kierownikom projektów podczas tworzenia planu krok po kroku dla projektu.

• Weryfikowalne . Musi istnieć sposób na przetestowanie każdego wymagania zawartego w SRS. Aby wymagania można było uznać za weryfikowalne, muszą zawierać wymierne i konkretne koncepcje.

• Modyfikowalny . Odnosi się to do struktury SRS. Aby nie zakłócać przepływu pracy projektu, gdy trzeba wprowadzić zmiany, SRS musi być jasny i łatwy do zmiany, a wymagania nie powinny się powtarzać.

• Identyfikowalny . Powinno być łatwe zidentyfikowanie źródła każdego wymagania określonego w SRS.

To są zalecenia . W rzeczywistości firmy mogą zrezygnować z niektórych z tych punktów w zależności od projektu, klienta i zespołu. Ale zawsze dobrze jest mieć jakieś wskazówki.

Wymagania są przydatne niezależnie od tego, czy specjalizujesz się w tworzeniu aplikacji na iOS i Androida, czy w tworzeniu stron internetowych. To dokumentacja ogólnego przeznaczenia. A ich wygląd zależy na ogół od programistów i ich klientów.

Ponieważ SRS powinien być łatwy do zrozumienia dla wszystkich zaangażowanych stron, najlepszy sposób ich zaprojektowania jest również dyskusyjny. Niektórzy wolą tabele, inni wolą listy. Są programiści, którzy preferują swoje specyfikacje w formie wizualnej jako diagramy przepływu danych i wykresy. Nie ma jednego właściwego sposobu na stworzenie dokumentu specyfikacji wymagań.

Wniosek

Oto najczęstsze punkty, w których przydają się wymagania dotyczące oprogramowania:

• Zrozumienie celu
• Szacowanie kosztów rozwoju
• Tworzenie kompleksowego harmonogramu
• Ustalajac priorytety

O tym, czy dokumentować wymagania, decyduje każdy programista. A wartość wymagań różni się w zależności od skali projektu. W Mind Studios wolimy mieć porządek, dlatego dokumentujemy wszystkie wymagania . Jeśli jesteś zainteresowany, jak to robimy lub masz pytania dotyczące wartości wymagań w ogóle, napisz do nas za pomocą naszego formularza kontaktowego .