Если у вас под рукой нет необходимых инструментов, сбор требований может показаться трудной задачей.
В этой статье мы рассмотрим несколько методов сбора требований, которые можно использовать при планировании и разработке программного обеспечения. Эти инструменты помогут вам сделать документ с требованиями более удобным для чтения.
Область применения этих методов сбора требований ни в коем случае не ограничивается разработкой программного обеспечения: вы можете использовать наши инструменты в любом другом проекте для облегчения этого процесса.
Что такое сбор требований
Сбор требований – важнейшая часть любого проекта вне зависимости от его масштабов. Он необходим для понимания и удовлетворения потребностей клиентов.
Процесс сбора требований включает в себя определение и документирование требований клиентов, пользователей, заинтересованных сторон и т.д., связанных с проектом. Эти знания будут использоваться для разработки различных решений: продуктов, услуг, программного обеспечения и т.д.
УДАЛЯЙ UNITY!
Методы, используемые для сбора этих данных, могут включать такие приемы, как интервьюирование, мозговой штурм, фокус-группы, анкетирование и т.д.
Методы сбора требований для разработки программного обеспечения
Следующие инструменты могут быть использованы в качестве вспомогательных или самостоятельных методов сбора требований.
Составление карт пользовательской истории
Составление пользовательской истории – это техника, которая используется для выявления и понимания требований конечных пользователей. Оно помогает командам разработчиков определять приоритеты своей работы исходя из того, что необходимо для обеспечения отличного пользовательского опыта.
Используя карту пользовательской истории, вы можете описать, как пользователь взаимодействует с вашим программным обеспечением (или продуктом, услугой, веб-сайтом и т.д.), а также историю знакомства пользователя с вашим продуктом.
Таким образом, вы сможете определить,что является наиболее желательным для ваших пользователей, и определить приоритетность создания функций, которые позволят улучшить их опыт взаимодействия с вашим продуктом.
Как создать карту пользовательской истории
Шаг 1: Соберите междисциплинарную команду сотрудников, участвующих в разработке продукта.
Шаг 2: С помощью профиля клиента выявите своих пользователей, их цели, потребности и т.д.. Проанализируйте собранные вами данные, чтобы сформулировать проблемы вашего пользователя. Подумайте, как ваш продукт может решить эти проблемы.
Шаг 3: Определите, какие действия совершают ваши пользователи при использовании вашего продукта. Это будут истории или темы, расположенные в верхней части вашей карты пользовательской истории. Вы можете использовать функцию совместной работы Creately в режиме реального времени, чтобы привлечь команду к совместной работе по разбивке этих действий на более мелкие пользовательские сценарии. Расположите эти сценарии вертикально на карте, самые важные из них разместите вверху.
4. Функциональные требования, тикеты, JIRA (Курс бизнес-аналитик с нуля)
Шаг 4: Зафиксируйте действия пользователя в рамках вашего продукта слева направо на вашей карте истории пользователя. Если пользователей несколько, создайте разные сценарии для каждого из них.
Шаг 5: Выделите истории, которые важны для создания лучшего пользовательского опыта. Затем определите зависимости, технические требования, проблемные аспекты, которые могут повлиять на предстоящую работу. Перед планированием работы убедитесь, что у вас есть методы решения этих проблем.
Аналогичным инструментом, который можно использовать для описания и анализа траектории пользователя, является карта действий пользователя.
Диаграммы вариантов использования
Диаграммы вариантов использования помогают визуализировать взаимодействие между пользователем и системой, или, другими словами, действия пользователя и реакцию системы на них. Это помогает сохранять фокус на требованиях конечного пользователя на всем протяжении процесса разработки системы.
Ознакомьтесь с нашим пособием по диаграмме вариантов использования, чтобы узнать, как ее составить.
Диаграммы последовательности
Еще один тип диаграмм UML, который может использоваться в качестве метода сбора требований, – это диаграмма последовательности.
Диаграмма последовательности иллюстрирует, как различные части системы взаимодействуют друг с другом для выполнения функции, а также порядок, в котором происходят эти взаимодействия при выполнении конкретного сценария использования.
Узнайте все о диаграммах последовательности и о том, как их составлять, в нашем пособии по диаграммам последовательности.
Каркасное представление и макеты пользовательского интерфейса
Каркасное представление
Каркасное представление – это общий план интерфейса веб-сайта или приложения, визуализирующий его навигацию и расположение. Оно поможет вам понять, как будет работать приложение или сайт, и определить, нет ли ошибок в его проекте.
Используя шаблон каркасного представления, подобный приведенному ниже, вы и ваша команда сможете понять, как работает ваша система.
Макет пользовательского интерфейса
Более наглядной и детализированной версией каркаса является макет пользовательского интерфейса. Он поможет вам получить представление не только о том, как работает ваше приложение, но и о том, как оно будет выглядеть.
С помощью инструмента макета пользовательского интерфейса Creately вы сможете добавить ссылки на элементы диаграммы, сделав ее навигационной, так что при нажатии на кнопку вы сможете перейти на соответствующую страницу. Это поможет вам составить представление о пользовательском опыте сайта.
Карты процессов и блок-схемы
Карты процессов и блок-схемы дают упрощенное представление о процессе. Они могут оказаться очень полезными, если вы хотите отобразить свои бизнес-процессы, потоки пользователей или понять и объяснить процесс сбора требований.
Вы можете использовать его для того, чтобы
- понять существующую систему (с помощью карты текущего состояния) и то, как она изменится после применения того или иного решения (с помощью карты будущего состояния);
- объяснить, как применить новое решение;
- составить карту задач и этапов проекта (и добавить дополнительную информацию, например, владельцев задач или отделы с плавающими дорожками);
- выявить пробелы и препятствия в ваших процессах и найти соответствующие решения.
Вот наше руководство по блок-схемам, который поможет понять, как рисовать и использовать блок-схемы.
Диаграммы связей
При сборе требований часто проводятся индивидуальные и групповые мозговые штурмы. Вы можете использовать диаграммы связей, чтобы фиксировать свои идеи, организовывать и классифицировать их и продолжать их доработку с помощью диаграмм связей.
Вот еще несколько визуальных методов мозгового штурма, которые вы можете использовать для более быстрого генерирования идей.
Контекстные диаграммы системы
Контекстные диаграммы – это один из методов сбора требований к программному обеспечению, который следует использовать в самом начале процесса.
Контекстные диаграммы системы дают глубокое представление о системе в ее окружении и о том, как она взаимодействует с внешним миром: пользователями, другими системами и т.д.
9 визуальных инструментов для сбора требований к программному обеспечению
Диаграммы функциональной декомпозиции
Диаграмма функциональной декомпозиции может быть использована для разбиения системы на более мелкие и простые части. Это поможет вам лучше понять, как она функционирует.
Разбив таким образом систему или процесс, вы сможете легко понять, что требуется сделать.
Знаете другие методы сбора требований?
Эти методы сбора требований облегчают восприятие; то, что они являются визуальными, поможет сделать ваш документ с требованиями более легким для чтения и понимания.
Хотите дополнить наш список методов сбора требований? Расскажите нам о вашем любимом методе в комментариях ниже.
Источник: creately.com
Пользовательские и системные требования к создаваемому программному обеспечению. Способы записи требований.
Спецификация системных требований: ее назначение, структура и краткая характеристика всех ее разделов.
Системные требования — это более детализированное описание пользовательских требований. Они обычно служат основой для заключения контракта на разработку программной системы и поэтому должны представлять максимально полную спецификацию системы в целом. Системные требования также используются в качестве отправной точки на этапе проектирования системы.
Спецификация системных требований может строиться на основе различных системных моделей, таких, как объектная модель или модель потоков данных.
В принципе системные требования определяют, что должна делать система, не показывая при этом механизма ее реализации. Но, с другой стороны, для полного описания системы требуется детализированная информация о ней, которая по возможности должна включать всю информацию о системной архитектуре. На то существует ряд причин.
1. Первоначальная архитектура системы помогает структурировать спецификацию требований. Системные требования должны описывать подсистемы, из которых состоит разрабатываемая система.
2. В большинстве случаев разрабатываемая система должна взаимодействовать с уже существующими системами. Это накладывает определенные ограничения на архитектуру новой системы.
3. В качестве внешнего системного требования может выступать условие использования для разрабатываемой системы специальной архитектуры.
Спецификации системных требований часто пишутся естественным языком. Использование естественного языка может породить определенные проблемы при написании детализированной спецификации. Применение естественного языка подразумевает, что те, кто пишет спецификацию, и те, кто ее читает, одни и те же слова и выражения понимают одинаково. Однако на самом деле это не так, поскольку естественному языку присуща определенная размытость понятий. Вследствие этого одно и то же требование может трактоваться разными людьми по-разному.
Требования могут быть функциональные и эксплуатационные. Первые касаются алгоритмов, процессов обработки информации, а именно:
- вида информации, которую предполагается хранить и обрабатывать;
- различных отчетов (времени их выдачи, получателей, количества экземпляров и т.д.);
- пользовательского интерфейса (т.е. всего того, что видит на экране пользователь);
- защиты информации и контроля доступа к ней разных пользователей;
- создания резервных копий информации для восстановления ее при случайной или преднамеренной порче.
К эксплуатационным требованиям можно отнести следующие:
- производительность программы (скорость обработки, время реакции программы на запрос пользователя и т.п.);
- требования к аппаратным средствам (оперативная память, быстродействие процессора и т.п.).
Источник: studfile.net
Все для аналитиков
Это определение неидеально. Потому что есть требования, которые пользователь явно не высказывает, например, работа системы в режиме 24/7, или пользователь высказал какое-нибудь пожелание, но оно не было реализовано. Особый случай: требование высказано в устной форме. На мой взгляд, если требование не зафиксировано в письменном виде, то оно не существует.
Требования можно разделить на две большие группы:
- функциональные требования
- нефункциональные требования
На картинке показано как разделение требований по группам, так и документы, в которых требования фиксируются.
Функциональные требования — что система должна делать.
К функциональным требованиям относят:
- Бизнес-требования. Что система система должна делать с точки зрения бизнеса. Слово «бизнес» в данном контексте ближе к слову «заказчик». Пример бизнес-требования: промо-сайт, привлекающий внимание определенной аудитории к определенной продукции компании.
- Пользовательские требования – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases). Иначе говоря, пользовательские требования — это что может сделать пользователь: зарегистрироваться, посмотреть определенную информацию, пересчитать данные по определенному алгоритму и прочее.
- Функциональные требования – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований. Другими словами, что будут делать разработчики, чтобы выполнить пользовательские требования.
В группу функциональных требований относят и системные требования. Эти характеристики могут описывать требования как к аппаратному обеспечению (тип и частота процессора, объём оперативной памяти, объём жесткого диска), так и к программному окружению (операционная система, наличие установленных системных компонентов и сервисов и т. п.). Обычно такие требования составляются производителем или автором ПО. Например, для игры это могут быть требования такого типа: видеокарта — объём памяти от 64 Мб, совместимость сDirectX 9.0b и новейшие драйвера. Для сайта: ОС — Windows не ниже XP, браузеры IE не ниже 7.0 и так далее.
Почему важно указывать системные требования и утверждать их у заказчика? Если не указать, например, что важно обеспечить просмотр сайта в IE 6, то разработчики вполне могут выбрать такое архитектурное решение, которое не позволит корректно отображать сайт. Системные требования напрямую зависят от целевой аудитории проекта.
Вторая группа требований это нефункциональные требования. Иначе говоря, как будет работать система и почему именно так.
- Бизнес-правила. Они определяют почему система работать должна именно так, как написано. Это могут быть ссылки на законодательство, внутренние правила заказчика и прочие причины. Часто упускают этот раздел и получается, что некоторые системные решения выглядят нетипичным и совсем неочевидными. Например, многие табачные компании и компании, производящие алкоголь требуют постоянного доказательства того, что промо-сайтами пользуются люди, достигшие определенного возраста. Это бизнес-правило (подтверждение возраста) возникает по требованию этических комитетов заказчика, хотя и несколько противоречит маркетинговым целям и требованиям по usability.
- Внешние интерфейсы. Это не только интерфейсы пользователя, но и протоколы взаимодействия с другими системами. Например, часто сайты связаны с CRM системами. Особенности протокола взаимодействия «сайт-CRM» также относятся к нефункциональным требованиям.
- Атрибуты качества. Атрибуты касаются вопросов прозрачности взаимодействия с другими системами, целостности, устойчивости и т.п. К таким характеристикам относятся:
- легкость и простота использования (usability)
- производительность (performance)
- удобство эксплуатации и технического обслуживания (maintainability)
- надежность и устойчивость к сбоям (reliability)
- взаимодействия системы с внешним миром (interfaces)
- расширяемость (scalability)
- требования к пользовательским и программным интерфейсам (user and software interface).
- Ограничения – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, . ). Ограничения часто основываются на бизнес-правилах.
Относительно состава групп функциональных и нефункциональных требований до сих пор нет согласия. Разные авторы и эксперты могут как добавлять, так и исключать подгруппы требований. Например, часто ограничения объединяют с бизнес-правилами, а бизнес-требования объединяют с ключевыми потребностями.
Существует прекрасная методика FURPS+, позволяющая создать качественную документацию при разработке ПО сколь угодно большой сложности.
Все вышесказанное относится только к дисциплине «Управление требованиями» в рамках методологии RUP. В рамках ГОСТ и определения требований другие и сами требования разбиваются на совершенно другие группы.
Источник: foranalysts.blogspot.com