Формализация требований что это
что есть
к программному обеспечению
с помощью
Назначение формализации требований
Что есть формализация требований?
Варианты формализации требований
Неформальная постановка требований
Данный метод хорош в случаях:
Важно вовремя понять, когда такой способ перестает работать и необходимы формальные подходы.
Формализация требований с помощью use-case диаграмм UML
ФОРМАЛИЗАЦИЯ ТРЕБОВАНИЙ С ПОМОЩЬЮ USE-CASE ДИАГРАММ UML
Формальная модель требований
В данном случае строится модель, описывающая некоторые аспекты (чаще функциональные) системы.
Существует процесс построения формального описания требований к программной системе FOREST (FOrmal REquirements Specification and Testing), в который включено использование формальной модели требований в качестве основы для построения тестов.
ФОРМАЛЬНАЯ МОДЕЛЬ ТРЕБОВАНИЙ
FOREST предоста вляет возможность автоматизации выполнения ряда сложных и трудоемких задач ра зработки, таких как:
ФОРМАЛИЗАЦИЯ требований в виде документов
По SWEBOK для описания комплексных проектов в части требований используется три основных документа:
Формализация требований с помощью технического задания (ТЗ) и технического проекта (ТП)
что есть Техническое задание?
Техническое задание — исходный документ на проектирование технического объекта, устанавливающий:
В ТЗ описывается, ЧТО нужно заказчику, в отличие от по следующей проектной документации, в которой говорится, КАК этого достичь.
что есть технический проект?
Технический проект – это документ (или их совокупность), который предназначен для технической реализации требований, сформулированных в Техническом задании, содержит окончательные проектные решения по изделию (автоматизированной системе).
Разрабатывается архитектором системы или группой программистов во главе с ним.
КЕМ пишется тЗ?
Сотрудник должен иметь ряд навыков и знаний, таких как опыт программирования и построения баз данных, хорошее знание систем, с которыми придется иметь дело.
Однако чем больше проект, тем и больше людей работает над Техническим заданием.
А нужно ли техническое задание?
В Scrum, Agile и прочих технологиях говорится: «минимум бумаг, ближе к Заказчику, больше конкретики и быстрее к результату». Но формализацию требований никто не отменял и там это явно сказано.
Хорошее техническое задание — важнейшая составляющая успеха в проекте, оно является основой порядка, грамотное ТЗ — это 50 % успеха в решении задачи, однако это не панацея.
Стандарты написания и оформления ТЗ и ТП
Понятие «Хорошего ТЗ»
Для менеджера ТЗ хорошее тогда, когда по нему удается сделать проект с первого захода. Когда время, ресурсы и результат оправдали ожидания.
Чтобы при сдаче избежать разработчику — неприятных вопросов, а заказчику — неожиданных трат, нужно заранее определить требования. Заказчику нужно понимать что он будет принимать у разработчиков.
В отличном ТЗ определен порядок тестирования и приемки результата, причем не скопирован из ГОСТа, а действительно продуман и принят сторонами.
дл я кого пишется ТЗ?
У ТЗ два основных читателя:
и один редкий — тот, кто будет разбираться в проблемах между первыми двумя.
Типичные реакции типичного клиента на ТЗ в 50-70 страниц:
Ведение листа изменений. Там могут появиться и отклонения от требований, и их придется согласовывать.
требования В ТЗ?
При написании ТЗ необходимо :
какие требования писать в тз?
Здесь нам поможет ГОСТ. Например:
Структура ТЗ и обязательные пункты
ГОСТ рекомендует следующие разделы:
Методы сбора требований или «Как понять, что хочет заказчик?»
Данная статья будет полезна как аналитикам, так и менеджерам, занимающимся сбором и анализом требований. В ней описаны основные методики сбора требований, а также их плюсы и минусы. Возможно, что-то вы уже применяли на практике, а о чем-то, возможно, не знали. В общем, эта статья для всех тех, кто уже занимается бизнес — анализом или только планирует пополнить ряды аналитиков. 
Сбор требований — это один из самых важных этапов процесса создания любой информационной системы, будь то десктопное, веб или мобильное приложение или же просто доработка уже существующего решения. Прежде, чем начать собирать требования, необходимо выявить всех заинтересованных лиц (стейкхолдеров), которые будут пользоваться системой. Чем точнее будет этот список, тем полнее будут требования. Итак, для начала, рассмотрим кто же такие стейкхолдеры.
Стейкхолдерами могут быть любые физические лица и/или организации, которые активно участвуют в нашем проекте, и чьи интересы могут быть затронуты не только в процессе создания системы, но и непосредственно по завершению самого проекта. Ими могут быть менеджеры, начальники отделов, директора, любые сотрудники организации, которые будут хоть как-то взаимодействовать с готовым решением, и чьи требования (пожелания, идеи, потребности, проблемы) будем собирать.
Существует множество различных техник сбора требований, которые помогут лучше понять, что же хочет заказчик.
Рассмотрим основные из них чуть подробнее:
Анкетирование
Данный способ подразумевает под собой составление листа-опросника (анкеты, брифа), который может содержать открытые (требуют от опрашиваемого сформулировать его ответ) и закрытые (требуют от опрашиваемого выбрать ответ из предложенных вариантов) вопросы.
Анкетирование используется для того, чтобы подтвердить или детализировать ранее известные требования, выбрать параметры для решений.
Самым известным примером анкетирования может быть “Бриф на разработку сайта” — анкета содержащая список основных требований и информацию о будущем сайте.
Интервью
Этот метод известен многим, своего рода беседа “по душам” с заинтересованным лицом, тет-а-тет.
Необходимо задавать открытые вопросы для получения информации и закрытые для того, чтобы подтвердить или опровергнуть конкретные варианты требований.
Данный способ применяется, в основном, для получения информации по какой-либо конкретной теме и/или для уточнения требований.
Многим может показаться этот способ достаточно легким, но это не так. Провести хорошее интервью достаточно сложно. Вы должны гибко реагировать на реакцию интервьюируемого и в случае необходимости изменять порядок заготовленных вопросов или их формулировку. Не забудьте включить диктофон во время интервью или вести заметки.
Автозапись
Данный метод подразумевает под собой работу с записями, письмами (электронными письмами), а также с любым другим документом, автором которого является Заказчик или конечный пользователь (т.е. стейкхолдер).
В действительности это может быть и документ и наговоренная на диктофон последовательность действий или самая обычная салфетка, на которой заказчик набросал свои идеи / проблемы /хотелки, которые необходимо превратить в полноценные требования, согласовать и передать в разработку.
Примером такого метода может быть работа с концепцией или видением проекта (сам Заказчик любит называть это — «ТЗ»), которую он прислал вам на момент начала работ по аналитике.
Изучение существующей документации
Данная методика может быть использована при наличии в организации документации, которая может помочь в определении потребностей Заказчика. Примеры документации включают в себя: регламенты,
описания процессов, структура организации, спецификации продукта, различные процедуры, стандарты и инструкции, шаблоны документов и т.д.
Выявленные требования являются основой для дальнейшего анализа и должны быть детализированы.
Данная методика применима, например, при автоматизации устоявшихся в организации регламентированных бизнес процессов.
Повторное использование спецификации
Повторно использовать спецификации можно в том случае, если есть уже завершенные один или несколько подобных проектов.
Техническое задание, подготовленное на предыдущем проекте может быть использовано для другого проекта с целью сократить продолжительность сбора, анализа и разработки требований, что позволит быстрее начать разработку.
Например, ТЗ для интернет магазинов похожи друг на друга и содержат одинаковые требования.
В большинстве случаев только часть документации актуальна для нового проекта, поэтому потребуется тщательная проверка требований на соответствие текущим целям и задачам Заказчика.
Представитель заказчика в компании разработчика
Один из наиболее эффективных методов сбора требований, поскольку позволяет получать от представителя Заказчика своевременную оценку прогресса, корректности реализации, в короткие сроки получать обратную связь (фидбек) и дополнительную информацию для корректировки и разработки требований.
Метод часто применяется для сбора и управления требованиями при итерационной разработке, позволяет оперативно собирать, согласовывать и дорабатывать требования.
В дополнение можно сказать, что наличие представителя заказчика в компании разработчика является одним из главных правил Agile.
Работа «в поле»
Работа «в поле» состоит из наблюдения за деятельностью и процессами будущих пользователей системы, и в определении требований, основанных на этом наблюдении. Если говорить проще, то это наблюдение за тем, как работают пользователи, и документирование процесса, задач и результатов их деятельности.
Метод позволяет избежать проблем, связанных с трудностями стейкхолдеров в описании и выражении своих потребностей. В некоторых случаях процесс наблюдения может сопровождаться «интервьюированием» пользователей для уточнения особенностей и деталей их работы и задач. В процессе наблюдения можно так же выявить пути оптимизации бизнес процессов Заказчика.
Обучение
Обучение — это процесс, в котором Заказчик или любой другой человек из организации Заказчика, знающий процесс, обучает аналитика по принципу учитель — ученик.
Метод полезен, когда процессы и деятельность сотрудников Заказчика трудно описать с помощью других методов или Заказчик не может предоставить адекватное описание требований.
Обучение позволяет лучше понять сложные бизнес-процессы, а также преодолеть трудности, связанные с нехваткой абстрактного мышления и самовыражения у будущих пользователей системы.
Мозговой штурм
Мозговой штурм — наиболее часто используемый метод получения требований, которые связанны с новыми или плохо изученными направлениями деятельности организации Заказчика или функциями системы.
Он позволяет собрать множество идей от различных заинтересованных лиц (стейкхолдеров) в кратчайшие сроки и практически бесплатно.
Во время мозгового штурма участники «накидывают» любые идеи, касающиеся решения данной проблемы.
С помощью этой методики можно проработать несколько различных вариантов решения заданной проблемы, а также разрешить конфликты требований.
Совещание
Совещание — встреча, ориентированная на обсуждение конкретных вопросов, которые были определены и озвучены участникам заранее.
На такие встречи привлекаются люди, которые придерживаются различных точек зрения по текущей проблеме и могут помочь описать требования, основываясь на взглядах с разных сторон. В процессе совещания уточняется общий список требований, выявляются скрытые требования и решаются конфликты требований.
Совещания являются одной из ключевых практик в Agile, т.к. в них участвуют все стороны, заинтересованные в развитии проекта и решении проблемы.
Use case
Use cases или варианты использования позволяют собрать и сформировать функциональные требования от лица участников Диаграммы вариантов использования определяют границы решения и показывают связи с внешними системами и участниками.
Метод позволяет детализировать требования с точки зрения пользователей, а также помогает уточнить и систематизировать функционал, который требуется реализовать.
Эпилог
Комбинирование методик позволяет повысить эффективность сбора требований, а так же избежать их «потери».
При сборе требований необходимо помнить, что важны не только функциональные требования (ЧТО делает система), но и нефункциональные (КАК система это делает).
Тщательно собранные требования минимизируют риски проекта, т.к. позволяют сформировать четкий и понятный базис для разработки системы.
Информация для статьи взята из учебного пособия по подготовке к сертификации REQB Certified Professional for Requirements Engineering (Базовый уровень).
Управление требованиями
Проблема
Кроме того, существуют трудности в понимании между заказчиком и программистами, а еще – в изменчивости ПО (требования имеют тенденцию меняться в ходе разработки).
В итоге, далеко не очевидно, что та система, которую хочет заказчик, вообще может быть сделана. Трудно найти черную кошку в темной комнате, особенно если ее там нет. Или то, как поняли и воплотили задачу разработчики, окажется удобным, востребованным на рынке.
Ошибки и разночтения, которые возникают при выявлении требований к системе, оказываются одними из самых дорогих. Требования – это то исходное понимание задачи разработчиками, которое является основой всей разработки.
Теперь чуть подробнее об изменчивости ПО и ее причинах.
Нечего и говорить, что изменчивость требований по ходу разработки очень болезненно сказывается на продукте. Авторы сталкивались, например, с такой ситуацией, что еще не созданную систему отдел продаж начинает активно продавать, в силу чего поступает огромный поток дополнительных требований. Все их реализовать в полном объеме не удается, в итоге система оказывается набором демо-функциональности….
Виды и свойства требований
Разделим требования на две большие группы – функциональные и нефункциональные.
Функциональные требования являются детальным описанием поведения и сервисов системы, ее функционала. Они определяют то, что система должна уметь делать.
Сформулируем ряд важных свойств требований.
Варианты формализации требований
Итак, формализация требований в проекте может быть очень разной – это зависит от его величины, принятого процесса разработки, используемых инструментальных средств, а также тех задач, которые решают формализованные требования. Более того, может существовать параллельно несколько формализаций, решающих различные задачи. Рассмотрим варианты.
Итак, каждый способ представления требований должен отвечать на следующие вопросы: кто потребитель, пользователь этого представления, как именно, с какой целью это представление используется.
Некоторые ошибки при документировании требований. Перечислим ряд ошибок, встречающихся при составлении технических заданий и иных документов с требованиями.
Цикл работы с требованиями
В своде знаний по программной инженерии SWEBOK определяются следующие виды деятельности при работе с требованиями.
Варианты формализации требований
Требования- некая абстракция, в реальной практике они всегда существуют в виде какого-то представления: документов, моделей, формальной спецификации, списка и т.д. Требования важны т.к. они оседают в виде понимания нужд заказчика создаваемой системы, поскольку в программном проекте много различных аспектов, видов деятельности и фаз разработки, то это понимание может принимать очень разные представления. Каждое представление требований выполняет определенную задачу, фиксация между различными группами соглашений и используется для оперативного управления проектом или используется для верификации и модельно ориентированного тестирования.
Таким образом формализация требований в проекте может быть очень разной это зависит от его величины, принятого процесса разработки, используемых инструментальных средств, а также тех задач, которые решают формализованные требования. Может существовать параллельно несколько формализаций решающие различные задачи, например:
1. Неформальная постановка требований в переписке по электронной почте хорошо работает в небольших проектах при вовлеченности заказчика в разработку, однако электронные письма оказываются важными документами (уметь вести деловую переписку, подводить итоги, хранить важные письма и пользоваться ими при разногласии)
2. Требования в виде документа- описание предметной области и ее свойств, составление технического задания, функциональная спецификация для разработчиков.
3. Требования в виде графа с зависимостями в одном из средств поддержки требований. Такое представление удобно при частом изменении требований, отслеживании выполнения, при организации привязки к требованиям: людей, задач, теста, кода. Важно, чтобы была возможность легко создавать такие графы из текстовых документов и наоборот. Определение кратчайшего пути и есть понятие графа.
4. Формальная модель требований для верификации модельно ориентированного тестирования и т.д.
Каждый способ представления требований должен отвечать на следующие вопросы: кто потребитель, пользователь этого представления и с какой целью это представление используется.
Перечислим ряд ошибок, встречающихся при составлении технического задания и иных документов с требованиями:
1. Описание возможных решений вместо требований
2. Нечеткие требования, которые не допускают однозначную проверку, а также имеет оттенок советов, обсуждений, рекомендаций
3. Игнорирование аудитории для которой предназначено представление требований
4. Пропуск важных аспектов связанных с нефункциональными требованиями (например срок готовности смежных подсистем с которыми взаимодействуют данные, окружение подсистем и т.д.). Типичной проблемой при создании программно-аппаратных систем, когда аппаратура не поспевает вовремя и ПО невозможно оттестировать.
Цикл работы с требованиями
В своде знаний по программной инженерии (SWEDOK) определяются следующие виды деятельности при работе с требованиями:
1. Выделение требований- целенаправленная на выявление всех возможных источников требований и ограничений на работу системы и извлечение требований из этих источников.
2. Анализ требований, целью которого является обнаружение и устранение противоречий и неоднозначности в требованиях, их уточнение и систематизация.
3. Описание требований- в результате этой деятельности требования должны быть оформлены в виде структурного набора документов и моделей, которые могут: периодически анализироваться, оцениваться с разных позиций и в итоге должен быть утвержден как официальная формулировка требований к системе
4. Валидация требований- решает задачу оценки принятности требований и их характеристик, на основе которых будут разработаны ПО, в силу непротиворечивости и полноты.
Файл- поименованная часть жестоко диска размеченная для хранения файла
Чтобы распечатать файл, скачайте его (в формате Word).
что есть
к программному обеспечению
с помощью
Назначение формализации требований
Что есть формализация требований?
Варианты формализации требований
Неформальная постановка требований
Данный метод хорош в случаях:
Важно вовремя понять, когда такой способ перестает работать и необходимы формальные подходы.
Формализация требований с помощью use-case диаграмм UML
ФОРМАЛИЗАЦИЯ ТРЕБОВАНИЙ С ПОМОЩЬЮ USE-CASE ДИАГРАММ UML
Формальная модель требований
В данном случае строится модель, описывающая некоторые аспекты (чаще функциональные) системы.
Существует процесс построения формального описания требований к программной системе FOREST (FOrmal REquirements Specification and Testing), в который включено использование формальной модели требований в качестве основы для построения тестов.
ФОРМАЛЬНАЯ МОДЕЛЬ ТРЕБОВАНИЙ
FOREST предоста вляет возможность автоматизации выполнения ряда сложных и трудоемких задач ра зработки, таких как:
ФОРМАЛИЗАЦИЯ требований в виде документов
По SWEBOK для описания комплексных проектов в части требований используется три основных документа:
Формализация требований с помощью технического задания (ТЗ) и технического проекта (ТП)
что есть Техническое задание?
Техническое задание — исходный документ на проектирование технического объекта, устанавливающий:
В ТЗ описывается, ЧТО нужно заказчику, в отличие от по следующей проектной документации, в которой говорится, КАК этого достичь.
что есть технический проект?
Технический проект – это документ (или их совокупность), который предназначен для технической реализации требований, сформулированных в Техническом задании, содержит окончательные проектные решения по изделию (автоматизированной системе).
Разрабатывается архитектором системы или группой программистов во главе с ним.
КЕМ пишется тЗ?
Сотрудник должен иметь ряд навыков и знаний, таких как опыт программирования и построения баз данных, хорошее знание систем, с которыми придется иметь дело.
Однако чем больше проект, тем и больше людей работает над Техническим заданием.
А нужно ли техническое задание?
В Scrum, Agile и прочих технологиях говорится: «минимум бумаг, ближе к Заказчику, больше конкретики и быстрее к результату». Но формализацию требований никто не отменял и там это явно сказано.
Хорошее техническое задание — важнейшая составляющая успеха в проекте, оно является основой порядка, грамотное ТЗ — это 50 % успеха в решении задачи, однако это не панацея.
Стандарты написания и оформления ТЗ и ТП
Понятие «Хорошего ТЗ»
Для менеджера ТЗ хорошее тогда, когда по нему удается сделать проект с первого захода. Когда время, ресурсы и результат оправдали ожидания.
Чтобы при сдаче избежать разработчику — неприятных вопросов, а заказчику — неожиданных трат, нужно заранее определить требования. Заказчику нужно понимать что он будет принимать у разработчиков.
В отличном ТЗ определен порядок тестирования и приемки результата, причем не скопирован из ГОСТа, а действительно продуман и принят сторонами.
дл я кого пишется ТЗ?
У ТЗ два основных читателя:
и один редкий — тот, кто будет разбираться в проблемах между первыми двумя.
Типичные реакции типичного клиента на ТЗ в 50-70 страниц:
Ведение листа изменений. Там могут появиться и отклонения от требований, и их придется согласовывать.
требования В ТЗ?
При написании ТЗ необходимо :
какие требования писать в тз?
Здесь нам поможет ГОСТ. Например:
Структура ТЗ и обязательные пункты
ГОСТ рекомендует следующие разделы: