Здравствуйте, Форумчане. Не знаю, по адрессу ли я обратился, потому заранее прошу, не обессудьте.
Поручили мне на работе создать некоторый шаблон требований. ИТ компания, занимающаяся поставкой и разработкой ПО. Мне было поручено создать некий шаблок требований, который можно было бы предъявлять клиентам для выявления их потребностей. У компании имеются определённые проблемы с этим. Хорошего документирования нет, процесс сбора требований у клиентов никак не формализован. Всё строится на отдельных записях в тетрадку и удержки в голове. Необходимо создать шаблон технических требований, который можно будет совместно с клиентом заполнить и на основании его писать далее техническое задание.
Для этого я использовал SRS. хочу, чтоб вы просмотрели и оценили корректность и пригодность данного документа. Ещё раз извиняюсь, если прошёл не по теме и прошу в таком случае посоветовать мне подходящий форум.
ссылка на документ http://zalil.ru/34305230

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

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

Согласен, что в документе много лишнего. Следовал стандарту срс 830-1998.
Но подразумевается, что документ будет составляться совместно представителями стороны клиента и исполнителей. Естественно, что среднестатистический клиент не сможет ответить на 80% вопросов в данном документе, но с другой стороны, ведь любые непонятные вещи можно объяснить и на простом языке. Делается это для того, чтобы определить все требования заказчика с самого начала, уменьшить степень неясности.

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

Чем больше всего разного - тем выше энтропия. Чем глубже кинетесь в детали - тем больше шанс упустить действительно важное.
То что вы даете заказчику, должно быть целиком и полностью ему понятно. И написано ему простым человеческим языком.
Зачем ему документ где он не сможет ответить на 80% вопросов?
За вас заказчик ТЗ не напишет:)

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

Если же нужно "стандартизировать и формализовать процесс сбора требований", то одним шаблоном весь процесс не заменишь. Как ни крути, придется и лично общаться с заказчиком тоже.
А вот как часть процесса - такой шаблон вполне.

Спасибо за разъяснение
Выходит, что так называемый шаблон требований должен состоять всего из нескольких основных пунктов, которые можно даже и не документировать а записать в тетрадке и надеяться что в процессе разработки не будет упущено чего-либо. Пример: клиент говорит что хочет хороший игровой комп с большим монитором, архитектура, объём памяти, платы и прочее его не интересует, да и не разбирается он. Но ведь можно было бы устроить с ним беседу и объяснить что такая то плата будет стоить столько то, нужна она для этого, приемущества и недостатки. Можно конечно, не спрашивая у него поставить туда всё самое лучшее, но это влетит ему в круглую сумму. Ведь если клиенту и в вамом деле нужен солюшн, то ему ему не жалко будет пожертвовать лишние пару часов на то, чтобы вникнуть в детали, даже поверхностно.
До сих пор всё делалось имеено так, как вы и описываете и так делается в большинстве организаций. Клиент предъявляет бизнес-цели а всё остальное для него тёмный лес и не волнует его и тут уже просто остаётся надеяться, что конечный продукт удовлетворит запросам. Рано или поздно, разумеется, всё встаёт на свои места, после исправления ошибок и недочётов, которые были вызваны тем, что заказчик не достаточно ясно изложил свои цели, в итоге сдаётся проект, договор выполнен. Однако, это сопровождается лишними затратами, не укладыванием в сроки по большому счёту именно из-за низкой формализации. И как мне кажется, небольшая "пытка", допрос клиента пойдёт лишь на пользу.

Нет, вы меня неправильно поняли. Никаких тетрадок и надежд.
Все должно быть последовательно, записано в документы и согласовано.
Сначала видение продукта. Это отдельный документ, в котором описывается что и зачем мы вообще затеваем.
Потом аналитик делает сбор требований. В том числе и с помощью обсуждаемого шаблона.
Затем аналитик выявляет требования из того что собрал от заказчика, из его "хочу/не хочу, это не это и т.д."
Аналитик готовит ТЗ в котором указывает все требования к разрабатываемой системе.
Если ТЗ согласовано с заказчиком - за дело берутся разработчики, которые решают какая архитектура удовлетворит требованиям (а не наоборот), какие реализации сделать, и т.д.

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

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


Еще раз кратко что я хотел сказать прошлым постом: Такой шаблон - лишь малая часть работы аналитика. Весь процесс сбора требований им не заменишь.

Ясно, согласен  А вот какие пункты включать/не включать в документ? каков должен быть уровень детализации?

Для каждого документа свой.

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

Если речь идет о ТЗ, то уже детальные требования, которые сделаны на основании опросника и бесед с заказчиком/пользователями заказчика. И уже их вы и будете согласовывать с заказчиком.

maggot brain,

1. Почитайте книжку Вигерса
2. Посмотрите ролики:
http://www.youtube.com/feed/UCLy9Y3p9SZB4us8UJ8Rh8BQ

Все базовые вещи мы Вам не расскажем на форуме!

я говорил именно про сбор требований
Спасибо, воспользуюсь

Вот тут ребята перевели Stakeholder Request Template — Шаблон запроса заинтересованного лица: http://sysana.wordpress.com/2010/06/04/%D0%BA%D0%BE%D0%BD%D1%82%D0%B5%D0%BA%D1%81%D1%82%D0%BD%D0%BE-%D0%BD%D0%B5%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8%D0%BC%D0%BE%D0%B5-%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D0%B2%D1%8C%D1%8E/

И да — сначала — выявление интересов и потребностей, и только потом, главным образом с помощью мозга аналитика — разработка требований.

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

Спасибо, Денис! Полезнейшая ссылка

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

Это поручение вряд ли выполнимо, потому что "определённые проблемы с этим" имеются у сотен тысяч компаний, занимающихся таким бизнесом. Из чего можно предположить, что маловероятно, что этот волшебный шаблон существует в природе

Пишите "Программу и Методику Испытаний". Можно по ГОСТ 34.603. Потом можно и 34.602. Но лучше начать с 34.603. Пробовал в нескольких фирмах. Знаю. Полезно. Делаю.

Можно мои доклады посмотреть. Наиболее полезен с ЛАФ-1010.