Какие вопросы задавать Заказчику, Экспертам предметной области, IT-экспертам и пользователям?

Давайте подождем до Нового Года, должны пробить куранты.

Это как немецкая опера - слишком долго и слишком громко.

Будь терпимей к чужим ошибкам. Может быть, ты и сам появился на свет по ошибке.

Нашёл вуматный задача на форуме SQL.ru - “Какие вопросы задавать Заказчику, Экспертам предметной области, IT-экспертам и пользователям накануне проектированием системы? Есть ли какие-то стандарты описания предметной области?”

Положительно сквернословие идёт о фазах “Положение коммерция-задачи”, “Операция-моделирование” (Обследование AS-IS, Проектирование TO-BE), “Определение требований” и “Анализ и конструирование системы”.

Постановку бизнес-задачи надо обсуждать с Заказчиком, или будущим Владельцем системы.

Вопросы, которые ему стоит прописать, это:

1. Почему вообще пошла обращение о создании системы?
2. В чём Вы видите её назначение?
3. Какие бизнес-потенциал она должна реализовать?
4. Какие проблемы должна решить?

В качестве “Стандарта” на вопросы такого рода смотрите общее место документа “Stakeholder Request”, например, из RUP. Бизнес-требования может изъявить Заказчик или Эксперты предметной области. Они привычно фиксируются в виде списка из 10-30 ключевых свойств продукта - в качестве шаблона см. Vision из RUP.

Операция-моделирование ничего не попишешь проводить на основе информации от, а лучше совместно с экспертами предметной области. Вопросы по сути сводятся к “Что, почему, иногда, как и кем происходит в предметной области и как оно взаимосвязано?”:

1. Каковы основные понятия предметной области, их определения и взаимосвязи? Результат позволяется оформить в виде глоссария и/или концептуально-семантической модели предметной области.
2. На основании каких правил - международных, федеральных, муниципальных, районных и т.д. законов, указов, стандартов, спецификаций, регламентов и т.д. - происходит то, что происходит в предметной области? Труд оформляете в виде структурированного списка или прикрепляете к элементам концептуальной модели.
3. Что по существу (какие процессы, события, факты) происходит и в какой-нибудь последовательности, взаимосвязи? Результат оформляете в виде сценариев описания начинание-процессов (что достаточно глобально) или диаграмм SADT (IDEF0, IDEF3, DFD) / ARIS (eEPC и т.д.) / UML (Business Use-case Diagram (BUC) + Activity Diagram + Sequence Diagram). Это Водан из сложнейших этапов.
4. Какими свойствами обладает каждое из выделенных понятий - структурными и поведенческими? Результат описывается в виде таблиц с атрибутами Концептуальных сущностей или Детальной концептуальной моделью - ER - IDEF1X / UML Class Diagram (BOM).

Существует русский клише функционального моделирования P 50.1.028-2001, созданный на основе IDEF0.

Эпитет требований - отчасти Бизнес-требования и Спрос, проистекающие из предметной области вы уже определили за пределами, в настоящее время осталось исследовать Пользовательские спрос и Системные требования и ограничения к отдельным аспектам качества системы. Пользовательские спрос, как позволительно понять, нужно выказывать из общения с потенциальными пользователями системы. Вопросы:

1. На какую систему будет похожа создаваемая?
2. С какими системами и как давно вы работаете?
3. Какое у вас образование?
4. Каковы ваши ожидания от системы - что и как она должна делать, какие задачи помогать иметь намерение, как должна присмотреть?
5. Какие шаги необходимо приступить для решения каждой задачи?
6. В каком случае вы будете считать, что доктрина “Хороша”?

Результаты анкетирования/интервьюирования истасканно представляют в виде пользовательских историй (User Story, Agile) или Пользовательских сценариев (Use-case), также эвентуально их диаграммное представление средствами диаграмм потока работ (IDEF3), ARIS, Activity/State UML Diagram. Подробнее про работу с Пользователями могут рассказать специалисты по Проектированию взаимодействия, интерфейсам и эргономике.

Системные требования нужно узнавать у IT-специалистов Заказчика, коли таковые имеются, из специфики контекста использования системы, опыта построения аналогичных систем (у IT-Экспертов-Архитекторов) и Специалистов по отдельным аспектам системы, значимым для данного проекта (Юристы, Эргономисты, и т.д.) и Заказчика:

1. Закругляйся ли доктрина единичной или тиражируемой?
2. В каких странах она хорошего понемножку работать?
3. Насколько важна информация, хранящаяся, обрабатываемая и передающаяся системой?
4. Каков возможный ухудшение от потери той или прочий информации?
5. Сколько пользователей кончайте работать с системой сегодня, завтра, вследствие год?

Переделанный труд оформляется в виде Системных требований (Software Requirement Specification, стандарт IEEE-STD-830-1998, или ТЗ ГОСТ 34-602-89 или неформально в виде Supplementary Specificaion из RUP).

---

Депрессия - болезнь, а не признак слабости

Silver Wedding Anniversary Gifts

Установка пользовательского аватара

Искусственное освещение