Современные методы описания функциональных требований к системам

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

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

Автор проделал отличную работу по формализации своего опыта разработки функциональных требований к программным системам. Ни в какой другой книге вы не найдёте более полного описания методики создания «способов применения» (use case'ов).

Юскейсы могут быть использованы:

1. Бизнес- и системными аналитиками, проектировщиками взаимодействия — для проектирования взаимодействия с системой, а также выявления и обеспечения полноты, детальности и связности функциональных требований.

2. Тест-дизайнерами и тестировщиками — как основа для разработки тестовых планов и тест-кейсов.

3. Менеджерами проектов и продуктов — как единица планирования и сдачи программного продукта.

4. Заказчиками — для получения наглядного и исчерпывающего описания системы.

5. Техническими писателями — как основа для создания руководств пользователя по системе.

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

В книге описан один метод написания части постановки задачи, а именно метод use case. Что это такое? Это описание сценария взаимодействия пользователя с системой (или с бизнесом). Система при этом выступает как черный ящик (и это дает возможность разделить сложную задачу проектирования на проектирование взаимодействия и обеспечение этого взаимодействия). При этом вводятся стандарты нотации, что обеспечивает простоту прочтения в том числе не участникам, и позволяет делать некоторые проверки на полноту и соответствие целям стейкхолдера. В целом, после прочтения книги, к сожалению, не понятно как пройти весь путь аналитика от бизнес-проблем до формализованного ТЗ для разработчика. В книге рассказывается только часть процесса с неясно сформулированными входящими и неясно показанными дальнейшими шагами. Сам по себе use case полной простановкой для разработчика чаще всего не является. Тем не менее, это один из немногих способов записи, допускающих проверяемые требования с явными точками поиска исключений.

Книга обязательна для прочтения аналитиками, чтобы они начали писать проверяемые постановки.