Написание спецификаций для проекта, традиционный маршрут

Question

Каковы общие, традиционные этапы / этапы разработки программного обеспечения или, более конкретно, написание спецификации?

Мне известны такие понятия, как метод водопада, сбор спецификаций, сценарии использования и т. Д. Но я хочу более формальное объяснение всего этого.

Answer 1

Я нашел компании, как правило, либо:

1. Не делай спецификаций.

2. Есть шаблон спецификации. Каждая спецификация выглядит как все остальные (т.е. «стандартные») - все они имеют одинаковые разделы.

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

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

Лучшие спецификации, которые я видел, это те, которые я могу взять и сделать, как есть, не задавая никаких вопросов автору спецификации. Если мне придется задавать вопросы, я считаю, что спецификации не удалось. Спецификация должна ответить на все мои вопросы.

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

Спецификация должна быть легко читаемой. Однажды мне вручили спецификацию на 120 страниц без содержания и номеров страниц. Я попросил автора спецификаций вставить оглавление, и она ответила: «Нет, я хочу, чтобы люди прочитали спецификацию, чтобы найти то, что они ищут, с тех пор они прочитают больше». Я потратил много времени, просматривая эту спецификацию в поисках вещей. Это была плохая спецификация.

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

Answer 2

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

Ниже приведен взлом подобного вопроса .

Шаги, как я вижу это;

1. Заявление о бизнес-требованиях (BRS)
2. Функциональная спецификация
3. Техническая спецификация

BRS охватывает проблемы бизнеса и требования к решениям, тестированию, безопасности, надежности и доставке. Это определяет, что сделало бы успешное решение.

Функциональная спецификация подробно описывает, что нужно, как оно должно выглядеть, сколько должно быть полей и т. Д.

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

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

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

Answer 3

Какие характеристики вы имеете в виду? Правильная спецификация для вас будет зависеть от вашей команды, которая будет использовать спецификацию и любые требования к проектной документации.

Спецификации должны быть адаптированы к целевой аудитории и учитывать ожидаемый срок действия документа. Я использовал функциональные спецификации и технические характеристики. Для функциональной спецификации основной целевой аудиторией был клиент, а для технической спецификации целевой аудиторией были разработчики и ИТ-группа (для развертывания).

Функциональная спецификация обычно не поддерживалась после начала разработки. Обычно функциональная спецификация создавалась до начала проекта и использовалась для оценки размера проекта. Один архитектор, с которым я работал, написал своего рода функциональную спецификацию в Power Point. Он брал это на все свои встречи, технические и нетехнические. Он был полон легко читаемых диаграмм и страниц с точечными точками, которые мы использовали как формулировку миссии для проекта.

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

Answer 4

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

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

Answer 5

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

Иногда мы начинаем с функции или улучшения, пишем полную спецификацию, затем делаем кодирование. В других случаях мы начнем кодировать его, затем вернемся и уточним спецификацию после факта. Оба подхода работают для нас. Часто наши спецификации описывают, как эта функция будет работать с точки зрения пользователя, хотя мы иногда включаем технические детали, такие как новые определения таблиц или изменения существующих классов / модулей / форм.

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