Помимо стандартных требований к поведению (или функциональности) разрабатываемого приложения крайне важно выявлять и документировать так называемые нефункциональные требования. Именно они будут отвечать за стабильность и надежность работы приложения, что является не менее важной оценкой успешности проекта, после того как разработанное приложение позволяет выполнять основные возложенные на него функции.

В одном из постов мы приводили пример описания архитектуры по стандарту IEEE 1471: Кому пригодится архитектурное описание?

Перед составлением архитектурного описания разработанного приложения, или программы, которая только планируется к разработке, необходимо четко определиться для кого создается архитектурный документ. Проблема в том, что нельзя создать всеобъемлющее и полное описание архитектуры программного приложения, поскольку это очень многогранное представление. Вы можете потерять много времени впустую и к этому моменту архитектура уже может измениться.

В коллекции наглядных картинок о Scrum пополнение - Visual Studio ALM Rangers Projects Scrum Guide, результат командной работы VSTS Rangers.

vtstalm

Единственное, на мой взгляд, для объяснения Scrum "с нуля" может показаться перегруженной для восприятия.

Ну и еженедельные скрамы, вместо ежедневных, немного настораживают :)

Зато явно прописано, что нужно иметь Definition of Done и Sprint Goal - об этом часто забывают.

Но все равно, лучшая по своей наглядности картинка у Mike Cohn:

cohnscrum

При разработке достаточно сложного или крупного приложения необходимо уделять особое внимание проектированию и документированию его архитектуры. В DEVPROM есть отдельная фаза, которая называется "Проектирование" в рамках которой участники проекта могут готовить соответствующие диаграммы или модели. Существует достаточно много инструментов для проектирования и документирования программной архитектуры и дизайна. В DEVPROM можно загружать готовые модели или вставлять изображения подготовленных диаграмм. Это может быть особенно полезно, если не все участники проекта владеют или хотят устанавливать дополнительное ПО для просмотра диаграмм.

Любая команда, занимающаяся разработкой ПО, вырабатывает собственный стиль оформления документации и самостоятельно определяет уровень детализации и охвата документируемой информации.