Modelowanie — Wymagania dla użytkownika

Artykuł
06/10/2015

Microsoft Visual Studio Ultimatepomaga zrozumieć, omawiać i komunikowanie się potrzeb użytkowników przez rysowanie diagramów o ich działalności oraz część systemu odgrywa w pomagając im w osiągnięciu wyznaczonych celów.Model wymagań jest zestaw tych diagramów, z których każdy koncentruje się na inny aspekt potrzeb użytkowników.

Prezentacja video, zobacz: Modeling domeny Business.

Model wymagania pomaga:

Koncentrować się na zachowanie zewnętrznego systemu, niezależnie od jej projekt wewnętrzny.
Opis użytkowników i udziałowców musi znacznie mniej niejednoznaczności, niż można w języku naturalnym.
Definiowanie spójne Słowniczek terminów, które mogą być używane przez użytkowników, programistów i testerów.
Zmniejszyć odstępy i niespójności w wymaganiach.
Zmniejszenie pracy wymaganej do reagowania na zmiany wymagań.
Planowane zamówienia, w którym zostanie rozwinięte funkcje.
W przypadku korzystania z modeli jako podstawa w odniesieniu do badań systemu dokonywania wyraźny związek między badań i wymagania.Po zmianie wymagań, ta relacja pomaga poprawnie zaktualizować testów.To sprawia, że system spełnia wymagania nowego.

Model wymagania zapewnia największe korzyści, jeśli umożliwia fokus dyskusji z użytkowników lub ich przedstawicielami i odwiedzisz go na początku każdej iteracji.Nie trzeba zakończyć szczegółowo, przed wpisaniem kodu.Częściowo pracy aplikacji, nawet jeżeli bardzo uproszczony, ogólnie stanowi najbardziej stymulowania podstawę dyskusji wymagania użytkowników.Model jest skutecznym sposobem podsumowywania rezultaty tych dyskusji.Aby uzyskać więcej informacji, zobacz Korzystanie z modeli podczas procesu projektowania.

[!UWAGA]

W tych tematach "system" oznacza system lub aplikacja, która rozwijają się.Może to oznaczać większego zbioru wielu składników oprogramowania i sprzętu; lub pojedynczy wniosek; lub składnika oprogramowania wewnątrz większych systemu.W każdym przypadku modelu wymagania opisano zachowanie, która jest widoczna z zewnątrz systemu, poprzez interfejs użytkownika lub interfejsu API.

Typowe zadania

Można utworzyć kilka różnych widoków wymagania użytkowników.Każdy widok udostępnia określonego typu informacji.Podczas tworzenia tych widoków, najlepiej przenieść często od jednego do drugiego.Można uruchomić w dowolnym widoku.

Diagram lub dokumentu	Co opisano w modelu wymagania	Sekcja
Diagram przypadków użycia	Kto korzysta z systemu i co one z nim zrobić.	Opisujące, w jaki sposób system jest używany
Diagram koncepcyjny klasy	Słowniczek typów, które są używane do opisania wymagań; typy widoczna w interfejsie systemu.	Definiowanie warunków używany do opisania wymagań
Diagram aktywności	Przepływ pracy i informacji między czynności wykonywane przez użytkowników i systemu lub jego części.	Pokazywanie przepływ pracy między użytkownikami i systemu
Diagram sekwencji	Sekwencja interakcje między użytkownikami i systemu lub jego części.Alternatywny widok diagram aktywności.	Pokazywanie interakcje między użytkownikami i systemu
Dodatkowych dokumentów lub elementów pracy	Kryteria wydajności, bezpieczeństwa, użyteczność i niezawodność.	Jakość usługi wymagania opisujące
Dodatkowych dokumentów lub elementów pracy	Ograniczenia i zasady dotyczące konkretnego przypadku użycia	Pokazywanie reguł biznesowych

Należy zauważyć, że większość typów diagramów może służyć do innych celów.Aby uzyskać omówienie typów diagramów, zobacz Modele projektowania dla projektowania oprogramowania.Aby uzyskać podstawowe informacje na temat rysowania diagramów, zobacz Edytowanie modeli i diagramów UML.

Opisujące, w jaki sposób system jest używany

Utworzyć diagramy przypadków służą do opisywania kto korzysta z systemu i jakie używają go.Przypadek użycia stanowi cel użytkownika systemu i procedury wykonują do osiągnięcia tego celu.

Jako przykład online mączki, systemu sprzedaży musi umożliwić klientom wybrać elementy z menu i musi umożliwić zapewnienie restauracje zaktualizować w menu.Podsumowania może oglądać w diagramie przypadku użycia:

Używanie przypadków dla Customer i Restaurant

Można również wyświetlić, jak przypadek użycia składa się z mniejszych przypadkach.Na przykład zamawianie jedzenie jest częścią skupu mączki, która zawiera także płatności i dostawy:

System uczestniczy w płatności, ale nie dostarczania.

Można też wyświetlić przypadków użycia, które są włączone w zakres systemu rozwijają się.Na przykład system na rysunku nie uczestniczy w przypadku stosowania mączki dostarczenia.Pomaga to ustawić kontekstu dla pracy rozwoju.(W diagramie przypadku użycia podsystemu pojemniki można reprezentować systemu lub jego części składowe.)

Pomaga również omawiać, jakie zostaną uwzględnione w kolejnych wydaniach zespołu.Na przykład można omawiać czy, w początkowym wydania systemu płatności dla mączki są rozmieszczone bezpośrednio między restauracji i odbiorcy, zamiast przechodzenia przez system.W takim przypadku można przenieść płatności na posiłek, poza prostokątem obiad teraz System do wersji początkowej.

Diagram przypadków użycia tylko podsumowanie dotyczące przypadków użycia.Aby zapewnić bardziej szczegółowe opisy, można połączyć przypadków użycia na diagramie, aby poszczególne dokumenty, a także do innych diagramów.Aby dowiedzieć się, jak to zrobić, zobacz Porady: łączenie wariantów użycia z dokumentami i diagramami.

Rysunku diagramu przypadków użycia pomaga zespołu:

Koncentrować się na użytkowników oczekiwać do systemu, bez jest rozpraszało przez szczegóły implementacji.
Omówienia zakresu systemu lub określonej wersji systemu.

Więcej informacji można znaleźć w następujących tematach:

Aby dowiedzieć się więcej o	Odczyt
Bardziej szczegółowe informacje o sposobie tworzenia przypadkami użycia.	Diagramy przypadków użycia UML: Zalecenia
Elementy na diagramie przypadków użycia	Diagramy przypadków użycia UML: Odwołanie
Jak opracować kod z przypadkami użycia	Modelowanie architektury oprogramowania

Definiowanie warunków używany do opisania wymagań

Diagramy klas UML służy do pomagają rozwijać spójne słownika koncepcje biznesowe wykorzystywane do następujących celów:

Przez samych użytkowników do omówienia działalności, w którym działa system.
Do opisania potrzeb użytkowników, na przykład w opisy przypadków użycia, reguły biznesowe i historie użytkownika.
Rodzaje informacji wymienianych w interfejsie API systemu lub za pośrednictwem interfejsu użytkownika.
Opisy testy systemu lub przyjęcia.

Gdy są one używane w tym celu, zawartość diagram klasy UML jest nazywany diagram koncepcyjny klasy.(Jest on znany również jako modelu domeny lub analizy klasy modelu.)

Diagram koncepcyjny klasy służy do wyświetlanie tylko tych klas potrzebne w opisach wymagania, bez wyświetlania żadnego szczegółów projektu wewnętrznego systemu.Diagram nie pokazuje szczegóły projektu wewnętrznego systemu.Można byłoby nie zwykle wykazują operacji lub interfejsów koncepcyjne klas.

Na przykład można narysować tych pojęć klas systemu obiad teraz:

Klasy Menu, Order, elementu Menu kolejność elementów.

Diagram koncepcyjny klasy zapewnia słownictwa terminy, które można używać na całym modelu wymagania.Na przykład w szczegółowy opis wykorzystania przypadku nakazać mączki, zapisać:

Klient wybiera Menu z którego do konstruowania zamówienia, a następnie tworzy Kolejność elementów w zamówienia wybierając Elementy Menu z Menu.

Należy zauważyć, jak terminy używane w tym opis są nazwy klas w modelu.Diagram usuwa niejasności relacje między tych klas.Na przykład to jasno wskazuje że każdego zamówienia jest skojarzony z tylko jednego Menu.

Nieporozumień dotyczących wymagań użytkowników może być śledzone często do nieporozumień dotyczących szczegółowych znaczenie słowa.Na przykład większość restauracje będą miały wspólne zrozumienie warunków Menu i zamówienia, ale mniej oczywiste jest różnica między elementu na zamówienia i elementu menu.Wymagania omawia się z zainteresowanymi stronami działalności jest ważne, aby udostępnić te różnice.Diagram klasy jest użytecznym narzędziem w celu wyjaśnienia warunków i ich relacji.

Model koncepcyjny klasy można tworzyć podstawowe słownictwo, przez który można opisać logiki biznesowej systemu.Ale klas w oprogramowaniu zazwyczaj będzie znacznie bardziej skomplikowane niż model koncepcyjny, ponieważ implementacji należy wziąć pod uwagę kwestii takich jak wydajność, dystrybucji, elastyczność i innych czynników.Kilka różnych implementacji klasy koncepcyjne często znajdują się w jednym systemie.

Na przykład zamówienia może być przedstawiona w XML, SQL, HTML i C# w różnych częściach systemu i w różnych interfejsów między częściami.Skojarzenie między zamówienia i Menu może być reprezentowane na wiele różnych sposobów, takie jak odwołania do kodu C#, relacje w bazie danych lub wiązanie identyfikatory w formacie XML.Jednak pomimo tych różnic, model koncepcyjny zawiera ważne informacje, które ma wartość true w każdej części oprogramowania.Diagram klasy w przykładzie mówi nam że w każdym wykonaniu będzie tylko jeden Menu skojarzone z każdego zamówienia.

Rysunku diagramu klasy wymagania pomaga zespołu:

Zdefiniowanie i ujednolicenie podstawowych pojęć używanych w dyskusji potrzeb użytkowników.
Wyjaśnienie relacji między tymi warunkami.

Więcej informacji można znaleźć w następujących tematach:

Aby dowiedzieć się więcej o	Odczyt
Więcej szczegółowych informacji na temat znajdowania klas wymogów	Diagramy klas UML: Zalecenia
Elementy na diagram koncepcyjny klasy	Diagramy klas UML: Odwołanie
Jak opracować kod koncepcyjny klas	Modelowanie architektury oprogramowania

Na diagramie klasy koncepcyjne zazwyczaj nie jest użyteczne umieszczenie strzałki na stowarzyszenia do reprezentowania zdolności żeglugowej.Wynika to z diagramu nie stanowi implementację.Skojarzenia reprezentują relacje między obiektami w świecie rzeczywistym.Następujące Visual Studio rozszerzenia należy strzałki kierunkowe innych niż domyślne: próbki: funkcje modelowania domeny UML.

Pokazywanie reguł biznesowych

Reguła biznesowa jest wymóg, który nie jest skojarzony z konkretnego przypadku użycia i powinna być przestrzegana w całym systemie.

Wiele reguł biznesowych są ograniczenia na relacje między koncepcyjne klas.Można napisać te statycznereguł biznesowych jako komentarze skojarzone z odpowiednich klas na diagram koncepcyjny klasy.Na przykład:

Reguła w komentarz dołączonym do klasy Order.

Reguły biznesowe dynamiczne ograniczyć dopuszczalne sekwencji zdarzeń.Na przykład użyć diagramu sekwencji lub działania, aby pokazać, że użytkownik musi zalogować przed wykonaniem innych czynności w systemie.

Jednak wiele reguł dynamicznych można bardziej efektywnie i tu podawana przez zamianę zasady statyczne.Na przykład można dodać atrybut logiczny rejestrowane w do klasy w model koncepcyjny klasy.Czy dodać rejestrowane w jako postcondition dziennika w przypadku użycia i dodać go jako warunku wstępnego większości innych przypadków użycia.Podejście to pozwala uniknąć definiowania wszystkie możliwe kombinacje sekwencji zdarzeń.Jest także bardziej elastyczne, gdy zachodzi konieczność dodania nowych przypadków użycia do modelu.

Należy zauważyć, że tutaj wybór jest o jak określenie wymagań i to niezależnie od sposobu wdrożenia wymogów w kodzie programu.

Więcej informacji można znaleźć w następujących tematach:

Aby dowiedzieć się więcej o	Odczyt
Bardziej szczegółowe informacje na temat znajdowania i rejestrowania reguł biznesowych statyczne	Diagramy klas UML: Zalecenia
Elementy na diagram koncepcyjny klasy	Diagramy klas UML: Odwołanie
Jak opracować kod, który przestrzega reguł biznesowych	Modelowanie architektury oprogramowania

Jakość usługi wymagania opisujące

Istnieje kilka kategorii jakości usługi wymóg.Obejmują one następujące:

Wydajność
Zabezpieczenia
Użyteczność
Niezawodność
Niezawodności

Niektóre z tych wymagań może zawierać w opisach przypadków użycia określonego.Inne wymagania nie są specyficzne dla przypadkami użycia i najbardziej skutecznie są zapisywane w oddzielnym dokumencie.Można, jest przydatne do słownika, zdefiniowane przez model wymagania.W poniższym przykładzie zauważyć głównych wyrazy użyte w wymóg tytuły podmiotów, przypadki użycia i klas w poprzednim ilustracji:

Jeśli restaurację usuwa element Menu, podczas, gdy klient jest zamawiania posiłek, dowolny element zamówienia, który odnosi się do tego elementu Menu będą wyświetlane w kolorze czerwonym.

Więcej informacji można znaleźć w następujących tematach:

Aby dowiedzieć się więcej o	Odczyt
Bardziej szczegółowe informacje o jakości usługi wymagania nagrywania	Guidelines for Defining Quality of Service Requirements
Dołączanie dodatkowych dokumentów przypadkami użycia	Porady: łączenie wariantów użycia z dokumentami i diagramami
Jak opracowanie kodu, który przestrzega jakości wymagania usługi	Modelowanie architektury oprogramowania

Pokazywanie przepływ pracy między użytkownikami i systemu

Diagram aktywności służy do pokazywania przepływu pracy między przypadkami użycia różnych.Często najlepiej rozpocząć modelu wymagania od rysunku diagramu aktywności zawierający główne zadania, które użytkownicy wykonują - zarówno z systemem, jak i poza nią.

Na przykład:

Działania z trzech akcji i pętli.

Można narysować diagramy przypadków użycia i diagramy aktywności, aby wyświetlić te same informacje w różnych widokach.Diagram przypadków użycia jest bardziej skutecznie zagnieżdżanie mniejszych działań w ramach działalności większe, ale nie pokazuje przepływ pracy.Na przykład:

Używanie przypadków dla poprzednich akcji

Można również użyć diagramy aktywności do zobrazowania algorytmów w oprogramowaniu, ale, gdy dla procesu biznesowego, skupić się na działania, które są widoczne spoza systemu diagramy ogłoszenia.

Więcej informacji można znaleźć w następujących tematach:

Aby dowiedzieć się więcej o	Odczyt
Więcej informacji na temat definiowania przepływów pracy firmy	Diagramy aktywności UML: Zalecenia
Elementy na diagramie aktywności	Diagramy aktywności UML: Odnośnik
Jak opracować kod z diagramy aktywności	Modelowanie architektury oprogramowania

Pokazywanie interakcje między użytkownikami i systemu

Diagram sekwencji służy do pokazywania wymiany komunikatów między systemem i podmiotów zewnętrznych lub między częściami systemu.Zapewnia to widok kroki w przypadku użycia, bardzo wyraźnie pokazujący sekwencji interakcje.Diagramy sekwencji są szczególnie przydatne, jeżeli istnieją, że interakcja kilka stron, w przypadku użycia, a także, gdy system ma interfejs API.

Na przykład:

Diagram sekwencji z systemu i uczestników.

Jedną z zalet diagramy sekwencji jest łatwe zobaczyć, jakie komunikaty przychodzą do systemu, które są konstruowania.Do projektowania systemu, Zastąp pojedynczej linii życia systemu oddzielnych linii życia dla każdego z jego składników i następnie pokazywać interakcje między nimi w odpowiedzi na każdą przychodzącą wiadomość.

Więcej informacji można znaleźć w następujących tematach:

Aby dowiedzieć się więcej o	Odczyt
Więcej informacji na temat sposobu definiowania interakcje	Diagramy sekwencyjne UML: Zalecenia
Elementy na diagramie sekwencji	Diagramy sekwencji UML: Odwołanie
Jak opracować kod z diagramy sekwencji	Modelowanie architektury oprogramowania

Aby zmniejszyć niespójności przy użyciu modelu

Tworzenie modelu zwykle powoduje znaczne ograniczenie niespójności i niejasności w wymagania użytkowników.Różne zainteresowane strony mają często różne rozumienie świecie biznesu, w którym działa system.Dlatego pierwsze zadanie jest usunięcia rozbieżności między klientów.

Można znaleźć wiele pytań dotyczących domeny business naturalnie powstać podczas tworzenia modelu.Umieszczając te pytania użytkowników, zmniejszy się potrzeba zmiany na późniejszym etapie w projekcie.Oto niektóre szczególne pytania, zadaj sobie pytanie, na początku, a następnie zapytaj zainteresowanych stron firmy czy odpowiedź jest niejasne:

Dla każdej klasy w modelu wymagania poprosić "co przypadek użycia tworzy wystąpienia tej klasy?" Na przykład w online usługi zamawiania mączki, może poprosić, "co przypadek użycia tworzy wystąpienia klasy Menu w restauracji?" Prowadziłoby to do dyskusji, w jaki sposób nowej restauracji jest zarejestrowany w usłudze i przyczynia się do jego menu.Podobne pytania można zapytać o co tworzy lub zmienia atrybuty i skojarzeń.
Dla każdego przypadku użycia w modelu wymagania próby opisują wynik lub postcondition każdego przypadku użycia słowa, świadczone przez diagramy klas.Jest ona często przydatne wyświetlić efekt przypadek użycia szkicując wystąpienia klas przed i po wystąpienie przypadku użycia.Na przykład jeśli postcondition przypadku użycia mówi "element menu jest dodawane do zamówienia klienta", szkic wystąpień klas zamówienia i elementu Menu.Pokaż skutków przypadek użycia, takie jak nowe łącze lub nowy obiekt w innym kolorze lub w nowy rysunek.Prowadzi to często dyskusje na temat jakie informacje są niezbędne w modelu.Chociaż klas wymagania nie dotyczą bezpośrednio z implementacją, opisują informacje potrzebne do przechowywania i transmitowania systemu.
Poproś o ograniczeniach na atrybuty i stowarzyszeń, zwłaszcza ograniczenia obejmujące więcej niż jeden atrybut lub stowarzyszenia.
Zapytaj o prawidłowych i nieprawidłowych sekwencji przypadków użycia, diagramy sekwencji lub działalności do zilustrowania ich rysowania.

Poprzez zbadanie relacji między widokami, które zapewniają różne diagramy, można szybko zrozumieć główne pojęcia, z którymi pracy użytkowników i ich zrozumienie potrzebują z systemu pomocy.Również osiągnięcia lepszego zrozumienia wymagań, jakie zainteresowane strony są najmniej niektóre informacje.Można zaplanować do rozwijania tych funkcji, co najmniej w formie uproszczonej na wczesnym etapie projektu, aby umożliwić użytkownikom poeksperymentować z nimi.