Замечания: 1. Документ требований не самый важный. Есть более важные. Например "Заинтересованные лица и их интересы в отношении проекта" и "Концепция" более важны. И да, для успеха проекта формальный документ требований совершенно необязателен.
2. Четко разделяйте три процесса: создание реестра требований, управление реестром, разработка требований. Внедряться они должны именно в таком порядке. Почему то все пытаются сделать наоборот. С неизменно печальным результатом. Судя по статье вы тоже пытаетесь сначала разрабатывать требования и только потом ими управлять. Ну-ну.
3. Согласен с Денисом. "Система должна обеспечивать возможность создания, модификации или удаления записи о сотруднике." - это не атомарное требование. После декомпозиции отдельные части этого типа "требования" могут попасть в разные релизы. Вообще, недостаточная декомпозиция - основная ошибка людей пишущих требования. И крайне болезненная.
4. ГОСТ 25010 вам в помощь. Перед написанием следующей статьи рекомендую с ним ознакомиться.
5. При изменении бизнеспроцессов вы меняете не менее одного пункта: а) навыки людей б) нормы деятельности ... к) информационную систему Последнее наименее эффективно. Первое наиболее эффективно.
6. "Реакция программы на действие пользователя должна укладываться в 100 мсек в 99% случаев, не превосходить 500 мсек в любом случае,...
Этот подход устарел на сотню лет. В 1924 году Шухарт опубликовал свои работы. С тех пор хорошие специалисты пользуются картами Шухарта. И да, они ГОСТ-ированы. Ажно в 1999 году.
1. Не соглашусь. Поиск стейкхолдеров критически важен для проекта, но это просто шаг на пути к верным требованиям. Если требования можно получить без этого шага - так и надо сделать, и тогда шаг просто не нужен. Требования же краеугольны. Концепция в этом плане важнее, потому что она, де факто, является дополняющей к требованиям и да, я считаю, что без неё нельзя. Но опять же, успешный проект без концепции и с требованиями мне кажется более вероятным, чем наоборот.
2. Я реалист. Я не верю (за исключением некоторых специальных случаев) и теорема Геделя о неполноте меня поддерживает, в возможность зафиксировать полный список требований до подписания акта сдачи. Да и то. Но соглашусь с тем, что правильный подход - формировать список требований, проставлять приоритеты, и только потом вообще прорабатывать их.
Увы, я пишу довольно компактные посты from the top of my mind, тупо не всё вспоминается. Да и, конечно, не всё на эту тему я и знаю.
PS: Спасибо за комментарии. Совершенно неподъёмная тема для одного поста, но обойти нельзя и какая-то обзорная статья для этого цикла нужна. Если хватит времени и сил, то буду возвращаться к теме, обсуждая отдельные подтемы.
Замечания:
1. Документ требований не самый важный. Есть более важные. Например "Заинтересованные лица и их интересы в отношении проекта" и "Концепция" более важны. И да, для успеха проекта формальный документ требований совершенно необязателен.
2. Четко разделяйте три процесса: создание реестра требований, управление реестром, разработка требований. Внедряться они должны именно в таком порядке. Почему то все пытаются сделать наоборот. С неизменно печальным результатом. Судя по статье вы тоже пытаетесь сначала разрабатывать требования и только потом ими управлять. Ну-ну.
3. Согласен с Денисом. "Система должна обеспечивать возможность создания, модификации или удаления записи о сотруднике." - это не атомарное требование. После декомпозиции отдельные части этого типа "требования" могут попасть в разные релизы. Вообще, недостаточная декомпозиция - основная ошибка людей пишущих требования. И крайне болезненная.
4. ГОСТ 25010 вам в помощь. Перед написанием следующей статьи рекомендую с ним ознакомиться.
5. При изменении бизнеспроцессов вы меняете не менее одного пункта:
а) навыки людей
б) нормы деятельности
...
к) информационную систему
Последнее наименее эффективно. Первое наиболее эффективно.
6. "Реакция программы на действие пользователя должна укладываться в 100 мсек в 99% случаев, не превосходить 500 мсек в любом случае,...
Этот подход устарел на сотню лет. В 1924 году Шухарт опубликовал свои работы. С тех пор хорошие специалисты пользуются картами Шухарта. И да, они ГОСТ-ированы. Ажно в 1999 году.
Reply
2. Я реалист. Я не верю (за исключением некоторых специальных случаев) и теорема Геделя о неполноте меня поддерживает, в возможность зафиксировать полный список требований до подписания акта сдачи. Да и то. Но соглашусь с тем, что правильный подход - формировать список требований, проставлять приоритеты, и только потом вообще прорабатывать их.
Увы, я пишу довольно компактные посты from the top of my mind, тупо не всё вспоминается. Да и, конечно, не всё на эту тему я и знаю.
6. Это был пример.
Reply
Reply
Leave a comment