ТЗ по ГОСТу нельзя писать в свободной форме ☺️. Есть структура и правила оформления. Можно расширять состав разделов. Можно в текст разделов, которые избыточны написать, что "требования не предъявляются" 😊

можно изменять состав разделов а не просто расширять.

Пересмотрел 34.602. действительно допускается вводить дополнительные, исключать или объединять разделы ТЗ

Мы работаем по другой серии ГОСТов. У нас нельзя 😂

Есть 2 крайности, которые применяются на практике:
1. Разделы должны быть ВСЕ и только те, которые указаны в ГОСТ 34.602/15.016 и т.п., если какие-то требования не определены - указывать "требования не предъявляются". Остальные требования раскидать как получится.
2. Перечень разделов формируется исходя из классификатора требований к  системе.

Мы работаем и по 15.ХХХ и по 19.ХХХ и по 34.ХХХ. Конструктора конечно вопят, что "ТЗ нипагосту", но это на самом деле зависит от принимающих решение. ТЗ "по ГОСТу" по сути должно содержать:
1. Перечень работ
2. Качественные характеристики результатов работ.

А состав разделов - это дело зависящее от предметной области и отраслевой практики.

У нас 1-я крайность. Я лично считаю, что так правильнее. Документы в системе стандартов обычно взаимосвязаны и на разные разделы ТЗ есть свои уточняющие ГОСТы - если перемешать разделы - потом сложно собрать соответствующие нормативные документы

Например 15ю серию стандартов категорически не рекомендую использовать для производства автоматизированных систем. Плюс нужно разделять ТЗ на Проектирование, Конструирование, Изготовление или что-то ещё.

гост не гост.
лишь бы требования норм описаны были.

Жизнь заставляет. Приноровились 😂

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

ГОСТ тут не причем, к сожалению

конечно.
но "осадочек остается"-)

В коммерческой разработке ТЗ по ГОСТу скорее помогало, так как задавало общий контекст взаимодействия сторон. Меньше недопонимания сразу

4 августа 2020, 19:00-20:00

Аудит пользовательского интерфейса с точки зрения аналитика

Обсудим вопросы:
1. Для чего нужно проводить аудит пользовательского интерфейса.
2. На что следует обращать внимание:
- Содержание пользовательского интерфейса:
ориентация на цели заказчика, потребности пользователей;
- Поведение пользователей: основные сценарии
- Форма и цветовые решения:
стандарты, шаблоны и учет предпочтений пользователей ;
- Детализация решений: поиск, сохранение\извлечение данных,
поиск, ошибки, уведомления и пр.

3. Другие вопросы по ходу эфира

Участие в мероприятии БЕСПЛАТНОЕ!
Подробности и регистрация: http://com-practice.com/

Ссылка в день эфира в наших инфоканалах:
https://t.me/compractice
https://facebook.com/groups/compractice/

#analyst #itanalyst #systemanalyst #businessanalysts  #practice #competences  #practicecompetences  #аналитик #итаналитик #системныйаналитик #бизнесаналитик #практикикомпетенции #практики #компетенции

Кстати, а вот концепция по какому ГОСТУ оформляется? В ГОСТ 34 серии я не нашел

И я так понимаю если делать по стандарту ISO 29148 то концепция это Stakeholder requirements specification (StRS) или я не прав?

В советских стандартах концепция в РД50, который относится к семейству 34

В 34.601-90 концепция рассматривается как стадия создания системы и есть пояснения какого типа документами описывать результаты стадии.

в iso 29148 концепция есть также в приложении, называется ConOps. Концепция относится к области решений, а не требований