Здравствуйте!

Вопрос: как писать спецификацию требований, чтобы она была понятна не только технически подкованным, но и не очень разбирающимся читателям?
Мне пришло в голову 2 варианта, но оба кажутся не очень удачными:

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

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

Хотелось бы услышать мнения на этот счет.

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

Почему плохо применим? Делает пример (ы) ТЗ на реальных требованиях, звоните Заказчику и ищете общий вариант.

Вообще, этому посвящены целые тракты. Форумы, конференции, дискуссии и статьи. На самом деле все очень относительно.

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

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

Сложные места снабжаю разными примерами. И использую активно быстрые прототипы на Access - очень помогает.

Простите за любопытство. А что такое прототипы на акссес? Может мне оно тоже надо... ))))

Простите за любопытство. А что такое прототипы на акссес? Может мне оно тоже надо... ))))

О это мое большое ноу-хау
Секрет прост. В ходе сбора требований и их изучения я делаю обычные ER-модели, использую ERWIN. Моделирую сразу пытаюсь передать понимаемую мною семантику, бизнес-правила и т.п.

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

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

Если заказчик (он же пользователь) простите туп, делаю ему примитивные формочки и некий мастер-путеводитель. Предупреждаю, что то что он видит - это вовсе не, то как будет. Цель правильно ли я понимаю то, что желает заказчик.

Аналогично для этих целей использую связку Rational Rose - Bold for Delphi 7.

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

Вопрос: как писать спецификацию требований, чтобы она была понятна не только технически подкованным, но и не очень разбирающимся читателям?

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

Мои методы:
1. Глоссарий
2. Согласование терминологии (до начала разработки документов)
3. Избегание профессионального жаргона

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

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

но и не очень разбирающимся читателям?

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

Есть такие отдельные виды документов, наряду со спецификацией требований, которые служат для близких с вашей целей:
1) Vision & Scope
2) Business Requirements Document (BRD)
3) User Requirements Document (URD)

Вы можете легко найти информацию и примеры этих документов в интернете.

Подумайте ещё раз хорошо, что вы хотите от ваших читателей. Понять, что из себя будет представлять ваша система? Подписаться (утвердить), что документ верно описывает поведение системы?
Исходя из вашего ответа, выбирайте наиболее подходящий документ и/или наиболее подходящее представление.

Мысль изреченная есть ложь (с)
А уж написанная - тем более. Однозначно и правильно понять мысль автора в технически сложном документе не могут даже технически подкованные читатели. У них регулярно возникает интерпретация, весьма далекая от действительности и понять это можно только в интерактиве, обсуждая документ. А еще - часто воспринимается 10-30% информации, заложенной в документ автором.

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

Однозначно и правильно понять мысль автора в технически сложном документе не могут даже технически подкованные читатели. У них регулярно возникает интерпретация, весьма далекая от действительности и понять это можно только в интерактиве, обсуждая документ. А еще - часто воспринимается 10-30% информации, заложенной в документ автором.
А так - больше схем, наглядности, прототипов - это очень хорошо, хотя и требует усилий. Обязательно - схемы верхнего уровня. И - обсуждайте, проверяйте понимание.

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