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


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

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

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

EDIT: Я читал мнение Джоэла о безболезненно Спецификация, мне очень понравилось, но есть и другие мнения :)

8 60

8 ответов:

на общие советы;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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