Inżynieria oprogramowania. Wykład 6 Analiza i specyfikowanie wymagań

Transkrypt

1 Inżynieria oprogramowania Wykład 6 Analiza i specyfikowanie wymagań

2 Proces inżynierii wymagań Feasibility Study Feasibility Report Requirements Analysis System Models Requirements Definition Definition of Requirements Requirements Specification Requirements Document Specification of Requirements

3 Analiza wymagań Metody modelowania danych i projektowania: Schematy przepływu danych Schematy encja-związek Słowniki danych Modele obiektów Wiele z tych metod zaciera różnicy między analizy i projektowania.

4 Model encja-związek (Entity-relationship diagrams, ERD) Metodologia projektowania relacyjnych baz danych: Baza danych encji i ich relacji. Narzędzia do wyświetlania i manipulacji diagramu encja-związek. Narzędzia do manipulowania bazą danych. Ostrzeżenie: Jest wiele zamieszania wokół definicji i notacji.

5 Diagram encja-związek Encja Relacja pomiędzy encje Atrybut encji lub relacji Relacja dziedziczenia

6 Przykład: dydaktyczny projekt zespołowy Ocena Kierownik projektu Temat projektu 1 ocenia 1 Ambitny student Projekt Wykładowca 1 0:n konsultuje 0:n Student 3 do 5 uczestniczy w

7 Przykład rekordu do katalogu MARC (Machine-readable cataloging) Book 1 Describes 0:n 0:n Author of Editor of 0:n 0:n Creator 0:n Catalog record 1:n Is about 0:n Subject heading Short title Control numb

8 Słowniki danych Słownik danych to lista nazw które będą używane przez system oprogramowania: Krótka definicja (np. Transport jest to ) Co to jest (np. numer, nazwa) Gdzie i do czego jest to używane (np. jako źródło danych do procesu rejestracji, itp.) Może być połączony ze słownikiem projektu (glosariuszem) W kontekście implementacji systemu: słownik danych jako część specyfikacji wymagań jest brudnopisem do systemowego słownika danych, który jest częścią formalnej specyfikacji systemu.

9 Uwaga na temat obiektowego modelu wymagań Będziemy używać model obiektów jako narzędzie do projektowania systemu oprogramowania. Niektórzy polecają model obiektów do analizy wymagań, ale trudno jest z nich korzystać, nie narzucając ograniczania na konstrukcję systemu.

10 Wymagania niefunkcjonalne Wymagania produktu: wydajność, niezawodność, mobilność, itp. Wymogi organizacyjne: dostawy, szkolenia, normy, itp. Zewnętrzne wymogi: prawne, interoperacyjne, itp.

11 Przykłady wymagań niefunkcjonalnych Projekt: Biblioteka cyfrowa Prywatność Wymaganie funkcjonalne: Dane użytkowe do zarządzania systemem Wymaganie niefunkcjonalne: Dane użytkowe nie mogą identyfikować osoby Minimalizowanie rekordów Wymaganie funkcjonalne: Zachować wszystkie wymagane rekordy Wymaganie niefunkcjonalne: Odrzucić wszystkie inne rekordy

12 Wymogi niewypowiedziane Przykład: Odporność na zmiany przy

13 Specyfikacja wymagań Jaki jest cel specyfikacji wymagań?

14 Przeznaczenie specyfikacji wymagań 1. Opisuje wymagania interesariuszy Wyrażone w warunkach, które zainteresowane strony rozumieją Zrozumiałe z wielu punktów widzenia Są korygowane przez interesariuszy, tak że rozumieją oni znaczenie wymagań Muszą być jasne założenia (rzeczy pominięte)

15 Przeznaczenie specyfikacji wymagań 2. Opisuje wymagania do realizatorów Tak precyzyjne i szczegółowe, jak to możliwe Wyrażone w słowach, które realizatorzy rozumieją Zrozumiałe dla nowych członków zespołu

16 Przeznaczenie specyfikacji wymagań 3. Opisuje wymagania na przyszłość Istotny element ewolucji systemu oprogramowania 4. Jeśli może być dokumentem umowy Do zobaczenia w sądzie!

17 Specyfikacja wymagań: podejścia Język naturalny Zorganizowany (strukturyzowany) język naturalny Język opisu projektu Język specyfikacji wymagań Graficzny zapis Formalae specyfikacja Patrz Sommerville, Rozdział 7.