что такое функционально статические задания
Функциональные и нефункциональные требования: полное руководство
Точно знать, какие функции и возможности клиент хочет от приложения, довольно сложно для команды разработчиков программного обеспечения. Во избежание недоразумений заказчику и команде разработчиков программного обеспечения необходимо определить требования к проекту: как функциональные, так и нефункциональные требования для будущего приложения. В этой статье мы объясним разницу между двумя типами требований и поделимся лучшими практиками их сбора.
Что такое функциональные требования?
При разработке программного обеспечения функциональные требования определяют функции, которые должно выполнять все приложение или только один из его компонентов. Функция состоит из трех шагов: ввод данных — поведение системы — вывод данных. Он может вычислять, манипулировать данными, выполнять бизнес-процессы, устанавливать взаимодействие с пользователем или выполнять любые другие задачи.
Другими словами, функциональное требование — это то, ЧТО приложение должно или не должно делать после ввода некоторых данных.
Функциональные требования важны, поскольку они показывают разработчикам программного обеспечения, как должна вести себя система. Если система не соответствует функциональным требованиям, значит, она не работает должным образом.
Что такое нефункциональные требования?
Нефункциональные требования определяют стандарты производительности и атрибуты качества программного обеспечения, например удобство использования системы, эффективность, безопасность, масштабируемость и т.д.
В то время как функциональные требования определяют, что делает система, нефункциональные требования описывают, КАК система это делает. Например, веб-приложение должно обрабатывать более 15 миллионов пользователей без какого-либо снижения производительности, или веб-сайт не должен загружаться более 3 секунд.
Если приложение не соответствует нефункциональным требованиям, оно продолжает выполнять свои основные функции, однако не сможет обеспечить удобство для пользователя.
Нефункциональные требования важны, поскольку они помогают разработчикам программного обеспечения определять возможности и ограничения системы, которые необходимы для разработки высококачественного программного обеспечения. Следовательно, нефункциональные требования так же важны, как и функциональные требования для успешного внедрения продукта.
Почему важна разница между функциональными и нефункциональными требованиями?
Четко определенные функциональные и нефункциональные требования помогают разработчикам программного обеспечения создавать продукт, точно соответствующий потребностям клиента. Однако действительно ли необходимо знать разницу между функциональными и нефункциональными требованиями?
Основная причина знать разницу между функциональными и нефункциональными требованиями заключается в том, что они определяют объем работ по проекту. Разработчики программного обеспечения должны идти в ногу с этим объемом, чтобы разработать приложение в рамках своих временных рамок и бюджета.
Если объем работ постоянно меняется, команде разработчиков приходится продлевать сроки, и затраты на разработку возрастают. Это может привести к неблагоприятным последствиям для проекта.
Важность различения двух типов требований имеет первостепенное значение при создании MVP. Команда разработчиков и заказчик должны обсудить, какие функции и функции следует реализовать в приложении в первую очередь. Заказчик может иметь собственное видение проекта и его требований. Если заказчик решает удалить или изменить какую-либо функцию, важно понимать, что это за требование. В большинстве случаев разработчики программного обеспечения могут просто изменить нефункциональные требования, в то время как функциональные требования потребуют дополнительной работы и серьезных изменений.
Когда заказчик и поставщик разработки программного обеспечения знают разницу между функциональными и нефункциональными требованиями, это помогает им более точно определять объем работ, более точно ранжировать требования по важности, оптимизировать затраты на проект и лучше удовлетворять потребности заказчика..
Как собираются функциональные и нефункциональные требования?
В идеале, прежде чем обращаться в компанию по разработке программного обеспечения, у клиентов уже должны быть под рукой все функциональные и нефункциональные требования. Поэтому их необходимо подготовить заранее самостоятельно или попросить стороннего поставщика.
Давайте посмотрим, что включает в себя каждый тип требований.
Функциональные требования можно разделить на три группы:
Нефункциональные требования подпадают под различные категории, в том числе:
Примеры и передовой опыт
Существует множество других форматов, которые могут помочь в выполнении требований проекта. Давайте посмотрим на самые эффективные.
Истории пользователей
Обычно требования формулируются в виде пользовательских историй. Пользовательские истории — это требования, предъявляемые пользователем. Обычно они имеют форму нескольких простых предложений, имеющих один и тот же образец:
Как (пользователь) я хочу (цель), чтобы (причина).
Пример пользовательской истории: как руководитель проекта я хочу понимать прогресс команды разработки программного обеспечения, чтобы я мог сообщить о результатах генеральному директору и заинтересованным сторонам проекта.
Разработчики программного обеспечения обычно составляют требования с использованием пользовательских историй, когда они хотят донести идеи о функциях и функциях продукта до участников, не являющихся техническими специалистами.
Сценарии использования
Сценарии использования шире, чем пользовательские истории. Они включают типы пользователей и все возможные действия, которые пользователь может выполнять в приложении. В отличие от пользовательских историй, описывающих конечную цель функции, варианты использования включают последовательность шагов, ведущих к цели.
Например, если вы хотите создать приложение для управления логистикой и цепочкой поставок, разработчики программного обеспечения должны подумать о следующих ролях: продавцы, покупатели, поставщики, менеджеры, диспетчеры и многие другие.
Действия для этих ролей могут выглядеть следующим образом:
Документ со спецификацией требований к программному обеспечению
Спецификация требований к программному обеспечению ( SRS ) — это документ, на который группа разработчиков программного обеспечения полагается при создании приложения. Он включает в себя все потребности и пожелания клиентов, переведенные на понятный для команды разработчиков язык — подробное описание всех функций и возможностей продукта.
Основные разделы, которые обычно включаются в документ SRS:
Создание SRS, пользовательских примеров и пользовательских историй имеет важное значение для эффективной разработки приложений.
Однако есть и другие документы, не менее важные для успешного запуска и развития проекта.
Заключение
С помощью специализированных программных услуг компании могут создавать приложения любого типа для эффективного развития своего бизнеса. Однако для того, чтобы приложение действительно соответствовало потребностям их бизнеса, оно должно иметь подробные функциональные и нефункциональные требования.
Чтобы сформировать функциональные и нефункциональные требования, вы можете обратиться за помощью к своей компании-разработчику программного обеспечения, сторонним компаниям или сделать это самостоятельно. Хорошо продуманные требования гарантируют, что ваш партнер по разработке программного обеспечения будет полностью понимать, как разработать цифровое решение, которое полностью соответствует вашим ожиданиям и удовлетворяет потребности вашего бизнеса.
Как писать функциональные требования
Сегодня мы хотим рассказать о том, как наша продуктовая команда подходит к подготовке функциональных требований для разработчиков при создании новых продуктов и фич.
На этапе разработки может возникнуть много неожиданностей, особенно если не четко описать задачу. Разработку и функционирование одной и той же фичи разные участники команды могут понимать по-разному, поэтому продакт-менеджеры отвечают за создание продукта от разработки концепции до окончательного релиза. И важная часть этого процесса — подготовка функциональных требований.
Вопрос описания задач для разработчиков мы уже затрагивали в статье Как менеджерам научиться ставить задачи разработчикам, но в ней мы говорили больше про административные моменты, а сегодня речь пойдет скорее о технических. Это крайне важная составляющая любого бизнеса, продажи которого идут через интернет. Каждая компания, активно развивающаяся в интернет-среде, по сути превращается в бизнес по производству программного обеспечения. Но несмотря на это, компетенции в области управления требованиями, как правило, наращиваются очень медленно.
В результате мы часто видим одну и ту же картину: в отдел разработки постоянно падают задачи от разных отделов, требования в этих задачах описаны размыто, и как только что-то выпускается в бой – сразу же возвращается на доработку (ведь постановщик не до конца описал, что хотел, а разработчик сделал так, как посчитал нужным). Итог очевиден: непредсказуемые сроки выполнения задач, которые могут исчисляться месяцами, демотивированная команда, напряженные отношения внутри коллектива, недовольные клиенты, отставание от конкурентов и так далее.
Этой статьей мы хотим дать простой рецепт, который положит начало решению подобных проблем. Его можно смело рекомендовать к изучению (более того, к действию) всем, кто ставит задачи.
В разных компаниях существуют различные подходы к написанию функциональных требований, но в Retail Rocket мы остановились на этом варианте и пока не жалеем.
Функциональные требования: что это такое и зачем они нужны
Для начала давайте разберемся, что такое функциональные требования.
Функциональные требования — это постановка задачи разработчику. Все, что не указано в требованиях, делается на усмотрение разработчика, что часто расходится с представлением продакт-менеджер об ожидаемом результате. Поэтому требования должны содержать ответы на все возможные вопросы по задаче.
Функциональные требования, как правило, состоят из:
User story
User story описывает, что делает пользователь определенной роли для достижения результата, и что нужно сделать разработчику, чтобы воплотить эту задачу в жизнь.
Как правило используется шаблон:
Существуют различные примеры применения этой методологии. Например, так это работает в Trello:
В Retail Rocket мы создаем User Stories в Google Docs, используя таблицы. Это помогает упростить процесс коммуникации между различными командами, поскольку каждый может оставить комментарии и дать фидбек.
Например, так выглядит задача об отслеживании NPS для интернет-магазина:
Благодаря такой визуализации взаимодействия задача пользователя плавно и логично переходит в задачу для разработчиков. Затем наступает очередь use case’ов.
Use cases
Use cases описывает поведение пользователя по шагам при взаимодействии с разрабатываемым продуктом.
Задача пользователя — это то, что делает пользователь для достижения краткосрочных целей.
Если пользователь решает задачу на разрабатываемой странице несколькими путями, то на каждое решение должен быть написан свой use case. Например, если доступ к затрагиваемому функционалу находится на нескольких страницах, нужно написать отдельный use case на каждый способ перехода пользователя к функционалу.
Рассмотрим на примере нашей недавно выпущенной фичи — Галерее изображений и шрифтов для массовых рассылок.
Цель пользователя в том, чтобы хранить изображения в нашей платформе и использовать их для создания email-кампаний.
Примеры use case’ов:
Почему функциональные требования так важны
Используя такой формат функциональных требований, вы предоставляете команде разработки четкие инструкции. Кроме того, вы можете показать, как интерфейс выглядит со стороны клиента и как он решает его задачи. Такой подход помогает презентовать вашу идею и избежать недопониманий в команде.
Обычно постановка задачи разработчикам рождает у них множество вопросов, от ответов на которые зависит сложность и срок реализации. Для уточнения деталей им приходится тратить время на коммуникацию вместо своей прямой работы — создания классных фич и улучшения продукта. И даже в процессе коммуникации не всегда выясняются все тонкости, если постановщик задачи только отвечает на возникающие вопросы, но не проходит путь пользователя сам.
Возьмем наш пример про галерею. Если бы продакт-менеджер просто пришел с задачей создать галерею, только на одном пункте про удаление файлов разработчикам пришлось бы уточнять:
Функциональные требования помогают продакт-менеджеру продумать и четко сформулировать все сценарии взаимодействия пользователя с интерфейсов в рамках задачи.
Чем точнее поставлена задача и чем больше деталей есть у разработчиков до начала работы, тем эффективнее идет работа. Не тратится время на долгую и подчас бессмысленную коммуникацию. В этом случае все стороны в выигрыше: разработчики получают четкое понимание, что и как нужно сделать, а поставщик задачи получает выполненную работу именно в том виде, в каком он ее себе представлял.
А как вы подходите к постановке задач разработчикам?
Как написать функциональное техническое задание?
Всё просто: нормальным русским языком описывайте нужные функции в формате сценария использования.
Сценарий проще всего описывать в по схеме: [роль пользователя] может [действие], [описание целей пользователя, а также необходимых шагов и вариантов развития событий]. Оптимально — разбивать описание больших компонентов на маленькие составляющие.
В конечном итоге, пункты ТЗ должны быть объективными, просто изложенными и элементарным способом проверяемыми требованиями.
Например, вполне адекватные функциональные требования в формате сценария:
Гость должен иметь возможность зарегистрироваться на сайте, путем заполнения формы регистрации (обязательно указав своё имя, адрес электронной почты и желаемый пароль). Также гость, при наличии у него учётной записи, должен иметь возможность войти на сайт, указав в соответствующей форме свой адрес электронной почты и пароль. Это нужно для того, чтобы у него была возможность выполнять действия, требующие наличия учетной записи (например, покупать товары в интернет-магазине или оставлять комментарии).
Каждый аутентифицированный (вошедший на сайт) пользователь должен иметь возможность выйти из системы, например, чтобы исключить осуществление дальнейших действий на сайте от своего имени другими пользователями компьютера.
Примеры некорректных требований ТЗ
Субъективные требования — это все требования с оценочными прилагательными типа удобный, красивый, простой и тому подобными. Они некорректны для ТЗ, так как их никак нельзя проверить, а значит принять работу, основываясь на таких критериях просто не получится:
Форма входа в систему должна быть удобной и понятной для пользователя.
Непонятно изложенные требования — это еще один пример того, что не должно попадать в ТЗ. Такие требования формулируются так, что нельзя без должной подготовки понять о чём вообще идёт речь, например:
Пользователь должен иметь возможность реструктуризировать компоненты своего аккаунта путём декомпозиции отдельных сущностей на произвольно задаваемое число взаимно зависимых компонентов.
Субъективные требования чаще всего формулирует бизнес и маркетинг, а непонятно изложенные — ИТ и другие технические специалисты. И с тем, и с другим надо бороться, так как ТЗ должно быть руководством к действию и чек-листом, по которому можно проверить выполненную работу. А некорректные требования приводят к тому, что ТЗ для этого не может быть использовано, и не очень понятно зачем его было вообще писать, если никто им не пользуется.
Примеры корректных требований ТЗ
Еще примеры нормальных функциональных требований:
Гость на каждой странице может войти на сайт. По нажатию кнопки «войти» открывается форма для ввода логина и пароля. При корректном вводе логина и пароля пользователь входит на сайт и ему выводится уведомление об этом, дальше он работает с сайтом как аутентифицированный пользователь и ему становятся доступны дополнительные возможности. При некорректном вводе логина и/или пароля отображается уведомление о произошедшем и пользователю предлагается повторно заполнить форму
Зарегистрированный пользователь при посещении сайта должен видеть персональное приветствие «Здравствуйте, [Имя] [Отчество]!» и ссылку для выхода с сайта. При нажатии на своё имя пользователь попадает в личный кабинет, при нажатии на ссылку «выход» — выходит из системы и дальше работает с сайтом как гость.
Администратор может удалить страницу сайта. В списке страниц напротив каждой страницы есть кнопка для удалени, по нажатию на эту кнопку выводится диалог подтверждения удаления. При подтверждении страница удаляется, а при отказе — удаления не происходит.
Как правило, функциональные требования развиваются: уточняются и конкретизируются как в процессе согласования, так и в процессе разработки.
Например, описание процедуры регистрации в конечном итоге может выглядеть так:
Гость должен иметь возможность зарегистрироваться на сайте. Для этого он может с любой страницы сайта по ссылке «зарегистрироваться» перейти на страницу с формой регистрации.
Форма регистрации содержит поля: Фамилия, Имя, Адрес электронной почты, Пароль и его Подтверждение, а также флаг согласия с публичной офертой. Все поля являются обязательными для заполнения. Адрес электронной почты должен быть корректным адресом e-mail, Пароль должен быть не короче 6 символов и содержать буквы и цифры, Пароль и Подтверждение должны совпадать, флаг согласия с публичной офертой должен быть установлен. При некорректном заполнении формы выводится список ошибок при заполнении формы, а поля с ошибками подсвечиваются.
Корректно заполнив и отправив форму регистрации гость создаёт новую учётную запись, а ему на указанный адрес электронной почты отправляется письмо с уведомлением о регистрации и со ссылкой для активаци аккаунта. Для активации аккаункта пользователь должен перейти по полученной ссылке, после чего он будет автоматически аутентифицирован (войдёт на сайт).
Если пользователь не получил ссылку для активации, то он может запросить её повторную отправку, просто указав свой адрес электронной почты, в этом случае ему должно быть также выведено сообщение с рекомендацией поискать письмо в спаме.
Вход при помощи формы входа до активации учётной записи невозможен, в случае попытки входа или регистрации с реквизитами доступа неактивной учетной записи пользователю должно быть выведено уведомление о том, что учетная запись неактивна, а также предложение повторно отправить письмо со ссылкой для активации аккаунта.
Если пользователь не активирует свою учётную запись в течение одной недели, то она будет удалена из базы данных.
В случае перехода по ссылке «зарегистрироваться» уже зарегистрированным и аутентифицированным пользователем форма регистрации не должна показываться, а должна быть осуществлена переадресация на страницу профиля текущего пользователя с уведомлением: «Вы уже зарегистрированы и уже вошли на сайт».
Такая подробная спецификация пусть и не очень проста в написании, но зато достаточно точно описывает требования к итоговой логике работы компонента, что позволяет без проблем провести сдачу-приёмку выполненных работ.
Разумеется, что в написании любой спецификации рационально соблюдать баланс между полнотой / детализированностью требований и простотой понимания / написания самого ТЗ.
Избыточная детализация времязатратна и делает ТЗ перегруженным очевидными деталями, но недостаточная детализация приводит к тому, что какие-то важные требования не будут описаны и могут не быть реализованы. Задача бизнес-аналитика, составляющего ТЗ, как раз и заключается в том, чтобы найти баланс между полнотой изложения и лаконичностью.
Уровень необходимой детализации ТЗ обычно зависит от компетентности специалистов и от корпоративной культуры. Профессионалам можно ставить высокоуровневые задачи и они их решат адекватным способом, а начинающим специалистам лучше более полно детализировать задачи, декомпозировать их и формулировать критерии приёмки. С корпоративной культурой всё несколько сложнее, например: чёткое следование регламентам и формализация — это отличный фактор для процессной деятельности, но в проектной / продуктовой разработке это несколько замедляет работу, так как требует более формальной и детализированной постановки задач.
Функциональное техническое задание — более простой и понятный способ описания требований, нежели классическое ТЗ.
Ликбез по техническому заданию
Польза: получите знания о том, что такое ТЗ и как его составить. Обогатите словарный запас словами: концептуальная модель, data flow, mind card, user flow. use cases, wireframes, ER-model, client-server, API.
Для кого: начинающим разработчикам и желающим чтобы их поняли (заказчикам, стартапам и менеджерам).
Время чтения: 7 минут.
Отправная точка — требования
Хочу пирожное, потом морожное!
Вовка в тридевятом царстве
Существует распространенное заблуждение, что достаточно сказать: “Нужно приложение для музея/кошки/завода” и сразу станет понятно, что вам необходимо.
К сожалению, все не так просто. Представьте, что вам нужно построить дом. Вы идете к строителю, и он приступает к работе. Вы не предоставили ему ни чертежей, ни участка, даже не сказали какого цвета должен быть забор. Но дали на все про все полгода и значительную сумму денег.
Жутко правда? Бюджет уже потрачен и срок истек.
Чтобы такого не произошло все требования к продукту фиксируют, это и есть то, с чего начинается любая разработка.
Удобный вид требований — ТЗ
Замесить и нарубить!
Вовка в тридевятом царстве
Хорошо. Будут требования. Теперь вас точно поймут разработчики. Но тут возникает подводный камень №1: человечество пока не научилось читать мысли. Поэтому нужно в каком-то виде передать информацию и лучший для этого способ — Техническое задание.
Его также называют ТЗ, SRS, PRD — все это названия документа, в котором в правильной форме зафиксированы требования к продукту.
Рецепт грамотного ТЗ
Техническое задание для разработчиков это своеобразный рецепт приготовления успешного продукта. Успешный продукт — тот, который легко поддерживать, можно развивать и менять, он не развалиться при смене разработчика и приносит прибыль в любом ее виде. Вы хотите, чтобы ваш проект был полноценным? Отлично. Напишите для этого хороший рецепт. Классическими ингредиентами (по международному стандарту IEEE-830) служат:
Ниже я разберу подробно каждый из пунктов. Для тех, кому не хочется подробно разобраться, оставляю ссылку на международный стандарт c шаблоном технического задания: ссылка на документ.
Концептуальная модель
В этот пункт входит краткое описание продукта, в нем отражается цель проекта и его отличительные черты.
Например: “Приложение для знакомств, в котором можно смотреть короткие видео в профилях пользователей и общаться в чате”.Также не помешает сказать пару слов об аудитории продукта, так команда проекта сможет понять его особенности и дать вам несколько полезных советов. Расскажите о ее возрасте, характере и территориальном расположении, каких-то особенностях, которые должны отразиться на проекте.
Например: “Это молодые люди, выезжающие за рубеж для отдыха и интересующиеся общением за пределами языкового барьера, которые любят снимать фото и видео”.
Стоит рассказать о типах пользователей и их ключевых отличиях.
Например: “В приложении должны быть обычные пользователи и модераторы, которые получают жалобы от пользователей на контент или профили. Модераторы могут просматривать чат обычных пользователей после жалобы и заблокировать в сервисе нарушающий правила аккаунт”.
И в завершении расскажите о компонентах вашего продукта.
Например: панель администратора, которую используют модераторы; мобильное приложение, которое использует пользователь, чтобы зарегистрироваться, добавить контент, поучаствовать в чате и т.д.
Высшим пилотажем будет сделать так называемый data flow или контекстную диаграмму, в которой будет отражено как пользователи взаимодействуют с продуктом, его компонентами и между собой.
Функциональная карта
Функциональная карта отображает общую концепцию проекта с уровнем детализации необходимым для того, чтобы оценить объем работ, расставить приоритеты.В традиционном формате такая карта напоминает карту сайта. Но удобнее всего ее отобразить в виде mind card (майнд карт, интеллект карт). Часто менеджеры рисуют на совещании на доске или листе бумаги слова и между ними связи, так вот, это и есть майнд карта. Это можно сделать удобно в бесплатных сервисах (coggle, draw.io и mindmeister) или просто в Office Word.
Очень важно отразить в функциональной карте все пользовательские особенности. В первом приближении это просто набор функций продукта.
Например: “В приложении должна быть регистрация по почте, создание и заполнение данных профиля,, возможность загрузить и отредактировать фото и видео, список аккаунтов других пользователей с различными типами фильтров, текстовый чат, обращение к службе поддержки.
Путь пользователя
Так называемый user flow или путь пользователя, это последовательный список действий или экранов, по которым может переходить пользователь в процессе взаимодействия с продуктом. Опишите, как в вашем представлении будет взаимодействовать с продуктом пользователь. Очень удобно это можно сделать также майнд картой или просто списком действий.
Например: “Пользователь заходит в приложение, чтобы познакомиться с сверстниками. Он заполняет свой профиль данными и загружает фото и видео. Затем пользователь заходит в ленту и фильтрует ее по каким-либо критериям. В качестве результата он получает список релевантных профилей, может посмотреть их и написать другому пользователю в чате.
Путь пользователя — это общий алгоритм работы с продуктом. Также существует еще use cases (варианты использования) — это детализация user flow. В случае мобильного приложения для знакомств вы создали путь пользователя по экранам, а затем описываете, что пользователь может сделать на каждом экране.
Например: на экране регистрации пользователь может:
перейти на экран авторизациизарегистрироваться через соцсети (Facebook, Twitter)может ввести почту, пароль, затем его повторить и подтвердить регистрацию в письме, пришедшем на почту.
Пользовательский интерфейс
Продукт должен мало того что работать, так еще и приятно выглядеть. Немного отойдем от тематики приложений, чтобы не заставлять вас их скачивать для ознакомления. Лучше посмотрим на симпатичные сайты:
Опишите в общем виде, каким вы хотите видеть свой продукт, какие у него должны быть цвета, какие элементы использоваться, какую вы хотите анимацию и т.д. Если у вас есть фирменный стиль или брендбук, отлично, сошлитесь на них.
Дизайнеры скажут вам большое спасибо, если вы укажите стиль дизайна интерфейса, например flat design или material design.
Высшим пилотажем будет добавить wireframes (вайрфреймы) — прототипы интерфейса продукта в виде приближенных схем.
Программные интерфейсы
Этот раздел для специалистов. Если вы уверены в своих силах, то продолжайте чтение.В лучшем техническом задании также описывается архитектура продукта, то есть то, из каких программных компонентов он состоит. В случае клиент-серверного приложения для знакомств сервис разбивается на часть сервера, которая хранит данные и обрабатывает их, производит какие-то логические операции и часть клиента, который отображает данные.
Сервер декомпозируется на модули: базы данных, аутентификации, чата и т.д.Клиент связывается с сервером через API (интерфейсы передачи данных), стоит указать его тип (REST, WEB, RPC и т.д.) и описать методы, ответы и обработку ошибок.
Данные обычно хранятся в базе данных в виде специальных структур, чаще всего таблиц (для реляционных БД) и json структур (для нереляционных). Разработчики скажут вам огромное спасибо, если в техническом задании вы укажите сущности базы данных (ER-модели) и опишите хранимые поля, с указанием их типов данных (string, int и т.д), ключей (primary, foreign), обязательности (required) и пустого значения (nullable).
Нефункциональные требования
Это общие требования к продукту. Их можно разделить на требования к техническому обеспечению, требования безопасности и требования к производительности.В требованиях к техническому обеспечению указывают пожелания к устройствам и операционной среде, например для приложения знакомств это Android 7.0+ и JDK 8+, iOS 11.0+ и Swift 4.2.
В требованиях к безопасности можно указать, что передача данных в чате должна осуществлять с помощью шифрования SHA-1 и что при регистрации сложность пароля должна быть не менее 8 бит.В требованиях к производительности говорится о связи компонентов и отказоустойчивости, например стоит указать, что таймаут на чтение сообщения в чате не более 1 с и что приложении частично хранит кеш и может ограниченное время работать в автономном режиме.