ДС
Они отвечают за обслуживание. Так например если проектировщик предложит ЦОД расположить на дне Марианской впадины, то обслуживающий персонал может предъявить требования по обеспечению их безопасности при техническом обслуживании
Size: a a a
2020 November 03
DB
Они отвечают за обслуживание. Так например если проектировщик предложит ЦОД расположить на дне Марианской впадины, то обслуживающий персонал может предъявить требования по обеспечению их безопасности при техническом обслуживании
на каком основании? нет такой практики
DB
ответственный за эксплуатацию != обслуживающий персонал
A
Они отвечают за обслуживание. Так например если проектировщик предложит ЦОД расположить на дне Марианской впадины, то обслуживающий персонал может предъявить требования по обеспечению их безопасности при техническом обслуживании
Приведите реальный кейс.
Я тоже впервые слышу что пользователи выставляют требования.
Вот прям чтобы фрезеровщик Петр пришёл к аналитику и требования поставил в тз
Я тоже впервые слышу что пользователи выставляют требования.
Вот прям чтобы фрезеровщик Петр пришёл к аналитику и требования поставил в тз
ДС
на каком основании? нет такой практики
В международном стандарте ISO/IEC 25010 приведена классификация стейкхолдеров:
1) пользователи, которые используют систему и получают выгоду;
2) пользователи, которые обслуживают работу системы и не получают от нее ничего, кроме работы;
3) другие люди, которые получают выгоду от системы, но не являются непосредственными пользователями системы
1) пользователи, которые используют систему и получают выгоду;
2) пользователи, которые обслуживают работу системы и не получают от нее ничего, кроме работы;
3) другие люди, которые получают выгоду от системы, но не являются непосредственными пользователями системы
ДС
Приведите реальный кейс.
Я тоже впервые слышу что пользователи выставляют требования.
Вот прям чтобы фрезеровщик Петр пришёл к аналитику и требования поставил в тз
Я тоже впервые слышу что пользователи выставляют требования.
Вот прям чтобы фрезеровщик Петр пришёл к аналитику и требования поставил в тз
Не на прямую конечно, но обычно это может выражаться в нормативных документах. В моем примере на проведение работ на глубине.
DB
В международном стандарте ISO/IEC 25010 приведена классификация стейкхолдеров:
1) пользователи, которые используют систему и получают выгоду;
2) пользователи, которые обслуживают работу системы и не получают от нее ничего, кроме работы;
3) другие люди, которые получают выгоду от системы, но не являются непосредственными пользователями системы
1) пользователи, которые используют систему и получают выгоду;
2) пользователи, которые обслуживают работу системы и не получают от нее ничего, кроме работы;
3) другие люди, которые получают выгоду от системы, но не являются непосредственными пользователями системы
я повторю, что в Stakeholder Requirements перепутаны требования стейкхолдеров и К стейкхолдерам
если они являются частью системы, а не снаружи, то требования К ним
если они являются частью системы, а не снаружи, то требования К ним
ДС
я повторю, что в Stakeholder Requirements перепутаны требования стейкхолдеров и К стейкхолдерам
если они являются частью системы, а не снаружи, то требования К ним
если они являются частью системы, а не снаружи, то требования К ним
Мне нужно немного переварить и отвечать не очень удобно. Так, что если можно пока без меня. А я потом включусь еще раз
N
А мы пишем пми и минимально достаточные требования к навыкам пользователя системой к тз.Это неверно?
DC
Nataly
А мы пишем пми и минимально достаточные требования к навыкам пользователя системой к тз.Это неверно?
Тут дело в том, что есть пользователи, а есть - персонал. И это разные люди. Персонал - внутри системы. Пользователи - снаружи.
A
Я нормально отношусь к требованиям к пользователям, пока заказчик жив и платит деньги. Вопрос в другом: как обеспечить их проверяемость? Так и не получила ответа.
DB
Я нормально отношусь к требованиям к пользователям, пока заказчик жив и платит деньги. Вопрос в другом: как обеспечить их проверяемость? Так и не получила ответа.
аттестационными испытаниями?
DC
Это как с допуском электрика к работе с электроустановками.
MK
Требования к пользователям?... хм, типа, пользователь должен соответствовать "чему"? Или типа " уметь владеть Эксель".. на каком уровне. Требования это к системам, пользователь должен исполнять свою роль в системе в рамках своих трудовых обязательств в купе с законом о трудовой деятельности. А вот к Роли можно применять требования - это уже более системная сущность, кмк
DC
Требования к пользователям?... хм, типа, пользователь должен соответствовать "чему"? Или типа " уметь владеть Эксель".. на каком уровне. Требования это к системам, пользователь должен исполнять свою роль в системе в рамках своих трудовых обязательств в купе с законом о трудовой деятельности. А вот к Роли можно применять требования - это уже более системная сущность, кмк
Должностные инструкции - вполне требования к пользователям.
MK
Да, но это вне системы, это в зоне юрлица/компании
A
аттестационными испытаниями?
Изначальный запрос был на требования к АС. Поэтому я и просила отделить одно от другого. Если я правильно понимаю, то требования к пользователям должен выдвигать бизнес и обеспечивать все аттестации тоже бизнес должен но никак не исполнитель работ по внедрению ас
DB
Изначальный запрос был на требования к АС. Поэтому я и просила отделить одно от другого. Если я правильно понимаю, то требования к пользователям должен выдвигать бизнес и обеспечивать все аттестации тоже бизнес должен но никак не исполнитель работ по внедрению ас
а при чём тут внедрение АС? АС вообще нельзя внедрить, можно только построить
A
а при чём тут внедрение АС? АС вообще нельзя внедрить, можно только построить
Ну ок, внедрение ни при чем. Как исполнитель работ проверит что требование к пользователю, зафиксированное в ТЗ, выполнено? Это может сделать только заказчик, проведя аттестацию, так? Тогда зачем включать это в тз? 🤷♀️ Включить во внутренний регламент заказчика требования по допуску к работе - да, соглашусь.
ДС
Ну ок, внедрение ни при чем. Как исполнитель работ проверит что требование к пользователю, зафиксированное в ТЗ, выполнено? Это может сделать только заказчик, проведя аттестацию, так? Тогда зачем включать это в тз? 🤷♀️ Включить во внутренний регламент заказчика требования по допуску к работе - да, соглашусь.
Что бы если, что-то произойдет с системой ответствнность была на заказчике