Бизнес требования к программному обеспечению это

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

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

Виды требований по уровням

• Бизнес-требования — определяют назначение ПО, описываются в документе о видении (vision) и границах проекта (scope).
• Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе. Пользовательские требования могут выражаться в виде фраз утверждений, в виде способов применения (use case), пользовательских историй (user story), сценариев взаимодействия (scenario).
• Функциональные требования — определяют «как» реализовать продукт. Описывается в системной спецификации (system requirement specification, SRS).

Виды требований по характеру

• Функциональные характер — требования к поведению системы

• Бизнес-требования
• Пользовательские требования
• Функциональные требования

• Бизнес-правила — определяют ограничения, проистекающие из предметной области и свойств автоматизируемого объекта (предприятия)
• Системные требования и ограничения — определения элементарных операций, которые должна иметь система, а также различных условий, которым она может удовлетворять. К системным ограничениям относятся ограничения на программные интерфейсы, требования к атрибутам качества, требования к применяемому оборудованию и ПО.
• Атрибуты качества
• Внешние системы и интерфейсы
• Ограничения

Типы документов требований

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

Что прочитать для прохождения интервью на Бизнес Аналитика?

• Концепция программы (Vision)
• Требования к ПО

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

За создание требований к ПО чаще всего в российской практике отвечает Системный аналитик, иногда — Бизнес-аналитик.

Для графических моделей требований исторически использовались диаграммы: ER (IDEF1FX), IDEF0, IDEF3, DFD, UML, OCL, SysML, ARIS (eEPC, VAD).

См.также

• Бизнес-моделирование
• Проектирование программного обеспечения

Литература

• Карл И. Вигерс: Разработка требований к программному обеспечению — Русская Редакция, 2004, ISBN 5-7502-0240-2.

Внешние ссылки

• Краткий курс в управление требованиями (+ аудио) (рус.)

Источник: www.sbup.com

2. Виды требований к программному обеспечению. Часть 1. (Курс бизнес-аналитик с нуля)

ТРЕБОВАНИЯ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

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

Определение требований разных уровней:

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

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

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

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

ФОРМИРОВАНИЕ И АНАЛИЗ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

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

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

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

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

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

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

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

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

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

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

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:

Источник: studopedia.ru

Лекция ТРПО. ТРПО 1 лекция (для ИСов). Тема Понятия требований, классификация, уровни требований. Методологии и стандарты, регламентирующие работу с требованиями

Единственный в мире Музей Смайликов

Самая яркая достопримечательность Крыма

Скачать 29.28 Kb.

Технология разработки программного обеспечения.

Тема 1. Понятия требований, классификация, уровни требований. Методологии и стандарты, регламентирующие работу с требованиями.

Функциональные, нефункциональные требования и характеристики продукта. UseCase. Классификация RUP. Разработки IEEE, ГОСТ.

Основные этапы разработки программного обеспечения:

Анализ — определение процесса разработки ПО

Проектирование — управление проектом разработки

Конструирование — описание целевого программного продукта

Программирование — проектирование продукта

Тестирование — тестирование частей программного продукта

Отладка — интеграция частей и тестирование продукта в целом

Развертывание — сопровождение продукта, обучение пользователей

Определение понятия «требования»

Л.Новиков в русской редакции нотации RUP [2.9] приводит следующее определение: «Требование — это условие или возможность, которой должна соответствовать система».

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

IEC (International Electrotechnical Commission) — международная электротехническая комиссия (МЭК), http://www.iec.ch. МЭК – некоммерческая организация, наряду с IEEE (http://www.ieee.org)- признанный мировой лидер в области создания международных стандартов в сфере электрики, электронники и смежных технологий, в том числе — в области информационных технологий. Под эгидой организации сотрудничают более 10 000 специалистов. Некоторые из разработанных стандартов созданы совместно с ISO.

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

Требования нужны в частности для того, чтобы Разработчик мог определить и согласовать с Заказчиком временные и финансовые перспективы проекта автоматизации. Поэтому значительная часть требований должна быть собрана и обработана на ранних этапах создания АИС. Однако собрать на ранних стадиях все данные, необходимые для реализации АИС, удается только в исключительных случаях. На практике процесс сбора, анализа и обработки растянут во времени на протяжении всего жизненного цикла АИС, зачастую нетривиален и содержит множество подводных камней; подробнее о процессе — в лекциях 4 — 8.

Классификация требований

Существует значительное количество различных методов классификации требований [2.2-2.7], наиболее существенные из которых будут рассмотрены в лекции.

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

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

Требования к проекту (как к рабочему процессу производства программного продукта!). Вопросы формулирования требований к проекту, т.е. к тому, как Разработчик будет выполнять работы по созданию целевой системы, казалось бы, не лежат в компетенции Заказчика.

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

1. регламентация процесса Заказчиком позволяет снизить его риски;
2. мероприятия Заказчика по регламентации процесса приводят к дополнительным накладным расходам. Требуется найти разумный компромисс между степенью контроля рисков и величиной расходов.

1. Разработчик представляет Заказчику согласованный план работ c детализацией (WorkBreakdownStructure — WBS) с точностью до конкретных исполнителей.
2. Разработчик осуществляет ежедневные сборки, регрессионное тестирование компонентов разрабатываемого продукта и тестирование продукта в целом.
3. Все управленческие и проектные артефакты, исходные коды и тестовые примеры размещаются в режиме online в интегрированной среде разработки Rational ClearCase с возможностью для Заказчика осуществления online-мониторинга на базе web-технологий.

Уровни требований

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

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

• На верхнем уровне представлены так называемые бизнес-требования (business requirements). Примеры бизнес-требования: система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза. Бизнес-требования обычно формулируются топ-менеджерами, либо акционерами предприятия.
• Следующий уровень — уровень требований пользователей (user requirements). Пример требования пользователя: система должна представлять диалоговые средства для ввода исчерпывающей информации о заказе, последующей фиксации информации в базе данных и маршрутизации информации о заказе к сотруднику, отвечающему за его планирование и исполнение. Требования пользователей часто бывают плохо структурированными, дублирующимися, противоречивыми. Поэтому для создания системы важен третий уровень, в котором осуществляется формализация требований.
• Третий уровень — функциональный (functional requirements). Пример функциональных требований (или просто функций) по работе с электронным заказом: заказ может быть создан, отредактирован, удален и перемещен с участка на участок.

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

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

Системные требования и требования к программному обеспечению

Существуют различные трактовки понятия «Системные требования» (system requirements).

К. Вигерс формулирует данный термин, как «высокоуровневые требования к продукту, которые содержат многие подсистемы, то есть системе» [2.2]. При этом под системой понимается программная, программно-аппаратная, либо человеко-машинная система. Данная система является сложной, структурированной системой и системные требования являются подмножеством функциональных требований к продукту. В данное подмножество целесообразно относить наиболее важные, существенные требования, которые относятся в целом к системе и не содержат избыточной детализации.

INCOSE (International Council on Systems Engineering) дает более детальное определение системы: «комбинация взаимодействующих элементов, созданная для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы». Таким образом, происходит разделение между системными требованиями, как обобщающему понятию и требованиями к программному обеспечению, как выделенному подмножеству системных требований, направленных исключительно на программные компоненты системы. Этот же подход прослеживается в стандарте ГОСТ Р ИСО/МЭК 12207/99 [2.8]: работы, связанные с системой в целом и с программным обеспечением выделяются в отдельные группы в целях удобства оперирования.

INCOSE (International Council on Systems Engineering) — Международный совет по системной инженерии, www.incose.org — некоммерческая организация, ставящая своей целью развитие системной инженерии и профессиональный рост системных инженеров. В настоящее время насчитывает более 8000 членов. Под эгидой INCOSE разработан ряд международных стандартов в области системной инженерии.

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

Функциональные, нефункциональные требования и характеристики продукта

Функциональные требования регламентируют функционирование или поведение системы (behavioral requirements). Функциональные требования отвечают на вопрос «что должна делать система» в тех или иных ситуациях. Функциональные требования определяют основной «фронт работ» Разработчика, и устанавливают цели, задачи и сервисы, предоставляемые системой Заказчику.

Функциональные требования записываются, как правило, при посредстве предписывающих правил: «система должна позволять кладовщику формировать приходные и расходные накладные». Другим способом являются так называемые варианты использования (users cases) — популярный и весьма продуктивный способ представления требований.

Use case — вариант использования, прецедент. Данный термин был введен в обиход программной инженерии шведским учёным Айваром Якобсоном (Ivar Hjalmar Jacobson) и по сей день является одной из наиболее позитивных абстракций в области создания требований к программному обеспечению.

Согласно нотации UML 2.4.1 (http://www.omg.org/spec/UML/2.4.1/), прецеденты являются средством для определения требуемых использований системы. Как правило, они применяются для извлечения требований к системе, то есть, того, что система предполагает делать. Основными понятиями, связанными с вариантами использования являются акторы, прецеденты, и объект.

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

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

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

• Внешние интерфейсы (External Interfaces),
• Атрибуты качества (Quality Attributes),
• Ограничения (Constraints).

• Применимость,
• Надежность,
• Производительность,
• Эксплуатационная пригодность,

Ограничения [2.2] — формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. Выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, . ), которые, в свою очередь, могут относиться, например, к внешним интерфейсам (конец цитаты).

Характеристики продукта. К.Вигерс [2.2] формулирует характеристику, «фичу» (feature), как набор логически связанных функциональных требований, которые обеспечивают возможности пользователя и удовлетворяют бизнес-цели.

Существует и более общий взгляд на данное понятие [2.9]: «features могут быть как относящимися к функциональным, так и к нефункциональным требованиям и могут изменяться от версии к версии продукта».

С.Орлик в [2.6] отмечает, что «с точки зрения инженерии требований, features являются самостоятельным артефактом, который может быть соотнесен как с функциональными требованиями, так и с нефункциональными».

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

Классификация RUP

В спецификациях Rational Unified Process при классификации требований используется модель FURPS+ со ссылкой на стандарт IEEE Std 610.12.1990 [2.1].

• Functionality (Функциональность)
• Usability (Применимость)
• Reliability (Надежность)
• Performance (Производительность)
• Supportability (эксплуатационная пригодность).

• ограничения проекта,
• требования выполнения,
• требования к интерфейсу,
• физические требования,

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

• ограничения проектирования (design);
• ограничения разработки (implementation);
• ограничения на интерфейсы (interface);
• физические ограничения (physical).

Подробно описана в работе Роберта Грейди.

Методологии и стандарты, регламентирующие работу с требованиями

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

• IEEE 1362 «Concept of Operations Document».
• IEEE 1233 «Guide for Developing System Requirements Specifications».
• IEEE Standard 830-1998, «IEEE Recommended Practice for Software Requirements Specifications»
• IEEE Standard Glossary of Software EngineeringTerminology/IEEE Std 610.12-1990
• IEEE Guide to the Software Engineering Body of Knowledge (1) — SWEBOK®, 2004.

• ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания.
• ГОСТ 34.602-89. Информационная технология. Техническое задание на создание автоматизированной системы
• ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.

Источник: topuch.com