Udostępnij za pośrednictwem

Opracowywanie wymagań

  • Artykuł

Wymagania opisują, czego oczekiwać od produktu zainteresowanych stron.Wymagań należy wyrazić w kategoriach, które pozwalają łatwo zostać omówione z zainteresowanych stron biznesowych, za pomocą słownictwa i pojęć domeny business.Wymagania nie powinny omówienia ani zależą od wykonania.Wymagania obejmują nie tylko behawioralnych i jakość usługi oczekiwania użytkowników, ale również ograniczenia ustawowe i norm handlowych.

Wymagania są tworzone w programie TFS, osiągnąć następujące korzyści:

  • Zweryfikuj, że zostały spełnione wymogi łącząc je do testowania przypadkach.

  • Monitorowanie postępów w realizacji wdrażające wymagania, łącząc je z elementów pracy zadania.

  • Wymagania do ogólnej struktury i bardziej szczegółowych wymagań, tak, że można je łatwiej zarządzać i tak, że sprawozdania z postępu prac można podsumować informacje.

  • Model wymagania w Visual Studio Ultimate, łączenie elementów modelu do wymogów w Team Foundation Server.

W tym temacie nie próbuje zreplikować bardzo duży zbiór literatury, dostępnej na temat określanie wymagań dotyczących.Zamiast tego, skupia się na aspekty, które są ważne przy użyciu Visual Studio narzędzi w sposób, który odpowiada CMMI.Aby uzyskać więcej informacji o bibliotece CMMI, zobacz Podstawy CMMI.

Działań, które są opisane w tym temacie, podobnie jak wszelkie działania na rzecz rozwoju, nie powinno być przeprowadzone w dokładna kolejność.Opracowanie modelu domeny podczas pisania scenariuszy ponieważ jedno działanie pomoże że poprawić innej działalności.Opracowanie scenariuszy jako czas kodowania ich podejścia.RSS doświadczenia z kodem, który został napisany i wykazać scenariusze, które nie zostały jeszcze mają być wprowadzone w życie.

Kiedy należy rozwijać wymagania

TFS obsługuje iteracyjne pracy, i praktyka ta jest najbardziej efektywne, gdy początku iteracji są używane do uzyskania opinii od potencjalnych użytkowników i innych zainteresowanych stron.Ta opinia może służyć do polepszenia wymogów, które zostały określone dla przyszłych iteracji.Skutkuje to produkt, który jest znacznie bardziej skuteczny w jej ostatecznym instalacji niż produkt, który jest rozwijany w tym samym okresie, bez jakiejkolwiek próby użytkownika.Jeśli projekt jest jednym ze składników wśród wielu do większego programu, początku integracji z innymi składnikami pozwala architektów program poprawy ogólnej produktu.

Elastyczność ta musi być zrównoważone wynikająca z konieczności dawać wiążące zobowiązania do klientów lub partnerów w projektach równoległych.

W zakresie kontrolowanych w związku z tym, wymagania są opracowane i Elegancja trwania całego projektu.Ponieważ szczegółowe wymagania mogą ulec zmianie podczas projektu, ich określenia w pełni, zanim właściwe wprowadzenie w życie będzie skutkować niewłaściwie wykorzystane wysiłku.

  • W iteracji 0 należy opracować zestaw wymagań, które opisują podstawowych cech ze szczegółowymi informacjami o tyle do utworzenia planu produktu.Plan produktu przypisuje wymagania do iteracji i stwierdza, jakie wymagania zostaną spełnione na końcu każdej iteracji.Tworzenie modelu domen głównych koncepcji i działań i definiowania słownictwa używanego dla tych koncepcji zarówno w dyskusji z użytkownikami i wykonania.Określenie wymagań szerokie, które przenikają wszystkich funkcji, takich jak zabezpieczenia i inne jakość usługi.

  • W pobliżu lub na początku każdej iteracji rozwijać wymagania dotyczące tych cech bardziej szczegółowo.Określają czynności, które użytkownicy postępują, określając je za pomocą diagramy aktywności lub sekwencji.Zdefiniować, co się dzieje w wyjątkowych przypadkach.

  • Sprawdź, czy tak często, jak to możliwe wszystkie wymagania, które zostały wdrożone.Wymagania wszechobecne, takich jak zabezpieczenia, należy zweryfikować z testów, które są rozszerzone dla każdej nowej funkcji.Jeśli to możliwe automatyzować testy, ponieważ automatyczne testy mogą być wykonywane w sposób ciągły.

Zarządzanie zmianami wymagań

Poniższe wskazówki umożliwiają działają przyrostowego procesu podczas monitorowania go do spełnienia wymagań CMMI.

  • Nie należy zmieniać wymagania, które są ustawione dla iteracji.W rzadkich przypadkach nagłych zmian w okolicznościach trzeba anulować iteracji, przegląd planu produktu i rozpocząć nowy iteracji.

  • Poszukaj niepewności w wymaganiach.Spróbuj ułożyć planu tak, aby doświadczenia użytkownika z początku iteracji daje informacji, który zmniejsza niepewności.

  • Elementów pracy żądania zmiany na rekord żądania umożliwia zmianę zachowania, która została już dokonana, chyba że poprawy żądana jest już częścią planu.Połączyć każdego żądania zmiany elementów pracy stosownych wymaganiach.

  • Opisz wniosków o zmianę podczas recenzowania produktu przed każdej iteracji.Badanie wpływu na wniosek w sprawie projektów zależnych i użytkowników i oszacowanie kosztów w odniesieniu do zmian w kodzie.W przypadku przyjęcia żądania zmiany aktualizacji zapotrzebowania.

  • Zaktualizuj testy odpowiadają typowi, każda zmiana wymagań.

  • Wyznaczenia daty (na przykład po iteracji, 2 lub 3) po zmiany wymagań, które musi być znacznie bardziej zdecydowanie uzasadnione.Jeśli projekt dotyczy płatniczej klienta, jest to data klienta zatwierdzić plan bazowy zestaw wymagań i przełączyć się z godzinowa płatność do formatu ceny ustalonej.

  • Użyj elementów pracy błędów do rekordu, wprowadzone w życie, które nie będzie działać zgodnie z wymogami jawny lub niejawny zachowanie.W przypadku gdy jest to praktyczne, należy utworzyć nowe badań, które byłyby złowionych błąd.

Napisze instrukcję wizji

Omówienia zespołu_gotowego z zespołem i wyświetlić je na portalu sieci Web projektu dla Team Foundation Server.

Oświadczenie o wizji jest przyniesie krótkie podsumowanie co korzyści produktu.Co użytkownicy będą mogli zrobić, że nie może przeprowadzić przed?Zespołu_gotowego pomaga wyjaśnienie zakresu produktu.

Jeśli produkt już istnieje, należy napisać zespołu_gotowego dla tej wersji.Co użytkownicy produktu będzie można zrobić, że nie może przeprowadzić przed?

Pisanie scenariuszy

Praca z klienta i innych zainteresowanych stron do tworzenia scenariuszy i wprowadzić je jako elementów pracy zapotrzebowania, z pola Typ wymagania do scenariusza.

Sprawa scenariusz lub użytkowania jest narracji, który opisuje sekwencję zdarzeń, pokazuje jak uzyskuje się konkretnego celu i zazwyczaj wymaga interakcji między osoby lub organizacje i komputery.

Nadaj opisowy tytuł, która wyraźnie odróżnia go od innych podczas wyświetlania na liście.Upewnij się, stwierdzono głównego uczestnika lub uczestników i że ich celem jest wyczyszczone.Na przykład będzie to dobra nazwa:

Klient kupuje posiłek.

Można napisać scenariusz w następujących formach.Czasami może przyczynić się do więcej niż jeden formularz:

  • Jeden lub dwa zdania w opisie przedmiotu pracy:

    Odbiorca orders posiłek w witrynie sieci Web i płaci za pomocą karty kredytowej.Kolejność jest przekazywana do restauracji, w której przygotowuje i dostarcza posiłek.

  • Ponumerowane kroki widoczne w opisie przedmiotu pracy:

    1. Klient odwiedza stronę internetową i utworzy zamówienie na posiłek.

    2. Witryna sieci Web przekierowuje klienta do witryny płatności, aby dokonać płatności.

    3. Kolejność jest dodawany do listy pracy restauracji.

    4. Restauracji przygotowuje i dostarcza posiłek.

  • Seria ujęć.Seria ujęć jest zasadniczo pasek animowany, który opowiada.W programie PowerPoint można wyciągnąć go.Dołącz plik serii ujęć do elementu pracy wymóg lub przekazać plik do portalu zespołu i dodać hiperłącze do elementu pracy.

    Serii ujęć jest szczególnie przydatna do wyświetlania interakcji użytkownika.Ale dla scenariusza biznesowego, zaleca się stosowanie szkic stylu, który sprawia, że jasne, że nie jest to ostateczny projekt dla interfejsu użytkownika.

  • Wymaganie dokumentów.Wymaganie dokumentów daje swobody świadczenia odpowiedni poziom szczegółów dla każdego zapotrzebowania.Jeśli użytkownik zdecyduje się użyć dokumentów, tworzenie dokumentu programu Word dla każdego zapotrzebowania i dołączyć dokument do elementu pracy wymóg lub przekazać plik do portalu zespołu i Dodaj hiperłącze do elementu pracy.

  • Diagram sekwencji zunifikowany Markup Language (UML).Diagram sekwencji jest szczególnie przydatne w przypadku, gdy kilka stron interakcji.Na przykład zamawiania posiłku wymaga klient, witryny sieci DinnerNow Web, system płatności i restauracji, współdziałać w określonej kolejności.Narysuj diagram sekwencji w modelu UML, sprawdź to w Team Foundation Serveri wprowadź łącze w elemencie pracy zapotrzebowania.Aby uzyskać więcej informacji, zobacz Diagramy sekwencyjne UML: Zalecenia.

Konkretne scenariusze

Zacznij od pisania scenariuszy szczególnych, które należy wykonać z określonym zestawem aktorów w określonej kolejności.Na przykład "Carlos zamówień chleba pizza i czosnku na stronie internetowej DinnerNow.Witryna sieci Web przekierowuje Carlos usługi płatności banku Woodgrove.Czwarty kawy przygotowuje pizza i dostarcza je."

Konkretne scenariusze pomóc przewidzieć system w użyciu i są najbardziej przydatne, gdy najpierw zbadać funkcja.

Może być również przydatne do tworzenia nazwanych autorstwa opisujących tła i inne działania osób i organizacji.Artur może pomieścić bez wygładzania i używa kawiarence internetowej; Wendy mieszka na ogrodzonym; Sanjay zamówienia posiłków żoną w jej pracy; Firma Contoso działa sieć 2 000 restauracji na całym świecie; Czwarty kawy prowadzony jest przez kilka, który dostarczyć na rowerze.

Bardziej ogólny scenariuszy, w których są zapisywane pod względem "klienta," "element menu," i tak dalej może być wygodne, ale są mniej prawdopodobne, aby doprowadzić do odkrycia przydatnych funkcji.

Poziomy szczegółów

W iteracji 0 Napisz kilka scenariuszy ważne w pewnych szczegółach, ale zapisu większości scenariuszy w konspekcie.Gdy zbliża się iteracji w którym danym scenariuszu ma być w pełni lub częściowo zaimplementowany, Dodaj więcej szczegółów.

Gdy uwzględni się po raz pierwszy scenariusz, może być przydatne do opisania kontekście firmy nawet aspektów, w których produkt przenosi żadna część.Na przykład, opisuje się metodę DinnerNow dostawy: czy każda z restauracji organizowanie własnych dostaw lub czy DinnerNow uruchomić usługę dostawy?Odpowiedzi na takie pytania przewidują przydatne kontekstu deweloperami.

Bardziej szczegółowe scenariuszy, które rozwijają się na początku iteracji można opisać interakcje interfejsu użytkownika i ujęć można pokazać układu interfejsu użytkownika.

Organizowanie scenariusze

Scenariuszy można organizować przy użyciu następujących metod:

  • Narysuj diagramy przypadków użycia, które pokazują Każdy scenariusz, jak w przypadku użycia.Ta metoda jest zalecana, ponieważ sprawia, że scenariusze bardzo łatwo przedstawić i dyskutować.Aby uzyskać więcej informacji, zobacz Diagramy przypadków użycia UML: Zalecenia.

    • Każdy przypadek użycia łącze do elementu pracy, która definiuje scenariusza.Aby uzyskać więcej informacji, zobacz Łączenie elementów modeli i elementów pracy.

    • Rysuj relacji rozszerzenie, aby pokazać, że jeden scenariusz jest odmianą innego.Na przykład "Klient określa osobną płatność i adresów dostawy" to rozszerzenie podstawowego "Odbiorca dokonuje zamówienia" Diagram przypadków użycia.Rozszerzenia są szczególnie przydatne do oddzielenia scenariuszy, które będą realizowane w późniejszym iteracji.

    • Rysuj obejmuje relacji do oddzielenia procedury, takie jak "Klient loguje się," który jest wspólny dla kilku przypadków użycia.

    • Narysować relacji generalizacji między Ogólne scenariusze, takie jak "Klient płaci" i określonego warianty, takie jak "Klient płaci za pomocą karty."

  • Tworzenie połączeń między elementów pracy scenariusza nadrzędny podrzędny.Można wyświetlić hierarchię w Team Explorer.Aby uzyskać więcej informacji, zobacz Przyporządkowywanie wymagań do planu produktu.

Model domeny business

Utworzenie modelu UML, który zawiera opis podstawowych rodzajów działalności i koncepcje, które są zaangażowane w zakresie stosowania produktu.Warunki, które są zdefiniowane w tym modelu jako "wszechobecne język", należy użyć w scenariuszach, w dyskusji z zainteresowanymi stronami, w interfejsie użytkownika i wszelkie podręczniki użytkownika i w sam kod.

Wiele wymagań nie zostały jawnie określone przez klienta i zrozumienia wymagania sprzętowe zależy od zrozumienia domeny business, czyli kontekst, w którym produkt będzie działać.Część pracy w nieznanym domeny gromadzenia wymagań jest zatem o zdobycie wiedzy tego kontekstu.Po ustaleniu tego rodzaju wiedza może służyć na więcej niż jednym projekcie.

Zapisz model kontroli wersji.

Aby uzyskać więcej informacji, zobacz Modelowanie — Wymagania dla użytkownika.

Modelowania zachowań

Narysuj diagramy aktywności Podsumowanie scenariuszy.Tory służą do grupowania akcje, które są wykonywane przez różne podmioty.Aby uzyskać więcej informacji, zobacz Diagramy aktywności UML: Zalecenia.

Chociaż zazwyczaj scenariusz opisuje określonej kolejności zdarzeń, diagram aktywności pokazuje wszystkie możliwości.Rysunek diagramie aktywności może monitować myśleć o alternatywne sekwencje i poprosić klientów biznesowych, co powinno się zdarzyć w tych przypadkach.

Na następującej ilustracji pokazano prosty przykład diagram aktywności.

Działania z trzech akcji i pętli.

W przypadku gdy wymiany wiadomości jest ważne, może być bardziej efektywne użycie diagram sekwencji zawierającą kształt linia życia dla każdego aktora i składnika głównego produktu.

Diagramy przypadków użycia umożliwiają podsumować różnych przepływach czynności, która obsługuje Twój produkt.Każdy węzeł na diagramie reprezentuje jedną serię interakcje między użytkownikami i aplikacji w dążeniu do osiągnięcia celu określonego użytkownika.Wspólne sekwencje i opcjonalne rozszerzenia może również czynnik do osobnego używania węzłów case.Aby uzyskać więcej informacji, zobacz Diagramy przypadków użycia UML: Zalecenia.

Na następującej ilustracji pokazano prosty przykład diagramu przypadków użycia.

Używanie przypadków dla poprzednich akcji

Pojęcia dotyczące modelowania

Narysuj diagramy klas domeny do opisania ważnych obiektów i ich związki, które są wymienione w scenariuszach.Na przykład DinnerNow model przedstawia restauracji, Menu, zamówienia, element Menu i tak dalej.Aby uzyskać więcej informacji, zobacz Diagramy klas UML: Zalecenia.

Etykiety role (kończy się) relacje z nazwy i cardinalities.

Na diagramie klasy domeny nie zazwyczaj dołączyć operacje do klas.W modelu domeny diagramy aktywności opisują stan.Przypisanie odpowiedzialności do klas program jest częścią prac rozwojowych.

Na następującej ilustracji pokazano prosty przykład diagram klasy.

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

Ograniczenia statyczne

Dodaj do diagramów klas ograniczenia, które regulują atrybutów i relacji.Na przykład elementy na zamówienie musi wszystkie pochodzą z tej samej restauracji.Te typy reguł są ważne dla projektowania produktu.

Spójność modelu

Upewnij się, że model i scenariusze są zgodne.Jest jednym z najbardziej zaawansowanych zastosowań dla modelu rozwiązania niejasności.

  • Opisy scenariusz używać terminów, które są zdefiniowane w modelu i są zgodne z relacji, które definiuje.Jeśli model definiuje elementy menu, scenariusze nie powinny dotyczyć tak samo jak produkty.Diagram klas pokazuje, że element menu należy dokładnie jedno menu, scenariusze nie należy mówić udostępniania element menu do innego.

  • Każdy scenariusz zawiera opis serii kroków, które są dozwolone przez diagramy aktywności.

  • Scenariusze lub działań opisują jak każdej klasy i relacji na diagramie klasy jest tworzony i zniszczone.Na przykład jaki scenariusz tworzy element menu?Kiedy jest niszczony zamówienia?

Opracowanie jakość usługi

Tworzenie elementów pracy, które określają jakość usługi.Zestaw pole Typ wymagania jakości usługi.

Jakość usługi lub współzależności funkcjonalnych wymagania obejmują wydajności, użyteczności, niezawodność, dostępność, integralność danych, zabezpieczeń, przystępność, łatwość serwisowania i upgradeability, wytłaczania, projekt i dopasowanie i zakończenia.

Należy wziąć pod uwagę każdej z tych kategorii dla każdego scenariusza.

Tytuł każdej jakości wymagania usługi należy przechwycić jego definicji przedstawiając kontekst, akcji i pomiar.Na przykład, można utworzyć następujące wymagania: "Podczas przeszukiwania katalogu, zwracają wyniki wyszukiwania w mniej niż trzy sekundy".

Ponadto jest przydatne do przechwytywania bardziej szczegółowo wyjaśniający, dlaczego konieczne jest wymaganie.Opisz Dlaczego persona wartości zapotrzebowania i dlaczego wymagany jest ten poziom usług.Dostarcza kontekst i uzasadnienie.Wyjaśnienie to może obejmować ryzyko przydatnych informacji danych z badań rynku, grupy fokusowej klienta lub studiów przydatności; bilety/pomocy technicznej raportów; lub inne niepotwierdzonych.

Łącze jakości wymagania usługi do każdego scenariusza (wymaganie element pracy), że ma wpływ jakości usług.Łączenie związanych z elementów pracy umożliwia użytkownikom Team Foundation Server do śledzenia wymagania zależnego.Kwerendy i raporty można pokazać, jak jakość usługi wpływają na wymagania funkcjonalne, które są przechwytywane jako scenariuszy.

Przegląd wymagań

Gdy wymogi zostały zapisane lub zaktualizowane, powinny one być zweryfikowane przez odpowiednie podmioty zapewniające, że odpowiednio opisują wszystkich interakcji użytkownika z produktem.Wspólne zainteresowane strony mogą obejmować ekspert przedmiot, analityk biznesowy i Architekt doświadczenia użytkownika.Scenariusze są sprawdzane do zapewnienia, że mogą być one wykonywane w programie project bez żadnych nieporozumień lub problemów.Jeśli nanosi się żadnych problemów, scenariusze musi zostać ustalona, tak aby były prawidłowe po zakończeniu tego działania.

Tworzenie elementu pracy recenzji do śledzenia przeglądu.Ten element zawiera ważne dowody na standardową metodę oceny CMMI oceny procesu poprawy (krewetki) i może zapewnić dobrym źródłem informacji do analizy przyczyn w przyszłości.

Opisz poszczególne scenariusze dla następujących właściwości:

  • Scenariusz jest napisany w kontekście co zadanie użytkownicy muszą wykonać, co już wiedzą i jak się spodziewać do interakcji z produktem.

  • Scenariusz opisuje problem i nie jest zakryta przez proponowane rozwiązania tego problemu.

  • Wszystkie interakcje istotne użytkownika z produktem są identyfikowane.

  • Przedmiot ekspertów, analityk biznesowy, architekt doświadczenia użytkownika przeglądu każdego scenariusza w ramach projektu do sprawdzania poprawności pomyślnie wprowadzone wszystkie scenariusze.Jeśli scenariusz jest nieprawidłowy, jest to zmienione tak, że jest ona prawidłowa.

  • Scenariusz może być zaimplementowany z dostępnych technik, narzędzia i zasoby i w ramach budżetu i harmonogramu.

  • Scenariusz złożony jest z jednego interpretacji, który jest łatwo zrozumiały.

  • Scenariusz nie powoduje konfliktu z innym scenariuszu.

  • Scenariusz jest sprawdzalne.

Walidacja

Plan wdrożenia wersji beta produktu w jego środowisku pracy przed jego ostatecznej wersji.Zaplanować wymagania dotyczące, na podstawie opinii zainteresowanych wdrażania tej aktualizacji.

"Zatwierdzenie" oznacza zapewnienie, że produkt spełnia jego zamierzonego zastosowania w jego środowisku operacyjnym.W MSF dla CMMI sprawdzania poprawności uzyskuje się poprzez wykazanie działanie oprogramowanie zainteresowanym stronom na końcu każdej iteracji w trakcie realizacji projektu.Harmonogram rozmieszczone w taki sposób, że dotyczy że są karmione Wstecz, aby deweloperzy od początku demonstracje mogą być rozpatrywane w planie dla pozostałych iteracji.

Uzyskanie PRAWDA sprawdzania poprawności, produkt musi nie tylko można uruchomić w demonstracji lub symulowane kontekstu.Jest tak dalece jak to jest możliwe, powinny być badane w warunkach rzeczywistych.

Procedury kontroli i edycji wymagania

Scenariusz i jakość usługi, które prowadzą do większości zadań rozwoju, mogą być kontrolowane przez przy użyciu kwerendy wymagań klienta.Jeśli wolisz wyświetlić wszystkie wymagania, możesz napisać kwerendę , które zwraca wszystkie elementy pracy z wymogu typu elementu pracy.Zestaw kolumn wyniku pokazanie ścieżki iteracji.

Zespół należy utworzyć większość wymagań w iteracji początku projektu.Zostaną dodane nowe wymagania i innych dostosować do własnych opinii jest uzyskane z wczesnych wersji.

Dodatkowe zasoby

Aby uzyskać więcej informacji, zobacz następujące zasoby sieci Web: