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

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

Жанры

Купить эту книгу

Бумажная

2831 ₽2399 ₽

Купить-16%

Бумажная

2831 ₽2399 ₽

Купить-16%

Рейтинг LiveLib

4,4

32 оценки

5
66%
4
22%
3
6%
2
6%
1
0%

Ваша оценка

Прочитали 40Хотят прочитать 236

Рецензии

oleghka27 июля 2011 г.
Помнится давно я впервые столкнулся с вариантами использования и немного офигел. Глядя на них меня очаровывала их простота и наглядность. Но как только я попытался сделать их сам, то мой мозг закипел. Я задался вероятно попсовым вопросом: «Как определить границы описания системы? В нашей жизни возможно бесконечное количество вариантов использования. Если пытаться полностью описать систему то описывая расширения простой авторизации я доберусь до причины смерти динозавров».
С тех пор прошло много времени и только недавно я смог ответить на этот вопрос и многие другие. Коберн в своей плохо переведенной и полной опечаток книге «Современные методы описания функциональных требований к системам» описывает методы создания вариантов использования. Рекомендуэ.
Читать далее
3
3,5K
DenisBeskov29 марта 2022 г.
Отличная методичка
Автор проделал отличную работу по формализации своего опыта разработки функциональных требований к программным системам. Ни в какой другой книге вы не найдёте более полного описания методики создания «способов применения» (use case'ов).
Юскейсы могут быть использованы:
1. Бизнес- и системными аналитиками, проектировщиками взаимодействия — для проектирования взаимодействия с системой, а также выявления и обеспечения полноты, детальности и связности функциональных требований.
2. Тест-дизайнерами и тестировщиками — как основа для разработки тестовых планов и тест-кейсов.
3. Менеджерами проектов и продуктов — как единица планирования и сдачи программного продукта.
4. Заказчиками — для получения наглядного и исчерпывающего описания системы.
5. Техническими писателями — как основа для создания руководств пользователя по системе.
В отличие от другой литературы по требованиям, эта книги предельно практична, она целиком построена вокруг рассмотрения конкретных примеров текстов требований.
Читать далее
2
1,7K
Evgeniy_Skorikov29 апреля 2019 г.
Отличный способ формализации сценариев взаимодействия. Жаль, что это не все что нужно.
В книге описан один метод написания части постановки задачи, а именно метод use case.
Что это такое? Это описание сценария взаимодействия пользователя с системой (или с бизнесом). Система при этом выступает как черный ящик (и это дает возможность разделить сложную задачу проектирования на проектирование взаимодействия и обеспечение этого взаимодействия). При этом вводятся стандарты нотации, что обеспечивает простоту прочтения в том числе не участникам, и позволяет делать некоторые проверки на полноту и соответствие целям стейкхолдера.

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

Все рецензии

Цитаты

Pepelnaya1 июля 2017 г.
Если вы пишете варианты использования как требования, имейте в виду:
это действительно требования
это не все требования
0
1K
Pepelnaya29 июня 2017 г.
Бессистемная (casual) форма в целях экономии времени упрощает шаблон варианта использования. В полной форме (fully dressed) используется полный шаблон варианта использования и схема нумерации шагов.
0
942
Pepelnaya29 июня 2017 г.
Недостаточно иметь только один шаблон. Должно быть по меньшей мере два: в свободном стиле для менее формальных проектов и строгой формы для более педантичного стиля проектирования"
0
138