Каковы ресурсы для обучения написанию спецификаций?

Question

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

EDIT: Если функциональная спецификация включает такие вещи, как предполагая, что я указываю веб-приложение, типы ввода (текстовое поле, раскрывающийся список и т. Д.)?

Answer 1

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

• Требование Docs - Пользователи + Бизнес-аналитик
• Функциональная Spec - Бизнес-аналитик + разработчик
• Технического Spec (как на самом деле будет реализована функциональность) - старший разработчик/ архитектора
• оценки времени для целей планирования - конкретный разработчик, присвоенный задаче

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

Википедия на самом деле является хорошим началом для функциональной спецификации, которая кажется похожей на ваш Spec - http://en.wikipedia.org/wiki/Functional_specification.

Answer 2

Важно, чтобы что-то было записано, а не беспокоиться о формате.

Answer 3

В Главе Стива МакКоннелла есть замечательная глава Code Complete, которая проходит через спецификации и то, что они должны содержать.

Когда мне было поручено создать команду «Архитектура и бизнес-анализ» в компании, которая никогда не была такой, я использовал раздел спецификации Макконнелла, чтобы создать схему для документа технической спецификации. Он развивался с течением времени, но, начав с этой структуры, я убедился, что мы ничего не пропустили, и это оказалось удивительно полезным.

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

Answer 4

Купить книги: Требования Engineering Яном Соммервилль & Pete Sawyer ISBN 0-471-97444-7 или Требования к программному обеспечению Карл Wiegers ISBN 0-7356-0631-5

Answer 5

См Painless Functional Specs Джоэла Спольски.

Некоторые из вещей, которые он говорит, что каждый должен иметь спецификации:

• Правовая оговорка
• Автор. Один автор
• Сценарии
• Nongoals
• Обзор
• Детали, детали, детали
• Открытые вопросы
• сторона отмечает