Как написать функциональную спецификацию быстро и эффективно

Так что я просто прочитал некоторые потрясающие статьи Джоэла о спецификациях здесь . (Написано в 2000 году!) Я прочитал все 4 части, но я ищу методические подходы к написанию своих спецификаций.

Я единственный разработчик, работающий над этим довольно сложным приложением (или семейством приложений) для очень известной финансовой компании.

Я никогда не делал что-то настолько серьезное, я начал писать что-то вроде плохой спецификации, какой-то обзор, и это потеряло МНОГО моего времени.

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

Я думаю, что ошибка, которую я совершил до сих пор, заключается не в написании подробных спецификаций, поэтому я сейчас к этому подхожу.

Так что все это состоит из

• Сайт MVC (для администраторов и просмотра данных)
• 2 модуля Silverlight (для 2 конкретных задач)
• 1 настольное приложение

У меня совсем мало времени, ресурсов и нужно сделать это быстро, а также нужно, чтобы эти парни прочитали это одинаково быстро и безболезненно.

• Итак, как мне это сделать, я ищу какие-либо советы, любые вещи из реального мира, как вы, ребята, обычно делаете это?
• Вы делаете макет скрининг каждого диалога / формы / страницы?

Я подумываю сделать фиктивный проект ASP.NET Web Forms, а затем заполнить HTML- файлы в папках и сделать его похожим на мою структуру URL MVC.

Затем создайте раздел в спецификации для веб-сайта и напишите страницу для каждого URL-адреса, который я получил со скринингом.

Для моего приложения Win Form я создал демо-проект Win Form. Затем я вставил бы диалоговое окно или структурировал бы все как в реальном приложении, а затем сделал бы снимок экрана?

Для некоторого фона в этом вопросе. Я всегда был сумасшедшим любопытным парнем, который работал нормально, но для приложения, над которым я работаю, оно не только сложное, но и для очень известной и крупной компании, и я должен ее получить право!

(И пока все шло хорошо, сегодня я представил демо-версию предварительной версии, которая понравилась многим людям !! = D)

Если я правильно разработаю первоначальный дизайн, у меня также будет отличный бизнес с этой компанией, уже многие думают о новых «потрясающих» функциях, за которые они готовы платить.

Вы читали вторую часть статьи или его пример спецификации ? Они воплощают пару важных принципов при написании спецификации.

• Не переусердствуйте. Цель написания спецификации - заставить вас задуматься о таких важных вещах, как то, что происходит в случае ошибки, и то, как вы ожидаете, что пользователь будет взаимодействовать с системой. Вам не нужно вдаваться в непонятные детали, чтобы получить что-то, из чего вы можете работать. Вам нужны детали, хотя.
• Это о связи. Цель спецификации - прийти к общему соглашению о том, что необходимо сделать. Это не железный документ, который требует силы закона. Это инструмент, который поможет вам лучше понять вашего клиента, а ваш клиент - лучше понять, что вы хотите для него сделать.

Лучший совет - писать достаточно, чтобы вы знали, что вам нужно делать. Если у вас есть открытые вопросы, запишите их в спецификации и получите ответы от своего клиента. Как только вы адекватно понимаете, что нужно прекратить .

Если вы не будете осторожны, документ обретет собственную жизнь. У него должна быть одна цель - не добавлять в документ ничего, что не соответствует этой цели. Это должно быть легко поддерживать. Если у вас есть все ваши подробные диаграммы классов вместе с другими деталями, которые действительно относятся к юнит-тесту, вы либо откажетесь от документа, потому что содержание слишком много, либо вы никогда не завершите проект.

О написании

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

• Знай свою аудиторию. Кто должен читать спецификации? Если это только вы и клиент, то это тот, кому вы пишете. Если у вас есть кто-то, кто отвечает за тестирование, у вас также будут для него заметки.
• Начните с наивысшего приоритета. Хотя аутентификация важна, экран входа в систему, вероятно, является наиболее понятной частью, которую приходится писать большинству людей. Вместо этого сосредоточьтесь на той функции, которая нужна вашим пользователям больше всего. Вы знаете, та часть, которая приносит им деньги и является единственной причиной, по которой им нужно программное обеспечение.
• Заполните детали, когда возникнут вопросы, и вы получите ответы. Сохраняйте вещи по-настоящему простыми, используя рисунки салфеток, пока клиент не будет доволен расположением. Важно знать, какая информация задействована и как они будут ее использовать.
• Стоп, когда добавление больше не добавляет ценности. Есть некоторые детали, которые вы просто не хотите в спецификации. Вы должны знать, когда у вас есть правильные вещи. Вам не нужно знать, что внутри метода есть переменная с именем «albaquerque». Это исходный код, а не спецификации.