Типы требований к по: Анализ требований по Вигерсу (2004). Этапы сбора требований.

Требования к ПО на пальцах / Хабр

Пост про основы разработки требований — без сложных схем, терминов и таблиц, зато с гифками.

Если коротко, то основные этапы разработки требований — это:

1. Зачем нам что-то делать? (нужно больше золота)
2. Что мы будем делать? (все как у людей, но дешевле)
3. Как мы это сделаем? (с блокчейном и датасаентистами, естественно)
4. Когда мы это сделаем? (вчера, а отрефакторим «потом»)

А теперь подробнее.

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

Если после выполнения просьбы получилось что-то не то — это либо накосячил исполнитель,

либо вы некорректно поставили задачу.

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

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

Так что же такое требования и почему важно уметь их разрабатывать?

Итак, обратимся к истокам:

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

С чего же начать разработку требований? В определении спрятана подсказка: начинать нужно с цели — для чего вообще нам что-то делать.

1. Зачем?

Как бы “ASAP!!!!” не требовалось что-то сделать — важно найти время и силы выяснить, зачем же это нужно.

Потому что часто, после выяснения цели, меняется или вовсе устраняется задача.

Например

Заказчик попросит срочно показывать ему все заказы, которые были сделаны в системе. Допустим, мы напряглись и впихнули посреди спринта задачу на отображение всех заказов для администратора. После этого заказчик просит выводить в отдельном окне список всех компаний, чьи заказы он видит. Сделали и это. Потом заказчик просит выводить дополнительно вообще все компании-партнеры. Окей… Через какое-то время мы встречаемся с заказчиком и видим, как он выгружает оба списка в эксель, ВПРит разницу и начинает обзванивать компании, у которых нет заказов, чтобы напомнить им, что нужно делать заказы через нашу систему.

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

Можно воспользоваться методом “Пяти почему” или любым другим. Но обычно люди не сопротивляются: если проявить интерес к их работе — разгадка становится доступной.

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

Например

Процесс заказа материалов считается автоматизированным, если >90% компаний-партнеров делают заказы через систему.

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

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

2. Что?

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

Например

Чтобы сократить процесс согласования счетов, мы можем:

А. Перераспределить задачи между согласующими. В результате несколько человек могут быть исключены из процесса. Суммарное время процесса сократится за счет периодов передачи данных/ожидания/коммуникации при передаче.

Б. Перейти на электронный документооборот — достоверность счетов и данных в них будет подтверждена оператором ЭДО, подтверждение человеком не потребуется.

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

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

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

3. Как?

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

Этот этап — дело техники. И если вы успешно прошли предыдущие два — будет гораздо проще.

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

Например

• Анкета должна содержать файл с фото, так как фото необходимо при оформлении документов — это бизнес-требование. А возможно, и бизнес-правило.
• Из бизнес-требования следует, что у пользователя должна быть возможность прикрепить фото к анкете — это пользовательское требование. То есть требование, описывающее действия пользователя.
• Получается, что система должна иметь функционал прикрепления фото к анкете — это уже функциональное требование, описывающее поведение системы. Или как должна работать система, чтобы выполнять исходное пользовательское требование.
• Будем хранить все фото в формате base64 в отдельной таблице в БД. Это — нефункциональные требования.
• Фото в очень хорошем качестве нам не нужно, а также мы не хотим покупать много памяти для сервера. Поэтому сделаем ограничение на размер загружаемого фото: не более 10Мб.

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

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

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

4. Когда?

В “лесу” ваших требований скорее всего найдется сколько-нибудь взаимоисключающих и сколько-нибудь повторяющихся. Поэтому полезно всю эту красоту документировать и представлять в виде таблиц и диаграмм.

Тут есть много инструментов: например, BPMN для описания бизнес-процессов и UML для создания схем взаимодействий сервисов и компонентов.

Если у вас получается объяснять всем, что и как вы хотите сделать с системой, при помощи салфетки и 3х пятен от кофе — значит вы Джон Уик от аналитики и это потрясающе.

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

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

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

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

Конечно, проблемы будут всегда. Будут переделки, сгоревшие дедлайны и баги. Не всегда будет возможность пройти все этапы и сделать нормальную аналитику, договориться или даже просто поговорить с заказчиком, задокументировать и протрассировать требования. Но в любой ситуации понимание “как должно быть” помогает сделать продукт лучше. Даже если в данный момент вы делаете “как получается” — вы осознаете, что упускаете, и знаете риски. А если вы знаете риски — значит вы можете ими управлять.

Подробнее про требования рекомендую почитать в книге Вигерса и Битти: “Разработка требований к программному обеспечению”. Хоть книга не всегда простая, но очень полезная. Большинство других материалов по теме — пересказ этих истин с той или иной степенью вольности.

Спасибо за внимание и удачного проектирования.

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

01.03.2018 18:48

Текстовая расшифровка третьего видеоурока курса Введение в профессию аналитика.

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

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

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

Самый первый вид требований: бизнес-требования. Что это такое, обобщённо? Описание высокоуровневых целей организации или заказчика, достигаемых посредством разрабатываемой системы.

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

Что дает описание бизнес требований? Описывает бизнес-идею, без реализации которой продукт не будет нужен потребителю. Это описание тех самых проблем и возможностей, для решения или реализации которых создается продукт.

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

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

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

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

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

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

Часто бизнес-требования путают с бизнес-правилами, потому что они начинаются со слова «бизнес». Что понимается под бизнес-правилом? Положение, определяющее или ограничивающее какие-либо стороны бизнеса. Я не буду перечитывать то, что написано у Вигерса, а лучше сразу покажу на примерах, что за этим стоит.

За этим стоят, во-первых, какие-то документы, регламентирующие на уровне законов или отраслевых стандартов (или ещё каких-то стандартов) то, как должен работать наш продукт. Если, например, мы разрабатываем банковскую систему, то там есть огромное количество правил, которые генерируют Центробанки. Если говорить о России, то это наш Центральный Банк, который выпускает различные инструкции, и банковская система должны обязательно им следовать.

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

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

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

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

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

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

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

Следующий вид требований: пользовательские требования.

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

Как я уже сказал, основная масса существующих методов разработки требований относится именно к этому уровню. Use Cases, User Stories, «персоны» и ещё некоторые методы, не так часто используемые. Лучше всего проработанные, концептуально завершенные, они как раз относятся к уровню взаимодействия людей с продуктом. Но это естественно, потому что продукты, в основном, до сих пор создаются для людей.

Здесь может быть очень много разных примеров. Я даже не стал их детализировать.

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

Мы можем описать требования в виде набора user stories, например, для интернет-магазина. Если я хочу выполнить покупку на сайте интернет-магазина, то мне нужно будет реализовать user stories для сравнения товаров, для добавления в корзину, для управления корзиной и оформления заказа, для онлайн-оплаты. Каждая user story имеет определенный формат, который не представлен на этом слайде.

Каждая user story — это такой единичный кусок, unit при разработке требований, обладающий своими собственными характеристиками, и разработанный по определённому методу.

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

Атрибуты качества. Более детально мы атрибуты качества рассмотрим ещё сегодня на этом вебинаре.

Что за этим стоит? Свойство продукта, выраженное через описание характеристик, важных для пользователей или разработчиков. Тоже несколько суконное определение.

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

Мы сегодня эти точки зрения рассмотрим на этом вебинаре, а пока три примера, которые разные точки зрения представляют.

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

Например, время загрузки главной страницы и карточки товара не должно превышать 3 секунд при нагрузке до 20 посетителей в минуту. Это требование отражает атрибуты качества «производительность» и «надёжность». Производительность — это время загрузки страницы, а надёжность — это какую нагрузку должен держать сайт.

База данных сайта должна устанавливаться на сервера mysql или MS SQL Server или Oracle без необходимости внесения изменений в установочные скрипты. Это, опять же, конкретное представление требования, которое отражает такой атрибут качества как «переносимость». Мы можем наш разработанный сайт устанавливать в разном окружении, и при этом должны быть реализованы эти требования, чтобы мы могли использовать разные системы баз данных.

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

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

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

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

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

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

Или похожий пример: сайт должен устанавливаться на определенную версию операционной системы.

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

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

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

Ну например, что это может быть.

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

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

Ещё пример: протокол взаимодействия с сервером транспортной компании для резервирования и оплаты билетов. Уже приведенный пример для авиакомпаний: единая точка для возможности сравнить и купить билеты разных авиакомпаний. Для такого сервиса очень важными тоже являются внешние интерфейсы взаимодействия с разными внешними сервисами резервирования и оплаты билетов.

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

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

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

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

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

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

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

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

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

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

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

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

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

Предыдущий урок: Уровни требований к программному продукту

Следующий урок: Функциональная и нефункциональная стороны программного продукта

Нефункциональные требования к программному обеспечению. Часть 1 / Хабр

Введение

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

В этой статье я расскажу о следующем:

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

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

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

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

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

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

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

Примеры бизнес-правил: «При отгрузке заказа менеджер должен запросить у бухгалтера товарно-транспортную накладную и счет-фактуру», «Если оплата по счету не поступила в течение 15 дней, заказ считается отменённым».

• Внешние интерфейсы — описание аспектов взаимодействия с другими системами и операционной средой. К ним относятся требования к API продукта или системы, а также требования к API других систем, с которыми осуществляется интеграция.

Примеры внешних интерфейсов: «Обеспечить запись в журнал операционной системы следующих событий: сообщения о запуске и остановке сервиса XX»; «Обеспечить запись в журнал параметров модулей программы: сканера, ядра, антивирусных баз (информация должна заноситься в журнал при запуске программы и при обновлении модулей)»

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

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

• Юридические требования — требования к лицензированию, патентной чистоте, etc.

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

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

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

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

Нефункциональные требования: работа над определением

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

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

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

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

1. Система получает оповещение о событии, инициирующем рассылку уведомлений.

2. Система осуществляет рассылку оповещений по адресам из списка рассылки X, используя шаблон Y. Для рассылки сообщений используется сервис Z.

3. В случае невозможности завершения рассылки, система предпринимает повторные попытку рассылки.

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

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

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

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

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

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

Ниже приведены основные характеристики качественных требований.

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

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

Атрибуты качества

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

Характеристики качества и модель качества ПО

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

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

Среди них можно выделить следующие:

Также можно назвать еще два стандарта, которые могут послужить источником для определения вашей модели качества:

• 1061-1998 IEEE Standard for Software Quality Metrics Methodology
• ISO 8402:1994 Quality management and quality assurance

Характеристики качества с точки зрения влияния на архитектуру системы

Все атрибуты качества с точки зрения архитектуры системы можно разделить на две большие группы: первая группа (runtime) – это атрибуты, относящиеся ко времени работы приложения или системы; вторая группа (design time) определяет ключевые аспекты проектирования приложения или системы. Многие из этих атрибутов взаимозависимы.

Рассмотрим более подробно каждую из этих групп.

Группа runtime

К этой группе относятся следующие атрибуты качества:

• Доступность — атрибут качества, определяющий время непрерывной работы приложения или системы. Чтобы определить этот параметр, обычно указывают максимально допустимое время простоя системы.
• Надежность — требование, описывающее поведение приложения или системы в нештатных ситуациях (примеры: автоматический перезапуск, восстановление работы, сохранение данных, дублирование важных данных, резервирование логики)
• Требования к времени хранения данных (например, использование БД в качестве постоянного хранилища данных, продолжительность хранения данных)
• Масштабируемость — требования к горизонтальному и/или вертикальному масштабированию приложения или системы. Говоря о вертикальной масштабируемости, мы определяем требования к вертикальной архитектуре системы или приложения. К требованиям вертикальной масштабируемости могут относиться, например, возможность переноса приложений на более мощные SMP-системы, поддержка большого объема памяти и файлов. Говоря о горизонтальной масштабируемости, мы определяем требования к горизонтальной архитектуре системы или приложения. К требованиям горизонтальной масштабируемости могут относиться, например, возможность использования технологий кластеризации. Следует особо заметить, что вертикальное масштабирование обычно направлено на повышение производительности системы. Горизонтальное масштабирование, помимо производительности, позволяет повысить отказоустойчивость системы. Более подробно о вертикальном и горизонтальном масштабировании можно прочитать, например, здесь.
• Требования к удобству использования системы/приложения (с точки зрения пользователя) и требования к удобству и простоте поддержки (Usability)
• Требования к безопасности, как правило, включают в себя три большие категории: требования, связанные с разграничением доступа, требования, связанные с работой с приватными данным, и требования, направленные на снижение рисков от внешних атак.
• Требования к конфигурируемости приложения, взаимодействия и расположения компонентов можно условно разделить на четыре уровня:
  
  1. конфигурируемость на основе предопределенного набора параметров (predefined configurability), когда необходимый уровень модификации достигается путем изменения значений параметров из предопределенного набора;
  
  2. конфигурируемость на основе предопределенного набора базовых объектов (framework constrained configurability), когда необходимый уровень модификации достигается путем перекомпоновки предопределенного набора процессов, сущностей и служебных процедур;
  
  3. конфигурируемость путем реализации новых базовых объектов (basis reimplementation), когда обеспечивается расширение набора процессов и сущностей;
  
  4. конфигурируемость путем новой реализации системы (system reimplementation), когда система должна устанавливаться и настраиваться с нуля.
• Требования к производительности решения, определяемые в терминах количества одновременно работающих пользователей, обслуживаемых транзакций, времени реакции, продолжительности вычислений, а также скорости и пропускной способности каналов связи
• Ограничения, накладываемые на объем доступной памяти, процессорного времени, дискового пространства, пропускную способность сети, при которых приложение должно эффективно выполнять возложенные на него задачи

Группа design time

К этой группе относятся следующие атрибуты качества:

• Требования к повторному использованию реализации или компонентов приложения или системы (Reusability). О том, как это выражается в конкретной реализации, будет рассказываться далее. Пока ограничимся лишь тем, что чаще всего эти требования будут возникать там, где общие компоненты используются несколькими модулями разрабатываемой вами системы.
• Требования к расширяемости (Extensibility) приложения или системы в связи с появлением новых функциональных требований, тесно связанное с таким архитектурным атрибутом качества, как переносимость кода. Как правило, на начальном этапе сбора требований можно ограничиться указанием тех функциональных областей, которые в дальнейшем должны удовлетворять требованию расширяемости.
• Требования к переносимости (Portability) приложения или системы на другие платформы.
• Требования к взаимодействию между компонентами решения, между внешними компонентами, использование стандартных протоколов и технологий взаимодействия (Interoperability). Например, к таким требованиям можно отнести возможность использования нескольких стандартных протоколов для обмена данными между одной из подсистем разрабатываемой системы и внешней системой-поставщиком данных (на примере ArcGIS)
• Требования к поддержке системы или приложения (Supportability). Среди этих параметров могут быть названы такие как, напрмер, дешевизна и скорость разработки, прозрачность поведения приложения, простота анализа ошибок и проблем в работе
• Требования к модульности приложения или системы (Modularity). Обычно такие требования указывают, каким образом система должна быть разделена на модули, или перечисляют список обязательных модулей, которые должны входить в состав системы.
• Требования к возможности тестирования (Testability) приложения или системы определяют объем требований к автоматическому и ручному тестированию, наличие необходимого инструментария
• Требования к возможности и простоте локализации (Localizability) приложения или системы определяют возможности и специфические архитектурные требования, накладываемые процессом локализации. Эти требования содержат также перечень языков, на которые предполагается выполнять локализацию приложения или системы

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

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

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

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

• обязательными, т.е. без них проект будет считаться незавершенным, а заказчик останется неудовлетворенным. Если готовый продукт не соответствует всем обязательным требованиям, это — провал;
• желательными. Эти требования не обязательны, но важны для заказчика, поэтому их стараются соблюдать, за исключением тех случаев, когда они влекут за собой неприемлемое увеличение стоимости или продолжительности проекта;
• необязательными — это те требования, без которых заказчик вполне может обойтись и которые удовлетворяются только по возможности.

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

Бизнес-процессы — самое начало работы.
Например, можно рассмотреть процессы RUP/MSF (упрощенная последовательность):
1. Бизнес-моделирование
2. Выявление требований
3. RUP: Анализ и проектирование, MSF: концептуальный, логический и физический дизайн
4. Реализация
5. Тестирование
6. Опытно-промышленная эксплуатация
7. Support и развитие системы

Совсем упрощенно:
1. От заказчика поступает начальная концепция системы (в нескольких предложениях что они хотят, что это позволит достигнуть и т.д.) — по сути это и есть бизнес-требования.
2. Приступаем к моделированию бизнес-процессов, которые хотим автоматизировать (тут в помощь нам ARIS, IDEF0/IDEF3, UML), возможно, строим дополнительную модель (оптимизированную), в которой будут прописаны бизнес-процессы после автоматизации.
3. Вытрясаем из заказчика требования к разрабатываемой системе (это будут пользовательские требования).
4. На основе пользовательских требований формулируем функциональные требования к системе (пользовательские требования — не единственный источник функциональных требований).

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

Например:
«Система должна вести журнал всех действий пользователя» или «Система должна позволять создавать новые Проекты».

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

Пользовательские и функциональные требования как правило связаны между собой. Это необходимо для отслеживания зависимостей требований друг от друга. В системах управления требованиями (например, Borland CaliberRM, TelelogicDoors, Rational RequisitePro) для этого есть так называемые «матрицы трассировки», на которых графически стрелками показываются зависимости между требованиями.

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

Схема процесса разработки с уровнями требований

Формирование и анализ требований

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

Аттестация требований

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

Подготовка к интервью по сбору требований у заказчика

Компания — Бизнес-требования

Источники: Топ-менеджмент компании
Документ: Бизнес-требования (обоснование потребностей инициативы)
Ответственный: Менеджер проекта

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

1. Описание контекста и списка ключевых заинтересованных лиц
2. Описание целей создания системы и критериев достижения
3. Ключевые бизнес-требования к решению и их приоритеты
4. Существующие и возможные ограничения на решение

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

Заказчик — Документ требований заинтересованных лиц

Этот документ описывает рекомендуемое содержание документа требований заинтересованных лиц:

• Бизнес-назначение
• Бизнес-рамки
• Обзор бизнеса
• Заинтересованные лица
• Организационная среда
• Цели и результаты
• Бизнес-модель
• Информационная среда
• Бизнес-процессы
• Политики и правила
• Ограничения деятельности
• Организационная структура
• Концепция использования системы
• Сценарии эксплуатации
• Проектные ограничения

Пользователь — Требования пользователя

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

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

Проблемы при формировании пользовательских требований

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

Системные требования

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

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

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

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

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

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

Нефункциональных требований

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

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

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

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

Требования предметной области

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

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

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

Организационные требования

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

Требования к интеграции

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

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

Интеграция через ESB

Интеграция через ESB (Enterprise Service Bus, «Сервисная шина предприятия») применяется для обеспечения информационных систем возможностями для взаимодействия с сервисами. Использование этого метода интеграции приложений обеспечивает слабую связанность между информационными системами, так как системы взаимодействуют не напрямую, а через сервисы, размещенные на сервисной шине предприятия.
Основными функциями ESB являются:

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

Интеграция точка-точка

Интеграция приложений напрямую, является методом интеграции, при котором взаимодействие между системами происходит без применения универсального централизованного посредника, такого, как сервисная шина предприятия (ESB).

Интеграция данных

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

Задачи интеграции данных:

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

Интеграция ETL
Интеграция ETL характеризуется следующим сценарием:
На платформе ETL пишется процесс, который
1) С помощью средств доступа к БД 1ой системы забирает из таблиц 1ой системы данные
2) С помощью средств и ресурсов БД 1ой или 2й системы или своих собственных механизмов осуществляет преобразование к структурам таблиц 2й системы
3) Загружает данные в таблицы БД 2й системы.

Файловый обмен
Файловый обмен характеризуется следующим сценарием:
1) Приложение, которому требуется передать данные другому приложению, сохра¬няет их в файле.
2) Разрабатывается интеграционное решение, которое преобразует формат файла в формат, требуемый другим приложением. (В частном случае для этого дорабатывается одна из интегрируемых систем)
3) Приложение которому нужны данные, загружает подготовленный файл.

Требования к пользовательскому интерфейсу

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

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

К первой группе можно отнести следующие типы требований:

• Требования к размещению элементов управления на экранных формах
• Требования к содержанию и оформлению выводимых сообщений
• Требования к форматам ввода

Ко второй группе относятся следующие типы требований:

• Требования к реакции системы на ввод пользователя
• Требования к времени отклика на команды пользователя

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

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

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

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

Процесс управления изменениями

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

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

Как и у всех путешествий, у проекта улучшения процессов должна быть цель. Если не определить конкретных целей по улучшению, люди не смогут работать согласованней, а вы не сможете сказать, есть ли движение вперед, не сможете определять приоритеты задач и сказать, когда цель достигнута.
Метрика — измеримая характеристика проекта, продукта или процесса.
Ключевые показатели производительности (KPI) — это метрики, привязанные цели и служащие мерилом продвижения проекта к достижению определенной цели или результата. Набор KPI-показателей может отображаться на контрольной панели, показывая приближение к целям.

При определении целей по совершенствованию процессов нужно иметь в виду два обстоятельства.

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

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

• Правильно ли были проанализированы проблемы и выявлены их первопричины?
• Выбрали ли вы действия по улучшению, непосредственно направленные на эти первопричины?
• Был ли реалистичным план реализации этих действий по улучшению? Был ли план реализован, как планировалось?
• Изменилось ли что-то со времени исходного анализа, что должно было заставить переориентировать действия команды по улучшению?
• Действительно ли члены команды приняли новые приемы работы и прошли период обучения, чтобы начать активно применять их на практике?
• Были ли поставлены реалистичные цели, которые команда была в состоянии достичь?

Высокопроизводительные проекты отличаются эффективными процессами на всех этапах создания требований: выявления, анализа, спецификации, проверки и управления. Для облегчения выполнения этих процессов каждой организации необходим набор документов процесса (process assets).
Любой процесс определяют выполняемые действия и получаемые результаты; документы процесса помогают команде выполнять процессы последовательно и эффективно. Эти документы позволяют участникам проекта понять, какие шаги им следует предпринять и каких результатов от них ждут.

Документы процесса разработки требований

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

Документы процесса управления требованиями

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

Пример дорожной карты совершенствования процессов работы с требованиями

5
1
Голос

Article Rating

Уровни требований к программному продукту

12.02.2018 18:30

Текстовая расшифровка второго видеоурока курса Введение в профессию аналитика.

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

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

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

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

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

Что нам даёт эта модель? Cобственно, она определяет направление движения, когда мы разрабатываем требования. Что крайне желательно сначала определиться с областью проблемы. Выяснить, собственно, какие проблемы мы собираемся решать. И после этого, в два этапа в данном случае, разрабатывать требования к системе. Сначала на уровне функций, и потом на уровне более детальном.

То есть вот эти три уровня которые предлагает Леффингуэл:

1. уровень потребностей,

2. уровень функций и

3. уровень программных требований.

В книге Вигерса, о которой я тоже уже говорил, подход немножко другой. Но он тоже выделяет три уровня.

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

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

Бизнес-требования в общем-то соответствуют уровню потребностей, который описан у Леффингуэлла.

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

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

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

Если очень приближённо говорить, очень примитивно, то работа бизнес-аналитика лежит преимущественно между первым и вторым уровнем, а работа системного аналитика больше приближена к работе между вторым и третьим уровнем.

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

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

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

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

Требования пользовательского уровня — кто и как взаимодействует с продуктом.

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

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

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

Не менее известный сейчас и распространенный метод описания требований с помощью User Stories (пользовательских историй) тоже, на самом деле, был разработан для описания требований в первую очередь пользовательского уровня. Хотя в Agile их, конечно, масштабировали сейчас на все уровни.

Ещё есть метод персонажей, может быть, не так хорошо известный аналитикам. Но в последней версии BABOK (Business Analysis Body of Knowledge, есть такой свод знаний по бизнес-анализу) этот метод уже упоминается как метод, которым аналитикам тоже нужно владеть. Мы о нём немного поговорим в курсе.

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

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

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

Предыдущий урок: Что такое требования к программному продукту

Следующий урок: Виды требований к программному продукту

Требования к программному обеспечению — CoderLessons.com

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

Требование техники

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

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

Требование инженерного процесса

Это четырехэтапный процесс, который включает в себя:

• Технико-экономическое обоснование
• Сбор требований
• Спецификация требований к программному обеспечению
• Проверка требований к программному обеспечению

Давайте посмотрим на процесс вкратце —

Технико-экономическое обоснование

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

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

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

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

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

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

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

SRS — это документ, созданный системным аналитиком после сбора требований от различных заинтересованных сторон.

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

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

SRS должен придумать следующие функции:

• Требования пользователя выражены на естественном языке.
• Технические требования выражены на структурированном языке, который используется внутри организации.
• Описание дизайна должно быть написано в псевдокоде.
• Формат форм и печать графического интерфейса.
• Условные и математические обозначения для DFD и т. Д.

Проверка требований к программному обеспечению

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

• Если они могут быть практически реализованы
• Если они действительны и согласно функциональности и области программного обеспечения
• Если есть какие-то неясности
• Если они завершены
• Если они могут быть продемонстрированы

Процесс выявления требований

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

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

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

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

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

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

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

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

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

Существуют различные способы определения требований

Интервью

Интервью являются сильной средой для сбора требований. Организация может проводить несколько типов интервью, таких как:

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

Обзоры

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

Анкетирование

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

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

Анализ задач

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

Анализ предметной области

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

мозговая атака

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

макетирования

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

наблюдение

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

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

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

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

• Очистить
• Правильный
• последовательный
• Последовательный
• понятный
• модифицируемый
• проверяемый
• Приоритетное
• недвусмысленный
• прослеживаемый
• Достоверный источник

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

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

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

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

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

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

Примеры —

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

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

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

Нефункциональные требования включают в себя —

• Безопасность
• логирование
• Место хранения
• конфигурация
• Спектакль
• Стоимость
• Interoperability
• гибкость
• Аварийное восстановление
• доступность

Требования классифицированы логически как

• Должно быть : программное обеспечение не может работать без них.
• Должно иметь : Расширение функциональности программного обеспечения.
• Может иметь : Программное обеспечение все еще может нормально функционировать с этими требованиями.
• Список пожеланий : эти требования не соответствуют каким-либо целям программного обеспечения.

При разработке программного обеспечения необходимо реализовать «Должен иметь», «Должен иметь» — предмет споров с заинтересованными сторонами и отрицания, тогда как «может иметь» и «список пожеланий» можно сохранить для обновлений программного обеспечения.

Требования к пользовательскому интерфейсу

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

• прост в эксплуатации
• быстрый ответ
• эффективно обрабатывать ошибки в работе
• обеспечение простого, но последовательного пользовательского интерфейса

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

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

Программный системный аналитик

Системный аналитик в ИТ-организации — это человек, который анализирует требования к предлагаемой системе и обеспечивает правильное и правильное оформление и документирование требований. Роль аналитика начинается на этапе анализа программного обеспечения SDLC. Аналитик обязан убедиться, что разработанное программное обеспечение соответствует требованиям клиента.

Системные аналитики имеют следующие обязанности:

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

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

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

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

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

По словам Тома ДеМарко (a) (Software Engineer): «Вы не можете контролировать то, что не можете измерить». По его словам, очень ясно, насколько важны меры программного обеспечения.

Давайте посмотрим некоторые метрики программного обеспечения:

Размер метрики — LOC (Lines of Code), в основном рассчитывается в тысячах доставленных строк исходного кода и обозначается как KLOC.

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

Метрики качества — Дефекты, их типы и причины, последствия, интенсивность и их значение определяют качество продукта.

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

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

LABA 2

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

Требования разных уровней, это :

· требования пользователя для обозначения высокоуровневых обобщенных требований;

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

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

Три перечисленных вида требований можно определить следующим образом.

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

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

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

Требования пользователя

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

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

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

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

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

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

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

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

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

Требование взаимодействия «человек-компьютер» точно определяет любой аспект интерфейса «пользователь- ПК». Это может включать положение о стиле, языке команд, меню, окнах; форматах сообщений, времени, затрачиваемое на ответ по команде.

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

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

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

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

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

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

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

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

Различают три типа специфицируемых интерфейсов.

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

2. Структуры (интерфейсные форматы) данных, которые пересылаются от одной подсистемы к другой.

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

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

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

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

3 Требования предметной области.Характеризуют ту предметную область, для которой разрабатывается система. Эти требования могут быть функциональными и нефункциональными.

Читайте также:

Рекомендуемые страницы:

Поиск по сайту

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

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

Знаете ли вы, что существует множество различных требований к программному обеспечению? Ладно, наверное, да! В этом посте я расскажу вам о наиболее распространенных типах требований к программному обеспечению.

Готовы начать?

Различные типы требований к программному обеспечению

Наиболее распространенные типы требований к программному обеспечению:

1. Бизнес-требования (BR)
   • Это общие бизнес-цели организации, создающей продукт, или заказчика, заказавшего проект.
   • Обычно они представлены в виде одной страницы с маркерами высокого уровня.
2. Требования рынка (MR)
   • Это детализация BR, но все еще высокого уровня. В дополнение к бизнес-целям они также определяют потребности рынка.
   • Обычно они представлены в виде маркированного списка или таблицы с указанием приоритетов и обычно не превышают 5 страниц.
3. Функциональные требования (FR) — сценарии использования
   
4. Нефункциональные требования (NFR)
   
   • Они не связаны с «функциональностью» продукта, но охватывают такие цели, как надежность, масштабируемость, безопасность, интеграция и т. Д.
   • Многие проекты делают ошибку, не указывая их явно.
5. Требования к пользовательскому интерфейсу (UIR)
   
   • Спецификации пользовательского интерфейса не считаются «требованиями» в традиционной теории управления требованиями .
   • Фуей! На мой взгляд, спецификации пользовательского интерфейса действительно являются требованиями (какие еще?) — и на самом деле их следует рассматривать как неотъемлемую часть требований для любого программного обеспечения с пользовательским интерфейсом.

Эй, а что же тогда «особенности»?

Как видите, в приведенный выше список не входит популярный термин, который часто используется в проектах по разработке программного обеспечения: Features .Интересно, почему? Причина проста…

«Характеристика» — это просто группа функциональных требований (FR), которые вместе отвечают конкретным потребностям клиента.

Вот и все — все различные типы программного обеспечения, подходящие для печати! В следующем посте я расскажу о документах с требованиями. А пока…

Примечание редактора:
Заинтересованы в доступном программном обеспечении корпоративного качества, которое поможет вам лучше управлять требованиями? Воспользуйтесь БЕСПЛАТНОЙ 30-дневной пробной версией аккомпанемента или зарегистрируйтесь для получения демоверсии.

.

Характеристики действующих требований к программному обеспечению и спецификации требований к программному обеспечению (SRS)

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

Характеристики действующих требований

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

Завершено

Каждое требование должно полностью описывать предоставляемые функциональные возможности. Он должен содержать всю информацию, необходимую разработчику для разработки и реализации этой функции. Если вы знаете, что вам не хватает определенной информации, используйте «TBD» (подлежит определению) в качестве стандартного флажка, чтобы выделить эти пробелы. Разрешите все TBD в каждой части требований, прежде чем приступить к построению этой части.

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

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

Повышение требований не только приносит пользу разработчикам, но и способствует рентабельности инвестиций всей организации. Узнайте, как это сделать, в нашей статье «Повышение требований к бизнесу».

Правильно

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

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

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

Возможно

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

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

Необходимо

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

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

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

Приоритет

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

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

Однозначно

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

Поддается проверке

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

Если требование не поддается проверке, определение того, правильно ли оно было выполнено, становится вопросом мнения, а не объективного анализа.Неполные, непоследовательные, невыполнимые или неоднозначные требования также не поддаются проверке.

Характеристики действующих спецификаций требований к программному обеспечению (SRS)

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

Завершено

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

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

Согласованный

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

Возможность изменения

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

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

Отслеживаемый

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

Как узнать, соответствуют ли эти атрибуты вашим требованиям и SRS?

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

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

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

Jama Software заключила партнерское соглашение с Карлом Вигерсом, чтобы делиться лицензионным контентом из его книг и статей. Карл Вигерс — независимый консультант, а не сотрудник Jama. С ним можно связаться на ProcessImpact.com.

.Анализ требований к программному обеспечению

с примером

• Home

• Testing

  • • Back
    • Agile Testing
    • BugZilla
    • Cucumber
    • Database Testing
    • 9000 J27
    • 9000 J27
    • 9000 J27
    • JUnit
    • LoadRunner
    • Ручное тестирование
    • Мобильное тестирование
    • Mantis
    • Почтальон
    • QTP
    • Назад
    • Центр контроля качества (ALM)
    • RPA 9000 Test4 Управление
    • TestLink

• SAP

  • • Назад
    • ABAP
    • APO
    • Начинающий
    • Basis
    • BODS
    • BI
    • BPC
    • CO
    • Назад
    • CRM
    • Crystal Reports
    • QM4000
    • QM4
    • Заработная плата
    • Назад
    • PI / PO
    • PP
    • SD
    • SAPUI5
    • Безопасность
    • Менеджер решений
    • Successfactors
    • Учебники SAP
  • Apache
    • AngularJS
    • ASP.Net
    • C
    • C #
    • C ++
    • CodeIgniter
    • СУБД
    • JavaScript
    • Назад
    • Java
    • JSP
    • Kotlin
    • Linux
    • Linux
    • Kotlin
    • Linux

    js

    • Perl
    • Назад
    • PHP
    • PL / SQL
    • PostgreSQL
    • Python
    • ReactJS
    • Ruby & Rails
    • Scala
    • SQL

    000

    • SQL

    000

    0003 SQL

    000

    0003 SQL

    000

    • UML
    • VB.Net
    • VBScript
    • Веб-службы
    • WPF

  • Обязательно учите!

    • • Назад
      • Бухгалтерский учет
      • Алгоритмы
      • Android
      • Блокчейн
      • Business Analyst
      • Создание веб-сайта
      • CCNA
      • Облачные вычисления
      • 00030003 COBOL
        9000 Compiler
        9000 Встроенные системы
        • 00030002 9000 Compiler
          • Ethical Hacking
          • Учебные пособия по Excel
          • Программирование на Go
          • IoT
          • ITIL
          • Jenkins
          • MIS
          • Сети
          • Операционная система
          • 00030003
          • Назад

          Управление проектами Обзоры

          • Salesforce
          • SEO
          • Разработка программного обеспечения
          • VB A

        • Big Data

          • • Назад
            • AWS
            • BigData
            • Cassandra
            • Cognos
            • Хранилище данных

            00030003

            • HBOps

            0003

            • HBOps

            0003

            • MicroStrategy

        .

        Что такое функциональное требование? Спецификация, типы, ПРИМЕРЫ

        • Home

        • Testing

          • • Back
            • Agile Testing
            • BugZilla
            • Cucumber
            • Database Testing
            • 94000
            • 000
            • 9000 J27 Testing
            • JUnit
            • LoadRunner
            • Ручное тестирование
            • Мобильное тестирование
            • Mantis
            • Почтальон
            • QTP
            • Назад
            • Центр качества (ALM)
            • RPA
            • SAP Testing
            • RPA
            • TestLink

        • SAP

          • • Назад
            • ABAP
            • APO
            • Начинающий
            • Basis
            • BODS
            • BI
            • BPC
            • CO
            • Назад
            • CRM
            • Crystal Reports
            • MMO
            • HANA
            • Назад
            • PI / PO
            • PP
            • SD
            • SAPUI5
            • Безопасность
            • Менеджер решений
            • Successfactors
            • SAP Tutorials

          000

        • Web

        • AngularJS
        • ASP.Net
        • C
        • C #
        • C ++
        • CodeIgniter
        • СУБД
        • JavaScript
        • Назад
        • Java
        • JSP
        • Kotlin
        • Linux
        • Linux
        • Kotlin
        • Linux

        js

        • Perl
        • Назад
        • PHP
        • PL / SQL
        • PostgreSQL
        • Python
        • ReactJS
        • Ruby & Rails
        • Scala
        • SQL

        000

        • SQL

        000

        0003 SQL

        000

        0003 SQL

        000

        • UML
        • VB.Net
        • VBScript
        • Веб-службы
        • WPF

    • Обязательно учите!

      • • Назад
        • Бухгалтерский учет
        • Алгоритмы
        • Android
        • Блокчейн
        • Business Analyst
        • Создание веб-сайта
        • CCNA
        • Облачные вычисления
        • 00030003 COBOL
          9000 Compiler
          9000 Встроенные системы
          • 00030002 9000 Compiler
            • Ethical Hacking
            • Учебные пособия по Excel
            • Программирование на Go
            • IoT
            • ITIL
            • Jenkins
            • MIS
            • Сети
            • Операционная система
            • 00030003
            • Назад

            Управление проектами Обзоры

            • Salesforce
            • SEO
            • Разработка программного обеспечения
            • VB A

          • Big Data

            • • Назад
              • AWS
              • BigData
              • Cassandra
              • Cognos
              • Хранилище данных

              00030003

              • HBOps

              0003

              • HBOps

              0003

              • MicroStrategy

          .

          No related posts.