Я собираюсь написать некоторые стандарты/рекомендации и шаблоны, которые будут использовать руководители проектов, разработчики и бизнес-аналитики. Целью было бы лучше понять решение, которое было или было разработано.
Одной из частей является предоставление стандарта/рекомендации по документированию решения. Например. документируя часть программного обеспечения, которая решает/отвечает требованиям бизнес-кейса/пользователя.
Теперь, будучи самим программистом, я вижу, что невозможно диктовать и говорить "каждое решение должно определять X, используя Y и представляя его в соответствии с Z.", поскольку X Y Z не всегда применимо и т.д.
Тем не менее, я знаю даже для своих проектов по хобби. Я всегда описываю свои решения так или иначе, модули/компоненты, комментарии к исходному коду, API, модель базы данных, некоторую таксономию, журнал журнала, формат xml и т.д...
Итак, чтобы продолжить работу, я был бы очень признателен, если бы вы могли поделиться тем, что вы документируете, чтобы описать свое решение (и предпочтительно также, как и почему). Я знаю, что он будет сильно отличаться в зависимости от многих вещей, но любой общий или конкретный ответ представляет интерес. Спасибо.
Обновление Это было непонятно, но я не имел в виду требования пользователей с X Y Z. Я имел в виду все возможные типы документации, которые могут иметь система. Поэтому прочитайте его как "невозможно заявить, что каждое решение должно иметь: список необходимых фреймворков, руководство по эксплуатации для серверного программного обеспечения, требуемые основные данные, матрицу требований пользователей и тестов, спецификацию пользовательского интерфейса. Хотя имеет смысл создать такой ограниченный набор требований, трудно быть четким и точным, поскольку то, что является самым важным/релевантным, отличается от проекта к проекту.
Кроме того, я спросил об этом довольно давно и никогда не принимал ответа, извините за это. Возможно, поскольку это открытый вопрос, было бы лучше, чем сообщество wiki?