Работаем с упущенными требованиями

Что имеется ввиду под упущенными требованиями?

Чаще всего под ними подразумеваются подразумеваемые и неявные требования:

• подразумеваемые требования - то, что заказчики ожидают получить, явно не выражая. Аналогично в случае аналитика: что очевидно для аналитика может быть не очевидно для других участников команды: разработчиков, тестировщиков.
• неявные требования - те, что необходимы по причине другого требования, но явно не сформулированы. Фактически "зависимые" требования, которые идут в сцепке с явно сформулированными.

В чем причина появления упущенных требований?

• Недостаточное значение бизнес-процессов заказчика (AS-IS)
• Неполный список stakeholder-ов, участвующих в процесс обсуждения требований;
• Недостаточное документирование результатов обсуждение требований (и открытых вопросов)
• Несоблюдение системного подхода к сбору, анализу и документированию требований

Примеры подразумеваемых требований:

1. Соответствие корпоративным стандартам (безопасность, отказоустойчивость, производительность и тд)
2. Соответствие отраслевым стандартам и законам (ведение деятельности, бух.учет, подготовка и сдача отчетности и тд)
3. Базовые функции, присутствующие у аналогичных продуктов (в компании, на рынке)
4. Понятный и удобный пользовательский интерфейс (область UI / UX)
5. Интеграция с другими ИС для получения или отправки данных, если это требуется по процессу
6. Поддержка функционала, реализованного в предыдущих версиях ИС (или в её предшественниках)
7. Возможность дальнейшего масштабирования (рост трафика, пользователей, нагрузки и другое)

Здесь могли быть требования...

Как выявлять упущенные требования?

• Раскладывайте требования высокого уровня на простейшие составляющие - это позволит в деталях понять, чего же именно запрашивают пользователи. Из-за неясности требований высокого уровня возможно несовпадение представлений заказчика о продукте и тем, как это представляет аналитик и разработка.
• Убедитесь, что все классы пользователей предоставили вам информацию и что у каждого пользовательского требования есть по крайней мере один класс пользователей, который выиграет от реализации этого требования.
• Используйте разнообразные формы представления информации о требованиях. Трудно прочитать большой объем текста и заметить, что чего-то не хватает. Применение нескольких форм (графики, таблицы, схемы, наброски интерфейса) позволяется посмотреть на описываемый процесс с разных точек зрения и увидеть пробелы в требованиях.
• Подробно документируйте (через трассировку требований), через какие функциональные требования реализуются пользовательские требования, бизнес требования и бизнес-правила - это позволит быть уверенным, что описана вся необходимая функциональность.
• Создайте контрольный список стандартных функциональных областей, которые надо учитывать в своих проектах: логирование, отчетность, ролевая модель и правила доступа, администрирование, печать, версионность, поддержка пользователей, инструкции и тд.
• Проверяйте пограничные значения (чаще всего это любые разветвление в процессе или логике). Если это не оговорено, значит, отсутствует соответствующее требование или как минимум неудовлетворительно задокументировано.
• Создайте модель данных. Все сущности данных, с которыми работает система, должны иметь соответствующую функциональность для их создания, чтения из внешних источников, обновления текущих значений и/или удаления. Часто эти четыре стандартные операции обозначают акронимом CRUD (Create, Read, Update, Delete - создание, чтение, обновление, удаление), иногда CRUDL (List - чтение списком)
• Документируйте и рассылайте участникам протоколы встреч с указанием открытых вопросов для дальнейшего анализа и проработки. Это позволит предотвратить забывание требований, устранит разночтение в их понимании у участников и проинформирует отсутствующих о достигнутых договоренностях.
• Проверяйте полноту описания требований со сложной булевой логикой (несколько операторов «И», «ИЛИ» и «НЕ»). Если для комбинации логических условий не определено соответствующее функциональное требование, приходится догадываться, как же должна действовать система. Не забываем добавлять условие «Иначе». Для описания сложных логик можно использовать таблицы и деревья решений.

Полезные статьи на канале:

• Как понять аналитику, что сбор требований завершен?
• Чек лист то, что в проекте проблема с требованиями

Больше другой полезной информации в ТГ канале: https://t.me/all_for_analyse