Chciałbym podzielić się kilkoma istotnymi zasadami, które, mam nadzieję, że pomogą ustanowić efektywne podstawy dla modelowania wymogów metodą agile (i nie tylko).
1. "Niezwykle ważny jest aktywny udział osób zainteresowanych”. Udziałowcy projektu powinni przekazywać swoje wymagania, nadawać im priorytety oraz w odpowiednim czasie podejmować decyzję. Istotnym jest, aby udziałowcy projektu zrozumieli tę koncepcję i angażowali się od początku projektu.
2. "Oprogramowanie musi być oparte na wymaganiach”. Jeśli nie ma wymagań, nie ma czego budować. Celem Tworzenia Oprogramowania jest zbudowanie działającego oprogramowania, które spełnia wymogi udziałowców projektu. Jeśli nie znasz tych potrzeb, nie jest w stanie odnieść sukcesu.
3. "Nie należy budować niczego, co nie spełnia wymogów”. Twój system musi być oparty na wymaganiach, całościowo na wymaganiach, i na niczym innym jak na wymaganiach.
4. "Celem jest wzajemne zrozumienie, nie dokumentacja”. Podstawowym celem procesu zbierania wymagań jest zrozumienie, czego chcą udziałowcy. To, czy stworzysz szczegółową dokumentację opisującą te wymagania, czy być może jedynie zbiór odręcznych szkiców czy notatek, to już zupełnie inna sprawa.
5. "Wymagania pochodzą od udziałowców, nie od programistów”. Udziałowcy projekty są jedynym źródłem wymogów. Tak, programiści mogą sugerować wymagania, ale udziałowcy muszą zaakceptować te sugestie.
6. "Używaj terminologii udziałowców”. Nie zmuszaj udziałowców projektu do używania sztucznego, technicznego żargonu. To oni zajmują się modelowaniem – i to dla nich budowany jest system — , dlatego też podczas modelowania systemu powinieneś używać ich terminologii.
7. "Pokazuj modele publicznie”. Modele są ważną częścią kanałów komunikacyjnych, ale działają tylko wtedy, gdy ludzie je widzą i rozumieją. Głęboko wierzę w koncepcję publicznego ujawniania modeli tak, aby każdy miał do nich dostęp i mógł z nimi pracować, nawet, jeśli są to tylko szkice lub arkusze ewidencyjne.
8. "Wymagania z czasem zmieniają się”. Ludzie często nie wiedzą, czego chcą – a jeśli wiedzą, to zazwyczaj nie wiedzą jak to przekazać. Co więcej, ludzie zmieniają zdanie – dość często można słyszeć jak udziałowcy mówią „Teraz, kiedy sobie to przemyślałem…” lub „Nie to miałem na myśli”. Co gorsza, środowisko zewnętrzne też się zmienia – być może Twoja konkurencja ogłosiła nową strategię, lub rząd uchwalił nową ustawę. Efektywni programiści akceptują fakt, iż zmiany się zdarzają, a nawet lepiej, wykorzystują to.
9. "Wymogom należy nadać priorytety”. Udziałowcy muszą nadać priorytety wymaganiom, umożliwiając Ci w ten sposób stałą pracę nad najważniejszymi i w ten sposób dostarczenie tych mających największą wartość dla ich inwestycji informatycznych.
10. "Wymagania muszą być jedynie wystarczająco dobre”. Nie doskonałe? Ale w ten sposób zbuduje się nie to, co potrzeba! Programiści agile nie potrzebują doskonałych specyfikacji wymagań, nie potrzebują też kompletnych specyfikacji, jako że mają dostęp do udziałowców. Nie jesteś pewien, co ma oznaczać dany wymóg, bo masz za mało szczegółów? Porozmawiaj z udziałowcem i pozwól mu wyjaśnić; jeśli nie potrafi tego wyjaśnić, rozmawiaj dalej.
11. "Używaj prostych, ogólnych narzędzi i technik”. Możliwym jest, a nawet pożądanym, aktywny udział osób zainteresowanych w modelowaniu. Nie mniej jednak udziałowcy zazwyczaj nie znają technik modelowania ani skomplikowanych narzędzi do modelowania. Jedną z opcji jest poświęcenie kilku miesięcy na przeszkolenie udziałowców z zakresu technik i narzędzi modelujących, ale o wiele lepszym podejściem jest użycie prostych narzędzi, takich jak białe tablice i kartki papieru, oraz prostych technik modelowania. Proste narzędzie i techniki są łatwe do nauczenia, dlatego też są one ogólne- każdy może z nimi pracować. Nie strasz ludzi technologią, jeśli nie ma takiej potrzeby!
12. "I tak będziesz musiał wytłumaczyć techniki – nawet te najprostsze”. Jako że ludzie najlepiej się uczą poprzez praktykę najczęściej najlepszym pomysłem jest poprowadzenie udziałowców przez kilka przykładów tworzenia.
13. "Większość wymogów powinna być niezależna od technologii”. Wzdrygam się, kiedy słyszę terminy takie, jak „zorientowane na obiekt”, „strukturalne” lub „oparte na komponencie” wymagania. Wszystkie te terminy to kategorie technologii wdrażania i dlatego tez odzwierciedlają kwestie architektoniczne i projektowe.
14. "Niektóre wymagania są techniczne”. Ważnym jest być świadomym tego, że niektóre wymagania, takie jak ograniczenia techniczne mówiące, iż Twój system musi używać standardowych technologii J2EE i relacyjnej bazy danych stosowanych w Twojej organizacji, są tak naprawdę zależnie od technologii. Twoi udziałowcy muszą zrozumieć, kiedy ma to zastosowanie i dlaczego.
15. “Potrzebujesz wielu modeli”. Wymagania odnoszące się do systemu są zazwyczaj złożone, jako że dość często obejmują wiele kwestii. Jako że każdy model ma swoje mocne i słabe strony, żaden pojedynczy model nie jest wystarczający; dlatego też aby móc wykonać swoje zadanie będziesz potrzebował kilka rodzajów modeli.
16. "Potrzebujesz jedynie podzestawu modeli”. Kiedy naprawiasz coś w domu używasz jedynie kilku ze swoich narzędzi, takich jak śrubokręt i klucz francuski. Następnym razem, gdy coś naprawiasz, możesz użyć innych narzędzi. Pomimo tego, że masz wiele narzędzi, nie używasz ich wszystkich naraz. Tak samo jest w przypadku Tworzenia Oprogramowania: Pomimo, że w swojej „intelektualnej skrzynce na narzędzia” posiadasz kilka technik, przy danym projekcie używasz jedynie podzestawu.
17. "Proces podstawowy determinuje niektóre artefakty”. Różne metodologie wymagają różnych artefaktów wymagań. Na przykład RUP, EUP wymagają przypadków użycia, XP wymaga user stories a FDD wymaga cech.
18. "Zaadaptuj podejście wszerz”. Lepiej jest namalować najpierw szeroki pas ziemi, aby spróbować wyobrazić sobie całość, niż ledwo skupiać się na małym aspekcie systemu. Poprzez zaadaptowanie podejścia „wszerz” szybko zaczynasz ogólnie rozumieć system, a i tak cały czas możesz zagłębić się w szczegóły jeśli tylko istnieje taka potrzeba. Adaptując podejście AMDD to szerokie rozumienie może przyjść wraz z początkowym modelowaniem podczas „Cyklu 0”.
19. "Zacznij od modelu biznesowego przedsiębiorstwa”. Niektóre organizacje posiadają tak zwane modele biznesowe przedsiębiorstwa, które odzwierciedlają ich wymagania biznesowe wysokiego stopnia. Jeśli Twoja organizacja posiada takowy, i jest on obowiązujący, to stanowi on doskonały punkt wyjściowy do zrozumienia zarówno organizacji i tego, jak system wpasowuje się w ogólny obraz. Powinieneś być w stanie zidentyfikować, które wymogi biznesowe wysokiego stopnia Twój system spełni (być może częściowo); w przeciwnym wypadku jest to czytelnym sygnałem, że albo Twój model jest nieaktualny, albo nie jest potrzebny organizacji.
Powodzenia 
Goście z SAFECode opracowali ciekawy guide dla Agile’owców. Jest tam mowa o takim prowadzeniu projektu, żeby już w pierwszej fazie brano pod uwagę kwestie bezpieczeństwa. Można sobie ściągnąć PDFa – niestety tylko po angielsku