Форум Сообщества Аналитиков

Дисциплины => Системный Анализ и Требования => Тема начата: boatman от 12 Декабря 2007, 02:05:21

Название: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: boatman от 12 Декабря 2007, 02:05:21
У меня подходит к концу проект, в котором целый этап был посвящен написанию ТЗ ровно по ГОСТ 34.602. Не то, чтобы это первое ТЗ по ГОСТ у меня, но такого трепетного отношения мы к нему еще не проявляли, к тому же со временем приходит все новое понимание старых вещей. Хорошо или плохо, но мы, естественно написали этот документ.
Из вопросов которые я мог бы осветить в потенциальной статье мне наиболее интересны следующие:
- Место концепции в ТЗ
- Место описания бизнес-процессов в ТЗ
- Место вариантов использования и других требований в ТЗ

Чуть менее интересно, по причине того, что это может быть очень по разному у всех
- Что мы писали в определеннных разделах (наше толкование ГОСТ)
- Последовательность разработки
Название: Re: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: Denis Beskov от 12 Декабря 2007, 02:10:23
Учитывая, что этим 3-м перечисленным пунктам в ТЗ не место - интересно )
Название: Re: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: Denis Beskov от 12 Декабря 2007, 03:20:56
...
- Место концепции в ТЗ
- Место описания бизнес-процессов в ТЗ
- Место вариантов использования и других требований в ТЗ
...
Ой ли?
Ой.
Если в проекте нужно работать по ГОСТам, то по ГОСТ 34.601-90 "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ" первыми 3-мя стадиями идут:
Цитировать
1. Формирование требований к АС
2. Разработка концепции АС.
3. Техническое задание.

Далее, если посмотрим по содержанию РД 50-34.698-90 "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ" (Приложение 1), то увидим, что на 1-м этапе пишется отчет по ГОСТ 7.32, основное содержание которого:
Цитировать
1) характеристика объекта и результатов его функционирования;
2) описание существующей информационной системы;
3) описание недостатков существующей информационной системы;
4) обоснование необходимости совершенствования информационной системы объекта;
5) цели, критерии и ограничения создания АС;
6) функции и задачи создаваемой АС;
7) выводы и предложения.

А более детально раздел 2 "Описание существующей информационной системы" содержит:
Цитировать
описание функциональной и информационной структуры системы, качественных и количественных характеристик, раскрывающих взаимодействие ее компонентов в процессе функционирования
, а это собственно и есть модели бизнес-процессов и прочее, одним понятием - модель деятельности объекта автоматизации.

Далее, то что на стадии "Разработка концепции АС" разрабатывается концепция АС думаю, и так понятно (оформляется отчётом по ГОСТ 7.32).

Теперь посмотрим на группы обобщённых сценариев взаимодействия (aka варианты использования) - что они содержат? Описание взаимодействия пользователей и системы. Откуда эти сценарии берутся, от заказчика? Нет, они являются результатом ПРОЕКТИРОВАНИЯ ВЗАИМОДЕЙСТВИЯ, как работы по определению хода развёртывания взаимодействия реактивной функции (в отличие от трансформационной), затребованной от системы на этапе ТЗ. Т.е. это материал для стадий 4/5 по ГОСТ 34.601 - "Эскизный проект", "Технический проект".

Смотрим содержание документа "Описание функциональной структуры" из ЭП/ТП:
Цитировать
1) элементы функциональной структуры АС (подсистемы АС); автоматизированные функции и (или) задачи (комплексы задач); совокупности действий (операций), выполняемых при реализации автоматизированных функций только техническими средствами (автоматически) или только человеком;

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

3) детализированные схемы частей функциональной структуры (при необходимости).

А также документ "Описание автоматизируемых функций":
Цитировать
1) исходные данные;
2) цели АС и автоматизированные функции;
3) характеристика функциональной структуры;
4) типовые решения (при наличии).
Раскроем отсюда пункт 3:
Цитировать
1) перечень подсистем АС с указанием функций и (или) задач, реализуемых в каждой подсистеме;
2) описание процесса выполнения функций (при необходимости);
3) необходимые пояснения к разделению автоматизированных функций на действия (операции), выполняемые техническими средствами и человеком;
4) требования к временному регламенту и характеристикам процесса реализации автоматизированных функций (точности, надежности и т.п.) и решения задач.

Ба, да 2-3 это собственно и есть алгоритмы для трансформационных функций и сценарии взаимодействия для реактивных (use case'ы)!


Ещё простой пример логики - что такого технического в модели бизнес-процессов и концепции, чтобы засовывать их в документ под названием ТЕХНИЧЕСКОЕ задание? Да ничего.
Название: Re: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: Denis Beskov от 12 Декабря 2007, 04:00:26
На мой взгляд из западных стандартов и шаблонов ГОСТ 34.602 в наибольшей мере соответствует документу System Requirements Document/System Requirements Specification (SRD/SRS), описанному в IEEE Std 1233-1998 - Guide for Developing System Requirements Specifications, с некоторыми элементами System Architecture Document (SAD, разбиение на подсистемы).
Название: Re: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: Galogen от 12 Декабря 2007, 09:42:17
В любом случае интересно почитать, что получилось. Заодно и покритиковать, если надо, а так же прийти к правильным выводам
Название: Re: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: bas от 12 Декабря 2007, 11:57:31
Просто, к сожалению, ГОСТ уже слишком далеко от тех стандартов по которым де-факто принято описывать требования. Вот каждый и изголяется.

М.б. действительно сначала обсудим что где должно быть. А потом уж писать?
Название: Re: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: Galogen от 12 Декабря 2007, 12:07:45
Насчет твоего утверждения есть возражения http://authorit.ru/?c=2, сам я, конечно, не фанат ГОСТ. НО может не так все печально как кажется, может мы не верно трактуем возможности ГОСТ?
Название: Re: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: Shur от 12 Декабря 2007, 13:10:18
Теперь посмотрим на группы обобщённых сценариев взаимодействия (aka варианты использования) - что они содержат? Описание взаимодействия пользователей и системы. Откуда эти сценарии берутся, от заказчика? Нет, они являются результатом ПРОЕКТИРОВАНИЯ ВЗАИМОДЕЙСТВИЯ, как работы по определению хода развёртывания взаимодействия реактивной функции (в отличие от трансформационной), затребованной от системы на этапе ТЗ. Т.е. это материал для стадий 4/5 по ГОСТ 34.601 - "Эскизный проект", "Технический проект".
Ещё простой пример логики - что такого технического в модели бизнес-процессов и концепции, чтобы засовывать их в документ под названием ТЕХНИЧЕСКОЕ задание? Да ничего.

То, что варианты использования являются исключительно продуктом проектной деятельности - сильное утверждение.
1. Если есть уже старая система, на смену которой создается новая, то часть сценариев взаимодействия неизбежно будет унаследована новой системой.
2. Системы и даже понятие системы возникли раньше, чем для управления этими системами стали применять программы. Поэтому когда все автоматизированные ныне виды деятельности автоматизировались впервые, то содержание автоматизированной деятельности (взаимодействие человека с "неавтоматизированной системой") получалась именно "от заказчика". И никак иначе. Проектировщик новой системы вносит в неё своё технологическое содержание, но обязательно на фундаменте содержания, полученного от заказчика системы.
3. То что в нашей стране многие представления о том как именно нужно "делать дело"  появляются вместе с программными продуктами никак не умаляет значимости тех системных решений, которые принимались при проектировании "неавтоматизированных" систем (например, автомобилей, самолетов, электростанций, городов). Многие такие ныне работающие системы унаследовали принципы их создания и функционирования, которые возникли до появления компьютера и пока еще не пересмотрены. История таких системных решений для автоматизируемой деятельности может быть очень полезна для понимания текущих проблем деятельности Заказчика, из-за чего он и затеял новый проект по автоматизации. Поэтому в разделе "Характеристика объекта автоматизации" ТЗ представляется вполне уместным описание деятельности заказчика как системы, рассматривая понятие "система" в данном случае существенно шире чем "компьютерная система".
Название: Re: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: darco от 12 Декабря 2007, 13:23:33
Конечно, было бы интересно прочитать и услышать ваши комментарии по проекту.
Ждем-с...
Название: Re: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: Galogen от 12 Декабря 2007, 18:07:29
skip...
Ой, Shur, :) как сказал. Прямо песня ....

Насчет ТЗ и use case есть забавный пример:
ТЗ на ИАС по социально-экономическому положению региона (http://projects.economy.gov.ru/pms/DownloadFile.aspx/ТЗ%20ИАС%20СЭР.rar?workproductid=c25495f0-88b0-4ede-b0e6-984c1e71d685)

ТЗ на ИАС юридических лиц региона (http://projects.economy.gov.ru/pms/DownloadFile.aspx/ТЗ%20ИАС%20ЮЛ.rar?workproductid=b48b5401-7a4a-49f6-b2b5-b76b8a45acf8)

ну и там пошукайте. для ТЗ типа использовался шаблон МЭРТ
Название: Re: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: Shur от 13 Декабря 2007, 00:11:45
Ой, Shur, :) как сказал. Прямо песня ....

Благодарю... Но хотел бы отметить, что в данном случае был бы также признателен за сомнения, конструктивные критические замечания (иначе мы оба можем потерять по кусочку сыра :). Возможно обсуждение темы в дальнейшем позволит уточнить границы рамок бизнеса и собственно ИТ-системы в описаниях отдельных разделов ТЗ, а также критерии, котрыми стоит руководствоваться при определении этих границ для целей написания ТЗ.
Название: Re: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: Denis Beskov от 13 Декабря 2007, 00:31:10
То, что варианты использования являются исключительно продуктом проектной деятельности - сильное утверждение.
1. Если есть уже старая система, на смену которой создается новая, то часть сценариев взаимодействия неизбежно будет унаследована новой системой.
Ну это какие-то частности, мы пока вроде о более фудаментальных вещах не договорились.
Цитировать
2. Системы и даже понятие системы возникли раньше, чем для управления этими системами стали применять программы. Поэтому когда все автоматизированные ныне виды деятельности автоматизировались впервые, то содержание автоматизированной деятельности (взаимодействие человека с "неавтоматизированной системой") получалась именно "от заказчика". И никак иначе. Проектировщик новой системы вносит в неё своё технологическое содержание, но обязательно на фундаменте содержания, полученного от заказчика системы.
Приведите пожалуйста какой-то пример, я не очень понимаю, о чём речь. На мой взгляд, автоматизация взаимодействий может существенно менять их содержание.
Цитировать
3. То что в нашей стране многие представления о том как именно нужно "делать дело"  появляются вместе с программными продуктами никак не умаляет значимости тех системных решений, которые принимались при проектировании "неавтоматизированных" систем (например, автомобилей, самолетов, электростанций, городов). Многие такие ныне работающие системы унаследовали принципы их создания и функционирования, которые возникли до появления компьютера и пока еще не пересмотрены. История таких системных решений для автоматизируемой деятельности может быть очень полезна для понимания текущих проблем деятельности Заказчика, из-за чего он и затеял новый проект по автоматизации. Поэтому в разделе "Характеристика объекта автоматизации" ТЗ представляется вполне уместным описание деятельности заказчика как системы, рассматривая понятие "система" в данном случае существенно шире чем "компьютерная система".
Если вы смотрели требования к содержанию раздела "Характеристика объекта автоматизации", то там достаточно поверхностные вещи отражаются. Я не понимаю, зачем в ТЗ тащить то, для чего есть отдельный документ и этап. Есть раздел "Описание существующей информационной системы", который я упоминал выше. Информационная система - естественно шире, чем компьютерная система.

Ведь ТЗ пишется на основе концепции, концепция пишется на основе результатов обследования и описания объекта автоматизации.
Название: Re: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: Юрий Булуй от 13 Декабря 2007, 00:57:51
О БП и их размещении в техзадании.
Я часто наблюдаю картину, когда ошибочно ставят знак равенства м/у бизнес-процессами и их моделями и ТЗ. Мне кажется тут не обошлось без "этих мерзких ERP-ников" (прим. это шутливое высказывание). В SAP нет например понятия требований как таковых -- есть БП и техническая имплементация. Вобщем, в голове рядового разработчика софта в интересах крупных полугосударственных структур есть жуткая каша и непонимание места моделей бизнес-процессов и требований к системам. Да, я понимаю, что есть т.н. "функциональная архитектура" по AIM (тоже заметим, те же ERP-шники), более того даже в IEEE этот термин используется. Но тут нужно очень четко представлять ДЛЯ чего мы делаем модели бизнес-процессов. Если для оптимизации бизнеса, внедрения KPI -- это одно,  а если для ПОНИМАНИЯ как устроен бизнес, чтобы его автоматизировать - это другое. Хуже, когда стоит задача "оптимизации бизнеса через автоматизацию", или как нынче модно говорить, через информатизацию :-). Ибо при этом с одной стороны -- что может быть очевиднее -- преимущества автоматизации явные (ускорение, удешевление и т.п.). Но тут начинает возникать вопрос -- "автоматизация изменяет бизнес-процессы или нет???". На него можно ответить по-разному. Например, мы копали яму лопатой, приделали к ней мотор -- она стала копать сама и гораздо быстрее. Бизнес-процесс изменился? Ответ -- НЕТ, т.к. изменился только механизм (вспомним IDEF0), но не процесс. Да, он стал производительнее. Аналог, автоматизация документооборота ... раньше бегали ногами носили бумаги, регистрировали в журнале ... а теперь то же самое, только в компьютерах. Вопрос -- изменился бизнес-процесс???

В любом случае я согласен с Денисом, что в чистом виде описание БП не должно быть в ТЗ, тем более по ГОСТ 34. Т.к. эту работу нужно было делать еще на этапе формирования требований к АС, проводя соответствующий НИР по изучению процессов организации и выпуская отчет по НИР.
Название: Re: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: Galogen от 13 Декабря 2007, 08:03:09
В любом случае я согласен с Денисом, что в чистом виде описание БП не должно быть в ТЗ, тем более по ГОСТ 34. Т.к. эту работу нужно было делать еще на этапе формирования требований к АС, проводя соответствующий НИР по изучению процессов организации и выпуская отчет по НИР.
Я тоже согласен, что моделирование БП не должно отражаться в ТЗ. Если посмотреть множество примеров вот здесь:http://projects.economy.gov.ru/pms/public/, то можно обнаружить, что бизнес-моделирование есть часть технического проекта.
Если обратится к RUP, то бизнес-моделирование происходит на стадии Развития, после формирования первой версии Концепции, важных прецедентов и спецификации дополнительных требований.

Ясно и то, что процесс в общем случае цикличен.

Так все-таки когда и кто делает бизнес-моделирование. Где место моделям бизнес-процессов?
Название: Re: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: Denis Beskov от 13 Декабря 2007, 14:24:37
Если посмотреть множество примеров вот здесь:http://projects.economy.gov.ru/pms/public/, то можно обнаружить, что бизнес-моделирование есть часть технического проекта.
Кроме того, если посмотреть множество примеров там, то можно увидеть много всякой чуши. А именно происходит путаница ГОСТовского технического проекта и консалтерского системного.

Цитировать
Если обратится к RUP, то бизнес-моделирование происходит на стадии Развития, после формирования первой версии Концепции, важных прецедентов и спецификации дополнительных требований.
Эд, с точностью до наоборот.

Цитировать
Так все-таки когда и кто делает бизнес-моделирование. Где место моделям бизнес-процессов?
В рамках ГОСТов - я уже сказал, в других методологиях надо обсуждать отдельно, хотя с RUP'ом всё понятно.
Название: Re: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: Galogen от 13 Декабря 2007, 15:35:55
Денис, а где ты это уже сказал. Насчет ГОСТов?

Насчет RUP. Я конечно не его знаток, я только учусь.

Но вот смотрю книгу Лармана Применение UML 3-е издание (стр.65) - характерный рисунок дисциплин унифицированного процесса (2.7) и (2.8). Видно, что львиная доля бизнес-моделирования приходится на стадию Развития.
Идем далее. стр. 68. Таблица примерный набор инструментов (Development Case {не удачный перевод, имхо})
и видим Бизнес-моделирование - артефакт: Модель предметной области. Фаза Развитие - начало. Тогда как артефакты требований начинаются на стадии Начало.
Реально, конечно, все идеть паралелльно и зависит от проекта.


Название: Re: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: Denis Beskov от 13 Декабря 2007, 16:51:14
Денис, а где ты это уже сказал. Насчет ГОСТов?
На предущей странице большой пост. Эд, открой описание первой стадии работ по ГОСТ и смотри содержание документа, создаваемого на ней.

Цитировать
Насчет RUP. Я конечно не его знаток, я только учусь.

Но вот смотрю книгу Лармана Применение UML 3-е издание (стр.65) - характерный рисунок дисциплин унифицированного процесса (2.7) и (2.8). Видно, что львиная доля бизнес-моделирования приходится на стадию Развития.
Идем далее. стр. 68. Таблица примерный набор инструментов (Development Case {не удачный перевод, имхо})
и видим Бизнес-моделирование - артефакт: Модель предметной области. Фаза Развитие - начало. Тогда как артефакты требований начинаются на стадии Начало.
Реально, конечно, все идеть паралелльно и зависит от проекта.
Эд, а тебе вот эта классическая диаграмма ни о чём не говорит?
(http://era.nih.gov/docs/rup_fundamentals_slide03.jpg)

На мой взгляд Ларман не эксперт по бизнес-моделированию, он свою область компетенции достаточно хорошо описал в названии - "An Introduction to Object-Oriented Analysis and Design and Iterative Development".
Название: Re: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: Shur от 13 Декабря 2007, 18:00:38
Ну это какие-то частности, мы пока вроде о более фудаментальных вещах не договорились.Приведите пожалуйста какой-то пример, я не очень понимаю, о чём речь. На мой взгляд, автоматизация взаимодействий может существенно менять их содержание.Если вы смотрели требования к содержанию раздела "Характеристика объекта автоматизации", то там достаточно поверхностные вещи отражаются. Я не понимаю, зачем в ТЗ тащить то, для чего есть отдельный документ и этап. Есть раздел "Описание существующей информационной системы", который я упоминал выше. Информационная система - естественно шире, чем компьютерная система.
Ведь ТЗ пишется на основе концепции, концепция пишется на основе результатов обследования и описания объекта автоматизации.

1. Я согласен, что автоматизация взаимодействия может менять содержание бизнес-процессов, но может и не изменять. И то и другое может иметь место и зависит от того из-за чего нам пришлось задаваться таким вопросом. Для меня представляется значимым, что, например, бухгалтерский учет возник существенно раньше, чем возникли системы, его автоматизирующие. Соответственно, первый автоматизатор бухгалтерского учета не имел значимых прототипов, которые он мог бы взять за образец.
С другой стороны автоматизация биржевых расчетов (особенно в 80-е годы) сделала возможным массовое применение сложных производных финансовых инструментов типа свопов, опционов на свопы и пр., что вызвало определенный культурный шок на рынке ценных бумаг. Сама запись по книгам учета брокерских операций стала фактически эквивалентом ценной бумаги. Даже для того, чтобы просто обратить эту запись в "бумажную" бумагу надо заплатить 25 долларов (при стоимости бумаг от 3 до 100 долларов делает целесообразность такого действия вообще проблематичным).
А электронный (безбумажный) билет, который сейчас внедряют авиакомпании - от билета в этом объекте одно название. Целый пласт возможных действий с бумажным билетом (типа экспертиза фальсификатов) для электронного билета приобретает совсем другую форму. Получается вроде и билет и не-билет одновременно.

2. Не очень понятно, на какой стадии  нужно решать вопрос о необходимости автоматизации того или иного процесса вообще и  в каких рамках нужно принимать решения об этом. Был случай, когда функциональное подразделения банка заказчика хотело иметь весьма навороченный отчет, который необходимо представлять в соответствии с требованиями ЦБ. Когда оценили трудоемкость разработки отчета, выяснилось, что за непредоставление этого отчета было предусмотрено наказание в виде существенно меньшей суммы денег, чем требовала разработка и предполагаемая поддержка отчета. Не очень понятно, можно ли было бы «отловить» эту ситуацию на этапе НИР или концепции? Не очень понятно, что могло бы заставить составителей ТЗ от Заказчика (прежде всего – ИТ-отдел) задаться  вопросом о необходимости реализации этого отчета при  написании ТЗ?
Решение было найдено потому, что ИТ-специалисты банка в силу ряда обстоятельств были интегрированы в "основную" деятельность по управлению деятельностью банка, что можно считать скорее исключением, чем правилом.   Но какие методики, стандарты  могли бы позволить «отлавливать» такие ситуации, соединяя представления разных специалистов ?
Название: Re: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: Denis Beskov от 13 Декабря 2007, 18:30:41
1. Я согласен, что автоматизация взаимодействия может менять содержание бизнес-процессов, но может и не изменять. И то и другое может иметь место и зависит от того из-за чего нам пришлось задаваться таким вопросом.
Я не говорил, что меняются бизнес-процессы. Меняются взаимодействия. Взаимодействия, для моделирования которых целесообразно применение use-case'ов.

Бизнес-процесс поездки может выглядеть так:
1. Принятие решения о поездке.
2. Покупка билета.
3. Сбор вещей.
4. Поездка.

Где 2 включает:
2.1 Определение возможных поездов.
2.2. Определение подходящего рейса.
2.3. Справка о наличии билетов.
2.4. Заказ билета.
2.5. Оплата билета.
2.6. Получение билета.

В результате автоматизации состав и порядок 2 (бизнес-процесса) может не поменяться. Поменяется то, как именно выполняется 2.1, 2.2 и т.д. (взаимодействия). И как именно поменяется, до этапа проектирования взаимодействия с системой - не ясно, потому что для этого нужно знать возможности системы.

Цитировать
2. Не очень понятно, на какой стадии  нужно решать вопрос о необходимости автоматизации того или иного процесса вообще и  в каких рамках нужно принимать решения об этом.
Опять-таки смотрим документ ГОСТ 34.601-90. Комплекс стандартов на автоматизированные системы АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ.
Цитировать
Стадии и Этапы работ
1. Формирование требований к АС
1.1. Обследование объекта и обоснование необходимости создания АС.
1.2. Формирование требований пользователя к АС.
1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания)
...

1. На этапе 1.1. "Обследование объекта и обоснование необходимости создания в АС" общем случае проводят:

а) сбор данных об объекте автоматизации и осуществляемых видах деятельности;
б) оценку качества функционирования объекта и осуществляемых видах деятельности, выявление проблем, решение которых возможно средствами автоматизации;
в) оценку (технико-экономической, социальной и т.д.) целесообразности создания АС.
Название: Re: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: Юрий Булуй от 13 Декабря 2007, 22:07:11
Кроме того, если посмотреть множество примеров там, то можно увидеть много всякой чуши. А именно происходит путаница ГОСТовского технического проекта и консалтерского системного.

Подтверждаю, что указанный источник нужно очень аккуратно воспринимать в качестве референса. Там документы ОЧЕНЬ разного качества.

Название: Re: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: AlexTheRaven от 13 Декабря 2007, 23:20:03
Я считаю, что ТЗ - документ, фиксирующий предварительную договорённость относительно обязательств разработчика. Элементы концепции, варианты использования и требования там нужны в объёме и абстракции, позволяющих зафиксировать рамки системы, и не больше. Описание архитектуры и средств реализации - только для соответствия стандартам, поэтому - максимально абстрактное. Описания бизнес-процессов там не нужны - как описать рамки ориентированной на БП системы, если БП до этого не изучены? Зачем пытаться уместить всё в ТЗ - есть много других документов :) .
Но с другой стороны, практика - главный критерий всего. Если у Вас есть положительный опыт создания, утверждения и использования ТЗ, включающего всё выше перечисленное, этим опытом обязательно нужно поделиться.
Название: Re: Писать ли статью про ТЗ по ГОСТ 34.602?
Отправлено: bustor от 14 Июля 2008, 16:10:29
У меня подходит к концу проект, в котором целый этап был посвящен написанию ТЗ ровно по ГОСТ 34.602. Не то, чтобы это первое ТЗ по ГОСТ у меня, но такого трепетного отношения мы к нему еще не проявляли, к тому же со временем приходит все новое понимание старых вещей. Хорошо или плохо, но мы, естественно написали этот документ.
Из вопросов которые я мог бы осветить в потенциальной статье мне наиболее интересны следующие:
- Место концепции в ТЗ
- Место описания бизнес-процессов в ТЗ
- Место вариантов использования и других требований в ТЗ

Чуть менее интересно, по причине того, что это может быть очень по разному у всех
- Что мы писали в определеннных разделах (наше толкование ГОСТ)
- Последовательность разработки

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