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

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

649 просмотров

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

1. Начинайте с описания бизнес-задачи

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

2. Сформулируйте требования точно и четко

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

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

3. Помните о совместимости

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

4. Не забывайте об использовании программы

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

5. Не забывайте о интерфейсах пользователя

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

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

Функциональные требования. Это документ или часть ТЗ

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

4.5. Функциональные и нефункциональные требования (Functional and Non-functional Requirements)

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

Функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции); часто функциональные требования представляют в виде сценариев (вариантов использования) Use Сase.

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

В действительности четкой границы между этими типами требований не существует. Например, пользовательские требования, касающиеся безопасности системы, можно отнести к нефункциональным. Однако при более детальном рассмотрении такое требование можно отнести к функциональным, поскольку оно порождает необходимость включения в систему средства авторизации пользователя. Поэтому, рассматривая далее эти виды требований, мы должны всегда помнить, что данная классификация в значительной степени искусственна. Классический пример (см. рисунок 4.3) высокоуровневого структурирования групп требований как требований к продукту описан в работах одного из классиков дисциплины управления требованиями – Карла Вигерса. Рисунок 4.3. Уровни требований по Вигерсу

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

• Бизнес-требования (Business Requirements) – определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемого программного обеспечения.
• Пользовательские требования (User Requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases).
• Функциональные требования (Functional Requirements) – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.

Группа нефункциональных требований (Non-Functional Requirements)

Бизнес-правила (Business Rules) – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и т.д. На самом деле, достаточно часто можно видеть недостаточное внимание такого рода требованиям со стороны сотрудников ИТ-департаментов и, в частности, технических специалистов, вовлеченных в проект. Business Rules Group дает понимание бизнес-правила, как “положения, которые определяют или ограничивают некоторые аспекты бизнеса. Они подразумевают организацию структуры бизнеса, контролируют или влияют на поведение бизнеса”. Бизнес-правила часто определяют распределение ответственности в системе, отвечая на вопрос “кто будет осуществлять конкретный вариант, сценарий использования” или диктуют появление некоторых функциональных требований. В контексте дисциплины управления проектами (уже вне проекта разработки программного обеспечения, но выполнения бизнес-проектов и бизнес-процессов) такие правила обладают высокой значимостью и, именно они, часто определяют ограничения бизнес-проектов, для автоматизации которых создается соответствующее программное обеспечение.

Внешние интерфейсы (External Interfaces) – часто подменяются “пользовательским интерфейсом”. На самом деле вопросы организации пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга при эксплуатации – все это не столько функциональные требования (к которым ошибочно приписывают иногда такие характеристики), сколько вопросы интерфейсов, так как функциональные требования связаны непосредственно с функциональностью системы, направленной на решение бизнес-потребностей.

Атрибуты качества (Quality Attributes) – описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п.

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

Системные требования (System Requirements) – иногда классифицируются как составная часть группы функциональных требований (не путайте с как таковыми “функциональными требованиями”). Описывают высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей. В общем случае, частью системы может быть персонал, выполняющий определенные функции системы, например, авторизация выполнения определенных операций с использованием программно-аппаратных подсистем.

Источник: studfile.net

Требования к разработке ПО. Почему вам нужно разбираться в них? Часть 2

Перевод второй части статьи «Why You Need to Understand Software Requirements as a Software Engineer».

Первую часть можно найти по ссылке.

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

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

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

Требования к ПО могут быть:

1. Функциональными и нефункциональными.

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

2. Производными и навязанными.

• Вытекает ли это требование из других требований?
• Это требование было явно и недвусмысленно высказано стейкхолдерами?

3. Ориентированными на продукт или на процесс его разработки.

• «Программа должна проверять права пользователя» — это требование к продукту.
• «Программа должна разрабатываться инкрементально. В ходе разработки должна использоваться непрерывная интеграция» — это требование к процессу.

4. Разной приоритетности. Для назначения приоритета может использоваться шкала с фиксированными значениями «обязательно», «крайне желательно», «желательно» и «необязательно».

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

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

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

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

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

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

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

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

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

Использование функциональных прототипов

Функциональные прототипы помогают нам:

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

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

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

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

Разработка и реализация требований

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

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

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

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

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

User Story

Разработчик часто работает в контексте данной ему пользовательской истории (user story).

User story — это изложенное простыми словами представление о взаимодействии пользователя определенного типа с программным обеспечением и его функционалом. Обычно user story излагается в следующем формате:

Как я хочу , чтобы .

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

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

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

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

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

Прежде, чем браться за реализацию user story, проверьте:

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

«Торги» по требованиям к ПО

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

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

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

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

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

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

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

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

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

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

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

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

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