સિસ્ટમો માટે કાર્યાત્મક આવશ્યકતાઓનું વર્ણન કરવા માટેની આધુનિક પદ્ધતિઓ. એલિસ્ટર કોબર્ન. પુસ્તકની સમીક્ષા અને ઉમેરાઓ

પુસ્તક સમસ્યાના નિવેદનના ભાગને લખવા માટેની એક પદ્ધતિનું વર્ણન કરે છે, એટલે કે ઉપયોગની કેસ પદ્ધતિ.

તે શુ છે? આ સિસ્ટમ (અથવા વ્યવસાય સાથે) સાથે વપરાશકર્તાની ક્રિયાપ્રતિક્રિયાના દૃશ્યનું વર્ણન છે. આ કિસ્સામાં, સિસ્ટમ બ્લેક બોક્સ તરીકે કાર્ય કરે છે (અને આ જટિલ ડિઝાઇન કાર્યને ક્રિયાપ્રતિક્રિયા ડિઝાઇન કરવા અને આ ક્રિયાપ્રતિક્રિયાને સુનિશ્ચિત કરવા માટે વિભાજિત કરવાનું શક્ય બનાવે છે). તે જ સમયે, નોટેશન ધોરણો રજૂ કરવામાં આવે છે, જે બિન-સહભાગીઓ સહિત વાંચવાની સરળતા સુનિશ્ચિત કરે છે, અને હિસ્સેદારના ધ્યેયો સાથે પૂર્ણતા અને પાલન માટે કેટલીક તપાસ માટે પરવાનગી આપે છે.

કેસ ઉદાહરણનો ઉપયોગ કરો

ઇમેઇલ દ્વારા સાઇટ પર અધિકૃતતાના ઉદાહરણનો ઉપયોગ કરીને, દૃશ્ય કેવું દેખાય છે:

(સિસ્ટમ) તમારું વ્યક્તિગત એકાઉન્ટ ઍક્સેસ કરવા માટે વેબસાઇટ પર લૉગ ઇન કરો. ~~ (સમુદ્ર સપાટી)

સંદર્ભ: અનધિકૃત ક્લાયંટ સાઇટ પર લૉગ ઇન કરે છે જેથી સાઇટ તેને ઓળખે અને તેના માટે વ્યક્તિગત માહિતી બતાવે: બ્રાઉઝિંગ ઇતિહાસ, ખરીદીનો ઇતિહાસ, બોનસ પોઇન્ટની વર્તમાન સંખ્યા, વગેરે, લોગિન તરીકે ઇમેઇલનો ઉપયોગ કરીને. 
સ્તર: વપરાશકર્તા ધ્યેય
મુખ્ય પાત્ર: ગ્રાહક (અમારા ઑનલાઇન સ્ટોરના મુલાકાતી)
અવકાશ: ઑનલાઇન સ્ટોર વેબસાઇટ સાથે ક્લાયન્ટની ક્રિયાપ્રતિક્રિયા
હિસ્સેદારો અને રુચિઓ:

• માર્કેટર ઇચ્છે છે કે વ્યક્તિગત મેઇલિંગના વધુ કવરેજ માટે સાઇટ મુલાકાતીઓની મહત્તમ સંખ્યા ઓળખવામાં આવે,
• સુરક્ષા નિષ્ણાત એ સુનિશ્ચિત કરવા માંગે છે કે મુલાકાતીઓના વ્યક્તિગત ડેટાની અનધિકૃત ઍક્સેસના કોઈ કેસ નથી, જેમાં એક એકાઉન્ટ માટે પાસવર્ડનો અંદાજ લગાવવાના પ્રયાસો અથવા નબળા પાસવર્ડ સાથે એકાઉન્ટ શોધવાનો સમાવેશ થાય છે,
• હુમલાખોર પીડિતના બોનસમાં પ્રવેશ મેળવવા માંગે છે,
• સ્પર્ધકો ઉત્પાદનો પર નકારાત્મક સમીક્ષાઓ છોડવા માંગે છે,
• બોટનેટ સ્ટોરનો ગ્રાહક આધાર મેળવવા માંગે છે અને સાઇટને બિનકાર્યક્ષમ બનાવવા માટે હુમલાનો ઉપયોગ કરવા માંગે છે.

પૂર્વશરતો: મુલાકાતી અધિકૃત ન હોવા જોઈએ.
ન્યૂનતમ ગેરંટી: મુલાકાતીને ખબર પડશે કે અધિકૃતતાનો પ્રયાસ સફળ હતો કે અસફળ.
સફળતાની બાંયધરી: મુલાકાતી અધિકૃત છે.

મુખ્ય દૃશ્ય:

1. ક્લાયંટ અધિકૃતતા શરૂ કરે છે.
2. સિસ્ટમ પુષ્ટિ કરે છે કે ક્લાયંટ અધિકૃત નથી અને "સુરક્ષા નિયમ નંબર 23" અનુસાર આપેલ સત્ર (બહુવિધ એકાઉન્ટ્સ માટે નબળા પાસવર્ડની શોધ) માંથી અસફળ અધિકૃત પ્રયાસોની સંખ્યા કરતાં વધી નથી.
3. સિસ્ટમ અધિકૃતતાના પ્રયાસોની સંખ્યા માટે કાઉન્ટર વધારે છે.
4. સિસ્ટમ ક્લાયન્ટને અધિકૃતતા ફોર્મ દર્શાવે છે.
5. ક્લાયંટ તેના ઇમેઇલ અને પાસવર્ડ દાખલ કરે છે.
6. સિસ્ટમ સિસ્ટમમાં આવા ઈમેલ સાથે ક્લાયન્ટની હાજરીની પુષ્ટિ કરે છે અને પાસવર્ડ મેળ ખાય છે અને આ એકાઉન્ટમાં લોગિન પ્રયાસોની સંખ્યા “સુરક્ષા નિયમ નંબર 24” અનુસાર ઓળંગાઈ નથી.
7. સિસ્ટમ ક્લાયંટને અધિકૃત કરે છે, આ ક્લાયંટ એકાઉન્ટના છેલ્લા સત્ર સાથે બ્રાઉઝિંગ ઇતિહાસ અને આ સત્રની ટોપલી ઉમેરે છે.
8. સિસ્ટમ અધિકૃતતા સફળતાનો સંદેશ દર્શાવે છે અને સ્ક્રિપ્ટ સ્ટેપ પર જાય છે જ્યાંથી ક્લાયંટને અધિકૃતતા માટે અવરોધવામાં આવ્યો હતો. આ કિસ્સામાં, પૃષ્ઠ પરનો ડેટા વ્યક્તિગત એકાઉન્ટ ડેટાને ધ્યાનમાં લઈને ફરીથી લોડ કરવામાં આવે છે.

એક્સ્ટેન્શન્સ:
2.એ. ક્લાયંટ પહેલેથી જ અધિકૃત છે:
 2.a.1. સિસ્ટમ ક્લાયન્ટને અગાઉ કરેલ અધિકૃતતાની હકીકત વિશે સૂચિત કરે છે અને સ્ક્રિપ્ટમાં વિક્ષેપ પાડવા અથવા પગલું 4 પર જવાની ઑફર કરે છે, અને જો પગલું 6 સફળતાપૂર્વક પૂર્ણ થાય છે, તો પછી પગલું 7 સ્પષ્ટતા સાથે કરવામાં આવે છે:
 2.a.7. સિસ્ટમ જૂના ખાતા હેઠળ ક્લાયન્ટને નિષ્ક્રિય કરે છે, નવા ખાતા હેઠળ ક્લાયન્ટને અધિકૃત કરે છે, જ્યારે આ ક્રિયાપ્રતિક્રિયા સત્રનો બ્રાઉઝિંગ ઇતિહાસ અને કાર્ટ જૂના ખાતામાં રહે છે અને નવા ખાતામાં સ્થાનાંતરિત થતું નથી. આગળ, પગલું 8 પર જાઓ.
2.b "સુરક્ષા નિયમ નંબર 23" અનુસાર અધિકૃતતાના પ્રયાસોની સંખ્યા થ્રેશોલ્ડને વટાવી ગઈ છે:
 2.b.1 સ્ટેપ 4 પર જાઓ, ઓથોરાઈઝેશન ફોર્મ પર એક કેપ્ચા વધુમાં પ્રદર્શિત થાય છે
 2.b.6 સિસ્ટમ સાચી કેપ્ચા એન્ટ્રીની પુષ્ટિ કરે છે
    2.b.6.1 કેપ્ચા ખોટી રીતે દાખલ કરેલ છે:
      2.બી.6.1.1. સિસ્ટમ આ એકાઉન્ટ માટે અસફળ અધિકૃત પ્રયાસોના કાઉન્ટરને પણ વધારે છે
      2.બી.6.1.2. સિસ્ટમ નિષ્ફળતા સંદેશ પ્રદર્શિત કરે છે અને પગલું 2 પર પાછા ફરે છે
6.એ. આ ઇમેઇલ ધરાવતું કોઈ એકાઉન્ટ મળ્યું નથી:
 6.a.1 સિસ્ટમ નિષ્ફળતા વિશે સંદેશ પ્રદર્શિત કરે છે અને ક્યાં તો પગલું 2 પર જવાની અથવા "વપરાશકર્તા નોંધણી" દૃશ્ય પર જવાની અને દાખલ કરેલ ઇમેઇલને સાચવવાની પસંદગી આપે છે,
6.બી. આ ઇમેઇલ સાથેના એકાઉન્ટ માટેનો પાસવર્ડ દાખલ કરેલ સાથે મેળ ખાતો નથી:
 6.b.1 સિસ્ટમ આ એકાઉન્ટમાં અસફળ લૉગિન પ્રયાસોના કાઉન્ટરને વધારે છે.
 6.b.2 સિસ્ટમ નિષ્ફળતા વિશે સંદેશ પ્રદર્શિત કરે છે અને "પાસવર્ડ પુનઃપ્રાપ્તિ" દૃશ્ય પર જવા અથવા પગલું 2 પર જવાની પસંદગી આપે છે.
6.c: આ એકાઉન્ટ માટે લોગિન પ્રયાસ કાઉન્ટર “સુરક્ષા નિયમ નંબર 24” માટે થ્રેશોલ્ડને વટાવી ગયો છે.
 6.c.1 સિસ્ટમ X મિનિટ માટે એકાઉન્ટ લોગિન અવરોધિત કરવા વિશેનો સંદેશ દર્શાવે છે અને પગલું 2 પર આગળ વધે છે.

શું મહાન છે

ધ્યેયોની સંપૂર્ણતા અને પાલન માટે તપાસ કરે છે, એટલે કે, તમે ચકાસણી માટે અન્ય વિશ્લેષકને જરૂરિયાતો આપી શકો છો, સમસ્યાના નિર્માણના તબક્કે ઓછી ભૂલો કરી શકો છો.

બ્લેક બોક્સ સિસ્ટમ સાથે કામ કરવાથી તમે અમલીકરણ પદ્ધતિઓમાંથી શું સ્વચાલિત થશે તેના ગ્રાહક સાથે વિકાસ અને સંકલનને અલગ કરી શકો છો.

તે વિશ્લેષકના માર્ગનો એક ભાગ છે, જે ઉપયોગીતાના મુખ્ય ભાગોમાંનો એક છે. વપરાશકર્તાનું દૃશ્ય તેના ચળવળના મુખ્ય માર્ગોને વ્યાખ્યાયિત કરે છે, જે ડિઝાઇનર અને ગ્રાહક માટે પસંદગીની સ્વતંત્રતાને મોટા પ્રમાણમાં ઘટાડે છે અને ડિઝાઇન વિકાસની ઝડપ વધારવામાં મદદ કરે છે.

હું વર્ણનમાં તે સ્થાનથી ખૂબ જ ખુશ છું જ્યાં ક્રિયાપ્રતિક્રિયાના દરેક પગલાના અપવાદો ઓળખવામાં આવે છે. સંપૂર્ણ IT સિસ્ટમે અમુક પ્રકારના અપવાદ હેન્ડલિંગ માટે પ્રદાન કરવું જોઈએ, અમુક મેન્યુઅલી, અમુક આપોઆપ (ઉપરના ઉદાહરણ તરીકે).

અનુભવ દર્શાવે છે કે અયોગ્ય-વિચારિત અપવાદ હેન્ડલિંગ સરળતાથી સિસ્ટમને ભયંકર અસુવિધાજનક સિસ્ટમમાં ફેરવી શકે છે. મને એ વાર્તા યાદ છે જ્યારે સોવિયેત સમયમાં, નિર્ણય લેવા માટે, તમારે વિવિધ સેવાઓમાંથી ઘણી મંજૂરીઓ મેળવવી પડતી હતી, અને જ્યારે છેલ્લી સેવા કહે છે ત્યારે તે કેટલું દુઃખદાયક છે - પરંતુ તમારી અરજી ખોટા નામમાં છે અથવા અન્ય કોઈ ભૂલ છે. વિરામચિહ્ન, બધું ફરીથી કરો અને બધું ફરીથી સંકલન કરો.

હું ઘણીવાર એવી પરિસ્થિતિઓનો સામનો કરું છું જ્યાં સિસ્ટમના ઓપરેટિંગ તર્કને અપવાદો માટે વિચારવામાં ન આવે તે માટે સિસ્ટમના નોંધપાત્ર પુનઃકાર્યની જરૂર પડે છે. આ કારણે, વિશ્લેષકના કાર્યનો સિંહફાળો અપવાદ સંભાળવામાં ખર્ચવામાં આવે છે.

ટેક્સ્ટ નોટેશન, આકૃતિઓથી વિપરીત, વધુ અપવાદોને ઓળખવા અને આવરી લેવાની મંજૂરી આપે છે.

પ્રેક્ટિસમાંથી પદ્ધતિમાં ઉમેરો

ઉપયોગનો કેસ વપરાશકર્તા વાર્તાથી વિપરીત નિવેદનનો સ્વતંત્ર રીતે પ્રાથમિકતા આપેલ ભાગ નથી.

ઉપરોક્ત દૃશ્યમાં, અપવાદને ધ્યાનમાં લો “6.a. આ ઈમેલ ધરાવતું કોઈ એકાઉન્ટ મળ્યું નથી.” અને આગળનું પગલું "6.a.1 સિસ્ટમ નિષ્ફળતા સંદેશ દર્શાવે છે અને પગલું 2 પર આગળ વધે છે." પડદા પાછળ કઈ નકારાત્મક બાબતો રહી ગઈ? ક્લાયન્ટ માટે, કોઈપણ વળતર એ હકીકત સમાન છે કે તેણે ડેટા દાખલ કરીને જે કામ કર્યું છે તે લેન્ડફિલમાં ફેંકવામાં આવે છે. (તે સ્ક્રિપ્ટમાં દેખાતું નથી!) શું કરી શકાય? સ્ક્રિપ્ટ ફરીથી બનાવો જેથી આવું ન થાય. શું આ કરવું શક્ય છે? તમે - ઉદાહરણ તરીકે, Google અધિકૃતતા સ્ક્રિપ્ટ જોઈ શકો છો.

દૃશ્ય ઑપ્ટિમાઇઝેશન

પુસ્તક ઔપચારિકતા વિશે વાત કરે છે, પરંતુ આવા દૃશ્યોને ઑપ્ટિમાઇઝ કરવાની પદ્ધતિઓ વિશે થોડું કહે છે.

પરંતુ દૃશ્યોને ઑપ્ટિમાઇઝ કરીને પદ્ધતિને મજબૂત બનાવવી શક્ય છે, અને ઉપયોગ કેસ ઔપચારિકતા પદ્ધતિ આને કરવાની મંજૂરી આપે છે. ખાસ કરીને, તમારે દરેક અપવાદ વિશે વિચારવાની, કારણ નક્કી કરવાની અને સ્ક્રિપ્ટને ફરીથી બનાવવાની જરૂર છે જેથી કરીને અપવાદથી છૂટકારો મેળવી શકાય અથવા ગ્રાહકની મુસાફરી ઓછી કરી શકાય.

ઓનલાઈન સ્ટોરમાંથી ઓર્ડર આપતી વખતે, તમારે ડિલિવરી શહેર દાખલ કરવું આવશ્યક છે. તે બહાર આવી શકે છે કે સ્ટોર ક્લાયંટ દ્વારા પસંદ કરેલા શહેરમાં માલ પહોંચાડી શકતો નથી કારણ કે તે ત્યાં ડિલિવરી કરતું નથી, કદના પ્રતિબંધોને કારણે અથવા સંબંધિત વેરહાઉસમાં માલની અછતને કારણે.

જો આપણે ફક્ત નોંધણીના તબક્કે ક્રિયાપ્રતિક્રિયાના દૃશ્યનું વર્ણન કરીએ, તો અમે "ક્લાયન્ટને જાણ કરી શકીએ છીએ કે ડિલિવરી અશક્ય છે અને શહેર અથવા કાર્ટની સામગ્રીને બદલવાની ઓફર કરીએ છીએ" (અને ઘણા શિખાઉ વિશ્લેષકો ત્યાં અટકે છે). પરંતુ જો આવા ઘણા કિસ્સાઓ છે, તો પછી દૃશ્ય ઑપ્ટિમાઇઝ કરી શકાય છે.

તમારે જે પ્રથમ વસ્તુ કરવાની જરૂર છે તે તમને ફક્ત તે જ શહેર પસંદ કરવા દો કે જ્યાં અમે ડિલિવરી કરી શકીએ. આ ક્યારે કરવું? વેબસાઇટ પર ઉત્પાદન પસંદ કરતા પહેલા (સ્પષ્ટતા સાથે IP દ્વારા શહેરની સ્વતઃ તપાસ).

બીજું, અમારે ફક્ત તે જ માલની પસંદગી કરવાની જરૂર છે જે અમે ક્લાયન્ટને પહોંચાડી શકીએ. આ ક્યારે કરવું? પસંદગીના ક્ષણે - ઉત્પાદન ટાઇલ અને ઉત્પાદન કાર્ડ પર.

આ બે ફેરફારો આ અપવાદને દૂર કરવા માટે ખૂબ આગળ વધે છે.

માપન અને મેટ્રિક્સ માટેની આવશ્યકતાઓ

અપવાદ હેન્ડલિંગને ઘટાડવાના કાર્યને ધ્યાનમાં લેતા, તમે રિપોર્ટિંગ કાર્ય સેટ કરી શકો છો (ઉપયોગનો કેસ વર્ણવેલ નથી). કેટલા અપવાદો હતા, તે કયા કેસમાં આવ્યા, ઉપરાંત કેટલા આવનારા દૃશ્યો સફળતાપૂર્વક પસાર થયા.

પણ અફસોસ. અનુભવ દર્શાવે છે કે આ ફોર્મમાં દૃશ્યો માટે રિપોર્ટિંગ આવશ્યકતાઓ પર્યાપ્ત નથી; તે પ્રક્રિયાઓ માટે રિપોર્ટિંગ આવશ્યકતાઓને ધ્યાનમાં લેવી જરૂરી છે જે મુખ્યત્વે ઉપયોગના કેસના સ્વરૂપમાં વર્ણવેલ નથી.

ઉપયોગિતાની ઍક્સેસ

અમારી પ્રેક્ટિસમાં, અમે ક્લાયન્ટ માટે નિર્ણય લેવા માટે એન્ટિટીના ચોક્કસ લક્ષણો અને ડેટાના વર્ણન સાથે ઉપયોગ કેસ વર્ણન ફોર્મનો વિસ્તાર કર્યો છે, જે અનુગામી ઉપયોગિતાને વધારે છે.

ઉપયોગિતા ડિઝાઇન માટે, અમે ઇનપુટ વિભાગ ઉમેર્યો - ડેટા ડિસ્પ્લે.

અધિકૃતતા સાથેના દૃશ્યમાં, આ હકીકત એ છે કે ક્લાયંટ સિસ્ટમમાં અધિકૃત છે. જો ક્લાયન્ટ પૂર્વ-અધિકૃત છે, તો સફળ અધિકૃતતા પછી નેવિગેશન ઇતિહાસ અને કાર્ટને નવા એકાઉન્ટમાં સ્વિચ કરવા વિશે ચેતવણી દર્શાવો.

સામાન્ય રીતે, આ ક્લાયંટ માટે જરૂરી માહિતીનું પ્રદર્શન છે જેથી તે દૃશ્ય અનુસાર તેની આગળની ક્રિયાઓ વિશે નિર્ણય લઈ શકે (તમે પૂછી શકો છો કે શું આ ડેટા ક્લાયંટ માટે પૂરતો છે, બીજું શું જરૂરી છે, કઈ માહિતી કરે છે ગ્રાહકે નિર્ણયો લેવાની જરૂર છે).  
દાખલ કરેલી માહિતીને ઇનપુટ ફીલ્ડમાં વિભાજીત કરવી પણ યોગ્ય છે જો તે અલગથી અને વિવિધ અપવાદોની રચના સાથે પ્રક્રિયા કરવામાં આવે.

ક્લાયંટ અધિકૃતતા સાથેના ઉદાહરણમાં, જો તમે દાખલ કરેલી માહિતીને લોગિન અને પાસવર્ડમાં અલગ કરો છો, તો પછી અલગ લોગિન અને અલગ પાસવર્ડ દાખલ કરવાના તબક્કાઓને પ્રકાશિત કરવા માટે અધિકૃતતા સ્ક્રિપ્ટમાં ફેરફાર કરવો યોગ્ય છે (અને આ યાન્ડેક્ષ, ગૂગલમાં કરવામાં આવે છે, પરંતુ મોટાભાગના ઓનલાઈન સ્ટોર્સમાં કરવામાં આવતું નથી).

જરૂરી ડેટા ટ્રાન્સફોર્મેશન સુધી પહોંચવું

તમે સ્ક્રિપ્ટમાંથી ડેટા કન્વર્ઝન એલ્ગોરિધમ્સ માટેની જરૂરિયાતો પણ કાઢી શકો છો.

ઉદાહરણો

• ઓનલાઈન સ્ટોરમાં પ્રોડક્ટ ખરીદવાનો નિર્ણય લેવા માટે, ક્લાયન્ટને પ્રોડક્ટ કાર્ડ પર આ પ્રોડક્ટની તેના શહેરમાં પહોંચવાની શક્યતા, કિંમત, ડિલિવરીનો સમય જાણવાની જરૂર છે (જેમાં ઉત્પાદનની ઉપલબ્ધતાના આધારે અલ્ગોરિધમ દ્વારા ગણતરી કરવામાં આવે છે. વેરહાઉસ અને સપ્લાય ચેઇન પરિમાણો).
• શોધ લાઇનમાં શબ્દસમૂહ દાખલ કરતી વખતે, ક્લાયંટને અલ્ગોરિધમ (જે અલ્ગોરિધમ દ્વારા જનરેટ કરવામાં આવે છે...) અનુસાર શોધ સૂચનો બતાવવામાં આવે છે.

કુલ

સામાન્ય રીતે, પુસ્તક વાંચ્યા પછી, કમનસીબે, તે સ્પષ્ટ નથી કે વિશ્લેષકથી લઈને વ્યવસાયિક સમસ્યાઓ સુધી વિકાસકર્તા માટે ઔપચારિક તકનીકી સ્પષ્ટીકરણ સુધી કેવી રીતે જવું. પુસ્તક પ્રક્રિયાનો માત્ર એક ભાગ જણાવે છે, જેમાં ઇનપુટ પગલાં અસ્પષ્ટ છે અને આગળનાં પગલાં અસ્પષ્ટ છે. ઉપયોગ કેસ પોતે મોટાભાગે વિકાસકર્તા માટે સંપૂર્ણ નિવેદન નથી.

તેમ છતાં, જ્યારે ક્રિયાપ્રતિક્રિયા વિષયમાં કોઈ વસ્તુમાં ફેરફારનું કારણ બને છે ત્યારે ઑબ્જેક્ટ અને વિષય વચ્ચેની ક્રિયાપ્રતિક્રિયાના દૃશ્યોને ઔપચારિક બનાવવા અને પ્રક્રિયા કરવાની આ એક ખૂબ જ સારી રીત છે. તે કેટલીક લેખન પદ્ધતિઓમાંથી એક છે જે સ્પષ્ટ અપવાદ શોધ બિંદુઓ સાથે ચકાસી શકાય તેવી આવશ્યકતાઓને મંજૂરી આપે છે.

ટેસ્ટેબલ નાટકો લખવાનું શરૂ કરવા માટે વિશ્લેષકો માટે આ પુસ્તક વાંચવું આવશ્યક છે.

સોર્સ: www.habr.com