Рубрика «функциональные требования»

Внедряем IdM. Взгляд со стороны инженера внедрения - 1

Ранее мы рассказывали о том, что такое IdM, для чего он нужен, как финансово обосновать его внедрение и т.п. Сегодня речь пойдет о том, какие подводные камни могут возникнуть при внедрении системы, и как их обойти и не набить себе множества шишек. Предположим, мы знаем, что у нас в компании есть некоторые проблемы, которые можно и хотелось бы решить с помощью IdM. Решение этих проблем в нашей компании экономически обосновано, поскольку серьезно разгрузит ИТ-подразделение, увеличит показатели эффективности компании в целом за счет экономии времени и ресурсов, необходимых для подготовки рабочего пространства новым работникам, и согласования и управления полномочиями старых. А сотрудники ИБ после внедрения IdM будут на седьмом небе от счастья, генерируя по кнопочке массу разнообразных отчетов, значительно упрощающих им жизнь при проведении аудитов безопасности, на радость себе и руководству. И вот решение принято – «Берем!».Читать полностью »

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

Речь идёт об организации готовых требований (требования уже получены и сформулированы, и теперь с ними ведётся работа). И в данном контексте требование — это описание некой функциональности (в моём случае — к сайту), на языке, понятном разработчику, заказчику, простому смертному, дающее представление о том, «как это должно работать».

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js