Чем отличаются бизнес требования от функциональных

Документация и требования

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

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

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

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

1. Единичность — требование описывает одну и только одну вещь.
2. Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.
3. Последовательность — требование не противоречит другим требованиям и полностью соответствует документации.
4. Атомарность — требование нельзя разделить на более мелкие.
5. Отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано.
6. Актуальность — требование не стало устаревшим с течением времени.
7. Выполнимость — требование может быть реализовано в рамках проекта.
8. Недвусмысленность — требование определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объекты и факты, а не субъективные мнения. Возможна одна и только одна его интерпретация. Определение не содержит нечетких фраз, использование отрицательных и составных утверждений запрещено.
9. Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.
10. Проверяемость — реализованность требования может быть проверена.

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

1. Что ПО должно делать. Пример — Позволять клиенту оформить заказы и обеспечить их доставку;
2. Насколько оно должно быть надежно. Пример — Работать 7 дней в неделю и 24 часа в сутки;
3. Насколько им должно быть удобно пользоваться. Пример — Покупатель должен легко находить нужный ему товар;
4. Насколько оно должно быть эффективно. Пример — Поддерживать обслуживание до 10000 запросов в секунду;
5. Насколько удобно должно быть его сопровождение. Пример — Добавление в систему нового вида запросов не должно требовать более 3 человеко-дней;
6. Насколько оно должно быть переносимо и заменяемо. Пример — ПО должно работать на операционных системах Linux, Windows XP и Mc OS X;

Уровни требований (по К.Вигерсу)

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

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

1. Функциональные требования описывают, что делает система, это требования к первой составляющей качества — функциональности. Эти требования обычно ориентированы на действия (Когда пользователь нажимает кнопку «Обработать заказ», система сохраняет данные заказа в БД и определяет его статус как «В очереди на обработку»).
При определении функциональных требований следует искать золотую середину между слишком конкретизированной формулировкой требования и слишком общей и неоднозначной. Требования должны оставаться понятными заказчикам и стать более понятны разработчикам.
К функциональным требованиям относят:
1.1. Бизнес-требования. Что система должна делать с точки зрения бизнеса. Слово «бизнес» в данном контексте ближе к слову «заказчик». Пример бизнес-требования: промо-сайт, привлекающий внимание определенной аудитории к определенной продукции компании.
1.2. Пользовательские требования – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования. Иначе говоря, пользовательские требования — это что может сделать пользователь: зарегистрироваться, посмотреть определенную информацию, пересчитать данные по определенному алгоритму и прочее.
1.3. Функциональные требования – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований. Другими словами, что будут делать разработчики, чтобы выполнить пользовательские требования.
1.4. В группу функциональных требований относят и Системные требования. Эти характеристики могут описывать требования как к аппаратному обеспечению (тип и частота процессора, объём оперативной памяти, объём жесткого диска), так и к программному окружению (операционная система, наличие установленных системных компонентов и сервисов и т. п.).

Обычно такие требования составляются производителем или автором ПО. Например, для игры это могут быть требования такого типа: видеокарта — объём памяти от 64 Мб, совместимость сDirectX 9.0b и новейшие драйвера. Для сайта: ОС — Windows не ниже XP, браузеры IE не ниже 7.0 и так далее.

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

2. Нефункциональные требования, соответственно, регламентируют внутренние и внешние условия или атрибуты функционирования системы. К. Вигерс [2] выделяет следующие основные группы нефункциональных требований:
2.1. Бизнес-правила. Они определяют почему система работать должна именно так, как написано. Это могут быть ссылки на законодательство, внутренние правила заказчика и прочие причины. Часто упускают этот раздел и получается, что некоторые системные решения выглядят нетипичным и совсем неочевидными.

Например, многие табачные компании и компании, производящие алкоголь требуют постоянного доказательства того, что промо-сайтами пользуются люди, достигшие определенного возраста. Это бизнес-правило (подтверждение возраста) возникает по требованию этических комитетов заказчика, хотя и несколько противоречит маркетинговым целям и требованиям по usability.
2.2. Внешние интерфейсы. Это не только интерфейсы пользователя, но и протоколы взаимодействия с другими системами. Например, часто сайты связаны с CRM системами. Особенности протокола взаимодействия «сайт-CRM» также относятся к нефункциональным требованиям.
2.3. Атрибуты качества. Атрибуты касаются вопросов прозрачности взаимодействия с другими системами, целостности, устойчивости и т.п. К таким характеристикам относятся:
— легкость и простота использования (usability)
— производительность (performance)
— удобство эксплуатации и технического обслуживания (maintainability)
— надежность и устойчивость к сбоям (reliability)
— взаимодействия системы с внешним миром (interfaces)
— расширяемость (scalability)
— требования к пользовательским и программным интерфейсам (user and software interface).
2.4. Ограничения – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных и т.д.). Ограничения часто основываются на бизнес-правилах.

Выявление требований

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

Стадию выявления и представления требований условно можно разделить на 4 этапа:
1. Выявление требований сбор информации.
2. Первичный анализ требований.
3. Документация требований.
4. Проверка требований.

Данные этапы будут выполняться, чередуясь и периодически повторяясь. Этот итерационный процесс и есть процедура выявления требований.

Источники требований

  1. Заинтересованные лица – как правило, являются первым и основным источником требований.Заинтересованные лица – как правило, являются первым и основным источником требований;
  2. Документация – все документы, присутствующие в компании или относящиеся к правовой системе страныбизнеса, являются источником требований, который чаще всего определяет те или иные ограничения проекта;
  3. Сегмент рынкабизнеса – конкурентные системы будущего продукта являются незаменимым источником требований. Благодаря изучению систем-аналогов можно существенно уменьшить время на выявление требований. Также незаменимым источником являются различные маркетинговые материалы;
  4. Бизнес заказчика – специфика бизнеса заказчика, наблюдение за работой будущих пользователей, бизнес-процессы организации – все так или иначе создает образ будущей системы и позволяет точнее определить потребности заказчика, а также проблемы, которая будущая система призвана решить.

Способы выявления требований

  1. Опрос – подразумевает опрос существующих и потенциальных пользователей продукта (например, интервью, анкеты);
  2. Наблюдение – подразумевается наблюдение за работой пользователей;
  3. Изучение правил работы пользователей по существующим регламентам/законодательству, а также изучение существующих документов, описывающих бизнес клиента или существующего продукта;
  4. Анализ истории использования продукта по его техническим журналам;
  5. Изучение существующих продуктов конкурентов на рынке;
  6. Обсуждения и мозговые штурмы с пользователями и экспертами;
  7. Маркетинговые исследования;
  8. Моделирование – может включать в себя как моделирование существующих бизнес-процессов, так и верхнеуровневое моделирование будущей системы.

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

Стандарты

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

Функции стандартов

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

Уровни стандартов

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

  • Международная стандартизация. Органом по стандартизации является ИСО (ISO). Нормативным документом ИСО являются стандарты ИСО.
  • Межгосударственная стандартизация. Охватывает ряд независимых государств (СНГ, ЕЭС и др.). Нормативным документом стран СНГ является межгосударственный стандарт.
  • Национальная стандартизация — это стандартизация в пределах одного государства (к примеру стандарты ДСТУ или ГОСТы).
  • Правила, нормы и рекомендации в определенной области — действуют в границах определенных сфер деятельности (к примеру IEEE)
  • Стандарты организаций — сюда входят стандарты предприятий, стандарты обществ и т. п.

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

Продуктная документация (product documentation)

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

  • План продукта (Product Management Plan)
  • Документ бизнес-требований (Business Requirements Document)
  • Маркетинговая документация (Market Requirements Document)
  • Документ требований к программному продукту (Product Requirements Document) или спецификация требований (Software Requirements Specification);
  • Спецификация функциональных требований (Functional Specifications Document);
  • Техническое задание (Terms of Reference TOR);
  • Mind Maps, Макеты, Прототипы;
  • Use Cases и User Story;
  • Дизайн (Graphic Design, Web Design, Game design).

Проектная документация

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

  • План проекта (Project Management Plan)
  • Пользовательская и сопроводительная документация (User and Accompanying Documentation)

Источник: qa-guide.ru

Что такое функциональные требования ? Четкая постановка задач разработчику

Получите все наши материалы — бесплатно

Тренинги, Курсы, Обучение — Agile, Scrum, OKR

Тренинги, Курсы, Обучение — Agile, Scrum, OKR

Тренинги, Курсы, Обучение — Agile, Scrum, OKR

Что такое функциональные требования?

Из чего состоят функциональные требования?

User story — ожидание от разработчика; Use cases — сценарии использования фичи; Wireframes — средство визуализации идей.

Зачем нужны функциональные требования?

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

Получите наш и Miro — бесплатно

Что такое функциональные требования?

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

Как избежать всего этого хаоса?

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

Из чего состоят функциональные требования?

Из чего состоят функциональные требования?

Существует три кита, на которых стоят функциональные требования:

  • User story — ожидание от разработчика;
  • Use cases — сценарии использования фичи;
  • Wireframes — средство визуализации идей.

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

Шаблон выглядит таким образом:

As a/an , I want to , so that , to do .

Для удобства постановки задачи можно использовать различные программы — Trello, Google Docs (таблицы) и т.д. Благодаря такой системе можно легко наладить структуру коммуникации и вовремя оставлять комментарии на ту или иную задачу. Пример перед вами:

Наглядно видно, как процесс постановки задачи плавно перетекает в её выполнение.

После User story переходим к Use cases.

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

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

Wireframes — иначе говоря, образ дизайна низкой точности. Как правило, он четко показывает три составляющих:

  • основную группу контента;
  • структуру информации;
  • описание и базовую визуализацию взаимодействия между интерфейсом и пользователем.

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

Зачем нужны функциональные требования?

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

Что необходимо учитывать в функциональных требованиях?

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

Отличия функциональных требований от бизнес-требований

Отличия функциональных требований от бизнес–требований

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

А как вы подходите к постановке задач разработчикам? Опираетесь только на интуицию или же применяете четкую структуру? Конечно же, мы понимаем, что невозможно довести постановку задач до идеала. Но приблизить её к совершенству вполне в силах каждый продакт–менеджер, если будет применять подход, о котором мы говорили выше.

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

Какие бывают требования?

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

Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Мне нравится записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами увеличения объема работ.

Требования пользователей (user requirements) описывают цели и задачи, которые пользователям даст система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.

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

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

Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
* легкость и простота использования
* легкость перемещения
* целостность
* эффективность и устойчивость к сбоям
* внешние взаимодействия между системой и внешним миром
* ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта

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

Источник: www.uml2.ru

Все для аналитиков

Это определение неидеально. Потому что есть требования, которые пользователь явно не высказывает, например, работа системы в режиме 24/7, или пользователь высказал какое-нибудь пожелание, но оно не было реализовано. Особый случай: требование высказано в устной форме. На мой взгляд, если требование не зафиксировано в письменном виде, то оно не существует.

Требования можно разделить на две большие группы:

  • функциональные требования
  • нефункциональные требования

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

Функциональные требования — что система должна делать.
К функциональным требованиям относят:

  • Бизнес-требования. Что система система должна делать с точки зрения бизнеса. Слово «бизнес» в данном контексте ближе к слову «заказчик». Пример бизнес-требования: промо-сайт, привлекающий внимание определенной аудитории к определенной продукции компании.
  • Пользовательские требования – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases). Иначе говоря, пользовательские требования — это что может сделать пользователь: зарегистрироваться, посмотреть определенную информацию, пересчитать данные по определенному алгоритму и прочее.
  • Функциональные требования – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований. Другими словами, что будут делать разработчики, чтобы выполнить пользовательские требования.

В группу функциональных требований относят и системные требования. Эти характеристики могут описывать требования как к аппаратному обеспечению (тип и частота процессора, объём оперативной памяти, объём жесткого диска), так и к программному окружению (операционная система, наличие установленных системных компонентов и сервисов и т. п.). Обычно такие требования составляются производителем или автором ПО. Например, для игры это могут быть требования такого типа: видеокарта — объём памяти от 64 Мб, совместимость сDirectX 9.0b и новейшие драйвера. Для сайта: ОС — Windows не ниже XP, браузеры IE не ниже 7.0 и так далее.

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

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

  • Бизнес-правила. Они определяют почему система работать должна именно так, как написано. Это могут быть ссылки на законодательство, внутренние правила заказчика и прочие причины. Часто упускают этот раздел и получается, что некоторые системные решения выглядят нетипичным и совсем неочевидными. Например, многие табачные компании и компании, производящие алкоголь требуют постоянного доказательства того, что промо-сайтами пользуются люди, достигшие определенного возраста. Это бизнес-правило (подтверждение возраста) возникает по требованию этических комитетов заказчика, хотя и несколько противоречит маркетинговым целям и требованиям по usability.
  • Внешние интерфейсы. Это не только интерфейсы пользователя, но и протоколы взаимодействия с другими системами. Например, часто сайты связаны с CRM системами. Особенности протокола взаимодействия «сайт-CRM» также относятся к нефункциональным требованиям.
  • Атрибуты качества. Атрибуты касаются вопросов прозрачности взаимодействия с другими системами, целостности, устойчивости и т.п. К таким характеристикам относятся:
  • легкость и простота использования (usability)
  • производительность (performance)
  • удобство эксплуатации и технического обслуживания (maintainability)
  • надежность и устойчивость к сбоям (reliability)
  • взаимодействия системы с внешним миром (interfaces)
  • расширяемость (scalability)
  • требования к пользовательским и программным интерфейсам (user and software interface).
  • Ограничения – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, . ). Ограничения часто основываются на бизнес-правилах.

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

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

Все вышесказанное относится только к дисциплине «Управление требованиями» в рамках методологии RUP. В рамках ГОСТ и определения требований другие и сами требования разбиваются на совершенно другие группы.

Источник: foranalysts.blogspot.com

Рейтинг
( Пока оценок нет )
Загрузка ...
Бизнес для женщин