Hi!

Witaj w kolejnym wpisie dotyczącym rozwoju tworzonej aplikacji. W poprzedniej części rozważyliśmy model w jakim będziemy tworzyli oprogramowanie. Wybrałem model kaskadowy, który w przyszłości będzie można przekształcić w model spiralny. Umożliwi to w łatwy sposób dodawanie funkcjonalności. Teraz na potrzeby konkursu założymy sobie pewne wymagania i je po prostu zrealizujemy właśnie zgodnie z modelem kaskadowym. A już w przyszłości, poza konkursem, kiedy w trakcie korzystania z tej aplikacji czegoś mi zabraknie, to to dopiszę. Jednak z takim dopisywaniem funkcjonalności oraz modelem spiralnym wiąże się Agile czyli zbiór metod, założeń tzw. zwinnego wytwarzania oprogramowania oraz Scrum jako jedna z metody zgodnych z Agile. Temat rzeka, jednak już niebawem o tym także porozmawiamy.

Specyfikacja funkcjonalna – opis wymagań, które system ma spełnić

Kiedy klient przychodzi do firmy tworzącej oprogramowanie, ma ku temu jakieś tam powody. Potrzebuje narzędzi, które programiści są w stanie mu dostarczyć. Stawia przed nimi wymagania, mające zaspokoić jego potrzeby. Dlatego w pierwszym kroku klient siada z odpowiednim zespołem i razem opracowują dokument, zawierający funkcjonalności realizowane przez powstający system. To nie jest łatwe zadanie i zajmuje stosunkowo dużo czasu. Zespół musi wdrożyć się niejako w dziedzinę, dla której oprogramowanie jest tworzone po to, aby wyciągnąć co się da od klienta, bo dla niego pewne rzeczy mogą być oczywiste, jako “osobnika z branży”, zaś dla deweloperów już niekoniecznie. Poza tym często jest problem z samym sposobem opisu. Mówi się, że jeden obrazek może zastąpić 1000 słów i to naprawdę tak jest. Ponadto przecież ten sam cel można osiągnąć pokonując różne drogi prawda? Jest dużo takich rozbieżności, używanie różnych terminologii, jeżeli z systemu ma korzystać wiele użytkowników, to każdy z nich co innego by chciał od oprogramowania i tak można wymieniać w nieskończoność. Dlatego ten etap jest kluczowym w rozwoju oprogramowania, bo ewentualne błędy potem odbijają się czkawką przez długi czas.

Czy wymagania są tylko funkcjonalne?

Oczywiście, że nie. Wymagania funkcjonalne jest to tylko część całego systemu, o którym trzeba myśleć. Poza nimi są tzw. wymagania niefunkcjonalne, definiowane jako specyfikowalne z perspektywy czarnej skrzynki jako jakościowe cechy rozwiązania. Wymagania te określają, jakie ograniczenia są nakładane na system, np. spełnienie wymogów określonej normy, integracja z istniejącymi już systemami, które nie mogą być modyfikowane pod nasze rozwiązanie, sprzęt, na którym oprogramowanie będzie miało działać… Znów wymieniać można w nieskończoność i zdecydowanie jest to temat na kolejny odcinek tej serii. Chciałem tylko rzucić temat, może i Ty mi coś ciekawego podpowiesz? 🙂

Jak definiować wymagania?

Jak mówiłem wcześniej – TO NIE JEST TAKIE PROSTE ŻEBY ZDEFINIOWAĆ WYMAGANIA! Dlaczego? Część z tych cech wymieniłem już wcześniej: każdy ma swoją wizję na świat i produkt, który ma uzyskać widzi inaczej, ciężko opisać pewne “ficzery”. Dalej, nie są one oczywiste dla wszystkich a przy okazji mocno ze sobą powiązane. Istny misz masz. Dlatego przechodzimy w opisie wymagań od ogółu do szczegółu w kolejnych krokach:

  • po wstępnych rozmowach z klientem powstaje opis słowny tego, co chce uzyskać,
  • w kolejnym etapie systematyzuje się to, co powstało w formie tekstu stosując różne zapisy, diagramy, schematy,
  • w ostatnim etapie spina się to wszystko razem w formalnie zdefiniowany dokument specyfikujący w pełni tworzone oprogramowanie.

Jakość opisu wymagań i cechy

Dlatego mówimy także o jakości sporządzonego opisu. Zastanówmy się więc, jakie cechy powinny mieć wymagania i opis, by rzeczywiście dało się coś z tego urzeźbić. Same wymagania przede wszystkim powinny być kompletne i dokładne. Mówiłem o tym wcześniej. Należy wycisnąć co się da z klienta, by rzeczywiście spełnić jego oczekiwania. Przy okazji należy pamiętać o tym, że wymagania muszą być realistyczne i osiągalne, ale tego chyba nie trzeba tłumaczyć. Dalej każde z wymagań powinno być opisane w sposób jasny oraz jednoznaczny – tutaj właśnie przydają się różnego rodzaju diagramy, które eliminują rozbieżności znaczeń języka naturalnego. Ostatnią cechą powinna być weryfikowalność stawianych wymagań. To pozwoli na uniknięcie nieprzyjemnych sytuacji typu nieuregulowanie płatności za pracę, bo produkt nie spełnia wymagań. To chyba tyle, może Ty masz jakiś pomysł?

Co zatem trzeba umieścić w dokumencie zbierający wymagania nałożone na system? Przede wszystkim należy zadbać o to, by dokument nie zaprzeczał sam w sobie w różnych jego częściach. Jeżeli tak jest, to błąd został popełniony na samym początku, przy procesie ich zbierania. Ponadto ma opisywać sposób pracy systemu, jego zachowania zewnętrzne, czy w przypadku niepożądanych lub skrajnych sytuacji. Sam dokument, który opisuje nie tylko funkcjonalności dostarczane przez system musi zawierać nakładane na oprogramowanie ograniczenia lub możliwości zmian/rozwoju aplikacji.

Dokumentacja

Oczywiście to co już zbierzemy, trzeba jakoś ładnie zebrać. W moim przypadku sporządzę dokument napisany w LaTeXu. Polecam się zapoznać z tym mega fajnym narzędziem! Odkąd zacząłem go używać, to Word służy mi jedynie do otwierania dokumentów w nim napisanych. Poza stworzeniem czegoś, co można wydrukować, są narzędzia, które pomagają podczas realizacji funkcjonalności przez programistów. Ale to znów tak obszerny temat, że powstanie o tym kolejny wpis na blogu 🙂 O tym podpowiedział mi mój kolega Michał, dzięki! Jak tylko to ogarnę sobie i będę w stanie Wam to przekazać, to na pewno to zrobię 🙂

MagazineManager – jakie są moje oczekiwania?

W końcu do sedna. Miało być krótko, a wyszło jak zwykle. Jest tyle rzeczy, którymi chce się z Wami podzielić, że wpisy się rozciągają, ale (przynajmniej mam taką nadzieję) mają przez to jakąś wartość dodaną, aniżeli tylko rozwój projektu. Zatem w kilku słowach opiszę, co chcę uzyskać, zaś mam nadzieję, że dzisiaj bądź jutro na GitHubie pojawią się pliki z dokumentacją.

Może od myślników będzie najczytelniej (to nie jest w żadnym porządku logicznym, po prostu co mi do głowy przychodzi na moment pisania tego posta):

  • dodawanie zawartości czasopisma do bazy danych przez formularz w programie
  • eksportowanie bazy danych do pliku z poziomu programu
  • tagowanie artykułów
  • wyszukiwanie artykułów
  • oznaczanie artykułu jako ulubiony
  • generowanie list zawartości do PDF

I to chyba tyle jak na razie. Na pewno wszystko znajdziecie w dokumencie, który powstanie.

Tym czasem kończę, proszę o komentarze oraz udostępnianie mojego bloga! Dzięki temu będzie nas więcej! 🙂 Miłego dnia! 🙂

P. S. Postanowiłem bardzo spontanicznie, że będę się z Wami witał w różnych językach, tak dla frajdy 🙂

A może…?

Dziękuję Ci, że dotartłeś aż do tego miejsca. Mam nadzieję, że podobał Ci się mój wpis i dowiedziałeś się z niego czegoś wartościowego. Jeżeli chcesz być poinformowanym o moich kolejnych wpisach bądź od czasu do czasu dostać wiadomość ze zbiorem jakiś ciekawych linków, zapisz się proszę do mojego newslettera. Będzie mi niesamowicie miło, jeśli to zrobisz i dołączysz do mojej społeczności!


Piotr Wachulec

Student, konsultant IT/programista, bloger, w wolnych chwilach uczy się nowych rzeczy, tańczy bachatę lub pije pyszną kawę ze znajomymi (chętnie się jej napije także z Tobą! :)). Często można go spotkać na konferencjach, meetupach lub po prostu biegnącego po stolicy na tramwaj. Jego piątka w "teście" Gallupa: Learner, Achiver, Intellection, Relator, Harmony.