Analiza wymagań oprogramowania z przykładem
Charlesa Moore'a
Na przykład w kontekście aplikacji bankowych wymogiem funkcjonalnym będzie, gdy klient wybierze opcję „Wyświetl saldo”, aby mógł zobaczyć swoje ostatnie saldo konta.
Wymagania dotyczące oprogramowania mogą być również niefunkcjonalne, mogą to być wymagania dotyczące wydajności. Przykładowo wymaganiem niefunkcjonalnym jest to, że każda strona systemu powinna być widoczna dla użytkowników w ciągu 5 sekund.
Więc w zasadzie wymagania dotyczące oprogramowania to a
- Funkcjonalny lub
- Niefunkcjonalny
potrzeba które należy zaimplementować w systemie. Wymagania dotyczące oprogramowania są zwykle wyrażane w postaci stwierdzeń.
Rodzaje wymagań
- Wymagania biznesowe: Są to wymagania wysokiego poziomu, które są pobierane z analizy biznesowej projektów. Na przykład system usług bankowości mobilnej zapewnia usługi bankowe w Azji Południowo-Wschodniej. Wymagania biznesowe, które są ustalane dla Indii, to podsumowanie konta i przelew środków, podczas gdy dla Chin podsumowanie konta i płatność rachunków są ustalane jako wymagania biznesowe
| Państwo | Firma dostarczająca Funkcjonalności lub usługi bankowe |
|---|---|
| Indie | Podsumowanie konta i transfer środków |
| Chiny | Podsumowanie konta i Bill Oplata |
- Archiwymagania techniczne i projektowe:Te wymagania są bardziej szczegółowe niż wymagania biznesowe. Określają one ogólny projekt wymagany do wdrożenia wymogu biznesowego. Dla naszej organizacji edukacyjnej przypadki użycia architektonicznego i projektowego to logowanie, szczegóły kursu itp. Wymagania byłyby takie, jak pokazano poniżej.
| Bankowy przypadek użycia | Wymaganie |
|---|---|
| Bill Oplata | Ten przypadek użycia opisuje, w jaki sposób klient może zalogować się do bankowości internetowej i korzystać z Bill Możliwość płatności.
Klient będzie mógł zobaczyć pulpit nawigacyjny niezapłaconych rachunków zarejestrowanych wystawców rachunków. Może dodawać, modyfikować i usuwać szczegóły wystawcy rachunków. Klient może skonfigurować SMS-y, alerty e-mail dla różnych działań rozliczeniowych. Może zobaczyć historię wcześniej opłaconych rachunków. Aktorami rozpoczynającymi ten przypadek użycia są klienci banku lub personel pomocniczy. |
- Wymagania systemowe i integracyjne:Na najniższym poziomie mamy wymagania systemowe i integracyjne. Jest to szczegółowy opis każdego wymagania. Może być w formie historii użytkownika, które tak naprawdę opisują codzienny język biznesowy. Wymagania są w obfitych szczegółach, aby programiści mogli zacząć kodować. Oto przykład Bill Moduł płatności, w którym zostanie podany wymóg dodania pliku Biller
| Bill Oplata | wymagania |
|---|---|
| Dodaj Billers |
|
Czasami w przypadku niektórych projektów możesz nie otrzymać żadnych wymagań ani dokumentów do pracy. Jednak nadal istnieją inne źródła wymagań, które można uwzględnić w przypadku wymagań lub informacji, aby móc oprzeć na tych wymaganiach swoje oprogramowanie lub projekt testów. Zatem innymi źródłami wymagań, na których możesz polegać, są:
Inne źródła wymagań
- Transfer wiedzy od współpracowników lub pracowników już pracujących nad tym projektem
- Porozmawiaj o projekcie z analitykiem biznesowym, kierownikiem produktu, kierownikiem projektu i programistami
- Przeanalizuj poprzednią wersję systemu, która jest już zaimplementowana w systemie
- Przeanalizuj starszy dokument wymagań projektu
- Sprawdź poprzednie raporty o błędach, niektóre z nich zostały zamienione na prośby o ulepszenia, które mogą zostać zaimplementowane w aktualnej wersji
- Zajrzyj do instrukcji instalacji, jeśli jest dostępna, aby zobaczyć, jakie są wymagane instalacje
- Przeanalizuj dziedzinę lub wiedzę branżową, którą zespół próbuje wdrożyć
Niezależnie od tego, jakie źródło wymagań otrzymasz, upewnij się, że udokumentujesz je w jakiejś formie, poproś o sprawdzenie ich przez innych doświadczonych i kompetentnych członków zespołu.
Jak analizować wymagania
Rozważmy przykład systemu oprogramowania edukacyjnego, w którym student może zarejestrować się na różne kursy.
Przeanalizujmy, jak analizować wymagania. Wymagania muszą utrzymywać standardową jakość swoich wymagań, obejmują różne typy jakości wymagań
- Atomic
- Unikalnie zidentyfikowane
- Absolutna
- Spójny i jednoznaczny
- Śledzenie
- Priorytetowe
- Testowalne
Zrozummy to na przykładzie, w pokazanej tutaj tabeli są trzy kolumny,
- Pierwsza kolumna wskazuje - „wymagana jakość”
- Druga kolumna wskazuje - „złe wymaganie z pewnym problemem”
- Trzecia kolumna jest taka sama jak druga kolumna, ale – „przekształcona w dobre wymaganie”.
| Jakość wymagań | Przykład złego wymagania | Przykład dobrego wymagania |
|---|---|---|
| Atomic |
|
|
| Unikalnie zidentyfikowane | 1- Studenci będą mogli zapisać się na studia licencjackie 1- Studenci będą mogli zapisać się na studia podyplomowe |
|
| Absolutna | Użytkownik profesor loguje się do systemu, podając swoją nazwę użytkownika, hasło i inne istotne informacje | Użytkownik profesor loguje się do systemu podając swoją nazwę użytkownika, hasło i kod wydziału |
| Spójny i jednoznaczny | Student będzie miał kursy licencjackie lub kursy podyplomowe, ale nie oba. Niektóre kursy będą otwarte zarówno dla studentów studiów licencjackich, jak i podyplomowych | Student będzie miał licencjat lub absolwentów studiów podyplomowych, ale nie oba |
| Śledzenie | Zachować mapowanie informacji o uczniach na BRD req.ID? | Zachowaj informacje o uczniach — zmapowane do BRD req ID 4.1 |
| Priorytetowe | Zarejestrowany student-Priorytet 1Zachowaj informacje o użytkowniku-Priorytet 1Zapisz się na kursy-Priorytet 1Wyświetl kartę raportu-Priorytet 1 | Zarejestruj Studenta-Priorytet 1Zachowaj informacje o użytkowniku-Priorytet 2Zapisz się na kursy-Priorytet 1Wyświetl kartę raportu-Priorytet3 |
| Testowalne | Każda strona systemu ładuje się w akceptowalnym przedziale czasowym | Zarejestruj studenta i zapisz się na kursy Strony systemu załadują się w ciągu 5 sekund |
Teraz przyjrzyjmy się bliżej każdemu z tych wymagań, zaczynając od Atomic.
Atomic
Tak więc każde Twoje wymaganie powinno być atomowe, co oznacza, że powinno być na bardzo niskim poziomie szczegółowości, nie powinno być możliwe rozdzielenie go na komponenty. Tutaj zobaczymy dwa przykłady wymagań, na Atomic i jednoznacznie zidentyfikowane poziomy wymagań.
Kontynuujmy więc przykład systemu zbudowanego dla domeny edukacyjnej. Tutaj złym wymaganiem jest „Studenci będą mogli zapisać się na kursy licencjackie i podyplomowe”. Jest to złe wymaganie, ponieważ nie jest atomowe, ponieważ mówi o dwóch różnych podmiotach, kursach licencjackich i podyplomowych. Więc oczywiście nie jest to dobre wymaganie, ale złe wymaganie, więc dobrym wymaganiem korespondencyjnym byłoby oddzielenie go na dwa wymagania. Więc jedno mówi o zapisie na kursy licencjackie, a drugie o zapisie na kursy podyplomowe.
Unikalnie zidentyfikowane
Podobnie kolejną wymaganą jakością jest sprawdzenie jednoznacznie zidentyfikowanych wymagań, tutaj mamy dwa oddzielne wymagania, ale oba mają ten sam ID#1. Tak więc, jeśli odnosimy się do naszego wymagania w odniesieniu do ID#, ale nie jest jasne, do którego dokładnie wymagania odnosimy się do dokumentu lub innej części systemu, ponieważ oba mają ten sam numer ID#1. Więc oddzielając się unikalnymi identyfikatorami, tak dobrym wymogiem będzie powrót jako sekcja 1 - zapisy na kursy, i ma dwa wymagania: 1.1 id to zapis na studia licencjackie, a 1.2 id to zapis na studia podyplomowe.
Absolutna
Ponadto każde wymaganie powinno być kompletne. Na przykład tutaj złe wymaganie mówi, że „użytkownik profesor zaloguje się do systemu, podając swoją nazwę użytkownika, hasło i inne istotne informacje”. W tym przypadku inne istotne informacje nie są jasne, więc inne istotne informacje powinny być określone w dobrym wymaganiu, aby wymaganie było kompletne.
Spójny i jednoznaczny
Następnie każdy wymóg powinien być spójny i jednoznaczny, więc tutaj na przykład mamy wymagania „Student będzie miał studia licencjackie lub studia podyplomowe, ale nie jedno i drugie” to jest jeden wymóg, jest inny wymóg, który mówi: „Niektóre kursy będą być otwarte zarówno dla studentów studiów licencjackich, jak i podyplomowych”.
Problem w tym wymogu polega na tym, że od pierwszego wymogu wydaje się, że kursy są podzielone na dwie kategorie w ramach kursów magisterskich i kursów podyplomowych, a student może wybrać jedną z dwóch, ale nie obie. Ale kiedy czytasz inny wymóg, jest on sprzeczny z pierwszym wymaganiem i mówi, że niektóre kursy będą otwarte zarówno dla studentów podyplomowych, jak i licencjackich.
Oczywiste jest więc przekształcenie tego złego wymagania w dobre wymaganie, które brzmi: „Student będzie miał albo kursy licencjackie, albo kursy podyplomowe, ale nie oba”. Oznacza to, że każdy kurs będzie oznaczony jako kurs licencjacki lub kurs podyplomowy
Śledzenie
Każde wymaganie powinno być możliwe do prześledzenia, ponieważ istnieją różne poziomy wymagań. Jak już widzieliśmy, na szczycie mamy wymagania biznesowe, następnie wymagania architektoniczne i projektowe, a na końcu wymagania dotyczące integracji systemów.
Teraz, gdy przekształcamy wymagania biznesowe w wymagania architektoniczne i projektowe lub przekształcamy wymagania architektoniczne i projektowe w wymagania integracji systemów, musi istnieć możliwość śledzenia. Oznacza to, że powinniśmy być w stanie wziąć każde wymaganie biznesowe i zmapować je na odpowiadające mu jedno lub więcej wymagań architektonicznych i projektowych oprogramowania. Oto przykład złego wymagania, które mówi „Zachowaj informacje o studentach – zmapowane na identyfikator wymagania BRD?” identyfikator wymagania nie jest tutaj podany.
Tak więc przekształcenie go w dobre wymaganie mówi to samo, ale jest mapowane z identyfikatorem wymagania 4.1. Tak więc mapowanie powinno być dostępne dla każdego wymagania. W ten sam sposób, w jaki mamy wymagania mapowania wysokiego i niskiego poziomu, mapowanie odbywa się również między wymaganiami systemowymi i integracyjnymi do kodu, który implementuje to wymaganie, a także istnieje mapowanie między wymaganiami systemowymi i integracyjnymi do przypadku testowego, który testuje to konkretne wymaganie .
Tak więc ta identyfikowalność dotyczy całego projektu
Priorytetowe
| Priorytetowe | Zarejestrowany student-Priorytet 1 Zachowaj informacje o użytkowniku — priorytet 1 Zapisz się na kursy - Priorytet 1 Zobacz kartę raportu - priorytet 1 |
Zarejestruj Student-Priorytet 1 Zachowaj informacje o użytkowniku — priorytet 2 Zapisz się na kursy - Priorytet 1 Zobacz kartę zgłoszenia-priorytet3 |
Następnie każdy wymóg musi zostać priorytetyzowany, więc zespół ma wytyczne, które wymaganie można wdrożyć jako pierwsze, a które można wykonać później. Tutaj możesz zobaczyć zły priorytet: rejestracja studenta, utrzymywanie informacji o użytkowniku, a każdemu wymogowi nadano priorytet 1. Wszystko nie może mieć tego samego priorytetu, więc wymaganiu można nadać priorytet. Tak więc przykładem dobrego wymagania tutaj jest rejestracja studenta i zapisywanie się na kursy, które otrzymują najwyższy priorytet 1, podczas gdy utrzymywanie informacji o użytkowniku znajduje się poniżej priorytetu 2, a następnie mamy przeglądanie raportu arkusza ocen z priorytetem 3.
Testowalne
| Testowalne | Każda strona systemu ładuje się w akceptowalnym przedziale czasowym | Zarejestruj studenta i zapisz się na kursy Strony systemu załadują się w ciągu 5 sekund |
Każde wymaganie powinno dać się przetestować, tutaj złym wymaganiem jest to, że „każda strona systemu zostanie załadowana w akceptowalnym czasie”. Z tym wymaganiem wiążą się dwa problemy. Po pierwsze, każda strona oznacza, że może być wiele stron, co zniweczy wysiłki związane z testowaniem. Innym problemem jest to, że wyświetla się informacja, że strona zostanie załadowana w akceptowalnym przedziale czasowym. Jaki jest teraz akceptowalny przedział czasowy? Dopuszczalne dla kogo. Musimy więc przekształcić argument, którego nie można przetestować, w argument, który można przetestować, który konkretnie wskazuje, o której stronie mówimy „strony rejestrowania studentów i zapisów na kursy”, a także podany jest akceptowalny przedział czasowy, który wynosi 5 sekund.
Podsumowanie
Tak więc musimy patrzeć na każde wymaganie na odpowiednim poziomie. Na przykład, jeśli zamierzamy zbudować oprogramowanie pod kątem wymagań systemowych i integracyjnych. Musimy zajrzeć do wymagań systemowych i integracyjnych podanych w specyfikacjach wymagań oprogramowania lub historiach użytkownika i zastosować je do każdej jakości wymagania. Następnie sprawdzić, czy każde wymaganie jest atomowe, jednoznacznie zidentyfikowane i kompletne itd.
