Документація – вступна сторінка
AyMINE – Technical doc. (in English)
abra
crm
- Модуль Контакти та адресної книги
- Системні права та налаштування CRM-модуля
- Огляд замовлень клієнтів
- Довідник
- Список і управління каталогами
- Політика конфіденційності та ділової інформації
- Надсилайте масові повідомлення відповідно до GDPR
- Патік масової електронної пошти
- Вихід і встановлення преференцій
для масової - Як коректно забути дані про людину
- Масові повідомлення електронної пошти
- Контракти, договори
- Партнер за контрактом
- Групи клієнтів
- Каталог або люди і компанії
- Контакти
- Швидко доступні контакти
sabre
hr
- Модуль персоналізації
- Цифровий кадровий архів
- Персоналізація – права користувача
- Облік кандидатів на роботу
- Посада
- Член команди – Працівник
- Огляд працівника
- Огляд власного персоналу
- Відповідальний персоналіст
- Синхронізація працівників та користувачів системи
- Трудовий договір
- modulesafety
- personalfolder
sys
- Системний модуль фреймворку AyMINE
- Клієнт
- Настроювання шлюзів для зовнішніх повідомлень
- Повідомлення із зовнішнім світом
- Правила для зовнішніх повідомлень
- Документи
- Додаткові функції з файлами
- Копіювання та переміщення файлів між об'єктами
- Презентація зображення
- Публічне посилання на документ
- Останні файли
- Дошка
- Розташування об'єкта на дошці оголошень
- Елементи клієнта
- Огляд і коментарі
- Безпека повідомлень і внутрішніх дискусій
- Переклади
- Зв'язки між об'єктами
- Типи сесій (відносин)
- Ролі та команди груп
- Користувач системи
- Адміністрація користувача
- GDPR та користувачі системи
- Безпечний вхід
- Адміністрація користувача
- Криптогаманець
- moduleclientoptions
frm
- introhelp
- introhelp_objectdetail
- AyMINE Framework
- Політика зберігання паролів
- Права користувача framework
- Модулі AyMINE
- Замки користувача
- Системні дозволи
- introhelp_deleting
- introhelp_settings
- introhelp_objectlist
- introhelp_dashboard
- introhelp_generalinfo
- introhelp_icons_dnadrhal9000_mar-22-220246-2023_caseconflict
- introhelp_icons
- Записи AyMINE
tsk
- 8D report
- Основним елементом FMEA
- FMEA
- FMEA - ймовірність виявлення
- Процес аналізу FMEA
- FMEA - ймовірність виникнення
- FMEA - оцінка тяжкості
- Модуль керування завданнями та інформаці
- Адміністрація модуля Управління завданнями
- Системні права модуля керування завданнями
- Події
- Акції, події та наради
- Персональний календар
- Журнал активності
- Згода керівника
- Чому не можна видалити деякі дані
- Область
- Область / проект / методологія
- Огляд областей
- Шаблони міток
- Управління тегами
- Мої області
- Подія
- Архівний пакет
- Кваліфікація, здібності / вміння
- Рівні компетентності та кваліфікації
- Необхідні здібності
- GDPR та облік кваліфікацій
- Право на управління кваліфікацією користувачів
- Кваліфікація користувача або контакту
- Команда проекту
- Рішення
- Об'єкти, які приймаються рішення
- Варіант прийняття рішень
- Шаблон плану / стратегії
- Визначення проекту
- Зразок запису
- Зразок ризику
- Визначення пакета
- шаблон завдання
- Активація події із завдання
- Управління відповідальністю – RACI matice
- Повідомлення про події
- Об'єкти, що відносяться до шаблонного завдання
- Події, що починаються
- Призначення нового завдання
- Обговорення
- Бізнес-подія
- Кнопки для активації події
- Події подій
- Покращення та запобіжні заходи
- Інформація
- Ключове слово
- Проведення наради
- Методики та правила
- Обов'язок
- Поняття
- Директиви та політики
- Управління змінами в проекті
- Проблеми, тікети та їх управління
- Центр обслуговування клієнтів
- Внутрішня довідка
- Об'єкти, яких стосується проблема
- Управління інцидентами, невідповідність якості
- Проект
- Графік проекту
- Команда проекту або команда до робочого процесу
- RACI-матриця для project
- Повернути план проекту за baseline
- Записи та журнали
- Записані дії
- Вимоги
- Вимоги до вступників
- Ризик
- Завдання
- Терміни викликів
- Огляд завдань
- Вплив завдання на право змінювати підключений obje
- Особисте завдання
- Член команди
- Об'єкти, які обробляються в задачі або вирішуються
- Завдання працівника
- Тест
- Типи тестів
- Попередження
- Попередження – приклад використання
- Попередження для себе
- tsktask_kanban
- moduleclientoptions
am
- amasset
- Модуль управління активами
- Процедура відбору та закупівлі
- Аналітична модель
- Постачальник продукту
- Категорія продуктів
- Властивість продукту або продукту
- Мета проекту
- Комерційна пропозиція
- Перерахувати пропозицію та замовлення
- Права доступу до пропозицій і цін
- Системний запит про стан замовлення
- Продукти та товари
- Стан продукту та його зміна
- Одиниці продуктів
- Критерії якості
- Про критерії якості продукції
- HARA продукту
Вимоги
Вимога означає завдання, яке має виконати проект у рамках реалізації. Вимоги до проекту вони отримують як завдання або виникають у проекті.
Вхідні та похідні запити
Вхідні вимоги проекту – це вимоги, які надходять із зовнішнього середовища, як правило, від замовника, замовника проекту або команди, яка розробила проект. Зазвичай їх називають користувацькими запитами.
На противагу вступним вимогам є вимоги, отримані, тобто такі, що виникли в проекті на основі аналізу того, як реалізувати проект. Виведені всі вимоги, що випливають із вступних вимог або іншого вступу до проекту. Типовим входом, який породжує вимоги, є обов'язок, методологія, винятково щось інше.
Типи запитів
Розподіл на вхідні похідні вимоги випливає з того, як виникли вимоги. Найчастіше використовується для похідних вимог більш детальний розподіл, описаний далі. Звичайно, в проекті мають сенс лише деякі типи вимог в залежності від того, що є сенсом (продуктом) проекту.
Користувацькі – ми вже описали. Це завжди вимоги до вступу.
Системні – вимоги, які стосуються всього рішення, системи (звичайно, тільки якщо в проекті створюється якась система, так буде і надалі)
Програмне забезпечення – Вимоги, які має/має виконати програмне забезпечення, створене в рамках проекту. Це не вимоги до програмного забезпечення, що використовується для реалізації проекту, а створене
Апаратні – Вимоги, які повинна виконувати електронна частина проекту, загальне обладнання
Інженерні – Вимоги, які він/вона повинна виконати для конструкцій, що виробляються або розробляються в проекті. Залежно від типу проекту це може бути розроблений механічний компонент або майбутня будівельна реалізація.
Процес – Вимоги до процесу виконання запиту. Це специфічні вимоги щодо того, як конкретна діяльність чи етап має бути реалізований, хто має брати участь у ньому тощо. Увага, не слід повторювати методологію, за якою реалізується проект. Таким чином, якщо вимога до якої-небудь процесуальної дії, наприклад, ревізії, яка дається методологією, не слід повторно писати її як процесуальну вимогу (її можна знайти як обов'язок або зразок завдання в методології).
Тести / Іспити – Вимоги до тестів, перевірки та випробування будь-яких проектних виходів. Вимоги повинні разом визначати все, що має бути зроблено для перевірки якості роботи. (За методологією він може включати в себе тести пристроїв вводу, наприклад, калібрування вимірювальних пристроїв. Але здебільшого ці вимоги контролю входів є безпосередньо частиною методології, або повинні бути процесуальними вимогами, оскільки це контроль у процесі, а не контроль виходу.)
Бізнес / Бізнес – Вимоги, що випливають з бізнес-аспекту проекту. Як правило, це вимоги, що випливають з бізнес-потреб (вони можуть стосуватися дизайну, витрат виробництва тощо). Зверніть увагу на різницю між вимогами та обов'язками. Якщо, наприклад, комерційна задача, щоб вироблений продукт мав собівартість продукції менше 10 євро, то варто розуміти, як обов'язок, якого повинен дотримуватися проект. Цей обов'язок позначається на всіх видах діяльності від планування проекту, до вибору постачальників, і не можна однозначно сказати, що він чимось наповнений.
Аналіз запитів
Якщо запити і переважно система, що розробляється, є більш складними, неможливо розробити / реалізувати проект безпосередньо на основі запитів користувача. Ці вимоги потрібно продумати, розділити, залежно від того, де, як і ким вони будуть реалізовані і часто більш детально розбирати. Такі дії називають аналізом. В рамках аналізу виникають похідні від вступних вимог.
Аналітичні відносини
- З запитів користувачів виникають системні вимоги (системні)
- Із системних вимог виникають вимоги до окремих частин системи, часто вже розділених залежно від того, яку суть має та частина системи (інженерне проектування – технологічна частина, програмне забезпечення, апаратне забезпечення).
- Вимоги до частин системи можуть ще більше розбитися на часткові, але краще постаратися уникнути цього і не створювати додатковий шар. Що стосується великої системи, то вона може потребувати
- Вимоги до тестування можуть бути як вхідними, так і похідними вимогами. Якщо вони є похідними, вони є результатом аналізу, що потрібно перевірити, щоб відповідати типово якісним критеріям.
Як документувати відносини
Зв'язки документуються шляхом зв'язування stopa / trace. Прив'язка завжди виходить з вимоги, на основі якої виникає вимога нова, похідна. Зв'язки легко утворюються за допомогою командних кнопок в деталях запиту.