Системалар үчүн функционалдык талаптарды сүрөттөөнүн заманбап ыкмалары. Алистер Коберн. Китеп жана толуктоолорду карап чыгуу

Китепте проблемалык билдирүүнүн бир бөлүгүн жазуунун бир ыкмасы, тактап айтканда Use case ыкмасы сүрөттөлөт.

Бул эмне? Бул система менен (же бизнес менен) колдонуучунун өз ара аракеттенүү сценарийинин сүрөттөлүшү. Бул учурда система кара кутучанын ролун аткарат (жана бул татаал долбоорлоо тапшырмасын өз ара аракеттенүүнү долбоорлоого жана бул өз ара аракеттенүүнү камсыз кылууга бөлүүгө мүмкүндүк берет). Ошону менен бирге, окуунун жеңилдигин, анын ичинде катышуучу эместер үчүн да камсыз кылуучу жана кызыкдар тараптардын максаттарына толуктугун жана шайкештигин айрым текшерүүгө мүмкүндүк берүүчү белгилер стандарттары киргизилет.

Мисал колдонуңуз

Электрондук почта аркылуу сайттагы авторизациянын мисалын колдонуу менен сценарий кандай болот:

(Система) Жеке аккаунтуңузга кирүү үчүн веб-сайтка кириңиз. ~~ (деңиз деңгээли)

Контекст: Уруксатсыз кардар сайтка кирип, сайт аны таанып, ал үчүн жеке маалыматты көрсөтөт: серептөө таржымалы, сатып алуу таржымалы, бонустук упайлардын учурдагы саны ж.б., логин катары электрондук почтаны колдонуу. 
деңгээл: колдонуучунун максаты
Негизги каарман: кардар (биздин онлайн дүкөндүн коногу)
Колдонуу чөйрөсү: Интернет-дүкөндүн веб-сайты менен кардарлардын өз ара аракеттенүүсү
Кызыкдар тараптар жана кызыкчылыктар:

  • маркетолог жеке каттарды көбүрөөк камтуу үчүн сайтка келгендердин максималдуу санын аныктоону каалайт,
  • коопсуздук боюнча адис зыяратчынын жеке маалыматтарына уруксатсыз кирүү учурлары, анын ичинде бир аккаунттун сырсөзүн табуу же начар сырсөзү бар каттоо эсебин издөө аракеттери болбошун камсыз кылууну каалайт,
  • чабуулчу жабырлануучунун бонустарына жетүүнү каалайт,
  • атаандаштар өнүмдөр боюнча терс сын-пикирлерди калтыргысы келет,
  • Ботнет дүкөндүн кардарлар базасын алууну каалайт жана сайтты иштебей турган кылуу үчүн чабуулду колдонушат.

Алдын ала шарттар: зыяратчыга уруксат берилбеши керек.
Минималдуу кепилдиктер: келген адам авторизациялоо аракети ийгиликтүү же ийгиликсиз болгонун билет.
Ийгиликтин кепилдиктери: зыяратчы ыйгарым укуктуу.

Негизги сценарий:

  1. Кардар авторизацияны баштайт.
  2. Система кардар авторизацияланбаганын ырастайт жана “No23 коопсуздук эрежеси” ылайык берилген сессиядан (бир нече аккаунттар үчүн алсыз сырсөздү издөө) ийгиликсиз авторизациялоо аракеттеринин санынан ашпайт.
  3. Система авторизациялоо аракеттеринин саны үчүн эсептегичти көбөйтөт.
  4. Система кардарга авторизация формасын көрсөтөт.
  5. кардар өзүнүн электрондук почтасын жана паролду киргизет.
  6. Система системада ушундай электрондук почтасы бар кардардын бар экендигин жана сырсөз дал келгенин жана бул эсепке кирүү аракеттеринин саны “No24 коопсуздук эрежеси” боюнча ашпаганын тастыктайт.
  7. Система кардарга уруксат берет, серептөө таржымалын жана ушул сеанстын корзинасын ушул кардар эсебинин акыркы сессиясы менен кошот.
  8. Система авторизация ийгиликтүү билдирүүсүн көрсөтөт жана кардар авторизациялоо үчүн үзгүлтүккө учураган скрипт кадамына өтөт. Бул учурда, баракчадагы маалыматтар жеке эсептин маалыматтарын эске алуу менен кайра жүктөлөт.

Кеңейтүүлөр:
2.а. кардар мурунтан эле ыйгарым укуктуу:
 2.a.1. Система кардарга мурда аткарылган авторизациянын фактысы жөнүндө кабарлайт жана сценарийди үзгүлтүккө учуратууну же 4-кадамга өтүүнү сунуштайт, ал эми 6-кадам ийгиликтүү аяктаса, анда 7-кадам тактоо менен аткарылат:
 2.a.7. Система кардарды эски эсеп боюнча деакторизациялайт, жаңы эсеп боюнча кардарга авторизациялайт, ошол эле учурда бул өз ара аракеттенүү сессиясынын серептөө таржымалы жана арабасы эски аккаунтта калып, жаңысына өткөрүлбөйт. Андан кийин, 8-кадамга өтүңүз.
2.b "Коопсуздук эрежеси № 23" боюнча уруксат берүү аракеттеринин саны босогодон ашты:
 2.b.1 4-кадамга өтүңүз, авторизация формасында кошумча түрдө captcha көрсөтүлөт
 2.b.6 Система туура каптча киргизүүнү ырастайт
    2.b.6.1 Captcha туура эмес киргизилген:
      2.b.6.1.1. система бул эсеп үчүн да ийгиликсиз авторизация аракеттеринин эсептегичтерин көбөйтөт
      2.b.6.1.2. система ката жөнүндө билдирүүнү көрсөтөт жана 2-кадамга кайтып келет
6.а. Бул электрондук почта менен эч кандай эсеп табылган жок:
 6.a.1 Система ката жөнүндө билдирүүнү көрсөтөт жана 2-кадамга өтүүнү же "Колдонуучуну каттоо" сценарийине өтүүнү жана киргизилген электрондук почтаны сактоону сунуштайт,
6.b. Бул электрондук почта менен каттоо эсебинин сырсөзү киргизилгенге дал келбейт:
 6.b.1 Система бул эсепке ийгиликсиз кирүү аракеттерин эсептегичти көбөйтөт.
 6.b.2 Система ката жөнүндө билдирүүнү көрсөтөт жана "Сырсөздү калыбына келтирүү" сценарийине өтүүнү же 2-кадамга өтүүнү сунуштайт.
6.c: Бул аккаунтка кирүү аракетинин эсептегичи "Коопсуздук эрежеси №24" чегинен ашып кетти.
 6.c.1 Система эсепке кирүү X мүнөткө бөгөт коюу жөнүндө билдирүүнү көрсөтөт жана 2-кадамга өтөт.

эмне сонун

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

Кара куту системасы менен иштөө, иштеп чыгууну жана кардар менен макулдашууну автоматташтырууну ишке ашыруу ыкмаларынан бөлүүгө мүмкүндүк берет.

Бул аналитиктин жолунун бир бөлүгү, колдонууга ыңгайлуулуктун негизги бөлүктөрүнүн бири. Колдонуучунун сценарийи анын кыймылынын негизги жолдорун аныктайт, бул дизайнер менен кардар үчүн тандоо эркиндигин кыйла азайтат жана дизайнды иштеп чыгуунун ылдамдыгын жогорулатууга жардам берет.

Сүрөттөмөдөгү өз ара аракеттенүүнүн ар бир кадамынан өзгөчөлүктөр аныкталган жер мага абдан жакты. Толук IT системасы кандайдыр бир өзгөчөлүктү башкарууну камсыз кылышы керек, кээ бирлери кол менен, кээ бирлери автоматтык түрдө (жогорку мисалдагыдай).

Тажрыйба көрсөткөндөй, ойлонулбаган өзгөчө кырдаалды чечүү оңой эле системаны өтө ыңгайсыз системага айландырышы мүмкүн. Совет доорунда кандайдыр бир чечимди кабыл алуу үчүн ар кайсы кызматтардан бир нече уруксат алуу керек болгон окуя эсимде, ал эми акыркы кызматтын айтканы кандай оор, бирок сиздин арызыңыз туура эмес аталышта же башка ката пунктуация, баарын кайра жасап, баарын кайра координациялоо.

Мен өзгөчө кырдаалдар үчүн ойлонулбаган системанын иштөө логикасы системаны олуттуу түрдө кайра иштетүүнү талап кылган кырдаалдарга көп жолугам. Ушундан улам, талдоочунун ишинин негизги үлүшү өзгөчө кырдаалдарды чечүүгө жумшалат.

Диаграммалардан айырмаланып, тексттик белгилер көбүрөөк өзгөчөлүктөрдү аныктоого жана камтууга мүмкүндүк берет.

Практикадан методго кошумча

Колдонуу окуясы колдонуучунун окуясынан айырмаланып, билдирүүнүн өз алдынча артыкчылыктуу бөлүгү эмес.

Жогорудагы сценарийде “6.a. Бул электрондук почта менен эч кандай эсеп табылган жок." жана кийинки кадам "6.a.1 Система ката жөнүндө билдирүүнү көрсөтүп, 2-кадамга өтөт." Көшөгө артында кандай терс көрүнүштөр калды? Кардар үчүн кандайдыр бир кайтаруу, ал маалыматтарды киргизүү боюнча жасаган бардык жумуштары полигонго ыргытылганына барабар. (Бул сценарийде көрүнбөйт!) Эмне кылса болот? Мындай болбошу үчүн скрипти кайра түзүңүз. Муну жасоого болобу? Мисал катары, Google авторизация скриптин карап көрө аласыз.

Сценарийди оптималдаштыруу

Китепте формалдаштыруу жөнүндө сөз болот, бирок мындай сценарийлерди оптималдаштыруу ыкмалары жөнүндө аз айтылат.

Бирок сценарийлерди оптималдаштыруу жолу менен ыкманы бекемдөөгө болот жана колдонуу учурун формалдаштыруу ыкмасы муну жасоого мүмкүндүк берет. Тактап айтканда, сиз пайда болгон ар бир өзгөчөлүк жөнүндө ойлонуп, себебин аныктап, өзгөчө кырдаалдан кутулуу же кардар сапарын азайтуу үчүн скриптти кайра курушуңуз керек.

Интернет-дүкөндөн буйрутма берүүдө жеткирүү шаарын киргизишиңиз керек. Дүкөн ал жакка жеткирбей койгондуктан, өлчөмдөгү чектөөлөрдөн же тиешелүү кампада товардын жоктугунан кардар тандаган шаарга товар жеткире албай калышы мүмкүн.

Эгерде биз жөн гана каттоо стадиясында өз ара аракеттенүү сценарийин сүрөттөп берсек, анда биз "кардарга жеткирүү мүмкүн эместигин билдирип, шаарды же арабанын мазмунун өзгөртүүнү сунуштайбыз" деп жаза алабыз (жана көптөгөн башталгыч аналитиктер ошол жерде токтойт). Бирок мындай учурлар көп болсо, анда сценарийди оптималдаштырса болот.

Эң биринчи биз жеткире ала турган шаарды тандап алышыңыз керек. Муну качан кылуу керек? Веб-сайтта продуктуну тандоодон мурун (түшүндүрүү менен IP аркылуу шаарды автоматтык түрдө аныктоо).

Экинчиден, биз кардарга жеткире ала турган товарларды гана тандоо мүмкүнчүлүгүн беришибиз керек. Муну качан кылуу керек? тандоо учурда - продукт плиткасы жана продукт карта боюнча.

Бул эки өзгөртүү бул өзгөчөлүктү жоюу үчүн узак жолго барат.

Өлчөөлөргө жана метрикаларга талаптар

Өзгөчө кырдаалды иштетүүнү минималдаштыруу тапшырмасын карап жатканда, сиз отчеттук тапшырманы орното аласыз (колдонуу учуру сүрөттөлгөн эмес). Канча өзгөчөлүктөр болгон, алар кандай учурларда болгон, ошондой эле канча келген сценарий ийгиликтүү өттү.

Бирок аттиң. Тажрыйба көрсөткөндөй, бул формадагы сценарийлер үчүн отчеттуулук талаптары жетишсиз, негизинен колдонуу түрүндө эмес сүрөттөлгөн процесстер үчүн отчеттуулук талаптарын эске алуу зарыл.

Usability мүмкүнчүлүгү

Биздин практикада биз субъекттердин спецификалык атрибуттарынын сыпаттамасы жана кардар үчүн чечим кабыл алуусу үчүн маалыматтардын сыпаттамасы менен колдонуу учурунун сүрөттөмө формасын кеңейттик, бул кийинки колдонууга ыңгайлуулукту жогорулатат.

Ыкчам дизайн үчүн биз киргизүү бөлүмүн коштук - маалыматтарды көрсөтүү.

Авторизациясы бар сценарийде, бул кардар системада ыйгарым укуктуу болгон факт. Эгерде кардар алдын ала уруксат алган болсо, анда ийгиликтүү авторизациядан кийин навигация таржымалын жана арабаны жаңы эсепке которуу жөнүндө эскертүү көрсөтүлөт.

Жалпысынан алганда, бул кардар үчүн зарыл болгон маалыматтын дисплейи, ал сценарий боюнча өзүнүн мындан аркы иш-аракеттери жөнүндө чечим кабыл ала алат (бул маалымат кардар үчүн жетиштүүбү, дагы эмне керек, кандай маалымат керек деп сурасаңыз болот. кардар чечим кабыл алышы керек).  
Киргизилген маалыматты киргизүү талааларына бөлүү керек, эгерде алар өзүнчө иштетилсе жана ар кандай өзгөчөлүктөрдү түзүү менен.

Кардардын авторизациясы бар мисалда, эгерде сиз киргизилген маалыматты логин менен паролго бөлүп алсаңыз, анда өзүнчө логинди жана өзүнчө сырсөздү киргизүүнүн этаптарын бөлүп көрсөтүү үчүн авторизация скриптин өзгөртүү керек (жана бул Yandex, Googleде жасалат, бирок көпчүлүк интернет дүкөндөрүндө жасалган эмес).

Керектүү маалыматтарды трансформациялоо

Ошондой эле скрипттен маалыматтарды конвертациялоо алгоритмдерине талаптарды чыгара аласыз.

мисалдар:

  • Интернет-дүкөндөн продуктуну сатып алуу жөнүндө чечим кабыл алуу үчүн, кардар продукт картасында бул товардын мүмкүнчүлүгүн, баасын, анын шаарына жеткирүү убактысын билиши керек (алар өнүмдүн болушуна негизделген алгоритм менен эсептелет). кампалар жана жеткирүү чынжырынын параметрлери).
  • Издөө сабына сөз айкашын киргизүүдө кардар алгоритм боюнча издөө сунуштары көрсөтүлөт (алгоритм тарабынан түзүлөт...).

жалпы

Жалпысынан алганда, китепти окугандан кийин, тилекке каршы, талдоочудан бизнес көйгөйлөрүнө чейин иштеп чыгуучу үчүн расмий техникалык спецификацияга чейин кантип баруу керектиги түшүнүксүз. Китеп процесстин бир бөлүгүн гана айтат, киргизүү кадамдары так эмес жана кийинки кадамдар түшүнүксүз. Колдонуу учурунун өзү көбүнчө иштеп чыгуучу үчүн толук билдирүү эмес.

Ошого карабастан, бул объект менен субъекттин өз ара аракеттенүүсүнүн сценарийлерин формалдаштыруунун жана иштеп чыгуунун эң жакшы жолу, качан өз ара аракеттенүү субъекттеги бир нерсенин өзгөрүшүнө алып келет. Бул ачык өзгөчө издөө чекиттери менен текшерилүүчү талаптарга мүмкүндүк берген бир нече жазуу ыкмаларынын бири.

Китепти талдоочулар сыналуучу пьесаларды жаза башташ үчүн окуш керек.

Source: www.habr.com

Комментарий кошуу