Temat: Przykład specyfikacji wymagań

Przykład specyfikacji dla aplikacji do rezerwacji zasobów przy uzyciu task descriptions:
http://modelowanieiuzytecznosc.weebly.com/przyklad-spe...

Czekam na wasze uwagi. Przykład jeszcze nie w pełni gotowy ale będzie w miarę czasu uzupełniony.

Temat: Przykład specyfikacji wymagań

Łukasz P.:
Przykład specyfikacji dla aplikacji do rezerwacji zasobów przy uzyciu task descriptions:
http://modelowanieiuzytecznosc.weebly.com/przyklad-spe...

Czekam na wasze uwagi. Przykład jeszcze nie w pełni gotowy ale będzie w miarę czasu uzupełniony.

to chyba zapis słowny programu strukturalnego...

Temat: Przykład specyfikacji wymagań

Na pewno nie. Tu nie ma mowy o żadnym programie. Zanim zaczyna się programowanie należy określić wymagania jakie mają klienci i użytkownicy. Należy zrozumieć na czym polega ich praca. Program można tworzyć dopiero po zrozumieniu potrzeb a nie na odwrót. Zachęcam do lektury:
http://www.it-c.dk/people/slauesen/Papers/IEEEtasks.pdf

Temat: Przykład specyfikacji wymagań

Bardzo ładna i dokładna specyfikacja, ja osobiście spróbował bym jeszcze dodać modele graficzne np. jakieś diagramy aktywności i stanu, wygodnie się przegląda dla osób, które nie chcą wdawać się w szczegóły, a chcą znać tematykę (zarząd, komitet, kierownicy zespołów nieprodukcyjnych). Stworzenie takich diagramów ułatwia tworzenie scenariuszy testowych, jak już aplikacja powstanie, tester powinien wiedzieć jak ma się zachować. Oczywiście wynikiem takich zapisów (na bieżąco uszczegóławianych) jest piękna dokumentacja merytoryczna.
Z doświadczenia też wiem, że zespołom realizującym projekt łatwiej się porozumiewać za pomocą grafiki, gdyż niektóre zapisy słowne, które są dla Ciebie oczywiste dla innych też mogą być oczywiste, ale "inaczej" :)
Tak czy siak, opis bardzo fajny, powodzenia.

Temat: Przykład specyfikacji wymagań

Łukasz P.:
Przykład specyfikacji dla aplikacji do rezerwacji zasobów przy uzyciu task descriptions:
http://modelowanieiuzytecznosc.weebly.com/przyklad-spe...

Czekam na wasze uwagi. Przykład jeszcze nie w pełni gotowy ale będzie w miarę czasu uzupełniony.

Próbujesz rozwiązać problem NP-zupełny.
http://en.wikipedia.org/wiki/Generalized_assignment_pr...

"Dokumentacja" idzie do kosza i nie próbuję być złośliwy.
Ta -tona- teksu jaką udostępniłeś jest "o niczym". Jeśli ktoś jest zainteresowany to mogę rozwinąć myśl.Ten post został edytowany przez Autora dnia 12.03.14 o godzinie 21:01

Temat: Przykład specyfikacji wymagań

Kontrpropozycje podejścia do "pełnej" dokumentacji ;)
http://it-consulting.pl/autoinstalator/wordpress/2013/...

Temat: Przykład specyfikacji wymagań

Jakub W.:
ktoś jest zainteresowany to mogę rozwinąć myśl.

rozwiń

Temat: Przykład specyfikacji wymagań

Jarosław Ż.:

Jakub W.:
ktoś jest zainteresowany to mogę rozwinąć myśl.

rozwiń

Właściwie powinienem to zrobić w pierwszym poście... niestety ilość uwag jakie miałem trochę mnie przytłoczyła.

1. Kto jest obiorcą takiego dokumentu ?

2. Pierwsza część (Problem biznesowy, Propozycja rozwiązania, Opis środowiska pracy, Reguły biznesowe) jest zbędna. To nie jest ani analiza biznesowa (na podstawie której ktoś zdecydował się na stworzenie systemu informatycznego) ani część specyfikacji wymagań.

3. Model danych powinien wynikać ze specyfikacji wymagań a nie być jej częścią.

4. Czym jest "Częstotliwość zadania, Krytyczna częstotliwość" ?

5. Co oznacza: "przykładowe rozwiązanie". To ma być takie rozwiązanie czy może być jakieś inne ?

6. Brak informacji nt. funkcjonalności związanej z "grupami". Kto nimi zarządza ?

7. "Łatwe zwiększanie lub skracanie czasu w krokach 15 min". Mieszanie wymagań funkcjonalnych z wymaganiami dla widoków / ułatwień (zapamiętywanie danych podawanych przez użytkownika).

8. "5. Znaleźć listę wolnych sal w terminach kiedy wszyscy uczestnicy są dostępni." Czy te sale mają spełniać wymagania z punktu 4 (w dokumencie) ?

9. "System powinien umożliwić wyszukanie dwóch sal gdzie wprowadzając przerwę na zmianę sali można by zorganizować spotkanie. " to jest nowa, potencjalnie złożona i nigdzie nie opisana funkcjonalność (i jest sprzeczna z modelem danych)

10. "poinformować, przypomnieć". ?

11. W modelu danych nie ma "Agendy" ani "Celu" spotkania.

12. Kto to jest "Zajęty uczestnik" / "Dostępny uczestnik" ?

13. "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." ? Nie rozumiem co autor miał na myśli ...

14. Kto to jest "posiadacz rezerwacji" ?

15. Ile to jest "duża liczba spotkań" ? Czy spotkanie to rezerwacja ? I co właściwie powinno się stać po "akceptacji prośby o zwolnienie rezerwacji" ?

16. 5. Przenieść rezerwację do nowego organizatora. To znaczy, że każda rezerwacja ma swojego organizatora ? A skąd wiadomo kto to jest, skoro organizator nie musi być na liście uczestników ? Znów - niespójny model.

17. Jak można zarządzać użytkownikami tej aplikacji ?

Mógłbym tak wymieniać na prawdę długo ...

Po drugiej lekturze myślałem, że moja wczorajsza opinia była trochę przesadzona.

Po trzeciej i czwartej - z tej specyfikcji wymagań na prawdę niewiele wynika.Ten post został edytowany przez Autora dnia 13.03.14 o godzinie 14:05

Temat: Przykład specyfikacji wymagań

Jeżeli z czymś nie polemizuje to przemilczałem :)

Jakub W.:

1. Kto jest obiorcą takiego dokumentu ?

2. Pierwsza część (Problem biznesowy, Propozycja rozwiązania, Opis środowiska pracy, Reguły biznesowe) jest zbędna. To nie jest ani analiza biznesowa (na podstawie której ktoś zdecydował się na stworzenie systemu informatycznego) ani część specyfikacji wymagań.

Reguły biznesowe to logika jaką ma (zakładam) realizować aplikacja, trzeba je więc udokumentować i uczynić wymaganiem.

3. Model danych powinien wynikać ze specyfikacji wymagań a nie być jej częścią.

to zależy jak traktujemy wymagania (można od developera wymagać ładnego domu a można mu dać do wykonania projekt, w drugim przypadku zaskoczenie tym co powstanie raczej nie występuje). Po drugie to zależy o metody pracy, idąc drogą "obiektową" model dany w ogóle nie wystąpi na etapie projektowania, to dopiero implementacja.

4. Czym jest "Częstotliwość zadania, Krytyczna częstotliwość" ?

ja tez nie wiem

5. Co oznacza: "przykładowe rozwiązanie". To ma być takie rozwiązanie czy może być jakieś inne ?

jak wyżej

6. Brak informacji nt. funkcjonalności związanej z "grupami". Kto nimi zarządza ?

jak wyżej

7. "Łatwe zwiększanie lub skracanie czasu w krokach 15 min". Mieszanie wymagań funkcjonalnych z wymaganiami dla widoków / ułatwień (zapamiętywanie danych podawanych przez użytkownika).

prawda

8. "5. Znaleźć listę wolnych sal w terminach kiedy wszyscy uczestnicy są dostępni." Czy te sale mają spełniać wymagania z punktu 4 (w dokumencie) ?

to miejsce na reguły biznesowe

9. "System powinien umożliwić wyszukanie dwóch sal gdzie wprowadzając przerwę na zmianę sali można by zorganizować spotkanie. " to jest nowa, potencjalnie złożona i nigdzie nie opisana funkcjonalność (i jest sprzeczna z modelem danych)

to kolejna reguła biznesowa

10. "poinformować, przypomnieć". ?

11. W modelu danych nie ma "Agendy" ani "Celu" spotkania.

12. Kto to jest "Zajęty uczestnik" / "Dostępny uczestnik" ?

13. "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." ? Nie rozumiem co autor miał na myśli ...

14. Kto to jest "posiadacz rezerwacji" ?

15. Ile to jest "duża liczba spotkań" ? Czy spotkanie to rezerwacja ? I co właściwie powinno się stać po "akceptacji prośby o zwolnienie rezerwacji" ?

16. 5. Przenieść rezerwację do nowego organizatora. To znaczy, że każda rezerwacja ma swojego organizatora ? A skąd wiadomo kto to jest, skoro organizator nie musi być na liście uczestników ? Znów - niespójny model.

17. Jak można zarządzać użytkownikami tej aplikacji ?

Mógłbym tak wymieniać na prawdę długo ...

Po drugiej lekturze myślałem, że moja wczorajsza opinia była trochę przesadzona.

Po trzeciej i czwartej - z tej specyfikcji wymagań na prawdę niewiele wynika.

wypada się zgodzić

Temat: Przykład specyfikacji wymagań

Jarosław Ż.:
Jeżeli z czymś nie polemizuje to przemilczałem :)

Jakub W.:
1. Kto jest obiorcą takiego dokumentu ?

2. Pierwsza część (Problem biznesowy, Propozycja rozwiązania, Opis środowiska pracy, Reguły biznesowe) jest zbędna. To nie jest ani analiza biznesowa (na podstawie której ktoś zdecydował się na stworzenie systemu informatycznego) ani część specyfikacji wymagań.

Reguły biznesowe to logika jaką ma (zakładam) realizować aplikacja, trzeba je więc udokumentować i uczynić wymaganiem.

No właśnie. Wymagania wynikają z reguł, więc po co ktoś te reguły przedstawia w wymaganiach ?

3. Model danych powinien wynikać ze specyfikacji wymagań a nie być jej częścią.

to zależy jak traktujemy wymagania (można od developera wymagać ładnego domu a można mu dać do wykonania projekt, w drugim przypadku zaskoczenie tym co powstanie raczej nie występuje).

W tym przypadku chodzi o specyfikację "rozwiązania" (biznesowego!) a nie "wymagań".
Podoba mi się takie podejście :)

8. "5. Znaleźć listę wolnych sal w terminach kiedy wszyscy uczestnicy są dostępni." Czy te sale mają spełniać wymagania z punktu 4 (w dokumencie) ?

to miejsce na reguły biznesowe

pozostaje mieć nadzieję, że z czegoś one wynikają.

10. "poinformować, przypomnieć". ?

11. W modelu danych nie ma "Agendy" ani "Celu" spotkania.

12. Kto to jest "Zajęty uczestnik" / "Dostępny uczestnik" ?

13. "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." ? Nie rozumiem co autor miał na myśli ...

14. Kto to jest "posiadacz rezerwacji" ?

15. Ile to jest "duża liczba spotkań" ? Czy spotkanie to rezerwacja ? I co właściwie powinno się stać po "akceptacji prośby o zwolnienie rezerwacji" ?

16. 5. Przenieść rezerwację do nowego organizatora. To znaczy, że każda rezerwacja ma swojego organizatora ? A skąd wiadomo kto to jest, skoro organizator nie musi być na liście uczestników ? Znów - niespójny model.

17. Jak można zarządzać użytkownikami tej aplikacji ?

Mógłbym tak wymieniać na prawdę długo ...

Po drugiej lekturze myślałem, że moja wczorajsza opinia była trochę przesadzona.

Po trzeciej i czwartej - z tej specyfikcji wymagań na prawdę niewiele wynika.

wypada się zgodzić

"Starszy Specjalista ds Analizy Biznesowej, ABB" :\

Temat: Przykład specyfikacji wymagań

Jakub W.:

Jarosław Ż.:
Jeżeli z czymś nie polemizuje to przemilczałem :)

Jakub W.:
1. Kto jest obiorcą takiego dokumentu ?

2. Pierwsza część (Problem biznesowy, Propozycja rozwiązania, Opis środowiska pracy, Reguły biznesowe) jest zbędna. To nie jest ani analiza biznesowa (na podstawie której ktoś zdecydował się na stworzenie systemu informatycznego) ani część specyfikacji wymagań.

Reguły biznesowe to logika jaką ma (zakładam) realizować aplikacja, trzeba je więc udokumentować i uczynić wymaganiem.

No właśnie. Wymagania wynikają z reguł, więc po co ktoś te reguły przedstawia w wymaganiach ?

nie wiem jak definiujesz pojęcie "wymaganie" ;) Język polski robi to tak: "wymaganie: warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać"

reguły mamy różne, może to być np. "Jeżeli udzielamy klientowi upustu, to wolno to zrobię tylko zgodnie z obowiązującą danego klienta tabela upustów", inna reguła "jeżeli wartość jakiegokolwiek zakupu przekracza ustalony próg, zamówienie na taki zakup musi zaakceptować Prezes", dalej reguła decyzyjna "wartości progów finansowych ustala co miesiąc Gł. Księgowa".

I jeżeli mój klient planuje zakup systemu obiegu dokumentów, to te reguły są wymaganiem. Są to tak zwane wymagania dziedzinowe (poza funkcjonalnymi i pozafunkcjonalnymi).

3. Model danych powinien wynikać ze specyfikacji wymagań a nie być jej częścią.

to zależy jak traktujemy wymagania (można od developera wymagać ładnego domu a można mu dać do wykonania projekt, w drugim przypadku zaskoczenie tym co powstanie raczej nie występuje).

W tym przypadku chodzi o specyfikację "rozwiązania" (biznesowego!) a nie "wymagań".
Podoba mi się takie podejście :)

ja się nauczyłem, że dobrym wymaganiem jest owa specyfikacja bo minimalizuje ryzyko ;)

8. "5. Znaleźć listę wolnych sal w terminach kiedy wszyscy uczestnicy są dostępni." Czy te sale mają spełniać wymagania z punktu 4 (w dokumencie) ?

to miejsce na reguły biznesowe

pozostaje mieć nadzieję, że z czegoś one wynikają.

z logiki (o ile tam taka funkcjonuje), jeżeli nie to bywa, że taniej jest dać użytkownikowi ładny schemat sal i 'drag&drop" do ręcznego rozkładania zajęć, tak jak się teraz rezerwuje bilety w kinach.

"Starszy Specjalista ds Analizy Biznesowej, ABB" :\

...Ten post został edytowany przez Autora dnia 14.03.14 o godzinie 07:45

Temat: Przykład specyfikacji wymagań

2. Pierwsza część (Problem biznesowy, Propozycja rozwiązania, Opis środowiska pracy, Reguły biznesowe) jest zbędna. To nie jest ani analiza biznesowa (na podstawie której ktoś zdecydował się na stworzenie systemu informatycznego) ani część specyfikacji wymagań.

Reguły biznesowe to logika jaką ma (zakładam) realizować aplikacja, trzeba je więc udokumentować i uczynić wymaganiem.

No właśnie. Wymagania wynikają z reguł, więc po co ktoś te reguły przedstawia w wymaganiach ?

nie wiem jak definiujesz pojęcie "wymaganie" ;) Język polski robi to tak: "wymaganie: warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać"

W tym przypadku język polski trochę zawodzi ponieważ nie rozróżnia -wymagań- implicite od explicite.

Wymaganie może przyjąć formę: " a ... napisz mi program do rozstrzygania problemu stopu (http://en.wikipedia.org/wiki/Halting_problem)"

albo

"zaimplementuj -ten- algorytm".

Pisząc "Wymagania wynikają z reguł" założyłem, że reguły to pewne zasady których nie można naruszyć. Znajomość zasad których nie można naruszyć nie wystarczy do tworzenia "dobrych" systemów.

PS: wszelkie zabawy ze słownikiem kończą się na pojęciach niedefiniowalnych albo na definicji cyklicznej (jak słownik polski definiuje pojęcie "warunku" ?) ;-)

reguły mamy różne, może to być np. "Jeżeli udzielamy klientowi upustu, to wolno to zrobię tylko zgodnie z obowiązującą danego klienta tabela upustów", inna reguła "jeżeli wartość jakiegokolwiek zakupu przekracza ustalony próg, zamówienie na taki zakup musi zaakceptować Prezes", dalej reguła decyzyjna "wartości progów finansowych ustala co miesiąc Gł. Księgowa".

I jeżeli mój klient planuje zakup systemu obiegu dokumentów, to te reguły są wymaganiem. Są to tak zwane wymagania dziedzinowe (poza funkcjonalnymi i pozafunkcjonalnymi).

Reguły można zdefiniować dość ogólnie.
Na to się "skarżę" ;)

8. "5. Znaleźć listę wolnych sal w terminach kiedy wszyscy uczestnicy są dostępni." Czy te sale mają spełniać wymagania z punktu 4 (w dokumencie) ?

to miejsce na reguły biznesowe

pozostaje mieć nadzieję, że z czegoś one wynikają.

z logiki (o ile tam taka funkcjonuje), jeżeli nie to bywa, że taniej jest dać użytkownikowi ładny schemat sal i 'drag&drop" do ręcznego rozkładania zajęć, tak jak się teraz rezerwuje bilety w kinach.

Myślę, że nie chodzi o logikę jaką kierował się twórca, a o "domyślność" odbiorcy dokumentu.
Tak na prawdę nie wiadomo (nie zostało to opisane) czy "proponowane sale" mają spełniać warunki zdefiniowane w punkcie 4.

Może między analitykami (przynajmniej niektórymi) i programistami powinni być "domyślatorzy"

"Starszy Specjalista ds Analizy Biznesowej, ABB" :\

...

To jest trochę straszne ...

"Na pewno nie. Tu nie ma mowy o żadnym programie. Zanim zaczyna się programowanie należy określić wymagania jakie mają klienci i użytkownicy. Należy zrozumieć na czym polega ich praca. Program można tworzyć dopiero po zrozumieniu potrzeb a nie na odwrót. "

... specyfikacja wymagań

Temat: Przykład specyfikacji wymagań

Jakub W.:

nie wiem jak definiujesz pojęcie "wymaganie" ;) Język polski robi to tak: "wymaganie: warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać"

W tym przypadku język polski trochę zawodzi ponieważ nie rozróżnia -wymagań- implicite od explicite.

Wymaganie może przyjąć formę: " a ... napisz mi program do rozstrzygania problemu stopu (http://en.wikipedia.org/wiki/Halting_problem)"

albo

"zaimplementuj -ten- algorytm".

j.polski jest OK, program albo spełnia wymagania czyli pozwala osiągnąć oczekiwany efekt albo nie, reszta to problemy inżynierskie....

Pisząc "Wymagania wynikają z reguł" założyłem, że reguły to pewne zasady których nie można naruszyć. Znajomość zasad których nie można naruszyć nie wystarczy do tworzenia "dobrych" systemów.

reguły to to co napisałeś, co do tworzenia "dobrych systemów" to one powinny spełniać wymagania, np. jeżeli reguła mówi "nie można umieścić na fakturze towaru w ilości większej niż ilość dostępna w magazynie" program, który wystawia faktury z respektowaniem tej reguły spełnia to wymaganie.

PS: wszelkie zabawy ze słownikiem kończą się na pojęciach niedefiniowalnych albo na definicji cyklicznej (jak słownik polski definiuje pojęcie "warunku" ?) ;-)

w dokumentacji umieszcza się słownik by była ona jednoznaczna...

Reguły można zdefiniować dość ogólnie.
Na to się "skarżę" ;)

dobrze zdefiniowane reguły, tam gdzie jest to konieczne, mają zdefiniowane kryteria decyzyjne (np. tablice decyzyjną).

Może między analitykami (przynajmniej niektórymi) i programistami powinni być "domyślatorzy"

:))) nie, produkt analityka powinien być w 100% jednoznaczny ale bo nie spełnia swojej roli :)

Temat: Przykład specyfikacji wymagań

Jarosław Ż.:

Jakub W.:

nie wiem jak definiujesz pojęcie "wymaganie" ;) Język polski robi to tak: "wymaganie: warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać"

W tym przypadku język polski trochę zawodzi ponieważ nie rozróżnia -wymagań- implicite od explicite.

Wymaganie może przyjąć formę: " a ... napisz mi program do rozstrzygania problemu stopu (http://en.wikipedia.org/wiki/Halting_problem)"

albo

"zaimplementuj -ten- algorytm".

j.polski jest OK, program albo spełnia wymagania czyli pozwala osiągnąć oczekiwany efekt albo nie, reszta to problemy inżynierskie....

Co należy zrobić w sytuacji, kiedy mamy jedno wymaganie i brzmi ono: system usprawnia funkcjonowanie firmy ?
:-). Z jednej strony to jest to wymaganie ( a nawet "matka wymagań wszystkich systemów biznesowych" ) z drugiej - kompletnie nic nie znaczy (może chodzi o system automatycznie rozwiązujący "pasjansa").

Pojęcie "wymagania" (w kontekście systemów IT) chyba warto (o ile jest to możliwe) doprecyzować.

Może między analitykami (przynajmniej niektórymi) i programistami powinni być "domyślatorzy"

:))) nie, produkt analityka powinien być w 100% jednoznaczny ale bo nie spełnia swojej roli :)

Mi to pachnie nową metodyką realizacji projektów. :-)

Analitycy będą analizować. Projektanci - projektować, a programiści - programować.
Ludzie kupią wszystko, trzeba tylko wymyślić jakąś dobrą nazwę ... ;-)Ten post został edytowany przez Autora dnia 17.03.14 o godzinie 19:52

Temat: Przykład specyfikacji wymagań

Jakub W.:
Co należy zrobić w sytuacji, kiedy mamy jedno wymaganie i brzmi ono: system usprawnia funkcjonowanie firmy ?

należy zdefiniować pojęcie "usprawnia funkcjonowanie firmy"...