Читать книгу Бизнес-анализ от а до я: гид для начинающих - - Страница 10

Есть бизнес-требование, которое звучит как «Профиль компании должен содержать информацию о кредитоспособности компании» – то есть требование от бизнеса и клиента довольно прозрачно. При любых коммерческих, торговых операциях между компаниями, компания продавец при предоставлении товаров в рассрочку, должна проверять и быть уверенной в платежеспособности компании-покупателя. Для данного бизнес-требования я, возможно, напишу 10-20 функциональных требований, но здесь опишу только одно.

На основании данного бизнес-требования я создаю функциональное требование «ФТ-СУК-КР-1. Система должна предоставлять на главной странице профиля компании обобщенную информацию о кредитном статусе клиента включая следующую информацию: кредитный статус, кредитный рейтинг, текущие кредитные условия». Что это за «ФТ-СУК-КР-1»? Это уникальный идентификатор требования, который в дальнейшем будет использоваться для матрицы связей/отслеживания и для упоминания в любых других связанных с этим требованием документах. Так же правила создания идентификатора создаются таким образом, чтобы, зная их можно было легко определить, о чем это требование. «ФТ» – значит Функциональное Требование. «СУК» – название системы куда входит требование «Система Управления Клиентами». «КР» – название модуля/компонента внутри системы «Кредитный модуль». И конечно же номер требования. Текстовка требования может изменяться, но идентификатор – никогда. Само требование состоит из следующих важных пунктов: 1) «Система» – это простое, но важное слово, которое 100 процентов подтверждает, что именно наша система должна поддержать определенную функциональность. 2) «должна» – тоже ключевое слово в требовании, которое очень явно говорит, что система именно «должна» поддержать функциональность, а не «может» или «будет» предоставлять что-то. Это важно – всего одно предложение, но оно может стоить десятки тысяч долларов например, и малейшая неясность в написании может быть использована как заказчиком, так и исполнителем. Например, использование словосочетания «Система может…» – может трактоваться как не обязательная часть функциональности системы и читаться как «ну может система будет выполнять такую-то функцию, а возможно и не может». 3) «предоставлять информацию на странице…» – описываем «местоположение» и «что», чтобы точно определить, где будет находиться функция. 4) «следующую информацию:…» и в заключение я определяю какую точно информацию мы должны предоставлять, а именно какие параметры. Есть вероятность, что какие-то еще параметры будут добавлены или нет, если это будет доступно с точки зрения проектного контекста. Но вот эти три упомянутых параметры точно будут присутствовать. Ну вот функциональное требование и готово! Возможно, у вас возник вопрос «а откуда и как ты всего лишь на основании короткого и общего бизнес-требования решил написать такое функциональное требование? Откуда детали про где и что?». Первая часть ответа – понимание как, где и что частично появляется у меня как раз на основании моего доменного опыта, о котором я упоминал ранее в этой книге. Я много лет работал в бизнесе и был именно конечным пользователем множества бизнес-систем, которые почти всегда содержат примерно одинаковый набор параметров и функций (и как я говорил, это был один из критериев, по которым меня рассматривали на эту работу без ИТ опыта). Соответственно в нашей системе для клиента я предлагаю наиболее распространенный подход в данном случае к информации о платежо/кредитоспособности клиента. Вторая часть ответа – именно сейчас я описываю исключительно действия, связанные с документированием требований. На самом деле, естественно, существуют еще коммуникационные действия – такие, как обсуждение требований, обновлений требований и их подписание. Т.е. для моего только что написанного функционального требования я НЕ начну тут же документировать дизайн. Сначала будет внутреннее рассмотрение с моим ведущим БА, возможные правки, а потом будет обсуждение с клиентом и возможные правки от него и потом подписание требования. И только потом в я начинаю документировать дизайн к этому функциональному требованию.