Почему требования важны в разработке программного обеспечения?

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

« Рабочее программное обеспечение важнее исчерпывающей документации». Это часть Agile Manifesto.

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

Начнем с небольшого объяснения требований к разработке программного обеспечения.

Какие требования к разработке приложений?

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

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

Как определить требования к программному обеспечению

При разработке программного обеспечения может быть несколько типов требований.

Бизнес-требования

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

Что ж, если вы гордитесь тем, что делаете, и стремитесь создавать качественные продукты, вам следует заботиться о «почему» не меньше, чем о том, что и как.

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

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

Требования к программному обеспечению

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

Функциональные требования - это какие требования - для чего предназначена эта система? Как следует из названия, они описывают функциональность программного обеспечения.

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

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

Основными функциональными требованиями в этом случае будут:

1. Приложение должно иметь возможность отправлять сообщения.
2. Приложение должно поддерживать передачу файлов и мультимедиа.
3. И т.п.

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

1. Сервис должен обеспечивать полную функциональность во всех основных браузерах: Microsoft Edge, Google Chrome (две последние версии), Mozilla Firefox (две последние версии), Opera, Safari (последняя версия).
2. Мобильные макеты должны поддерживаться.
3. И т.п.

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

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

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

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

Дамоклов меч недокументированных требований

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

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

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

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

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

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

Дьявол кроется в деталях: что делает спецификацию требований к программному обеспечению хорошей?

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

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

Независимо от того, насколько технически наполнена ваша документация, существуют общие правила управления требованиями к программному обеспечению. Есть даже официальный стандарт: IEEE Std 830-1998, «Рекомендуемая практика для спецификаций требований к программному обеспечению». Вот какой должна быть хорошая SRS по стандарту:

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

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

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

• Последовательный . Внутренняя согласованность означает, что никакие утверждения в SRS не противоречат другим утверждениям в той же SRS. Это еще одна причина для включения глоссария - чтобы любой объект, процесс и спецификация в документе обозначались точным термином.

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

• Поддается проверке . Должен быть способ проверить каждое требование, которое вы включаете в SRS. Чтобы требования считались поддающимися проверке, они должны содержать измеримые и конкретные концепции.

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

• Отслеживаемый . Должно быть легко определить источник каждого требования, изложенного в SRS.

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

Требования удобны, независимо от того, специализируетесь ли вы на разработке приложений для iOS и Android или на веб-разработке. Это документация общего назначения. А то, как они выглядят, обычно зависит от разработчиков и их клиентов.

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

Заключение

Вот наиболее частые моменты, когда могут пригодиться требования к программному обеспечению:

• Понимание цели
• Оценка затрат на разработку
• Составление подробного расписания
• Расстановка приоритетов

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