Шаблоны технических и функциональных характеристик

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

Что вы используете? Насколько глубоки вы получаете при написании спецификаций? Любые дополнительные общие советы, которые вы могли бы предоставить, были бы оценены.

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

РЕДАКТИРОВАТЬ: Я прочитал, что Джоэл взял Безболезненный Спецификация, мне очень понравилось, но есть ли какие-либо другие мнения:)

Ответ 1

В общих советах

Мы реализуем процесс

1) Требования к бизнес-требованиям (BRS)

2) Функциональная спецификация

3) Техническая спецификация

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

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

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

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

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

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

Ответ 3

Вы можете купить шаблоны от ieee и других мест, но я всегда делал свой собственный.

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

Что касается функциональной спецификации, важно определить все интерфейсы:

  • UI (макеты экрана)
  • Программные интерфейсы (плагины и т.д.)
  • Аппаратные интерфейсы (при необходимости)
  • Коммуникационные интерфейсы (службы, электронная почта, обмен сообщениями и т.д.).

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

Ответ 5

Мне нравится этот, среди прочих: ReadySet.

Он также продает про-версию.

Ответ 7

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

Ответ 8

Я хотел бы предложить посмотреть шаблон Roberston Volere здесь. Они являются частью гильдии Atlantic Systems вместе с такими людьми, как Том ДеМарко и Тимоти Листер из "Peopleware".

Поскольку шаблон защищен авторским правом, я не буду воспроизводить его здесь, но дайте вам некоторые из основных заголовков:

  • Цель проекта
  • Заинтересованные стороны
  • Мандатные ограничения
  • Соглашения об именах и терминологии
  • Соответствующие факты и предположения
  • Объем работы
  • Модель бизнес-данных и словарь данных
  • Объем продукта
  • Функциональные требования
  • Посмотрите и почувствуйте требования ...

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

Посмотрите здесь в главе 9.