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

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

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

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

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

8 ответов


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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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


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


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

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


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


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


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

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

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

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

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