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

Об общих советах;

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

1) Заявление о бизнес-требованиях (BRS)

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

3) Технические характеристики

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

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

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

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

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

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

Не шаблон, но Джоэл написал несколько статей о написании функциональной спецификации. У него также есть пример здесь.

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

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

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

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

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

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

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

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

Это лучший из тех, что я нашел: http://www.jiludwig.com/templates/FRDTemplate.doc

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

Я бы посоветовал взглянуть на шаблон Volere Роберстона здесь. Они входят в гильдию Атлантических систем вместе с такими людьми, как Том ДеМарко и Тимоти Листер, известными как «Peopleware».

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

1. Цель проекта
2. Заинтересованные стороны
3. Обязательные ограничения
4. Соглашения об именах и терминология
5. Соответствующие факты и предположения
6. Объем работы
7. Модель бизнес-данных и словарь данных
8. Объем продукта
9. Функциональные требования
10. Требования к внешнему виду и ощущениям...

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

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