Przykład pełnej specyfikacji wymagań.
Chciałbym pokazać Wam przykład specyfikacji wymagań. W internecie jest bardzo mało kompletnych i nietrywialnych przykładów. Chciałbym żebyście zastanowili się jak praca poświęcona utworzeniu specyfikacji skraca czas potrzebny na ukończenie projektu. Jaki jest zwrot z inwestycji zapewnienia właściwej i łatwej do zrozumienia specyfikacji? Podpowiem, że zwrot należy liczyć na podstawie skróconego czasu programowania, mniejszych kosztów utrzymania i poprawy błędów oraz przede wszystkim oszczędności czasu użytkowników nowego oprogramowania w porównaniu do rozwiązań których obecnie używają.
Problem biznesowy.
Od dawna próbowałem zmierzyć się z problemem rezerwacji zasobów i tym samym blokowania ich. Dawno temu musieliśmy w zespołach liczących kilka, kilkanaście osób dzielić się sprzętem telekomunikacyjnym. Sprzętu było sporo, jednak zapotrzebowanie na konkretne elementy było bardzo duże. Często trwały poszukiwania wolnego sprzętu i rozmowy z kimś kto mógłby użyczyć to co ma zarezerwowane. Sporo myślałem nad tym problemem jako administrator laboratorium.
Później wielokrotnie stykałem się z podobnym problemem braku wolnych sal na spotkanie. Myślałem, że musi istnieć jakieś rozwiązanie skoro w praktyce nie wszystkie rezerwacje były wykorzystywane. Często, pomimo pełnej rezerwacji wszystkich sal, można było zwiedzając budynek odkryć, że właściwie to sale są wolne... Czy wam też zdarzało się coś podobnego?
Ten dokument opisuje wymagania dla narzędzia, które pomaga porozumiewać się miedzy osobami korzystającymi ze wspólnych zasobów. Konkretnie skupimy się nad problemem rezerwacji sali na spotkanie, zwracając szczególną uwagę na sytuację kiedy wszystkie sale są zarezerwowane.
Później wielokrotnie stykałem się z podobnym problemem braku wolnych sal na spotkanie. Myślałem, że musi istnieć jakieś rozwiązanie skoro w praktyce nie wszystkie rezerwacje były wykorzystywane. Często, pomimo pełnej rezerwacji wszystkich sal, można było zwiedzając budynek odkryć, że właściwie to sale są wolne... Czy wam też zdarzało się coś podobnego?
Ten dokument opisuje wymagania dla narzędzia, które pomaga porozumiewać się miedzy osobami korzystającymi ze wspólnych zasobów. Konkretnie skupimy się nad problemem rezerwacji sali na spotkanie, zwracając szczególną uwagę na sytuację kiedy wszystkie sale są zarezerwowane.
Propozycja rozwiązania.
Mamy tu do rozwiązania pewien paradoks. Trzeba znaleźć salę kiedy wszystkie są zajęte. W praktyce ludzie rezerwują sale na spotkania z dużym wyprzedzeniem i często robią to na wszelki wypadek, by nie mieć później problemów ze znalezieniem wolnej sali. Paradoksalnie aby rozwiązać ten problem należy zapewnić, że zawsze kiedy ktoś organizuje spotkanie można znaleźć wolną salę. Aby pozbyć się niewykorzystywanych rezerwacji sal należy sprawić, by można sobie łatwo poradzić w sytuacji kiedy nie ma wolnych sal.
Specyfikacja wymagań.
Opis środowiska pracy:
Biuro, każdy ma swój komputer lub urządzenie mobilne. Pracownik otrzymuje polecenie lub sam decyduje o konieczności organizacji spotkania. Na spotkanie trzeba zaprosić osoby, które często są dostępne jedynie w określonych godzinach. Czasem może się okazać, że nie ma terminu kiedy wszyscy są wolni. Większość sal jest już zarezerwowana. Organizator chce jak najszybciej zrobić rezerwację i wrócić do swojej pracy. Organizatorowi zależy na konkretnych godzinach w konkretnym dniu. Organizator wie, że część sal pomimo rezerwacji może okazać się dostępna.
Co do uczestników to można z nimi dyskutować czy faktycznie są zajęci w konkretnych godzinach i czy mogą zmienić swoje plany, by pojawić się na tym spotkaniu o konkretnej godzinie. Można w przyszłości dodać do systemu funkcjonalność wyszukiwania wolnych sal w terminach kiedy tylko jeden z uczestników nie może się pojawić. W pewnych sytuacjach byłaby to pomocna informacja. Jednak nie jest to dogodna sytuacja dla organizatora spotkania i dla uczestników dlatego w pierwszej wersji systemu ją pominiemy. Dobra specyfikacja powinna ułatwić nam dodanie tej funkcjonalności w przyszłości.
Co do uczestników to można z nimi dyskutować czy faktycznie są zajęci w konkretnych godzinach i czy mogą zmienić swoje plany, by pojawić się na tym spotkaniu o konkretnej godzinie. Można w przyszłości dodać do systemu funkcjonalność wyszukiwania wolnych sal w terminach kiedy tylko jeden z uczestników nie może się pojawić. W pewnych sytuacjach byłaby to pomocna informacja. Jednak nie jest to dogodna sytuacja dla organizatora spotkania i dla uczestników dlatego w pierwszej wersji systemu ją pominiemy. Dobra specyfikacja powinna ułatwić nam dodanie tej funkcjonalności w przyszłości.
Reguły biznesowe:
- Nie można organizować spotkania jeżeli brak jest wolnej sali lub inaczej określonego miejsca spotkania.
- Spotkania należy organizować w terminach kiedy wszyscy uczestnicy mogą wziąć w nich udział.
- Wolno zapraszać jedynie osoby zatrudnione wewnątrz organizacji.
- Początek dnia roboczego to 8:00 a koniec to 17:00.
- Dni robocze to Pon – Pt z wyłączeniem dni świątecznych.
Model danych:
Słownik danych:
lista uczestników =
sala = rezerwacja = uczestnik = |
identyfikator uczestnika {kilka razy}
nazwa sali + adres budynku + lokalizacja sali + liczba miejsc siedzących + numer telefonu w sali + liczba tablic do rysowania + rzutnik [tak | nie] + sala z oknem [tak | nie] data rezerwacji [YYYY-MM-DD] + czas rozpoczęcia [HH:MM] + czas zakończenia [HH:MM] + nazwa sali + {lista uczestników} identyfikator uczestnika + imię + nazwisko + adres e-mail + daty planowanych urlopów + rola podczas spotkania [merytoryczny | moderator | organizator | skryba] |
Opisy zadań (ang. task scripts, task descriptions) oraz szczegółowe wymagania
Zadanie:
Cel: Częstotliwość zadania: Krytyczna częstotliwość: Pod-zadania: 1. Określić listę uczestników. 2. Określić czas trwania spotkania. 3. Określić horyzont czasowy kiedy ma odbyć się spotkanie. 4. Podać wymagania co do sali (opcjonalnie). 5. Znaleźć listę wolnych sal w terminach kiedy wszyscy uczestnicy są dostępni. 6. Wybrać salę i złożyć rezerwację. 7. Poinformować uczestników o miejscu i terminie spotkania 8. Przed samym spotkaniem przypomnieć o nim uczestnikom. Warianty: 5a. Jeden z uczestników całkowicie zajęty w ustalonym horyzoncie czasowym. 5b. Brak terminów w ustalonym horyzoncie czasowym kiedy wszyscy uczestnicy są dostępni. 5c. Brak wolnych sal w terminach kiedy wszyscy uczestnicy są dostępni. |
Zarezerwować salę i czas uczestników. ID = ZS
Zorganizować spotkanie grupy ludzi w określonym dniu Raz na tydzień. Cztery razy dziennie. Przykładowe rozwiązanie: 1. Proste wybranie spośród osób zapraszanych do tej pory przez organizatora. Wyszukiwanie wśród wszystkich pracowników organizacji. Dodanie wszystkich osób wchodzących w skład zdefiniowanej grupy. 2. Domyślnie proponowany jest czas na podstawie ostatnio ustalanych przez organizatora spotkań. Łatwe zwiększanie lub skracanie czasu w krokach 15 min. Możliwe zdefiniowanie dowolnego czasu z dokładnością do 1min. 3. Domyślnie czas od chwili obecnej do końca następnego dnia roboczego. Łatwe zmienianie czasu początku i końca w krokach 30 min. Określanie przedziału czasowego wewnątrz horyzontu czasowego, który ma nie być brany po uwagę (np. po godzinach i w nocy) domyślnie ten przedział to 5PM – 8AM. Możliwe dodawanie kilku horyzontów czasowych dla jednego spotkania. 4. Możliwe określenie minimalnej liczba miejsc siedzących. Określenie niezbędnego wyposażenia sali. 7. Zarezerwować czas uczestników 5a. System umożliwia usunięcie uczestnika. System podaje najbliższy termin kiedy ten uczestnik jest dostępny. 5b. System podaje najbliższy termin kiedy wszyscy uczestnicy są dostępni. System wyświetla grafik dostępności wszystkich uczestników. System zaznacza terminy kiedy wszyscy poza jedną osobą są dostępni. 5c. System podaje najbliższy termin kiedy wszyscy uczestnicy są dostępni i jest wolna sala. System pomaga w zarezerwowaniu sali kiedy wszystkie sale są już zajęte. System pomaga znaleźć dwie sale gdzie mogłoby zostać zorganizowane spotkanie ze zmianą sali w trakcie. |
ZS.ListaUczestników.
Wyszukiwanie:
Organizator: Szczegóły: Zapraszani: Grupy: Usuwanie: Role: |
Powinno dać się dodać dowolną osobę z organizacji wyszukując ją wg:
adresu e-mail, imienia, nazwiska, departamentu, nazwy zespołu Organizator domyślnie jest pierwszym uczestnikiem spotkania ale może usunąć się z listy uczestników. Lista uczestników powinna zawierać następujące szczegóły: imię + nazwisko + adres e-mail + najbliższy zaplanowany urlop System powinien pokazywać osoby zapraszane do tej pory i umożliwiać dodanie ich do listy uczestników planowanego spotkania. Pokazywać maksymalnie 20 najczęściej zapraszanych osób. System powinien przechowywać dane o zapraszanych osobach przez ostatni rok. Powinno dać się tworzyć grupy osób do celów zapraszania całej grupy na spotkanie. System powinien umożliwiać dodanie wszystkich osób z wskazanej grupy. Pokazywać wszystkie zdefiniowane grupy. Powinno dać się w dowolnym momencie dodawać do grupy nowe osoby i usuwać obecne. System powinien umożliwiać w dowolnym momencie usunięcie wybranych osób z listy uczestników. Powinno dać się ustalić rolę dla każdego z uczestników spotkania, domyślnie jest jeden 'organizator' (jest nim organizator jak łatwo zgadnąć :) a pozostali to 'merytoryczni'. |
ZS.CzasTrwaniaSpotkania.
Format:
Domyślnie: MinMax: Zmiana: |
Czas trwania powinien być w formacie MM np. 90 minut
Początkowo domyślny czas to 90 minut. Każde spotkanie które zostało już w pełni zaplanowane - sala i czas uczestników zarezerwowane - wpływa na domyślny czas. Domyślny czas to najczęściej pojawiające się ustawienie z ostatnich 10 spotkań organizowanych przez daną osobę. Minimalny czas jednego spotkania to 15 min, maksymalny to 480 min (8h) Łatwe zmienianie plus i minus 15 min jednym kliknięciem. |
ZS.HoryzontCzasowy.
Format:
Domyślnie: Zapamiętywanie: ZmianaDomyślnych: Noc: KilkaHoryzontów: |
Pola „Początek” i „Koniec” ustala się podając datę i czas.
Początkowo domyślnie Początek ustalany jest jako najbliższa pełna połowa godziny. Początkowo domyślnie Koniec ustalany jest jako koniec następnego dnia roboczego. System powinien zapamiętywać dla w pełni zaplanowanych do tej pory spotkań następujące informacje: organizator + czas wysłania zaproszenia na spotkania + horyzont czasowy użyty do wyszukania sali. System powinien wyliczać każdorazowo domyślny Początek, dodając do obecnego czasu średnią wartość różnicy między czasem wysłania zaproszenia i Początkiem horyzontu użytego do wyszukiwania sali z ostatnich 10-ciu spotkań tego organizatora, a następnie zaokrąglając wynik tego obliczenia do najbliższej połowy godziny. System powinien wyliczać domyślny koniec dodając do użytego obecnie domyślnego Początku średnią różnicę czasu między Początkiem i Końcem w ostatnich 10-ciu organizowanych spotkaniach. System powinien w horyzoncie czasowym nie uwzględniać godzin nocnych od 17:00 do 8:00 kolejnego dnia. Powinno dać się poza ustaleniem jednego początka i końca dodawać kolejne przedziały czasowe. |
ZS.ParametrySali.
Opcje:
Domyślnie: |
Powinno dać się filtrować sale uwzględniane do wyszukiwania podając następujące kryteria:
budynek, minimalna liczba miejsc siedzących, maksymalna liczba miejsc siedzących, minimalna liczba tablic do rysowania, rzutnik, okno. Domyślnie wszystkie sale są brane pod uwagę. |
ZS.ZnaleźćSale.
DwieSale:
|
System powinien umożliwić wyszukanie dwóch sal gdzie wprowadzając przerwę na zmianę sali można by zorganizować spotkanie.
|
ZS.ZłożyćRezerwację.
Wybór:
Agenda: Powiadomienia: |
Powinno dać się wybrać jeden lub kilka proponowanych terminów.
System powinien pozwalać na wykonanie rezerwacji jednego terminu i sali oraz na wykonanie kilku rezerwacji. Organizator powinien móc ustalić cel i agendę spotkania. System powinien powiadomić wszystkich uczestników w tym i organizatora o terminie i miejscu spotkania oraz przedstawić im cel i agendę. |
ZS.PrzypomniećOSpotkaniu.
Czas:
|
System powinien na 15 minut przed spotkaniem przypomnieć o niem wszystkim uczestnikom.
System powinien przypomnieć organizatorowi na 20 minut przed spotkaniem. |
ZS.ZajętyUczestnik.
Obsługa:
|
System powinien poinformaować organizatora jeżeli jeden z uczestników nie ma wystarczająco dużo wolnego czasu w wybranym horyzoncie czasowym.
System powinien pokazać godziny dostępności tego uczestnika w wybranym horyzoncie czasowym. System podaje najbliższy wolny termin dla tego uczestnika. |
ZS.BrakDostępnościWszystkich
Obsługa:
|
System powinien poinformować organizatora w sytuacji kiedy nie ma terminu kiedy wszyscy uczestnicy byliby dostępni.
System podaje najbliższy termin kiedy wszyscy sa dostępni. System pokazuje grafik spotkań wszystkich uczestników włączając w to jak zawsze organizatora. |
ZS.BrakWolnychSal.
Obsługa:
|
Jeżeli są terminy kiedy wszyscy uczestnicy są dostępni ale nie ma wolnych sal system powinien poinformować o tym organizatora.
System powinien podać najbliższy termin kiedy wszyscy są dostępni i jest też wolna sala. System powinien pokazać listę terminów kiedy wszyscy uczestnicy są dostępni w ramach wybranego horyzontu czasowego. |
Zadanie:
Cel: Warunek początkowy: Częstotliwość zadania: Krytyczna częstotliwość: Pod-zadania: 1. Pokazać listę terminów kiedy wszyscy uczestnicy spotkania są dostępni. 2. Wybrać terminy, które najbardziej pasują. 3. Pokazać listę rezerwacji sal pokrywających się z tymi terminami. 4. Wysłać prośbę o zwolnienie rezerwacji do wszystkich lub wybranych posiadaczy rezerwacji. 5. Dowiedzieć się o odmowach. 6. Dowiedzieć się o akceptacji prośby. Warianty: 5a. Jeżeli wszyscy odmówią pokazać horyzont czasowy kiedy nie da się zorganizować spotkania. |
Poprosić o zwolnienie rezerwacji sali. ID = POZ
Poprosić grupę posiadaczy odpowiednich rezerwacji o zwolnienie rezerwacji sali. Brak wolnych sal w terminach kiedy wszyscy uczestnicy spotkania są dostępni. Raz na tydzień. Dwa razy dziennie Przykładowe rozwiązanie: 2. Możliwe wybieranie jednego, kilku lub wszystkich terminów. Możliwe wybranie przedziału czasowego. 3. Pokazać tylko te rezerwacje, dla których w ciągu ostatnich 24h nie było odmowy zwolnienia sali. 4. Opcjonalnie zawęzić listę osób, do których ma zostać wysłana prośba 5. Dowiedzieć się ile próśb zostało wysłanych i ile jest odmów. Wyraźna informacje kiedy wszystkie prośby zakończyły się odmową zwolnienia sali. 6. System powinien poinformować uczestników o miejscu i terminie spotkania. 5a. Pokazać grafik dostępności. |
Zadanie:
Cel: Warunek początkowy: Częstotliwość zadania: Krytyczna częstotliwość: Pod-zadania: 1. Pokazać prośbę o zwolnienie konkretnej rezerwacji sali. 2. Odmówić prośbie. Warianty: 2a. Posiadacz rezerwacji nie odpowiada w żaden sposób przez 1h. |
Odrzucić prośbę o zwolnienie rezerwacji sali
Zatrzymać posiadaną rezerwację i uchronić się przed dalszym otrzymywaniem zapytań w sprawie tej konkretnej rezerwacji. Otrzymano prośbę o zwolnienie rezerwacji sali W zależności od liczby posiadanych rezerwacji raz na dwa dni na jedną rezerwację. Kilkanaście razy dziennie jeżeli dana osoba ma dużą liczbę spotkań ustaloną na najbliższe dni. Przykładowe rozwiązania: 2. System zapamiętuje, że ta rezerwacja nie może zostać odwołana i w ciągu najbliższych 24h nie będzie brał jej pod uwagę przy prośbach o zwolnienie sali. 2a. Potraktować to jako odmowę. |
Zadanie:
Cel: Warunek początkowy: Częstotliwość zadania: Krytyczna częstotliwość: Pod-zadania: 1. Pokazać prośbę o zwolnienie konkretnej rezerwacji sali. 2. Wyrazić zgodę. 3. Poinformować organizatora spotkania o akceptacji jego prośby. 4. Poinformować osoby, które otrzymały prośby o tym, że ktoś inny zwolnił już swoją rezerwację. 5. Przenieść rezerwację do nowego organizatora. 6. Spotkanie, które straciło rezerwację sali przesunąć na inny termin Warianty: 2a. Przesunąć spotkanie na inny termin. 5a. Odwołać spotkanie. |
Zaakceptować prośbę o zwolnienie rezerwacji
Zwolnić posiadaną rezerwację sali Otrzymano prośbę o zwolnienie rezerwacji sali W zależności od liczby posiadanych rezerwacji raz na dwa dni na jedną rezerwację. Kilkanaście razy dziennie jeżeli dana osoba ma dużą liczbę spotkań ustaloną na najbliższe dni. Przykładowe rozwiązania: 4. System informuje tylko osoby, które otrzymały tę prośbę ale jeszcze jej nie odrzuciły. 5. System informuje organizatora, który wysłał prośbę. System wysyła zaproszenia do uczestników. 6. System ułatwia osobie zwalniającej rezerwację przeniesienie jej na inny termin: umożliwia wyszukanie sali na to spotkanie. System powiadamia uczestników w razie zmiany terminu. 2a. System mógłby sugerować na kiedy można przesunąć zaplanowane spotkanie bazując na dostępności jego uczestników i wolnych salach. 5a. System powiadamia uczestników o odwołaniu spotkania. |
© Łukasz Pasek, [email protected]