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

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

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

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

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

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

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

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

22.08.2008 18:18:56
Этот вопрос кажется не по теме, потому что вопросы по управлению проектами больше не относятся к теме. Смотрите pm.stackexchange.com .
LittleBobbyTables - Au Revoir 6.06.2014 13:53:09
Я голосую, чтобы закрыть этот вопрос как не по теме, потому что он касается управления проектами.
EJoshuaS - Reinstate Monica 16.08.2017 14:12:17
4 ОТВЕТА

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

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

0
22.08.2008 18:22:31

Joel on Software особенно хорош в этом и имеет несколько хороших статей на эту тему ...

конкретный случай

5
22.08.2008 18:22:44

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

Для этой цели есть несколько отличных инструментов, таких как FIT , Fitnesse , GreenPepper или Concordion .

2
29.08.2008 08:49:26

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

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

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

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

3
2.09.2008 18:48:07