Что произойдет с организацией если система не будет введена в эксплуатацию ответ

Анализ осуществимости

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

1. Отвечает ли система бизнес-целям организации-заказчика и организации-разработчика?

2. Можно ли реализовать систему, используя известные технологии и не выходя за пределы заданной стоимости и заданного времени?

3. Можно ли объединить систему с другими уже эксплуатируемыми системами?

Для ответа на первый (и главный) вопрос нужно опросить заинтересованных лиц, например, менеджеров подразделений, в которых будет использоваться система, для выяснения того,

• что произойдет с организацией, если система не будет введена в эксплуатацию;

• как система будет способствовать целям бизнеса;

• какие текущие проблемы поможет решить система и т.д.

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

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

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

Бизнес-требования – это вся та информация, которая описывает финансовые, рыночные и другие коммерческие преимущества, которые пользователи (и разработчики) хотят получить от использования продукта.

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

Образ продукта (product vision) описывает продукт во времени. В нем указывается, как продукт будет изменяться (эволюционировать) от текущего состояния при развитии или изменении бизнес-целей. Границы проекта (project scope) относятся к определенной итерации проекта или версии продукта. Образ продукта – это определение стратегического образа системы, позволяющей выполнять бизнес-задачи. Образ будет основой принятия решений в течение всего жизненного цикла продукта, т.к. содержит описание долгосрочных целей и назначения продукта, которое удовлетворяет различных заинтересованных лиц, основано на существующих (или прогнозируемых) рыночных факторах, учитывает структуру и стратегию развития организации.

Сведения об образе и границах проекта могут быть оформлены в виде отдельного документа [1], владельцами которого являются лица, финансирующие проект. Этот документ должен содержать следующую информацию.

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

• целевой аудитории пользователей, их потребности или возможности;

• имени, категории и ключевого преимущества – основы для использования;

• отличий от конкурентов или текущего бизнес-процесса, описание основного

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

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

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

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

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

Границы проекта относятся к определенной итерации проекта или версии продукта.

Образ продукта (product vision) выстраивает работу всех заинтересованных лиц в одном направлении. Он описывает, что продукт представляет собой сейчас и каким он станет впоследствии. Границы проекта (project scope) показывают, к какой области конечного долгосрочного образа продукта будет направлен текущий проект. В положении о границах определена черта между тем, что входит в проект и тем, что остается вовне. То есть указанные рамки также определяют ограничения проекта. Более детально эти сведения изложены в базовой версии требований, которую разрабатывает команда для данного проекта.

Источник

Что произойдет с организацией если система не будет введена в эксплуатацию ответ

Об актуальных изменениях в КС узнаете, став участником программы, разработанной совместно с АО «Сбербанк-АСТ». Слушателям, успешно освоившим программу выдаются удостоверения установленного образца.

Программа разработана совместно с АО «Сбербанк-АСТ». Слушателям, успешно освоившим программу, выдаются удостоверения установленного образца.

Какое предусмотрено наказание за эксплуатацию не введенного объекта, если в одном разрешении на строительство указано шесть объектов? Штраф будет за каждый объект или один за все объекты?

По данному вопросу мы придерживаемся следующей позиции:
Эксплуатация каждого отдельного объекта капитального строительства без разрешения на ввод его в эксплуатацию является самостоятельным административным правонарушением. Поэтому за каждое из таких правонарушений должно быть назначено административное наказание.

Ответ подготовил:
Эксперт службы Правового консалтинга ГАРАНТ
Прибыткова Мария

Ответ прошел контроль качества

12 сентября 2019 г.

© ООО «НПП «ГАРАНТ-СЕРВИС», 2021. Система ГАРАНТ выпускается с 1990 года. Компания «Гарант» и ее партнеры являются участниками Российской ассоциации правовой информации ГАРАНТ.

Все права на материалы сайта ГАРАНТ.РУ принадлежат ООО «НПП «ГАРАНТ-СЕРВИС». Полное или частичное воспроизведение материалов возможно только по письменному разрешению правообладателя. Правила использования портала.

Портал ГАРАНТ.РУ зарегистрирован в качестве сетевого издания Федеральной службой по надзору в сфере связи,
информационных технологий и массовых коммуникаций (Роскомнадзором), Эл № ФС77-58365 от 18 июня 2014 года.

ООО «НПП «ГАРАНТ-СЕРВИС», 119234, г. Москва, ул. Ленинские горы, д. 1, стр. 77, info@garant.ru.

8-800-200-88-88
(бесплатный междугородный звонок)

Редакция: +7 (495) 647-62-38 (доб. 3145), editor@garant.ru

Отдел рекламы: +7 (495) 647-62-38 (доб. 3136), adv@garant.ru. Реклама на портале. Медиакит

Если вы заметили опечатку в тексте,
выделите ее и нажмите Ctrl+Enter

Источник

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

4.1. Определение предметной области

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

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

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

Анализ предметной области является основой для анализа осуществимости проекта и определения образа (концепции) продукта и границ проекта.

Анализ осуществимости

Для ответа на первый (и главный) вопрос нужно опросить заинтересованных лиц, например, менеджеров подразделений, в которых будет использоваться система, для выяснения того,

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

Постановку бизнес-задачи надо обсуждать с Заказчиком, или будущим Владельцем системы.

Вопросы, которые ему стоит задать, это:

Системные требования нужно выяснять у IT-специалистов Заказчика, если таковые имеются, из специфики контекста использования системы, опыта построения аналогичных систем (у IT-Экспертов-Архитекторов) и Специалистов по отдельным аспектам системы, значимым для данного проекта (Юристы, Эргономисты, и т.д.) и Заказчика:

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

Оптимальный подбор предоставляемых средств определяет все остальное

4.3. Формирование и документирование требований к проекту

Для всех проектов разработки программного обеспечения, кроме самых тривиальных, важно иметь единственный «руководящий документ», в котором определяются:

Единственный руководящий документ, который управляет всем процессом разработки, должен включать несколько разделов:

Источник

Глава 2. Разработка требований к ПО

Анализ осуществимости

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

Различают четыре основных этапа процесса разработки требований:

— анализ технической осуществимости создания системы,

— формирование и анализ требований,

— специфицирование требований и создание соответствующей документации,

— аттестация этих требований.

Анализ осуществимости должен осветить следующие вопросы:

Отвечает ли система общим и бизнес-целям организации-заказчика и организации-разработчика?

Можно ли реализовать систему, используя существующие на данный момент техно¬логии и не выходя за пределы заданной стоимости?

Можно ли объдинить систему с другими системами, которые уже эксплуатируются?

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

Что произойдет с организацией, если система не будет введена в эксплуатацию?

Какие текущие проблемы существуют в организации и как новая система поможет их решить?

Каким образом система будет способствовать целям бизнеса?

Требует ли разработка системы технологии, которая до этого не использовалась в организации?

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

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

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

На требования к системе могут влиять политические факторы.

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

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

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

Лица, участвующие в формировании требований, часто не знают конкретно, чего они хотят от компьютерной системы.

Процесс формирования и анализа требований проходит через ряд этапов:

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

Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области.

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

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

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

Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость.

Распространены три подхода к формированию требований: метод, основанный на множестве опорных точек зрения, сценарии и этнографический метод.

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

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

Метод опорных точек зрения

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

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

Различные методы предлагают разные трактовки выражения «точка зрения». Точки зрения можно трактовать следующим образом:

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

Как получатели системных сервисов. В этом случае точки зрения являются внешними (относительно системы) получателями системных сервисов. Точки зрения помогают определить данные, необходимые для выполнения системных сервисов или их управления.

Как получатели системных сервисов. В этом случае точки зрения являются внешними (относительно системы) получателями системных сервисов. Точки зрения помогают определить данные, необходимые для выполнения системных сервисов или их управления.

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

Этот тип точек зрения имеет ряд преимуществ:

Точки зрения, внешние к системе, — естественный способ структурирования про­цесса формирования требований.

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

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

Таблица 1 ‑ Сервисы, соотнесенные с точками зрения

ИНОСТРАННЫЙ КЛИЕНТ

Запрос баланса Выдача чеков Посылка сообщения

диагностики Зачисление денег

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

Сценарии особенно полезны для детализации уже сформулированных требований, поскольку описывают последовательность интерактивной работы пользователя с системой. Каждый сценарий описывает одно или несколько возможных взаимодействий.

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

В большинстве случаев сценарий включает следующее:

— Описание состояния системы после завершения сценария.

— Информацию относительно других действий, которые можно осуществлять во время выполнения сценария.

— Описание исключительных ситуаций и способов их обработки.

— Описание нормального протекания событий.

— Описание состояния системы в начале сценария.

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

1. Данные, поступающие в систему или исходящие из нее, представлены в эллипсах.

2. Управляющая информация показана стрелками в верхней части прямоугольников.

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

4. Исключительные ситуации показаны в нижней части прямоугольников.

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

Варианты использования (use-case) — это методика формирования требований, основанная на сценариях. Они стали основой нотаций в языке моделирования UML при описании объектных моделей систем.

Этнографический подход

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

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

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

1. Проверка правильности требований.

2. Проверка на непротиворечивость.

3. Проверка на полноту.

4. Проверка на выполнимость.

Существует ряд методов аттестации требований:

1. Обзор требований.

3. Генерация тестовых сценариев.

4. Автоматизированный анализ непротиворечивости.

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

С точки зрения разработки требования можно разделить на два класса:

1. Постоянные требования.

2. Изменяемые требования.

Планирование управления требованиями

1. Идентификация требований.

2. Управление процессом внесения изменений.

3. Стратегия оперативного контроля.

— Информация об источнике требования

— Информация о требованиях

— Информация о структуре системы

4. Поддержка CASE-средств.

Процесс управления изменениями состоит из трех основных этапов:

1. Анализ проблем изменения спецификации.

2. Анализ изменений и расчет их стоимости.

3. Реализация изменений.

Вопросы для обсуждения

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

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

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

Формальные спецификации

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

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

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

Разработка спецификация и проектирование могут выпол­няться параллельно, когда информация от этапов разработки спецификации передается к этапам проектирования и наоборот.

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

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

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

Подход, ориентированный на моделирование, при котором модель системы стро­ится с использованием математических конструкций, таких, как множества и по­следовательности, а системные операции определяются тем, как они изменяют со­стояния системы.

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

Таблица 2 ‑ Языки разработки формальных спецификаций

Последовательные системы

Параллельные системы

Основанный на моделях

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

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

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

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

Структура спецификации объекта состоит из четырех компонентов:

Введение, где объявляется класс ( sort ) объектов. Класс — это общее название для множества объектов. Он обычно реализуется как тип данных. Введение может так­же включать объявление импорта ( imports ), где указываются имена спецификаций, определяющие другие классы. Импортирование спецификаций делает эти классы доступными для использования.

Описательная часть, в которой неформально описываются операции, ассоцииро­ванные с классом. Это делает формальную спецификацию более простой для пони­мания. Формальная спецификация дополняет это описание, обеспечивая одно­значный синтаксис и семантику операций.

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

Часть аксиом, где определяется семантика операций посредством создания ряда аксиом, которые характеризуют поведение абстрактного типа данных. Эти аксиомы связывают операции создания объектов класса с операциями, проверяющими их значения.

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

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

Операции конструирования, которые создают или изменяют объекты класса. Обычно их называют Create (Создать), Update (Изменить), Add (Добавить) или Cons (Конструирование).

Операции проверки, которые возвращают атрибуты класса. Обычно им дают имена, соответствующие именам атрибута, или имена, подобные Eval (Значение), Get (Получить) и т.п.

Хорошим эмпирическим правилом для написания алгебраической спецификации является создание аксиом для каждой операции конструирования с применением всех операций проверки. Это означает, что если есть m операций конструирования и n операций проверки, то должно быть определено m x n аксиом.

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

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

Источник