Как написать спецификацию, которая будет продуктивной?

Question

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

С одной стороны, эти многословные документы, которые выдаются программисту, могут привести к тому, что он / она упустят несколько вещей. Лично я боюсь спецификации документов Word ... Я думаю, что это из-за моего стиля чтения ... Я всегда быстро читаю вещи, которые, я думаю, заставят меня упустить ключевые моменты.

С другой стороны, я видел эти инновационные спецификации, написанные в Excel одним из наших клиентов. Он использовал для написания спецификации своего рода создание фиктивного приложения в Excel и использование некоторого VBA для его симуляции. Он будет делать такие вещи, как нажатие кнопки, куда должна идти форма или какое действие она должна выполнять (в комментариях).

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

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

Visio - это еще один инструмент для создания экрана, но я все еще думаю, что Excel имеет преимущество перед ним, учитывая его поддержку VBA и его функции.

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

Answer 1

Джоэл о программном обеспечении особенно хорош в этом и имеет несколько хороших статей на эту тему ...

особый случай

Answer 2

Два подхода хорошо сработали для меня.

Одним из них является «рабочий прототип», который вы как бы описали в своем вопросе. По моему опыту, компания заключила контракт с экспертом по пользовательскому интерфейсу для создания полнофункциональных макетов HTML. Данные на странице были статичными, но это позволило разработчикам и руководству увидеть и поиграть с «функциональной» версией сайта. Осталось только заменить статические данные на страницах динамическим контентом - этот прототип был нашей спецификацией для первоначальной версии нашего продукта. Дизайнер даже включил подробное объяснение некоторого тонкого поведения во всплывающих диалогах, которые будут появляться при наведении курсора на ссылки. Это хорошо сработало для нашей команды.

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

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

Answer 3

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

Есть несколько замечательных инструментов, таких как FIT , Fitnesse , GreenPepper или Concordion .

Answer 4

В одной из книг Microsoft Press есть отличные примеры различных документов, в том числе SRS (о чем я и говорю). Это может быть одна из книг требований Вейгерта (я думаю, что это его имя, я сейчас не обращаю на это внимания). Я видел, как правительственные организации США используют это в качестве шаблона, и, исходя из трех моих опытов работы с правительством, они любят делать свои собственные, где только могут, поэтому, если они используют его повторно, это должно быть хорошо.

Также - спецификация должна содержать NO CODE, по моему мнению. Следует сосредоточиться на том, что система должна делать, что делать, а что нельзя делать, используя текст и диаграммы.