P
Что бы если, что-то произойдет с системой ответствнность была на заказчике
«Требования к квалификации персонала»?
Size: a a a
2020 November 03
A
Пойду я. Всем хороших выходных. 🍕
GK
Да, но это вне системы, это в зоне юрлица/компании
Это вне ПО, но внутри Системы
NK
12 ноября, в четверг вечером, Евгения Хотовицкая расскажет, что такое СЭД, кому они нужны и как правильно внедрять такие типы информационных систем.
https://sysanschool.timepad.ru/event/1472898/
https://sysanschool.timepad.ru/event/1472898/
NK
11 ноября в 6 вечера по Москве вебинар по Master Data Management от HF Labs https://us02web.zoom.us/webinar/register/8316033789536/WN_2ENx3589QDWd8IuqrSjDPQ
M
Всем привет) друзья, кто пользуется Swagger для документирования API?)
2020 November 04
NK
13 ноября однопоточная конференция для бизнес-аналитиков от портала Инфостарт https://infostart.ru/events/1315037/
ДС
я повторю, что в Stakeholder Requirements перепутаны требования стейкхолдеров и К стейкхолдерам
если они являются частью системы, а не снаружи, то требования К ним
если они являются частью системы, а не снаружи, то требования К ним
Если не возражаете хотелось бы вернуться к ослуживающему персоналу.
Я вроде понял почему они относятся к элементам системы.
Но вот требования к ним, они выражаются в StRS или SySR?
Этот вопрос исходит из определений стейкхолдеров в стандарте 25010
Я вроде понял почему они относятся к элементам системы.
Но вот требования к ним, они выражаются в StRS или SySR?
Этот вопрос исходит из определений стейкхолдеров в стандарте 25010
N
Если не возражаете хотелось бы вернуться к ослуживающему персоналу.
Я вроде понял почему они относятся к элементам системы.
Но вот требования к ним, они выражаются в StRS или SySR?
Этот вопрос исходит из определений стейкхолдеров в стандарте 25010
Я вроде понял почему они относятся к элементам системы.
Но вот требования к ним, они выражаются в StRS или SySR?
Этот вопрос исходит из определений стейкхолдеров в стандарте 25010
С пользователями/стейкхолдерами сложно. Требования к ним как к элементам системы - это требования к системе, а требования/ограничения/интересы их как стейкхолдеров - это требования стейкхолдеров. Но! не все требования стейкхолдеров должны быть учтены. Бывают стейкхолдеры требования которых должны быть игнорированы, например в системе "электронный браслет, надетый на осужденного для контроля его передвижений" у осужденного как стейкхолдера может быть требования чтобы электронный браслет не сообщал о нарушениях и это требование игнорируется инженерами, а к осужденному как к элементу системы может быть требование чтобы он его не ломал.
ДС
С пользователями/стейкхолдерами сложно. Требования к ним как к элементам системы - это требования к системе, а требования/ограничения/интересы их как стейкхолдеров - это требования стейкхолдеров. Но! не все требования стейкхолдеров должны быть учтены. Бывают стейкхолдеры требования которых должны быть игнорированы, например в системе "электронный браслет, надетый на осужденного для контроля его передвижений" у осужденного как стейкхолдера может быть требования чтобы электронный браслет не сообщал о нарушениях и это требование игнорируется инженерами, а к осужденному как к элементу системы может быть требование чтобы он его не ломал.
Так этож отрицательная потребность, это как с вандалами, думаю, это нужно учитывать.
N
Так этож отрицательная потребность, это как с вандалами, думаю, это нужно учитывать.
не обязательно, можно учитывать с отрицательным знаком, а можно и игнорировать. итоговый набор требований стейкхолдеров - это всегда результат компромисса что из их требований мы будем решать в системе и в каком объеме.
ДС
Это, вроде понятно. А про обслуживающий персонал - тот который внутри системы...с ними как быть?
N
Их требования как стейкхолдеров в одном месте, требования к ним - в другом
ДС
То есть если у них есть какие-то требования которые я должен учитывать, то же обеспечение безопасности при техническом обслуживании то это в StRS, а если не допускать к техническому обслуживанию сиситемы идиота то это в SySR?
N
лучше ближе к жизни: 1. танкист должен быть ростом не выше 1.7 м и весом не больше 80 кг. это будет требование к элементу системы
2. я хочу чтобы дисплей монитора целеуказателя не был слишком ярким, чтобы не болели глаза при долгом смотрении на него. это будет требование командира танка как стейкхолдера
2. я хочу чтобы дисплей монитора целеуказателя не был слишком ярким, чтобы не болели глаза при долгом смотрении на него. это будет требование командира танка как стейкхолдера
DC
Денис уже писал, что если стейкхолдер внутри системы - то требования к нему, если вне - то требования от него к системе.
Насчёт дисплея монитора целеуказателя - система указания и сопровождения целей может быть в данном случае рассмотрена как подсистема танка и стейкхолдер будет тут внешний - поэтому требования от него к подсистеме.
Но нужно учитывать уровень детализации требований и нахождения подсистемы в общей иерархии. На уровне танка требования к росту есть, а к дисплею - нет. Сказано только, что именно система целеуказания обеспечивает. А требования к этой системе - отдельно.
Поэтому не нужно смешивать стейкхолдеров с разных уровней. На одном уровне стейкхолдер или снаружи системы, или внутри.
Насчёт дисплея монитора целеуказателя - система указания и сопровождения целей может быть в данном случае рассмотрена как подсистема танка и стейкхолдер будет тут внешний - поэтому требования от него к подсистеме.
Но нужно учитывать уровень детализации требований и нахождения подсистемы в общей иерархии. На уровне танка требования к росту есть, а к дисплею - нет. Сказано только, что именно система целеуказания обеспечивает. А требования к этой системе - отдельно.
Поэтому не нужно смешивать стейкхолдеров с разных уровней. На одном уровне стейкхолдер или снаружи системы, или внутри.
N
Dmitriy Chernyak
Денис уже писал, что если стейкхолдер внутри системы - то требования к нему, если вне - то требования от него к системе.
Насчёт дисплея монитора целеуказателя - система указания и сопровождения целей может быть в данном случае рассмотрена как подсистема танка и стейкхолдер будет тут внешний - поэтому требования от него к подсистеме.
Но нужно учитывать уровень детализации требований и нахождения подсистемы в общей иерархии. На уровне танка требования к росту есть, а к дисплею - нет. Сказано только, что именно система целеуказания обеспечивает. А требования к этой системе - отдельно.
Поэтому не нужно смешивать стейкхолдеров с разных уровней. На одном уровне стейкхолдер или снаружи системы, или внутри.
Насчёт дисплея монитора целеуказателя - система указания и сопровождения целей может быть в данном случае рассмотрена как подсистема танка и стейкхолдер будет тут внешний - поэтому требования от него к подсистеме.
Но нужно учитывать уровень детализации требований и нахождения подсистемы в общей иерархии. На уровне танка требования к росту есть, а к дисплею - нет. Сказано только, что именно система целеуказания обеспечивает. А требования к этой системе - отдельно.
Поэтому не нужно смешивать стейкхолдеров с разных уровней. На одном уровне стейкхолдер или снаружи системы, или внутри.
целеуказатель - часть системы, и требования к целеуказателю - часть требований к системе. а командир танка - также часть системы, поэтому по отношению к системе он будет "внутренним" стейкхолдером. другое дело что деление на внешних и внутренних стейкхолдеров - это условность, и стоит ли такое деление использовать на проекте - вопрос лишь онтологии, принятой участниками для данного проекта
DC
целеуказатель - часть системы, и требования к целеуказателю - часть требований к системе. а командир танка - также часть системы, поэтому по отношению к системе он будет "внутренним" стейкхолдером. другое дело что деление на внешних и внутренних стейкхолдеров - это условность, и стоит ли такое деление использовать на проекте - вопрос лишь онтологии, принятой участниками для данного проекта
Убрав деление на внешних и внутренних возвращается проблема Дмитрия, из-за которой пошло обсуждение про стейкхолдеров - когда требования к ним, а когда от них.
Насчёт танка - при разработке систем такого уровня сложности сразу все требования от верхнеуровневых до требований к ручкам аппаратуры и яркости экрана не описываются. И подсистемы часто разрабатывают разные компании-подрядчики, при этом конечные требования часто определяются в ходе натурных испытаний с опытными образцами изделия.
С моей точки зрения, следует рассматривать сложную систему как комплекс более простых систем. И так же поступать с требованиями - различать по уровням.
Насчёт танка - при разработке систем такого уровня сложности сразу все требования от верхнеуровневых до требований к ручкам аппаратуры и яркости экрана не описываются. И подсистемы часто разрабатывают разные компании-подрядчики, при этом конечные требования часто определяются в ходе натурных испытаний с опытными образцами изделия.
С моей точки зрения, следует рассматривать сложную систему как комплекс более простых систем. И так же поступать с требованиями - различать по уровням.
N
Dmitriy Chernyak
Убрав деление на внешних и внутренних возвращается проблема Дмитрия, из-за которой пошло обсуждение про стейкхолдеров - когда требования к ним, а когда от них.
Насчёт танка - при разработке систем такого уровня сложности сразу все требования от верхнеуровневых до требований к ручкам аппаратуры и яркости экрана не описываются. И подсистемы часто разрабатывают разные компании-подрядчики, при этом конечные требования часто определяются в ходе натурных испытаний с опытными образцами изделия.
С моей точки зрения, следует рассматривать сложную систему как комплекс более простых систем. И так же поступать с требованиями - различать по уровням.
Насчёт танка - при разработке систем такого уровня сложности сразу все требования от верхнеуровневых до требований к ручкам аппаратуры и яркости экрана не описываются. И подсистемы часто разрабатывают разные компании-подрядчики, при этом конечные требования часто определяются в ходе натурных испытаний с опытными образцами изделия.
С моей точки зрения, следует рассматривать сложную систему как комплекс более простых систем. И так же поступать с требованиями - различать по уровням.
1. однако сложную систему, особенно с механическими компонентами вроде танка, часто бывает вредно рассматривать как сумму подсистем - изменение параметров одной подсистемы влечет изменения параметров других подсистем
2. проблема Дмитрия решается не введением деления на внутренних и внешних стейкхолдеров, а изменением ракурса: когда пользователь рассматривается отдельно как стейкхолдер и отдельно как рабочий элемент системы, соответственно в первом случае он источник требований к системе, а во втором - объект проектирования
2. проблема Дмитрия решается не введением деления на внутренних и внешних стейкхолдеров, а изменением ракурса: когда пользователь рассматривается отдельно как стейкхолдер и отдельно как рабочий элемент системы, соответственно в первом случае он источник требований к системе, а во втором - объект проектирования
ДС
1. однако сложную систему, особенно с механическими компонентами вроде танка, часто бывает вредно рассматривать как сумму подсистем - изменение параметров одной подсистемы влечет изменения параметров других подсистем
2. проблема Дмитрия решается не введением деления на внутренних и внешних стейкхолдеров, а изменением ракурса: когда пользователь рассматривается отдельно как стейкхолдер и отдельно как рабочий элемент системы, соответственно в первом случае он источник требований к системе, а во втором - объект проектирования
2. проблема Дмитрия решается не введением деления на внутренних и внешних стейкхолдеров, а изменением ракурса: когда пользователь рассматривается отдельно как стейкхолдер и отдельно как рабочий элемент системы, соответственно в первом случае он источник требований к системе, а во втором - объект проектирования
То есть вы предлагаете в любом случае рассмотреть потребности всех сторон, а потом в случае необходимости предъявить еще и требования к ним?
Ну как в случае с командиром танка
С одной стороны у него как у пользователя есть свои потребности, а с другой стороны со стороны системы к нему есть требования...ну тот же рост и отметка, что инструктаж он прошел...
Ну как в случае с командиром танка
С одной стороны у него как у пользователя есть свои потребности, а с другой стороны со стороны системы к нему есть требования...ну тот же рост и отметка, что инструктаж он прошел...