Przykład: wymagania dla modernizacji strony internetowej uczelni,
Wymagania biznesowe
1. Przeznaczenie i cele
Modernizacja strony internetowej Uczelni ma na celu przede wszystkim zwiększenie jej dostępności dla osób niedowidzących i z innymi problemami.
Założeniem jest przy tym funkcjonowanie jednej strony dostępnej dla wszystkich, a nie tworzenie odmiennej strony dla różnych urządzeń i użytkowników.
Dlatego celem projektu musi być stworzenie następujących elementów:
1. Opracowanie przejrzystych i dobrze widocznych elementów wizualnych, składających do wykorzystania w publikowanych dokumentach i stronach internetowych.
2. Stworzenie książki wzorów (tak zwany „Brand book”), obejmującej poza wspomnianymi wyżej elementami graficznymi także specyfikację kolorów, czcionek, wzorów dokumentów etc…
3. Opracowanie nowego wyglądu strony – z wykorzystaniem powyższych elementów, zgodnego z obowiązującymi zaleceniami i nowoczesnymi trendami w tej dziedzinie.
4. Modernizacja strony pod względem technicznym (np. czytnik tekstu), tak by maksymalnie zwiększyć jej użyteczność dla użytkowników (UX) – ze szczególnym uwzględnieniem osób z niepełnosprawnościami (dostępność cyfrowa).
5. Wdrożenie zasad publikacji treści, gwarantujących wysoką jakość i dostępność.
6. Audyt istniejącej strony i poprawienie elementów nie wyświetlających się poprawnie w wyniku jej modernizacji.
7. Opracowanie raportów i dokumentacji potwierdzających spełnienie przez stronę postawionych wymagać. W tym audyt dostępności (zgodność z WCAG na poziomie co najmniej AA) oraz deklaracja dostępności.
2. Uwarunkowania
Kontekst i motywacja.
Strona internetowa jest obecnie rozwijana w oparciu o CMS Wordpress. Składa się ona z szeregu podstron, które są uzupełniane przez osoby w odpowiednich działach Uczelni. Strona jest nieco mało nowoczesny wygląd, a przede wszystkim nie spełnia wymogów związanych z dostępnością cyfrową.
Najważniejsze problemy
1. Nie spełnia wymogów dostępności cyfrowej (WCAG).
2. Niejednolity wygląd – poszczególne podstrony mają odmienną (dość przypadkową) kolorystykę etc..
3. Strona nie jest zoptymalizowana pod kontem UX (doświadczenie użytkownika, ang. User experience).
Możliwość biznesowa.
Dostępne są środki w ramach projektu finansowanego z funduszy UE.
Wymagania użytkowników
Użytkownicy
Użytkownicy strony to przede wszystkim osoby poszukujące na niej informacje. Poza nimi użytkownikami są: osoby publikujące treści, władze uczelni, instytucje i osoby współpracujące z Uczelnią (potencjalni dostarczyciele treści) i osoby oceniające działalność uczelni (np. PKA).
Korzyści dla użytkowników
W wyniku realizacji projektu spodziewane są następujące korzyści (w podziale na grupy użytkowników / interesariuszy).
1) Użytkownicy strony:
-
zwiększenie dostępności cyfrowej
-
lepsza nawigacja, wyszukiwanie treści, przejrzystość i inne elementy składające się na doświadczenia użytkowników (UX)
2) Redaktorzy publikujący treści na stronie:
-
jasne reguły działania, upraszczające pracę redaktorów
-
gotowe wzorce i elementy graficzne wysokiej jakości
3) Władze uczelni:
-
lepszy kanał komunikacji z pracownikami i otoczeniem uczelni (interesariuszami)
-
większa wartość marketingowa Uczelni
4) Uczniowie – potencjalni studenci
-
informacja o uczelni i kierunkach kształcenia
-
integracja z systemem elektronicznej rekrutacji
5) Studenci Erasmusa
-
informacja w języku angielskim
-
powiązanie z elementami projektu EWP (Erasmus Without Paper)
6) Inni interesariusze zewnętrzni:
-
lepsza dostępność treści,
-
przejrzysta nawigacja – z dostępnością potencjalnie udostępnianych treści
-
większa motywacja do współdziałania z Uczelnią.
W dalszej części analizy zostaną opracowane przypadki użycia (jak użytkownicy używają strony) i na tej podstawie powstanie dokument pozwalający na obiektywną ocenę wykonania pracy.
Wymagania funkcjonalne
Poniżej zebrano tematy (funkcje) strony, jakie zidentyfikowaliśmy w trakcie analizy z zaznaczeniem, które z nich mieszczą się w zakresie projektu.
|
Lp |
Temat |
w zakre-sie |
waga |
Uwagi |
|
1 |
Modernizacja strony (używanego CMS) pod kątem jej przejrzystości i użyteczności (UX). |
tak |
10 |
Wordpress |
|
1-1 |
Przygotowanie co najmniej dwóch prototypów do wyboru. Prototypy powinny obejmować podstawowe elementy nawigacji, układ elementów na stronie, przejrzysty podział na podstrony (uwzględniający potrzeby Uczelni). |
tak |
Wybór wariantu dokona Dział Promocji |
|
|
1-2 |
Opracowanie różnych schematów publikowanych treści (artykułów) – dla różnych wariantów informacji (różniących się sposobem wyróżnień, nagłówkami, itp.). |
? |
||
|
1-3 |
Opracowanie we współpracy z Działem Promocji zasad publikacji różnych typów plików multimedialnych (filmy, galerie zdjęć itp…) oraz powiązania z serwisami społecznościowymi. |
tak |
||
|
2 |
Opracowanie we współpracy z Działem Promocji Księgi Identyfikacji Wizualnej – Brand book |
tak |
10 |
przeniesienie praw autorskich na Zleceniodawcę |
|
2-1 |
Elementy graficzne – w wersji wektorowej |
tak |
||
|
2-2 |
Kolorystyka i czcionki |
tak |
||
|
2-3 |
Wzory pism |
tak |
||
|
2-4 |
Wzory treści na stronie i reguły używania Księgi Identyfikacji Wizualnej |
tak |
||
|
3 |
Wygląd strony (temat, szablon) |
tak |
10 |
|
|
3-1 |
Stworzenie szablonu zgodnego z przyjętymi zasadami nawigacji i rozwoju (pkt 1) oraz wymaganiami Księgi Identyfikacji Wizualnej (pkt 2). |
tak |
||
|
3-2 |
Dostępność cyfrowa – WCAG (poziom AA) |
tak |
||
|
3-3 |
Możliwość globalnej zmiany layout-u serwisu – co najmniej żałobny, świąteczny (bożonarodzeniowy i wielkanocny), patriotyczny, standardowy. |
tak |
||
|
3-4 |
Responsywność. Automatyczne dostosowanie się do wielkości ekranu. |
tak |
||
|
3-5 |
Responsywna grafika. Grafika w formacie rastrowym, poza elementami uzgodnionymi ze Zleceniodawcą, które będą w formacie wektorowym. |
tak |
||
|
3-6 |
Uwzględnienie wszystkich przeglądarek internetowych powszechnie używanych, w tym Internet Explorer (wersja 11), Mozilla Firefox, Google Chrome, Opera, Edge, Safar, etc.. |
tak |
||
|
3-6 |
Zastosowanie strony kodowej zapewniającej poprawne wyświetlanie tekstu z polskimi znakami. |
tak |
||
|
4 |
Zabezpieczenia |
tak |
10 |
|
|
4-1 |
Standardowa ochrona przed próbami nieautoryzowanego dostępu do panelu administratora (https, hasła, system uprawnień) |
- |
||
|
4-2 |
Automatyczna analiza strony pod kątem obecności szkodliwego oprogramowania, podatności na włamania, etc..; jeśli używane są do tego powszechnie dostępne wtyczki dla których są dostępne wersje płatne (rozszerzona funkcjonalność) – musi zostać uwzględniona wersja o pełnej funkcjonalności. |
tak |
np.. Wordfence w wersji profesjonalnej |
|
|
4-3 |
Audyt bezpieczeństwa strony (brak podatności na ataki typu brute force, sql injection etc..). |
tak |
||
|
4-4 |
Mechanizm automatycznej kopii strony (utrzymywanie kopii roboczej dla prac rozwojowych). |
? |
||
|
5 |
Audyt strony po zmianie szablonu |
tak |
8 |
|
|
5-1 |
Sprawdzenie, czy jakaś treść nie łamią wymogów postawionych wobec szablonu. Tam gdzie możliwe jest poprawienie bez zmiany treści (np.. automatyczne czyszczenie formatowania) – powinno to zostać wykonane w ramach projektu. |
tak |
||
|
5-2 |
Zgodność kodu stron z rekomendacjami W3C dotyczącymi HTML oraz jego weryfikację przy pomocy narzędzi udostępnianych przez W3C pod adresami: http://validator.w3.org i http://jigsaw.w3c.org/css-validator/. |
tak |
||
|
6 |
Nowe elementy strony |
tak |
4 |
|
|
6-1 |
Newsletter z możliwością importu/eksportu listy adresatów, podział adresatów na grupy i wysyłania wiadomości do wybranych grup |
tak |
||
|
6-2 |
Formularz kontaktowy odporny na spamowanie i z możliwością wyboru tematu i związanego z nim adresata) |
tak |
||
|
6-3 |
Nowości: możliwość definiowania (wyboru) elementów podstron, które pojawią się na stronie głównej lub na wskazanych podstronach. |
tak |
||
|
6-4 |
Automatyczne generowanie kanałów RSS dla każdego działu. |
tak |
||
|
6-5 |
Mechanizmy wyszukiwania: mapa, wyszukiwarka, rozwijane drzewo działów |
tak |
||
|
7 |
Marketing (SEO) |
tak |
9 |
|
|
7-1 |
Elementy strony zwiększające jej rozpoznawalność i pozycjonowanie |
tak |
||
|
7-2 |
Automatyczne tworzenie mapy serwisu w formatach wymaganych przez wyszukiwarki |
tak |
||
|
7-3 |
Kampania reklamowa |
? |
||
|
7-4 |
Połączenie z mediami społecznościowymi z możliwością automatycznej publikacji wskazanych treści (co najmniej na Facebook i Twitter) |
tak |
||
|
8 |
Dostępność cyfrowa |
tak |
10 |
|
|
8-1 |
Zgodność z WCAG na poziomie AA |
tak |
||
|
8-2 |
Stale dostępny przycisk włączenia wysokiej ostrości |
tak |
||
|
8-3 |
Czytnik tekstu |
tak |
Licencja otwarta lub na na dwa lata |
|
|
8-4 |
Możliwość dodawania audiotekstu do filmów |
tak |
Licencja otwarta lub na na dwa lata |
|
|
9 |
Wersja wielojęzyczna |
tak |
||
|
9-1 |
Wersja angielska dla wybranych podstron |
tak |
||
|
9-3 |
Automatyczna zmiana menu i innych elementów nawigacji – tak, by uwzględniały tylko elementy przetłumaczone |
tak |
||
|
9-4 |
Informacje dla studentów Erasmusa |
tak |
Atrybuty jakościowe
1. Przedstawiony projekt powinien uwzględniać specyfikę estetyki właściwej dla stron internetowych instytucji administracji publicznej, uwzględniając jednocześnie aspekty korzystania z informacji wyświetlanych na monitorze (kolorystyka, krój czcionki, rozmiar czcionki, ikony itp.). Projekt graficzny powinien uwzględniać charakter instytucji i dziedzin, którymi się zajmuje.
2. Z uwagi na konieczność poprawnego wyświetlania treści już opublikowanych na stronie nie dopuszcza się używania generatorów wymagających stosowanie specjalnych kodów (czysty tekst powinien się poprawnie wyświetlać przy użyciu nowego szablonu strony).
3. Układ menu, podziału na podstrony (zarządzane przez odrębnych administratorów) etc powinien być w trakcie tworzenia projektu uzgadniany z Wydziałem Marketingu.
4. Wykonawca przedstawi co najmniej dwie propozycje Brandbooka - może być w wersji roboczej, ale na tyle dopracowanej, by móc dokonać porównań i wyboru jednej z nich.
5. Przed stworzeniem szablonu strony zostanie zbudowany prototyp w celu jego weryfikacji pod kątem użyteczności, przejrzystości i łatwości nawigacji. Prototyp powinien obejmować układ elementów strony oraz projekt podziału na główne podstrony wraz z zasadami nawigacji. Weryfikacja prototypu zostanie wykonana przez Zleceniodawcę w oparciu o dokonaną analizę (persony i przypadki użycia), która wraz z wynikami weryfikacji zostanie przekazana wykonawcy.
6. Wszystkie istotne elementy graficzne (nie dotyczy zdjęć i jednostkowych ozdobników) zostaną w wersji wektorowej przekazane Zleceniodawcy wraz z prawami dowolnego wykorzystania.
7. Wszystkie nowe elementy strony zostaną przekazane w postaci przejrzystego (niezakodowanego) kodu HTML lub PHP.
Miary sukcesu (wskaźniki)
Cel zostanie osiągnięty, jeśli powstaną i zostaną zaakceptowane dokumenty o których mowa w rozdziale „Przeznaczenie i cele” punkt 7.
Dokumenty te muszą zostać opracowane w oparciu o:
1. Obiektywne wskaźniki wynikające z normy WCAG.
2. Potwierdzony stan faktyczny (funkcjonowanie zamówionych elementów).
3. Akceptację wzorów i elementów graficznych przez Dział Promocji.
4. Pozytywna analiza użyteczności o której mowa w punkcie 5 poprzedniego rozdziału – zarówno w odniesieniu do prototypu jak i gotowej strony.
5. Wykonanie audytu strony pod względem bezpieczeństwa i poprawności (kodowania i wyglądu) – zaakceptowanego przez Zleceniodawcę. Podstawą akceptacji jest poprawienie zauważonych błędów, lub wskazanie tych błędów, których poprawa wykracza poza zakres projektu (stare treści niemożliwe do poprawienia poprzez „wyczyszczenie” stylów lub automatyczną poprawę kodowania).
6. Pozytywny odbiór nowej strony potwierdzony badaniami ankietowymi użytkowników.