apavlyut (deppkind) wrote,
apavlyut
deppkind

Требования к создаваемой системе. Практическое руководство по инжинирингу требований (черновичек).

Управление требованиями - это логистка требований.

Многие считают что управление требованиями это и есть процесс выявления требований. Нет это не так.

Требования выявляются как-то кратко если то вот:

  1. Декомпозируем так называемое ТЗ от клиента. В самом начале мы вообще пишем все хотелки в любом формтате (обычно построчно сюда выгружаем то что присылают клиенты с гордным именованием Техническое Задание) в простой список нужд.

  2. По каждой "нужде" мы пишем как мы это поняли, на языке физике решения - тут говориться про композицию элементов, тут указаны структуры данных, тут описан кусок сценария, тут клиент указывает на ограничение к архитектруе и тд и получаем фидбек что - да поняли верно.

  3. Потом каждую их этих нужд надо отметить "тегом" или меткой чтобы после отработать по теме.

  4. После по каждому тегу или метке записать все хотелки в простом формате: Я хочу _хотелку_ для того чтобы _получаемая_польза_через_хотелку_ и я вижу решение (хочу чтобы были розовые кнопочки) этого так _возможное_видение_решения_.

  5. Финальный список даем таких "требований" (система должна ДЕЛАТЬ) и ограничений (система должна делать это ТАК) - это и есть требования.


На требования пишутся уже решения, или то что назвается Техническое задание в производство.

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

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

  1. Единичность — требование описывает одну и только одну вещь.

  2. Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.

  3. Последовательность — требование не противоречит другим требованиям и полностью соответствует документации.

  4. Атомарность — требование нельзя разделить на более мелкие.

  5. Отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано.

  6. Актуальность — требование не стало устаревшим с течением времени.

  7. Выполнимость — требование может быть реализовано в рамках проекта.

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

  9. Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.

  10. Проверяемость — реализованность требования может быть проверена.

Мы пишем требования в формате JobStory:
Находясь в __контексте_ситуации-context__ (под воздействием _внешней_принуждающей_силы__) я как __стейкхолдер__ хочу что-то сделать с система имела  __возможность_как_требование__, для того чтобы сбылась моя _хотелка-userneed__.
Необходимо указать артефакт-обоснование что данное требование решит потребность.
В результате составленного списка требований мы извлекаем стейкхолдера и модели данных, которые точно так же подшиваются к требованию, а так-же извлечение алгоритма (критичного для клиента правила поведения).
На основании данной информации мы составляем базовые последовательности - воздействия пользователя в месте входа - выдача от системы в месте выхода.
После этого хотелка считается отработана и закрывается - от нее остаются только требования.
После того как у нас извлечено большинство требований мы спокойно переходим к построению архитектурного описания.
Итак, начнем с того что архитектура решения есть всегда.
Для того чтобы сделать хорошую архитектуру - необходимо иметь знания о различных видах архитектуры, и поддерживать навыки их создания и эксплуатации, чтобы "мочь" хотя бы их повторить, а тем более описать.
Также нужно использовать ТРИЗ для поиска наилучших архитектурных решений.
Архитектура системы задается интерфейсами - страницы, элементы, кнопки. Вот как раз на языке этой архитектуры описывается решение.
На архитектуру навешивается взаимодейсвтие с системой по сценариям в деталях. UseCases.
Это и есть контрольная конфигурация выпуска.
Рабочая документация - это и есть то самое Техническое Задание которое нужно реализовать, оно состоит из сценариев, экранов, структур данных, и тд.

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

Recent Posts from This Journal

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 0 comments