При разработке какой-либо новой информационной системы (либо при внедрении существующей) специалисты обязательно столкнутся в своей работе с необходимостью определения данного рода требований. Есть смысл подробно их рассмотреть. Что такое нефункциональные требования, какими они бывают, как их определяют профессионалы.
Две категории требований
Предписаний по характеристикам, качеству программных продуктов, информационных систем большое множество. Однако их можно разделить всего на две большие категории — это функциональные и нефункциональные требования. Важно в начале статьи обозначить между ними разницу.
Вам будет интересно: Аналог «АвтоКада»: список альтернативных программ, описание и возможности
- Функциональные требования. Описывают, что конкретно нужно реализовать в той или иной системе или продукте, какие действия должны производить пользователи в отношении данной разработки.
- Нефункциональные требования. Описывают, как именно работает создаваемая система или программный продукт, какими свойствами и характеристиками обладает конкретная разработка.
Пункт 1. Понятие о функциональных и нефункциональных требованиях мы сформировали. Переходим теперь ко второму пункту — рассмотрим, что конкретно возможно отнести к последним.
Как отличать нефункциональные требования?
Вам будет интересно: Как управлять курсором с клавиатуры? Назначение клавиш клавиатуры
Что относится к категории?
По сути, к нефункциональным требованиям прежде всего причисляют различные атрибуты качества продукта. А именно — требования, определяющие качественные характеристики разработки (программного обеспечения, информационной системы). Это, конечно, надежность, масштабируемость, производительность продукта.
Однако большое значение имеют и такие нефункциональные требования:
- Ограничения. То есть условия, ограничивающие выбор каких-либо решений по воплощению в жизнь отдельных требований (или наборов требований). Они сужают разнообразие выбора инструментов, стратегий, средств при разработке как структуры (архитектуры), так и внешнего вида информационного либо программного продукта.
- Бизнес-правила. Сюда относятся руководящие правила, политика, принципы, положения, как-то ограничивающие определенные аспекты бизнеса. Например, они могут определять состав и правила выполнения каких-либо бизнес-проектов. Что можно отнести в данную категорию? Корпоративную политику, всевозможные правительственные постановления и указы, промышленные стандарты, вычислительные алгоритмы. Все правила, что как-то влияют на разработку системы, продукта, используются во время работы над проектом.
- Предложения по реализации. В группу входят конкретные предложения, оценивающие возможность применения определенных архитектурных и технологических решений.
- Внешние интерфейсы. Описание ключевых аспектов взаимодействия продукта с иными системами и операционной средой. Прежде всего, это требования к API системы или продукта, а также требования к API иных систем, с которыми планируется интеграция разрабатываемого продукта.
- Предложения по проверке, тестированию разрабатываемого программного обеспечения. Это ряд дополнений к требованиям, указывающий, как то или иное требование должно быть протестировано на практике.
- Юридические требования. К лицензированию продукта, наличию патента и проч.
Вам будет интересно: Установка Hackintosh: особенности, пошаговое описание и отзывы
Как писать требования так, чтобы команда хотела их читать / Александр Войтехович / ISsoft
Важно отметить, что нефункциональные требования к системе предварительно определяются и фиксируются. Только после этого специалист может приступить к разработке продукта.
Примеры требований
Чтобы иметь более ясное представление о нефункциональных требованиях к информационной системе, разберем ряд примеров:
- Ограничения. «Данная разработка ведется только на платформе вендора Х». «При аутентификации пользователя в информационной системе должны использоваться только биометрические методики идентификации».
- Бизнес-правила. «При отгрузке продукта менеджер обязан запросить у бухгалтера предприятия счет-фактуру и транспортно-товарные накладные». «Заказ будет считаться отмененным, если оплата по счету не поступила поставщику в течение 14-ти дней».
- Внешние интерфейсы. «Обеспечить запись в журнал разрабатываемой операционной системы таких событий: сообщение о старте и остановке сервиса Х». «Обеспечить запись в журнал разрабатываемой программы параметров данных ее модулей: ядра, сканера, антивирусной базы. Информация должна быть занесена в журнал как при запуске приложения, так и при обновлении его модулей».
Как определять данные требования?
Анализ требований, бизнес-анализ, анализ проблемной области
В настоящее время существуют уже сотни методик, методологий, процессов, стандартов, регламентирующих те или иные детали выбора и комплексирования потоков работ при разработке автоматизированных информационных систем. То, что в АТ стоит в начале цепочки работ и что ее результаты во многом определяют успех проекта мало у кого вызывает сомнения.
Другое дело — работы, связанные с бизнес-анализом и бизнес-моделированием. Их роль не столь очевидна и принимается далеко не всеми методологиями. Итак, стоит ли собирать информацию о предприятии, для которого разрабатывается (выбирается) АИС в виде бизнес-моделей или стоит пропустить этот этап и сразу формировать артефакты АТ? Авторы [5.1], «отцы-основатели» RUP и UML, в этом вопросе дают определенную свободу: можно создавать бизнес-модели при помощи соответствующих расширений UML и рекомендаций RUP, а можно ограничиться выработкой глоссария объектов предметной области. Как и в вопросе выбора глубины проработки артефактов АТ, вопрос — проводить или не проводить бизнес-анализ (или, точнее говоря, анализ проблемной области), решается в зависимости от конкретной задачи.
Роль глоссария при ат.
Несколько утрируя, можно сказать, что Заказчик и Разработчик всегда говорят на разных языках. Общее понимание вырабатывается с трудом, этот процесс занимает время, но важность его трудно переоценить: ведь успешная реализация проекта в области и внедрения АИС во многом зависит от того, удастся ли выработать и документировать их общее представление о предмете разработки. Если же Разработчик идет еще дальше и вникает в особенности ведения дел на предприятии Заказчика — он, во-первых, сможет добиться лучшего понимания требований к АИС и, во-вторых, участвовать наряду с Заказчиком в формулировке этих требований, анализе пропущенных требований и пр. Глоссарий (подробнее см. в лекции 8) можно рассматривать, как документ, удостоверяющий общее понимание основной терминологии Заказчиком и Разработчиком. Задачу анализа бизнес-процессов (деловое моделирование), столь популярную в последние десятилетия ввиду устойчивой конъюнктуры, следует рассматривать, как часть более общей задачи, анализа проблемной области. Работы, посвященные анализу проблемной области, появились в отечественной литературе в середине прошлого века; данная тематика неразрывно связана с задачным подходом и инженерией экспертных систем. Применимы ли методы, принятые при построении интеллектуальных систем для такой «более приземленной» задачи, как задача построения АИС — безусловно, да. Так, стратегии извлечения знаний, рассмотренные в [5.2], во многом пересекаются с рекомендациями по работе аналитика [5.3], методы решения задачи путем редукции на подзадачи и поиска в пространстве состояний нашли свое отражение во множестве методик бизнес-анализа, анализа и синтеза программных систем и этот список можно продолжать. Другой вопрос — насколько результативно применение тех или иных моделей и методов при описании организационных систем. Ключ к решению этого вопроса лежит в следующем: вначале надо определить цели и задачи самого бизнес-анализа, как этапа построения КИС. С позиций моделирования, анализ требований (АТ) и анализ проблемной области (АПО) — принципиально разные процессы. АПО преследует классические цели создания модели: налицо объект (автоматизируемое предприятие или организационная система, ОС) и задача аналитика — отразить этот объект в создаваемой модели с требуемой степенью точности (рис. 5.1). Анализ требований, напротив, направлен на моделирование воображаемого, еще не существующего объекта (АИС) (рис. 5.2). Т.е. сначала создается модель, а затем, на ее основании, синтезируется объект. Для того, чтобы прояснить связь между этими процессами, необходимо заметить, что создаваемая АИС также является моделью, по отношении к ОС. Таким образом, создавая документ АТ, мы тем самым порождаем как бы «модель второго порядка», т.к. документ АТ является ничем иным, как моделью модели ОС. Не обладая моделью АПО, мы, конечно, можем создать модель АТ. Но при этом мы рискуем тем, что при синтезе оригинала модели (т.е. АИС), не обладая знаниями об ОС, мы можем попасть в ситуацию рассогласования: результирующая АИС не будет ингерентна (согласована с) ОС и, тем самым, не станет жизнеспособной. Рис. 5.1. Следует ли из этого, что этап АПО является необходимым звеном создания КИС? Нет, не всегда. Здесь уместно обратиться к классификации задач и методологий А. Коберна [5.4]. Кроме того, это зависит от состава третьей компоненты «треугольника моделирования» — моделирующего субъекта, в нашем случае — коллектива Разработчика. Если моделирующий субъект обладает неявными знаниями об ОС в достаточном объеме — значит, АПО можно исключить. На практике это возможно в следующих случаях:
- Разработчик является частью (структурным подразделением, дочерним предприятием и т.д.) ОС, в коллектив Разработчика входят эксперты, хорошо знающие предметную область;
- Заказчик наравне с Разработчиком участвует в создании документа АТ и разделяет с ним ответственность за принятие решений. Это — путь «agile методологий» (см. материалы лекции 15).
Рассмотрим теперь обобщенную «формулу» создания АИС. ОС->М(ОС)->М(АИС)->М’(АИС)->М’’(АИС)->М’’’(АИС)->АИС (рис. 5.1). Анализ организационной системы позволяет создать ее модель М(ОС). Это — модель бизнес-анализа (проблемной области). Анализируя модель проблемной области, в ней можно вычленить,
- с одной стороны, задачи и функции, реализуемые внутри ОС и функции коммуникации ОС и среды,
- с другой — устройство предметной области (в начале — на уровне концептуальной модели),
- с третьей — требования к информации и ее обработке.
Выделив среди функций те, которые подлежат автоматизации, мы получаем основу для выявления функциональных требований к системе. Остальная, собранная на этапе АПО, информация служит для поиска нефункциональных требований. В результате получаем модель АТ, как первое приближение модели АИС, М(АИС). Затем, путем углубленного анализа и проектирования, формируются, соответственно, аналитическая модель М’(АИС), проектная модель М’’(АИС) и модель реализации М’’’(АИС). Модель уровня реализации позволяет синтезировать собственно АИС, как совокупность программных, информационных, организационных и др. артефактов. АИС в свою очередь представляет собой модель организационной системы М’(ОС), замыкая цикл моделирования.
Источник: studfile.net
Требования в бизнес анализе примеры требований
За всеми нюансами предпроектного анализа нельзя забывать про главное — решение проблемы клиента. Рассмотрим процесс проведения аналитики на примере успешного кейса.
Гузель Рахимова
9 декабря 2014
Для чего
Для чего нужна аналитика на проекте? Чтобы в конце получился именно тот продукт, который задумывался в начале.
Предпроектная аналитика поможет составить образ конечного продукта, избавиться от неопределенности при реализации, снизить затраты на доработки и обслуживание.
- Как договориться и сделать хороший продукт в срок и без лишних нервов?
- Как вносить ясность и раскладывать требования по полочкам?
- Как же понять, все ли мы делаем правильно на проекте?
- Как адекватно оценить разработку?
- Как обозначить зоны ответственности?
Требования
Довольно часто во время разработки всплывают все новые и новые требования. Еще печальнее, когда это происходит на этапе сдачи проекта, когда конечный продукт не соответствует ожиданиям заказчика. И в результате заказчик не доволен, он теряет деньги, исполнитель переделывает и несет убытки.
Почему же так происходит? Участники проекта не сошлись в формулировках и ожиданиях, не поняли друг друга.
Такого непонимания можно избежать, если вовремя:
- конкретизировать требования
- упорядочить требования
- зафиксировать требования
Конкретизация
Весь пул пожеланий и ожиданий заказчика необходимо уточнить до состояния полной однозначности. Например, заказчик предъявляет такое требование «Интерфейс должен быть интуитивно понятным». Хорошее требование (спасибо Денису Бескову за отличный пример).
Но что оно значит? Кому должен быть интуитивно понятен интерфейс: заказчику, пользователю, разработчику, жене заказчика?
Что значит «интуитивно понятен»? Интерфейс позволяет пройти базовый сценарий на странице без подсказок? А если пользователь прошел базовый сценарий без подсказок, но потратил на это полчаса? Это много или мало? На все это должны быть ответы.
Требования должны быть однозначными, измеримыми, выполнимыми.
Конкретные требования к продукту позволяют задать границы разработки, обеспечить разработчиков однозначными тасками, определить критерии качества.
Упорядочение
Собранные требования можно привести в порядок разными способами.
Например, требования можно разбить на смысловые группы по приоритетам, по функциям и т.д. Например, есть задача по созданию сервиса, на котором пользователи могут платно смотреть некоторые видео. В первую очередь необходимо реализовать функцию загрузки, хранения и просмотра видео. Далее уже настроить возможность оплатить просмотр, сделать интеграцию с платежными сервисами, настройку регистрации пользователей и т.д.
Фиксация
Все собранные и обработанные требования обязательно должны быть зафиксированы документально и согласованы. Что не записано, значит, не было. Например, я фиксирую требования в таких документах как: рамки проекта, ТЗ, спецификация, художественное задание, контентная таблица, схемы и прототипы.
Решение проблемы
За всеми этими нюансами и деталями очень важно не упустить главное. А главным является решение проблемы клиента. Конечный продукт не должен быть вещью-в-себе, он должен решать задачи и быть полезным. Необходимо прояснить, в чем дело. Не всегда то, что хочет заказчик, это то, что ему действительно нужно.
Например, заказчик хочет интернет-магазин, так как считает, что это поможет ему увеличить прибыль. Ок, у заказчика появился классный, красивый и удобный интернет-магазин. Заказов стало больше, а прибыль не растет. В чем же дело? Заказов стало больше, операторы на стороне заказчика не успевают все обработать, на складе путаница.
Выходит, что внутренние системы заказчика не были готовы к такому объему работы. Сайт не помог, а только усугубил положение. Истинная проблема была в несовершенстве бизнес-процессов внутри компании заказчика. Это необходимо выяснить на этапе аналитики.
Как сделать
Как же сделать это? Задавать много вопросов.
Но главное здесь — это умение задавать правильные вопросы, даже пусть они будут неудобными. Важно поставить себя на место заказчика, на место конечного пользователя и попытаться представить, что и зачем я делаю.
К вам пришел проект. Не поленитесь, задайте вопросы «для кого, зачем, почему, как, что в итоге», представьте себя пользователем, узнайте ожидания заказчика. Ответы на эти вопросы, полученные в самом начале, сэкономят вам кучу нервов и крови в конце проекта.
Процесс
Кейс
Процесс проведения аналитики я хочу показать на примере одного успешного кейса.
Рассмотрим кейс разработки корпоративного сайта для агрохолдинга. Вроде звучит достаточно ясно, но дьявол кроется в деталях.
- 1 место в регионе
- 16 компаний
- 6 типов производства
- 6 сегментов аудитории b2b и b2c
- Всего 1 сайт для представления
Первый этап «Определение бизнес-задач и ожиданий»
Процесс проведения аналитики необходимо начинать с изучения бизнес-сферы клиента, целей и задач проекта и продукта.
На этом этапе мы с командой выезжали к клиенту в офис, провели встречи со всеми заинтересованными отделами, получили документ с видением сайта. По итогам первого этапа мы получили в качестве артефакта документ с рамками проекта, в котором зафиксировали задачи сайта, задачи клиента, задачи нас как исполнителя, указали ограничения по информационной структуре и навигации. Это послужило основой для разработки ТЗ и интерактивных прототипов
Второй этап «Изучение целевой аудитории»
Конечным продуктом будут пользоваться живые люди. Необходимо выяснить, кто они такие.
Далее мы изучили потенциальных посетителей сайта, их требований и задач. Сайт ориентирован одновременно и на b2b, и на b2c сегменты.
Нужно было учесть интересы партнеров, инвесторов, контролирующих органов, СМИ, соискателей, конечных потребителей продукции. По итогам был составлен документ с пользовательскими сценариями и описанием необходимых разделов.
Третий этап «Аудит конкурентов»
Следующим этапом стал аудит сайтов конкурентов и анализ лучших практик в интерфейсах и дизайне. Было изучено 19 различных сайтов и составлен документ с выводами, что опять таки повлияло на разработку прототипов и дизайна.
Поговорив с маркетологами, мы определили наиболее серьезных конкурентов и изучили их сайты по нескольким критериям: наличие промо баннеров, разделение контента по аудитории, каталог продукции, формы связи и т.д.
Четвертый этап «Анализ контента»
На четвертом этапоме мы собрали требования к контенту. Учитывая большой пул разнообразных задач сайта, обширную аудиторию и невероятное желание клиента рассказать о себе все, мы решили все зафиксировать. Мы с командой составили таблицу соответствия раздела и необходимого контента и отрядили специального человека собирать контент в офисе клиента.
Пятый этап «Определение функций и сценариев работы»
На предыдущих этапах мы выявили цели и задачи проекта, заказчика и пользователей. Теперь же исходя из этих данных мы описали функциональные возможности разрабатываемого продукта.
Все собранные и проанализированные требования к функциональности, работоспособности продукта мы отразили в проектной документации. Написали подробнейшее ТЗ и создали интерактивные прототипы.
Конечный прототип содержит 44 уникальных страницы. Проработанный до мелочей прототип позволил выявить недочеты в интерфейсе, помог осознать взаимосвязь всех разделов. Немаловажную роль сыграло тестирование прототипов.
Артефакты
В ходе анализа требований мы получили следующие артефакты:
- Рамки проекта
- Информационная структура сайта
- Пользовательские сценарии
- ТЗ на разработку сайта
- Контентная таблица
- Аудит сайтов конкурентов
- Прототипы
- Инструкции для контент-менеджеров
- Юзабилити тесты и приемочные тесты
Основными материалами, которыми мы руководствовались при разработке, были ТЗ и прототипы.
Итог
Проведенная аналитика позволила:
- Определить понимание конечного продукта
- Корректно оценить и спланировать разработку
- Избежать рисков, связанных с концептуальным изменением разделов, структуры сайта или подачи контента
- Сформулировать задачи команде
- Разработать сценарии тестирования
- Определить реальные сроки сдачи
- Написать инструкции
- Выполнить приемку работОсуществить поддержку проекта
- Все знают, что делать
- Все знают, что должно получиться
- Клиент в курсе всего и доволен
- .
- .
- Profit.
Продукт соответствует указанным требованиям, выполняет свою роль с первых же минут релиза.
Литература
Могу порекомендовать литературу, которая поможет понять процесс аналитики:
- Карл Вигерс «Разработка требований к программному обеспечению»
- А. Перерва, В. Иванова «Путь аналитика»
- К. Чандлер, Р. Уингер «UX дизайн. Практическое руководство по проектированию опыта взаимодействия»
- Алан Купер «Психбольница в руках пациентов»
- Хабрахабр
Ищете исполнителя для реализации проекта?
Проведите конкурс среди участников CMS Magazine
Узнайте цены и сроки уже завтра. Это бесплатно и займет ≈5 минут.
Источник: cmsmagazine.ru
