Pozyskiwanie i dokumentowanie wymaga
This presentation is the property of its rightful owner.
Sponsored Links
1 / 40

Pozyskiwanie i dokumentowanie wymagań PowerPoint PPT Presentation


  • 100 Views
  • Uploaded on
  • Presentation posted in: General

Pozyskiwanie i dokumentowanie wymagań. Koncepcja wykładu: Slajdy/Lektor/Montaż:. Jerzy Nawrocki/Łukasz Olek Łukasz Olek. Plan wykładów. Standardy serii ISO 9000 Model dojrzałości CMMI Zarządzanie przedsięwzięciami i PRINCE2, cz. I Zarządzanie przedsięwzięciami i PRINCE2, cz. II

Download Presentation

Pozyskiwanie i dokumentowanie wymagań

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Pozyskiwanie i dokumentowanie wymaga

Pozyskiwanie i dokumentowanie wymagań

Koncepcja wykładu:

Slajdy/Lektor/Montaż:

Jerzy Nawrocki/Łukasz Olek

Łukasz Olek


Plan wyk ad w

Plan wykładów

Standardy serii ISO 9000

Model dojrzałości CMMI

Zarządzanie przedsięwzięciami i PRINCE2, cz. I

Zarządzanie przedsięwzięciami i PRINCE2, cz. II

Personal Software Process, cz. I

Personal Software Process, cz. II

Metodyki programowania: TSP i RUP

Pozyskiwanie i dokumentowanie wymagań (IEEE 830)

Wymagania pozafunkcyjne i ISO 9126

Zarządzanie ryzykiem

Systemy krytyczne i HAZOP

Szacowanie rozmiaru oprogramowania

Szacowanie pracochłonności


Przypadki u ycia przypomnienie

Przypadki użycia - przypomnienie


Wprowadzenie

Wprowadzenie

  • Jakie pytania zadać klientowi?

  • Komu zadawać pytania?

  • Jak stworzyć całą specyfikację wymagań?


Plan wyk adu

Plan wykładu

  • Wprowadzenie

  • IEEE 830

    • Kryteria dobrej specyfikacji

    • Struktura dokumentu

  • Dobre praktyki dotyczące dokumentu wymagań


Dobre praktyki in ynierii wymaga

Dobre praktyki inżynierii wymagań

  • Yan Sommerville & Pete Sawyer ‘97

  • Zbiór dobrych praktyk


Kryteria dobrej specyfikacji

IEEE Std 830-1998

Kryteria dobrej specyfikacji

  • Poprawna

  • Jednoznaczna

  • Kompletna

  • Spójna

  • Uporządkowana wg ważności/stabilności

  • Weryfikowalna

  • Modyfikowalna

  • Umożliwiająca śledzenie powiązań


Kryteria dobrej specyfikacji1

IEEE Std 830-1998

Kryteria dobrej specyfikacji

  • Poprawna

  • Jednoznaczna

  • Kompletna

  • Spójna

  • Uporządkowana wg ważności/stabilności

  • Weryfikowalna

  • Modyfikowalna

  • Umożliwiająca śledzenie powiązań


Kryteria dobrej specyfikacji2

IEEE Std 830-1998

Kryteria dobrej specyfikacji

  • Poprawna

  • Jednoznaczna

  • Kompletna

  • Spójna

  • Uporządkowana wg ważności/stabilności

  • Weryfikowalna

  • Modyfikowalna

  • Umożliwiająca śledzenie powiązań


Kryteria dobrej specyfikacji3

IEEE Std 830-1998

Kryteria dobrej specyfikacji

  • Poprawna

  • Jednoznaczna

  • Kompletna

  • Spójna

  • Uporządkowana wg ważności/stabilności

  • Weryfikowalna

  • Modyfikowalna

  • Umożliwiająca śledzenie powiązań


Kryteria dobrej specyfikacji4

IEEE Std 830-1998

Kryteria dobrej specyfikacji

  • Poprawna

  • Jednoznaczna

  • Kompletna

  • Spójna

  • Uporządkowana wg ważności/stabilności

  • Weryfikowalna

  • Modyfikowalna

  • Umożliwiająca śledzenie powiązań


Kryteria dobrej specyfikacji5

IEEE Std 830-1998

Kryteria dobrej specyfikacji

  • Poprawna

  • Jednoznaczna

  • Kompletna

  • Spójna

  • Uporządkowana wg ważności/stabilności

  • Weryfikowalna

  • Modyfikowalna

  • Umożliwiająca śledzenie powiązań


Kryteria dobrej specyfikacji6

IEEE Std 830-1998

Kryteria dobrej specyfikacji

  • Poprawna

  • Jednoznaczna

  • Kompletna

  • Spójna

  • Uporządkowana wg ważności/stabilności

  • Weryfikowalna

  • Modyfikowalna

  • Umożliwiająca śledzenie powiązań


Kryteria dobrej specyfikacji7

IEEE Std 830-1998

Kryteria dobrej specyfikacji

  • Poprawna

  • Jednoznaczna

  • Kompletna

  • Spójna

  • Uporządkowana wg ważności/stabilności

  • Weryfikowalna

  • Modyfikowalna

  • Umożliwiająca śledzenie powiązań


Plan wyk adu1

Plan wykładu

  • Wprowadzenie

  • IEEE 830

    • Kryteria dobrej specyfikacji

    • Struktura dokumentu

  • Dobre praktyki dotyczące dokumentu wymagań


Struktura srs

IEEE Std 830-1998

Określ standardową strukturę dokumentu

Struktura SRS

1. Wprowadzenie

2. Ogólny opis produktu

3. Wymagania funkcjonalne

4. Wymagania pozafunkcjonalne

Dodatki

Indeks


Struktura srs1

IEEE Std 830-1998

Struktura SRS

  • 1. Wprowadzenie

    • 1.1 Cel dokumentu

    • 1.2 Zakres produktu

    • 1.3 Definicje, akronimy i skróty

    • 1.4 Odwołania do literatury

    • 1.5 Omówienie dokumentu

  • 2. Ogólny opis produktu

  • 3. Wymagania funkcjonalne

  • 4. Wymagania pozafunkcjonalne

  • Dodatki

  • Indeks

Wyjaśnij, jak korzystać z dokumentu

Dołącz streszczeniewymagań

Zdefiniuj terminyspecjalistyczne


1 1 cel dokumentu

1.1 Cel dokumentu

Rola dokumentu specyfikacji wymagań + czytelnicy

Niniejszy dokument prezentuje wymagania dotyczące oprogramowania, czyli opisuje funkcjonalność budowanego oprogramowania i warunki, jakie ono musi spełniać.

Dokument ten został napisany z myślą o potencjalnych użytkownikach, projektantach, programistach, osobach zajmujących się testowaniem i autorach dokumentacji użytkowej.


1 2 zakres produktu

1.2 Zakres produktu

  • Identyfikacja produktu programistycznego poprzez nazwę.

  • Co produkt będzie, a czego nie będzie robił.

  • Zastosowanie specyfikowanego oprogramowania.

  • Wizja produktu:

    • Na czym polega problem?

    • Kogo dotyczy?

    • Jakie są jego implikacje?

    • Jaki jest pomysł na jego rozwiązanie?


1 2 zakres produktu1

1.2 Zakres produktu

  • Identyfikacja produktu programistycznego poprzez nazwę.

  • Co produkt będzie, a czego nie będzie robił.

  • Zastosowanie specyfikowanego oprogramowania.

Polskie Towarzystwo Literackie ma ponad 10 tys. członków. Członkowie często zmieniają swoje dane adresowe i są kłopoty z ich szybką aktualizacją. Problem dotyczy zarówno członków towarzystwa (ok. 500 osób rocznie zmienia swoje dane), jak też zarządu, który ma kłopoty z komunikacją. Konsekwencją tego stanu rzeczy są zaległości składkowe rzędu 15 tys. zł. Rozwiązaniem ma być system internetowy e-Member umożliwiający aktualizację danych adresowych poprzez Internet.


1 3 definicje akronimy i skr ty

1.3 Definicje, akronimy i skróty

ASAP – Tak szybko, jak to możliwe (od ang. As Soon As Possible)

Explorer – patrz MS Explorer

...

MS Explorer – Oprogramowanie firmy Microsoft umożliwiające czytanie stron internetowych

NIP – Numer identyfikacji podatkowej

PTL – Polskie Towarzystwo Literackie

Uporządkuj alfabetycznie


1 4 odwo ania do literatury

1.4 Odwołania do literatury

System powinien podawać wartość średnią i odchylenie standardowe [Montgomery97].

[Montgomery97] D.Montgomery, Introduction to Statistical Quality Control, John Wiley & Sons, Boston, 1997.

[Ustawa2000] Ustawa z dnia 16.11.2000 o przeciwdziałaniu wprowadzaniu do obrotu finansowego wartości majątkowych pochodzących z nielegalnych lub nieujawnionych źródeł oraz o przeciwdziałaniu finansowaniu terroryzmu, Dz.U. z dnia 22 grudnia 2000.


1 5 om wienie dokumentu

1.5 Omówienie dokumentu

Omówić organizację pozostałej części dokumentu

W rozdziale 2. omówiono ogólnie produkt wraz z krótką charakterystyką użytkowników i funkcjonalności, jaką będzie im udostępniał budowany system. Rozdział 3. jest poświęcony szczegółowemu opisowi wymagań funkcjonalnych, które zostały podzielone na grupy wg klas użytkowników (ról). Wymagania te są punktem wyjścia do opisu wymagań pozafunkcjonalnych, które przedstawiono w rozdziale 4.


Struktura srs2

IEEE Std 830-1998

Struktura SRS

  • 1. Wprowadzenie

  • 2. Ogólny opis produktu

    • 2.1 Kontekst funkcjonowania

    • 2.2 Charakterystyka użytkowników

    • 2.3 Główne funkcje produktu

    • 2.4 Ograniczenia

    • 2.5 Założenia i zależności

  • 3. Wymagania funkcjonalne

  • 4. Wymagania pozafunkcjonalne

  • Dodatki

  • Indeks


2 1 kontekst funkcjonowania

2.1 Kontekst funkcjonowania

Omawiany system ma współpracować z systemem PolCard w zakresie płatności elektronicznych. Diagram kontekstu przedstawiono na rys. 1.

Wzbogacaj język naturalny innymi formami opisu

Odpowiednio korzystaj z diagramów


2 2 charakterystyka u ytkownik w

2.2 Charakterystyka użytkowników

Można wyróżnić następujące role:

Członek towarzystwa – Gros członków PTL (ponad 80%) jest w przedziale od 30 do 55 lat. Część z nich ma problemy ze wzrokiem. Z przeprowadzonej ostatnio ankiety wynika, że 80% członków ma w domu komputer i umie lub chce się nauczyć korzystać z Internetu.

Zarząd – Wszyscy członkowie zarządu mają komputery i potrafią korzystać z Internetu.


2 3 g wne funkcje produktu

2.3 Główne funkcje produktu

  • Produkt udostępnia funkcje opisane poniżej.

  • Członek PTL może za pomocą e-Member:

  • Czytać swoje dane przechowywane w systemie

  • Aktualizować swoje dane

  • Zarząd PTL może:

  • Wysyłać do członków PTL korespondencję zbiorową


2 4 ograniczenia

2.4 Ograniczenia

System musi spełniać wymagania stawiane przez ustawę o ochronie danych osobowych [UstawaOsob].


2 5 za o enia i zale no ci

2.5 Założenia i zależności

Prezentowane wymagania dotyczą stanu prawnego na dzień 1 września 2005 roku.


Struktura srs3

IEEE Std 830-1998

Struktura SRS

1. Wprowadzenie

2. Ogólny opis produktu

3. Wymagania funkcjonalne

3.1 Interfejsy zewnętrzne

3.2 Funkcje

3.2.1 Członek PTL

3.2.1.1 Czytanie danych

3.2.1.2 Aktualizacja danych

3.2.2 Zarząd PTL

3.2.2.1 Wysyłanie korespondencji

4. Wymagania pozafunkcjonalne

Dodatki

Indeks


Struktura srs4

IEEE Std 830-1998

Struktura SRS

1. Wprowadzenie

2. Ogólny opis produktu

3. Wymagania funkcjonalne

3.1 Interfejsy zewnętrzne

3.2 Funkcje

3.2.1 Członek PTL

3.2.1.1 Czytanie danych

3.2.1.2 Aktualizacja danych

3.2.2 Zarząd PTL

3.2.2.1 Wysyłanie korespondencji

4. Wymagania pozafunkcjonalne

Dodatki

Indeks


Interfejsy zewn trzne

Interfejsy zewnętrzne


Struktura srs5

IEEE Std 830-1998

Struktura SRS

1. Wprowadzenie

2. Ogólny opis produktu

3. Wymagania funkcjonalne

3.1 Opis otoczenia

3.2. Funkcje

3.2.1 Członek PTL

3.2.1.1 Czytanie danych

3.2.1.2 Aktualizacja danych

3.2.2 Zarząd PTL

3.2.2.1 Wysyłanie korespondencji

4. Wymagania pozafunkcjonalne

Dodatki

Indeks

Przypadki użycia!


Struktura srs6

IEEE Std 830-1998

Struktura SRS

  • 1. Wprowadzenie

  • 2. Ogólny opis produktu

  • 3. Wymagania funkcjonalne

  • 4. Wymagania pozafunkcjonalne

    • 4.1 Użyteczność

    • 4.2 Niezawodność

    • 4.3 Wydajność

    • 4.4 Bezpieczeństwo

  • Dodatki

  • Indeks


Klasyfikacja dobrych praktyk

Klasyfikacja dobrych praktyk


Dokument wymaga

Dokument wymagań

  • Zdefiniuj standardową strukturę dokumentu

  • Wyjaśnij, jak korzystać z dokumentu

  • Dołącz streszczenie wymagań

  • Opracuj uzasadnienie biznesowe dla systemu

  • Zdefiniuj terminy specjalistyczne

  • Wybierz czytelny szablon dokumentu

  • Pomóż czytelnikom znaleźć informację

  • Uczyń dokument łatwym do zmiany


Klasyfikacja dobrych praktyk1

Klasyfikacja dobrych praktyk


Opisywanie wymaga

Opisywanie wymagań

  • Zdefiniuj standardowe szablony dla opisu wymagań

  • Pisz prosto i krótko

  • Odpowiednio korzystaj z diagramów

  • Wzbogacaj język naturalny innymi formami opisu

  • Specyfikuj wymagania ilościowo


Podsumowanie

Podsumowanie

  • Standard IEEE 830-1998

    • kryteria dobrej specyfikacji wymagań

    • dotyczy dokumentu specyfikacji wymagań

  • Struktura dokumentu

  • Dobre praktyki inżynierii wymagań


Literatura

Literatura

  • IEEE 830-1998

  • Adolph, Bramble, Cockburn, Pols: Patterns for Effective Use Cases

  • Sommerville, Sawyer: Requirements Engineering. A Good Practice Guide.


  • Login