Карьера в IT. Системный аналитик, часть 1. Виды и качества требований
Всем привет.
Сегодня перейдем к более прикладной и конкретной теории, без которой нельзя обойтись хоть бизнес-, хоть системному аналитику (к слову, один из самых частых вопросов, который задают на собеседовании начинающего аналитика - какие виды требований ты знаешь? Какими качествами требование должно обладать?).
Не буду душнить и писать сухую теорию про то, что требование - это совокупность утверждений относительно атрибутов, свойств или качеств программной системы... бла-бла-бла. Я думаю, что все понимают - что такое требование к системе. Теперь давайте разберемся, какими они бывают.
Виды требований.
Общепринято делить требования на следующие категории:
Функциональные требования, которые включают в себя:
Бизнес-требования - что система должна делать с точки зрения бизнеса. Т.е. содержат в себе высокоуровневые задачи и цели заказчика. Как правило их формулируют именно те люди, которые заказывают какой-либо продукт. Они описывают те цели, которые заказчик намеревается достичь с помощью системы (ПО). В 90% случаев эти требования направлены на получение дополнительной прибыли заказчика:
Либо через внедрение доработки\системы, которая будет приносить прямую прибыль через, допустим, привлечение новых клиентов (привет ДБО и различные мобильные приложения);
Либо через сокращение издержек и оптимизацию процессов, что тоже приводит к увеличению прибыли;
Либо по необходимости. Например, когда центробанк выдал на-гора очередное распоряжение по необходимости считать ПДН (показатель долговой нагрузки) клиента - банкам ничего не остается делать, кроме как внедрять соответствующие доработки. Ну тут тоже есть косвенная финансовая выгода: ты делаешь доработку > не получаешь штрафы и не теряешь лицензию > профит.
Пример бизнес-требования: “Требуется уменьшить время работы над одной заявкой сотрудником колл-центра на 50%” (чувствуете прямую выгоду? Быстрее обработка > больше заявок будет обработано в единицу времени > дешевле стоимость обработки или просто выше КПД).
Пользовательские требования описывают цели и задачи, которые пользователи смогут решить с помощью системы. Их часто представляют в виде сценариев использования (Use case, о которых поговорим позже).
Функциональные требования (системные) - определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований. Другими словами, что должны сделать разработчики, чтобы по итогу получилась система, позволяющая пользователь выполнять их функционал и выполняющие бизнес-требования заказчика.
Например, “Требуется реализовать возможность поиска товара по продавцу, категории, диапазону сумм и рейтингу”.
Нефункциональные требования описывают характер поведения системы и атрибуты качества и также делятся на несколько категорий:
Бизнес-правила - описывают почему система должна работать именно так в разрезе внутренних корпоративных правил, требований закона и различных стандартов.
Например, многие табачные компании и компании, производящие алкоголь, требуют постоянного доказательства того, что промо-сайтами пользуются люди, достигшие определенного возраста. Это бизнес-правило (подтверждение возраста) возникает по требованию этических комитетов заказчика, хотя и несколько противоречит маркетинговым целям и требованиям по usability;Атрибут качества - описывают дополнительные характеристики продукта в различных измерениях, важных для пользователя или разработчиков. Эти характеристики включают практичность, портабельность, целостность, эффективность, устойчивость;
Ограничения - это формулировка условия, которое модифицирует требование или набор требований сужая выбор возможных решений.
Например, "Требуется ограничить загрузку файлов размером более 20мб", "Ограничить работу приложения только на IOS" или только в браузере Chrome и т.д.
Внешние интерфейсы - описание аспектов взаимодействия с другими системами и операционной средой. К ним относятся требования к API продукта или системы, а также требования к API других систем, с которыми осуществляется интеграция.
Именно такую классификацию требований предложил и описал Вигерс в своей книге "Разработка требований к программному обеспечению" и сейчас, в целом, все придерживаются ее.
На схеме это выглядит примерно вот так:
Качества требований:
С видами требований разобрались. Теперь нельзя обойти стороной вопрос о том, а какими они должны быть, эти требования? Вот список качеств, которыми требование, очень желательно, должно обладать:
Атомарность - требование является атомарным, если его нельзя декомпозировать на несколько требований. Например, “Требуется ограничить загрузку файлов размером более 20мб” является атомарным, т.к. его нельзя разделить на несколько частей;
Завершенность и полнота - требование содержит полный набор информации для однозначного понимания;
Краткость - чем лаконичнее требование, тем лучше;
Консистентность - требование не должно противоречить самому себе и другим требованиям;
Выполнимость - требование возможно реализовать в рамках проекта (его сроков и бюджета);
Проверяемость - реализованность требования может быть определена через один из четырёх возможных методов: осмотр, демонстрация, тест или анализ;
Однозначность - разработчик, тестировщик (или любой другой человек) должен понять это требование также, как и вы. Соответственно требование не должно быть расплывчато, размыто, не должно содержать непонятных аббревиатур.
Понятно, что на практике далеко не все требования обладают каждым из этих качеств. Где-то из-за спешки, где-то из-за ошибки или даже нежелания. У кого-то просто своеобразный стиль и он любит писать длинный сложносочиненные требования - и это неплохо, там где уместно. Самое главное, чтобы требование было консистентным, завершенным, выполнимым и однозначным.
У меня, как и у многих на самом деле, в начале моей карьеры аналитика были проблемы с тем, что я просто физически сопротивлялся тому, чтобы писать кратко. Мне казалось, что если я написал одно предложение и этого будто бы хватало - что-то не так и нужно налить воды и чего-нибудь еще придумать. Но на самом деле, если вы уместили решение задачи в одно предложение и оно полностью покрывает всё что необходимо - эт круто и не нужно этого пугаться (но перепроверить, что ничего не упущено не помешает =) )
P.S.: Опять получился длиннопост, но скорее всего все последующие будут примерно такими же, т.к. на самом деле темы объемные и уместить все что хочется (и необходимо) рассказать в одном посте достаточно тяжело.
P.P.S.: Буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.