‫‪3‬‬

‫ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت‬

‫ﺇﻥ ﲢﺪﻳﺪ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻋﻤﻞ ﺫﻭ ﻣﻨﺤﻰ ﺍﺟﺘﻤﺎﻋﻲ ﻧﻮﻋﹰﺎ ﻣﺎ ﻓﻬﻮ ﻳﻌﺘﻤﺪ ﻋﻠﻰ ﺍﳋﱪﺍﺕ ﺍﻹﺩﺍﺭﻳﺔ ﻭﻋﻠﻰ‬
‫ﻣﻬﺎﺭﺍﺕ ﺍﻟﺘﻮﺍﺻﻞ ﺍﻟﱵ ﳝﺘﻠﻜﻬﺎ ﻓﺮﻳﻖ ﺍﻟﺘﻄﻮﻳﺮ‪ .‬ﻭﺗﻌﺘﻤﺪ ﻫﺬﻩ ﺍﳌﺮﺣﻠﺔ ﻣﻦ ﺃﺩﱏ ﻣﺮﺍﺣﻞ ﺗﻄﻮﻳﺮ ﺍﻟﻨﻈﺎﻡ‬
‫ﻣﻦ ﺣﻴﺚ ﳏﺘﻮﺍﻫﺎ ﺍﻟﺘﻘﲏ‪ .‬ﻟﻜﻨﻬﺎ ﻣﻊ ﺫﻟﻚ ﺃﺳﺎﺳﻴﺔ ﺟﺪﹰﺍ ﻭﺇﺫﺍ ﱂ ﺗﻨﺠﺰ ﻫﺬﻩ ﺍﳌﺮﺣﻠﺔ ﺑﺈﺗﻘﺎﻥ ﺳﺘﻈﻬﺮ‬
‫ﻧﺘﺎﺋﺠﻬﺎ ﺍﻟﺴﻠﺒﻴﺔ ﺟﻠﻴﺔ ﰲ ﺍﳌﺮﺍﺣﻞ ﺍﻟﻼﺣﻘﺔ‪ .‬ﻭﻳﺆﺩﻱ ﺇﻏﻔﺎﻝ ﻣﺘﻄﻠﺒﺎﺕ ﺍﻟﺰﺑﻮﻥ ﺃﻭ ﺇﺳﺎﺀﺓ ﺗﻔﺴﲑﻫﺎ ﺃﻭ‬
‫ﻋﺪﻡ ﺍﻛﺘﺸﺎﻓﻬﺎ ﺇﱃ ﺯﻳﺎﺩﺓ ﺗﻜﺎﻟﻴﻒ ﺇﺟﺮﺍﺋﻴﺔ ﺍﻟﺘﻄﻮﻳﺮ ﺍﻟﱵ ﺗﻈﻬﺮ ﺑﻮﺿﻮﺡ ﰲ ﺍﳌﺮﺍﺣﻞ ﺍﳌﺘﻘﺪﻣﺔ‪.‬‬
‫ﻳﻌﺮﺽ ﻫﺬﺍ ﺍﻟﻔﺼﻞ ﻃﻴﻔﹰﺎ ﻭﺍﺳﻌﹰﺎ ﻣﻦ ﺍﳌﻮﺍﺿﻴﻊ ﺍﳌﺘﻌﻠﻘﺔ ﺑﺘﺤﺪﻳﺪ ﺍﳌﺘﻄﻠﺒﺎﺕ‪ ،‬ﻓﻴﻬﺘﻢ ﺍﻟﻨﺼﻒ ﺍﻷﻭﻝ ﻣﻨﻪ‬
‫ﺑﻄﺮﺍﺋﻖ ﺍﺳﺘﻨﺘﺎﺝ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻣﻦ ﺧﻼﻝ ﺍﳊﻮﺍﺭ ﻣﻊ ﺍﻟﺰﺑﻮﻥ ﻭﺍﻟﺘﺤﻘﻖ ﻣﻦ ﺻﻼﺣﻴﺔ ﻣﺘﻄﻠﺒﺎﺗﻪ ﺇﱃ ﺟﺎﻧﺐ‬
‫ﻋﺮﺽ ﺑﻌﺾ ﺍﳌﺒﺎﺩﺉ ﺍﻷﺳﺎﺳﻴﺔ ﰲ ﺇﺩﺍﺭﺓ ﺍﳌﺘﻄﻠﺒﺎﺕ‪ ،‬ﺍﻟﱵ ﺗﻌﲎ ﺑﺈﺩﺍﺭﺓ ﺍﻟﺘﻐﲑﺍﺕ ﻭﻛﺸﻔﻬﺎ ﻭﻫﻮ‬
‫ﺍﳌﻮﺿﻮﻉ ﺍﻟﺬﻱ ﺳﻨﺪﺭﺳﻪ ﲟﺰﻳﺪ ﻣﻦ ﺍﻟﺘﻔﺼﻴﻞ ﰲ ﺍﻟﻔﺼﻞ ﺍﻟﻌﺎﺷﺮ‪.‬‬

‫ﻡﺒﺎدئ ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت‬ ‫‪1-3‬‬

‫ﺇﻥ ﲢﺪﻳﺪ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻫﻲ ﺍﳌﺮﺣﻠﺔ ﺍﻷﻭﱃ ﻣﻦ ﻣﺮﺍﺣﻞ ﺩﻭﺭﺓ ﺗﻄﻮﻳﺮ ﺍﻟﻨﻈﺎﻡ ﺍﻟﺬﻱ ﲢﺪﺩﻩ ﺑﺪﻗﺔ ﺃﻧﺸﻄﺔ‬
‫ﲣﻄﻴﻂ ﺍﻟﻨﻈﺎﻡ )ﺍﻟﻔﻘﺮﺓ ‪ .(2-1‬ﻳﻬﺪﻑ ﲢﺪﻳﺪ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺇﱃ ﻭﺿﻊ ﺗﻌﺮﻳﻒ ﻣﻮﺟﺰ ﻟﻠﻤﺘﻄﻠﺒﺎﺕ ﺍﻟﻮﻇﻴﻔﻴﺔ‬
‫ﻭﻏﲑ ﺍﻟﻮﻇﻴﻔﻴﺔ ﺍﻟﱵ ﻳﺘﻮﻗﻊ ﺍﳌﻌﻨﻴﻮﻥ ﺑﺎﻟﻨﻈﺎﻡ ﺃﻥ ﳛﻘﻘﻬﺎ‪.‬‬
‫ﺗُﻌﺮﱢﻑ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﳋﺪﻣﺎﺕ ﺍﳌﺘﻮﻗﻊ ﻣﻦ ﺍﻟﻨﻈﺎﻡ ﺃﻥ ﻳﻮﻓﺮﻫﺎ )ﺑﻴﺎﻧﺎﺕ ﺍﳋﺪﻣﺔ( ﻭﺍﻟﻘﻴﻮﺩ ﺍﻟﱵ ﳚﺐ ﺃﻥ‬
‫ﳜﻀﻊ ﳍﺎ ﺍﻟﻨﻈﺎﻡ )ﺑﻴﺎﻧﺎﺕ ﺍﻟﻘﻴﻮﺩ(‪ .‬ﻭﳝﻜﻦ ﺗﻮﺯﻳﻊ ﺑﻴﺎﻧﺎﺕ ﺍﳋﺪﻣﺎﺕ ﻋﻠﻰ ﳎﻤﻮﻋﺎﺕ ﻣﻨﻬﺎ ﻣﺎ ﻳﻮﺻﻒ‬
‫ﻧﻄﺎﻕ ﺍﻟﻨﻈﺎﻡ ﻭﻣﻨﻬﺎ ﻣﺎ ﻳﻮﺻﻒ ﻭﻇﺎﺋﻒ ﺍﻟﻌﻤﻞ ﺍﻟﻼﺯﻣﺔ )ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻟﻮﻇﻴﻔﻴﺔ( ﻭﺑﲎ ﺍﳌﻌﻄﻴﺎﺕ‬
‫ﺍﳌﻄﻠﻮﺑﺔ )ﻣﺘﻄﻠﺒﺎﺕ ﺍﳌﻌﻄﻴﺎﺕ(‪ ،‬ﺃﻣﺎ ﺑﻴﺎﻧﺎﺕ ﺍﻟﻘﻴﻮﺩ ﻓﺘﺼﻨﻒ ﺗﺒﻌﹰﺎ ﻟﻔﺌﺎﺕ ﳐﺘﻠﻔﺔ ﻣﻦ ﺍﻟﻘﻴﻮﺩ ﺍﳌﻔﺮﻭﺿﺔ‬
‫ﻋﻠﻰ ﺍﻟﻨﻈﺎﻡ ﻛﻤﺘﻄﻠﺒﺎﺕ ﺍﻟﺸﻜﻞ ﻭﺍﳌﻈﻬﺮ ﺍﳋﺎﺭﺟﻲ ﻭﻣﺘﻄﻠﺒﺎﺕ ﺍﻷﺩﺍﺀ ﻭﺍﻷﻣﻦ ﻭﻏﲑﻫﺎ‪.‬‬
‫اﻟﻔﺼﻞ اﻟﺜﺎﻟﺚ‬ ‫‪106‬‬

‫ﺗﺴﺘﺨﻠﺺ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻣﻦ ﺍﻟﺰﺑﺎﺋﻦ )ﺍﳌﺴﺘﺨﺪﻣﲔ ﻭﻣﺎﻟﻜﻲ ﺍﻟﻨﻈﺎﻡ(‪ ،‬ﻭﻳﻘﻮﺩ ﻧﺸﺎﻁ ﺍﺳﺘﻨﺘﺎﺝ ﺍﳌﺘﻄﻠﺒﺎﺕ‬
‫ﳏﻠﻞ ﺃﻋﻤﺎﻝ )ﺃﻭ ﳏﻠﻞ ﻧﻈﻢ(‪ ،‬ﻭﳝﻜﻦ ﺃﻥ ﻳﺴﺘﺨﺪﻡ ﺍﶈﻠﻞ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺍﻟﺘﻘﻨﻴﺎﺕ ﺑﺪﺀﹰﺍ ﻣﻦ ﺇﺟﺮﺍﺀ‬
‫ﻣﻘﺎﺑﻼﺕ ﺗﻘﻠﻴﺪﻳﺔ ﻣﻊ ﺍﻟﺰﺑﺎﺋﻦ ﻭﺍﻧﺘﻬﺎﺀ ﺑﺒﻨﺎﺀ ﳕﻮﺫﺝ ﺃﻭﱄ ﻟﻠﻨﻈﺎﻡ )ﺇﺫﺍ ﻛﺎﻥ ﺫﻟﻚ ﺿﺮﻭﺭﻳﹰﺎ( ﻳﺴﺎﻋﺪ ﰲ‬
‫ﺍﻛﺘﺸﺎﻑ ﺍﳌﺰﻳﺪ ﻣﻦ ﺍﳌﺘﻄﻠﺒﺎﺕ‪.‬‬
‫ﳚﺐ ﺃﻥ ﲣﻀﻊ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻟﱵ ﺟﺮﻯ ﺍﺳﺘﻨﺘﺎﺟﻬﺎ ﻟﻌﻤﻠﻴﺔ ﲢﻠﻴﻞ ﺩﻗﻴﻘﺔ ﻬﺑﺪﻑ ﺍﻟﺘﺨﻠﺺ ﻣﻦ ﺍﳌﺘﻄﻠﺒﺎﺕ‬
‫ﺍﳌﻜﺮﺭﺓ ﻭﺍﳌﺘﻨﺎﻗﻀﺔ‪ ،‬ﻭﻗﺪ ﻳﺘﻄﻠﺐ ﻫﺬﺍ ﻣﺮﺍﺟﻌﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﺇﻋﺎﺩﺓ ﺍﻟﺘﻔﺎﻭﺽ ﻣﻊ ﺍﻟﺰﺑﺎﺋﻦ‪.‬‬
‫ﻭﺑﻌﺪ ﺃﻥ ﻳﻈﻬﺮ ﺍﻟﺰﺑﺎﺋﻦ ﺭﺿﺎﻫﻢ ﻭﻛﻔﺎﻳﺘﻬﻢ ﺗُﻌﺮﻑ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﺗﺼﻨﻒ ﻭﺗﺮﻗﻢ ﻟﺘﻈﻬﺮ ﺣﺴﺐ ﺃﻭﻟﻮﻳﺘﻬﺎ‬
‫ﰲ ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻟﱵ ﳚﺐ ﺃﻥ ﺗُﻌ ّﺪ ﻭﻓﻘﹰﺎ ﻟﻘﺎﻟﺐ ﲣﺘﺎﺭﻩ ﺍﳌﺆﺳﺴﺔ ﻟﺘﻮﺛﻴﻖ ﻣﺘﻄﻠﺒﺎﻬﺗﺎ‪.‬‬
‫ﻭﻣﻊ ﺃﻥ ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻫﻲ ﻭﺛﻴﻘﺔ ﺳﺮﺩﻳﺔ ﻋﺎﻣﺔ ﻳﻔﻀﻞ ﺃﻥ ﲢﻮﻱ ﳐﻄﻄﹰﺎ ﻳﺒﲔ ﳕﻮﺫﺝ ﺍﻟﻌﻤﻞ ﰲ‬
‫ﺍﳌﺴﺘﻮﻯ ﺍﻷﻋﻠﻰ ﺍﻟﺬﻱ ﳛﻮﻱ ﻋﺎﺩﺓ ﳕﻮﺫﺝ ﻧﻄﺎﻕ ﺍﻟﻨﻈﺎﻡ ﻭﳕﻮﺫﺝ ﺣﺎﻻﺕ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻷﻋﻤﺎﻝ ﻭﳕﻮﺫﺝ‬
‫ﺻﻔﻮﻑ ﺍﻟﻌﻤﻞ‪.‬‬
‫ﺇﻥ ﻣﺘﻄﻠﺒﺎﺕ ﺍﻟﺰﺑﻮﻥ ﻫﻲ ﻫﺪﻑ ﻣﺘﺤﺮﻙ‪ ،‬ﻭﻟﻠﺘﻌﺎﻣﻞ ﻣﻊ ﻫﺬﻩ ﺍﳌﺘﻄﻠﺒﺎﺕ ﳚﺐ ﺃﻥ ﻧﻜﻮﻥ ﻗﺎﺩﺭﻳﻦ ﻋﻠﻰ‬
‫ﻼ ﺗﻮﻗﻊ ﺗﺄﺛﲑ ﺗﻐﲑ ﺑﻌﺾ ﺍﳌﺘﻄﻠﺒﺎﺕ‬
‫ﺇﺩﺍﺭﺓ ﺍﻟﺘﻐﲑﺍﺕ‪ ،‬ﻭﺗﺘﻀﻤﻦ ﺇﺩﺍﺭﺓ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺃﻧﺸﻄﺔ ﻋﺪﻳﺪﺓ ﻣﻨﻬﺎ ﻣﺜ ﹰ‬
‫ﻋﻠﻰ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻷﺧﺮﻯ ﻭﻋﻠﻰ ﺑﻘﻴﺔ ﺍﻟﻨﻈﺎﻡ‪.‬‬

‫اﺳﺘﻨﺘﺎج اﻟﻤﺘﻄﻠﺒﺎت‬ ‫‪2-3‬‬

‫ﻳﻜﺘﺸﻒ ﳏﻠﻞ ﺍﻷﻋﻤﺎﻝ ﻣﺘﻄﻠﺒﺎﺕ ﺍﻟﻨﻈﺎﻡ ﺑﺎﺳﺘﺸﺎﺭﺓ ﺍﻟﺰﺑﺎﺋﻦ ﻭﺧﱪﺍﺀ ﻣﻦ ﳎﺎﻝ ﺍﻷﻋﻤﺎﻝ ﺍﳌﻌﲏ‪ ،‬ﻭﻗﺪ‬
‫ﳝﺘﻠﻚ ﳏﻠﻞ ﺍﻷﻋﻤﺎﻝ ﰲ ﺑﻌﺾ ﺍﳊﺎﻻﺕ ﺧﱪﺓ ﻛﺎﻓﻴﺔ ﰲ ﳎﺎﻝ ﺍﻟﻌﻤﻞ ﺍﳌﻌﲏ ﲝﻴﺚ ﳝﻜﻨﻪ ﺍﻻﺳﺘﻐﻨﺎﺀ‬
‫ﻋﻦ ﻣﺴﺎﻋﺪﺓ ﺍﳋﱪﺍﺀ‪ ،‬ﻭﻳﻜﻮﻥ ﳏﻠﻞ ﺍﻷﻋﻤﺎﻝ ﻋﻨﺪﺋ ٍﺬ )‪ (Business analyst‬ﻧﻮﻋﹰﺎ ﻣﻦ ﺧﱪﺍﺀ ﺍﺠﻤﻟﺎﻝ‬
‫)‪ (Domain Expert‬ﻛﻤﺎ ﺗﻮﺿﺢ ﻋﻼﻗﺔ ﺍﻟﺘﻌﻤﻴﻢ ﺍﳌﺒﻨﻴﺔ ﰲ ﺍﻟﺸﻜﻞ)‪) .(1-3‬ﳚﺐ ﺍﻻﻧﺘﺒﺎﻩ ﺇﱃ ﺃﻥ ﻫﺬﺍ‬
‫ﺍﻟﺸﻜﻞ ﻻ ﳝﺜﻞ ﳕﻮﺫﺝ ﺣﺎﻟﺔ ﺍﺳﺘﺨﺪﺍﻡ ﻟﻜﻨﻪ ﻳﺴﺘﺨﺪﻡ ﺍﻟﺮﻣﻮﺯ ﺍﳌﺴﺘﺨﺪﻣﺔ ﰲ ﺗﺪﻭﻳﻦ ﻫﺬﺍ ﺍﻟﻨﻤﻮﺫﺝ(‪.‬‬
‫ﺗﺸﻜﻞ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻟﱵ ﺗﺴﺘﻨﺘﺞ ﻣﻦ ﺍﳋﱪﺍﺀ ﻗﺎﻋﺪﺓ ﻣﻌﺎﺭﻑ ﰲ ﳎﺎﻝ ﺍﻟﻌﻤﻞ ﻓﻬﻲ ﺗﺼﻮﺭ ﻗﻮﺍﻋﺪ ﺍﻟﻌﻤﻞ‬
‫ﺍﳌﺴﺘﻘﻠﺔ ﻋﻦ ﺍﻟﺰﻣﻦ ﻭﺍﻟﱵ ﳝﻜﻦ ﺗﻄﺒﻴﻘﻬﺎ ﻋﻠﻰ ﻣﻌﻈﻢ ﺍﳌﺆﺳﺴﺎﺕ ﻭﺍﻷﻧﻈﻤﺔ‪ ،‬ﺃﻣﺎ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻟﱵ ﺗﺴﺘﻨﺞ‬
‫ﻣﻦ ﺍﻟﺰﺑﺎﺋﻦ ﻓﻴﻌﱪ ﻋﻨﻬﺎ ﲝﺎﻻﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ ﻭﻫﻲ ﺗﺘﺨﻄﻰ ﺍﳌﻌﺎﺭﻑ ﺍﻷﺳﺎﺳﻴﺔ ﻟﺘﺼﻮﺭ ﻫﻮﻳﺔ ﺍﳌﺆﺳﺴﺔ‬
‫ﲝﺪ ﺫﺍﻬﺗﺎ‪ -‬ﺃﻱ ﻃﺮﻳﻘﺔ ﺃﺩﺍﺀ ﺍﻷﻋﻤﺎﻝ ﰲ ﻫﺬﻩ ﺍﳌﺆﺳﺴﺔ ﺑﺎﻟﺬﺍﺕ ﻭﰲ ﻫﺬﺍ ﺍﻟﻮﻗﺖ ﺃﻭ ﻛﻴﻒ ﳚﺐ ﺃﻥ‬
‫ﺗﻜﻮﻥ‪.‬‬
‫‪107‬‬ ‫‪ : 3‬ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت‬

‫اﻟﺘﺄﺛﻴﺮات اﻟﻤﺘﺒﺎدﻟﺔ ﺧﻼل ﻣﺮﺣﻠﺔ ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت‪.‬‬ ‫اﻟﺸﻜﻞ )‪(1-3‬‬

‫ﻋﻠﻰ ﳏﻠﻞ ﺍﻷﻋﻤﺎﻝ ﺃﻥ ﳚﻤﻊ ﻣﺎ ﺑﲔ ﳎﻤﻮﻋﱵ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﳌﺬﻛﻮﺭﺗﲔ ﻟﺒﻨﺎﺀ ﳕﻮﺫﺝ ﺍﻟﻌﻤﻞ‪ ،‬ﻭﻛﻤﺎ ﻳﺒﲔ ﺍﻟﺸﻜﻞ‬
‫)‪ (1-3‬ﻳﺘﻀﻤﻦ ﳕﻮﺫﺝ ﺍﻷﻋﻤﺎﻝ )‪ (business model‬ﳕﻮﺫﺝ ﺻﻔﻮﻑ ﺍﻷﻋﻤﺎﻝ )‪(Business class model‬‬
‫ﻭﳕﻮﺫﺝ ﺣﺎﻟﺔ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﻌﻤﻞ )‪ .(Business Use Case Model‬ﻭﳕﻮﺫﺝ ﺻﻔﻮﻑ ﺍﻷﻋﻤﺎﻝ ﻫﻮ‬
‫ﳐﻄﻂ ﺻﻔﻮﻑ ﻋﻠﻰ ﻣﺴﺘﻮﻯ ﻋﺎﻝ ﻣﻦ ﺍﻟﺘﺠﺮﻳﺪ ﻳﻌﺮﻑ ﺃﻏﺮﺍﺽ ﺍﻷﻋﻤﺎﻝ ﻭﻳﺮﺑﻂ ﺑﻴﻨﻬﺎ‪ ،‬ﺃﻣﺎ ﳕﻮﺫﺝ‬
‫ﺣﺎﻟﺔ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﻌﻤﻞ ﻓﻬﻮ ﳐﻄﻂ ﺣﺎﻟﺔ ﺍﺳﺘﺨﺪﺍﻡ ﻋﻠﻰ ﻣﺴﺘﻮﻯ ﲡﺮﻳﺪ ﻋﺎﻝ ﺃﻳﻀﹰﺎ ﻳﺒﲔ ﺍﻟﻜﺘﻞ‬
‫ﺍﻟﻮﻇﻴﻔﻴﺔ ﺍﻷﺳﺎﺳﻴﺔ ﰲ ﺍﻟﻨﻈﺎﻡ‪.‬‬
‫ﻻ ﺗﺸﺘﻖ ﻋﻤﻮﻣﹰﺎ ﺻﻔﻮﻑ ﺍﺠﻤﻟﺎﻝ )ﺃﻏﺮﺍﺽ ﺍﻟﻌﻤﻞ( ﻣﻦ ﺣﺎﻻﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ‪ ،‬ﻭﳚﺐ ﻣﻦ ﺍﻟﻨﺎﺣﻴﺔ‬
‫ﺍﻟﻌﻤﻠﻴﺔ ﺍﻟﺘﺤﻘﻖ ﻣﻦ ﺻﻼﺣﻴﺔ ﳕﻮﺫﺝ ﺻﻔﻮﻑ ﺍﻷﻋﻤﺎﻝ ﲟﻘﺎﺭﻧﺘﻪ ﺑﻨﻤﻮﺫﺝ ﺣﺎﻻﺕ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﻌﻤﻞ‪،‬‬
‫ﻭﻗﺪ ﻳﺆﺩﻱ ﻫﺬﺍ ﺍﻟﺘﺤﻘﻖ ﺇﱃ ﺗﺼﺤﻴﺢ ﳕﻮﺫﺝ ﺍﻟﺼﻔﻮﻑ ﻭﺗﻮﺳﻴﻌﻪ‪.‬‬
‫‪ ،Hoffer‬ﺑﲔ ﺍﻟﻄﺮﺍﺋﻖ ﺍﻟﺘﻘﻠﻴﺪﻳﺔ ﻭﺍﻟﻄﺮﺍﺋﻖ ﺍﳊﺪﻳﺜﺔ ﰲ ﲨﻊ‬ ‫)‪et al (1996‬‬ ‫ﺳﻨﻤﻴﺰ ﻛﻤﺎ ﻳﻘﺘﺮﺡ‬
‫ﺍﳌﻌﻠﻮﻣﺎﺕ ﻭﺍﳊﻘﺎﺋﻖ‪.‬‬
‫اﻟﻔﺼﻞ اﻟﺜﺎﻟﺚ‬ ‫‪108‬‬

‫‪ 1-2-3‬اﻟﻄﺮاﺋﻖ اﻟﺘﻘﻠﻴﺪﻳﺔ ﻓﻲ اﺳﺘﻨﺘﺎج اﻟﻤﺘﻄﻠﺒﺎت‬

‫ﻣﻦ ﺍﻟﻄﺮﺍﺋﻖ ﺍﻟﺘﻘﻠﻴﺪﻳﺔ ﺍﳌﺘﺒﻌﺔ ﰲ ﺍﺳﺘﻨﺘﺎﺝ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺇﺟﺮﺍﺀ ﺍﳌﻘﺎﺑﻼﺕ ﻭﺗﻮﺯﻳﻊ ﺍﻻﺳﺘﺒﺎﻧﺎﺕ ﻭﺍﳌﻼﺣﻈﺔ‬
‫ﻭﺩﺭﺍﺳﺔ ﻭﺛﺎﺋﻖ ﺍﻟﻌﻤﻞ‪ ،‬ﻭﻫﻲ ﻛﻠﻬﺎ ﻣﻦ ﺍﻟﻄﺮﻕ ﺍﻟﺒﺴﻴﻄﺔ ﺫﺍﺕ ﺍﻟﻜﻠﻔﺔ ﺍﳌﻨﺨﻔﻀﺔ‪.‬‬
‫ﺗﺘﻨﺎﺳﺐ ﻓﺎﻋﻠﻴﺔ ﺍﻟﻄﺮﺍﺋﻖ ﺍﻟﺘﻘﻠﻴﺪﻳﺔ ﻣﻊ ﺩﺭﺟﺔ ﳐﺎﻃﺮ ﺍﳌﺸﺮﻭﻉ ﺗﻨﺎﺳﺒﹰﺎ ﻋﻜﺴﻴﺎﹰ‪ ،‬ﻓﺎﳋﻄﻮﺭﺓ ﺍﳌﺮﺗﻔﻌﺔ ﺗﺰﻳﺪ‬
‫ﺻﻌﻮﺑﺔ ﲢﻘﻴﻖ ﺍﻟﻨﻈﺎﻡ‪ ،‬ﺇﺫ ﻟﻦ ﺗﻌﺪ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﺍﺿﺤﺔ‪ ،‬ﻭﻻ ﺗﻌﺘﱪ ﺍﻟﻄﺮﺍﺋﻖ ﺍﻟﺘﻘﻠﻴﺪﻳﺔ ﻛﺎﻓﻴﺔ ﳌﺸﺎﺭﻳﻊ‬
‫ﻛﻬﺬﻩ‪.‬‬

‫إﺟﺮاء ﻡﻘﺎﺏﻼت ﻡﻊ اﻟﺰﺏﺎﺋﻦ وﻡﻊ اﻟﺨﺒﺮاء‬ ‫‪1-1-2-3‬‬

‫ﺗﻌﺘﱪ ﺍﳌﻘﺎﺑﻼﺕ ﺗﻘﻨﻴﺔ ﺃﺳﺎﺳﻴﺔ ﻻﻛﺘﺸﺎﻑ ﺍﳊﻘﺎﺋﻖ ﻭﲨﻊ ﺍﳌﻌﻠﻮﻣﺎﺕ‪ .‬ﻭﲡﺮﻯ ﻣﻌﻈﻢ ﺍﳌﻘﺎﺑﻼﺕ ﻣﻊ‬
‫ﺍﻟﺰﺑﺎﺋﻦ ﻭﻧﺴﺘﻨﺘﺞ ﻣﻨﻬﺎ ﺑﺸﻜﻞ ﺭﺋﻴﺴﻲ ﻣﺘﻄﻠﺒﺎﺕ ﺣﺎﻻﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ )ﺍﻟﺸﻜﻞ ‪ ،(1-3‬ﻛﻤﺎ ﳝﻜﻦ‬
‫ﺃﻳﻀﹰﺎ ﶈﻠﻞ ﺍﻷﻋﻤﺎﻝ ﺃﻥ ﳚﺮﻱ ﻣﻘﺎﺑﻼﺕ ﻣﻊ ﺧﱪﺍﺀ ﻣﻦ ﳎﺎﻝ ﺍﻷﻋﻤﺎﻝ ﺍﳌﻌﲏ ﺇﺫﺍ ﱂ ﺗﻜﻦ ﻟﺪﻳﻪ ﻣﻌﺮﻓﺔ‬
‫ﻛﺎﻓﻴﺔ ﺑﻪ‪.‬‬
‫ﲤﺜﻞ ﺍﳌﻘﺎﺑﻼﺕ ﻣﻊ ﺍﳋﱪﺍﺀ ﺇﺟﺮﺍﺋﻴﺔ ﺑﺴﻴﻄﺔ ﻟﻨﻘﻞ ﺍﳌﻌﺮﻓﺔ‪ ،‬ﻓﻬﻲ ﻋﺒﺎﺭﺓ ﻋﻦ ﺗﺪﺭﻳﺐ ﺗﻌﻠﻴﻤﻲ ﺑﺎﻟﻨﺴﺒﺔ ﶈﻠﻞ‬
‫ﺍﻷﻋﻤﺎﻝ‪ ،‬ﺃﻣﺎ ﺍﳌﻘﺎﺑﻼﺕ ﻣﻊ ﺍﻟﺰﺑﺎﺋﻦ ﻓﻬﻲ ﺃﻛﺜﺮ ﺗﻌﻘﻴﺪﹰﺍ )‪.(Kotonya & Sommerville, 1998; Sawyer, 1997‬‬
‫ﻗﺪ ﻻ ﳝﻠﻚ ﺍﻟﺰﺑﺎﺋﻦ ﺇﻻ ﺻﻮﺭﺓ ﻏﺎﻣﻀﺔ ﳌﺘﻄﻠﺒﺎﻬﺗﻢ‪ ،‬ﻭﻗﺪ ﻻ ﻳﺮﻏﺒﻮﻥ ﺑﺎﻟﺘﻌﺎﻭﻥ ﻣﻊ ﺍﶈﻠﻠﲔ‪ ،‬ﻭﺭﲟﺎ ﻻ‬
‫ﻳﺴﺘﻄﻴﻌﻮﻥ ﺍﻟﺘﻌﺒﲑ ﻋﻦ ﻣﺘﻄﻠﺒﺎﻬﺗﻢ ﲟﻔﺮﺩﺍﺕ ﻭﺍﺿﺤﺔ ﻭﻣﻔﻬﻮﻣﺔ‪ .‬ﻛﻤﺎ ﻗﺪ ﺗﺘﺠﺎﻭﺯ ﻣﺘﻄﻠﺒﺎﻬﺗﻢ ﻣﻮﺍﺯﻧﺔ‬
‫ﺍﳌﺸﺮﻭﻉ ﻭﻗﺪ ﺗﻜﻮﻥ ﺃﺣﻴﺎﻧﹰﺎ ﻏﲑ ﻗﺎﺑﻠﺔ ﻟﻠﺘﺤﻘﻴﻖ ﻭﺃﺧﲑﹰﺍ ﻣﻦ ﺍﻟﺸﺎﺋﻊ ﺃﻥ ﺗﺘﻌﺎﺭﺽ ﻣﺘﻄﻠﺒﺎﺕ ﺍﻟﺰﺑﺎﺋﻦ‬
‫ﺍﳌﺨﺘﻠﻔﲔ ﻓﻴﻤﺎ ﺑﻴﻨﻬﺎ‪.‬‬
‫ﻫﻨﺎﻙ ﻧﻮﻋﺎﻥ ﺃﺳﺎﺳﻴﺎﻥ ﻣﻦ ﺍﳌﻘﺎﺑﻼﺕ‪ :‬ﻣﻘﺎﺑﻼﺕ ﻣﻬﻴﻜﻠﺔ )ﺻﻮﺭﻳﺔ( ﻭﻏﲑ ﻣﻬﻴﻜﻠﺔ )ﻏﲑ ﺻﻮﺭﻳﺔ(‪،‬‬
‫ﲢﻀﺮ ﺍﳌﻘﺎﺑﻠﺔ ﺍﳌﻬﻴﻜﻠﺔ ﻗﺒﻞ ﺍﻟﺒﺪﺀ ﺑﺈﺟﺮﺍﺋﻬﺎ ﻭﲢﻀﺮ ﻣﻌﻈﻢ ﺍﻷﺳﺌﻠﺔ ﻗﺒﻞ ﺍﳌﻘﺎﺑﻠﺔ‪ ،‬ﻭﻗﺪ ﺗﻜﻮﻥ ﺑﻌﺾ‬
‫ﺍﻷﺳﺌﻠﺔ ﻣﻔﺘﻮﺣﺔ ﺍﻟﻨﻬﺎﻳﺔ )ﺃﻭ ﻻ ﳝﻜﻦ ﲢﻀﲑ ﺃﺟﻮﺑﺘﻬﺎ ﻣﺴﺒﻘﹰﺎ(‪ ،‬ﻭﻗﺪ ﻳﻜﻮﻥ ﺑﻌﻀﻬﺎ ﺍﻵﺧﺮ ﻣﻐﻠﻖ‬
‫ﺍﻟﻨﻬﺎﻳﺔ )ﺃﻱ ﻳﻨﺘﻘﻰ ﺍﳉﻮﺍﺏ ﻣﻦ ﺑﲔ ﻋﺪﺓ ﺃﺟﻮﺑﺔ ﺗﻄﺮﺡ ﻣﻊ ﺍﻟﺴﺆﺍﻝ(‪.‬‬
‫ﳚﺐ ﺇﻛﻤﺎﻝ ﺍﳌﻘﺎﺑﻼﺕ ﺍﳌﻬﻴﻜﻠﺔ ﲟﻘﺎﺑﻼﺕ ﻏﲑ ﻣﻬﻴﻜﻠﺔ ﻭﻫﻲ ﻋﺒﺎﺭﺓ ﻋﻦ ﺍﺟﺘﻤﺎﻋﺎﺕ ﻏﲑ ﺻﻮﺭﻳﺔ‬
‫ﺩﻭﻥ ﺃﺳﺌﻠﺔ ﳏﺪﺩﺓ ﻣﺴﺒﻘﹰﺎ ﻭﺩﻭﻥ ﺃﻫﺪﺍﻑ ﻣﺘﻮﻗﻌﺔ‪ ،‬ﻭﺗﺒﻘﻰ ﺍﻟﻐﺎﻳﺔ ﻣﻨﻬﺎ ﺗﺸﺠﻴﻊ ﺍﻟﺰﺑﻮﻥ ﻋﻠﻰ ﺍﻟﺘﻜﻠﻢ‬
‫ﻭﺍﻟﺘﻌﺒﲑ ﻋﻤﺎ ﳚﻮﻝ ﰲ ﺧﺎﻃﺮﻩ ﳑﺎ ﻗﺪ ﻳﻘﻮﺩ ﳏﻠﻞ ﺍﻷﻋﻤﺎﻝ ﺇﱃ ﺍﺳﺘﻨﺘﺎﺝ ﻣﺘﻄﻠﺒﺎﺕ ﱂ ﻳﻜﻦ ﻳﺘﻮﻗﻌﻬﺎ‪،‬‬
‫ﻭﺑﺎﻟﺘﺎﱄ ﱂ ﻳﻄﺮﺡ ﺃﺳﺌﻠﺔ ﺣﻮﳍﺎ‪.‬‬
‫‪109‬‬ ‫‪ : 3‬ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت‬

‫ﳚﺐ ﺃﻥ ﳓﺪﺩ ﻧﻘﻄﺔ ﺍﻻﻧﻄﻼﻕ ﻭﺳﻴﺎﻕ ﺍﻟﻨﻘﺎﺵ ﻟﻠﻤﻘﺎﺑﻼﺕ ﺍﳌﻬﻴﻜﻠﺔ ﻭﻏﲑ ﺍﳌﻬﻴﻜﻠﺔ‪ ،‬ﻭﳝﻜﻦ ﺃﻥ ﳚﺮﻱ‬
‫ﺫﻟﻚ ﻣﻦ ﺧﻼﻝ ﻭﺛﻴﻘﺔ ﻣﻜﺘﻮﺑﺔ ﺻﻐﲑﺓ ﺃﻭ ﺣﱴ ﺑﺮﻳﺪ ﺇﻟﻜﺘﺮﻭﱐ ﻳﺮﺳﻞ ﻟﻠﺸﺨﺺ ﺍﳌﻌﲏ ﻗﺒﻞ ﺍﳌﻘﺎﺑﻠﺔ‬
‫ﻳﺸﺮﺡ ﻓﻴﻬﺎ ﺍﶈﻠﻞ ﻫﺪﻓﻪ ﻭﻗﺪ ﻳﻄﺮﺡ ﻓﻴﻬﺎ ﺑﻌﺾ ﺍﻷﺳﺌﻠﺔ‪.‬‬
‫ﳚﺐ ﺃﻥ ﻳﺘﺠﻨﺐ ﺍﶈﻠﻞ ﻋﻤﻮﻣﹰﺎ ﻃﺮﺡ ﺛﻼﺛﺔ ﺃﻧﻮﺍﻉ ﻣﻦ ﺍﻷﺳﺌﻠﺔ )‪:(Whitten and Bentley, 1998‬‬
‫ﺍﻷﺳﺌﻠﺔ ﺍﻟﻌﻨﻴﺪﺓ‪ :‬ﺃﻱ ﺗﻠﻚ ﺍﻟﱵ ﻳﻌﱪ ﻓﻴﻬﺎ ﻣﻦ ﳚﺮﻱ ﺍﳌﻘﺎﺑﻠﺔ )ﻣﺒﺎﺷﺮﺓ ﺃﻭ ﻏﲑ ﻣﺒﺎﺷﺮﺓ( ﻋﻦ ﺭﺃﻳﻪ‬ ‫™‬
‫ﻼ‪ :‬ﻫﻞ ﻋﻠﻴﻨﺎ ﺃﻥ ﻧﻘﻮﻡ ﺑﺎﻷﻣﻮﺭ ﺑﺎﻟﻄﺮﻳﻘﺔ ﺍﻟﱵ ﺗﻘﻮﻡ ﺑﺘﻄﺒﻴﻘﻬﺎ؟(‪.‬‬
‫ﺑﺎﳌﻮﺿﻮﻉ )ﻣﺜ ﹰ‬
‫ﺍﻷﺳﺌﻠﺔ ﺍﳌﺘﺤﻴﺰﺓ‪ :‬ﻭﻫﻲ ﺷﺒﻴﻬﺔ ﺑﺎﻷﺳﺌﻠﺔ ﺍﻟﻌﻨﻴﺪﺓ‪ ،‬ﻟﻜﻦ ﺭﺃﻱ ﺍﳌﻘﺎﺑﻞ ﻳﻜﻮﻥ ﻣﻨﺤﺎﺯﹰﺍ ﻭﺿﻮﺣﹰﺎ‪.‬‬ ‫™‬
‫ﻼ‪ :‬ﺃﻧﺖ ﻟﻦ ﺗﻘﻮﻡ ﻬﺑﺬﺍ ﺍﻷﻣﺮ‪ ،‬ﺃﻟﻴﺲ ﻛﺬﻟﻚ َ؟(‪.‬‬
‫)ﻣﺜ ﹰ‬
‫ﻼ‬
‫ﺍﻷﺳﺌﻠﺔ ﺍﻟﱵ ﺗﻔﺮﺽ ﺇﺟﺎﺑﺎﻬﺗﺎ‪ ،‬ﻭﻫﻲ ﺍﻟﱵ ﺗﻔﺘﺮﺽ ﺃﻥ ﺍﻹﺟﺎﺑﺔ ﻣﻀﻤﻨﺔ ﰲ ﺍﻟﺴﺆﺍﻝ ﻧﻔﺴﻪ )ﻣﺜ ﹰ‬ ‫™‬
‫ﺃﻧﺖ ﺗﻘﻮﻡ ﺑﻌﻤﻠﻚ ﻬﺑﺬﻩ ﺍﻟﻄﺮﻳﻘﺔ‪ ،‬ﺃﻟﻴﺲ ﻛﺬﻟﻚ َ؟(‬
‫ﺗﺴﺎﻋﺪ ﰲ ﺇﳒﺎﺡ ﺍﳌﻘﺎﺑﻠﺔ ﻋﺪﺓ ﻋﻮﺍﻣﻞ‪ ،‬ﻟﻜﻦ ﻗﺪ ﻳﻜﻮﻥ ﺍﻷﻫﻢ ﻣﻦ ﺑﲔ ﻫﺬﻩ ﺍﻟﻌﻮﺍﻣﻞ ﻫﻮ ﻣﻬﺎﺭﺍﺕ‬
‫ﺍﻟﺘﻮﺍﺻﻞ ﺍﻟﱵ ﳝﺘﻠﻜﻬﺎ ﺍﻟﺸﺨﺺ ﺍﻟﺬﻱ ﳚﺮﻱ ﺍﳌﻘﺎﺑﻠﺔ‪ ،‬ﻓﻤﻊ ﺃﳘﻴﺔ ﺍﺣﺘﻔﺎﻇﻪ ﺑﺎﻟﺴﻴﻄﺮﺓ ﻭﻃﺮﺡ ﺍﻷﺳﺌﻠﺔ‬
‫ﻣﻦ ﺍﳍﺎﻡ ﺑﺎﻟﻘﺪﺭ ﻧﻔﺴﻪ ﺃﻥ ﻳﺼﻐﻲ ﺑﺎﻧﺘﺒﺎﻩ ﳌﺎ ﻳﻘﻮﻟﻪ ﺍﻟﺰﺑﻮﻥ ﻭﺃﻥ ﻳﺒﻘﻰ ﺻﺒﻮﺭﺍﹰ‪ ،‬ﻭﻟﻜﻲ ﳛﺎﻓﻆ ﻋﻠﻰ‬
‫ﻣﻮﻗﻌﻪ ﻭﺍﺣﺘﺮﺍﻣﻪ ﺍﻟﺸﺨﺼﻲ ﻭﻟﻜﻲ ﳛﺼﻞ ﻋﻠﻰ ﺭﺩ ﺟﻴﺪ ﳚﺐ ﺃﻥ ﻳﻌ ﱠﺪ ﻣﺬﻛﺮﺓ ﻳﻠﺨﺺ ﻓﻴﻬﺎ ﻧﺘﺎﺋﺞ‬
‫ﺍﳌﻘﺎﺑﻠﺔ ﻭﻳﺮﺳﻠﻬﺎ ﻟﻠﺰﺑﻮﻥ ﺧﻼﻝ ﻳﻮﻡ ﺃﻭ ﻳﻮﻣﲔ‪.‬‬

‫اﻻﺳﺘﺒﺎﻥﺎت‬ ‫‪2-1-2-3‬‬

‫ﺗﻌﺘﱪ ﺍﻻﺳﺘﺒﺎﻧﺎﺕ ﻃﺮﻳﻘﺔ ﻓﻌﺎﻟﺔ ﳉﻤﻊ ﺍﳌﻌﻠﻮﻣﺎﺕ ﻋﻨﺪ ﺍﻟﺘﻌﺎﻣﻞ ﻣﻊ ﻋﺪﺓ ﺯﺑﺎﺋﻦ ﰲ ﺍﻟﻮﻗﺖ ﻧﻔﺴﻪ‪،‬‬
‫ﻼ ﳍﺎ ﺇﻻ ﺇﺫﺍ ﻛﺎﻧﺖ ﺃﻫﺪﺍﻑ‬ ‫ﻭﺗﺴﺘﺨﺪﻡ ﺍﻻﺳﺘﺒﺎﻧﺎﺕ ﻋﺎﺩﺓ ﺇﱃ ﺟﺎﻧﺐ ﺍﳌﻘﺎﺑﻼﺕ ﻭﻻ ﺗﺸﻜﻞ ﺑﺪﻳ ﹰ‬
‫ﺍﳌﺸﺮﻭﻉ ﻣﻔﻬﻮﻣﺔ ﺟﻴﺪﹰﺍ ﻭﻣﺴﺘﻮﻯ ﺍﳋﻄﻮﺭﺓ ﻓﻴﻪ ﻣﻨﺨﻔﺾ‪ ،‬ﻓﻔﻲ ﻣﺸﺎﺭﻳﻊ ﻛﻬﺬﻩ ﻗﺪ ﺗﻜﻔﻲ ﺍﺳﺘﺒﺎﻧﺎﺕ‬
‫ﻋﺎﻣﺔ‪.‬‬
‫ﺇﻥ ﻣﺎ ﳓﺼﻞ ﻋﻠﻴﻪ ﻣﻦ ﺍﻻﺳﺘﺒﺎﻧﺎﺕ ﺃﻗﻞ ﻋﻤﻮﻣﹰﺎ ﳑﺎ ﳓﺼﻞ ﻋﻠﻴﻪ ﻣﻦ ﺍﳌﻘﺎﺑﻼﺕ‪ ،‬ﺇﺫ ﻻ ﳝﻜﻦ ﻋﻨﺪ‬
‫ﺍﺳﺘﺨﺪﺍﻡ ﺍﻻﺳﺘﺒﺎﻧﺎﺕ ﺗﻮﺿﻴﺢ ﺍﻷﺳﺌﻠﺔ ﺃﻭ ﺍﻷﺟﻮﺑﺔ ﺍﳌﻤﻜﻨﺔ‪ ،‬ﻭﻫﻲ ﻃﺮﻳﻘﺔ ﻣﻨﻔﻌﻠﺔ ﻭﻟﻴﺴﺖ ﻓﺎﻋﻠﺔ‬
‫ﻭﻫﺬﻩ ﻣﻴﺰﺓ ﺳﻠﺒﻴﺔ ﻭﺇﳚﺎﺑﻴﺔ ﰲ ﺁﻥ ﻣﻌﹰﺎ‪ .‬ﻓﻬﻲ ﺇﳚﺎﺑﻴﺔ ﻷﻥ ﻣﻦ ﺳﻴﺠﻴﺐ ﻋﻠﻰ ﺍﻷﺳﺌﻠﺔ ﳝﻠﻚ ﺍﻟﻮﻗﺖ‬
‫ﺍﻟﻜﺎﰲ ﳌﻘﺎﺭﻧﺔ ﺍﻹﺟﺎﺑﺎﺕ ﺍﳌﻤﻜﻨﺔ ﻭﻳﺴﺘﻄﻴﻊ ﺃﻥ ﳛﺎﻓﻆ ﻋﻠﻰ ﺑﻘﺎﺋﻪ ﳎﻬﻮﻻﹰ‪ ،‬ﻭﻫﻲ ﺳﻠﺒﻴﺔ ﻷﻬﻧﺎ ﻻ ﺗﻌﻄﻴﻪ‬
‫ﺍﻟﻔﺮﺻﺔ ﻻﺳﺘﻴﻀﺎﺡ ﺍﻷﺳﺌﻠﺔ‪.‬‬
‫اﻟﻔﺼﻞ اﻟﺜﺎﻟﺚ‬ ‫‪110‬‬

‫ﳚﺐ ﺃﻥ ﻳُﺼﻤﻢ ﺍﻻﺳﺘﺒﻴﺎﻥ ﲝﻴﺚ ﺗﺴﻬﻞ ﺍﻹﺟﺎﺑﺔ ﻋﻠﻰ ﺃﺳﺌﻠﺘﻪ‪ ،‬ﻭﻳﻔﻀﻞ ﲡﻨﺐ ﺍﻷﺳﺌﻠﺔ ﻣﻔﺘﻮﺣﺔ‬
‫ﺍﻟﻨﻬﺎﻳﺔ ﻭﺃﻥ ﺗﺒﻘﻰ ﻣﻌﻈﻢ ﺍﻷﺳﺌﻠﺔ ﻣﻐﻠﻘﺔ ﺍﻟﻨﻬﺎﻳﺔ‪ ،‬ﻭﳝﻜﻦ ﺃﻥ ﺗﺄﺧﺬ ﻫﺬﻩ ﺍﻷﺳﺌﻠﺔ ﺛﻼﺙ ﺻﻴﻎ‬
‫)‪:(Whitten and Bentley, 1998‬‬
‫ﺃﺳﺌﻠﺔ ﻣﻊ ﺧﻴﺎﺭﺍﺕ ﻣﺘﻌﺪﺩﺓ‪ ،‬ﺣﻴﺚ ﳚﺐ ﻋﻠﻰ ﺍﺠﻤﻟﻴﺐ ﺃﻥ ﻳﻨﺘﻘﻲ ﺇﺟﺎﺑﺔ ﺃﻭ ﺃﻛﺜﺮ ﻣﻦ ﳎﻤﻮﻋﺔ ﻣﻦ‬ ‫™‬
‫ﺍﻹﺟﺎﺑﺎﺕ ﺍﳌﻘﺘﺮﺣﺔ ﻣﻊ ﺍﻟﺴﺆﺍﻝ‪ ،‬ﻛﻤﺎ ﳚﺐ ﺍﻟﺴﻤﺎﺡ ﻟﻪ ﺑﻜﺘﺎﺑﺔ ﺗﻌﻠﻴﻖ ﺇﺿﺎﰲ‪.‬‬
‫ﺃﺳﺌﻠﺔ ﺗﻘﺪﻳﺮ ﺩﺭﺟﺔ ﺍﳌﻮﺍﻓﻘﺔ‪ ،‬ﺣﻴﺚ ﻳﻌﱪ ﺍﺠﻤﻟﻴﺐ ﻋﻦ ﺭﺃﻳﻪ ﺑﺒﻴﺎﻥ ﻣﺎ‪ ،‬ﻭﺗﻜﻮﻥ ﺍﻹﺟﺎﺑﺎﺕ ﻋﺎﺩﺓ‪:‬‬ ‫™‬
‫ﻣﻮﺍﻓﻖ ﲤﺎﻣﺎﹰ‪ ،‬ﻣﻮﺍﻓﻖ‪ ،‬ﺣﻴﺎﺩﻱ‪ ،‬ﻏﲑ ﻣﻮﺍﻓﻖ‪ ،‬ﻏﲑ ﻣﻮﺍﻓﻖ ﺇﻃﻼﻗﺎﹰ‪ ،‬ﻭﻻ ﺃﻋﻠﻢ‪.‬‬
‫ﺃﺳﺌﻠﺔ ﻣﻊ ﺇﺟﺎﺑﺎﺕ ﻣﺮﺗﺒﺔ‪ ،‬ﺣﻴﺚ ﺗﺮﺗﺐ ﺍﻹﺟﺎﺑﺎﺕ ﺍﳌﺮﺍﻓﻘﺔ ﻟﻠﺴﺆﺍﻝ ﺑﺄﺭﻗﺎﻡ ﺗﺴﻠﺴﻠﻴﺔ‪ ،‬ﺃﻭ ﺑﻨﺴﺐ‬ ‫™‬
‫ﻣﺌﻮﻳﺔ ﺃﻭ ﺑﻮﺳﺎﺋﻞ ﺗﺮﺗﻴﺐ ﻣﺸﺎﻬﺑﺔ‪.‬‬
‫ﻳﺸﺠﻊ ﺍﻻﺳﺘﺒﻴﺎﻥ ﺍﳌﺼﻤﻢ ﺟﻴﺪﹰﺍ ﻭﺍﻟﺬﻱ ﺗﺴﻬﻞ ﺍﻹﺟﺎﺑﺔ ﻋﻠﻰ ﺃﺳﺌﻠﺘﻪ ﺍﺠﻤﻟﻴﺐ ﻋﻠﻰ ﺇﻋﺎﺩﺓ ﺍﻟﻮﺛﻴﻘﺔ‬
‫ﻛﺎﻣﻠﺔ‪ ،‬ﻟﻜﻦ ﳚﺐ ﻋﻨﺪ ﺗﻘﻴﻴﻢ ﻧﺘﺎﺋﺞ ﺍﻻﺳﺘﺒﻴﺎﻥ ﺃﻥ ﻳﺄﺧﺬ ﳏﻠﻞ ﺍﻷﻋﻤﺎﻝ ﺑﺎﳊﺴﺒﺎﻥ ﺃﻥ ﺑﻌﺾ ﻣﻦ ﱂ‬
‫ﳚﻴﺒﻮﺍ ﺭﲟﺎ ﻛﺎﻧﻮﺍ ﻳﻔﻀﻠﻮﻥ ﺇﺟﺎﺑﺎﺕ ﺃﺧﺮﻯ )‪.(Hoffer et al, 1996‬‬

‫‪ 3-1-2-3‬اﻟﻤﺮاﻗﺒﺔ‬
‫ﻗﺪ ﳚﺪ ﳏﻠﻞ ﺍﻷﻋﻤﺎﻝ ﰲ ﺑﻌﺾ ﺍﳊﺎﻻﺕ ﺻﻌﻮﺑﺔ ﰲ ﺍﳊﺼﻮﻝ ﻋﻠﻰ ﻣﻌﻠﻮﻣﺎﺕ ﻛﺎﻣﻠﺔ ﻣﻦ ﺍﳌﻘﺎﺑﻼﺕ‬
‫ﻭﺍﻻﺳﺘﺒﺎﻧﺎﺕ‪ ،‬ﻓﻘﺪ ﻻ ﻳﻜﻮﻥ ﺍﻟﺰﺑﻮﻥ ﻗﺎﺩﺭﹰﺍ ﻋﻠﻰ ﺇﻳﺼﺎﻝ ﻣﻌﻠﻮﻣﺎﺗﻪ ﻟﻠﻤﺤﻠﻞ ﺑﻔﺎﻋﻠﻴﺔ ﻭﻗﺪ ﻻ ﳝﻠﻚ ﺇﻻ‬
‫ﻣﻌﺮﻓﺔ ﺟﺰﺋﻴﺔ ﺑﺈﺟﺮﺍﺋﻴﺔ ﺍﻟﻌﻤﻞ‪ ،‬ﻭﰲ ﻣﺜﻞ ﻫﺬﻩ ﺍﳊﺎﻻﺕ ﻗﺪ ﺗﻜﻮﻥ ﺍﳌﺮﺍﻗﺒﺔ ﺗﻘﻨﻴﺔ ﻓﻌﺎﻟﺔ ﳌﻌﺮﻓﺔ ﺍﳊﻘﺎﺋﻖ‪.‬‬
‫ﻭﰲ ﻬﻧﺎﻳﺔ ﺍﳌﻄﺎﻑ ﺗﺒﻘﻰ ﻣﺮﺍﻗﺒﺔ ﻭﻣﻼﺣﻈﺔ ﺍﻹﺟﺮﺍﺋﻴﺔ ﺍﻟﻄﺮﻳﻘﺔ ﺍﻷﻓﻀﻞ ﻟﺘﻌﻠﻢ ﻭﻓﻬﻢ ﻣﺎ ﳚﺮﻱ‪.‬‬
‫ﻭﳝﻜﻦ ﺃﻥ ﺗﺄﺧﺬ ﺍﳌﺮﺍﻗﺒﺔ ﺇﺣﺪﻯ ﺻﻐﺘﲔ‪:‬‬
‫ﻣﺮﺍﻗﺒﺔ ﻣﻨﻔﻌﻠﺔ‪ ،‬ﻭﻓﻴﻬﺎ ﻳﺮﺍﻗﺐ ﳏﻠﻞ ﺍﻷﻋﻤﺎﻝ ﺃﻧﺸﻄﺔ ﺍﻟﻌﻤﻞ ﺩﻭﻥ ﺃﻥ ﻳﻘﺎﻃﻌﻬﺎ ﻭﺩﻭﻥ ﺃﻥ ﻳﺘﺪﺧﻞ‬ ‫™‬
‫ﻓﻴﻬﺎ ﻣﺒﺎﺷﺮﺓ‪ ،‬ﻭﳝﻜﻦ ﺃﻥ ﻳﻠﺠﺄ ﺍﶈﻠﻞ ﰲ ﺑﻌﺾ ﺍﳊﺎﻻﺕ ﺇﱃ ﺍﻟﺘﺼﻮﻳﺮ ﺍﻟﺘﻠﻔﺰﻳﻮﱐ‪.‬‬
‫ﻣﺮﺍﻗﺒﺔ ﻓﺎﻋﻠﺔ‪ ،‬ﻭﻓﻴﻬﺎ ﻳﺸﺎﺭﻙ ﳏﻠﻞ ﺍﻷﻋﻤﺎﻝ ﰲ ﺃﻧﺸﻄﺔ ﺍﻟﻌﻤﻞ ﻟﻴﺘﺤﻮﻝ ﺇﱃ ﻋﻨﺼﺮ ﻓﻌﺎﻝ ﰲ ﺍﻟﻔﺮﻳﻖ‪.‬‬ ‫™‬

‫ﻭﻟﻜﻲ ﺗﻌﻄﻲ ﺍﳌﺮﺍﻗﺒﺔ ﻣﻌﻠﻮﻣﺎﺕ ﺣﻘﻴﻘﻴﺔ ﳚﺐ ﺃﻥ ﺗﺪﻭﻡ ﻟﻔﺘﺮﺓ ﻃﻮﻳﻠﺔ‪ ،‬ﻛﻤﺎ ﳚﺐ ﺃﻥ ﺗﺘﻢ ﰲ ﺃﻭﻗﺎﺕ‬
‫ﳐﺘﻠﻔﺔ‪ ،‬ﻭﰲ ﻇﺮﻭﻑ ﻋﻤﻞ ﻣﺘﺒﺎﻳﻨﺔ‪ ،‬ﻭﺗﺒﻘﻰ ﺍﻟﺼﻌﻮﺑﺔ ﺍﻷﺳﺎﺳﻴﺔ ﻫﻨﺎ ﺃﻥ ﺍﻟﻨﺎﺱ ﳝﻴﻠﻮﻥ ﻟﻠﺘﺼﺮﻑ‬
‫ﺑﻄﺮﻕ ﳐﺘﻠﻔﺔ ﺃﺛﻨﺎﺀ ﻣﺮﺍﻗﺒﺘﻬﻢ‪ ،‬ﻭﳝﻴﻠﻮﻥ ﺧﺼﻮﺻﺎﹰ ﺇﱃ ﺍﻟﻌﻤﻞ ﺗﺒﻌﺎﹰ ﻟﻺﺟﺮﺍﺀﺍﺕ ﻭﺍﻟﻘﻮﺍﻋﺪ ﺍﻟﺮﲰﻴﺔ‬
‫ﺍﻟﺼﻮﺭﻳﺔ‪ ،‬ﻭﻫﺬﺍ ﻳﺸﻮﻩ ﺍﳊﻘﻴﻘﺔ ﺑﺈﺧﻔﺎﺀ ﺍﻻﺧﺘﺰﺍﻻﺕ ﺍﻟﱵ ﻗﺪ ﳚﺮﻳﻬﺎ ﺍﻟﻌﺎﻣﻞ ﺳﻮﺍﺀ ﻛﺎﻧﺖ ﺳﻠﺒﻴﺔ ﺃﻡ‬
‫ﺇﳚﺎﺑﻴﺔ‪.‬‬
‫‪111‬‬ ‫‪ : 3‬ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت‬

‫دراﺳﺔ اﻟﻮﺙﺎﺋﻖ واﻷﻥﻈﻤﺔ اﻟﺒﺮﻡﺠﻴﺔ‬ ‫‪4-1-2-3‬‬

‫ﺗﺒﻘﻰ ﺩﺭﺍﺳﺔ ﺍﻟﻮﺛﺎﺋﻖ ﻭﺍﻷﻧﻈﻤﺔ ﺍﻟﱪﳎﻴﺔ ﺗﻘﻨﻴﺔ ﻻ ﻏﲎ ﻋﻨﻬﺎ ﻻﻛﺘﺸﺎﻑ ﻣﺘﻄﻠﺒﺎﺕ ﺣﺎﻻﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ‬
‫ﻭﻣﺘﻄﻠﺒﺎﺕ ﺍﺠﻤﻟﺎﻝ ﺍﳌﻌﺮﻓﻴﺔ )ﺍﻧﻈﺮ ﺍﻟﻔﻘﺮﺓ ‪ ،(2-3‬ﻭﺗُﺴﺘﺨﺪﻡ ﻫﺬﻩ ﺍﻟﺘﻘﻨﻴﺔ ﺩﻭﻣﹰﺎ ﻣﻊ ﺃﻬﻧﺎ ﺗﺘﺠﻪ ﻟﺪﺭﺍﺳﺔ‬
‫ﺡ ﳏﺪﻭﺩﺓ ﻣﻦ ﺍﻟﻨﻈﺎﻡ‪.‬‬ ‫ﻣﻨﺎ ٍ‬
‫ﳚﺮﻱ ﺍﻛﺘﺸﺎﻑ ﻣﺘﻄﻠﺒﺎﺕ ﺣﺎﻻﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ ﻋﱪ ﺩﺭﺍﺳﺔ ﻭﺛﺎﺋﻖ ﺍﳌﺆﺳﺴﺔ ﺍﳌﻮﺟﻮﺩﺓ ﻭﺍﺳﺘﻤﺎﺭﺍﺕ‬
‫ﻭﺗﻘﺎﺭﻳﺮ ﺍﻷﻧﻈﻤﺔ )ﰲ ﺣﺎﻝ ﻭﺟﻮﺩ ﺣﻞ ﺣﺎﺳﻮﰊ ﻟﻠﻨﻈﺎﻡ ﺍﳊﺎﱄ‪ ،‬ﻭﻫﺬﺍ ﳏﺘﻤﻞ ﺟﺪﹰﺍ ﰲ ﺍﳌﺆﺳﺴﺎﺕ‬
‫ﺍﻟﻜﺒﲑﺓ(‪ .‬ﻭﻣﻦ ﺃﻫﻢ ﻣﺎ ﳚﺐ ﺍﻟﺘﺮﻛﻴﺰ ﻋﻠﻴﻪ ﺃﺛﻨﺎﺀ ﺍﺳﺘﻜﺸﺎﻑ ﻣﺘﻄﻠﺒﺎﺕ ﺣﺎﻻﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ ﻫﻮ ﺳﺠﻞ‬
‫ﺍﻷﺧﻄﺎﺀ ﻭﻃﻠﺒﺎﺕ ﺗﻌﺪﻳﻞ ﺍﻟﻨﻈﺎﻡ ﺍﳌﻮﺟﻮﺩ )ﺇﺫﺍ ﻛﺎﻥ ﻣﺜﻞ ﻫﺬﺍ ﺍﻟﺴﺠﻞ ﻣﻮﺟﻮﺩﹰﺍ(‪.‬‬
‫ﺗﺘﻀﻤﻦ ﺍﻟﻮﺛﺎﺋﻖ ﺍﻟﱵ ﲡﺐ ﺩﺭﺍﺳﺘﻬﺎ‪ :‬ﺍﺳﺘﻤﺎﺭﺍﺕ ﺍﻟﻌﻤﻞ )ﺑﻌﺪ ﻣﻠﺌﻬﺎ ﺑﺒﻴﺎﻧﺎﺕ ﻓﻌﻠﻴﺔ ﺇﻥ ﺃﻣﻜﻦ(‪،‬‬
‫ﺇﺟﺮﺍﺀﺍﺕ ﺍﻟﻌﻤﻞ‪ ،‬ﺍﻷﻧﻈﻤﺔ ﺍﻟﺪﺍﺧﻠﻴﺔ‪ ،‬ﺧﻄﻂ ﺍﻟﻌﻤﻞ‪ ،‬ﳐﻄﻄﺎﺕ ﺍﻟﺒﻨﻴﺔ ﺍﻟﺘﻨﻈﻴﻤﻴﺔ‪ ،‬ﺍﻟﻌﻼﻗﺎﺕ ﺑﲔ‬
‫ﺍﳌﻜﺎﺗﺐ ﺩﺍﺧﻞ ﺍﳌﺆﺳﺴﺔ ﻧﻔﺴﻬﺎ‪ ،‬ﳏﺎﺿﺮ ﺍﻻﺟﺘﻤﺎﻋﺎﺕ‪ ،‬ﺳﺠﻼﺕ ﺍﶈﺎﺳﺒﺔ‪ ،‬ﺍﻻﺭﺗﺒﺎﻃﺎﺕ ﺍﳋﺎﺭﺟﻴﺔ‬
‫ﻼ(‪ ،‬ﻭﺷﻜﺎﻭﻯ ﺍﻟﺰﺑﺎﺋﻦ ﻭﻏﲑﻫﺎ‪.‬‬
‫)ﲟﺆﺳﺴﺎﺕ ﺃﺧﺮﻯ ﻣﺜ ﹰ‬
‫ﻭﺗﺘﻀﻤﻦ ﺍﻻﺳﺘﻤﺎﺭﺍﺕ ﻭﺍﻟﺘﻘﺎﺭﻳﺮ ﺍﻟﱵ ﲡﺐ ﺩﺭﺍﺳﺘﻬﺎ‪ :‬ﺷﺎﺷﺎﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ ﻭﺍﻟﺘﻘﺎﺭﻳﺮ ﺇﱃ ﺟﺎﻧﺐ ﺍﻟﺘﻮﺛﻴﻖ‬
‫ﺍﳌﺮﺍﻓﻖ‪ ،‬ﺃﻱ‪ :‬ﺃﺩﻟﺔ ﻋﻤﻞ ﺍﻟﻨﻈﺎﻡ‪ ،‬ﺩﻟﻴﻞ ﺍﳌﺴﺘﺨﺪﻡ‪ ،‬ﺍﻟﺘﻮﺛﻴﻖ ﺍﻟﺘﻘﲏ‪ ،‬ﳕﺎﺫﺝ ﲢﻠﻴﻞ ﻭﺗﺼﻤﻴﻢ ﺍﻟﻨﻈﺎﻡ‪.‬‬
‫ﻭﳚﺮﻱ ﺍﺳﺘﻜﺸﺎﻑ ﻣﺘﻄﻠﺒﺎﺕ ﺍﺠﻤﻟﺎﻝ ﺍﳌﻌﺮﻓﻴﺔ ﻋﱪ ﺍﻟﺒﺤﺚ ﰲ ﺍﺠﻤﻟﻼﺕ ﻭﺍﻟﻜﺘﺐ ﺍﳌﺮﺟﻌﻴﺔ ﺍﻟﱵ ﺗﺘﻨﺎﻭﻝ‬
‫ﻫﺬﺍ ﺍﺠﻤﻟﺎﻝ ﻣﻦ ﺍﻷﻋﻤﺎﻝ‪ .‬ﻛﻤﺎ ﳝﻜﻦ ﺃﻥ ﳛﺼﻞ ﺍﶈﻠﻞ ﻋﻠﻰ ﻣﻌﺮﻓﺔ ﻏﻨﻴﺔ ﲟﺠﺎﻝ ﺍﻟﻌﻤﻞ ﺑﻌﺪ ﺩﺭﺍﺳﺔ‬
‫ﺍﳊﺰﻡ ﺍﻟﱪﳎﻴﺔ ﺍﳌﻼﺋﻤﺔ ﻟﻠﻌﻤﻞ‪ .‬ﻭﻋﻠﻴﻪ ﺗﻌﺘﱪ ﺯﻳﺎﺭﺓ ﺍﳌﻜﺘﺒﺎﺕ ﻭﺑﺎﺋﻌﻲ ﺍﻟﱪﳎﻴﺎﺕ ﺟﺰﺀﹰﺍ ﻣﻦ ﺇﺟﺮﺍﺋﻴﺔ‬
‫ﺍﺳﺘﻨﺘﺎﺝ ﺍﳌﺘﻄﻠﺒﺎﺕ )ﺗﺴﻤﺢ ﺷﺒﻜﺔ ﺍﻹﻧﺘﺮﻧﺖ ﺑﺈﺟﺮﺍﺀ ﻫﺬﻩ "ﺍﻟﺰﻳﺎﺭﺍﺕ" ﺩﻭﻥ ﻣﻐﺎﺩﺭﺓ ﺍﳌﻜﺘﺐ(‪.‬‬

‫‪ 2-2-3‬اﻟﻄﺮاﺋﻖ اﻟﺤﺪﻳﺜﺔ ﻓﻲ اﺳﺘﻨﺘﺎج اﻟﻤﺘﻄﻠﺒﺎت‬

‫ﻣﻦ ﺑﲔ ﺍﻟﻄﺮﺍﺋﻖ ﺍﳊﺪﻳﺜﺔ ﰲ ﺍﺳﺘﻨﺘﺎﺝ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺇﻋﺪﺍﺩ ﺍﻟﻨﻤﺎﺫﺝ ﺍﻟﱪﳎﻴﺔ ﺍﻷﻭﻟﻴﺔ‪ ،‬ﻭﺗﻄﻮﻳﺮ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ‬
‫ﺍﳌﺸﺘﺮﻙ ‪ (Joint Application Development) JAD‬ﻭﺗﻄﻮﻳﺮ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻟﺴﺮﻳﻊ‬
‫‪ .(Rapid Application Development) RAD‬ﺗﻌﻄﻲ ﻫﺬﻩ ﺍﻟﻄﺮﺍﺋﻖ ﺃﳘﻴﺔ ﺃﻛﱪ ﻻﺳﺘﻜﺸﺎﻑ‬
‫ﺍﳌﺘﻄﻠﺒﺎﺕ ﻟﻜﻨﻬﺎ ﲢﺘﺎﺝ ﺑﺎﳌﻘﺎﺑﻞ ﺇﱃ ﺟﻬﺪ ﻭﻛﻠﻔﺔ ﺃﻛﱪ‪ ،‬ﻟﻜﻦ ﺗﺒﻘﻰ ﺍﶈﺼﻠﺔ ﻋﻠﻰ ﺍﳌﺪﻯ ﺍﻟﻄﻮﻳﻞ‬
‫ﺃﻓﻀﻞ‪.‬‬
‫ﻭﺗﺴﺘﺨﺪﻡ ﺍﻟﻄﺮﺍﺋﻖ ﺍﳊﺪﻳﺜﺔ ﻋﺎﺩﺓ ﻋﻨﺪﻣﺎ ﺗﻜﻮﻥ ﺩﺭﺟﺔ ﺧﻄﻮﺭﺓ ﺍﳌﺸﺮﻭﻉ ﻋﺎﻟﻴﺔ‪ ،‬ﻭﺍﻟﱵ ﺗﻨﺘﺞ ﺑﺪﻭﺭﻫﺎ‬
‫ﻋﻦ ﻋﻮﺍﻣﻞ ﻋﺪﻳﺪﺓ ﻣﻦ ﺑﻴﻨﻬﺎ ﻋﺪﻡ ﻭﺿﻮﺡ ﺍﻷﻫﺪﺍﻑ‪ ،‬ﻭﻋﺪﻡ ﻭﺟﻮﺩ ﺗﻮﺛﻴﻖ ﻟﻺﺟﺮﺍﺀﺍﺕ‪ ،‬ﻭﻋﺪﻡ‬
‫ﺍﺳﺘﻘﺮﺍﺭ ﺍﳌﺘﻄﻠﺒﺎﺕ‪ ،‬ﺍﳔﻔﺎﺽ ﺧﱪﺍﺕ ﺍﳌﺴﺘﺨﺪﻣﲔ‪ ،‬ﻭﻋﺪﻡ ﺧﱪﺓ ﺍﳌﻄﻮﺭﻳﻦ‪ ،‬ﻭﻋﺪﻡ ﺍﻟﺘﺰﺍﻡ ﺍﳌﺴﺘﺨﺪﻣﲔ‬
‫اﻟﻔﺼﻞ اﻟﺜﺎﻟﺚ‬ ‫‪112‬‬

‫ﺑﺸﻜﻞ ﻛﺎﻑٍ‪ ،‬ﻭﻏﲑﻫﺎ‪.‬‬

‫اﻟﻨﻤﺬﺟﺔ اﻷوﻟﻴﺔ )‪(Prototyping‬‬ ‫‪1-2-2-3‬‬

‫ﺗﻌﺘﱪ ﺍﻟﻨﻤﺬﺟﺔ ﺍﻷﻭﻟﻴﺔ ﻣﻦ ﺃﻛﺜﺮ ﺍﻟﻄﺮﺍﺋﻖ ﺍﳊﺪﻳﺜﺔ ﺍﺳﺘﺨﺪﺍﻣﺎﹰ‪ ،‬ﺇﺫ ﺗﺒﲎ ﺍﻟﻨﻤﺎﺫﺝ ﺍﻟﱪﳎﻴﺔ ﺍﻷﻭﻟﻴﺔ ﻟﻴﻌﺎﻳﻦ‬
‫ﺍﻟﺰﺑﺎﺋﻦ ﺍﻟﻨﻈﺎﻡ‪ ،‬ﺃﻭ ﺟﺰﺀﹰﺍ ﻣﻨﻪ‪ ،‬ﻬﺑﺪﻑ ﻣﻌﺮﻓﺔ ﺍﻧﻄﺒﺎﻋﺎﻬﺗﻢ‪.‬‬
‫ﻟﻴﺲ ﺍﻟﻨﻤﻮﺫﺝ ﺍﻷﻭﱄ ﺇﻻ ﻧﻈﺎﻣﹰﺎ ﺗﻮﺿﻴﺤﻴﹰﺎ‪-‬ﻭﻫﻮ ﳕﻮﺫﺝ ﻋﻤﻞ "ﺳﺮﻳﻊ ﻭﻧﺎﻗﺺ" ﻳﺘﻀﻤﻦ ﻭﺍﺟﻬﺔ‬
‫ﺍﺳﺘﺨﺪﺍﻡ ﺑﻴﺎﻧﻴﺔ )‪ (GUI‬ﻭﳛﺎﻛﻲ ﺳﻠﻮﻙ ﺍﻟﻨﻈﺎﻡ ﺇﺯﺍﺀ ﺃﺣﺪﺍﺙ ﳐﺘﻠﻔﺔ‪ ،‬ﻭﺗﺜﺒﺖ ﺍﳌﻌﻠﻮﻣﺎﺕ ﺍﶈﺘﻮﺍﺓ ﰲ‬
‫ﻭﺍﺟﻬﺎﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ ﺿﻤﻦ ﺑﺮﻧﺎﻣﺞ ﺍﻟﻨﻤﻮﺫﺝ ﺍﻷﻭﱄ ﺑﺪ ﹰﻻ ﻣﻦ ﺍﳊﺼﻮﻝ ﻋﻠﻴﻬﺎ ﺩﻳﻨﺎﻣﻴﻜﻴﹰﺎ ﻣﻦ ﻗﺎﻋﺪﺓ‬
‫ﺍﳌﻌﻄﻴﺎﺕ‪.‬‬
‫ﻭﻧﻈﺮﹰﺍ ﻟﺘﻌﻘﻴﺪ ﻭﺍﺟﻬﺎﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ ﺍﻟﺒﻴﺎﻧﻴﺔ ﺍﳊﺪﻳﺜﺔ )ﻭﺗﻨﺎﻣﻲ ﺗﻮﻗﻌﺎﺕ ﺍﻟﺰﺑﺎﺋﻦ( ﻓﻘﺪ ﺃﺻﺒﺤﺖ‬
‫ﺍﻟﻨﻤﺬﺟﺔ ﺍﻷﻭﻟﻴﺔ ﻋﻨﺼﺮﹰﺍ ﺃﺳﺎﺳﻴﹰﺎ ﰲ ﻋﻤﻠﻴﺔ ﺗﻄﻮﻳﺮ ﺍﻟﱪﳎﻴﺎﺕ‪ ،‬ﻭﺑﻔﻀﻠﻬﺎ ﺃﺻﺒﺢ ﺑﺎﻹﻣﻜﺎﻥ ﺗﻘﺪﻳﺮ‬
‫ﺟﺪﻭﻯ ﺍﻟﻨﻈﺎﻡ ﻭﻓﺎﺋﺪﺗﻪ ﻗﺒﻞ ﺍﻟﺒﺪﺀ ﺑﺘﺤﻘﻴﻘﻪ ﻓﻌﻠﻴﹰﺎ‪.‬‬
‫ﺗﺸﻜﻞ ﺍﻟﻨﻤﺎﺫﺝ ﺍﻷﻭﻟﻴﺔ ﻋﻤﻮﻣﹰﺎ ﻃﺮﻳﻘﺔ ﻓﻌﺎﻟﺔ ﺟﺪﹰﺍ ﻻﺳﺘﻨﺘﺎﺝ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻟﱵ ﻳﺼﻌﺐ ﺍﳊﺼﻮﻝ ﻋﻠﻴﻬﺎ‬
‫ﻣﻦ ﺍﻟﺰﺑﺎﺋﻦ ﺑﺎﻟﻮﺳﺎﺋﻞ ﺍﻷﺧﺮﻯ‪ ،‬ﻭﻧﺼﺎﺩﻑ ﻫﺬﻩ ﺍﳊﺎﻟﺔ ﻏﺎﻟﺒﹰﺎ ﻋﻨﺪ ﺗﻄﻮﻳﺮ ﺃﻧﻈﻤﺔ ﲢﻘﻖ ﻭﻇﺎﺋﻒ ﺃﻋﻤﺎﻝ‬
‫ﺟﺪﻳﺪﺓ‪ ،‬ﻛﻤﺎ ﻧﺼﺎﺩﻑ ﻫﺬﻩ ﺍﳊﺎﻟﺔ ﺃﻳﻀﹰﺎ ﻋﻨﺪﻣﺎ ﺗﻈﻬﺮ ﺗﻨﺎﻗﻀﺎﺕ ﺑﲔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺃﻭ ﻋﻨﺪﻣﺎ ﺗﻈﻬﺮ‬
‫ﻣﺸﺎﻛﻞ ﰲ ﺍﻟﺘﻮﺍﺻﻞ ﺑﲔ ﺍﻟﺰﺑﺎﺋﻦ ﻭﺍﳌﻄﻮﺭﻳﻦ‪.‬‬
‫ﻳﻮﺟﺪ ﻧﻮﻋﺎﻥ ﻣﻦ ﺍﻟﻨﻤﺎﺫﺝ ﺍﻷﻭﻟﻴﺔ )‪:(Kotonya and Sommerville, 1998‬‬
‫ﺍﻟﻨﻤﻮﺫﺝ ﺍﻷﻭﱄ ﺍﳌﻌﺪ ﻟﻺﳘﺎﻝ )‪ ،(Throw-away‬ﻭﻫﻮ ﺍﻟﻨﻤﻮﺫﺝ ﺍﻟﺬﻱ ﻳﺸﻄﺐ ﻛﻠﻴﹰﺎ ﺑﻌﺪ‬ ‫™‬
‫ﺍﻛﺘﻤﺎﻝ ﺍﺳﺘﻨﺘﺎﺝ ﺍﳌﺘﻄﻠﺒﺎﺕ‪ ،‬ﻭﻳﺪﻋﻢ ﻫﺬﺍ ﺍﻟﻨﻤﻮﺫﺝ ﻣﺮﺣﻠﺔ ﲢﺪﻳﺪ ﺍﳌﺘﻄﻠﺒﺎﺕ ﰲ ﺩﻭﺭﺓ ﺣﻴﺎﺓ‬
‫ﺍﻟﺘﻄﻮﻳﺮ‪ ،‬ﻭﻫﻮ ﻳﺮﻛﺰ ﻋﺎﺩﺓ ﻋﻠﻰ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻷﻗﻞ ﻭﺿﻮﺣﹰﺎ‪.‬‬
‫ﺍﻟﻨﻤﻮﺫﺝ ﺍﻟﺘﻄﻮﺭﻱ‪ ،‬ﻭﻫﻮ ﺍﻟﻨﻤﻮﺫﺝ ﺍﻟﺬﻱ ﳛﻔﻆ ﺑﻌﺪ ﺍﺳﺘﻨﺘﺎﺝ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﻳﺴﺘﺨﺪﻡ ﻹﻋﺪﺍﺩ‬ ‫™‬
‫ﺍﳌﻨﺘﺞ ﺍﻟﻨﻬﺎﺋﻲ‪ .‬ﻭﻳﻬﺪﻑ ﺍﻟﻨﻤﻮﺫﺝ ﺍﻟﺘﻄﻮﺭﻱ ﺇﱃ ﺗﺴﺮﻳﻊ ﺗﺴﻠﻴﻢ ﺍﳌﻨﺘﺞ‪ ،‬ﻭﻫﻮ ﻳﺮﻛﺰ ﻋﺎﺩﺓ ﻋﻠﻰ‬
‫ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻷﻛﺜﺮ ﻭﺿﻮﺣﹰﺎ ﲝﻴﺚ ﳝﻜﻦ ﺗﺴﻠﻴﻢ ﺍﻹﺻﺪﺍﺭ ﺍﻷﻭﻝ ﻣﻦ ﺍﳌﻨﺘﺞ ﺑﺴﺮﻋﺔ )ﺣﱴ ﻟﻮ ﻛﺎﻥ‬
‫ﻏﲑ ﻛﺎﻣﻞ ﻭﻇﻴﻔﻴﹰﺎ(‪.‬‬
‫ﻧﻔﻀﻞ ﻋﻤﻮﻣﹰﺎ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﻨﻤﺎﺫﺝ ﺍﻷﻭﻟﻴﺔ ﺍﳌﻌﺪﺓ ﻟﻺﳘﺎﻝ‪ ،‬ﻓﺒﺬﻟﻚ ﻧﺘﺠﻨﺐ ﳐﺎﻃﺮ ﺑﻘﺎﺀ ﺣﻠﻮﻝ ﻏﲑ‬
‫ﻓﻌﺎﻟﺔ ﺃﻭ ﺇﺟﺮﺍﺀﺍﺕ ﺳﺮﻳﻌﺔ ﻭﻧﺎﻗﺼﺔ ﰲ ﺍﳌﻨﺘﺞ ﺍﻟﻨﻬﺎﺋﻲ‪ ،‬ﻟﻜﻦ ﺗﻄﻮﺭ ﻭﻣﺮﻭﻧﺔ ﺃﺩﻭﺍﺕ ﺇﻧﺘﺎﺝ ﺍﻟﱪﳎﻴﺎﺕ‬
‫ﺍﳌﻮﺟﻮﺩﺓ ﺣﺎﻟﻴﹰﺎ ﻗﺪ ﺃﺿﻌﻔﺖ ﺃﳘﻴﺔ ﻫﺬﻩ ﺍﳊﺠﺔ ﻓﺒﻮﺟﻮﺩ ﺇﺩﺍﺭﺓ ﺟﻴﺪﺓ ﻟﻠﻤﺸﺮﻭﻉ ﻟﻴﺲ ﲦﺔ ﻣﺎ ﳝﻨﻊ ﻣﻦ‬
‫‪113‬‬ ‫‪ : 3‬ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت‬

‫ﺍﻟﺘﺨﻠﺺ ﻣﻦ ﺍﳊﻠﻮﻝ ﻏﲑ ﺍﻟﻔﻌﺎﻟﺔ ﺍﳌﻮﺟﻮﺩﺓ ﰲ ﺍﻟﻨﻤﺎﺫﺝ ﺍﻷﻭﻟﻴﺔ‪.‬‬

‫ﺗﻄﻮﻳﺮ اﻟﺘﻄﺒﻴﻘﺎت اﻟﻤﺸﺘﺮك‬ ‫‪2-2-2-3‬‬

‫ﻛﻤﺎ ﻳﺸﲑ ﺍﲰﻬﺎ ﺗﻌﺘﻤﺪ ﻫﺬﻩ ﺍﻟﻄﺮﻳﻘﺔ ﻋﻠﻰ ﺇﻗﺎﻣﺔ ﻭﺭﺷﺔ ﻋﻤﻞ ﺃﻭ ﺃﻛﺜﺮ ﲡﻤﻊ ﻛﻞ ﺍﳌﻌﻨﻴﲔ ﺑﺎﳌﺸﺮﻭﻉ‬
‫)ﻣﻦ ﺯﺑﺎﺋﻦ ﻭﻣﻄﻮﺭﻳﻦ( )‪ ،(Wood and Silver, 1955‬ﻭﻣﻊ ﺃﻧﻨﺎ ﻧﺼﻨﻔﻬﺎ ﺑﲔ ﺍﻟﻄﺮﺍﺋﻖ ﺍﳊﺪﻳﺜﺔ ﻓﻘﺪ‬
‫ﻋﺮﺿﺘﻬﺎ ﺷﺮﻛﺔ ‪ IBM‬ﰲ ﺃﻭﺍﺧﺮ ﺍﻟﺴﺒﻌﻴﻨﺎﺕ‪.‬‬
‫ﳝﻜﻦ ﺃﻥ ﺗﻄﺒﻖ ﻫﺬﻩ ﺍﻟﻄﺮﻳﻘﺔ ﺑﺼﻴﻎ ﻣﺘﻨﻮﻋﺔ‪ ،‬ﻭﺗﻌﺮﺽ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺍﻟﺸﺮﻛﺎﺕ ﺍﻻﺳﺘﺸﺎﺭﻳﺔ ﺧﺪﻣﺔ‬
‫ﺗﻨﻈﻴﻢ ﻭﺇﺟﺮﺍﺀ ﺟﻠﺴﺎﺕ ﺍﻟﺘﻄﻮﻳﺮ ﺍﳌﺸﺘﺮﻙ‪ .‬ﻭﻗﺪ ﻳﺴﺘﻐﺮﻕ ﺍﻻﺟﺘﻤﺎﻉ ﻋﺪﺓ ﺳﺎﻋﺎﺕ ﺃﻭ ﻋﺪﺓ ﺃﻳﺎﻡ ﺃﻭ‬
‫ﺣﱴ ﺃﺳﺒﻮﻋﲔ‪ ،‬ﻭﳚﺐ ﺃﻻ ﻳﺘﺠﺎﻭﺯ ﻋﺪﺩ ﺍﳌﺸﺎﺭﻛﲔ ﻣﻦ ‪ 25‬ﺇﱃ ‪ 30‬ﺷﺨﺼﺎﹰ‪ ،‬ﻭﺍﳌﺸﺎﺭﻛﻮﻥ ﻫﻢ‬
‫);‪:(Whitten and Bentley, 1998; Hoffer et al, 1996‬‬
‫ﺍﻟﻘﺎﺋﺪ‪ ،‬ﻭﻫﻮ ﺍﻟﺸﺨﺺ ﺍﻟﺬﻱ ﻳﺪﻳﺮ ﺍﻻﺟﺘﻤﺎﻋﺎﺕ ﻭﻳﻀﺒﻄﻬﺎ‪ ،‬ﻭﻳﺘﻤﺘﻊ ﻋﺎﺩﺓ ﲟﻬﺎﺭﺍﺕ ﺗﻮﺍﺻﻞ‬ ‫™‬
‫ﳑﺘﺎﺯﺓ‪ ،‬ﻭﻫﻮ ﻟﻴﺲ ﻣﻌﻨﻴﹰﺎ ﺑﺎﳌﺸﺮﻭﻉ )ﻓﻴﻤﺎ ﻋﺪﺍ ﺃﻧﻪ ﻗﺎﺋﺪ ﺍﻻﺟﺘﻤﺎﻋﺎﺕ(‪ ،‬ﻭﳝﺘﻠﻚ ﻣﻌﺮﻓﺔ ﺟﻴﺪﺓ‬
‫ﲟﺠﺎﻝ ﺍﻟﻌﻤﻞ )ﻟﻜﻦ ﻻ ﳝﺘﻠﻚ ﺑﺎﻟﻀﺮﻭﺭﺓ ﻣﻌﺮﻓﺔ ﺟﻴﺪﺓ ﺑﺘﻄﻮﻳﺮ ﺍﻟﱪﳎﻴﺎﺕ(‪.‬‬
‫ﺍﳌﻘﺮﺭ‪ ،‬ﻭﻫﻮ ﺍﻟﺸﺨﺺ ﺍﻟﺬﻱ ﻳﺴﺠﻞ ﺟﻠﺴﺎﺕ ﺍﻟﺘﻄﻮﻳﺮ ﺍﳌﺸﺘﺮﻙ ﻋﻠﻰ ﺍﳊﺎﺳﻮﺏ‪ ،‬ﻭﳚﺐ ﺃﻥ‬ ‫™‬
‫ﳝﺘﻠﻚ ﻣﻬﺎﺭﺍﺕ ﻃﺒﺎﻋﻴﺔ ﻭﻣﻌﺮﻓﺔ ﺟﻴﺪﺓ ﺑﺘﻄﻮﻳﺮ ﺍﻟﱪﳎﻴﺎﺕ‪ .‬ﻭﳝﻜﻦ ﻟﻠﻤﻘﺮﺭ ﺃﻥ ﻳﺴﺘﺨﺪﻡ ﺍﻷﺩﻭﺍﺕ‬
‫ﺍﳌﺴﺎﻧﺪﺓ ﰲ ﻫﻨﺪﺳﺔ ﺍﻟﱪﳎﻴﺎﺕ ﻟﺘﻮﺛﻴﻖ ﺍﳉﻠﺴﺎﺕ ﻭﺗﻄﻮﻳﺮ ﳕﺎﺫﺝ ﺑﺪﺍﺋﻴﺔ ﻟﻠﻌﻤﻞ‪.‬‬
‫ﺍﻟﺰﺑﺎﺋﻦ )ﺍﳌﺴﺘﺨﺪﻣﻮﻥ ﻭﺍﳌﺪﺭﺍﺀ(‪ ،‬ﻭﻫﻢ ﺍﳌﺸﺎﺭﻛﻮﻥ ﺍﻟﺮﺋﻴﺴﻴﻮﻥ ﺍﻟﺬﻳﻦ ﻳﺘﻮﺍﺻﻠﻮﻥ ﻓﻴﻤﺎ ﺑﻴﻨﻬﻢ‬ ‫™‬
‫ﻭﻳﻨﺎﻗﺸﻮﻥ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﻳﺄﺧﺬﻭﻥ ﺍﻟﻘﺮﺍﺭﺍﺕ ﻭﳛﺪﺩﻭﻥ ﺃﻫﺪﺍﻑ ﺍﳌﺸﺮﻭﻉ‪.‬‬
‫ﺍﳌﻄﻮﺭﻭﻥ‪ ،‬ﻭﻫﻢ ﳏﻠﻠﻮ ﺍﻷﻋﻤﺎﻝ ﻭﺃﻋﻀﺎﺀ ﺁﺧﺮﻭﻥ ﻣﻦ ﻓﺮﻳﻖ ﺍﻟﺘﻄﻮﻳﺮ‪ ،‬ﻭﻫﻢ ﻳﺼﻐﻮﻥ ﺃﻛﺜﺮ ﳑﺎ‬ ‫™‬
‫ﻳﺘﻜﻠﻤﻮﻥ‪ ،‬ﻓﻬﻢ ﻣﻮﺟﻮﺩﻭﻥ ﰲ ﺍﻻﺟﺘﻤﺎﻉ ﻬﺑﺪﻑ ﺍﻟﺒﺤﺚ ﻋﻦ ﺍﳊﻘﺎﺋﻖ ﻭﲨﻊ ﺍﳌﻌﻠﻮﻣﺎﺕ ﻭﻟﻴﺲ‬
‫ﻬﺑﺪﻑ ﺍﻟﺴﻴﻄﺮﺓ ﻋﻠﻰ ﺍﻟﻌﻤﻠﻴﺔ‪.‬‬
‫ﺗﺴﺘﻔﻴﺪ ﻃﺮﻳﻘﺔ ﺍﻟﺘﻄﻮﻳﺮ ﺍﳌﺸﺘﺮﻙ ﻣﻦ ﺩﻳﻨﺎﻣﻜﻴﺔ ﺍﺠﻤﻟﻤﻮﻋﺔ ﺍﻟﱵ ﺗﻌﻄﻲ ﻏﺎﻟﺒﹰﺎ ﺣﻠﻮ ﹰﻻ ﺃﻓﻀﻞ‪ ،‬ﻓﺎﺠﻤﻟﻤﻮﻋﺔ ﺗﺰﻳﺪ‬
‫ﺍﻹﻧﺘﺎﺟﻴﺔ‪ ،‬ﻭﺗﺘﻌﻠﻢ ﺃﺳﺮﻉ‪ ،‬ﻭﺗﺼﻞ ﺇﱃ ﺃﺣﻜﺎﻡ ﺃﻛﺜﺮ ﻧﻀﺠﺎﹰ‪ ،‬ﻭﲢﺬﻑ ﺃﺧﻄﺎﺀ ﺃﻛﺜﺮ‪ ،‬ﻭﺗﺄﺧﺬ ﻗﺮﺍﺭﺍﺕ ﺃﺧﻄﺮ‬
‫)ﻗﺪ ﻳﻜﻮﻥ ﻫﺬﺍ ﺳﻠﺒﻴﹰﺎ(‪ ،‬ﻭﺗﺸﺪ ﺍﻫﺘﻤﺎﻡ ﺍﳌﺸﺎﺭﻛﲔ ﳓﻮ ﺍﳌﻮﺍﺿﻴﻊ ﺍﻷﻛﺜﺮ ﺃﳘﻴﺔ‪ ،‬ﻭﺗﻜﺎﻣﻞ ﺟﻬﻮﺩ ﺍﻷﻓﺮﺍﺩ‪ .‬ﻭﺇﺫﺍ‬
‫ﺃﺟﺮﻳﺖ ﺟﻠﺴﺎﺕ ﺍﻟﺘﻄﻮﻳﺮ ﺍﳌﺸﺘﺮﻙ ﺗﺒﻌﹰﺎ ﻟﻠﻘﻮﺍﻋﺪ ﺗﻌﻄﻲ ﻧﺘﺎﺋﺞ ﺟﻴﺪﺓ ﻋﻠﻰ ﳓﻮ ﻏﲑ ﻣﺘﻮﻗﻊ‪ ،‬ﻟﻜﻦ ﳚﺐ‬
‫ﺗﻮﺧﻲ ﺍﳊﺬﺭ ﻫﻨﺎ ﻓﻘﺪ "‪ ...‬ﻋﺎﻧﺖ ﺷﺮﻛﺔ ‪ Ford Motor Co.‬ﰲ ﺍﳋﻤﺴﻴﻨﺎﺕ ﻣﻦ ﻛﺎﺭﺛﺔ ﺗﺴﻮﻳﻘﻴﺔ‬
‫ﺑﺎﻟﻨﺴﺒﺔ ﻟﻠﺴﻴﺎﺭﺓ ‪ - Edsel‬ﻭﻫﻲ ﺳﻴﺎﺭﺓ ﺻﻤﻤﺘﻬﺎ ﳉﻨﺔ"‪.(Wood and Silver, 1995) .‬‬
‫ﺗﻄﻮﻳﺮ اﻟﺘﻄﺒﻴﻘﺎت اﻟﺴﺮﻳﻊ‬ ‫‪3-2-2-3‬‬
‫اﻟﻔﺼﻞ اﻟﺜﺎﻟﺚ‬ ‫‪114‬‬

‫ﺇﻥ ﺗﻄﻮﻳﺮ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻟﺴﺮﻳﻊ ﻫﻮ ﺃﻛﺜﺮ ﻣﻦ ﳎﺮﺩ ﻃﺮﻳﻘﺔ ﻻﺳﺘﻨﺘﺎﺝ ﺍﳌﺘﻄﻠﺒﺎﺕ‪ ،‬ﻭﻫﻮ ﰲ ﺍﻟﻮﺍﻗﻊ ﻣﻨﻬﺞ‬
‫ﻟﺘﻄﻮﻳﺮ ﺍﻟﱪﳎﻴﺎﺕ ﻛﻜﻞ )‪ .(Hoffer et al, 1996‬ﻭﻛﻤﺎ ﻳﺸﲑ ﺍﲰﻬﺎ ﻬﺗﺪﻑ ﻫﺬﻩ ﺍﻟﻄﺮﻳﻘﺔ ﺇﱃ ﺗﺴﻠﻴﻢ‬
‫ﺣﻠﻮﻝ ﺍﻟﻨﻈﺎﻡ ﺑﺴﺮﻋﺔ‪ ،‬ﺃﻣﺎ ﺍﳉﻮﺩﺓ ﺍﻟﺘﻘﻨﻴﺔ ﻓﻬﻲ ﺛﺎﻧﻮﻳﺔ ﺑﺎﻟﻨﺴﺒﺔ ﻟﺴﺮﻋﺔ ﺍﻟﺘﺴﻠﻴﻢ‪.‬‬
‫ﲡﻤﻊ ﻫﺬﻩ ﺍﻟﻄﺮﻳﻘﺔ ﺑﲔ ﲬﺲ ﺗﻘﻨﻴﺎﺕ )‪:(Wood and Silver, 1995‬‬
‫ﺇﻧﺸﺎﺀ ﺍﻟﻨﻤﺎﺫﺝ ﺍﻷﻭﻟﻴﺔ ﺍﻟﺘﻄﻮﺭﻳﺔ )ﺍﻟﻔﻘﺮﺓ ‪.(1-2-2-3‬‬ ‫™‬

‫ﺍﻷﺩﻭﺍﺕ ﺍﳌﺴﺎﻧﺪﺓ ﰲ ﻫﻨﺪﺳﺔ ﺍﻟﱪﳎﻴﺎﺕ ﺍﳌﺰﻭﺩﺓ ﺑﺈﻣﻜﺎﻧﻴﺔ ﺗﻮﻟﻴﺪ ﺍﻟﺮﻣﺎﺯ ﻭﺑﺈﻣﻜﺎﻧﻴﺔ ﺗﺼﺤﻴﺢ ﳕﺎﺫﺝ‬ ‫™‬
‫ﺍﻟﺘﺼﻤﻴﻢ ﺍﻧﻄﻼﻗﹰﺎ ﻣﻦ ﺍﻟﺮﻣﺎﺯ‪.‬‬
‫ﺃﺧﺼﺎﺋﻴﲔ ﳝﻠﻜﻮﻥ ﺃﺩﻭﺍﺕ ﻣﺘﻘﺪﻣﺔ )ﺃﻭ ‪ (Specialists with Advanced Toals:SWAT‬ﻭﻫﻢ ﰲ‬ ‫™‬
‫ﺍﻟﻮﺍﻗﻊ ﻓﺮﻳﻖ ﺍﻟﺘﻄﻮﻳﺮ ﺍﳌﺆﻟﻒ ﻣﻦ ﺃﻓﻀﻞ ﺍﶈﻠﻠﲔ ﻭﺍﳌﺼﻤﻤﲔ ﻭﺍﳌﱪﳎﲔ ﺍﻟﺬﻳﻦ ﺗﺴﺘﻄﻴﻊ ﺍﳌﺆﺳﺴﺔ‬
‫ﺗﻮﻇﻴﻔﻬﻢ‪ .‬ﻳﻌﻤﻞ ﺃﻋﻀﺎﺀ ﺍﻟﻔﺮﻳﻖ ﲢﺖ ﻗﻴﻮﺩ ﺯﻣﻨﻴﺔ ﺩﻗﻴﻘﺔ ﻭﻳﺒﻘﻮﻥ ﻣﻊ ﺍﳌﺴﺘﺨﺪﻣﲔ ﰲ ﺍﳌﻮﻗﻊ‬
‫ﻧﻔﺴﻪ‪.‬‬
‫ﺍﻟﺘﻄﻮﻳﺮ ﺍﳌﺸﺘﺮﻙ ﺍﻟﺘﻔﺎﻋﻠﻲ‪ ،‬ﻭﻫﻲ ﺟﻠﺴﺔ ﺗﻄﻮﻳﺮ ﻣﺸﺘﺮﻙ )ﺍﻟﻔﻘﺮﺓ ‪ (2-2-2-3‬ﻳﺴﺘﺒﺪﻝ ﻓﻴﻬﺎ ﺍﳌﻘﺮﺭ‬ ‫™‬
‫ﺑﺎﻟﻔﺮﻳﻖ ‪ SWAT‬ﺍﳌﺰﻭﺩ ﺑﺄﺩﻭﺍﺕ ﻣﺴﺎﻧﺪﺓ ﰲ ﻫﻨﺪﺳﺔ ﺍﻟﱪﳎﻴﺎﺕ‪.‬‬
‫ﺍﻟﺘﻘﻴﻴﺪ ﺍﻟﺰﻣﲏ‪ ،‬ﻭﻫﻮ ﻃﺮﻳﻘﺔ ﰲ ﺇﺩﺍﺭﺓ ﺍﳌﺸﺎﺭﻳﻊ ﺗﻔﺮﺽ ﻋﻠﻰ ﺍﻟﻔﺮﻳﻖ ‪ SWAT‬ﺃﻥ ﻳﻨﺠﺰ ﺍﳌﺸﺮﻭﻉ‬ ‫™‬
‫ﺧﻼﻝ ﻓﺘﺮﺓ ﺯﻣﻨﻴﺔ ﺛﺎﺑﺘﺔ‪ .‬ﲤﻨﻊ ﻫﺬﻩ ﺍﻟﻄﺮﻳﻘﺔ ﺍﻣﺘﺪﺍﺩ ﻧﻄﺎﻕ ﺍﳌﺸﺮﻭﻉ‪ ،‬ﻓﺈﺫﺍ ﻛﺎﻥ ﺍﳌﺸﺮﻭﻉ ﻣﺘﺄﺧﺮﹰﺍ‬
‫ﻳُﻘﻠﺺ ﻧﻄﺎﻕ ﺍﳊﻞ ﲝﻴﺚ ﳝﻜﻦ ﺇﳒﺎﺯ ﺍﳌﺸﺮﻭﻉ ﺧﻼﻝ ﺍﻟﻮﻗﺖ ﺍﶈﺪﺩ‪.‬‬
‫ﺗﻌﺘﱪ ﻃﺮﻳﻘﺔ ﺍﻟﺘﻄﻮﻳﺮ ﺍﻟﺴﺮﻳﻊ ﻣﻨﺎﺳﺒﺔ ﺟﺪﹰﺍ ﻟﻠﻌﺪﻳﺪ ﻣﻦ ﺍﳌﺸﺎﺭﻳﻊ ﺍﻟﺼﻐﲑﺓ ﺍﻟﱵ ﻻ ﺗﺘﻨﺎﻭﻝ ﺃﻋﻤﺎﻝ‬
‫ﺍﳌﺆﺳﺴﺔ ﺍﳌﺮﻛﺰﻳﺔ ﻭﺍﻟﱵ ﻻ ﺗﺆﺛﺮ ﺑﺎﻟﺘﺎﱄ ﻋﻠﻰ ﺭﻭﺯﻧﺎﻣﺔ ﺗﻄﻮﻳﺮ ﺍﳌﺸﺎﺭﻳﻊ ﺍﻷﺧﺮﻯ‪ ،‬ﻓﺎﳊﻠﻮﻝ ﺍﻟﺴﺮﻳﻌﺔ‬
‫ﻧﺎﺩﺭﹰﺍ ﻣﺎ ﺗﻜﻮﻥ ﺃﻣﺜﻠﻴﺔ ﻭﺩﺍﻋﻤﺔ ﺠﻤﻟﺎﻻﺕ ﺍﻟﻌﻤﻞ ﺍﳌﺮﻛﺰﻳﺔ‪ .‬ﻭﻣﻦ ﺍﳌﺸﺎﻛﻞ ﺍﻟﱵ ﺗﻌﺘﺮﺽ ﻫﺬﻩ ﺍﻟﻄﺮﻳﻘﺔ‪:‬‬
‫ﻋﺪﻡ ﺍﻧﺴﺠﺎﻡ ﺗﺼﺎﻣﻴﻢ ﻭﺍﺟﻬﺎﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ ﺍﻟﺒﻴﺎﻧﻴﺔ‪.‬‬ ‫‪.1‬‬

‫ﺍﻟﻮﺻﻮﻝ ﺇﱃ ﺣﻠﻮﻝ ﲣﺼﺼﻴﺔ ﺑﺪ ﹰﻻ ﻣﻦ ﺣﻠﻮﻝ ﻋﺎﻣﺔ ﺗﺴﻬﻞ ﺇﻋﺎﺩﺓ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﱪﳎﻴﺎﺕ‪.‬‬ ‫‪.2‬‬

‫ﺍﳊﺼﻮﻝ ﻋﻠﻰ ﺗﻮﺛﻴﻖ ﺿﻌﻴﻒ ﺃﻭ ﻧﺎﻗﺺ‪.‬‬ ‫‪.3‬‬

‫ﺻﻌﻮﺑﺔ ﺻﻴﺎﻧﺔ ﺍﻟﱪﳎﻴﺎﺕ ﻭﺗﻮﺳﻴﻌﻬﺎ ﺗﺪﺭﺟﻴﹰﺎ‪.‬‬ ‫‪.4‬‬

‫ﻡﻨﺎﻗﺸﺔ اﻟﻤﺘﻄﻠﺒﺎت واﻟﺘﺤﻘﻖ ﻡﻦ ﺹﻼﺡﻴﺘﻬﺎ‬ ‫‪3-3‬‬

‫‪115‬‬ ‫‪ : 3‬ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت‬

‫ﻗﺪ ﺗﺘﻘﺎﻃﻊ‪ ،‬ﺃﻭ ﺣﱴ ﺗﺘﻀﺎﺭﺏ‪ ،‬ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻟﱵ ﺟﺮﻯ ﺍﺳﺘﻨﺘﺎﺟﻬﺎ ﻣﻦ ﺍﻟﺰﺑﺎﺋﻦ‪ ،‬ﻭﻗﺪ ﺗﻜﻮﻥ ﺑﻌﺾ‬
‫ﺍﳌﺘﻄﻠﺒﺎﺕ ﻏﺎﻣﻀﺔ ﺃﻭ ﻏﲑ ﻭﺍﻗﻌﻴﺔ‪ ،‬ﻓﻴﻤﺎ ﻗﺪ ﻳﺒﻘﻰ ﺑﻌﻀﻬﺎ ﺍﻵﺧﺮ ﺩﻭﻥ ﺍﻛﺘﺸﺎﻑ‪ ،‬ﻭﻟﺬﻟﻚ ﲡﺐ‬
‫ﻣﺮﺍﺟﻌﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﺍﻟﺘﺤﻘﻖ ﻣﻦ ﺻﻼﺣﻴﺘﻬﺎ ﻗﺒﻞ ﺃﻥ ﲡﺪ ﻃﺮﻳﻘﻬﺎ ﺇﱃ ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ‪.‬‬
‫ﲡﺮﻱ ﻫﺬﻩ ﺍﻟﻌﻤﻠﻴﺔ ﰲ ﺍﻟﻮﺍﻗﻊ ﻋﻠﻰ ﺍﻟﺘﻮﺍﺯﻱ ﻣﻊ ﻋﻤﻠﻴﺔ ﺍﺳﺘﻨﺘﺎﺝ ﺍﳌﺘﻄﻠﺒﺎﺕ‪ ،‬ﻓﺘﺨﻀﻊ ﻫﺬﻩ ﺍﳌﺘﻄﻠﺒﺎﺕ‬
‫ﻓﻮﺭ ﺍﺳﺘﻨﺘﺎﺟﻬﺎ ﺇﱃ ﻋﻤﻠﻴﺔ ﺗﻔﺤﺺ ﻭﺗﺪﻗﻴﻖ ﻭﻳﺘﻢ ﺫﻟﻚ ﻋﱪ ﻣﺎ ﻧﺴﻤﻴﻪ ﺩﻳﻨﺎﻣﻴﻜﻴﺔ ﺍﺠﻤﻟﻤﻮﻋﺔ ﺍﳌﺴﺘﺨﺪﻣﺔ‬
‫ﰲ ﻛﻞ ﺍﻟﻄﺮﺍﺋﻖ ﺍﳊﺪﻳﺜﺔ‪ .‬ﻭﺑﻌﺪ ﺃﻥ ﲡﻤﻊ ﺍﳌﺘﻄﻠﺒﺎﺕ ﳚﺐ ﺇﺧﻀﺎﻋﻬﺎ ﻣﻦ ﺟﺪﻳﺪ ﻟﻠﻤﻨﺎﻗﺸﺔ ﻭﺍﻟﺘﺪﻗﻴﻖ‪.‬‬
‫ﻻ ﳝﻜﻦ ﺃﻥ ﲡﺮﻱ ﻋﻤﻠﻴﺔ ﺗﺪﻗﻴﻖ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﺍﻟﺘﺤﻘﻖ ﻣﻦ ﺻﻼﺣﻴﺘﻬﺎ ﺑﺎﺳﺘﻘﻼﻝ ﻋﻦ ﻋﻤﻠﻴﺔ ﻛﺘﺎﺑﺔ‬
‫ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ‪ ،‬ﺑﻞ ﲡﺮﻱ ﺍﳌﻨﺎﻗﺸﺔ ﻋﺎﺩﺓ ﺑﺎﻻﻋﺘﻤﺎﺩ ﻋﻠﻰ ﻣﺴﻮﺩﺓ ﻫﺬﻩ ﺍﻟﻮﺛﻴﻘﺔ ﻟﻴﺠﺮﻱ ﺗﻌﺪﻳﻠﻬﺎ ﻋﻨﺪ‬
‫ﺍﻟﻀﺮﻭﺭﺓ‪ ،‬ﻓﺘﺤﺬﻑ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻟﺰﺍﺋﻔﺔ ﻭﺗﻀﺎﻑ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻟﱵ ﺍﻛﺘﺸﻔﺖ ﺣﺪﻳﺜﹰﺎ‪.‬‬
‫ﺃﻣﺎ ﺍﻟﺘﺤﻘﻖ ﻣﻦ ﺻﻼﺣﻴﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻓﻴﺤﺘﺎﺝ ﻟﻮﺟﻮﺩ ﻭﺛﻴﻘﺔ ﻣﺘﻄﻠﺒﺎﺕ ﺃﻛﺜﺮ ﻛﻤﺎ ﹰﻻ ﺗﻈﻬﺮ ﻓﻴﻬﺎ‬
‫ﺑﻮﺿﻮﺡ ﻛﻞ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺑﻌﺪ ﺗﺼﻨﻴﻔﻬﺎ‪ ،‬ﲝﻴﺚ ﻳﺘﻤﻜﻦ ﺍﳌﻌﻨﻴﻮﻥ ﻣﻦ ﻗﺮﺍﺀﺓ ﺍﻟﻮﺛﻴﻘﺔ ﻭﻋﻘﺪ ﺍﺟﺘﻤﺎﻋﺎﺕ‬
‫ﻣﺮﺍﺟﻌﺔ ﺭﲰﻴﺔ‪ ،‬ﻭﺍﳌﺮﺍﺟﻌﺎﺕ ﻫﻨﺎ ﻫﻲ ﺇﺣﺪﻯ ﺻﻴﻎ ﺍﻻﺧﺘﺒﺎﺭ )ﺍﻧﻈﺮ ﺍﻟﻔﻘﺮﺓ ‪.(1-1-10‬‬

‫‪ 1-3-3‬اﻟﻤﺘﻄﻠﺒﺎت اﻟﺘﻲ ﺗﻘﻊ ﺥﺎرج ﻥﻄﺎق اﻟﻤﺸﺮوع‬

‫ﻳﺘﻢ ﺍﺧﺘﻴﺎﺭ ﺍﳌﺸﺎﺭﻳﻊ ﺍﻟﱪﳎﻴﺔ‪ ،‬ﻭﺑﺎﻟﺘﺎﱄ ﺍﻟﻨﻈﻢ ﺍﻟﱵ ﳚﺐ ﲢﻘﻴﻘﻬﺎ )ﻭﻧﻄﺎﻗﺎﻬﺗﺎ( ﻣﻦ ﺧﻼﻝ ﺃﻧﺸﻄﺔ‬
‫ﲣﻄﻴﻂ ﺍﻟﻨﻈﺎﻡ )ﺍﻟﻔﻘﺮﺓ ‪ ،(2-1‬ﻟﻜﻦ ﻻ ﳝﻜﻦ ﻛﺸﻒ ﺍﻻﺭﺗﺒﺎﻃﺎﺕ ﺍﻟﺘﻔﺼﻴﻠﻴﺔ ﺑﲔ ﺍﻟﻨﻈﻢ ﺇﻻ ﰲ ﻣﺮﺣﻠﺔ‬
‫ﲢﻠﻴﻞ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻟﱵ ﳚﺮﻱ ﻓﻴﻬﺎ ﲢﺪﻳﺪ ﺣﺪﻭﺩ ﺍﻟﻨﻈﺎﻡ )ﺃﻭ ﻧﻄﺎﻗﻪ( ﲝﻴﺚ ﳝﻜﻦ ﺿﺒﻂ ﻫﺬﻩ ﺍﳊﺪﻭﺩ‬
‫ﻣﻨﺬ ﻣﺮﺍﺣﻞ ﺍﻟﺘﻄﻮﻳﺮ ﺍﻷﻭﱃ‪.‬‬
‫ﳛﺘﺎﺝ ﺍﲣﺎﺫ ﺍﻟﻘﺮﺍﺭ ﺑﺸﺄﻥ ﻣﺘﻄﻠﺐ ﻣﺎ ﺇﺫﺍ ﻛﺎﻥ ﺩﺍﺧﻞ ﻧﻄﺎﻕ ﺍﻟﻨﻈﺎﻡ ﺃﻡ ﺧﺎﺭﺟﻪ ﻟﻮﺟﻮﺩ ﳕﻮﺫﺝ ﻣﺮﺟﻌﻲ‬
‫ﻳﺘﺨﺬ ﺍﻟﻘﺮﺍﺭ ﺑﺎﻟﻌﻮﺩﺓ ﺇﻟﻴﻪ‪ ،‬ﻭﻣﻦ ﺃﻫﻢ ﺍﻟﻨﻤﺎﺫﺝ ﺍﳌﺮﺟﻌﻴﺔ ﺍﳌﻌﺮﻭﻓﺔ ﺗﺎﺭﳜﻴﹰﺎ ﺍﳌﺨﻄﻂ ﺍﳌﻌﺮﻭﻑ ﺑﺎﺳﻢ‬
‫ﳐﻄﻂ ﺍﻟﺴﻴﺎﻕ )‪ ،(Context diagram‬ﻭﻫﻮ ﺍﳌﺨﻄﻂ ﺫﻭ ﺍﳌﺴﺘﻮﻯ ﺍﻷﻋﻠﻰ ﰲ ﺗﻘﻨﻴﺔ ﺍﻟﻨﻤﺬﺟﺔ ﺍﳌﻬﻴﻜﻠﺔ‬
‫ﺍﻟﺸﺎﺋﻌﺔ ﺍﳌﻌﺮﻭﻓﺔ ﺑﺎﺳﻢ ﳐﻄﻄﺎﺕ ﺗﺪﻓﻖ ﺍﳌﻌﻄﻴﺎﺕ ﺃﻭ ‪ ،(Data Flow Diagrams) DFD‬ﻭﻣﻊ ﺃﻥ ﻫﺬﻩ‬
‫ﺍﳌﺨﻄﻄﺎﺕ ﻗﺪ ﺍﺳﺘﺒﺪﻟﺖ ﲟﺨﻄﻄﺎﺕ ﺣﺎﻻﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ ﰲ ‪ ،UML‬ﻟﻜﻦ ﻳﺒﻘﻰ ﳐﻄﻂ ﺍﻟﺴﻴﺎﻕ‬
‫ﺍﻟﻄﺮﻳﻘﺔ ﺍﻷﻓﻀﻞ ﻟﺘﻌﺮﻳﻒ ﺣﺪﻭﺩ ﺍﻟﻨﻈﺎﻡ )ﺍﻟﻔﻘﺮﺓ ‪.(1-5-3‬‬
‫ﻫﻨﺎﻙ ﺃﺳﺒﺎﺏ ﺃﺧﺮﻯ ﻛﺜﲑﺓ ﺗﺪﻓﻌﻨﺎ ﻟﺘﺼﻨﻴﻒ ﺍﳌﺘﻄﻠﺐ ﺧﺎﺭﺝ ﻧﻄﺎﻕ ﺍﳌﺸﺮﻭﻉ‬
‫)‪ (Sommerville and Sawyer, 1997‬ﻓﻌﻠﻰ ﺳﺒﻴﻞ ﺍﳌﺜﺎﻝ ﻗﺪ ﻳﻜﻮﻥ ﲢﻘﻴﻖ ﺍﳌﺘﻄﻠﺐ ﰲ ﻧﻈﺎﻡ ﺣﺎﺳﻮﰊ‬
‫ﺃﻣﺮﹰﺍ ﺻﻌﺒﹰﺎ ﻟﻠﻐﺎﻳﺔ ﻓﻴﺘﺮﻙ ﻋﻨﺪﺋ ٍﺬ ﻛﺈﺟﺮﺍﺋﻴﺔ ﺑﺸﺮﻳﺔ‪ ،‬ﺃﻭ ﻗﺪ ﻳﻜﻮﻥ ﺍﳌﺘﻄﻠﺐ ﻗﻠﻴﻞ ﺍﻷﳘﻴﺔ ﻭﰎ ﺍﺳﺘﺒﻌﺎﺩﻩ‬
‫ﻣﻦ ﺍﻹﺻﺪﺍﺭ ﺍﻷﻭﻝ ﻟﻠﻨﻈﺎﻡ‪ .‬ﻛﻤﺎ ﳝﻜﻦ ﺃﻳﻀﹰﺎ ﺃﻥ ﳚﺮﻱ ﲢﻘﻴﻖ ﺍﳌﺘﻄﻠﺐ ﺑﻮﺳﺎﺋﻞ ﻋﺘﺎﺩﻳﺔ ﺃﻭ ﺃﺟﻬﺰﺓ‬
‫اﻟﻔﺼﻞ اﻟﺜﺎﻟﺚ‬ ‫‪116‬‬

‫ﺧﺎﺭﺟﻴﺔ ﺃﺧﺮﻯ ﻭﻳﻘﻊ ﺧﺎﺭﺝ ﺇﻃﺎﺭ ﺳﻴﻄﺮﺓ ﺍﻟﻨﻈﺎﻡ ﺍﻟﱪﳎﻲ‪.‬‬

‫‪ 2-3-3‬ﻡﺼﻔﻮﻓﺔ ارﺗﺒﺎط اﻟﻤﺘﻄﻠﺒﺎت‬

‫ﳝﻜﻦ ﺑﻌﺪ ﺗﻌﺮﻳﻒ ﻭﺗﺮﻗﻴﻢ ﻛﻞ ﺍﳌﺘﻄﻠﺒﺎﺕ )ﺍﻟﻔﻘﺮﺓ ‪ (1-4-3‬ﺇﻧﺸﺎﺀ ﻣﺎ ﻧﺴﻤﻴﻪ ﻣﺼﻔﻮﻓﺔ ﺍﺭﺗﺒﺎﻁ‬
‫ﺍﳌﺘﻄﻠﺒﺎﺕ )ﺃﻭ ﻣﺼﻔﻮﻓﺔ ﺗﺒﺎﺩﻝ ﺍﻟﺘﺄﺛﲑ(‪ .‬ﺗﻌﺮﺽ ﻫﺬﻩ ﺍﳌﺼﻔﻮﻓﺔ ﺭﻣﻮﺯ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻣﺮﺗﺒﺔ ﰲ ﺗﺮﻭﻳﺴﺎﺕ‬
‫ﺍﻷﺳﻄﺮ ﻭﺍﻷﻋﻤﺪﺓ ﻛﻤﺎ ﻫﻮ ﻣﺒﲔ ﰲ ﺍﻟﺸﻜﻞ )‪.(2-3‬‬

‫اﻟﻤﺘﻄﻠﺐ‬ ‫‪R1‬‬ ‫‪R2‬‬ ‫‪R3‬‬ ‫‪R4‬‬

‫‪R1‬‬ ‫‪X‬‬ ‫‪X‬‬ ‫‪X‬‬ ‫‪X‬‬

‫‪R2‬‬ ‫ﺗﻌﺎرض‬ ‫‪X‬‬ ‫‪X‬‬ ‫‪X‬‬

‫‪R3‬‬ ‫‪X‬‬ ‫‪X‬‬

‫‪R4‬‬ ‫ﺗﻘﺎﻃﻊ‬ ‫ﺗﻘﺎﻃﻊ‬ ‫‪X‬‬

‫ﻣﺼﻔﻮﻓﺔ ارﺗﺒﺎط اﻟﻤﺘﻄﻠﺒﺎت‪.‬‬ ‫اﻟﺸﻜﻞ )‪(2-3‬‬

‫ﻻ ﻳﺴﺘﺨﺪﻡ ﺍﳉﺰﺀ ﺍﻟﻴﻤﻴﲏ ﺍﻷﻋﻠﻰ ﻣﻦ ﺍﳌﺼﻔﻮﻓﺔ )ﺍﻟﻘﻄﺮ ﻭﻣﺎ ﻓﻮﻗﻪ(‪ ،‬ﻭﺗﺸﲑ ﺑﻘﻴﺔ ﺍﳋﻼﻳﺎ ﺇﱃ ﺗﻘﺎﻃﻊ ﺃﻭ‬
‫ﺗﻌﺎﺭﺽ ﺃﻱ ﻣﻦ ﺃﺯﻭﺍﺝ ﺍﳌﺘﻄﻠﺒﺎﺕ‪ .‬ﻭﺗﺸﲑ ﺍﳋﻼﻳﺎ ﺍﻟﻔﺎﺭﻏﺔ ﺇﱃ ﺍﺳﺘﻘﻼﻝ ﺯﻭﺝ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﳌﻮﺍﻓﻖ‪.‬‬
‫ﳚﺐ ﺃﻥ ﺗﻨﺎﻗﺶ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﳌﺘﻌﺎﺭﺿﺔ ﻣﻊ ﺍﻟﺰﺑﺎﺋﻦ ﻭﺃﻥ ﺗﻌﺎﺩ ﺻﻴﺎﻏﺘﻬﺎ ﻟﻠﺘﺨﻠﺺ ﻣﻦ ﺍﻟﺘﻀﺎﺭﺏ ﻛﻠﻤﺎ‬
‫ﺃﻣﻜﻦ )ﻭﻳﻔﻀﻞ ﻫﻨﺎ ﺍﻻﺣﺘﻔﺎﻅ ﺑﺴﺠﻞ ﻳﺒﲔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻟﱵ ﺟﺮﻯ ﺗﻌﺪﻳﻠﻬﺎ(‪ .‬ﺃﻣﺎ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﳌﺘﻘﺎﻃﻌﺔ‬
‫ﻓﺘﺠﺐ ﺇﻋﺎﺩﺓ ﺍﻟﻨﻈﺮ ﻓﻴﻬﺎ ﻭﺗﻌﺪﻳﻠﻬﺎ ﻟﺘﺼﺒﺢ ﻣﺴﺘﻘﻠﺔ‪.‬‬
‫ﺗﻌﺘﱪ ﻣﺼﻔﻮﻓﺔ ﺍﺭﺗﺒﺎﻁ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺗﻘﻨﻴﺔ ﺑﺴﻴﻄﺔ ﻭﻓﻌﺎﻟﺔ ﻟﻜﺸﻒ ﺗﻌﺎﺭﺽ ﻭﺗﻘﺎﻃﻊ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻋﻨﺪﻣﺎ ﻳﻜﻮﻥ‬
‫ﻋﺪﺩ ﻫﺬﻩ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺻﻐﲑﹰﺍ ﻧﺴﺒﻴﺎﹰ‪ ،‬ﺃﻣﺎ ﺇﺫﺍ ﻛﺎﻥ ﻋﺪﺩﻫﺎ ﻛﺒﲑﹰﺍ ﻓﺘﺒﻘﻰ ﻫﺬﻩ ﺍﻟﺘﻘﻨﻴﺔ ﺻﺎﳊﺔ ﻟﻼﺳﺘﺨﺪﺍﻡ ﻋﻠﻰ‬
‫ﺃﻥ ﻳﺘﻢ ﲡﻤﻴﻊ ﺍﳌﺘﻄﻠﺒﺎﺕ ﰲ ﻓﺌﺎﺕ )ﺍﻟﻔﻘﺮﺓ ‪ (1-4-3‬ﲝﻴﺚ ﺗﻘﺎﺭﻥ ﻣﺘﻄﻠﺒﺎﺕ ﻛﻞ ﻓﺌﺔ ﻋﻠﻰ ﺣﺪﺓ‪.‬‬

‫‪ 3-3-3‬ﻡﺨﺎﻃﺮ اﻟﻤﺘﻄﻠﺒﺎت وأوﻟﻮﻳﺎﺗﻬﺎ‬

‫ﺑﻌﺪ ﺣﻞ ﻣﺸﺎﻛﻞ ﺗﻌﺎﺭﺽ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﺗﻘﺎﻃﻌﻬﺎ ﻭﺍﳊﺼﻮﻝ ﻋﻠﻰ ﳎﻤﻮﻋﺔ ﻣﺘﻄﻠﺒﺎﺕ ﻣﻌﺪﱠﻟﺔ ﳚﺐ‬
‫ﺇﺧﻀﺎﻉ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﳉﺪﻳﺪﺓ ﻟﻌﻤﻠﻴﺔ ﲢﻠﻴﻞ ﳐﺎﻃﺮ ﻭﲢﺪﻳﺪ ﺃﻭﻟﻮﻳﺎﺕ‪ ،‬ﻭﳛﺪﺩ ﲢﻠﻴﻞ ﺍﳌﺨﺎﻃﺮ ﺍﳌﺘﻄﻠﺒﺎﺕ‬
‫ﺍﻟﱵ ﻳﻌﺘﻘﺪ ﺃﻬﻧﺎ ﺳﺘﻀﻊ ﺻﻌﻮﺑﺎﺕ ﰲ ﻭﺟﻪ ﻋﻤﻠﻴﺔ ﺍﻟﺘﻄﻮﻳﺮ‪ ،‬ﺃﻣﺎ ﲢﺪﻳﺪ ﺍﻷﻭﻟﻮﻳﺎﺕ ﻓﻴﺴﻬﻞ ﺇﻋﺎﺩﺓ‬
‫ﺗﻌﺮﻳﻒ ﻧﻄﺎﻕ ﺍﳌﺸﺮﻭﻉ ﻋﻨﺪ ﺣﺪﻭﺙ ﺗﺄﺧﲑ ﰲ ﻋﻤﻠﻴﺔ ﺗﻄﻮﻳﺮﻩ‪.‬‬
‫‪117‬‬ ‫‪ : 3‬ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت‬

‫ﻗﺪ ﺗﺼﺒﺢ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺧﻄﺮﺓ ﻧﺘﻴﺠﺔ ﻟﻌﻮﺍﻣﻞ ﻣﺘﻨﻮﻋﺔ‪ ،‬ﻭﺃﳕﺎﻁ ﺍﳌﺨﺎﻃﺮ ﺍﻟﻨﻤﻄﻴﺔ ﻫﻲ‬
‫)‪:(Sommerville and Sawyer, 1997‬‬
‫ﳐﺎﻃﺮ ﺗﻘﻨﻴﺔ‪ ،‬ﻓﻘﺪ ﻳﻜﻮﻥ ﲢﻘﻴﻖ ﺍﳌﺘﻄﻠﺐ ﺻﻌﺒﹰﺎ ﺗﻘﻨﻴﹰﺎ‪.‬‬ ‫™‬

‫ﳐﺎﻃﺮ ﺍﻷﺩﺍﺀ‪ ،‬ﻓﻘﺪ ﻳﺆﺛﺮ ﲢﻘﻴﻖ ﺍﳌﺘﻄﻠﺐ ﺳﻠﺒﻴﹰﺎ ﻋﻠﻰ ﺯﻣﻦ ﺍﺳﺘﺠﺎﺑﺔ ﺍﻟﻨﻈﺎﻡ‪.‬‬ ‫™‬

‫ﳐﺎﻃﺮ ﺃﻣﻨﻴﺔ‪ ،‬ﻓﻘﺪ ﻳﻌﺮﺽ ﲢﻘﻴﻖ ﺍﳌﺘﻄﻠﺐ ﺍﻟﻨﻈﺎﻡ ﻻﺧﺘﺮﺍﻗﺎﺕ ﺃﻣﻨﻴﺔ‪.‬‬ ‫™‬

‫ﳐﺎﻃﺮ ﺗﻜﺎﻣﻞ ﻗﻮﺍﻋﺪ ﺍﳌﻌﻄﻴﺎﺕ‪ ،‬ﻓﻘﺪ ﻳﺼﻌﺐ ﺍﻟﺘﺤﻘﻖ ﻣﻦ ﺻﻼﺣﻴﺔ ﺍﳌﺘﻄﻠﺐ ﻭﻳﺆﺩﻱ ﻟﻌﺪﻡ‬ ‫™‬
‫ﺍﻧﺴﺠﺎﻡ ﺍﳌﻌﻄﻴﺎﺕ‪.‬‬
‫ﳐﺎﻃﺮ ﺇﺟﺮﺍﺋﻴﺔ ﺍﻟﺘﻄﻮﻳﺮ‪ ،‬ﺗﻈﻬﺮ ﻫﺬﻩ ﺍﳌﺨﺎﻃﺮ ﻋﻨﺪﻣﺎ ﳛﺘﺎﺝ ﲢﻘﻴﻖ ﺍﳌﺘﻄﻠﺐ ﻻﺳﺘﺨﺪﺍﻡ ﻃﺮﺍﺋﻖ‬ ‫™‬
‫ﻼ‪ :‬ﻃﺮﺍﺋﻖ ﺍﻟﺘﻮﺻﻴﻒ ﺍﻟﺼﻮﺭﻱ(‪.‬‬
‫ﺗﻄﻮﻳﺮ ﻏﲑ ﺗﻘﻠﻴﺪﻳﺔ ﻻ ﻳﺄﻟﻔﻬﺎ ﺍﳌﻄﻮﺭﻭﻥ )ﻣﺜ ﹰ‬
‫ﳐﺎﻃﺮ ﺳﻴﺎﺳﻴﺔ‪ ،‬ﻓﻘﺪ ﻳﺼﻌﺐ ﲢﻘﻴﻖ ﺍﳌﺘﻄﻠﺐ ﻻﻋﺘﺒﺎﺭﺍﺕ ﺳﻴﺎﺳﻴﺔ ﺩﺍﺧﻠﻴﺔ‪.‬‬ ‫™‬

‫ﳐﺎﻃﺮ ﻗﺎﻧﻮﻧﻴﺔ‪ ،‬ﻓﻘﺪ ﳜﺮﻕ ﻣﺘﻄﻠﺐ ﻣﺎ ﺍﻟﻘﻮﺍﻧﲔ ﺍﻟﺴﺎﺭﻳﺔ ﺍﳌﻔﻌﻮﻝ‪ ،‬ﺃﻭ ﺍﻟﺘﻌﺪﻳﻼﺕ ﺍﳌﺘﻮﻗﻌﺔ ﻋﻠﻰ‬ ‫™‬
‫ﺍﻟﻘﻮﺍﻧﲔ‪.‬‬
‫ﳐﺎﻃﺮ ﻋﺪﻡ ﺍﻟﺜﺒﺎﺕ‪ ،‬ﻓﻘﺪ ﻳﻈﻬﺮ ﺃﻥ ﻣﺘﻄﻠﺒﹰﺎ ﻣﺎ ﺳﻴﺴﺘﻤﺮ ﰲ ﺍﻟﺘﻐﲑ ﻭﺍﻟﺘﻄﻮﺭ ﻃﻴﻠﺔ ﻓﺘﺮﺓ ﺇﺟﺮﺍﺋﻴﺔ ﺍﻟﺘﻄﻮﻳﺮ‪.‬‬ ‫™‬

‫ﻧﻈﺮﻳﹰﺎ ﳚﺮﻱ ﲢﺪﻳﺪ ﺃﻭﻟﻮﻳﺎﺕ ﺍﳌﺘﻄﻠﺒﺎﺕ ﰲ ﺍﻟﺒﺪﺍﻳﺔ ﺧﻼﻝ ﻣﺮﺣﻠﺔ ﺍﺳﺘﻨﺘﺎﺝ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻣﻦ ﺍﻟﺰﺑﺎﺋﻦ ﰒ‬
‫ﲡﺮﻱ ﻣﻨﺎﻗﺸﺔ ﻫﺬﻩ ﺍﻷﻭﻟﻮﻳﺎﺕ ﰲ ﺍﻻﺟﺘﻤﺎﻋﺎﺕ ﻭﺗﻌﺪﻝ ﺛﺎﻧﻴﺔ ﺑﻌﺪ ﺃﺧﺬ ﻋﻮﺍﻣﻞ ﺍﳋﻄﻮﺭﺓ ﺑﺎﳊﺴﺒﺎﻥ‪.‬‬
‫ﻭﻟﺘﺠﻨﺐ ﺍﻻﻟﺘﺒﺎﺱ ﻭﺗﺴﻬﻴﻞ ﻋﻤﻠﻴﺔ ﲢﺪﻳﺪ ﺍﻷﻭﻟﻮﻳﺎﺕ ﳚﺐ ﺃﻥ ﻳﻜﻮﻥ ﻋﺪﺩ ﺩﺭﺟﺎﺕ ﺍﻷﻭﻟﻮﻳﺔ ﺻﻐﲑﺍﹰ‪،‬‬
‫ﻭﻳﻜﻮﻥ ﻫﺬﺍ ﺍﻟﻌﺪﺩ ﻋﺎﺩﺓ ﺑﲔ ‪ 3‬ﻭ ‪ ،5‬ﻛﺄﻥ ﺗﻌﻄﻰ ﺍﻷﻭﻟﻮﻳﺎﺕ ﺩﺭﺟﺎﺕ ﻣﺜﻞ‪ :‬ﻋﺎﱄ‪ ،‬ﻣﺘﻮﺳﻂ‪،‬‬
‫ﻣﻨﺨﻔﺾ‪ ،‬ﻏﲑ ﺃﻛﻴﺪ‪ ،‬ﺃﻭ ﺩﺭﺟﺎﺕ ﻣﺜﻞ‪ :‬ﺃﺳﺎﺳﻲ‪ ،‬ﻣﻔﻴﺪ‪ ،‬ﻣﻬﻢ ﻧﻮﻋﹰﺎ ﻣﺎ‪ ،‬ﳚﺐ ﺍﲣﺎﺫ ﻗﺮﺍﺭ ﺑﺸﺄﻧﻪ‪.‬‬

‫إدارة اﻟﻤﺘﻄﻠﺒﺎت‬ ‫‪4-3‬‬

‫ﺗﺸﻜﻞ ﺇﺩﺍﺭﺓ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺟﺰﺀﹰﺍ ﻓﻌﻠﻴﹰﺎ ﻣﻦ ﺇﺟﺮﺍﺋﻴﺔ ﺇﺩﺍﺭﺓ ﺍﳌﺸﺮﻭﻉ ﻛﻜﻞ‪ ،‬ﻭﻫﻲ ﺗﻌﲎ ﺑﺪﺭﺍﺳﺔ ﺛﻼﺛﺔ‬
‫ﻣﻮﺍﺿﻴﻊ ﺭﺋﻴﺴﻴﺔ‪:‬‬
‫ﲢﺪﻳﺪ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﺗﺼﻨﻴﻔﻬﺎ ﻭﺗﻨﻈﻴﻤﻬﺎ ﻭﺗﻮﺛﻴﻘﻬﺎ‪.‬‬ ‫‪.1‬‬

‫ﺗﻐﲑ ﺍﳌﺘﻄﻠﺒﺎﺕ )ﻣﻊ ﺇﺟﺮﺍﺋﻴﺎﺕ ﺗﺒﲔ ﻛﻴﻒ ﺳﺘﻘﺘﺮﺡ ﺗﻌﺪﻳﻼﺕ ﻻ ﳝﻜﻦ ﲡﻨﺒﻬﺎ‪ ،‬ﻭﻛﻴﻒ ﺗﻨﺎﻗﺶ‬ ‫‪.2‬‬
‫ﻭﺗﺪﻗﻖ ﻭﺗﻮﺛﱠﻖ(‪.‬‬
‫اﻟﻔﺼﻞ اﻟﺜﺎﻟﺚ‬ ‫‪118‬‬

‫ﺗﺘﺒﻊ ﺍﳌﺘﻄﻠﺒﺎﺕ )ﻣﻊ ﺇﺟﺮﺍﺋﻴﺎﺕ ﲢﺎﻓﻆ ﻋﻠﻰ ﻋﻼﻗﺎﺕ ﺍﻻﺭﺗﺒﺎﻁ ﺑﲔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﲝﺪ ﺫﺍﻬﺗﺎ‪ ،‬ﻭﺑﲔ‬ ‫‪.3‬‬
‫ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﻣﻌﻄﻴﺎﺕ ﺍﻟﻨﻈﺎﻡ ﺍﻷﺧﺮﻯ(‪) .‬ﺍﻧﻈﺮ ﺍﻟﻔﺼﻞ ﺍﻟﻌﺎﺷﺮ(‪.‬‬

‫‪ 1-4-3‬ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت وﺗﺼﻨﻴﻔﻬﺎ‬

‫ﻼ‪:‬‬
‫ﺗﻮﺻﻒ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺑﻌﺒﺎﺭﺍﺕ ﻣﻜﺘﻮﺑﺔ ﺑﺎﻟﻠﻐﺔ ﺍﻟﻄﺒﻴﻌﻴﺔ‪ ،‬ﻣﺜ ﹰ‬
‫ﳚﺐ ﺃﻥ ﳚﺪﻭﻝ ﺍﻟﻨﻈﺎﻡ ﺍﻻﺗﺼﺎﻝ ﺍﳍﺎﺗﻔﻲ ﺍﻟﺘﺎﱄ ﺑﻨﺎﺀ ﻋﻠﻰ ﻃﻠﺐ ﺍﳌﺴﻮﱢﻕ‪.‬‬ ‫™‬

‫ﳚﺐ ﺃﻥ ﻳﻄﻠﺐ ﺍﻟﻨﻈﺎﻡ ﺭﻗﻢ ﺍﳍﺎﺗﻒ ﺍﺠﻤﻟﺪﻭﻝ ﺗﻠﻘﺎﺋﻴﹰﺎ ﻭﻳﻌﺮﺽ ﰲ ﺍﻟﻮﻗﺖ ﻧﻔﺴﻪ ﻋﻠﻰ ﺷﺎﺷﺔ‬ ‫™‬
‫ﺍﳌﺴﻮﻕ ﺍﳌﻌﻠﻮﻣﺎﺕ ﺍﳋﺎﺻﺔ ﺑﺎﻟﺰﺑﻮﻥ‪ ،‬ﲟﺎ ﻓﻴﻬﺎ ﺍﺳﻢ ﺍﻟﺰﺑﻮﻥ‪ ،‬ﺭﻗﻤﻪ‪ ،‬ﺭﻗﻢ ﻫﺎﺗﻔﻪ‪.‬‬
‫ﻋﻨﺪ ﳒﺎﺡ ﺍﻻﺗﺼﺎﻝ‪ ،‬ﳚﺐ ﺃﻥ ﻳﻌﺮﺽ ﺍﻟﻨﻈﺎﻡ ﻧﺼﹰﺎ ﲤﻬﻴﺪﻳﹰﺎ ﻗﺪ ﻳﻨﻘﻞ ﺍﳌﺴﻮﻕ ﻓﺤﻮﺍﻩ ﺇﱃ ﺍﻟﺰﺑﻮﻥ‬ ‫™‬
‫ﻟﺒﺪﺀ ﺍﶈﺎﺩﺛﺔ‪.‬‬
‫ﻗﺪ ﻳﺘﻀﻤﻦ ﺍﻟﻨﻈﺎﻡ ﺍﻟﻨﻤﻄﻲ ﻣﺌﺎﺕ ﺃﻭ ﺁﻻﻓﹰﺎ ﻣﻦ ﻋﺒﺎﺭﺍﺕ ﺗﻮﺻﻴﻒ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻛﺘﻠﻚ ﺍﳌﺬﻛﻮﺭﺓ ﺃﻋﻼﻩ‪،‬‬
‫ﻭﻟﺘﺴﻬﻴﻞ ﺇﺩﺍﺭﺓ ﻫﺬﺍ ﺍﻟﻌﺪﺩ ﺍﻟﻜﺒﲑ ﻣﻦ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻳﻔﻀﻞ ﺗﺮﻗﻴﻤﻬﺎ ﺑﺎﻋﺘﻤﺎﺩ ﻧﻈﺎﻡ ﻣﺎ‪ ،‬ﻭﻗﺪ ﻳﻨﻄﻮﻱ ﻫﺬﺍ‬
‫ﺍﻟﻨﻈﺎﻡ ﻋﻠﻰ ﺗﺼﻨﻴﻒ ﺍﳌﺘﻄﻠﺒﺎﺕ ﰲ ﳎﻤﻮﻋﺎﺕ ﺗﺴﻬﻞ ﺇﺩﺍﺭﻬﺗﺎ‪.‬‬
‫ﺗﻮﺟﺪ ﻋﺪﺓ ﺗﻘﻨﻴﺎﺕ ﻟﺘﺤﺪﻳﺪ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﺗﺼﻨﻴﻔﻬﺎ )‪:(Kotonya and Sommerville, 1998‬‬
‫ﺍﳌﻌﺮﻑ ﺍﻟﻮﺣﻴﺪ‪ ،‬ﻭﻫﻮ ﻋﺎﺩﺓ ﺭﻗﻢ ﺗﺴﻠﺴﻠﻲ ﻳﻌﻄﻰ ﻳﺪﻭﻳﹰﺎ ﺃﻭ ﺗﻮﻟﺪﻩ ﺃﺩﺍﺓ ﻣﺴﺎﻧﺪﺓ ﰲ ﻫﻨﺪﺳﺔ‬ ‫™‬
‫ﺍﻟﱪﳎﻴﺎﺕ )ﺃﻭ ﺑﺎﻷﺣﺮﻯ ﻗﺎﻋﺪﺓ ﺍﳌﻌﻄﻴﺎﺕ ﺍﻟﱵ ﲣﺰﻥ ﻓﻴﻬﺎ ﺍﻷﺩﺍﺓ ﺍﳌﻌﻄﻴﺎﺕ ﻭﺍﳊﻘﺎﺋﻖ ﺍﳌﺘﻌﻠﻘﺔ‬
‫ﺑﺎﻟﺘﺤﻠﻴﻞ ﻭﺍﻟﺘﺼﻤﻴﻢ(‪.‬‬
‫ﺭﻗﻢ ﺗﺴﻠﺴﻠﻲ ﺿﻤﻦ ﺍﻟﻔﺌﺔ‪ ،‬ﺣﻴﺚ ﻳﻌﻄﻰ ﻟﻜﻞ ﻣﺘﻄﻠﺐ ﺭﻗﻤﹰﺎ ﺗﺴﻠﺴﻠﻴﹰﺎ ﺑﺎﻹﺿﺎﻓﺔ ﺇﱃ ﺍﺳﻢ ﺭﻣﺰﻱ‬ ‫™‬
‫ﳝﻴﺰ ﺍﻟﻔﺌﺔ ﺍﻟﱵ ﻳﻨﺘﻤﻲ ﺇﻟﻴﻬﺎ )ﳝﻜﻦ ﺃﻥ ﺗﺼﻨﻒ ﺍﳌﺘﻄﻠﺒﺎﺕ ﰲ ﻓﺌﺎﺕ ﻣﺜﻞ ﻭﻇﺎﺋﻒ‪ ،‬ﻣﻌﻄﻴﺎﺕ‪ ،‬ﺃﺩﺍﺀ‪،‬‬
‫ﺃﻣﻦ‪.(..،‬‬
‫ﻟﻜﻞ ﻃﺮﻳﻘﺔ ﻣﻦ ﺍﻟﻄﺮﻕ ﺍﻟﺴﺎﺑﻘﺔ ﳏﺎﺳﻨﻬﺎ ﻭﻣﺴﺎﻭﺋﻬﺎ‪ ،‬ﻭﻗﺪ ﺗﻜﻮﻥ ﻃﺮﻳﻘﺔ ﺍﻟﺮﻗﻢ ﺍﻟﺘﺴﻠﺴﻠﻲ ﺍﳌﻮﻟﺪ ﻣﻦ‬
‫ﻗﺎﻋﺪﺓ ﻣﻌﻄﻴﺎﺕ ﺍﻟﻄﺮﻳﻘﺔ ﺍﻷﻛﺜﺮ ﻣﺮﻭﻧﺔ ﻭﺍﻷﻗﻞ ﻋﺮﺿﺔ ﻟﻸﺧﻄﺎﺀ‪ ،‬ﺇﺫ ﺗﺘﻀﻤﻦ ﺃﻧﻈﻤﺔ ﺇﺩﺍﺭﺓ ﻗﻮﺍﻋﺪ‬
‫ﺍﳌﻌﻄﻴﺎﺕ ﺇﻣﻜﺎﻧﻴﺔ ﺗﺴﻤﺢ ﳍﺎ ﺑﺈﻧﺸﺎﺀ ﺭﻗﻢ ﻭﺣﻴﺪ ﻟﻜﻞ ﺳﺠﻞ ﺟﺪﻳﺪ ﺿﻤﻦ ﺑﻴﺌﺔ ﻳﺴﻤﺢ ﻓﻴﻬﺎ ﻟﻌﺪﺓ‬
‫ﻣﺴﺘﺨﺪﻣﲔ ﺑﺎﻟﻮﺻﻮﻝ ﺇﱃ ﺍﳌﻌﻄﻴﺎﺕ ﰲ ﺍﻟﻮﻗﺖ ﻧﻔﺴﻪ‪.‬‬
‫ﺗﺪﻋﻢ ﺑﻌﺾ ﺃﻧﻈﻤﺔ ﺇﺩﺍﺭﺓ ﻗﻮﺍﻋﺪ ﺍﳌﻌﻄﻴﺎﺕ ﺇﻣﻜﺎﻧﻴﺔ ﺇﺩﺍﺭﺓ ﻋﺪﺓ ﺇﺻﺪﺍﺭﺍﺕ ﻣﻦ ﺍﻟﺴﺠﻞ ﻧﻔﺴﻪ‬
‫)ﺑﺘﻀﻤﲔ ﺭﻗﻢ ﺍﻹﺻﺪﺍﺭ ﺿﻤﻦ ﺍﻟﺮﻗﻢ ﺍﳌﻤﻴﺰ(‪ .‬ﻭﺃﺧﲑﹰﺍ ﳝﻜﻦ ﺃﻥ ﲢﺎﻓﻆ ﻗﻮﺍﻋﺪ ﺍﳌﻌﻄﻴﺎﺕ ﻋﻠﻰ‬
‫ﺍﺭﺗﺒﺎﻃﺎﺕ ﺍﻟﺘﻜﺎﻣﻞ ﺍﳌﺮﺟﻌﻲ ﺑﲔ ﻣﻌﻄﻴﺎﺕ ﻭﺣﻘﺎﺋﻖ ﺍﻟﻨﻤﺬﺟﺔ‪ ،‬ﲟﺎ ﻓﻴﻬﺎ ﺍﳌﺘﻄﻠﺒﺎﺕ‪ ،‬ﻭﺑﺬﻟﻚ ﳝﻜﻦ ﺃﻥ‬
 ‫‪119‬‬ ‫‪ : 3‬ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت‬

‫ﺗﺪﻋﻢ ﺇﺩﺍﺭﺓ ﺗﻐﲑ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﺗﺘﺒﻌﻬﺎ ﺃﻳﻀﹰﺎ‪.‬‬

‫‪ 2-4-3‬هﺮﻡﻴﺔ اﻟﻤﺘﻄﻠﺒﺎت‬
‫ﳝﻜﻦ ﺗﻨﻈﻴﻢ ﺍﳌﺘﻄﻠﺒﺎﺕ ﰲ ﺑﻨﻴﺔ ﻫﺮﻣﻴﺔ ﲝﻴﺚ ﺗﺮﺑﻂ ﺑﻴﻨﻬﺎ ﻋﻼﻗﺎﺕ ﻣﻦ ﺍﻟﺸﻜﻞ ﺃﺏ‪-‬ﺇﺑﻦ‪ ،‬ﻭﺗﺸﺒﻪ ﻫﺬﻩ‬
‫ﺍﻟﻌﻼﻗﺔ ﻋﻼﻗﺔ ﺍﻟﺘﺮﻛﻴﺐ )ﺍﻟﻔﻘﺮﺓ ‪ ،(4-1-2‬ﻓﻴﺘﺮﻛﺐ ﺍﳌﺘﻄﻠﺐ ﺍﻷﺏ ﻣﻦ ﻣﺘﻄﻠﺒﺎﺕ ﺃﺑﻨﺎﺀ‪ ،‬ﻭﳝﻜﻦ ﺍﻟﻘﻮﻝ‬
‫ﺃﻥ ﺍﳌﺘﻄﻠﺐ ﺍﻻﺑﻦ ﻫﻮ ﻣﺘﻄﻠﺐ ﻓﺮﻋﻲ ﻣﻦ ﺍﻷﺏ‪.‬‬
‫ﺗﻌﺮﻑ ﺍﻟﻌﻼﻗﺎﺕ ﺍﳍﺮﻣﻴﺔ ﻣﺴﺘﻮﻳﹰﺎ ﺇﺿﺎﻓﻴﹰﺎ ﻟﺘﺼﻨﻴﻒ ﺍﳌﺘﻄﻠﺒﺎﺕ‪ ،‬ﻭﻗﺪ ﻳﻈﻬﺮ ﻫﺬﺍ ﺍﻟﺘﺼﻨﻴﻒ‪ ،‬ﻣﺒﺎﺷﺮﺓ ﺃﻭ‬
‫ﻏﲑ ﻣﺒﺎﺷﺮﺓ‪ ،‬ﰲ ﺗﺮﻗﻴﻢ ﺍﳌﺘﻄﻠﺒﺎﺕ‪ ،‬ﻓﺎﳌﺘﻄﻠﺐ ﺭﻗﻢ ‪ 4.9‬ﻫﻮ ﺍﻻﺑﻦ ﺍﻟﺘﺎﺳﻊ ﻟﻸﺏ ﺍﳌﻤﻴﺰ ﺑﺎﻟﺮﻗﻢ ‪.4‬‬
‫ﻟﻨﺄﺧﺬ ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﳌﺜﺎﻝ ﳎﻤﻮﻋﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﳍﺮﻣﻴﺔ ﺍﻟﺘﺎﻟﻴﺔ‪:‬‬
‫ﳚﺐ ﺃﻥ ﳚﺪﻭﻝ ﺍﻟﻨﻈﺎﻡ ﺍﻻﺗﺼﺎﻝ ﺍﳍﺎﺗﻔﻲ ﺍﻟﺘﺎﱄ ﺑﻨﺎﺀ ﻋﻠﻰ ﻃﻠﺐ ﺍﳌﺴﻮﱢﻕ‪.‬‬ ‫‪.1‬‬

‫ﳚﺐ ﺃﻥ ﻳﺆﻫﻞ ﺍﻟﻨﻈﺎﻡ ﺍﻟﺰﺭ ‪ Next Call‬ﺑﻌﺪ ﺍﻟﺪﺧﻮﻝ ﺇﱃ ﺍﻻﺳﺘﻤﺎﺭﺓ ‪ Telemarketing Control‬ﺃﻭ‬ ‫‪1.1‬‬
‫ﺑﻌﺪ ﺍﻧﺘﻬﺎﺀ ﺍﳌﻜﺎﳌﺔ ﺍﻟﺴﺎﺑﻘﺔ‪.‬‬
‫ﳚﺐ ﺃﻥ ﳛﺬﻑ ﺍﻟﻨﻈﺎﻡ ﺍﳌﻜﺎﳌﺔ ﻣﻦ ﺑﺪﺍﻳﺔ ﻗﺎﺋﻤﺔ ﺍﳌﻜﺎﳌﺎﺕ ﺍﺠﻤﻟﺪﻭﻟﺔ ﻭﳚﻌﻠﻬﺎ ﺍﳌﻜﺎﳌﺔ ﺍﳊﺎﻟﻴﺔ‪.‬‬ ‫‪2.1‬‬

‫‪...‬‬ ‫‪3.1‬‬

‫ﺗﺴﻤﺢ ﻫﺮﻣﻴﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺑﺘﻌﺮﻳﻒ ﻣﺘﻄﻠﺒﺎﺕ ﻣﻦ ﻣﺴﺘﻮﻳﺎﺕ ﲡﺮﻳﺪ ﳐﺘﻠﻔﺔ‪ ،‬ﺍﻷﻣﺮ ﺍﻟﺬﻱ ﻳﻨﺴﺠﻢ ﻣﻊ‬
‫ﺍﳌﺒﺪﺃ ﺍﻟﻌﺎﻡ ﻟﻠﻨﻤﺬﺟﺔ ﺍﻟﺬﻱ ﻳﻨﺺ ﻋﻠﻰ ﺇﺿﺎﻓﺔ ﺍﻟﺘﻔﺎﺻﻴﻞ ﺇﱃ ﺍﻟﻨﻤﺎﺫﺝ ﻋﻨﺪ ﺍﻻﻧﺘﻘﺎﻝ ﺇﱃ ﻣﺴﺘﻮﻯ ﲡﺮﻳﺪ‬
‫ﺃﺩﱏ‪ .‬ﻭﺑﺎﻟﻨﺘﻴﺠﺔ ﳝﻜﻦ ﺃﻥ ﺗﺒﲎ ﺍﻟﻨﻤﺎﺫﺝ ﰲ ﺍﳌﺴﺘﻮﻯ ﺍﻷﻋﻠﻰ ﻟﺘﻠﺒﻴﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻵﺑﺎﺀ ﻭﺃﻥ ﺗﻘﺮﻥ ﳕﺎﺫﺝ‬
‫ﺍﳌﺴﺘﻮﻯ ﺍﻷﺩﱏ ﺑﺎﳌﺘﻄﻠﺒﺎﺕ ﺍﻷﺑﻨﺎﺀ‪.‬‬

‫‪ 3-4-3‬إدارة اﻟﺘﻐﻴﻴﺮات‬
‫ﳝﻜﻦ ﺃﻥ ﺗﺘﻐﲑ ﺍﳌﺘﻄﻠﺒﺎﺕ ﰲ ﺃﻱ ﻣﺮﺣﻠﺔ ﻣﻦ ﻣﺮﺍﺣﻞ ﺍﻟﺘﻄﻮﻳﺮ‪ ،‬ﻓﻘﺪ ﻳﺘﻐﲑ ﺍﳌﺘﻄﻠﺐ ﺃﻭ ﳛﺬﻑ ﻭﻗﺪ‬
‫ﺗُﻀﺎﻑ ﻣﺘﻄﻠﺒﺎﺕ ﺟﺪﻳﺪﺓ‪ ،‬ﻭﻻ ﻳﺸﻜﻞ ﻫﺬﺍ ﲝﺪ ﺫﺍﺗﻪ ﻣﺸﻜﻠﺔ ﻟﻜﻦ ﺗﻈﻬﺮ ﺍﳌﺸﻜﻠﺔ ﻋﻨﺪ ﻏﻴﺎﺏ ﺇﺩﺍﺭﺓ‬
‫ﻫﺬﻩ ﺍﻟﺘﻐﻴﲑﺍﺕ‪.‬‬
‫ﺗﺰﺩﺍﺩ ﻛﻠﻔﺔ ﺗﻐﲑ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻣﻊ ﺗﻘﺪﻡ ﻣﺮﺍﺣﻞ ﺍﻟﺘﻄﻮﻳﺮ‪ ،‬ﻭﺗﻜﻮﻥ ﻫﺬﻩ ﺍﻟﺰﻳﺎﺩﺓ ﺗﺼﺎﻋﺪﻳﺔ ﺃﻳﻀﺎﹰ‪ ،‬ﻓﺘﻐﻴﲑ‬
‫ﻣﺘﻄﻠﺐ ﺃﺩﺭﺝ ﻟﻠﺘﻮ ﻭﱂ ﻳﺮﺑﻂ ﲟﺘﻄﻠﺒﺎﺕ ﺃﺧﺮﻯ ﻻ ﻳﻌﺪﻭ ﻛﻮﻧﻪ ﻋﻤﻠﻴﺔ ﺗﻨﻘﻴﺢ ﻣﺒﺎﺷﺮﺓ ﻟﻮﺛﻴﻘﺔ‪ ،‬ﺃﻣﺎ‬
‫ﺗﻐﻴﲑ ﺍﳌﺘﻄﻠﺐ ﻧﻔﺴﻪ ﺑﻌﺪ ﲢﻘﻴﻘﻪ ﰲ ﺍﻟﻨﻈﺎﻡ ﺍﻟﱪﳎﻲ ﻓﻬﻮ ﺃﻣﺮ ﻣﻜﻠﻒ ﺟﺪﹰﺍ ﺩﻭﻥ ﺷﻚ‪.‬‬
‫اﻟﻔﺼﻞ اﻟﺜﺎﻟﺚ‬ ‫‪120‬‬

‫ﳝﻜﻦ ﺃﻥ ﻳﻌﺰﻯ ﺗﻐﲑ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻷﺧﻄﺎﺀ ﺑﺸﺮﻳﺔ‪ ،‬ﻟﻜﻦ ﻛﺜﲑﹰﺍ ﻣﺎ ﺗﺘﻐﲑ ﺍﳌﺘﻄﻠﺒﺎﺕ ﰲ ﺍﻟﻮﺍﻗﻊ ﻧﺘﻴﺠﺔ ﻟﺘﻐﲑ‬
‫ﺍﻟﺴﻴﺎﺳﺔ ﺍﻟﺪﺍﺧﻠﻴﺔ ﺃﻭ ﺑﺴﺒﺐ ﻋﻮﺍﻣﻞ ﺧﺎﺭﺟﻴﺔ ﻛﺎﻟﻘﻮﻯ ﺍﳌﻨﺎﻓﺴﺔ‪ ،‬ﻭﺍﻷﺳﻮﺍﻕ ﺍﻟﻌﺎﳌﻴﺔ ﺃﻭ ﺍﻟﺘﻄﻮﺭ‬
‫ﺍﻟﺘﻜﻨﻮﻟﻮﺟﻲ‪ .‬ﻭﻣﻬﻤﺎ ﻛﺎﻥ ﺳﺒﺐ ﺍﻟﺘﻐﲑ ﻻﺑﺪ ﻣﻦ ﺍﺗﺒﺎﻉ ﺳﻴﺎﺳﺎﺕ ﺇﺩﺍﺭﺓ ﻗﻮﻳﺔ ﻟﺘﻮﺛﻴﻖ ﺗﻐﲑ ﺍﳌﺘﻄﻠﺒﺎﺕ‬
‫ﻭﺗﻘﻴﻴﻢ ﺁﺛﺎﺭﻫﺎ ﻭﺃﺧﺬﻫﺎ ﺑﺎﳊﺴﺒﺎﻥ‪.‬‬
‫ﻭﻧﻈﺮﹰﺍ ﻻﺭﺗﻔﺎﻉ ﻛﻠﻔﺔ ﺗﻐﲑ ﺍﳌﺘﻄﻠﺒﺎﺕ ﳚﺐ ﺇﻋﺪﺍﺩ ﺣﺎﻟﺔ ﻋﻤﻞ ﺻﻮﺭﻳﺔ ﻟﻜﻞ ﺗﻐﲑ ﳛﺼﻞ‪ ،‬ﻓﻤﻦ ﺃﺟﻞ ﻛﻞ‬
‫ﺗﻐﲑ ﲡﺐ ﺩﺭﺍﺳﺔ ﺇﻣﻜﺎﻧﻴﺔ ﲢﻘﻴﻘﻪ ﺗﻘﻨﻴﹰﺎ ﻭﺗﻘﺪﻳﺮ ﺃﺛﺮﻩ ﻋﻠﻰ ﺑﻘﻴﺔ ﺍﳌﺸﺮﻭﻉ ﻭﻋﻠﻰ ﺍﻟﻜﻠﻔﺔ‪ ،‬ﻭﺑﻌﺪ ﺍﻟﺘﺼﺪﻳﻖ‬
‫ﻋﻠﻰ ﺻﻼﺣﻴﺔ ﺍﻟﺘﻐﻴﲑ ﳚﺐ ﺇﻋﺎﺩﺓ ﺃﺧﺬﻩ ﺑﺎﳊﺴﺒﺎﻥ ﰲ ﺍﻟﻨﻤﺎﺫﺝ ﺍﳌﻮﺍﻓﻘﺔ ﻭﲢﻘﻴﻘﻪ ﰲ ﺍﻟﻨﻈﺎﻡ ﺍﻟﱪﳎﻲ‪.‬‬
‫ﺗﺘﻄﻠﺐ ﺇﺩﺍﺭﺓ ﺍﻟﺘﻐﻴﲑﺍﺕ ﺗﺘﺒﻊ ﻛﻤﻴﺎﺕ ﻛﺒﲑﺓ ﻣﻦ ﺍﳌﻌﻠﻮﻣﺎﺕ ﺍﳌﺘﺮﺍﺑﻄﺔ ﻋﻠﻰ ﻓﺘﺮﺍﺕ ﻃﻮﻳﻠﺔ‪ ،‬ﻭﻗﺪ ﺗﻔﺸﻞ‬
‫ﺇﺩﺍﺭﺓ ﺍﻟﺘﻐﻴﲑﺍﺕ ﻣﺎ ﱂ ﺗﻌﺘﻤﺪ ﻋﻠﻰ ﺩﻋﻢ ﺃﺩﺍﺓ ﻣﻨﺎﺳﺒﺔ‪ .‬ﳚﺐ‪ ،‬ﻧﻈﺮﻳﺎﹰ‪ ،‬ﲣﺰﻳﻦ ﺗﻐﲑ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﺗﺘﺒﻊ ﻫﺬﻩ‬
‫ﺍﻟﺘﻐﲑﺍﺕ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺃﺩﻭﺍﺕ ﻹﺩﺍﺭﺓ ﺗﺸﻜﻴﻞ ﺍﻟﱪﳎﻴﺎﺕ ﺍﻟﱵ ﻳﺴﺘﺨﺪﻣﻬﺎ ﺍﳌﻄﻮﺭﻭﻥ ﻋﺎﺩﺓ ﻹﺩﺍﺭﺓ ﺇﺻﺪﺍﺭﺍﺕ‬
‫ﺍﻟﻨﻤﺎﺫﺝ ﻭﺍﻟﱪﺍﻣﺞ ﻋﱪ ﺩﻭﺭﺓ ﺣﻴﺎﺓ ﺍﻟﺘﻄﻮﻳﺮ‪ .‬ﻭﳝﻜﻦ ﺃﻥ ﺗﺘﻀﻤﻦ ﺍﻷﺩﺍﺓ ﺍﳌﺴﺎﻧﺪﺓ ﰲ ﻫﻨﺪﺳﺔ ﺍﻟﱪﳎﻴﺎﺕ‬
‫ﺇﻣﻜﺎﻧﻴﺎﺕ ﺧﺎﺻﺔ ﻬﺑﺎ ﻹﺩﺍﺭﺓ ﺍﻟﺘﻐﻴﲑﺍﺕ ﺃﻭ ﺃﻥ ﺗﺘﻤﺘﻊ ﺑﺈﻣﻜﺎﻧﻴﺔ ﺍﻻﺗﺼﺎﻝ ﺑﺄﺩﺍﺓ ﻣﺴﺘﻘﻠﺔ ﻹﺩﺍﺭﺓ‬
‫ﺍﻟﺘﻐﻴﲑﺍﺕ‪.‬‬

‫‪ 4-4-3‬ﺗﺘﺒﻊ اﻟﻤﺘﻄﻠﺒﺎت‬
‫ﻳﺸﻜﻞ ﺗﺘﺒﻊ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺟﺰﺀﹰﺍ ﻫﺎﻣﹰﺎ ﺟﺪﹰﺍ ﻣﻦ ﺇﺩﺍﺭﺓ ﺍﻟﺘﻐﻴﲑﺍﺕ‪ ،‬ﻭﻳﻬﺘﻢ ﻫﺬﺍ ﺍﳉﺰﺀ ﺑﺘﺘﺒﻊ ﺃﺛﺮ ﺗﻐﲑ‬
‫ﺍﳌﺘﻄﻠﺐ ﻋﻠﻰ ﺍﻟﻌﻼﻗﺎﺕ ﺑﲔ ﺍﻟﻨﻤﺎﺫﺝ ﻭﻣﻜﻮﻧﺎﻬﺗﺎ ﻋﱪ ﻣﺮﺍﺣﻞ ﺩﻭﺭﺓ ﺣﻴﺎﺓ ﺍﻟﺘﻄﻮﻳﺮ‪.‬‬
‫ﻟﻨﺄﺧﺬ ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﳌﺜﺎﻝ ﺍﳌﺘﻄﻠﺐ‪" :‬ﳚﺐ ﺃﻥ ﳚﺪﻭﻝ ﺍﻟﻨﻈﺎﻡ ﺍﻻﺗﺼﺎﻝ ﺍﳍﺎﺗﻔﻲ ﺍﻟﺘﺎﱄ ﺑﻨﺎﺀ ﻋﻠﻰ ﻃﻠﺐ‬
‫ﺍﳌﺴﻮﱢﻕ" ﻓﻘﺪ ﻳﻨﻤﺬﺝ ﻫﺬﺍ ﺍﳌﺘﻄﻠﺐ ﲟﺨﻄﻂ ﺗﺴﻠﺴﻞ‪ ،‬ﻭﳚﺮﻱ ﺗﻔﻌﻴﻠﻪ ﻋﱪ ﺗﻄﺒﻴﻖ ﻓﻌﻞ ﻋﻠﻰ ﺯﺭ ﺍﲰﻪ‬
‫"‪ "Next Call‬ﰲ ﻭﺍﺟﻬﺔ ﺍﻻﺳﺘﺨﺪﺍﻡ ﺍﻟﺒﻴﺎﻧﻴﺔ‪ ،‬ﻭﻳﱪﻣﺞ ﺑﺼﻴﻐﺔ ﻗﺎﺩﺡ ﰲ ﻗﺎﻋﺪﺓ ﻣﻌﻄﻴﺎﺕ‪ ،‬ﻭﻋﻨﺪ ﻭﺟﻮﺩ‬
‫ﻋﻼﻗﺔ ﺗﺘﺒﻊ ﺑﲔ ﻛﻞ ﻫﺬﻩ ﺍﻟﻌﻨﺎﺻﺮ ﻳﻄﺮﺡ ﺗﻐﲑ ﺃﻱ ﻣﻨﻬﺎ ﺍﻟﻌﻼﻗﺔ ﻣﻦ ﺟﺪﻳﺪ ﻟﻠﻨﻘﺎﺵ‪.‬‬
‫ﳝﻜﻦ ﺃﻥ ﲤﺘﺪ ﻋﻼﻗﺔ ﺍﻟﺘﺘﺒﻊ ﻋﱪ ﻋﺪﺓ ﳕﺎﺫﺝ ﰲ ﻣﺮﺍﺣﻞ ﻣﺘﻌﺎﻗﺒﺔ ﻣﻦ ﺩﻭﺭﺓ ﺍﳊﻴﺎﺓ‪ ،‬ﻭﻣﺎ ﳝﻜﻦ ﺗﻌﺪﻳﻠﻪ‬
‫ﻣﺒﺎﺷﺮﺓ ﻫﻮ ﻓﻘﻂ ﺍﻟﻌﻼﻗﺎﺕ ﺍﳌﺘﺠﺎﻭﺭﺓ‪ ،‬ﻭﺳﻨﺪﺭﺱ ﻫﺬﺍ ﺍﳌﻮﺿﻮﻉ ﺑﺎﻟﺘﻔﺼﻴﻞ ﰲ ﺍﻟﻔﺼﻞ ﺍﻟﻌﺎﺷﺮ‪.‬‬

‫ﻥﻤﻮذج ﻡﺘﻄﻠﺒﺎت اﻷﻋﻤﺎل‬ ‫‪5-3‬‬

‫ﺗﺼﻮﺭ ﻣﺮﺣﻠﺔ ﲢﺪﻳﺪ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺗﻠﻚ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﺗﻌﺮﻓﻬﺎ ﺑﻌﺒﺎﺭﺍﺕ ﻣﻦ ﺍﻟﻠﻐﺔ ﺍﻟﻄﺒﻴﻌﻴﺔ‪ ،‬ﰒ ﲡﺮﻱ ﳕﺬﺟﺔ‬
‫ﺍﳌﺘﻄﻠﺒﺎﺕ ﺑﺼﻴﻐﺔ ﺻﻮﺭﻳﺔ ﺑﺎﺳﺘﺨﺪﺍﻡ ﻟﻐﺔ ‪ UML‬ﰲ ﻣﺮﺣﻠﺔ ﺗﻮﺻﻴﻒ ﺍﳌﺘﻄﻠﺒﺎﺕ‪ ،‬ﻟﻜﻦ ﻳﺘﻢ ﻋﺎﺩﺓ ﲤﺜﻴﻞ‬
‫‪121‬‬ ‫‪ : 3‬ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت‬

‫ﻼ ﺑﻴﺎﻧﻴﹰﺎ ﲟﺴﺘﻮﻯ ﲡﺮﻳﺪ ﻋﺎﻝ‪ ،‬ﻭﻧﺪﻋﻮ ﻫﺬﻩ‬

‫ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻟﱵ ﰎ ﲤﺜﻴﻠﻬﺎ ﰲ ﻣﺮﺣﻠﺔ ﲢﺪﻳﺪ ﺍﳌﺘﻄﻠﺒﺎﺕ ﲤﺜﻴ ﹰ‬
‫ﺍﻟﻌﻤﻠﻴﺔ ﳕﺬﺟﺔ ﻣﺘﻄﻠﺒﺎﺕ ﺍﻷﻋﻤﺎﻝ‪.‬‬
‫ﳓﺘﺎﺝ ﳍﺬﻩ ﺍﻟﻨﻤﺎﺫﺝ ﻋﺎﻟﻴﺔ ﺍﳌﺴﺘﻮﻯ ﻟﺘﺤﺪﻳﺪ ﻧﻄﺎﻕ ﺍﻟﻨﻈﺎﻡ ﻋﻠﻰ ﺍﻷﻗﻞ ﻭﻟﻠﺘﻌﺮﻑ ﻋﻠﻰ ﺣﺎﻻﺕ‬
‫ﺍﻻﺳﺘﺨﺪﺍﻡ ﺍﻷﺳﺎﺳﻴﺔ ﻭﻟﺘﻌﻴﲔ ﺻﻔﻮﻑ ﺍﻷﻋﻤﺎﻝ ﺍﻷﻛﺜﺮ ﺃﳘﻴﺔ‪ .‬ﻳﺒﲔ ﺍﻟﺸﻜﻞ )‪ (3-3‬ﺍﻻﺭﺗﺒﺎﻃﺎﺕ ﺑﲔ‬
‫ﺍﻟﻨﻤﺎﺫﺝ ﺍﻟﺜﻼﺛﺔ ﺍﻟﻨﺎﲡﺔ ﻋﻦ ﻣﺮﺣﻠﺔ ﲢﺪﻳﺪ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﳕﺎﺫﺝ ﻣﺮﺍﺣﻞ ﺩﻭﺭﺓ ﺍﳊﻴﺎﺓ ﺍﻷﺧﺮﻯ‪.‬‬
‫ﻭﻳﻮﺿﺢ ﺍﻟﺸﻜﻞ )‪ (3-3‬ﺍﻟﺪﻭﺭ ﺍﻷﺳﺎﺳﻲ ﻭﺍﳍﺎﻡ ﺍﻟﺬﻱ ﺗﻠﻌﺒﻪ ﳐﻄﻄﺎﺕ ﺣﺎﻻﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ ﰲ ﺩﻭﺭﺓ‬
‫ﺣﻴﺎﺓ ﺍﻟﺘﻄﻮﻳﺮ‪ ،‬ﺇﺫ ﺗُﺸﺘﻖ ﻣﻨﻬﺎ ﺣﺎﻻﺕ ﺍﻻﺧﺘﺒﺎﺭ ﻭﺗﻮﺛﻴﻖ ﺍﻻﺳﺘﺨﺪﺍﻡ ﻭﺧﻄﻂ ﺍﳌﺸﺮﻭﻉ‪ .‬ﻭﺑﺎﻹﺿﺎﻓﺔ‬
‫ﻟﺬﻟﻚ ﺗﺴﺘﺨﺪﻡ ﳐﻄﻄﺎﺕ ﺣﺎﻻﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ ﻋﻠﻰ ﺍﻟﺘﻮﺍﺯﻱ ﻣﻊ ﳕﺎﺫﺝ ﺍﻟﺼﻔﻮﻑ ﻓﺘﻘﻮﺩ ﻛﻞ ﻣﻨﻬﻤﺎ‬
‫ﺍﻷﺧﺮﻯ ﰲ ﻋﻤﻠﻴﺔ ﺗﻄﻮﻳﺮ ﺗﺰﺍﻳﺪﻳﺔ‪ ،‬ﻭﺗﻈﻬﺮ ﻋﻼﻗﺔ ﻣﺸﺎﻬﺑﺔ ﺑﲔ ﺍﻟﺘﺼﻤﻴﻢ ﻭﺍﻟﺘﺤﻘﻴﻖ ﺍﻟﱵ ﻗﺪ ﺗﻌﻴﺪ‬
‫ﻣﻌﻠﻮﻣﺎﺕ ﺟﺪﻳﺪﺓ ﻟﻨﻤﺎﺫﺝ ﺗﻮﺻﻴﻒ ﺍﳌﺘﻄﻠﺒﺎﺕ‪.‬‬

‫ﻧﻤﺎذج اﻷﻋﻤﺎل ﻓﻲ دورة اﻟﺤﻴﺎة‪.‬‬ ‫اﻟﺸﻜﻞ )‪(3-3‬‬

‫‪ 1-5-3‬ﻥﻤﻮذج ﻥﻄﺎق اﻟﻨﻈﺎم‬

‫ﻗﺪ ﻳﻜﻮﻥ ﺗﻮﺳﻊ ﺍﻟﻨﻄﺎﻕ ﻫﻮ ﺃﻛﺜﺮ ﻣﺎ ﻬﻧﺘﻢ ﺑﻪ ﰲ ﺗﻄﻮﻳﺮ ﺍﻟﻨﻈﺎﻡ‪ ،‬ﻭﻳﻌﻮﺩ ﺳﺒﺐ ﻫﺬﺍ ﺍﻟﺘﻮﺳﻊ ﺇﱃ ﺍﻟﺘﻐﲑ‬
‫ﺍﻟﺪﺍﺋﻢ ﻟﻠﻤﺘﻄﻠﺒﺎﺕ‪ ،‬ﻭﻣﻊ ﺃﻥ ﺑﻌﺾ ﺍﻟﺘﻐﲑﺍﺕ ﻻ ﳝﻜﻦ ﲡﻨﺒﻬﺎ ﻟﻜﻦ ﳚﺐ ﺃﻥ ﻧﻀﻤﻦ ﺃﻻ ﺗﺘﺠﺎﻭﺯ‬
‫ﺍﻟﺘﻌﺪﻳﻼﺕ ﻧﻄﺎﻕ ﺍﳌﺸﺮﻭﻉ‪.‬‬
‫اﻟﻔﺼﻞ اﻟﺜﺎﻟﺚ‬ ‫‪122‬‬

‫ﻭﻳﺒﻘﻰ ﺍﻟﺴﺆﺍﻝ ﺍﳍﺎﻡ‪ :‬ﻛﻴﻒ ﻧﻌﺮﻑ ﻧﻄﺎﻕ ﺍﻟﻨﻈﺎﻡ؟ ﻭﻻ ﲤﻜﻦ ﺍﻹﺟﺎﺑﺔ ﻋﻠﻰ ﻫﺬﺍ ﺍﻟﺴﺆﺍﻝ ﺑﺼﻴﻐﺔ‬
‫ﻣﺒﺎﺷﺮﺓ ﻓﺄﻱ ﻧﻈﺎﻡ ﻫﻮ ﺟﺰﺀ ﻣﻦ ﳏﻴﻂ ﺃﻭﺳﻊ‪ ،‬ﺃﻭ ﺑﺎﻷﺣﺮﻯ ﺟﺰﺀ ﻣﻦ ﳎﻤﻮﻋﺔ ﻣﻦ ﺍﻷﻧﻈﻤﺔ ﺗﺸﻜﻞ‬
‫ﻣﻌﹰﺎ ﺍﶈﻴﻂ ﺑﺄﻛﻤﻠﻪ‪ ،‬ﻭﺗﺘﻌﺎﻭﻥ ﻫﺬﻩ ﺍﻷﻧﻈﻤﺔ ﺑﺘﺒﺎﺩﻝ ﺍﳌﻌﻠﻮﻣﺎﺕ ﻓﻴﻤﺎ ﺑﻴﻨﻬﺎ ﻭﺑﺎﺳﺘﺪﻋﺎﺀ ﺧﺪﻣﺎﺕ ﻣﻦ‬
‫ﺑﻌﻀﻬﺎ؛ ﻭﻟﺬﻟﻚ ﻳﻔﻀﻞ ﺃﻥ ﻧﻌﻴﺪ ﺻﻴﺎﻏﺔ ﺍﻟﺴﺆﺍﻝ ﺍﻟﺴﺎﺑﻖ ﻛﻤﺎ ﻳﻠﻲ‪ :‬ﻫﻞ ﳚﺐ ﺃﻥ ﳓﻘﻖ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺃﻡ‬
‫ﺃﻥ ﺍﻟﻮﻇﻴﻔﺔ ﺍﳌﻄﻠﻮﺑﺔ ﻣﻦ ﻣﺴﺆﻭﻟﻴﺎﺕ ﻧﻈﺎﻡ ﺁﺧﺮ؟‬
‫ﻭﻟﻜﻲ ﻧﺘﻤﻜﻦ ﻣﻦ ﺍﻹﺟﺎﺑﺔ ﻋﻠﻰ ﺍﻷﺳﺌﻠﺔ ﺍﳌﺘﻌﻠﻘﺔ ﺑﻨﻄﺎﻕ ﺍﻟﻨﻈﺎﻡ ﳚﺐ ﺃﻥ ﻧﻌﺮﻑ ﺍﻟﺴﻴﺎﻕ ﺍﻟﺬﻱ ﻳﻌﻤﻞ‬
‫ﻓﻴﻪ ﺍﻟﻨﻈﺎﻡ‪ ،‬ﳚﺐ ﺃﻥ ﻧﻌﺮﻑ ﻣﺎ ﻫﻲ ﺍﻟﻜﻴﺎﻧﺎﺕ ﺍﳋﺎﺭﺟﻴﺔ ‪ -‬ﺍﻷﻧﻈﻤﺔ ﺍﻷﺧﺮﻯ‪ ،‬ﺍﳌﺆﺳﺴﺎﺕ‪،‬‬
‫ﺍﻷﺷﺨﺎﺹ‪ ،‬ﺍﻵﻻﺕ ‪ ...‬ﺍﻟﱵ ﺗﺘﻮﻗﻊ ﻣﻨﺎ ﺑﻌﺾ ﺍﳋﺪﻣﺎﺕ ﺃﻭ ﺗﻘﺪﻡ ﻟﻨﺎ ﺧﺪﻣﺎﺕ‪ .‬ﺗﺘﺠﻠﻰ ﻫﺬﻩ‬
‫ﺍﳋﺪﻣﺎﺕ ﰲ ﻧﻈﻢ ﺍﻷﻋﻤﺎﻝ ﺑﺎﳌﻌﻠﻮﻣﺎﺕ ‪ -‬ﺃﻭ ﺗﺪﻓﻖ ﺍﳌﻌﻄﻴﺎﺕ‪.‬‬
‫ﳝﻜﻦ ﺇﺫﹰﺍ ﲢﺪﻳﺪ ﻧﻄﺎﻕ ﺍﻟﻨﻈﺎﻡ ﻣﻦ ﺧﻼﻝ ﺍﻟﺘﻌﺮﻑ ﻋﻠﻰ ﺍﻟﻜﻴﺎﻧﺎﺕ ﺍﳋﺎﺭﺟﻴﺔ ﻭﻋﻠﻰ ﺗﺪﻓﻖ ﻣﻌﻄﻴﺎﺕ‬
‫ﺍﻟﺪﺧﻞ ﻭﺍﳋﺮﺝ ﺑﲔ ﻫﺬﻩ ﺍﻟﻜﻴﺎﻧﺎﺕ ﻭﻧﻈﺎﻣﻨﺎ‪ ،‬ﺇﺫ ﳛﺼﻞ ﻧﻈﺎﻣﻨﺎ ﻋﻠﻰ ﻣﻌﻠﻮﻣﺎﺕ ﺍﻟﺪﺧﻞ ﻭﳚﺮﻱ ﻋﻠﻴﻬﺎ‬
‫ﻋﻤﻠﻴﺎﺕ ﺍﳌﻌﺎﳉﺔ ﺍﻟﻼﺯﻣﺔ ﻟﻴﻨﺘﺞ ﻣﻌﻠﻮﻣﺎﺕ ﺍﳋﺮﺝ‪ .‬ﻭﻋﻠﻴﻪ ﻳﻘﻊ ﺧﺎﺭﺝ ﻧﻄﺎﻕ ﺍﻟﻨﻈﺎﻡ ﻛﻞ ﻣﺘﻄﻠﺐ ﻻ‬
‫ﺗﺴﺘﻄﻴﻊ ﻋﻤﻠﻴﺎﺕ ﺍﳌﻌﺎﳉﺔ ﺍﻟﺪﺍﺧﻠﻴﺔ ﰲ ﺍﻟﻨﻈﺎﻡ ﺃﻥ ﺗﺪﻋﻤﻪ‪.‬‬
‫ﻻ ﺗﻮﻓﺮ ﻟﻐﺔ ‪ UML‬ﳕﻮﺫﺟﹰﺎ ﺑﻴﺎﻧﻴﹰﺎ ﺟﻴﺪﹰﺍ ﻟﺘﻌﺮﻳﻒ ﻧﻄﺎﻕ ﺍﻟﻨﻈﺎﻡ‪ ،‬ﻭﻟﺬﻟﻚ ﻣﺎﺯﺍﻝ ﻳﺴﺘﺨﺪﻡ ﳍﺬﻩ ﺍﳌﻬﻤﺔ‬
‫ﳐﻄﻂ ﺍﻟﺴﻴﺎﻕ ﺍﳌﺄﺧﻮﺫ ﻣﻦ ﺗﻘﻨﻴﺔ ﳐﻄﻄﺎﺕ ﺗﺪﻓﻖ ﺍﳌﻌﻄﻴﺎﺕ ‪) DFD‬ﺍﻟﻔﻘﺮﺓ ‪ .(1-3-3‬ﻳﺒﲔ ﺍﻟﺸﻜﻞ )‪(4-3‬‬
‫ﳐﻄﻂ ﺍﻟﺴﻴﺎﻕ ﻟﺘﻄﺒﻴﻖ ﺍﻟﺘﺴﻮﻳﻖ ﺍﳍﺎﺗﻔﻲ‪.‬‬

‫ﻡﺜﺎل ﻟﻨﻤﺬﺟﺔ ﻥﻄﺎق اﻟﻨﻈﺎم‬ ‫‪1-1-5-3‬‬

‫ﻣﺜﺎل )‪) :(1-3‬اﻟﺘﺴﻮﻳﻖ اﻟﻬﺎﺗﻔﻲ(‬

‫أﻧﺸﺊ ﻣﺨﻄﻂ اﻟﺴﻴﺎق ﻟﻤﺴﺎﻟﺔ اﻟﺘﺴﻮﻳﻖ اﻟﻬﺎﺗﻔﻲ اﻟﻮارد ﻧﺼﻬﺎ ﺳﺎﺑﻘﺎً )اﻟﻔﻘﺮة ‪(4-3-2‬‬
‫ﺁﺧﺬاً ﺑﻌﻴﻦ اﻻﻋﺘﺒﺎر اﻟﻤﻼﺣﻈﺎت اﻟﺘﺎﻟﻴﺔ‪:‬‬

‫‪ .1‬ﻳﺠﺮي اﻟﺘﺨﻄﻴﻂ ﻟﻠﺤﻤﻼت ﺑﻨﺎء ﻋﻠﻰ ﻧﺼﺎﺋﺢ وﺗﻮﺻﻴﺎت ﻣﻦ ﺟﻤﻌﻴﺔ‬

‫اﻷﻣﻨﺎء اﻟﺘﻲ ﺗﺘﺨﺬ اﻟﻘﺮار ﻷﺳﺒﺎب ﺧﻴﺮﻳﺔ‪ .‬ﻳﺠﺐ أن ﺗﻮاﻓﻖ اﻟﺤﻜﻮﻣﺔ‬
‫اﻟﻤﺤﻠﻴﺔ ﻋﻠﻰ اﻟﺤﻤﻼت‪ .‬ﻳﺪﻋﻢ ﻧﻈﺎم ﺗﻄﺒﻴﻘﻲ ﻣﺴﺘﻘﻞ ‪(Campain‬‬
‫)‪ Database‬ﺗﺼﻤﻴﻢ اﻟﺤﻤﻼت واﻟﺘﺨﻄﻴﻂ ﻟﻬﺎ‪.‬‬

‫ﺗﻮﺟﺪ ﻗﺎﻋﺪة ﻣﻌﻄﻴﺎت ﻣﺴﺘﻘﻠﺔ ‪ Supporter database‬ﺗﺤﻔﻆ‬ ‫‪.2‬‬

‫ﻣﻌﻠﻮﻣﺎت ﻋﻦ آﻞ اﻟﻤﺴﺎهﻤﻴﻦ‪-‬اﻟﺴﺎﺑﻘﻴﻦ واﻟﺤﺎﻟﻴﻴﻦ‪ ،‬وﺗﺴﺘﺨﺪم‬
‫هﺬﻩ اﻟﻘﺎﻋﺪة ﻻﻧﺘﻘﺎء اﻟﻤﺴﺎهﻤﻴﻦ اﻟﺬﻳﻦ ﺳﻴﺠﺮي اﻻﺗﺼﺎل ﺑﻬﻢ‬
‫ﻟﺪﻋﻢ ﺣﻤﻠﺔ ﻣﻌﻴﻨﺔ‪.‬‬
‫‪123‬‬ ‫‪ : 3‬ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت‬

‫ﺗﺴﺠﻞ ﻃﻠﺒﺎت ﺷﺮاء ﺑﻄﺎﻗﺎت اﻟﻴﺎﻧﺼﻴﺐ ﻟﺘﺠﺮي ﻣﺮاﺟﻌﺘﻬﺎ ﻣﻦ ﻗﺒﻞ‬ ‫‪.3‬‬

‫ﻧﻈﺎم ﻣﻌﺎﻟﺠﺔ اﻟﻄﻠﺒﺎت ‪ .Order Processing‬وﻳﺤﺘﻔﻆ هﺬا اﻟﻨﻈﺎم‬
‫ﺑﺤﺎﻟﺔ اﻟﻄﻠﺒﺎت ﻓﻲ ﻗﺎﻋﺪة ﻣﻌﻄﻴﺎت اﻟﻤﺴﺎهﻤﻴﻦ‪.‬‬

‫ﻳﺒﲔ ﺍﻟﺸﻜﻞ )‪ (4-3‬ﳐﻄﻂ ﺍﻟﺴﻴﺎﻕ ﺍﻟﺬﻱ ﻗﺪ ﲢﺼﻞ ﻋﻠﻴﻪ ﻋﻨﺪ ﺣﻞ ﻫﺬﺍ ﺍﳌﺜﺎﻝ‪ ،‬ﺣﻴﺚ ﲤﺜﻞ ﺍﻟﻔﻘﺎﻋﺔ‬
‫ﺍﻟﱵ ﺗﻈﻬﺮ ﰲ ﻣﺮﻛﺰ ﺍﳌﺨﻄﻂ ﻧﻈﺎﻣﻨﺎ ﺍﻟﺬﻱ ﻧﺪﺭﺳﻪ‪ ،‬ﺑﻴﻨﻤﺎ ﲤﺜﻞ ﺍﳌﺴﺘﻄﻴﻼﺕ ﺍﶈﻴﻄﺔ ﻬﺑﺎ ﺍﻟﻜﻴﺎﻧﺎﺕ‬
‫ﺍﳋﺎﺭﺟﻴﺔ ﻭﺗﺸﲑ ﺍﻷﺳﻬﻢ ﺇﱃ ﺗﺪﻓﻖ ﺍﳌﻌﻄﻴﺎﺕ‪ .‬ﻟﻜﻦ ﻻ ﺗﻈﻬﺮ ﻋﻠﻰ ﺍﳌﺨﻄﻂ ﺍﳌﻌﻠﻮﻣﺎﺕ ﺍﻟﺘﻔﺼﻴﻠﻴﺔ‬
‫ﺍﳌﻜﻮﻧﺔ ﻟﺘﺪﻓﻘﺎﺕ ﺍﳌﻌﻄﻴﺎﺕ ‪ -‬ﺗﻌﺮﻑ ﳏﺘﻮﻳﺎﺕ ﺗﺪﻓﻘﺎﺕ ﺍﳌﻌﻄﻴﺎﺕ ﺑﺸﻜﻞ ﻣﺴﺘﻘﻞ ﻭﲣﺰﻥ ﰲ ﺧﺎﺯﻧﺔ‬
‫ﻣﻌﻄﻴﺎﺕ ﺍﻷﺩﺍﺓ ﺍﳌﺴﺎﻧﺪﺓ ﰲ ﻫﻨﺪﺳﺔ ﺍﻟﱪﳎﻴﺎﺕ‪.‬‬

‫ﻧﻤﻮذج ﻧﻄﺎق اﻟﻨﻈﺎم‪-‬ﻣﺨﻄﻂ اﻟﺴﻴﺎق )اﻟﺘﺴﻮﻳﻖ اﻟﻬﺎﺗﻔﻲ(‪.‬‬ ‫اﻟﺸﻜﻞ )‪(4-3‬‬

‫ﳛﺼﻞ ﻧﻈﺎﻡ ﺍﻟﺘﺴﻮﻳﻖ ‪ Telemarketing‬ﻋﻠﻰ ﻣﻌﻠﻮﻣﺎﺕ ﻋﻦ ﺍﳊﻤﻠﺔ ﺍﳊﺎﻟﻴﺔ ﻣﻦ ﻛﻴﺎﻥ ﺧﺎﺭﺟﻲ ﻫﻮ‬
‫ﻗﺎﻋﺪﺓ ﻣﻌﻄﻴﺎﺕ ﺍﳊﻤﻼﺕ ‪ ،Campaign Database‬ﻭﺗﺘﻀﻤﻦ ﻫﺬﻩ ﺍﳌﻌﻠﻮﻣﺎﺕ ﻋﺪﺩ ﺍﻟﺒﻄﺎﻗﺎﺕ‬
‫ﻭﺃﺳﻌﺎﺭﻫﺎ ﻭﺍﳉﻮﺍﺋﺰ ﺍﻟﺮﺍﲝﺔ ﻭﻓﺘﺮﺓ ﺍﳊﻤﻠﺔ ﻭﻏﲑﻫﺎ ﻣﻦ ﺍﳌﻌﻠﻮﻣﺎﺕ ﺍﻷﺧﺮﻯ‪.‬‬

‫ﺑﺎﳌﺜﻞ‪ ،‬ﳛﺼﻞ ﺍﻟﻨﻈﺎﻡ ‪ Telemarketing‬ﻋﻠﻰ ﻣﻌﻠﻮﻣﺎﺕ ﺗﻔﺼﻴﻠﻴﺔ ﻋﻦ ﺍﳌﺴﺎﳘﲔ ﻣﻦ ﻗﺎﻋﺪﺓ ﺍﳌﻌﻄﻴﺎﺕ‬

‫ﺍﳋﺎﺻﺔ ‪ ،Supporter Database‬ﻭﻗﺪ ﺗﻈﻬﺮ ﻣﻌﻠﻮﻣﺎﺕ ﺟﺪﻳﺪﺓ ﻋﻦ ﺍﳌﺴﺎﻫﻢ ﺧﻼﻝ ﺍﺗﺼﺎﻝ ﺍﻟﺘﺴﻮﻳﻖ‬
‫ﻼ(‪ ،‬ﻭﻟﺬﻟﻚ ﳚﺐ ﲢﺪﻳﺚ ﻗﺎﻋﺪﺓ ﺍﳌﻌﻄﻴﺎﺕ ﺑﺎﳌﻌﻠﻮﻣﺎﺕ ﺍﳉﺪﻳﺪﺓ‪،‬‬‫)ﻛﺄﻥ ﻳﻐﲑ ﺍﳌﺴﺎﻫﻢ ﺭﻗﻢ ﻫﺎﺗﻔﻪ ﻣﺜ ﹰ‬
‫اﻟﻔﺼﻞ اﻟﺜﺎﻟﺚ‬ ‫‪124‬‬

‫ﻭﳍﺬﺍ ﻧﻼﺣﻆ ﺃﻥ ﺗﺪﻓﻖ ﺍﳌﻌﻄﻴﺎﺕ ‪ Supporter Details‬ﳚﺮﻱ ﰲ ﺍﻻﲡﺎﻫﲔ‪.‬‬

‫ﳚﺮﻱ ﺍﻟﻨﺸﺎﻁ ﺍﻷﺳﺎﺳﻲ ﺑﲔ ﺍﻟﻨﻈﺎﻡ ‪ Telemarketing‬ﻭﺍﳌﺴﺎﻫﻢ ‪ ،Supporter‬ﻭﳛﻮﻱ ﺗﺪﻓﻖ‬
‫ﺍﳌﻌﻄﻴﺎﺕ ﺍﳌﺴﻤﻰ ‪ Conversation‬ﺍﳌﻌﻠﻮﻣﺎﺕ ﺍﳌﺘﺒﺎﺩﻟﺔ ﺧﻼﻝ ﺍﶈﺎﺩﺛﺔ ﺍﳍﺎﺗﻔﻴﺔ‪ ،‬ﻭﺗﻨﺘﻘﻞ ﺇﺟﺎﺑﺔ ﺍﳌﺴﺎﻫﻢ‬
‫ﺇﱃ ﺍﳌﺴﻮﻕ ﻋﱪ ﺗﺪﻓﻖ ﺍﳌﻌﻄﻴﺎﺕ ﺍﳌﺴﻤﻰ ‪ ،Outcome‬ﻭﻳﺴﺘﺨﺪﻡ ﺗﺪﻓﻖ ﺍﳌﻌﻄﻴﺎﺕ ﺍﳌﺴﺘﻘﻞ ‪Ticket‬‬
‫‪ Placement‬ﻟﺘﺴﺠﻴﻞ ﺍﻟﺘﻔﺎﺻﻴﻞ ﺍﳌﺘﻌﻠﻘﺔ ﺑﺎﻟﺒﻄﺎﻗﺎﺕ ﺍﻟﱵ ﻃﻠﺒﻬﺎ ﺍﳌﺴﺎﻫﻢ‪.‬‬
‫ﺗﻘﻊ ﻋﻤﻠﻴﺔ ﻣﻌﺎﳉﺔ ﻃﻠﺒﺎﺕ ﺷﺮﺍﺀ ﺍﻟﺒﻄﺎﻗﺎﺕ ﺧﺎﺭﺝ ﻧﻄﺎﻕ ﻧﻈﺎﻣﻨﺎ ﻭﻟﺬﻟﻚ ﻳﺘﺠﻪ ﺗﺪﻓﻖ ﺍﳌﻌﻄﻴﺎﺕ‬
‫‪ Ticket Order‬ﺇﱃ ﺍﻟﻜﻴﺎﻥ ﺍﳋﺎﺭﺟﻲ ‪ ،Order Processing‬ﻭﺳﻨﻔﺘﺮﺽ ﺃﻧﻪ ﺑﻌﺪ ﺇﺩﺧﺎﻝ ﺍﻟﻄﻠﺒﺎﺕ‬
‫ﺗﺘﻜﻔﻞ ﻛﻴﺎﻧﺎﺕ ﺧﺎﺭﺟﻴﺔ ﺃﺧﺮﻯ ﲟﻌﺎﳉﺔ ﻋﻤﻠﻴﺎﺕ ﺍﻟﺪﻓﻊ ﻭﺇﺭﺳﺎﻝ ﺍﻟﺒﻄﺎﻗﺎﺕ ﻭﺍﳉﻮﺍﺋﺰ‪ ...‬ﻭﻟﻦ ﻬﻧﺘﻢ‬
‫ﻬﺑﺬﻩ ﺍﻟﻌﻤﻠﻴﺎﺕ ﻃﺎﳌﺎ ﺃﻧﻨﺎ ﻧﺴﺘﻄﻴﻊ ﺍﳊﺼﻮﻝ ﻋﻠﻰ ﺣﺎﻟﺔ ﻣﻌﺎﳉﺔ ﺍﻟﻄﻠﺒﺎﺕ ﻭﺍﻟﺪﻓﻌﺎﺕ ﻭﻏﲑﻫﺎ ﻣﻦ‬
‫ﻛﻴﺎﻧﺎﺕ ﺧﺎﺭﺟﻴﺔ ﻫﻲ ‪ Campaign Database‬ﻭ ‪.Supporter Database‬‬

‫‪ 2-5-3‬ﻥﻤﻮذج ﺡﺎﻻت اﺳﺘﺨﺪام اﻷﻋﻤﺎل‬

‫ﺇﻥ ﳕﻮﺫﺝ ﺣﺎﻟﺔ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﻌﻤﻞ ﻫﻮ ﻋﺒﺎﺭﺓ ﻋﻦ ﳕﻮﺫﺝ ﺣﺎﻟﺔ ﺍﺳﺘﺨﺪﺍﻡ ﻋﻠﻰ ﻣﺴﺘﻮﻯ ﻋﺎﻝ ﻣﻦ‬
‫ﺍﻟﺘﺠﺮﻳﺪ )ﺍﻟﻔﻘﺮﺓ ‪ ،(2-2-2‬ﻓﻬﻮ ﻳﻌﺮﻑ ﺇﺟﺮﺍﺋﻴﺎﺕ ﺍﻟﻌﻤﻞ ﰲ ﺍﳌﺴﺘﻮﻯ ﺍﻷﻋﻠﻰ ‪ -‬ﺃﻱ ﺣﺎﻻﺕ ﺍﺳﺘﺨﺪﺍﻡ‬
‫ﺍﻟﻌﻤﻞ‪ ،‬ﻭﺗﻘﺎﺑﻞ ﺣﺎﻟﺔ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﻌﻤﻞ ﻣﺎ ﻳﺪﻋﻰ ﺃﺣﻴﺎﻧﹰﺎ ﻣﻴﺰﺓ ﻟﻠﻨﻈﺎﻡ )ﺗُﺤﺪﺩ ﻣﻴﺰﺍﺕ ﺍﻟﻨﻈﺎﻡ ﰲ ﻭﺛﻴﻘﺔ‬
‫ﺍﻟﺮﺅﻳﺔ‪ ،‬ﻓﺈﺫﺍ ﻛﺎﻧﺖ ﻫﺬﻩ ﺍﻟﻮﺛﻴﻘﺔ ﻣﻮﺟﻮﺩﺓ ﳝﻜﻦ ﺃﻥ ﺗﺴﺘﺨﺪﻡ ﺑﺪ ﹰﻻ ﻣﻦ ﳕﻮﺫﺝ ﺣﺎﻟﺔ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﻌﻤﻞ(‪.‬‬
‫ﻳﺮﻛﺰ ﳐﻄﻂ ﺣﺎﻻﺕ ﺍﻟﻌﻤﻞ ﻋﻠﻰ ﺑﻨﻴﺔ ﺇﺟﺮﺍﺋﻴﺎﺕ ﺍﻟﻌﻤﻞ ﺇﺫ ﻳﻌﻄﻲ ﻫﺬﺍ ﺍﳌﺨﻄﻂ ﺭﺅﻳﺔ ﻋﺎﻣﺔ ﻟﺴﻠﻮﻙ‬
‫ﺍﻟﻨﻈﺎﻡ ﺍﳌﺮﻏﻮﺏ‪ ،‬ﻭﺗﻮﺻﻒ ﻛﻞ ﺣﺎﻟﺔ ﺍﺳﺘﺨﺪﺍﻡ ﺑﻨﺺ ﺳﺮﺩﻱ ﻣﻮﺟﺰ ﻭﻣﻮﺟﻪ ﺑﺎﻟﻌﻤﻞ ﻭﻳﺮﻛﺰ ﻋﻠﻰ‬
‫ﺳﲑ ﺍﻷﻧﺸﻄﺔ ﺍﻟﺮﺋﻴﺴﻲ‪ ،‬ﻟﻜﻦ ﻻ ﻳﻌﺘﱪ ﳕﻮﺫﺝ ﺣﺎﻻﺕ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﻌﻤﻞ ﻣﻨﺎﺳﺒﹰﺎ ﻹﻳﺼﺎﻝ ﻣﺎ ﳚﺐ ﻋﻠﻰ‬
‫ﺍﻟﻨﻈﺎﻡ ﻓﻌﻠﻪ ﺑﺪﻗﺔ ﺇﱃ ﺍﳌﻄﻮﺭﻳﻦ‪.‬‬
‫ُﺗﺤﻮﱠﻝ ﺣﺎﻻﺕ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻷﻋﻤﺎﻝ ﰲ ﻣﺮﺣﻠﺔ ﺗﻮﺻﻴﻒ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺇﱃ ﺣﺎﻻﺕ ﺍﺳﺘﺨﺪﺍﻡ‪ ،‬ﻓﻔﻲ ﻫﺬﻩ‬
‫ﺍﳌﺮﺣﻠﺔ ﺗﻌﺮﻑ ﺣﺎﻻﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ ﺍﻟﺘﻔﺼﻴﻠﻴﺔ ﻭﻳﻔﺼﻞ ﺍﻟﻮﺻﻒ ﺍﻟﺴﺮﺩﻱ ﻟﻴﺸﻤﻞ ﺍﻹﺟﺮﺍﺋﻴﺎﺕ ﺍﻟﻔﺮﻋﻴﺔ‬
‫ﻭﺍﻹﺟﺮﺍﺋﻴﺎﺕ ﺍﻟﺒﺪﻳﻠﺔ‪ ،‬ﻛﻤﺎ ﺗﻮﺿﻊ ﺗﺼﻮﺭﺍﺕ ﺑﺪﺍﺋﻴﺔ ﻟﺸﺎﺷﺎﺕ ﻭﺍﺟﻬﺎﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ ﻭﲢﺪﺩ ﺍﻟﻌﻼﻗﺎﺕ‬
‫ﺑﲔ ﺣﺎﻻﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ‪.‬‬

‫ﳜﺘﻠﻒ ﺍﻟﻔﺎﻋﻠﻮﻥ ﰲ ﳐﻄﻂ ﺣﺎﻻﺕ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻷﻋﻤﺎﻝ ﻋﻦ ﺍﻟﻜﻴﺎﻧﺎﺕ ﺍﳋﺎﺭﺟﻴﺔ ﰲ ﳐﻄﻂ ﺍﻟﺴﻴﺎﻕ‪،‬‬
‫ﻭﻳﺘﺠﻠﻰ ﻫﺬﺍ ﺍﻟﻔﺎﺭﻕ ﰲ ﻃﺮﻳﻘﺔ ﺗﻔﺎﻋﻞ ﺍﻟﻔﺎﻋﻠﲔ ﻣﻊ ﺍﻟﻨﻈﺎﻡ‪ ،‬ﻓﺎﻟﻔﺎﻋﻞ ﳝﺘﻠﻚ ﺍﻟﺘﺤﻜﻢ ﻭﻫﻮ ﳛﺮﺽ‬
‫ﺣﺎﻻﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ ﻋﱪ ﺇﺭﺳﺎﻝ ﺃﺣﺪﺍﺙ ﺇﻟﻴﻬﺎ‪ ،‬ﻓﺤﺎﻻﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ ﻣﺴﺎﻗﺔ ﺑﺎﻷﺣﺪﺍﺙ‪ ،‬ﻭﺍﳋﻄﻮﻁ‬
‫‪125‬‬ ‫‪ : 3‬ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت‬

‫ﺍﻟﱵ ﺗﺼﻞ ﺍﻟﻔﺎﻋﻠﲔ ﲝﺎﻻﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ ﻟﻴﺴﺖ ﺗﺪﻓﻘﺎﺕ ﳌﻌﻄﻴﺎﺕ‪ ،‬ﺑﻞ ﲤﺜﻞ ﺗﺪﻓﻖ ﺍﻷﺣﺪﺍﺙ ﻣﻦ‬
‫ﺍﻟﻔﺎﻋﻠﲔ ﻭﺗﺪﻓﻖ ﺍﻻﺳﺘﺠﺎﺑﺎﺕ ﻣﻦ ﺣﺎﻻﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ‪.‬‬
‫ﺑﺎﻹﺿﺎﻓﺔ ﳌﺎ ﺗﻘﺪﻡ‪ ،‬ﲦﺔ ﻣﻼﺣﻈﺔ ﺟﺪﻳﺮﺓ ﺑﺎﻻﻫﺘﻤﺎﻡ‪ ،‬ﻓﻘﺪ ﻳﻜﻮﻥ ﺍﻟﻔﺎﻋﻠﻮﻥ ﺧﺎﺭﺟﻴﲔ ﺃﻭ ﺩﺍﺧﻠﻴﲔ‬
‫ﺑﺎﻟﻨﺴﺒﺔ ﻟﻠﻨﻈﺎﻡ‪ ،‬ﻓﺎﻟﻔﺎﻋﻞ ﺧﺎﺭﺟﻲ ﻷﻧﻪ ﻳﺘﻔﺎﻋﻞ ﻣﻊ ﺍﻟﻨﻈﺎﻡ ﻣﻦ ﺍﳋﺎﺭﺝ‪ ،‬ﻭﻫﻮ ﺩﺍﺧﻠﻲ ﻷﻥ ﺍﻟﻨﻈﺎﻡ ﻗﺪ‬
‫ﳛﺘﻔﻆ ﲟﻌﻠﻮﻣﺎﺕ ﻋﻨﻪ ﲤﻜﻨﻪ ﻣﻦ ﺍﻟﺘﺨﺎﻃﺐ ﻣﻌﻪ‪ .‬ﳚﺐ ﺃﻥ ﻳﺼﻒ ﺗﻮﺻﻴﻒ ﺍﻟﻨﻈﺎﻡ‪ ،‬ﻣﻦ ﺣﻴﺚ ﺃﻧﻪ‬
‫ﳕﻮﺫﺝ‪ ،‬ﺍﻟﻨﻈﺎﻡ ﻭﳏﻴﻄﻪ ﻓﺎﶈﻴﻂ ﳛﻮﻱ ﺍﻟﻔﺎﻋﻠﲔ ﻭﻗﺪ ﳛﺘﻔﻆ ﺍﻟﻨﻈﺎﻡ ﻧﻔﺴﻪ ﲟﻌﻠﻮﻣﺎﺕ ﻋﻦ ﺍﻟﻔﺎﻋﻠﲔ‪ .‬ﻣﻦ‬
‫ﻫﻨﺎ ﳚﺴﺪ ﺍﻟﺘﻮﺻﻴﻒ ﳕﻮﺫﺟﲔ ﻓﻴﻤﺎ ﳜﺺ ﺍﻟﻔﺎﻋﻠﲔ‪-‬ﳕﻮﺫﺝ ﻟﻠﻔﺎﻋﻞ ﻭﳕﻮﺫﺝ ﳌﺎ ﻳﺴﺠﻠﻪ ﺍﻟﻨﻈﺎﻡ ﻋﻦ‬
‫ﺍﻟﻔﺎﻋﻞ‪.‬‬

‫ﻡﺜﺎل ﻟﻨﻤﺬﺟﺔ ﺡﺎﻻت اﺳﺘﺨﺪام اﻷﻋﻤﺎل‬ ‫‪1-2-5-3‬‬

‫ﻣﺜﺎل )‪) : (2-3‬اﻟﺘﺴﻮﻳﻖ اﻟﻬﺎﺗﻔﻲ(‬

‫ﺑﺎﻟﻌﻮدة إﻟﻰ ﻧﺺ ﻣﺴﺄﻟﺔ اﻟﺘﺴﻮﻳﻖ اﻟﻬﺎﺗﻔﻲ وإﻟﻰ ﻣﺨﻄﻂ اﻟﺴﻴﺎق اﻟﺨﺎص ﺑﻬﺎ‬
‫)اﻟﻔﻘﺮﺗﻴﻦ ‪ 4-3-2‬و ‪ (1-1-5-3‬أﻧﺸﺊ ﻣﺨﻄﻂ ﺣﺎﻻت اﺳﺘﺨﺪام اﻷﻋﻤﺎل‪.‬‬

‫ﻳﺒﲔ ﺍﻟﺸﻜﻞ )‪ (5-3‬ﳐﻄﻄﹰﺎ ﳑﻜﻨﹰﺎ ﳊﺎﻻﺕ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻷﻋﻤﺎﻝ‪ ،‬ﻭﻳﻈﻬﺮ ﰲ ﻫﺬﺍ ﺍﳌﺨﻄﻂ ﻓﺎﻋﻼﻥ‪:‬‬
‫ﺍﳌﺴﻮّﻕ ‪ Telemarketer‬ﻭﺍﳌﺴﺎﻫﻢ ‪ .Supporter‬ﻳﻄﻠﺐ ﺍﳌﺴﻮﻕ ﻣﻦ ﺍﻟﻨﻈﺎﻡ ﺃﻥ ﳚﺪﻭﻝ ﺍﺗﺼﺎ ﹰﻻ ﻫﺎﺗﻔﻴﹰﺎ‬
‫ﺑﺎﳌﺴﺎﻫﻢ ﻭﻳﻄﻠﺒﻪ‪ ،‬ﻭﻋﻨﺪ ﳒﺎﺡ ﺍﻻﺗﺼﺎﻝ ﻳﺼﺒﺢ ﺍﳌﺴﺎﻫﻢ ﻓﺎﻋﻼﹰ‪ ،‬ﻭﺗﺼﺒﺢ ﺣﺎﻟﺔ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﻌﻤﻞ‬
‫‪) Schedule Phone Conversation‬ﺍﻟﱵ ﺗﺘﻀﻤﻦ ﻫﻨﺎ ﺇﻗﺎﻣﺔ ﺍﻻﺗﺼﺎﻝ( ﺟﺰﺀﹰﺍ ﻣﻦ ﻭﻇﻴﻔﺔ ﻣﻔﻴﺪﺓ ﻳﺮﺍﻫﺎ‬
‫ﻣﻦ ﺍﳋﺎﺭﺝ ﻛﻼ ﺍﻟﻔﺎﻋﻠﲔ‪.‬‬
‫ﻗﺪ ﳛﺘﺎﺝ ﺍﳌﺴﻮﻕ ﺧﻼﻝ ﺍﶈﺎﺩﺛﺔ ﻟﻠﻮﺻﻮﻝ ﺇﱃ ﺗﻔﺎﺻﻴﻞ ﺍﳊﻤﻠﺔ ﻭﺍﳌﺴﺎﻫﻢ‪ ،‬ﻭﻫﺬﺍ ﻣﺎ ﺗﺼﻮﺭﻩ ﺣﺎﻟﺔ‬
‫ﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﻌﻤﻞ ﺍﳌﺴﻤﺎﺓ ‪) CRUD Campaign and Supporter Details‬ﺍﻷﺣﺮﻑ ‪ CRUD‬ﻫﻲ‬
‫ﺍﺧﺘﺼﺎﺭ ﺷﺎﺋﻊ ﻳﺸﲑ ﺇﱃ ﺍﻟﻌﻤﻠﻴﺎﺕ ﺍﻷﺳﺎﺳﻴﺔ ﺍﻷﺭﺑﻊ ﺍﻟﱵ ﳝﻜﻦ ﺃﻥ ﺗﻄﺒﻖ ﻋﻠﻰ ﺍﳌﻌﻄﻴﺎﺕ ﻭﻫﻲ‪:‬‬
‫‪.(Create, Read, Update, Delete‬‬
‫ﺃﺧﲑﹰﺍ ﲣﺪﻡ ﺣﺎﻟﺔ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﻌﻤﻞ ﺍﳌﺴﻤﺎﺓ ‪Enter Conversation Outcome‬ﻫﺪﻑ ﺇﺩﺧﺎﻝ ﻧﺘﺎﺋﺞ‬
‫ﻋﻤﻠﻴﺔ ﺍﻟﺘﺴﻮﻳﻖ ﺳﻮﺍﺀ ﻛﺎﻧﺖ ﻧﺎﺟﺤﺔ ﺃﻡ ﻻ‪ ،‬ﻭﺗﻌﻄﻲ ﻫﺬﻩ ﺍﳊﺎﻟﺔ ﻧﺘﻴﺠﺔ ﺫﺍﺕ ﻗﻴﻤﺔ ﻟﻜﻼ ﺍﻟﻔﺎﻋﻠﲔ‪.‬‬
‫اﻟﻔﺼﻞ اﻟﺜﺎﻟﺚ‬ ‫‪126‬‬

‫ﻧﻤﻮذج ﺣﺎﻻت اﺳﺘﺨﺪام اﻷﻋﻤﺎل )اﻟﺘﺴﻮﻳﻖ اﻟﻬﺎﺗﻔﻲ(‪.‬‬ ‫اﻟﺸﻜﻞ )‪(5-3‬‬

‫‪CURD Campaign and Supporter Details‬‬ ‫ﻟﻘﺪ ﺣﺬﻓﻨﺎ ﻫﻨﺎ ﺍﻟﻌﻼﻗﺔ ﺑﲔ ﺣﺎﻟﱵ ﺍﻻﺳﺘﺨﺪﺍﻡ‬
‫ﻭ ‪ ،Enter Conversation Outcome‬ﻭﳝﻜﻦ ﻋﻤﻮﻣﹰﺎ ﺣﺬﻑ ﻛﻞ ﺍﻟﻌﻼﻗﺎﺕ ﺑﲔ ﺣﺎﻻﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ‬
‫ﻟﺘﺠﻨﺐ ﺯﻳﺎﺩﺓ ﺷﻜﻞ ﺍﳌﺨﻄﻂ‪ ،‬ﻓﻤﻦ ﺣﻴﺚ ﺍﳌﺒﺪﺃ ﻳﻮﺟﺪ ﻧﻮﻉ ﻣﻦ ﺍﻻﺗﺼﺎﻝ ﺩﻭﻣﹰﺎ ﺑﲔ ﺃﻱ ﺣﺎﻟﺔ‬
‫ﺍﺳﺘﺨﺪﺍﻡ ﻭﺍﳊﺎﻻﺕ ﺍﻷﺧﺮﻯ ﻭﺇﺩﺭﺍﺝ ﻛﻞ ﻫﺬﻩ ﺍﻟﻌﻼﻗﺎﺕ ﻋﻠﻰ ﺍﳌﺨﻄﻂ ﻗﺪ ﻳﺸﺘﺘﻨﺎ ﻋﻦ ﺍﻟﻐﺎﻳﺔ‬
‫ﺍﻷﺳﺎﺳﻴﺔ ﻣﻨﻪ‪.‬‬

‫‪ 3-5-3‬ﻥﻤﻮذج ﺹﻔﻮف اﻷﻋﻤﺎل‬

‫ﺇﻥ ﳕﻮﺫﺝ ﺻﻔﻮﻑ ﺍﻷﻋﻤﺎﻝ ﻫﻮ ﰲ ﺍﻟﻮﺍﻗﻊ ﳕﻮﺫﺝ ﺻﻔﻮﻑ‪ ،‬ﻭﻛﻤﺎ ﻫﻮ ﺍﳊﺎﻝ ﺑﺎﻟﻨﺴﺒﺔ ﻟﻨﻤﻮﺫﺝ‬
‫ﺣﺎﻻﺕ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻷﻋﻤﺎﻝ ﻳﻜﻤﻦ ﺍﻟﻔﺮﻕ ﺑﲔ ﳕﻮﺫﺝ ﺻﻔﻮﻑ ﺍﻷﻋﻤﺎﻝ ﻭﳕﻮﺫﺝ ﺍﻟﺼﻔﻮﻑ ﰲ‬
‫ﻣﺴﺘﻮﻯ ﺍﻟﺘﺠﺮﻳﺪ ﺍﻟﺬﻱ ﳚﺴﺪﻩ ﻛﻞ ﻣﻨﻬﻤﺎ‪ ،‬ﻓﻴﻌﺮﻑ ﳕﻮﺫﺝ ﺻﻔﻮﻑ ﺍﻷﻋﻤﺎﻝ ﺃﻏﺮﺍﺽ ﺍﻷﻋﻤﺎﻝ‬
‫ﺍﻟﺮﺋﻴﺴﻴﺔ ﰲ ﺍﻟﻨﻈﺎﻡ ‪ -‬ﺃﻱ ﺑﲎ ﻣﻌﻄﻴﺎﺕ ﺍﻟﻌﻤﻞ ﺍﻟﱵ ﺗﺸﻜﻞ ﺃﺳﺎﺱ ﺍﻟﻨﻈﺎﻡ ﻭﺗﻮﺟﻬﻪ‪.‬‬
‫ﳝﺜﻞ ﳕﻮﺫﺝ ﺻﻔﻮﻑ ﺍﻷﻋﻤﺎﻝ ﻣﺴﺘﻮﻳﹰﺎ ﻋﺎﻟﻴﹰﺎ ﻣﻦ ﺍﻟﺘﺠﺮﻳﺪ‪ ،‬ﻭﰲ ﻫﺬﺍ ﺍﳌﺴﺘﻮﻯ ﻻ ﻬﻧﺘﻢ ﻛﺜﲑﹰﺍ ﺑﺼﻔﺎﺕ‬
‫ﺍﻟﺼﻔﻮﻑ ﻭﳏﺘﻮﻳﺎﻬﺗﺎ ﻭﻗﺪ ﻳﻜﻔﻲ ﺍﺳﻢ ﺍﻟﺼﻒ ﻣﻊ ﻭﺻﻒ ﻣﻮﺟﺰ ﻟﻪ‪ ،‬ﻭﰲ ﻛﺜﲑ ﻣﻦ ﺍﻷﺣﻴﺎﻥ ﳝﺜﻞ‬
‫ﻓﺎﻋﻠﻮ ﳕﻮﺫﺝ ﺣﺎﻻﺕ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻷﻋﻤﺎﻝ ﻛﺼﻔﻮﻑ ﰲ ﳕﻮﺫﺝ ﺻﻔﻮﻑ ﺍﻷﻋﻤﺎﻝ‪ ،‬ﻭﻫﺬﺍ ﻳﻨﺴﺠﻢ ﻣﻊ‬
‫‪127‬‬ ‫‪ : 3‬ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت‬

‫ﺍﳌﻼﺣﻈﺔ ﺍﻟﱵ ﺫﻛﺮﻧﺎﻫﺎ ﺳﺎﺑﻘﹰﺎ ﺇﺫ ﺃﺷﺮﻧﺎ ﺇﱃ ﺃﻥ ﺍﻟﻔﺎﻋﻠﲔ ﻏﺎﻟﺒﹰﺎ ﻣﺎ ﻳﻜﻮﻧﻮﻥ ﺩﺍﺧﻠﻴﲔ ﻭﺧﺎﺭﺟﻴﲔ‬
‫ﺑﺎﻟﻨﺴﺒﺔ ﻟﻠﻨﻈﺎﻡ ﰲ ﺍﻟﻮﻗﺖ ﻧﻔﺴﻪ )ﺍﻟﻔﻘﺮﺓ ‪.(2-5-3‬‬

‫ﻡﺜﺎل ﻟﻨﻤﺬﺟﺔ ﺹﻔﻮف اﻷﻋﻤﺎل‬ ‫‪1-3-5-3‬‬

‫ﻣﺜﺎل )‪) :(3-3‬اﻟﺘﺴﻮﻳﻖ اﻟﻬﺎﺗﻔﻲ(‬

‫ﺑﻌﺪ اﻟﻌﻮدة إﻟﻰ ﻧﺺ ﻣﺴﺎﻟﺔ اﻟﺘﺴﻮﻳﻖ اﻟﻬﺎﺗﻔﻲ وإﻟﻰ ﻣﺨﻄﻂ اﻟﺴﻴﺎق وﻣﺨﻄﻂ ﺣﺎﻻت‬
‫اﺳﺘﺨﺪام اﻷﻋﻤﺎل )اﻟﻔﻘﺮات ‪ 4-3-2‬و ‪ 1-1-5-3‬و ‪ (1-2-5-3‬أﻧﺸﺊ ﻣﺨﻄﻂ ﺻﻔﻮف‬
‫اﻷﻋﻤﺎل‪ .‬ﻗﺪ ﺗﺴﺎﻋﺪك ﻓﻲ ذﻟﻚ اﻟﻤﻼﺣﻈﺘﺎن اﻟﺘﺎﻟﻴﺘﺎن‪.‬‬

‫‪ .1‬إن اﻟﻤﻬﻤﺔ اﻷﺳﺎﺳﻴﺔ ﻟﻠﻨﻈﺎم هﻲ ﺟﺪوﻟﺔ اﻻﺗﺼﺎﻻت‪ ،‬وهﻲ ﺑﺤﺪ‬

‫ذاﺗﻬﺎ ﻣﺴﺄﻟﺔ إﺟﺮاﺋﻴﺔ‪ :‬أي أن ﺣﻠﻬﺎ هﻮ ﺣﻞ ﺧﻮارزﻣﻲ ﺑﻄﺒﻴﻌﺘﻬﺎ‪.‬‬
‫ﻳﺠﺐ أن ﺗﺨﺰن أرﺗﺎل اﻟﻤﻜﺎﻟﻤﺎت اﻟﻤﺠﺪوﻟﺔ وﻧﺘﺎﺋﺞ اﻻﺗﺼﺎﻻت ﻓﻲ‬
‫ﺑﻨﻴﺔ ﻣﻌﻄﻴﺎت ﻣﻦ ﻧﻤﻂ ﻣﺎ‪.‬‬

‫‪ .2‬آﻤﺎ ذآﺮﻧﺎ ﺳﺎﺑﻘﺎً‪ ،‬ﻓﻘﺪ ﻧﺤﺘﺎج ﻟﺤﻔﻆ ﻣﻌﻠﻮﻣﺎت ﻋﻦ اﻟﻔﺎﻋﻠﻴﻦ ﻓﻲ‬

‫اﻟﺼﻔﻮف‪.‬‬

‫ﻳﺒﲔ ﺍﻟﺸﻜﻞ )‪ (6-3‬ﺻﻮﺭﺓ ﺃﻭﻟﻴﺔ ﻟﻨﻤﻮﺫﺝ ﺻﻔﻮﻑ ﺍﻷﻋﻤﺎﻝ‪ ،‬ﻭﻳﺘﻀﻤﻦ ﺍﳌﺨﻄﻂ ﺳﺘﺔ ﺻﻔﻮﻑ‪ ،‬ﺍﺷﺘُﻖ‬
‫ﺍﺛﻨﺎﻥ ﻣﻨﻬﺎ)‪ Supporter‬ﻭ‪ (Telemarketer‬ﻣﻦ ﻓﺎﻋﻠﻲ ﳕﻮﺫﺝ ﺣﺎﻻﺕ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻷﻋﻤﺎﻝ‪ .‬ﲢﺼﻞ‬
‫ﺧﻮﺍﺭﺯﻣﻴﺔ ﺟﺪﻭﻟﺔ ﺍﻻﺗﺼﺎﻻﺕ ﻋﻠﻰ ﺭﻗﻢ ﻫﺎﺗﻒ‪ ،‬ﻣﻌﻠﻮﻣﺎﺕ ﺃﺧﺮﻯ ﻣﻦ ﺍﻟﺼﻒ ‪ Supporter‬ﻭﲡﺪﻭﻝ‬
‫ﺍﳌﻜﺎﳌﺔ ﻋﻠﻰ ﻗﺎﺋﻤﺔ ﺍﺗﺼﺎﻻﺕ ﺃﺣﺪ ﺍﳌﺴﻮﻗﲔ )‪ (Telemarketers‬ﺍﳌﺘﻮﻓﺮﻳﻦ ﺣﺎﻟﻴﺎﹰ‪ ،‬ﻭﺳﻴﺠﺮﻱ ﲢﻘﻴﻖ‬
‫ﻫﺬﻩ ﺍﳋﻮﺍﺭﺯﻣﻴﺔ ﰲ ﻗﺎﻋﺪﺓ ﻣﻌﻄﻴﺎﺕ ﺍﻟﻨﻈﺎﻡ ﺑﺼﻴﻐﺔ ﺇﺟﺮﺍﺀ ﳐﺰﻥ )ﺍﻟﻔﻘﺮﺓ ‪.(1-2-1-9‬‬
‫ﻳﺘﻀﻤﻦ ﺍﻟﺼﻒ ‪ Call Scheduled‬ﻗﺎﺋﻤﺔ ﺍﳌﻜﺎﳌﺎﺕ ﺍﺠﻤﻟﺪﻭﻟﺔ ﺣﺎﻟﻴﹰﺎ ﲟﺎ ﻓﻴﻬﺎ ﺍﳌﻜﺎﳌﺎﺕ ﺍﳉﺎﺭﻳﺔ ﰲ ﺗﻠﻚ‬
‫ﺍﻟﻠﺤﻈﺔ‪ ،‬ﻭﺗﺴﺠﻞ ﺣﺼﻴﻠﺔ ﺍﳌﻜﺎﳌﺎﺕ ﰲ ﺍﻟﺼﻒ ‪ Call Outcome‬ﻭﻗﺪ ﺗﺼﻞ ﺁﺛﺎﺭﻫﺎ ﺇﱃ ﺻﻔﻮﻑ‬
‫ﺃﺧﺮﻯ ﻣﺜﻞ ‪ Campaign Ticket‬ﺃﻭ ‪.Supporter‬‬
‫اﻟﻔﺼﻞ اﻟﺜﺎﻟﺚ‬ ‫‪128‬‬

‫ﻧﻤﻮذج ﺻﻔﻮف اﻷﻋﻤﺎل )اﻟﺘﺴﻮﻳﻖ اﻟﻬﺎﺗﻔﻲ(‪.‬‬ ‫اﻟﺸﻜﻞ )‪(6-3‬‬

‫ﻳﺘﻀﻤﻦ ﺍﻟﺼﻒ ‪ Campaign‬ﺍﻷﻏﺮﺍﺽ ‪ Campaign Tickets‬ﻭﻗﺪ ﺗﺮﺗﺒﻂ ﺑﻐﺮﺽ ﻣﻨﻪ ﻋﺪﺓ ﺃﻏﺮﺍﺽ ﻣﻦ‬
‫ﺍﻟﺼﻒ ‪ .Call Scheduled‬ﺑﺎﳌﺜﻞ ﳝﻜﻦ ﺃﻥ ﻳﺮﺗﺒﻂ ﺑﺎﻟﻐﺮﺽ ‪ Supporter‬ﻭﺑﺎﻟﻐﺮﺽ ‪Telemarketer‬‬
‫ﻋﺪﺓ ﺃﻏﺮﺍﺽ ‪ ،Call Scheduled‬ﺃﻣﺎ ﺍﻻﻗﺘﺮﺍﻥ ﺑﲔ ‪ Call Scheduled‬ﻭ ‪ Call Outcome‬ﻓﻬﻮ ﻣﻦ ﳕﻂ‬
‫ﻭﺍﺣﺪ ﻟﻮﺍﺣﺪ‪.‬‬

‫وﺙﻴﻘﺔ اﻟﻤﺘﻄﻠﺒﺎت‬ ‫‪6-3‬‬

‫ﺗﺸﻜﻞ ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻟﻨﺎﺗﺞ ﺍﻟﻨﻬﺎﺋﻲ ﺍﳌﻠﻤﻮﺱ ﳌﺮﺣﻠﺔ ﲢﺪﻳﺪ ﺍﳌﺘﻄﻠﺒﺎﺕ‪ ،‬ﻭﺗﻜﺘﺐ ﻣﻌﻈﻢ‬
‫ﺍﳌﺆﺳﺴﺎﺕ ﻫﺬﻩ ﺍﻟﻮﺛﻴﻘﺔ ﺗﺒﻌﺎﹰ ﻟﻘﺎﻟﺐ ﳏﺪﺩ ﻣﺴﺒﻘﺎﹰ ﻳﻌﺮﻑ ﺑﻨﻴﺔ ﻫﺬﻩ ﺍﻟﻮﺛﻴﻘﺔ )ﺃﻱ ﺟﺪﻭﻝ‬
‫ﺍﶈﺘﻮﻳﺎﺕ( ﻭﳕﻄﻬﺎ‪.‬‬
‫ﻳﺘﺄﻟﻒ ﺍﳌﱳ ﺍﻟﺮﺋﻴﺴﻲ ﻟﻮﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻣﻦ ﺑﻴﺎﻧﺎﺕ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻟﱵ ﳝﻜﻦ ﺗﺼﻨﻴﻔﻬﺎ‪ ،‬ﻛﻤﺎ ﺫﻛﺮﻧﺎ ﰲ‬
‫ﺍﻟﻔﻘﺮﺓ )‪ ،(1-3‬ﰲ ﺑﻴﺎﻧﺎﺕ ﺧﺪﻣﺔ )ﺗﺪﻋﻰ ﻏﺎﻟﺒﹰﺎ ﻣﺘﻄﻠﺒﺎﺕ ﻭﻇﻴﻔﻴﺔ( ﻭﰲ ﺑﻴﺎﻧﺎﺕ ﻗﻴﻮﺩ‪ .‬ﻭﳝﻜﻦ ﻻﺣﻘﹰﺎ‬
‫ﺗﺼﻨﻴﻒ ﺑﻴﺎﻧﺎﺕ ﺍﳋﺪﻣﺔ ﺗﺼﻨﻴﻔﹰﺎ ﺃﻛﺜﺮ ﺩﻗﺔ ﺑﻘﺴﻤﺘﻬﺎ ﺇﱃ ﻣﺘﻄﻠﺒﺎﺕ ﺍﻟﻮﻇﺎﺋﻒ ﻭﻣﺘﻄﻠﺒﺎﺕ ﺍﳌﻌﻄﻴﺎﺕ‬
‫)ﳝﻜﻦ ﺃﻥ ﺗﺴﺘﺨﺪﻡ ﻋﺒﺎﺭﺓ "ﻣﺘﻄﻠﺒﺎﺕ ﻭﻇﻴﻔﻴﺔ" ﲟﻌﲎ ﻭﺍﺳﻊ ﺃﻭ ﲟﻌﲎ ﳏﺪﻭﺩ ﻭﻋﻨﺪ ﺍﳊﺪﻳﺚ ﻋﻦ ﻣﻌﲎ‬
‫ﳏﺪﺩ ﻓﻬﻲ ﺗﺸﲑ ﺇﱃ ﻣﺎ ﻧﺪﻋﻮﻩ ﻣﺘﻄﻠﺒﺎﺕ ﺍﻟﻮﻇﺎﺋﻒ(‪.‬‬
‫ﻭﺑﻌﻴﺪﹰﺍ ﻋﻦ ﺍﳌﺘﻄﻠﺒﺎﺕ ﲝﺪ ﺫﺍﻬﺗﺎ ﳚﺐ ﺃﻥ ﺗﺸﲑ ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺇﱃ ﻣﻔﺎﺗﻴﺢ ﺍﳌﺸﺮﻭﻉ ﺍﻷﺳﺎﺳﻴﺔ‪ ،‬ﻭﺗﺬﻛﺮ‬
‫ﻋﺎﺩﺓ ﰲ ﺑﺪﺍﻳﺔ ﺍﻟﻮﺛﻴﻘﺔ ﻭﻳﻌﺎﺩ ﺫﻛﺮﻫﺎ ﰲ ﻬﻧﺎﻳﺘﻬﺎ‪ .‬ﻳﻨﺎﻗﺶ ﺳﻴﺎﻕ ﻋﻤﻞ ﺍﳌﺸﺮﻭﻉ ﰲ ﺍﳉﺰﺀ ﺍﻟﺘﻘﺪﳝﻲ ﻟﻠﻮﺛﻴﻖ ﲟﺎ‬
‫ﻓﻴﻪ ﻫﺪﻑ ﺍﳌﺸﺮﻭﻉ ﻭﺍﻷﺷﺨﺎﺹ ﺫﻭﻱ ﺍﻟﺼﻠﺔ ﺑﻪ ﻭﺍﻟﻘﻴﻮﺩ ﺍﻟﺮﺋﻴﺴﻴﺔ‪ ،‬ﻭﰲ ﻬﻧﺎﻳﺔ ﺍﻟﻮﺛﻴﻘﺔ ﺗﻨﺎﻗﺶ ﺍﳌﻮﺍﺿﻴﻊ‬
‫ﺍﻷﺧﺮﻯ ﲟﺎ ﻓﻴﻬﺎ ﺟﺪﻭﻟﺔ ﺍﳌﺸﺮﻭﻉ ﺍﻟﺰﻣﻨﻴﺔ‪ ،‬ﻣﻮﺍﺯﻧﺘﻪ‪ ،‬ﺍﻷﺧﻄﺎﺭ‪ ،‬ﺍﻟﺘﻮﺛﻴﻖ ﻭﻏﲑﻫﺎ‪.‬‬
‫‪ 1-6-3‬ﻗﻮاﻟﺐ اﻟﻮﺙﻴﻘﺔ‬
‫‪129‬‬ ‫‪ : 3‬ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت‬

‫ﺗﺘﻮﺍﻓﺮ ﻗﻮﺍﻟﺐ ﻭﺛﺎﺋﻖ ﺍﳌﺘﻄﻠﺒﺎﺕ ﰲ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺍﻟﻜﺘﺐ‪ ،‬ﻭﻟﺪﻯ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺍﳌﺆﺳﺴﺎﺕ ﺍﻟﱵ ﺗﻌﲎ‬
‫ﺑﻮﺿﻊ ﺍﳌﻌﺎﻳﲑ )ﻣﺜﻞ ‪ IEEE‬ﻭ ‪ ANSI‬ﻭﻏﲑﻫﺎ( ﻭﻋﻠﻰ ﻣﻮﺍﻗﻊ ﺍﻟﺸﺮﻛﺎﺕ ﺍﻻﺳﺘﺸﺎﺭﻳﺔ ﻋﻠﻰ ﺷﺒﻜﺔ ﺍﻟﻮِﺏ‬
‫ﻭﻟﺪﻯ ﺑﺎﺋﻌﻲ ﺃﺩﻭﺍﺕ ﻫﻨﺪﺳﺔ ﺍﻟﱪﳎﻴﺎﺕ‪ .‬ﻭﻭﻓﻘﹰﺎ ﳌﺎ ﻫﻮ ﻣﺘﻌﺎﺭﻑ ﻋﻠﻴﻪ ﳚﺐ ﺃﻥ ﺗﻄﻮﺭ ﻛﻞ ﻣﺆﺳﺴﺔ‬
‫ﻣﻌﺎﻳﲑﻫﺎ ﺍﳋﺎﺻﺔ ﺍﻟﱵ ﺗﻼﺋﻢ ﺧﱪﺍﻬﺗﺎ ﻭﺛﻘﺎﻓﺘﻬﺎ ﻭﺃﳕﺎﻁ ﺍﻷﻧﻈﻤﺔ ﺍﻟﱵ ﺗﻌﻤﻞ ﻋﻠﻰ ﺗﻄﻮﻳﺮﻫﺎ‪.‬‬
‫ﻳﻌﺮﻑ ﻗﺎﻟﺐ ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺑﻨﻴﺔ ﻫﺬﻩ ﺍﻟﻮﺛﻴﻘﺔ ﻭﻳﻌﻄﻲ ﺍﻟﻌﻨﺎﻭﻳﻦ ﺍﻷﺳﺎﺳﻴﺔ ﺍﻟﺘﻔﺼﻴﻠﻴﺔ ﳌﺎ ﳚﺐ ﺃﻥ‬
‫ﻳﻜﺘﺐ ﰲ ﻛﻞ ﻣﻘﻄﻊ ﻣﻨﻬﺎ‪ ،‬ﻭﻗﺪ ﺗﺘﻀﻤﻦ ﻫﺬﻩ ﺍﻟﻌﻨﺎﻭﻳﻦ ﺍﳌﺴﺎﺋﻞ ﺍﶈﺘﻮﺍﺓ ﻭﺍﳊﻮﺍﻓﺰ ﻭﺍﻷﻣﺜﻠﺔ ﻭﺍﻋﺘﺒﺎﺭﺍﺕ‬
‫ﺃﺧﺮﻯ ﺇﺿﺎﻓﻴﺔ )‪ .(Robertson and Robertson, 2000‬ﻳﺒﲔ ﺍﻟﺸﻜﻞ )‪ (7-3‬ﺟﺪﻭﻝ ﳏﺘﻮﻳﺎﺕ ﳕﻄﻲ‬
‫ﻟﻮﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ‪ ،‬ﻭﺳﻨﺸﺮﺡ ﻫﺬﻩ ﺍﶈﺘﻮﻳﺎﺕ ﰲ ﺍﻟﻔﻘﺮﺍﺕ ﺍﻟﺘﺎﻟﻴﺔ‪.‬‬

‫‪ 2-6-3‬اﻟﺘﻤﻬﻴﺪ ﻟﻠﻤﺸﺮوع‬
‫ﻳﺘﻮﺟﻪ ﺍﳉﺰﺀ ﺍﻟﺘﻤﻬﻴﺪﻱ ﻣﻦ ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺑﺸﻜﻞ ﺭﺋﻴﺴﻲ ﺇﱃ ﺍﳌﺪﺭﺍﺀ ﻭﺻﺎﻧﻌﻲ ﺍﻟﻘﺮﺍﺭ ﺍﻟﺬﻳﻦ ﻧﺎﺩﺭﹰﺍ‬
‫ﻣﺎ ﻳﺮﻏﺒﻮﻥ ﺑﺪﺭﺍﺳﺔ ﺍﻟﻮﺛﻴﻘﺔ ﻛﻠﻬﺎ ﺑﺎﻟﺘﻔﺼﻴﻞ‪ ،‬ﻭﻣﻦ ﺍﻟﻀﺮﻭﺭﻱ ﺷﺮﺡ ﻫﺪﻑ ﺍﳌﺸﺮﻭﻉ ﻭﻧﻄﺎﻗﻪ‬
‫ﺑﻮﺿﻮﺡ ﰲ ﺑﺪﺍﻳﺔ ﺍﻟﻮﺛﻴﻘﺔ ﰒ ﺷﺮﺡ ﻭﺗﻮﺿﻴﺢ ﺳﻴﺎﻕ ﺍﻟﻌﻤﻞ‪.‬‬
‫ﳚﺐ ﺃﻥ ﺗﻀﻊ ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺣﺎﻟﺔ ﻋﻤﻞ ﻟﻠﻨﻈﺎﻡ ﻭﲡﺐ ﺍﻹﺷﺎﺭﺓ ﻋﻠﻰ ﻭﺟﻪ ﺍﳋﺼﻮﺹ ﺇﱃ ﺟﻬﻮﺩ‬
‫ﲣﻄﻴﻂ ﺍﻟﻨﻈﺎﻡ )ﺍﻟﻔﻘﺮﺓ ‪ (2-1‬ﺍﻟﱵ ﲢﺪﺩ ﺍﳊﺎﺟﺔ ﻟﻠﻨﻈﺎﻡ‪ .‬ﻛﻤﺎ ﳚﺐ ﺃﻥ ﺗﻘﺪﻡ ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺷﺮﺣﹰﺎ‬
‫ﻳﺒﲔ ﻛﻴﻒ ﺳﻴﺴﺎﻫﻢ ﺍﻟﻨﻈﺎﻡ ﺍﳌﻘﺘﺮﺡ ﰲ ﲢﻘﻴﻖ ﺃﻫﺪﺍﻑ ﻭﻏﺎﻳﺎﺕ ﻋﻤﻞ ﺍﳌﺆﺳﺴﺔ‪.‬‬
‫ﳚﺐ ﺃﻥ ﺗﻌﺮﻑ ﻫﺬﻩ ﺍﻟﻔﻘﺮﺓ ﺍﻷﺷﺨﺎﺹ ﺫﻭﻱ ﺍﻟﺼﻠﺔ ﺑﺎﳌﺸﺮﻭﻉ )ﺍﻟﻔﻘﺮﺓ ‪ ،(2-1-1‬ﻭﻣﻦ ﺍﳍﺎﻡ ﻫﻨﺎ ﺃﻻ‬
‫ﺗﺘﻢ ﺍﻹﺷﺎﺭﺓ ﺇﱃ ﺍﻟﺰﺑﻮﻥ ﻛﻤﻜﺘﺐ ﺃﻭ ﻗﺴﻢ ﺑﻞ ﳚﺐ ﺫﻛﺮ ﺃﲰﺎﺀ ﺍﻷﺷﺨﺎﺹ‪ ،‬ﻓﻔﻲ ﻬﻧﺎﻳﺔ ﺍﻟﻴﻮﻡ ﺳﻴﻘﺮﺭ‬
‫ﺷﺨﺺ ﻣﺎ ﺇﺫﺍ ﻛﺎﻥ ﺍﳌﻨﺘﺞ ﺍﻟﱪﳎﻲ ﺍﳌﺴﻠﻢ ﻣﻘﺒﻮ ﹰﻻ ﺃﻡ ﻻ‪.‬‬
‫ﻭﻣﻊ ﺃﻥ ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﳚﺐ ﺃﻥ ﺗﺒﻘﻰ ﺑﻌﻴﺪﺓ ﻗﺪﺭ ﺍﻹﻣﻜﺎﻥ ﻋﻦ ﺍﳊﻠﻮﻝ ﺍﻟﺘﻘﻨﻴﺔ ﻳﺒﻘﻰ ﻣﻦ ﺍﳍﺎﻡ ﺟﺪﹰﺍ‬
‫ﺃﻥ ﺗﺴﺘﺪﺭﺝ ﺃﻓﻜﺎﺭ ﻟﻠﺤﻞ ﻣﻨﺬ ﺍﳌﺮﺍﺣﻞ ﺍﻷﻭﱃ ﻟﺪﻭﺭﺓ ﺣﻴﺎﺓ ﺍﻟﺘﻄﻮﻳﺮ‪ ،‬ﻭﳚﺐ ﺍﻻﻫﺘﻤﺎﻡ ﻫﻨﺎ ﺑﺎﳊﻠﻮﻝ‬
‫ﺍﻟﱪﳎﻴﺔ ﺍﳉﺎﻫﺰﺓ ﻓﺸﺮﺍﺀ ﻣﻨﺘﺞ ﺟﺎﻫﺰ ﻳﺒﻘﻰ ﺃﻓﻀﻞ ﻣﻦ ﺗﻄﻮﻳﺮ ﻣﻨﺘﺞ ﺟﺪﻳﺪ ﻛﻠﻴﹰﺎ‪.‬‬
‫ﳚﺐ ﺃﻥ ﺗﻌﺮﺽ ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻗﺎﺋﻤﺔ ﺑﺎﳊﺰﻡ ﻭﺍﳌﻜﻮﻧﺎﺕ ﺍﻟﱪﳎﻴﺔ ﺍﳌﻮﺟﻮﺩﺓ ﺍﻟﱵ ﳚﺐ ﺍﻟﺘﺤﺮﻱ ﻋﻦ‬
‫ﻣﺪﻯ ﺻﻼﺣﻴﺔ ﺍﺳﺘﺨﺪﺍﻣﻬﺎ ﻛﺤﻠﻮﻝ ﺟﺎﻫﺰﺓ‪ ،‬ﻭﻧﺬﻛﺮ ﻫﻨﺎ ﺃﻥ ﺃﺧﺬ ﺃﺣﺪ ﺍﳊﻠﻮﻝ ﺍﳉﺎﻫﺰﺓ ﻳﺆﺛﺮ‬
‫ﺑﻮﺿﻮﺡ ﻋﻠﻰ ﺇﺟﺮﺍﺋﻴﺔ ﺍﻟﺘﻄﻮﻳﺮ ﻟﻜﻨﻪ ﻻ ﻳﻐﲏ ﻋﻦ ﲢﻠﻴﻞ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﺗﺼﻤﻴﻢ ﺍﻟﻨﻈﺎﻡ‪.‬‬

‫وﺛﻴﻘﺔ اﻟﻤﺘﻄﻠﺒﺎت‬
‫اﻟﻔﺼﻞ اﻟﺜﺎﻟﺚ‬ ‫‪130‬‬

‫ﺟﺪول اﻟﻤﺤﺘﻮﻳﺎت‬

‫‪ -1‬اﻟﺘﻤﻬﻴﺪ ﻟﻠﻤﺸﺮوع‪:‬‬
‫‪ 1-1‬هﺪف اﻟﻤﻨﺘﺞ وﻧﻄﺎﻗﻪ‪.‬‬
‫‪ 2-1‬ﺳﻴﺎق اﻟﻌﻤﻞ‪.‬‬
‫‪ 3-1‬اﻷﺷﺨﺎص اﻟﻤﻌﻨﻴﻮن‪.‬‬
‫‪ 4-1‬أﻓﻜﺎر اﻟﻌﻤﻞ‪.‬‬
‫‪ 5-1‬ﻧﻈﺮة ﻋﺎﻣﺔ ﻋﻠﻰ اﻟﻮﺛﻴﻘﺔ‪.‬‬
‫‪ -2‬ﺧﺪﻣﺎت اﻟﻨﻈﺎم‪:‬‬
‫ﻧﻄﺎق اﻟﻨﻈﺎم‪.‬‬ ‫‪1-2‬‬
‫‪ 2-2‬ﻣﺘﻄﻠﺒﺎت اﻟﻨﻈﺎم‪.‬‬
‫‪ 3-2‬ﻣﺘﻄﻠﺒﺎت اﻟﻤﻌﻄﻴﺎت‪.‬‬
‫‪ -3‬ﻗﻴﻮد اﻟﻨﻈﺎم‪:‬‬
‫‪ 1-3‬ﻣﺘﻄﻠﺒﺎت اﻟﻮاﺟﻬﺔ‪.‬‬
‫‪ 2-3‬ﻣﺘﻄﻠﺒﺎت اﻷداء‪.‬‬
‫‪ 3-3‬ﻣﺘﻄﻠﺒﺎت اﻷﻣﻦ‪.‬‬
‫‪ 4-3‬ﻣﺘﻄﻠﺒﺎت اﻟﺘﺸﻐﻴﻞ‪.‬‬
‫‪ 5-3‬ﻣﺘﻄﻠﺒﺎت ﺳﻴﺎﺳﻴﺔ وﻗﺎﻧﻮﻧﻴﺔ‪.‬‬
‫‪ 6-3‬ﻗﻴﻮد أﺧﺮى‪.‬‬
‫‪ -4‬ﻣﻮاد اﻟﻤﺸﺮوع‪:‬‬
‫‪ 1-4‬ﻣﻮاﺿﻴﻊ ﻣﻔﺘﻮﺣﺔ‪.‬‬
‫‪ 2-4‬اﻟﺠﺪول اﻟﺰﻣﻨﻲ اﻷوﻟﻲ‪.‬‬
‫‪ 3-4‬اﻟﻤﻮازﻧﺔ اﻷوﻟﻴﺔ‪.‬‬
‫اﻟﻤﻼﺣﻖ‪:‬‬
‫ﺳﺮد اﻟﻤﺼﻄﻠﺤﺎت‪.‬‬
‫اﺳﺘﻤﺎرات ووﺛﺎﺋﻖ اﻟﻌﻤﻞ‪.‬‬
‫اﻟﻤﺮاﺟﻊ‪.‬‬

‫وﺛﻴﻘﺔ اﻟﻤﺘﻄﻠﺒﺎت‪-‬ﺟﺪول اﻟﻤﺤﺘﻮﻳﺎت‬ ‫اﻟﺸﻜﻞ )‪(7-3‬‬

‫ﻧﺸﲑ ﺃﺧﲑﹰﺍ ﺇﱃ ﺃﻧﻪ ﻣﻦ ﺍﳉﻴﺪ ﺃﻥ ﺗﺘﻀﻤﻦ ﺍﻟﻔﻘﺮﺓ ﺍﻟﺘﻤﻬﻴﺪﻳﺔ ﻧﻈﺮﺓ ﻋﺎﻣﺔ ﻋﻠﻰ ﺑﺎﻗﻲ ﳏﺘﻮﻳﺎﺕ ﺍﻟﻮﺛﻴﻘﺔ‪،‬‬
‫ﻓﻘﺪ ﳚﺬﺏ ﻫﺬﺍ ﺍﻷﻣﺮ ﺍﻫﺘﻤﺎﻡ ﺍﻟﻘﺎﺭﺉ ﻭﳛﺜﻪ ﻋﻠﻰ ﺩﺭﺍﺳﺔ ﺃﺟﺰﺍﺀ ﺃﺧﺮﻯ ﻣﻦ ﺍﻟﻮﺛﻴﻘﺔ ﻛﻤﺎ ﻳﺴﻬﻞ ﻓﻬﻢ‬
‫ﳏﺘﻮﻳﺎﻬﺗﺎ‪ ،‬ﻛﻤﺎ ﻳﻔﻀﻞ ﺃﻥ ﺗﻮﺿﺢ ﻫﺬﻩ ﺍﻟﻨﻈﺮﺓ ﺍﻟﻌﺎﻣﺔ ﻣﻨﻬﺠﻴﺔ ﺍﻟﺘﺤﻠﻴﻞ ﻭﺍﻟﺘﺼﻤﻴﻢ ﺍﻟﱵ ﻳﺘﺒﻌﻬﺎ‬
‫ﺍﳌﻄﻮﺭﻭﻥ‪.‬‬

‫‪ 3-6-3‬ﺥﺪﻡﺎت اﻟﻨﻈﺎم‬
‫ﻭ ‪،(1-3‬‬ ‫‪1-3-1‬‬ ‫ﳜﺼﺺ ﺍﳉﺰﺀ ﺍﻟﺮﺋﻴﺴﻲ ﻣﻦ ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻟﺘﻌﺮﻳﻒ ﺧﺪﻣﺎﺕ ﺍﻟﻨﻈﺎﻡ )ﺍﻟﻔﻘﺮﺗﺎﻥ‬
‫‪131‬‬ ‫‪ : 3‬ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت‬

‫ﻭﻣﻦ ﺍﶈﺘﻤﻞ ﺃﻥ ﻳﺸﻐﻞ ﻫﺬﺍ ﺍﳉﺰﺀ ﻧﺼﻒ ﺍﻟﻮﺛﻴﻘﺔ‪ ،‬ﻭﻫﻮ ﻋﻤﻠﻴﹰﺎ ﺍﳉﺰﺀ ﺍﻟﻮﺣﻴﺪ ﻣﻦ ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ‬
‫ﺍﻟﺬﻱ ﻗﺪ ﳛﻮﻱ ﳕﺎﺫﺝ ﻟﻠﺤﻞ ﻋﻠﻰ ﻣﺴﺘﻮﻯ ﲡﺮﻳﺪ ﻋﺎﻝ‪-‬ﳕﺎﺫﺝ ﻣﺘﻄﻠﺒﺎﺕ ﺍﻷﻋﻤﺎﻝ )ﺍﻟﻔﻘﺮﺓ ‪.(5-3‬‬
‫ﳝﻜﻦ ﳕﺬﺟﺔ ﻧﻄﺎﻕ ﺍﻟﻨﻈﺎﻡ ﺑﺮﺳﻢ ﳐﻄﻂ ﺍﻟﺴﻴﺎﻕ )ﺍﻟﻔﻘﺮﺓ ‪ ،(1-5-3‬ﺇﺫ ﳚﺐ ﺃﻥ ﺗﺘﻀﺢ ﺣﺪﻭﺩ ﺍﳌﺸﺮﻭﻉ‬
‫ﺍﳌﻘﺘﺮﺡ ﻣﻦ ﺧﻼﻝ ﺷﺮﺡ ﻫﺬﺍ ﺍﳌﺨﻄﻂ‪ ،‬ﻭﻣﻦ ﺩﻭﻥ ﺗﻌﺮﻳﻒ ﻫﺬﻩ ﺍﳊﺪﻭﺩ ﻟﻦ ﻳﺴﺘﻄﻴﻊ ﺍﳌﺸﺮﻭﻉ ﺃﻥ‬
‫ﻳﺼﻤﺪ ﰲ ﻣﻮﺍﺟﻬﺔ ﻣﺸﻜﻼﺕ ﺍﺗﺴﺎﻉ ﺍﻟﻨﻄﺎﻕ‪ ،‬ﻭﳝﻜﻦ ﳕﺬﺟﺔ ﻣﺘﻄﻠﺒﺎﺕ ﺍﻟﻮﻇﺎﺋﻒ ﲟﺨﻄﻂ ﺣﺎﻻﺕ‬
‫ﻼ ﻋﺎﱄ ﺍﳌﺴﺘﻮﻯ ﻟﻘﺎﺋﻤﺔ‬
‫ﺍﺳﺘﺨﺪﺍﻡ ﺍﻷﻋﻤﺎﻝ )ﺍﻟﻔﻘﺮﺓ ‪ ،(2-5-3‬ﻟﻜﻦ ﻟﻦ ﻳﻌﻄﻴﻨﺎ ﻫﺬﺍ ﺍﳌﺨﻄﻂ ﺇﻻ ﲤﺜﻴ ﹰ‬
‫ﻣﺘﻄﻠﺒﺎﺕ ﺍﻟﻮﻇﺎﺋﻒ ﺍﻟﺘﻔﺼﻴﻠﻴﺔ‪ ،‬ﻭﻛﻤﺎ ﺫﻛﺮﻧﺎ ﰲ ﺍﻟﻔﻘﺮﺓ ‪ 4-3‬ﳚﺐ ﲢﺪﻳﺪ ﻛﻞ ﻣﺘﻄﻠﺐ ﻭﺗﺼﻨﻴﻔﻪ‬
‫ﻭﺗﻌﺮﻳﻔﻪ‪.‬‬
‫ﺃﻣﺎ ﻣﺘﻄﻠﺒﺎﺕ ﺍﳌﻌﻄﻴﺎﺕ ﻓﺘﻤﻜﻦ ﳕﺬﺟﺘﻬﺎ ﲟﺨﻄﻂ ﺻﻔﻮﻑ ﺍﻷﻋﻤﺎﻝ )ﺍﻟﻔﻘﺮﺓ ‪ ،(3-5-3‬ﻭﻛﻤﺎ ﻫﻮ‬
‫ﻼ ﻟﺒﲎ ﻣﻌﻄﻴﺎﺕ‬
‫ﺍﳊﺎﻝ ﺑﺎﻟﻨﺴﺒﺔ ﳌﺘﻄﻠﺒﺎﺕ ﺍﻟﻮﻇﺎﺋﻒ ﻓﺈﻥ ﳐﻄﻂ ﺻﻔﻮﻑ ﺍﻷﻋﻤﺎﻝ ﻟﻴﺲ ﺗﻌﺮﻳﻔﹰﺎ ﻛﺎﻣ ﹰ‬
‫ﺍﻟﻌﻤﻞ‪ ،‬ﺇﺫ ﳚﺐ ﺷﺮﺡ ﻛﻞ ﺻﻒ ﻣﻦ ﺻﻔﻮﻑ ﺍﻷﻋﻤﺎﻝ ﺑﺸﻜﻞ ﺃﻭﺳﻊ ﻻﺣﻘﹰﺎ ﻛﻤﺎ ﳚﺐ ﺗﻮﺻﻴﻒ‬
‫ﺻﻔﺎﺕ ﺍﻟﺼﻔﻮﻑ ﻭﳏﺘﻮﻳﺎﻬﺗﺎ ﻓﻤﻦ ﺩﻭﻬﻧﺎ ﻟﻦ ﻳﻜﻮﻥ ﺑﺎﻹﻣﻜﺎﻥ ﺷﺮﺡ ﻋﻼﻗﺎﺕ ﺍﻻﻗﺘﺮﺍﻥ ﺑﻮﺿﻮﺡ‪.‬‬

‫‪ 4-6-3‬ﻗﻴﻮد اﻟﻨﻈﺎم‬
‫ﺗُﻌﺮﱢﻑ ﺧﺪﻣﺎﺕ ﺍﻟﻨﻈﺎﻡ ﻣﺎ ﳚﺐ ﺃﻥ ﻳﻨﺠﺰﻩ ﺍﻟﻨﻈﺎﻡ ﺑﻴﻨﻤﺎ ﺗﺼﻒ ﻗﻴﻮﺩ ﺍﻟﻨﻈﺎﻡ )ﺍﻟﻔﻘﺮﺗﺎﻥ ‪ 1-3-1‬ﻭ ‪(1-3‬‬
‫ﻛﻴﻒ ﻳُﻘﻴﱠﺪ ﻋﻤﻞ ﺍﻟﻨﻈﺎﻡ ﺃﺛﻨﺎﺀ ﺃﺩﺍﺋﻪ ﳋﺪﻣﺎﺗﻪ‪ ،‬ﻭﲢﺪﺩ ﻗﻴﻮﺩ ﺍﻟﻨﻈﺎﻡ ﻭﻓﻘﹰﺎ ﳌﺎﻳﻠﻲ‪:‬‬
‫ﻣﺘﻄﻠﺒﺎﺕ ﺍﻟﻮﺍﺟﻬﺔ‪.‬‬ ‫™‬

‫ﻣﺘﻄﻠﺒﺎﺕ ﺍﻷﺩﺍﺀ‪.‬‬ ‫™‬

‫ﻣﺘﻄﻠﺒﺎﺕ ﺍﻷﻣﻦ‪.‬‬ ‫™‬

‫ﻣﺘﻄﻠﺒﺎﺕ ﺍﻟﺘﺸﻐﻴﻞ‪.‬‬ ‫™‬

‫ﻣﺘﻄﻠﺒﺎﺕ ﺳﻴﺎﺳﻴﺔ ﻭﻗﺎﻧﻮﻧﻴﺔ‪.‬‬ ‫™‬

‫ﺗﻌﺮﻑ ﻣﺘﻄﻠﺒﺎﺕ ﺍﻟﻮﺍﺟﻬﺔ ﻛﻴﻒ ﻳﺘﺨﺎﻃﺐ ﺍﳌﻨﺘﺞ ﻣﻊ ﺍﳌﺴﺘﺨﺪﻣﲔ‪ ،‬ﻓﻨﻌﺮﻑ ﰲ ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ‬
‫ﺍﳌﻈﻬﺮ ﺍﻟﻌﺎﻡ ﻟﻮﺍﺟﻬﺎﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ ﺍﻟﺒﻴﺎﻧﻴﺔ ﻓﻘﻂ‪ ،‬ﺃﻣﺎ ﺍﻟﺘﺼﻤﻴﻢ ﺍﻷﻭﱄ ﳍﺬﻩ ﺍﻟﻮﺍﺟﻬﺎﺕ ﻓﻴﺘﻢ ﺧﻼﻝ‬
‫ﻣﺮﺣﻠﺔ ﺗﻮﺻﻴﻒ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﻻﺣﻘﹰﺎ ﺃﺛﻨﺎﺀ ﺗﺼﻤﻴﻢ ﺍﻟﻨﻈﺎﻡ‪.‬‬
‫ﻭﳝﻜﻦ ﺃﻥ ﺗﺘﺤﻮﻝ ﻣﺘﻄﻠﺒﺎﺕ ﺍﻷﺩﺍﺀ ﺇﱃ ﻣﻔﺎﺗﻴﺢ ﺃﺳﺎﺳﻴﺔ ﻟﻨﺠﺎﺡ ﺍﳌﺸﺮﻭﻉ ﺗﺒﻌﹰﺎ ﳊﻘﻞ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﻓﻔﻲ‬
‫ﺃﺿﻴﻖ ﺍﳌﻌﺎﱐ ﲢﺪﺩ ﻫﺬﻩ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻟﺴﺮﻋﺔ ﺍﻟﱵ ﳚﺐ ﺃﻥ ﻳﻨﺠﺰ ﻓﻴﻬﺎ ﺍﻟﻨﻈﺎﻡ ﻣﻬﺎﻣﻪ ﺍﳌﺨﺘﻠﻔﺔ )ﺃﺯﻣﻨﺔ‬
‫ﻼ ﺑﻮﺛﻮﻗﻴﺔ‬
‫ﺍﺳﺘﺠﺎﺑﺔ ﺍﻟﻨﻈﺎﻡ(‪ ،‬ﻭﰲ ﻣﻌﲎ ﺃﻭﺳﻊ ﻗﺪ ﺗﺸﻤﻞ ﻣﺘﻄﻠﺒﺎﺕ ﺍﻷﺩﺍﺀ ﻗﻴﻮﺩ ﺃﺧﺮﻯ ﺗﺘﻌﻠﻖ ﻣﺜ ﹰ‬
‫اﻟﻔﺼﻞ اﻟﺜﺎﻟﺚ‬ ‫‪132‬‬

‫ﺍﻟﻨﻈﺎﻡ ﻭﺟﺎﻫﺰﻳﺘﻪ ﻟﻠﻌﻤﻞ ﺍﻟﺪﺍﺋﻢ ﻭﻏﲑﻫﺎ‪.‬‬

‫ﻭﺗﺼﻒ ﻣﺘﻄﻠﺒﺎﺕ ﺍﻷﻣﻦ ﺍﳊﻘﻮﻕ ﺍﳌﻤﻨﻮﺣﺔ ﻟﻠﻤﺴﺘﺨﺪﻣﲔ ﻟﻠﻮﺻﻮﻝ ﺇﱃ ﺍﳌﻌﻠﻮﻣﺎﺕ ﲢﺖ ﺳﻴﻄﺮﺓ‬
‫ﺍﻟﻨﻈﺎﻡ‪ ،‬ﻓﻘﺪ ﻳُﻌﻄﻰ ﺍﳌﺴﺘﺨﺪﻣﻮﻥ ﺇﻣﻜﺎﻧﻴﺎﺕ ﻣﻘﻴﺪﺓ ﻟﻠﻮﺻﻮﻝ ﺇﱃ ﺍﳌﻌﻠﻮﻣﺎﺕ ﺃﻭ ﺣﻘﻮﻕ ﻣﻌﻴﻨﺔ ﻟﺘﻨﻔﻴﺬ‬
‫ﻋﻤﻠﻴﺎﺕ ﳏﺪﺩﺓ ﻋﻠﻰ ﺍﳌﻌﻄﻴﺎﺕ‪.‬‬
‫ﻭﲢﺪﺩ ﻣﺘﻄﻠﺒﺎﺕ ﺍﻟﺘﺸﻐﻴﻞ ﺍﻟﺒﻴﺌﺔ ﺍﻟﻌﺘﺎﺩﻳﺔ‪/‬ﺍﻟﱪﳎﻴﺔ ﺍﻟﱵ ﺳﻴﻌﻤﻞ ﺿﻤﻨﻬﺎ ﺍﻟﻨﻈﺎﻡ‪ ،‬ﻭﻗﺪ ﻳﻜﻮﻥ ﳍﺬﻩ‬
‫ﺍﳌﺘﻄﻠﺒﺎﺕ ﺃﺛﺮ ﻣﺒﺎﺷﺮ ﻋﻠﻰ ﻣﻮﺍﺿﻴﻊ ﺃﺧﺮﻯ ﺫﺍﺕ ﺻﻠﺔ ﺑﺎﳌﺸﺮﻭﻉ ﻛﺘﺪﺭﻳﺐ ﺍﳌﺴﺘﺨﺪﻣﲔ ﻭﺻﻴﺎﻧﺔ‬
‫ﺍﻟﻨﻈﺎﻡ‪.‬‬
‫ﺃﻣﺎ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻟﺴﻴﺎﺳﻴﺔ ﻭﺍﻟﻘﺎﻧﻮﻧﻴﺔ ﻓﻨﺎﺩﺭﹰﺍ ﻣﺎ ﺗﺬﻛﺮ ﺻﺮﺍﺣﺔ ﰲ ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﺗﻌﺘﱪ ﻣﻌﺮﻭﻓﺔ‬
‫ﺿﻤﻨﺎﹰ‪ ،‬ﻟﻜﻦ ﻗﺪ ﻳﺘﺤﻮﻝ ﲡﺎﻫﻞ ﻫﺬﻩ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺇﱃ ﺧﻄﺄ ﻣﻜﻠﻒ ﺟﺪﹰﺍ ﻓﻤﻦ ﺩﻭﻥ ﺫﻛﺮ ﻫﺬﻩ‬
‫ﺍﳌﺘﻄﻠﺒﺎﺕ ﺻﺮﺍﺣﺔ ﻗﺪ ﻳﺴﺘﺤﻴﻞ ﺗﻮﺯﻳﻊ ﺍﳌﻨﺘﺞ ﻷﺳﺒﺎﺏ ﺳﻴﺎﺳﻴﺔ ﺃﻭ ﻗﺎﻧﻮﻧﻴﺔ‪.‬‬
‫ﻼ ﻣﺘﻄﻠﺒﺎﺕ ﺇﺿﺎﻓﻴﺔ ﻋﻠﻰ ﺳﻬﻮﻟﺔ‬‫ﻗﺪ ﳒﺪ ﺃﻳﻀﹰﺎ ﻓﺌﺎﺕ ﺃﺧﺮﻯ ﻣﻦ ﺍﻟﻘﻴﻮﺩ ﻓﻘﺪ ﺗﻀﻊ ﺑﻌﺾ ﺍﻷﻧﻈﻤﺔ ﻣﺜ ﹰ‬
‫ﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﻨﻈﺎﻡ )ﻣﺘﻄﻠﺒﺎﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ( ﺃﻭ ﻋﻠﻰ ﺳﻬﻮﻟﺔ ﺻﻴﺎﻧﺘﻪ )ﻣﺘﻄﻠﺒﺎﺕ ﺍﻟﺼﻴﺎﻧﺔ(‪.‬‬
‫ﺇﻥ ﻭﺿﻊ ﺗﻌﺎﺭﻳﻒ ﺩﻗﻴﻘﺔ ﻭﻭﺍﺿﺤﺔ ﻟﻘﻴﻮﺩ ﺍﻟﻨﻈﺎﻡ ﺃﻣﺮ ﺑﺎﻟﻎ ﺍﻷﳘﻴﺔ ﻓﻬﻨﺎﻙ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺍﻷﻣﺜﻠﺔ ﳌﺸﺎﺭﻳﻊ‬
‫ﻓﺸﻠﺖ ﺑﺴﺒﺐ ﲡﺎﻫﻞ ﺃﻭ ﺳﻮﺀ ﺗﻔﺴﲑ ﻗﻴﻮﺩ ﺍﻟﻨﻈﺎﻡ‪ ،‬ﻭﻳﻌﺘﱪ ﻫﺬﺍ ﺍﻷﻣﺮ ﻋﻠﻰ ﺩﺭﺟﺔ ﺍﻷﳘﻴﺔ ﻧﻔﺴﻬﺎ ﻟﻜﻞ‬
‫ﻣﻦ ﺍﻟﺰﺑﺎﺋﻦ ﻭﺍﳌﻄﻮﺭﻳﻦ‪ ،‬ﻓﻘﺪ ﻳﺴﺘﻐﻞ ﺍﳌﻄﻮﺭﻭﻥ ﺍﻟﻴﺎﺋﺴﻮﻥ ﺃﻭ ﻋﺪﳝﻮ ﺍﻟﻀﻤﲑ ﻋﺪﻡ ﻭﺿﻮﺡ ﻗﻴﻮﺩ ﺍﻟﻨﻈﺎﻡ‬
‫ﻟﻠﺘﻬﺮﺏ ﻣﻦ ﻣﺴﺆﻭﻟﻴﺎﻬﺗﻢ‪.‬‬

‫‪ 5-6-3‬ﻡﻮاد اﻟﻤﺸﺮوع‬
‫ﻳﺘﻨﺎﻭﻝ ﺍﳉﺰﺀ ﺍﻷﺧﲑ ﻣﻦ ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻣﻮﺍﺿﻴﻊ ﺃﺧﺮﻯ ﺫﺍﺕ ﺻﻠﺔ ﺑﺎﳌﺸﺮﻭﻉ‪ ،‬ﻭﻣﻦ ﺍﳌﻘﺎﻃﻊ ﺍﳍﺎﻣﺔ‬
‫ﰲ ﻫﺬﺍ ﺍﳉﺰﺀ ﺍﳌﻘﻄﻊ ﺍﻟﺬﻱ ﻧﺴﻤﻴﻪ ﻣﻮﺍﺿﻴﻊ ﻣﻔﺘﻮﺣﺔ‪ ،‬ﻓﻔﻲ ﻫﺬﺍ ﺍﳌﻘﻄﻊ ﳝﻜﻦ ﺃﻥ ﻧﺬﻛﺮ ﻛﻞ ﻣﺎ ﳝﻜﻦ‬
‫ﺃﻥ ﻳﺆﺛﺮ ﻋﻠﻰ ﳒﺎﺡ ﺍﳌﺸﺮﻭﻉ ﻭﱂ ﻧﺘﻄﺮﻕ ﻟﺬﻛﺮﻩ ﰲ ﻣﻮﺿﻊ ﺁﺧﺮ ﻣﻦ ﺍﻟﻮﺛﻴﻘﺔ‪ ،‬ﻭﻳﺘﻀﻤﻦ ﻫﺬﺍ ﺍﻟﻨﻤﻮ‬
‫ﺍﳌﺘﻮﻗﻊ ﻷﳘﻴﺔ ﺑﻌﺾ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻟﱵ ﺗﻘﻊ ﺣﺎﻟﻴﹰﺎ ﺧﺎﺭﺝ ﻧﻄﺎﻕ ﺍﳌﺸﺮﻭﻉ‪ ،‬ﻛﻤﺎ ﳝﻜﻦ ﺃﻥ ﻳﺘﻀﻤﻦ ﺃﻱ‬
‫ﻣﺸﻜﻼﺕ ﳏﺘﻤﻠﺔ ﻗﺪ ﺗﻈﻬﺮ ﻋﻨﺪ ﺗﻮﺯﻳﻊ ﺍﻟﻨﻈﺎﻡ‪.‬‬

‫ﻻ ﺑﺪ ﺃﻳﻀﹰﺎ ﻣﻦ ﻭﺿﻊ ﺟﺪﻭﻝ ﺯﻣﲏ ﺃﻭﱄ ﻟﻠﻤﻬﺎﻡ ﺍﻟﺮﺋﻴﺴﻴﺔ ﻟﻠﻤﺸﺮﻭﻉ )ﺍﻟﻔﻘﺮﺓ ‪ ،(8-3-1‬ﻭﻳُﻔﻀﱠﻞ ﺃﻥ‬
‫ﻳﺸﻤﻞ ﻫﺬﺍ ﲢﺪﻳﺪﹰﺍ ﺃﻭﻟﻴﹰﺎ ﻟﻠﻤﻮﺍﺭﺩ ﺍﻟﺒﺸﺮﻳﺔ ﺍﻟﻼﺯﻣﺔ ﻭﻟﻐﲑﻫﺎ ﻣﻦ ﺍﳌﻮﺍﺭﺩ‪ .‬ﻭﳝﻜﻦ ﺃﻥ ﻧﺴﺘﺨﺪﻡ ﻟﺬﻟﻚ‬
‫ﺇﺣﺪﻯ ﺃﺩﻭﺍﺕ ﺇﺩﺍﺭﺓ ﺍﳌﺸﺎﺭﻳﻊ ﻟﻮﺿﻊ ﳐﻄﻄﺎﺕ ﳋﻄﻂ ﻗﻴﺎﺳﻴﺔ ﻣﺜﻞ ﳐﻄﻄﺎﺕ ‪ PERT‬ﺃﻭ ﳐﻄﻄﺎﺕ‬
‫‪133‬‬ ‫‪ : 3‬ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت‬

‫‪.(Maciaszek,1990) Gantt‬‬
‫ﻭﻛﻨﺘﻴﺠﺔ ﻣﺒﺎﺷﺮﺓ ﻟﻠﺠﺪﻭﻝ ﺍﻟﺰﻣﲏ ﳝﻜﻦ ﺃﻥ ﻧﻀﻊ ﻣﻮﺍﺯﻧﺔ ﺃﻭﻟﻴﺔ‪ ،‬ﻭﳝﻜﻦ ﺍﻟﺘﻌﺒﲑ ﻋﻦ ﻛﻠﻔﺔ ﺍﳌﺸﺮﻭﻉ‬
‫ﻋﻠﻰ ﺷﻜﻞ ﳎﺎﻝ ﺑﺪ ﹰﻻ ﻣﻦ ﻗﻴﻤﺔ ﺗﻘﺮﻳﺒﻴﺔ ﳏﺪﺩﺓ‪ ،‬ﻭﺇﺫﺍ ﻛﺎﻧﺖ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻣﻮﺛﻘﺔ ﺟﻴﺪﹰﺍ ﳝﻜﻦ ﺍﺳﺘﺨﺪﺍﻡ‬
‫ﻼ‪ :‬ﲢﻠﻴﻞ ﺍﻟﻨﻘﺎﻁ ﺍﻟﻮﻇﻴﻔﻴﺔ(‪.‬‬
‫ﺇﺣﺪﻯ ﺍﻟﻄﺮﺍﺋﻖ ﺍﳌﻌﺮﻭﻓﺔ ﻟﺘﻘﺪﻳﺮ ﺍﻟﻜﻠﻔﺔ )ﻣﺜ ﹰ‬

‫‪ 6-6-3‬اﻟﻤﻼﺡﻖ‬
‫ﺗﺘﻀﻤﻦ ﺍﳌﻼﺣﻖ ﻣﻌﻠﻮﻣﺎﺕ ﺃﺧﺮﻯ ﻣﻔﻴﺪﺓ ﻟﻔﻬﻢ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﺃﳘﻬﺎ ﺳﺮﺩ ﺍﳌﺼﻄﻠﺤﺎﺕ ﺍﻟﺬﻱ ﻳﻌﺮﻑ‬
‫ﺍﳌﻔﺮﺩﺍﺕ ﻭﺍﻻﺧﺘﺼﺎﺭﺍﺕ ﺍﳌﺴﺘﺨﺪﻣﺔ ﰲ ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ‪ ،‬ﻭﳚﺐ ﻋﺪﻡ ﺍﻟﺘﻘﻠﻴﻞ ﻣﻦ ﺃﳘﻴﺔ ﻭﺟﻮﺩ‬
‫ﻗﺎﺋﻤﺔ ﻣﺼﻄﻠﺤﺎﺕ ﺟﻴﺪﺓ ﺇﺫ ﻗﺪ ﻳﺆﺩﻱ ﺳﻮﺀ ﺗﻔﺴﲑ ﺍﳌﻔﺮﺩﺍﺕ ﺇﱃ ﺃﺧﻄﺎﺀ ﻣﻜﻠﻔﺔ ﺟﺪﹰﺍ‪.‬‬
‫ﻭﻣﻦ ﺍﳌﻼﺣﻈﺎﺕ ﺍﳍﺎﻣﺔ ﺍﻟﱵ ﳚﺐ ﺃﺧﺬﻫﺎ ﺑﺎﳊﺴﺒﺎﻥ ﻋﻨﺪ ﻛﺘﺎﺑﺔ ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺃﻥ ﺇﺩﺭﺍﺝ ﻭﺛﺎﺋﻖ‬
‫ﻭﺍﺳﺘﻤﺎﺭﺍﺕ ﺍﻟﻌﻤﻞ ﳛﺴﻦ ﺑﻮﺿﻮﺡ ﺇﻣﻜﺎﻧﻴﺔ ﻓﻬﻢ ﳎﺎﻝ ﺍﻟﻌﻤﻞ ﺍﳋﺎﺹ ﺑﺎﳌﺸﺮﻭﻉ ‪ ،‬ﻭﻟﺬﻟﻚ ﳚﺐ‬
‫ﺇﺩﺭﺍﺝ ﺍﺳﺘﻤﺎﺭﺍﺕ ﺍﻟﻌﻤﻞ ﺑﻌﺪ ﻣﻠﺌﻬﺎ ﺑﺎﳌﻌﻠﻮﻣﺎﺕ ﻛﻠﻤﺎ ﻛﺎﻥ ﺫﻟﻚ ﳑﻜﻨﹰﺎ ﻭﻻ ﺗﻌﻄﻲ ﺍﻻﺳﺘﻤﺎﺭﺍﺕ‬
‫ﺍﻟﻔﺎﺭﻏﺔ ﺍﻟﻔﺎﺋﺪﺓ ﻧﻔﺴﻬﺎ‪.‬‬
‫ﻭﻳﺜﺒﺖ ﻣﻘﻄﻊ ﺍﳌﺮﺍﺟﻊ ﺍﻟﻮﺛﺎﺋﻖ ﺍﻟﱵ ﰎ ﺍﺳﺘﺨﺪﺍﻣﻬﺎ ﺃﻭ ﺍﻟﺮﺟﻮﻉ ﺇﻟﻴﻬﺎ ﻋﻨﺪ ﲢﻀﲑ ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ‪،‬‬
‫ﻭﻗﺪ ﺗﺘﻀﻤﻦ ﻫﺬﻩ ﺍﳌﺮﺍﺟﻊ ﻛﺘﺒﹰﺎ ﻭﻣﺼﺎﺩﺭ ﺃﺧﺮﻯ ﻟﻠﻤﻌﻠﻮﻣﺎﺕ‪ ،‬ﻟﻜﻦ ﻳﺒﻘﻰ ﺍﻷﻫﻢ ﺃﻥ ﻧﻀﻊ ﻓﻴﻬﺎ‬
‫ﺧﻼﺻﺎﺕ ﺍﻻﺟﺘﻤﺎﻋﺎﺕ ﻭﺍﳌﺬﻛﺮﺍﺕ ﻭﺍﻟﻮﺛﺎﺋﻖ ﺍﻟﺪﺍﺧﻠﻴﺔ‪.‬‬

‫اﻟﺨﻼﺹﺔ‬
‫ﺃﻟﻘﻴﻨﺎ ﺍﻟﻀﻮﺀ ﻣﻦ ﺧﻼﻝ ﻫﺬﺍ ﺍﻟﻔﺼﻞ ﻋﻠﻰ ﻣﺮﺣﻠﺔ ﲢﺪﻳﺪ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﻫﻲ ﺍﳌﺮﺣﻠﺔ ﺍﻟﱵ ﺗﺴﺒﻖ ﺗﻮﺻﻴﻒ‬
‫ﺍﳌﺘﻄﻠﺒﺎﺕ‪ ،‬ﺇﺫ ﻳﺘﻠﺨﺺ ﲢﺪﻳﺪ ﺍﳌﺘﻄﻠﺒﺎﺕ ﰲ ﺍﺳﺘﻜﺸﺎﻓﻬﺎ ﻭﺗﻮﺛﻴﻘﻬﺎ ﰲ ﻭﺛﻴﻘﺔ ﺳﺮﺩﻳﺔ ﻣﻮﺟﺰﺓ ﻧﺴﻤﻴﻬﺎ‬
‫ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ‪ ،‬ﺃﻣﺎ ﻣﺮﺣﻠﺔ ﺗﻮﺻﻴﻒ ﺍﳌﺘﻄﻠﺒﺎﺕ ‪ -‬ﺍﻟﱵ ﺳﻨﺪﺭﺳﻬﺎ ﰲ ﺍﻟﻔﺼﻞ ﺍﻟﻘﺎﺩﻡ ‪ -‬ﻓﺘﻮﻟﺪ ﳕﺎﺫﺝ‬
‫ﺃﻛﺜﺮ ﺻﻮﺭﻳﺔ ﻟﻠﻤﺘﻄﻠﺒﺎﺕ‪.‬‬
‫ﳚﺮﻱ ﺍﺳﺘﻨﺘﺎﺝ ﻭﺍﺳﺘﺨﻼﺹ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻋﱪ ﺳﻠﻮﻙ ﺧﻄﲔ ﻣﺘﻤﺎﻳﺰﻳﻦ ‪ :‬ﻣﻦ ﺍﳌﻌﺎﺭﻑ ﺍﳌﺘﻌﻠﻘﺔ ﲝﻘﻞ‬
‫ﺍﻟﺘﻄﺒﻴﻖ ﻭﻣﻦ ﺣﺎﻻﺕ ﺍﻻﺳﺘﺨﺪﺍﻡ‪ ،‬ﻓﻴﻜﻤﻞ ﻛﻞ ﺧﻂ ﻣﻨﻬﻤﺎ ﺍﳋﻂ ﺍﻵﺧﺮ ﻭﻳﺆﺩﻱ ﺫﻟﻚ ﺇﱃ ﲢﺪﻳﺪ‬
‫ﳕﻮﺫﺝ ﻋﻤﻞ ﺍﻟﻨﻈﺎﻡ ﺍﳌﻄﻠﻮﺏ ﺗﻄﻮﻳﺮﻩ‪.‬‬
‫ﳝﻜﻦ ﺍﺳﺘﻨﺘﺎﺝ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺑﻌﺪﺓ ﻃﺮﻕ‪ :‬ﺇﺟﺮﺍﺀ ﻣﻘﺎﺑﻼﺕ ﻣﻊ ﺍﻟﺰﺑﺎﺋﻦ ﻭﺧﱪﺍﺀ ﳎﺎﻝ ﺍﻷﻋﻤﺎﻝ‪ ،‬ﺗﻮﺯﻳﻊ‬
‫ﺍﻻﺳﺘﺒﺎﻧﺎﺕ‪ ،‬ﺍﳌﻼﺣﻈﺔ ﻭﺍﳌﺮﺍﻗﺒﺔ‪ ،‬ﺩﺭﺍﺳﺔ ﺍﻟﻮﺛﺎﺋﻖ ﻭﺍﻷﻧﻈﻤﺔ ﺍﻟﱪﳎﻴﺔ ﺍﳌﻮﺟﻮﺩﺓ‪ ،‬ﺍﻟﻨﻤﺬﺟﺔ ﺍﻷﻭﻟﻴﺔ‪،‬‬
‫ﺗﻄﻮﻳﺮ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﳌﺸﺘﺮﻙ‪ ،‬ﻭﺗﻄﻮﻳﺮ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻟﺴﺮﻳﻊ‪.‬‬
‫اﻟﻔﺼﻞ اﻟﺜﺎﻟﺚ‬ ‫‪134‬‬

‫ﻗﺪ ﺗﺘﻘﺎﻃﻊ ﺍﳌﺘﻄﻠﺒﺎﺕ ﺍﻟﱵ ﰎ ﺍﺳﺘﻨﺘﺎﺟﻬﺎ ﻣﻦ ﺍﻟﺰﺑﺎﺋﻦ ﻭﻗﺪ ﺗﺘﻌﺎﺭﺽ ﻓﻴﻤﺎ ﺑﻴﻨﻬﺎ‪ ،‬ﻭﻳﻘﻊ ﺣﻞ ﻫﺬﻩ‬
‫ﺍﳌﺸﻜﻠﺔ ﻋﻠﻰ ﻋﺎﺗﻖ ﳏﻠﻞ ﺍﻷﻋﻤﺎﻝ ﺍﻟﺬﻱ ﻋﻠﻴﻪ ﺃﻥ ﻳﺘﺤﻘﻖ ﻣﻦ ﺻﻼﺣﻴﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﺃﻥ ﻳﻔﺎﻭﺽ‬
‫ﺍﻟﺰﺑﺎﺋﻦ ﺑﺸﺄﻬﻧﺎ‪ ،‬ﻭﻟﻨﺠﺎﺡ ﻫﺬﻩ ﺍﳌﻬﻤﺔ ﳚﺐ ﺃﻥ ﻳﻌﺪ ﳏﻠﻞ ﺍﻷﻋﻤﺎﻝ ﻣﺼﻔﻮﻓﺔ ﺍﺭﺗﺒﺎﻁ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﺃﻥ‬
‫ﻳﺴﻨﺪ ﻟﻠﻤﺘﻄﻠﺒﺎﺕ ﺩﺭﺟﺎﺕ ﺍﻷﻭﻟﻮﻳﺔ ﻭﺩﺭﺟﺎﺕ ﺍﳋﻄﻮﺭﺓ ﺍﳌﻤﻴﺰﺓ ﳍﺎ‪.‬‬
‫ﳛﺘﺎﺝ ﺗﻨﻔﻴﺬ ﺍﳌﺸﺎﺭﻳﻊ ﺍﻟﻜﺒﲑﺓ ﻹﺩﺍﺭﺓ ﺃﻋﺪﺍﺩ ﺿﺨﻤﺔ ﻣﻦ ﺍﳌﺘﻄﻠﺒﺎﺕ‪ ،‬ﻭﻟﺬﻟﻚ ﻳﺼﺒﺢ ﻣﻦ ﺍﳍﺎﻡ ﰲ ﻫﺬﻩ‬
‫ﺍﳌﺸﺎﺭﻳﻊ ﺗﻌﺮﻳﻒ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻭﺗﺼﻨﻴﻔﻬﺎ ﻟﻴﻤﻜﻦ ﺑﻌﺪﺋ ٍﺬ ﺗﻌﺮﻳﻒ ﻫﺮﻣﻴﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ﳑﺎ ﻳﺴﻤﺢ ﻻﺣﻘﹰﺎ‬
‫ﺑﺘﺘﺒﻊ ﺍﳌﺘﻄﻠﺒﺎﺕ ﰲ ﻣﺮﺍﺣﻞ ﺗﻨﻔﻴﺬ ﺍﳌﺸﺮﻭﻉ ﺍﻟﻼﺣﻘﺔ ﺇﱃ ﺟﺎﻧﺐ ﺍﻟﺴﻴﻄﺮﺓ ﻋﻠﻰ ﺗﻐﲑ ﺍﳌﺘﻄﻠﺒﺎﺕ‪.‬‬
‫ﻭﻣﻊ ﺃﻥ ﲢﺪﻳﺪ ﺍﳌﺘﻄﻠﺒﺎﺕ ﻻ ﻳﺘﻀﻤﻦ ﳕﺬﺟﺔ ﺻﻮﺭﻳﺔ ﻟﻠﻨﻈﺎﻡ ﻟﻜﻦ ﻳﻔﻀﻞ ﺇﻧﺸﺎﺀ ﳕﻮﺫﺝ ﺃﺳﺎﺳﻲ‬
‫ﳌﺘﻄﻠﺒﺎﺕ ﺍﻟﻌﻤﻞ ﻣﻦ ﺧﻼﻝ ﺑﻨﺎﺀ ﺛﻼﺛﺔ ﳐﻄﻄﺎﺕ ﻋﺎﻣﺔ ﻫﻲ‪ :‬ﳐﻄﻂ ﺍﻟﺴﻴﺎﻕ‪ ،‬ﳐﻄﻂ ﺣﺎﻻﺕ ﺍﺳﺘﺨﺪﺍﻡ‬
‫ﺍﻷﻋﻤﺎﻝ‪ ،‬ﻭﳐﻄﻂ ﺻﻔﻮﻑ ﺍﻷﻋﻤﺎﻝ‪.‬‬
‫ﺗﺒﺪﺃ ﺍﻟﻮﺛﻴﻘﺔ ﺍﻟﻨﺎﲡﺔ ﻋﻦ ﻣﺮﺣﻠﺔ ﲢﺪﻳﺪ ﺍﳌﺘﻄﻠﺒﺎﺕ ‪ -‬ﺃﻱ ﻭﺛﻴﻘﺔ ﺍﳌﺘﻄﻠﺒﺎﺕ ‪ -‬ﺑﻮﺻﻒ ﻋﺎﱄ ﺍﳌﺴﺘﻮﻯ‬
‫ﳋﻄﻮﺍﺕ ﺍﳌﺸﺮﻭﻉ ﺍﻟﺘﻤﻬﻴﺪﻳﺔ )ﻣﻮﺟﻬﺔ ﺃﺳﺎﺳﹰﺎ ﻟﻠﻤﺪﺭﺍﺀ(‪ ،‬ﻭﺗﺼﻒ ﺍﻷﺟﺰﺍﺀ ﺍﻟﺮﺋﻴﺴﻴﺔ ﻣﻦ ﺍﻟﻮﺛﻴﻘﺔ‬
‫ﺧﺪﻣﺎﺕ ﺍﻟﻨﻈﺎﻡ ﻭﻗﻴﻮﺩﻩ‪ ،‬ﻭﻳﻌﲎ ﺍﳉﺰﺀ ﺍﻷﺧﲑ ﻣﻦ ﺍﻟﻮﺛﻴﻘﺔ ﲟﻮﺍﺿﻴﻊ ﺃﺧﺮﻯ ﺫﺍﺕ ﺻﻠﺔ ﺑﺎﳌﺸﺮﻭﻉ ﲟﺎ‬
‫ﻓﻴﻬﺎ ﺗﻔﺎﺻﻴﻞ ﺍﳉﺪﻭﻝ ﺍﻟﺰﻣﲏ ﻭﺍﳌﻮﺍﺯﻧﺔ‪.‬‬