Здравствуйте.
Укажите, пожалуйста, нужные ориентиры начинающему.
Пришлось выступать в роли представителя заказчика и писать ТЗ на систему, состоящую из нескольких устройств и ПО к ним.
ТЗ вышло монстром (объем чуть более 100 страниц), хотя сначала все казалось управляемым. В связи с этим появилось желание написать другой документ, повествовательный, объясняющий, как система должна работать в форме каких-то случаев использования, и на этот документ, назовем его "Программа функционирования", протрассировать свое ТЗ, чтобы было понятно, откуда взялись требования и зачем они нужны. Далее подумал, что не плохо и исполнителям свои требования к составным частям системы протрассировать на мое ТЗ, чтобы легче было их проверять, и можно было увидеть неохваченные требования. И, конечно же, программу и методику испытаний протрассировать на ТЗ. И чтобы все это можно было редактировать, не теряя трассировки.
Подскажите, пожалуйста:
1. Есть ли в описанном пожелании то, чего не надо / не возможно делать или стоит делать совсем не так.
2. Если для описанных мною документов или действий есть другие, правильные названия, подскажите их.
3. Есть ли freeware (или платное с триалом на срок, позволяющий успеть разобраться и продемонстрировать всем), чтобы воплотить описанное в жизнь и заинтересовать начальство в автоматизации разработки требований в принципе? Желательно, с возможностью создать репозиторий в сетевой папке и поработать с нескольких учетных записей.

Спасибо.

Добрый вечер, Илья.

Вообще для обсуждения неплохо бы визуализировать Ваши мысли в виде ... модели трассировки. Кстати у вас в Петербурге есть специалист в области трассировок - это Юлия Мадорская (https://www.facebook.com/yulia.madorskaya). Попробуйте с ней связаться, возможно она сумеет Вам помочь больше, чем кто-либо еще.

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

2. Не думаю, что название документов является тут важным. Определится с их названиями поможет следование какому-то стандарту (посмотрите например тут http://dit.isuct.ru/Publish_RUP/index.htm#core.base_rup/guidances/supportingmaterials/welcome_2BC5187F.html)

3. На таких условиях ничего особого посоветовать не могу, разве какие-нибудь средства типа redmine или wiki.

Идею обратиться к Мадорской по поводу трассировки полностью поддерживаю. Есть правда шансы после этого начать считать, что 3sl cradle лучший в мире инструмент аналитика, но в этом ничего плохого нет

Идею обратиться к Мадорской по поводу трассировки полностью поддерживаю. Есть правда шансы после этого начать считать, что 3sl cradle лучший в мире инструмент аналитика, но в этом ничего плохого нет

В данном случае инструмент не проходить по условиям пункта 3

Здравствуйте.
Укажите, пожалуйста, нужные ориентиры начинающему.
Пришлось выступать в роли представителя заказчика и писать ТЗ на систему, состоящую из нескольких устройств и ПО к ним.
ТЗ вышло монстром (объем чуть более 100 страниц), хотя сначала все казалось управляемым.

В связи с этим появилось желание написать другой документ, повествовательный, объясняющий, как система должна работать в форме каких-то случаев использования, и на этот документ, назовем его "Программа функционирования", протрассировать свое ТЗ, чтобы было понятно, откуда взялись требования и зачем они нужны. Далее подумал, что не плохо и исполнителям свои требования к составным частям системы протрассировать на мое ТЗ, чтобы легче было их проверять, и можно было увидеть неохваченные требования. И, конечно же, программу и методику испытаний протрассировать на ТЗ. И чтобы все это можно было редактировать, не теряя трассировки.
Подскажите, пожалуйста:
1. Есть ли в описанном пожелании то, чего не надо / не возможно делать или стоит делать совсем не так.
2. Если для описанных мною документов или действий есть другие, правильные названия, подскажите их.
3. Есть ли freeware (или платное с триалом на срок, позволяющий успеть разобраться и продемонстрировать всем), чтобы воплотить описанное в жизнь и заинтересовать начальство в автоматизации разработки требований в принципе? Желательно, с возможностью создать репозиторий в сетевой папке и поработать с нескольких учетных записей.
Спасибо.

2. Есть форматы описания поведения ИТ-систем и продуктов, которые в себя включают:
user story — трассировка пользовательских ФТ на бизнес-требования
use case — трассировка технических ФТ на пользовательские ФТ

Инструментов для трассировки — сотни. Jira, TFS и т.д.

Спасибо всем ответившим. И снова здравствуйте.
Galogen, спасибо за контакт. Но пока что вряд ли будет какое-либо финансирование для привлечения специалиста. И пока что "с ходу" не понял, что такое "Модель трассировки".
1. К сожалению, главная проблема - именно отсутствие культуры разработки на всех уровнях - предприятие старое и закостенелое. Исполнители тоже не в восторге от планов ввести даже SVN и Trac, но часть менеджмента видит, что по предыдущим проектам соисполнителям вообще не было выдано никаких требований, поэтому позволяют тратить на изучение вопроса время.
2. Название документов, наверное, позволит объяснять, чего же хочу в итоге. Некоторое время работал кодировщиком в организации, где использовался стандарт КТ-178B, но погружен в эти вопросы был только менеджмент. Планировал пока что опираться на него, как хоть немного знакомый. Или этот стандарт "из другой оперы"?

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

Почитал, что такое user story и use case. Use case очень похож на то описательное объяснение работы, что я хотел бы разработать. А user story для железа, не имеющего пользовательского интерфейса, наверное, не подходит. В прочем, теперь я дезориентирован и думаю, является ли мое ТЗ бизнес-требованиями или чем-то еще. Или, может быть, оно должно чем-то являться, но я написал что-то другое По традиции нашей организации в ТЗ оказались и требуемые функции, и требовния к точности, и то, какая структура будет у системы, и какие технические решения должны обеспечивать выполнение функций. Наверное, это должны быть несколько документов: в ТЗ только требуемые функции и требования к точности, времени исполнения, а на его основе уже документ со структурой системы, взаимосвязями частей.

Спасибо, буду как-то укладывать всю эту информацию в сознании.

А ТЗ у Вас в какой форме написано. Вы берете какую-то основу или это просто какой-то внутренний формат?

Такого стандарта я не знаю. В поисковике ссылок довольно много. Посмотрел это стандарт, в нем 11 раздел посвящен целому набору документов, они Вас не очень устраивают?

Тут ко мне с обвинением, что я обманываю людей, обратилась Юлия Мадорская.

Идею обратиться к Мадорской по поводу трассировки полностью поддерживаю. Есть правда шансы после этого начать считать, что 3sl cradle лучший в мире инструмент аналитика, но в этом ничего плохого нет

В данном случае инструмент не проходить по условиям пункта 3

Я должен заявить, что никого обманывать не планировал. Мне известно только о 14 днях (https://www.threesl.com/en/downloads/software.php), но оказывается это не совсем верно, при обращении к представителям продукта ознакомительную лицензию можно продлить. Так что ilyaspb поспешите воспользоваться возможностью.

Некоторое время работал кодировщиком в организации, где использовался стандарт КТ-178B, но погружен в эти вопросы был только менеджмент. Планировал пока что опираться на него, как хоть немного знакомый. Или этот стандарт "из другой оперы"?

Под этот стандарт уже есть модель трассировки

http://saturs.ru/index.php?r=block%2Fplain&label=do178

Ну и в фейсбуке сформировалась инициативная группа разработки модеи под 34 ГОСТ.

Galogen, Внутренний формат, существующий последние лет 20, наверное. Примерно такой состав:
-Перечень определений
-1. Назначение
-2. Состав
-3. Технические требования -  пишутся как душе угодно. Содержит тоже все, что в голову придет: уровни сигналов, некоторые временные характеристики, какие-то технические вопросы просто детально проработаны. Регламентирует структуру продукта и какие сигналы из какого устройства куда идут, но про какие-то части обычно разработчик ТЗ не подумал, так как писать на бумаге - одно, а разрабатывать - все же другое. В общем, абсолютно все пожелания, которые родятся у автора ТЗ, здесь. Обычно это до 10 подпунктов, внутри подпунктов - сплошной текст и пара картинок. Объем от 1 до 20 листов.
-4. и т.д. - требования к технологичности, упаковке и прочее - разделы, которые никто не заполняет (точнее, пишут ссылки на одни и те же документы) и не читает традиционно. Считается, что люди, ответственные за эти участки, и так знают, что надо делать.
- Приложения - несколько таблиц с информацией вроде назначения регистров устройств.

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

Взял этот формат за основу (других вариантов и не было). Принципиально старался переломить традиции в нескольких местах:
1. Постарался сделать каждое требование отдельным подпунктом, чтобы на него можно было ссылаться. Уже после передачи исполнителю понял, что много где это не получилось - требования можно еще разбить.
2. Постарался избавиться от неполноты требований: если даются параметры входных/выходных сигналов, то давать все, например. Тоже не вышло идеально.
3. Не разрабатывал структуру, а разбил все на функциональные модули, описал, какие функции они должны решать. Предоставил конкретную структуру выбрать разработчикам.
4. Добавил требование использовать SVN или Git и предоставить доступ Заказчику.
5. Добавил требование перед созданием всех составных частей и ПО разработать и согласовать на них требования, а затем и проект.
6. Добавил требование согласовать стандарт  на кодирование (сам же его и разработал, пока шли споры).
7. Добавил требование разработать и согласовать программу и методику тестирования составных частей устройства и самого устройства. Раньше принимали работы бессистемно. Методику разрабатывали уже при постановке на производство. И то очень короткую, не покрывающую почти никаких требований.
8. Добавил требование разработать словарь данных. Хотя, теперь уже сомневаюсь, что правильно смысл термина понимаю. Вижу его как докумет, присваивающий каждой сущности идентификатор, который должен быть использован во всем ПО, на всех схемах.
9. Пытался формулировать требования так, чтобы они были проверяемы. Тоже не все гладко.

Нет, к КТ-178В никаких претензий нет. Есть еще, кажется, с него же списанный ГОСТ 51904-2002. Проблема в том, что я просто запутался - никогда раньше не поднимался выше роли кодировщика. В частности, дорожка от ТЗ до требований к ПО - как в тумане. В КТ-178В есть упоминание "Требований к системе" и "Программы функционирования". Не понятно, это одно и то же, или нет. Не понятно, является ли ТЗ синонимом одного или обоих из этих терминов. В общем, в системной области - полная дезориентация. Буду рад, если участники форума пояснят, что из этих трех документов за чем следует и чем они отличаются.

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

Отдельный вопрос - как КТ-178В (или другой стандарт) связать с ЕСПД, чтобы не возникало никаких вопросов (наш заказчик требует следования ЕСПД). Состав документов ведь разный. Да и жизненный цикл, как я понимаю, предполагается разный. Или тут я зря беспокоюсь?

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

Почитал, что такое user story и use case. Use case очень похож на то описательное объяснение работы, что я хотел бы разработать.

А user story для железа, не имеющего пользовательского интерфейса, наверное, не подходит.

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

Например: Как родитель ребёнка, я хочу чтобы кровать не имела резких выступающих углов, чтобы ребёнок не мог случайно пораниться в контакте с ней.

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

В прочем, теперь я дезориентирован и думаю, является ли мое ТЗ бизнес-требованиями или чем-то еще.
Или, может быть, оно должно чем-то являться, но я написал что-то другое

А вы покажите примеры.

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

Это обычная ситуация, когда мешают ТЗ и техпроект. В половине случаев она вполне оправдана.

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

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

При проектировании АСУ есть такая болезнь - определять состав компонент в соответствии с организационной структурой. Очень тяжело потом сдавать ...

8. Добавил требование разработать словарь данных. Хотя, теперь уже сомневаюсь, что правильно смысл термина понимаю. Вижу его как докумет, присваивающий каждой сущности идентификатор, который должен быть использован во всем ПО, на всех схемах.

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

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

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