Нет, Shur, я не за то, чтобы его выкидывать, а зато, чтобы его грамотно использовать. Т.е. в МУ как и следует обыграть ситуация с современными подходами, хотя бы разделить структурный подход и объектный и показать, что в каком случае применять из ГОСТОв и как.

1. По жизни не все документы из ГОСТ используются в проекте. Поэтому пункты структуры методуказаний можно предложить студентам использовать в качестве каталога, из которого они должны выбрать те, которые, как они считают, необходимы для их конкретной работы. И в качестве главного ограничения свободы выбора студентов можно поставить условие, что выбранные документы должны покрывать все стадии проекта (ГОСТ 34.601-90), хотя, возможно, и с рзной степенью полноты.
2. ИМХО неверно требовать от дипломника чтобы он одинаково полно писал и ТЗ и тех. проект. Требует раздвоения личности - представлять себя то Заказчиком (когда пишешь ТЗ), то исполнителем (когда техпроект). По жизни очень часто бывает, что Исполнитель пишет и ТЗ и техпроект потом, но это если ТЗ - простая формальность. А написать в даже в этом случае хорошее ТЗ без искушения проваливания в обсуждение деталей разработки (уровня техпроекта) - для разработчиков сущее мучение. Проблемы, как правило, вылезают на уровне описания программы и методики испытаний - Заказчик стремится испытывать систему как черный ящик, а границы этого черного ящика как раз задаются и должны выдерживаться при написании ТЗ (с чем разработчики, пишущие ТЗ, часто не справляются). Поэтому ИМХО полезно, когда за написания ТЗ и программы испытаний отвечают одни люди, а за техпроект- другие. Может быть возможно рзрешить дипломникам акцентировать свои работы с точки зрения роли, в которой они себя видят? Наверняка большая часть будет писать техпроекты, а задачу написания диплома с акцентом на ТЗ можно рекомендовать тем, кто стремится в аналитики .

В результате я все-таки с ребятами оформлю как нам лучше для того, чтобы представить свой проект. А комиссия раз и снизит ему за оформление - мол не стандартно у вас мил человек!

Наверное, методуказания должны требовать, чтобы дипломник декларировал явно в  какой методологии он выполнил работу и комиссия должна будет оценивать работу на соответствие заявленной методологии (как по оформлению, так и по сути). Описанный в первом посте список можно оставить как рекомендацию тем, кто выбрал ГОСТ, которая должна облегчить работу студентам, не более того.
Издавать нормативные документы от кафедры, которые фактически будут задавать свою трактовку (версию?) методолгий представляется нескромным .

Издавать нормативные документы от кафедры, которые фактически будут задавать свою трактовку (версию?) методолгий представляется нескромным .

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

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

Вопрос: существует ли трассировка между российскими ГОСТами и документами и артефактами разлияных методологий разработки ПО?

Юрий Булуй проводил подобную работу. Я в сети встречал его презентацию к докладу на какой-то конференции. Не сохранил. А теперь найти не могу . Юрий, может быть, выложите ее нам на растерзание.
Работа называлась "классификация требований".

Как всегда мне очень нравится бежать впереди паровоза.

Внимательно почитал презентацию Юры, которая у меня уже если не год лежит.

Кроме того, отличный анализ связи ГОСТ с другими видами документов и методологиями сделан в курсе "Анализ требований".

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

Для развития мысли все-таки приведу текст содержания старых методуказаний
вот они:
АННОТАЦИЯ (1 стр.)
ВВЕДЕНИЕ (2 - 3 стр.)
1. АНАЛИТИЧЕСКАЯ ЧАСТЬ (10 - 15 стр.)
2. ПРОЕКТНАЯ ЧАСТЬ (20 - 25 стр.)
3. ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ (20 - 25 стр.)
4 ОБОСНОВАНИЕ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ (6 - 10 стр.)
ЗАКЛЮЧЕНИЕ (1 - 2 стр.)

Ну и самое примерное содержание

Аннотация. Текст аннотации (реферата) представляет собой краткое изложение всей работы с основными сведениями и выводами. В ней целе-сообразно кратко охарактеризовать: цель работы, объект исследования или разработки; основные методы исследования, анализа и проектирования; полученные результаты их область применения и новизну; основные кон-структивные, технологические и технико-эксплуатационные характери-стики; рекомендации по внедрению (результаты внедрения); общую и эко-номическую эффективность. В аннотации следует привести сведения об объеме пояснительной записки, количестве иллюстраций, таблиц, количе-ство использованных литературных источников.

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

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

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

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

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

Далее по тексту идет разъяснение пунктов, но без навязывания каких-либо нотаций, ГОСТов и т.п. Т.е. просто описывается общий круг вопросов, на которые следует ответить при оформлении записки. В частности раскрывают отдельные тематики: создания АРМ, БД, модернизация, конфигурирование и т.п.

В качестве примера приведу тематику для АРМ:

4.1. Тематика, связанная с разработкой информационного и про-граммного обеспечения информационных систем и АРМ
   Примерный перечень материалов основной части дипломного проек-та.

1. Аналитическая часть
­   Разработка основных требований к информационному и программному обеспечению
­   Обоснование необходимости разработки информационного и про-граммного обеспечения
­   Анализ возможных вариантов информационного и программного обес-печения
­   Обоснование выбора инструментальных средств, систем программиро-вания, пакетов прикладных программ, СУБД

2. Проектная часть
­   Разработка системы показателей и реквизитов и системы классифика-ции информации.
­   Разработка системы кодирования информации.
­   Унификация форм документов и разработка системы документооборо-та.
­   Разработка основных принципов организации базы данных.
­   Разработка концептуальной и логической схем базы данных.
­   Разработка структуры информационных массивов.
­   Обоснование и выбор стандартных методов, алгоритмов и программ поиска информации, внесения в нее изменений, сжатия информации, уменьшения времени приема и выдачи хранимой информации
­   Обоснование необходимости разработки нестандартных алгоритмов и программ.
­   Разработка нестандартных алгоритмов и программ.

3. Технологическая часть
­   Обоснование и выбор комплекса технических средств
­   Обоснование и выбор машинных носителей
­   Разработка (выбор) программных средств обеспечения достоверности преобразования информации и сохранности информационных массивов.
­   Привязка разработанного комплекса программ и информационных мас-сивов к комплексу технических средств
­   Описание основных режимов функционирования системы
­   Разработка сопроводительной документации.

В свете вышеизложенного приведу цитату коллеги
"в общем, у меня родилось такое же предложение, как в конце у Shur. по-моему, студенту нужно предложить создать пакет документов в соответствии с той методологией, которую он выберет. как ты знаешь, мнение, что agile-методики не используют документы, является заблуждением.
другое дело, что если основываться на ГОСТ, то только письменные документы дают какое-то представление о проекте и процессе его реализации. а для гибких методик надо потребовать еще какие-то артефакты - те же карточки историй заказчика
...а почему МУ должны задавать, фактически, шаблон выполнения работы? пусть они задают перечень ВОПРОСОВ, на которые представленные артефакты должны отвечать
...наличие этих частей ничему не противоречит. просто надо сформулировать список вопросов, на которые должны отвечать представленные в части документы. например, аналитическая часть - описание бизнес-процессов и плана их модернизации. в какой нотации и по какой методике - неважно
и, конечно, надо включить во введение требование обоснования выбора методики
...меня всегда убивали методички, в которых все разжевано. это обман студента, на самом деле - в жизни так не бывает, всегда надо делать какой-то выбор и что-то адаптировать. поэтому если мы хотим приблизить квал. работу к жизни, то надо ставить вопросы и требования, а не предлагать план ответа"

Таким образом, идея такая - а имеет ли смыл что-то менять, может только содержательную часть разделов более четко?

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

1. Вообще, тема,затронутая Эдуардом, для меня тоже достаточно актуальна. Года через 2 у нас созреет первый выпуск и прийдется резко соображать методичку для дипломной работы.
На мой взгляд старая структура диплома предоставляет больше свободы для творчества. Если взять и привязатся к ГОСТу то тут есть два варианта либо все делать по нему, либо брать только некоторые виды документов. К тому же по опыту скажу,что ГОСТ как правило перегружен всякими безсодежательными документами порою не несущими никакого смысла. Мне доводилось один раз оформлять документацию на ПО по ГОСТу для одного оборонного предприятия. В принципе работа не сложная если есть шаблон но жутко рутинная . Возникает вопрос: а нужно ли это студенту? Ведь если он будет работать на таких предприятиях,где требуют оформлять по ГОСТ то этому его и так  научат. Таких знатоков- старичков сейчас хоть отбавляй, а вот людей реально что-либо делающих очень мало, особенно в оборонке, куда зачастую идет молодой специалист, чтобы откосить от армии.
Поэтому привязываться  к ГОСТ все равно что подрезать птице крылья. К тому же на каждом предприятии и даже в каждой фирме выработался или вырабатывается свой набор документов. Где по госту а где просто по наитию
2. А теперь по структуре.  Можно оставить старую структуру но с изменениями. Я думаю  пора выкинуть всякие экономики и БЖД из диплома- все это давно превратилось в формальность. Мы, например, на кафедре так и сделали. Я считаю лучше всего делать привязку к Жизненному циклу ПО. Это то что подтверждено и временем и практикой. Сюда легко можно увязать и RUP и все остальное.  А вот какой ЖЦ выбрать -должен решать студент с руководителем. Здесь все зависит от уровня знаний и того и другого.
3. И наконец диплом - это все-таки квалификационная работа и должна удовлетворять определенным формальным требованиям. К тому же в комиссию порой входят люди не очень хорошо знакомые с современными методиками проектирования ПО. Для них RUP- это ново и не совсем непонятно, а то что непонятно вызывает раздражение. Нужно это учитывать.

Короче говоря нужно искать разумный компромис между ГОСТ, старой методикой и современными методами. Брать из них лучшее и использовать.

Вот мои соображения

Здравствуйте, Алексей.

Спасибо за интерес к теме.

Действительно, старое руководство, кажется, дает больше свободы и студенту и руководителю. Лично я рекомендую (но не настаиваю) студентам использовать оформление записки по Вигерсу, по крайней мере, что касается анализа требований и формирование ТЗ. При этом студенты частенько используют то, что им дали в крусе Проектирование инфосистем (а их учать по Вендрову: Проектирование ПО для ЭИС).

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

Почему вообще возникла потребность в каком-то изменении. В ходе ряда защит члены комиссии высказывали неудовольствие содержательной частью записки, в частности сложно было найти ТЗ, понять где собственно проектная часть и т.п. Кроме того, ряд членов комиссии, люди с солидным опытом жизни, высказывали недоумения  структуре записке: что это за Аналитическая проектная и технологическая часть - мол таких элементов в реальной практики оформления ИТ-проектов нет. Потому предложена структура, которая формально отражает некоторые стадии жизненного цикла: ТехЗадание, Само проектирование и его реализация (Техпроект), Рабочая документация и Внедрение.

Насчет экономической части - сказать ничего не могу. Да она формальна. Это во многом зависит от консультанта по экономической части. Я уже давно рекомендую использовать для этого тот же MS Expert Project. Вообще лучше бы тут была не экономическая часть как таковая, а скажем формирование бюджета проекта с оценкой экономической эффективности, хотя последнее значительно натянуто и не ко всем работам подходит.

Анализируя дискуссию на форуме и личные переговоры с коллегами, можно попытаться предложить такую структуру.

Постановка задачи - краткое описание проблемы, объекта исследования

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

Собственно проект - который уже будет содержать структуру выбранной методологии в том или ином объеме и вероятно будет содержать:
Концепцию
ТЗ
Архитектуру системы
Детальное проектирование
Вопросы конструирования
Результаты тестирования и соответствия заявленным требованиям (причем как мне кажется - это должен делать руководитель или рецензент)
Необходимую рабочую документацию, раскрывающие вопросы внедрения
что-то еще....

Причем последняя часть может сильно зависить от типа квалификационной работы и ее содержание может корректироваться

Собственно проект - который уже будет содержать структуру выбранной методологии в том или ином объеме и вероятно будет содержать:
Концепцию...

Имеется ввиду концепция методологии, например, той же RUP или концепция разрабатываемой ИС?

ТЗ

Могу предложить такую структуру ТЗ (близко к ГОСТу, выбросил некоторые пункты )

1. НАИМЕНОВАНИЕ
1.1. Наименование - .
1.2. Заказчик –
1.3. Исполнитель -
2. ЦЕЛЬ РАБОТЫ
2.1. Целью работы является ...
3. НАЗНАЧЕНИЕ РАЗРАБАТЫВАЕМОГО ПРОГРАММНОГО ПРОДУКТА
3.1. Разработка программного обеспечения для ... должно обеспечить уменьшение времени...
4. ТРЕБОВАНИЯ К РАЗРАБАТЫВАЕМОМУ ПРОГРАММНОМУ ПРОДУКТУ
4.1. Разработанное ПО ... должно включать в себя:
- ..
- ..
- ..
- ..
- ..

4.2. ПО .. должно обеспечивать возможность работы под управлением ОС ...
4.3. ...
4.4. ...
...

5. ТРЕБОВАНИЯ К ПРОГРАММНОЙ ДОКУМЕНТАЦИИ
5.1. Документация на ПО ... должна быть разработана в соответствии с требованиями ЕСПД
5.2. Комплект программной документации (ПД) должен содержать:
 - исходные тексты программ ПО ...;
 - описание применения ПО.
5.3. Программная документация предоставляется Заказчику на магнитных носителях в 1 экз.

6. ЭТАПЫ И СРОКИ ВЫПОЛНЕНИЯ РАБОТЫ
6.1. .....


7. ПОРЯДОК ВЫПОЛНЕНИЯ И Сдачи работы
7.1. На приемку работы Исполнителем предъявляются:
-   программная документация и исполняемые модули на магнитных носителях - 1 экз.
7.2. Данное техническое задание может корректироваться и дополняться установленным порядком.

Архитектуру системы
Детальное проектирование

Может объединить их в один раздел? или как подразделы в один

Вопросы конструирования

Непонятно какое имеет отношение к ПО. У меня сразу возникает ассоциация с конструкторской документацией
Конструирование скорее относится к аппаратуре, например конструирование корпуса изделия...

Результаты тестирования ...

Вот интересный раздел! Сюда студенты как правило втыкают какие-нибудь аляпистые формочки со всякими там наворотами и минимум текста. Возникает вопрос а нужен ли он? Может лучше сделать руководство пользователя.

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

Я вам сразу скажу что это превратится в банальное переписывание фраз из ТЗ
типа Требуется то-то... ->  Выполнил  то-то..
Кому из преводавателей охота выдумывать что-то для каждого студента? А если еще их с десяток?

Необходимую рабочую документацию, раскрывающие вопросы внедрения
что-то еще....

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

Причем последняя часть может сильно зависить от типа квалификационной работы и ее содержание может корректироваться

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

Простите за, возможно, слишком резкую критику :-)

Простите за, возможно, слишком резкую критику :-)

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

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

Кроме того, а зачем адаптировать ТЗ гостовское, надо его использовать и все. Все эти ГОСТы носят рекомендательный характер, мы ими можем рукводствоваться, а можем игнорировать.

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

При описании результатов тестирования, конечно, студент может банально переписать содержание ТЗ. Однако тут и нужен руководитель. А если он и ухом не шевелит, то комиссия может проверить при желании на соответствие.
Хотя в прочем я не настаиваю, просто знаю, что многие руковдители просто читают записку и совершенно не смотрят на проект и его не тестируют. Хорошо, если студент делает реальный проект и у него есть реальный заказчик.

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

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

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

Понятно, у нас тоже есть проблемы

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

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

Кроме того, а зачем адаптировать ТЗ гостовское, надо его использовать и все. Все эти ГОСТы носят рекомендательный характер, мы ими можем рукводствоваться, а можем игнорировать.

Там много воды. Нужны вам скажем требования к упаковке или маркировки изделия?
 

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

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

При описании результатов тестирования, конечно, студент может банально переписать содержание ТЗ. Однако тут и нужен руководитель. А если он и ухом не шевелит, то комиссия может проверить при желании на соответствие.

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

Вот-вот большинство так и делает

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

Почему же пусть приучаются писать реальную документацию к проекту, пусть упрощенную, но реальную. Ведь так стояла изначально задача:

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

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

не видел надо поглядеть...

Похоже дискуссия будет только между нами. А соответственно носить академический характер, но может и к лучшему...

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

Костяк есть в старой методичке вполне норальный костяк, написанный надо сказать на основании опыта других вузов. Другое дело, что это костяк нужно конкретизировать походу дипломного проекта. Что я лично и делаю.
С другой стороны студенты обучались на курсе Проектирование ИС, где им читался курс ведения документации проекта. Так что в целом костяк есть.

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

Понимаете шаблонов масса. Шаблон от Вигерса, шаблон РУП, шаблон ОпенУП, ГОСТ наконец
 

Почему же пусть приучаются писать реальную документацию к проекту, пусть упрощенную, но реальную. Ведь так стояла изначально задача:

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

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

Т.е. в ходе анализа методички + анализа того, что она должна содержать, приходим к мысли, что для начала надо посмотреть, а так ли учим и чему учим :-)

Можно соблюсти скажем формальные признаки оформления работы по ГОСТу, а содержание будет неверным.

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

Я тут посмотрел коллекцию дипломов, которые я рецензировал из разных вузов - везде структура очень разная. есть близкая к ГОСТ. Однако содержательная часть довольно забавная - несколько примеров

3.3.1   Общие требования к системе

Система материальными ресурсами предприятия должна удовлетворять ряду требований предъявляемых к ней как системе удовлетворения информационных потребностей на предприятии. Определим их:

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

     6. Проектируемая система должна обеспечить информацией, удовлетворяющей требованиям полноты, достоверности, точности, своевременности.

как это можно понять? и использовать?

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

совершенно инертная формулировка

3.3.1.9 Требования по стандартизации и унификации

ИС должна обеспечивать:
•     Совместимость по форматам и процедурам обмена с другими подсистемами предприятия;

Каким таким форматам и процедурам?


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

Вот какая мысль пришла в голову.

Дискуссия по поводу содержательной части рекомендаций к дипломному проектированию с моим коллегой зашла в тупик.
Коллега настаивает на использовании ГОСТ, как единственной разумной альтернативе при описании и документировании цикла разработки АС или АИС.
Я считаю, что альтернатив несколько - они могут определяться общей методологией разработки или  процессом разработки.
Коллега утверждает, что одно другому не противоречит.
Я полагаю, что ГОСт - является методолгией структурного подхода, а следовательно у студентов, практикующих объектный подход, возникнеть необходимость затрачивать определенные усилия для адаптации используемого подхода или методологии к ГОСТу.

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

Поэтому требования к ИС неравны требованиям к программному обеспечению, и требования к программному обеспечению есть подмножество требований к ИС.

Исходя из этой логики, получается коллега прав, утверждая необходимость использования ГОСТов. Например, модель FRUPS+ не содержит таких понятий как организационное обеспечение, правовое обеспечение и некоторые другие. Или же я не прав, и все это входит в раздел business rules?

Стоит ли при разработки АИС учитывать главным образом вопросы разработки software.
Можно ли полагать в настоящий момент, что АИС - просто некоторый класс software?

Кто что думает по этому поводу?

А кого готовите-то? "Информационные системы и технологии" - это слишком общее название. Как специальности называются?