Wymagania modelu użytkownika

Program Visual Studio pomaga zrozumieć, omówić i komunikować się z potrzebami użytkowników, rysując diagramy dotyczące ich działań, a część, jaką odgrywa system, pomagając im osiągnąć swoje cele. Model wymagań to zestaw tych diagramów, z których każdy koncentruje się na innym aspekcie potrzeb użytkowników.

Aby sprawdzić, które wersje programu Visual Studio obsługują każdy typ modelu, zobacz Obsługa wersji dla narzędzi do architektury i modelowania.

Model wymagań ułatwia:

• Skoncentruj się na zewnętrznym zachowaniu systemu, niezależnie od jego wewnętrznego projektu.

• Opisz potrzeby użytkowników i uczestników projektu z znacznie mniejszą niejednoznacznością niż w języku naturalnym.

• Definiowanie spójnego słownika terminów, które mogą być używane przez użytkowników, deweloperów i testerów.

• Zmniejszanie luk i niespójności w wymaganiach.

• Zmniejsz pracę wymaganą do reagowania na zmiany wymagań.

• Zaplanuj kolejność, w której zostaną opracowane funkcje.

• Użyj modeli jako podstawy do testów systemowych, aby jasno nawiązać relację między testami a wymaganiami. Gdy wymagania się zmienią, ta relacja pomaga poprawnie zaktualizować testy. Dzięki temu system spełnia nowe wymagania.

Model wymagań zapewnia największą korzyść, jeśli używasz go do skupienia dyskusji z użytkownikami lub ich przedstawicielami i ponownego przyjrzenia się na początku każdej iteracji. Nie trzeba go szczegółowo wykonywać przed napisaniem kodu. Częściowo działająca aplikacja, nawet jeśli jest bardzo uproszczona, na ogół stanowi najbardziej stymulującą podstawę do dyskusji na temat wymagań użytkowników. Model jest skutecznym sposobem podsumowania wyników tych dyskusji. Aby uzyskać więcej informacji, zobacz Używanie modeli w procesie programowania.

Uwaga

W tych tematach "system" oznacza system lub opracowywaną aplikację. Może to być duża kolekcja wielu składników oprogramowania i sprzętu; lub pojedyncza aplikacja; lub składnik oprogramowania wewnątrz większego systemu. W każdym przypadku model wymagań opisuje zachowanie widoczne spoza systemu, zarówno za pośrednictwem interfejsu użytkownika, jak i interfejsu API.

Typowe zadania

Można utworzyć kilka różnych widoków wymagań użytkowników. Każdy widok zawiera określony typ informacji. Podczas tworzenia tych widoków najlepiej jest często przenosić się między sobą. Możesz zacząć od dowolnego widoku.

Diagram lub dokument	Co opisano w modelu wymagań	Sekcja
Diagram klasy koncepcyjnej	Słownik typów używanych do opisywania wymagań; typy widoczne w interfejsie systemu.
Dodatkowe dokumenty lub elementy robocze	Kryteria wydajności, bezpieczeństwa, użyteczności i niezawodności.	Opis wymagań dotyczących jakości usług
Dodatkowe dokumenty lub elementy robocze	Ograniczenia i reguły, które nie są specyficzne dla konkretnego przypadku użycia	Wyświetlanie reguł biznesowych

Zwróć uwagę, że większość typów diagramów może być używana w innych celach. Aby zapoznać się z omówieniem typów diagramów, zobacz Tworzenie modeli dla aplikacji.

Wyświetlanie reguł biznesowych

Reguła biznesowa jest wymaganiem, który nie jest skojarzony z konkretnym przypadkiem użycia i powinien być obserwowany w całym systemie.

Wiele reguł biznesowych jest ograniczeniami relacji między klasami koncepcyjnym. Te statyczne reguły biznesowe można napisać jako komentarze skojarzone z odpowiednimi klasami na diagramie klasy koncepcyjnej. Na przykład:

Dynamiczne reguły biznesowe ograniczają dozwolone sekwencje zdarzeń. Na przykład użyjesz diagramu sekwencji lub działania, aby pokazać, że użytkownik musi się zalogować przed wykonaniem innych operacji w systemie.

Jednak wiele reguł dynamicznych może być bardziej efektywne i ogólnie określone, zastępując je regułami statycznymi. Można na przykład dodać atrybut logiczny "Zalogowany" do klasy w modelu klasy koncepcyjnej. Należy dodać wartość Log In jako postkondycję dziennika w przypadku użycia i dodać go jako warunek wstępny większości innych przypadków użycia. Takie podejście pozwala uniknąć definiowania wszystkich możliwych kombinacji sekwencji zdarzeń. Jest również bardziej elastyczny, gdy trzeba dodać nowe przypadki użycia do modelu.

Zwróć uwagę, że tutaj chodzi o sposób definiowania wymagań i że jest to niezależne od sposobu implementacji wymagań w kodzie programu.

Następujące tematy zawierają więcej informacji:

Aby dowiedzieć się więcej o	Odczyt
Jak opracowywać kod zgodny z regułami biznesowymi	Modelowanie architektury aplikacji

Opis wymagań dotyczących jakości usług

Istnieje kilka kategorii wymagań dotyczących jakości usług. Te kraje to:

• Wydajność

• Zabezpieczenia

• Użyteczność

• Niezawodność

• Niezawodność

Niektóre z tych wymagań można uwzględnić w opisach konkretnych przypadków użycia. Inne wymagania nie są specyficzne dla przypadków użycia i są najbardziej efektywnie zapisywane w osobnym dokumencie. Gdy to możliwe, warto stosować się do słownictwa zdefiniowanego przez model wymagań. W poniższym przykładzie zwróć uwagę, że głównymi słowami użytymi w wymaganiach są tytuły aktorów, przypadki użycia i klasy na poprzednich ilustracjach:

Jeśli restauracja usunie element menu, gdy klient zamawia posiłek, każdy element zamówienia, który odwołuje się do tego elementu menu, będzie wyświetlany na czerwono.

Zobacz Modelowanie architektury aplikacji, aby dowiedzieć się, jak opracowywać kod zgodny z wymaganiami dotyczącymi jakości usług.

Powiązana zawartość

• Używanie modeli w procesie tworzenia aplikacji
• Modelowanie architektury aplikacji