بنام خدا

با سلام

در طراحي و پياده سازي هر سيستم نرم افزاري مي بايد با استفاده از روش مناسبي ، نسبت به استخراج و مستند سازي عمليات مختلف سيستم اقدام نمود با تجربياتي كه من در مدت كاري خود به آن رسيده ام نوشتن Use Case ها بصورت متني موجب فهم دقيق رويه ها توسط كليه افراد درگير در پروژه (تحليل گر ، برنامه نويس ، مديران پروژه ، كاربران نهايي ، مالك سيستم) مي گردد در اين سري مقالات چند Use Case پروژه سفارش غذاي رستوران آورده شده ، تا شما يك مثال از يك پروژه واقعي را ديده و موجب درك بهتر از Use Case ها گردد. لازم به ذكر است در مقالات ديگري مزايا ، الگوها و روش نوشتن Use Case هاي بهينه را به تفصيل توضيح خواهم داد ولي در حال حاضر به علت درخواست بعضي از دوستان در راستاي تكميل پروژه سيستم سفارش غذاي رستوران ، چند Use Case مهم آن را با هم مرور مي كنيم.

در ذيل لينك مقالات قبلي مرتبط با اين پروژه آورده شده است كه پيشنهاد مي شود ابتدا آنها را مطالعه نماييد.

 

مقالات مرتبط با مستند محدوده و چشم انداز سيستم (Scope and Vision Document) :

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت اول

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت دوم

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت سوم(آخر)

مقالات مرتبط بامستند مشخصات نيازمنديهاي نرم افزار(Software Requirement Specification) :

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت اول

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت دوم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت سوم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت چهارم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت پنجم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت ششم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت ششم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت هفتم و آخر

 

مقاله مرتبط با قوانين تجاري (Business Rules) :

قوانین تجاری و کسب و کار (Business Rules) - مثال عملی سیستم سفارش غذای آنلاین

 

 

تذكر مهم  : اگر چه Use Case ذيل از لحاظ آموزشي بسيار مفيد مي باشد ولي از نظر اينجانب داراي ابهاماتي مي باشد و لازم است اصلاحاتي در آن صورت پذيرد ولي در اين مرحله من متن اصلي را آورده ام و همانطور كه قبلا هم گفتم در يك سلسله مقالات روش نوشتن بهينه Use Case ها را با مثال آموزش خواهم داد ان شاء ....

 

 

شماره Use Case :	11
عنوان :	اصلاح فهرست غذا
ايجاد كننده :                           آخرين بروز رساني كننده : تاريخ ايجاد :                            تاريخ آخرين بروز رساني :
راهبران اصلي :	مدير فهرست غذا
توضيح :	مدير فهرست غذا ، ممكن است نسبت به اصلاح فهرست غذا از لحاظ در دسترس بودن و يا قيمت نمايد تا براي يك تاريخ معين در تعداد و قيمت ها بروز بوده و يا غذاي مخصوص روز ، تعريف شده باشد.
پيش شرط :	فهرست غذا در حال حاضر در سيستم وجود دارد.
پس شرط :	فهرست غذاي تغيير يافته ذخيره مي گردد.
سناريوي موفق اصلي :	11.0 ويرايش فهرست موجود مدير فهرست درخواست مشاهده فهرست غذاي يك روز مشخص را مي دهد. سيستم فهرست غذا را نمايش مي دهد. مدير فهرست تغييرات مورد نظر شامل اضافه نمودن يك آيتم ، حذف و يا تغيير يك آيتم ، ايجاد يا تغيير غذاي مخصوص و يا تغيير قيمتها را صورت مي دهد. مدير فهرست درخواست ذخيره نمودن فهرست را مي دهد سيستم فهرست اصلاح شده را ذخيره مي نمايد.
ساير حالتها :	ندارد
استثنا ها :	مرحله 1a : هيچ فهرستي براي روز مشخص شده وجود ندارد. 1.  سيستم مدير فهرست را از عدم وجود فهرست براي روز مشخص شده ، مطلع مي سازد. 2.  سيستم از مدير فهرست در خصوص ايجاد فهرست غذا براي روز مشخص شده ، كسب تكليف مي نمايد. 3a .مدير فهرست پاسخ مثبت مي دهد. 3b.سيستم رويه ايجاد فهرست جديد را فراخواني مي كند. 4a. مدير فهرست پاسخ منفي مي دهد. 4b.سيستم به رويه پايان مي دهد.   مرحله 2a : تاريخ مشخص شده قبل از تاريخ جاري مي باشد. 1.سيستم مدير فهرست را از عدم امكان اصلاح فهرست غذاي روزهاي قبل ، مطلع مي سازد. 2.سيستم به رويه پايان مي دهد.
Use Case هاي فراخواني شونده :	ايجاد فهرست غذا
اولويت :	بالا
فراواني استفاده :	بطور متوسط 20 مرتبه در هفته توسط يك كاربر
قوانين تجاري مرتبط :	قانون تجاري 24
نيازمنديها خاص :	مدير فهرست در هر لحظه امكان دارد از ثبت تغييرات داده شده انصراف دهد . در اين صورت سيستم مي بايد در خصوص لغو تغييرات ، تاييديه كاربر را اخذ نمايد.
فرضيات :	براي هر روز كاري رسمي ، يك فهرست غذا ايجاد خواهد شد علاوه بر آن براي روزهاي تعطيل و آخر هفته هايي كه طبق برنامه ريزي مي بايد كارمندان در محل شركت حاضر گردند اين عمل صورت مي پذيرد.
يادداشت ها و ملاحضات :	1.  بعضي از آيتمها در محل تحويل داده نخواهند شد لذا فهرست غذاهايي كه قابل تحويل دادن در محل مي باشند با فهرست غذاهايي كه در محل رستوران قابل تحويل مي باشند ، يكسان نيست. لذا فهرست غذا مي بايد به نحوي آيتمهايي كه قابل تحويل در محل نيستند را مشخص نمايد.سيستم مي بايد اجازه سفارش اين آيتمها را جهت تحويل در محل ندهد.

 

 

خوب دوستان اينم از اين مطلب

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت

 

بنام خدا

با سلام

يكي از مشكلات بزرگي كه در برنامه هاي كاربردي مشاهده مي شود باگها و يا غير قابل اطمينان و يا متناقض بودن نتايج عمليات و يا گزارشات سيستم مي باشد كه در بسياري موارد نتيجه طراحي غير اصولي بانك اطلاعاتي برنامه كاربردي بوده و هزينه هاي زماني و ريالي زيادي جهت پشتيباني اينگونه نرم افزارها مورد نياز است در اين سري مقالات سعي يك مثال عملي در خصوص طراحي بانك آورده شده است تا در راستاي مقالات قبلي به فهم بهتر اصول طراحي بانك اطلاعات كمك نمايد.

 

تذكر : ابتدا قسمت اول و دوم و سوم اين مقاله را مطالعه نماييد.

 

تذكر مهم : هنگام پياده سازي بانك اطلاعاتي مربوطه بهتر است بعد از ساخت جداول بر روي نيازمنديها تمركز نموده و سپس با توجه به آن ويوهاي (View) مناسبي را ايجاد نماييد تا با انجام پرس و جو از روي هر يك تعدادي از نياز پاسخ داده شود بطور مثال :

 

Create View SaleInformationvew AS

Select ,StoreTitle,ProductName,SalerFName+'-'+SalerLName SalerName ,  Taste,Volume,Containertbl.Type, Date ,  Num

From Storetbl Inner Join Saletbl On

Storetbl.StoreCode=Saletbl.StoreCode Inner Join Producttbl On Producttbl.ProductCode=Saletbl.ProductCode Inner Join Containertbl On

Producttbl.ContainerCode= Containertbl. ContainerCode Inner Join Salertbl On

Saletbl.SalerCode=Salertbl.SalerCode

Where Saletbl.Type=1

 

 

حال اين ويو اطلاعاتي به شكل ذيل را داراست :

 

Num	Date	‏Type	Volume	‏Taste‏	SalerName	‏ProductName	‏ٍStoreName
400	87/01/09	يكبار مصرف	300	كولا	ناصر علايي	نوشابه 300 سي سي كولا	فروشگاه شهروند مركزي
350	87/01/09	يكبار مصرف	500	كولا	ناصر علايي	نوشابه 500 سي سي كولا	فروشگاه شهروند مركزي
50	87/01/10	يكبار مصرف	300	كولا	آرش شكرابي	نوشابه 300 سي سي كولا	فروشگاه شهروند مركزي
126	87/01/20	يكبار مصرف	500	پرتغالي	آرش شكرابي علايي	نوشابه 500 سي سي پرتقالي	فروشگاه شهروند مركزي
325	87/01/15	يكبار مصرف	500	ليمويي	سعيد سهرابي	نوشابه 500 سي سي ليمويي	فروشگاه شهروند مركزي

 

حال مثال اول را به ياد بياوريد :

ميزان فروش به تفكيك نوع عصاره : با ايجاد يك پرس و جو (Query) از دو جدول محصول (Producttbl) و فروش (Saletbl) بصورت ذيل مي توان نتيجه مورد نظر را گرفت :

Select Taste,Sum(Num) Num

From Producttbl Inner Join Saletbl On Producttbl.ProductCode=Saletbl.ProductCode

Where Saletbl.Date Between '01/01/87' And '30/12/87'

Group By Taste

بازنويسي با توجه به ويوي فوق :

Select Taste,Sum(Num) Num

From SaleInformationvew

WhereDate Between '01/01/87' And '30/12/87'

Group By Taste

 

و يا مثال : ميزان فروشي كه يك فروشنده خاص صورت داده است به تفكيك عامل و نوع محصول

گزارش فوق با ايجاد يك پرس و جو (Query) از 3 جدول محصول (Producttbl) ، عامل (Storetbl) و فروش (Saletbl) بدست مي آيد.

 

Select StoreTitle,ProductName,Sum(Num) Num

From Storetbl Inner Join Saletbl On

Storetbl.StoreCode=Saletbl.StoreCode Inner Join Producttbl On Producttbl.ProductCode=Saletbl.ProductCode

Where Saletbl.Type=1 And Saletbl.Saletbl.SalerCode=10 And Saletbl.Date Between '01/01/87' And '30/01/87'

Group By StoreName,ProductName

بازنويسي با توجه به ويوي فوق :

 

Select StoreTitle,ProductName,Sum(Num) Num

From SaleInformationvew

Where SalerName='ناصر علايي' And Date Between '01/01/87' And '30/01/87'

Group By StoreName,ProductName

 

و بازنويسي ريز فروش آن :

 

Select StoreTitle,ProductName, Date , Num

From SaleInformationvew

Where SalerName='ناصر علايي' And Date Between '01/01/87' And '30/01/87'

 

تذكر مهم : ويوي نوشته شده در فوق تنها در حد مثال بوده و بايد فيلدهاي ديگري را نيز به آن اضافه نمود تا گزارشات بيشتري را در برگيرد. دقت كنيد با اين ويو از ايجاد ارتباط پرس و جوهاي مرتبط به نياز گرديده و از طرفي به علت مسطح بودن اطلاعات پرس و جوهايي كه از روي ويوها ساخته مي شوند ساده تر مي باشند.

 

تذكر مهم : كليه پرس و جوهايي كه به عنوان گزارش مي باشند بهتر است بصورت رويه ذخير شده ((Stored Procedure در بانك اطلاعاتي ذخيره شود و با فراخواني آن از نرم افزار نوشته شده ، اطلاعات مورد نظر خود را تهيه كرد.

بطور مثال براي آخرين پرس و جوي نوشته شده مي توان يك Stored Procedure بصورت ذيل نوشت :

 

CREATE PROCEDURE [SaleDetailBySalersp] 

@SalerName Varchar(50),

@StartDate Char(8)

@FinishDate Char(8)

 AS

Select StoreTitle,ProductName, Date , Num

From SaleInformationvew

Where SalerName=@SalerName And Date Between @StartDate And @FinishDate

 

به اين روش هر بار كه كاربر محدوده تاريخي و يا فروشنده مورد نظر خود را در فرم شروط گزارش تغيير داد شما تنها سه پارامتر نام فروشنده (@SalerName) و تاريخ شروع (@StartDate) و تاريخ پايان (@FinishDate) محدوده گزارش را از طريق نرم افزار نوشته شده به بانك اطلاعاتي ارسال نموده تا بانك اطلاعاتي ريز فروش فروشنده مورد نظر شما در محدوده تاريخي تعيين شده را به شما برگرداند.

 

خوب دوستان اينم از اين مطلب

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت

بنام خدا

با سلام

يكي از مشكلات بزرگي كه در برنامه هاي كاربردي مشاهده مي شود باگها و يا غير قابل اطمينان و يا متناقض بودن نتايج عمليات و يا گزارشات سيستم مي باشد كه در بسياري موارد نتيجه طراحي غير اصولي بانك اطلاعاتي برنامه كاربردي بوده و هزينه هاي زماني و ريالي زيادي جهت پشتيباني اينگونه نرم افزارها مورد نياز است در اين سري مقالات سعي يك مثال عملي در خصوص طراحي بانك آورده شده است تا در راستاي مقالات قبلي به فهم بهتر اصول طراحي بانك اطلاعات كمك نمايد.

 

تذكر : ابتدا قسمت اول و دوم اين مقاله را مطالعه نماييد.

 

حال نگاهي به نيازمنديها اوليه مي كنيم تا ببينيم طراحي صورت گرفته جوابگوي آنها خواهد بود بطور مثال نيازمندي شماره 1 :

ميزان فروش به تفكيك نوع عصاره ،حجم، نوع ظرف (يكبار مصرف يا گردشي) : اين نيازمندي حالات مختلفي را مي تواند داشته باشد كه به چند نمونه اشاره مي كنيم :

ميزان فروش به تفكيك نوع عصاره : با ايجاد يك پرس و جو (Query) از دو جدول محصول (Producttbl) و فروش (Saletbl) بصورت ذيل مي توان نتيجه مورد نظر را گرفت :

Select Taste,Sum(Num) Num

From Producttbl Inner Join Saletbl On Producttbl.ProductCode=Saletbl.ProductCode

Where Saletbl.Date Between '01/01/87' And '30/12/87'

Group By Taste

 

Num	‏Taste
5326	پرتغالي
4050	كولا
1689	ليمويي

 

ميزان فروش به تفكيك نوع عصاره و حجم : با ايجاد يك پرس و جو (Query) از 3 جدول محصول (Producttbl) ، ظرف (Containertbl) و فروش (Saletbl) بصورت ذيل مي توان نتيجه مورد نظر را گرفت :

 

Select Taste,Volume,Sum(Num) Num

From Containertbl Inner Join Producttbl On Containertbl.ContainerCode=Producttbl.ContainerCode Inner Join Saletbl On Producttbl.ProductCode=Saletbl.ProductCode

Where Saletbl.Type=1 And Saletbl.Date Between '01/01/87' And '30/12/87'

Group By Taste,Volume

 

Num	‏Volume	‏Taste
1306	300	پرتغالي
4020	1500	پرتغالي
2010	300	كولا
1500	500	كولا
530	1500	كولا
705	300	ليمويي
320	500	ليمويي
664	1500	ليمويي

 

 

نيازمندي شماره 6 : هر تركيب از 5 حالت فوق

مثال : ميزان فروشي كه يك فروشنده خاص صورت داده است به تفكيك عامل و نوع محصول

گزارش فوق با ايجاد يك پرس و جو (Query) از 3 جدول محصول (Producttbl) ، عامل (Storetbl) و فروش (Saletbl) بدست مي آيد.

 

Select StoreTitle,ProductName,Sum(Num) Num

From Storetbl Inner Join Saletbl On

Storetbl.StoreCode=Saletbl.StoreCode Inner Join Producttbl On Producttbl.ProductCode=Saletbl.ProductCode

Where Saletbl.Type=1 And Saletbl.Saletbl.SalerCode=10 And Saletbl.Date Between '01/01/87' And '30/01/87'

Group By StoreName,ProductName

 

Num	‏ProductName	‏ٍStoreTitle
1200	نوشابه 300 سي سي كولا	فروشگاه شهروند مركزي
800	نوشابه 500 سي سي كولا	فروشگاه شهروند مركزي
750	نوشابه 500 سي سي ليمويي	فروشگاه شهروند مركزي
300	نوشابه 500 سي سي كولا	سوپر ستاره
120	نوشابه 500 سي سي پرتغالي	سوپر ستاره
150	نوشابه 1500 سي سي كولا	پيتزا شقايق
150	نوشابه 1500 سي سي پرتغالي	پيتزا شقايق
150	نوشابه 1500 سي سي ليمويي	پيتزا شقايق

 

حال اگر بطور مثال ريز فروش صورت گرفته با شرايط مثال فوق را بخواهيم پرس و جوي ذيل را خواهيم داشت :

 

Select StoreTitle,ProductName, Date , Num

From Storetbl Inner Join Saletbl On

Storetbl.StoreCode=Saletbl.StoreCode Inner Join Producttbl On Producttbl.ProductCode=Saletbl.ProductCode

Where SaleType=1 And Saletbl.Saletbl.SalerCode=10 And Saletbl.Date Between '01/01/87' And '30/01/87'

 

قسمتي از جواب مطابق با جواب پرس و جوي قبلي (ريز فروش به فروشگاه شهروند مركزي) :

 

Num	Date	‏ProductName	‏ٍStoreTitle
400	87/01/09	نوشابه 300 سي سي كولا	فروشگاه شهروند مركزي
350	87/01/09	نوشابه 500 سي سي كولا	فروشگاه شهروند مركزي
800	87/01/19	نوشابه 300 سي سي كولا	فروشگاه شهروند مركزي
450	87/01/25	نوشابه 500 سي سي كولا	فروشگاه شهروند مركزي
750	87/01/25	نوشابه 500 سي سي ليمويي	فروشگاه شهروند مركزي

 

 

با بررسي ساير نيازمنديها به اين نتيجه مي توان رسيد كه طراحي صورت گرفته در برگيرنده نيازمنديها مي باشد بهتر است سعي نماييد روش استخراج ساير نيازمنديها از جداول را به عنوان تمرين انجام دهيد.

 

خوب دوستان اينم از اين قسمت – در قسمت هاي بعد ادامه مثال مربوطه را با هم مرور مي كنيم.

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت

 

بنام خدا

با سلام

يكي از مشكلات بزرگي كه در برنامه هاي كاربردي مشاهده مي شود باگها و يا غير قابل اطمينان و يا متناقض بودن نتايج عمليات و يا گزارشات سيستم مي باشد كه در بسياري موارد نتيجه طراحي غير اصولي بانك اطلاعاتي برنامه كاربردي بوده و هزينه هاي زماني و ريالي زيادي جهت پشتيباني اينگونه نرم افزارها مورد نياز است در اين سري مقالات سعي يك مثال عملي در خصوص طراحي بانك آورده شده است تا در راستاي مقالات قبلي به فهم بهتر اصول طراحي بانك اطلاعات كمك نمايد.

تذكر : ابتدا قسمت اول اين مقاله را مطالعه نماييد.

 

در ذيل نمونه نرمال شده طراحي فوق را مشاهده مي نماييد (در مورد علل تغييرات و نوع نرمال سازيها صورت گرفته بررسي نماييد.)

 

 

نام جدول : Storetbl      توضيح : عامل فروش – مغازه ، رستوران ، اغديه ، نمايندگي و كلا فرشندگان نوشابه
عنوان ستون	نوع	شرح
StoreCode	Int	كد عامل
StoreTilte	Varchar(50)	عنوان عامل
SectionCode	Varchar(30)	كد بخش
Type	Int	نوع عامل

 

نام جدول : Statetbl      توضيح : ليست استان ها
عنوان ستون	نوع	شرح
StateCode	Int	كد استان
StateName	Varchar(50)	عنوان استان

 

نام جدول : Citytbl      توضيح : ليست شهرها
عنوان ستون	نوع	شرح
CityCode	Int	كد شهر
CityName	Varchar(50)	عنوان شهر
StateCode	Int	كد استان – كليد خارجي

 

نام جدول : Sectiontbl      توضيح : ليست بخش ها
عنوان ستون	نوع	شرح
SectionCode	Int	كد بخش
SecrionName	Varchar(50)	عنوان بخش
CityCode	Varchar(30)	كد شهر – كليد خارجي

 

 

نام جدول : Salertbl      توضيح : فروشنده – كليه فروشندگان و رانندگاني كه كالاي شركت را توزيع مي نمايند.
عنوان ستون	نوع	شرح
SalerCode	Int	كد فروشنده
SalerFName	Varchar(50)	نام فروشنده
SalerLName	VarChar(50)	نام خانوادگي فروشنده
NationalCode	Varchar(12)	كد ملي
VehicleType	Varchar(30)	نوع وسيله توزيع
VehicleIDNo	Varchar(30)	پلاك وسيله توزيع
نام جدول : Producttbl      توضيح مشخصات محصولات و كالاهاي قابل فروش
عنوان ستون	نوع	شرح
ProductCode	Int	كد محصول
ProductName	Varchar(50)	نام محصول
Taste	Varchar(12)	عصاره
ContainerCode	Int	كد ظرف – كليد خارجي

 

 

نام جدول : Containertbl      توضيح : ليست مشخصات ظروف
عنوان ستون	نوع	شرح
ContainerCode	Int	كد ظرف
ContainerName	Varchar(50)	عنوان ظرف
Volume	Int	حجم
Type	Int	نوع ظرف (گردشي/يكبار مصرف)

 

 

دو جدول تحويل (Deliverytbl) و فروش (Saletbl) احتياج به تغيير ندارند.

 

نمودار موجوديت نهايي به صورت ذيل مي باشد.

 

 

 

 

خوب دوستان اينم از اين قسمت – در قسمت هاي بعد ادامه مثال مربوطه را با هم مرور مي كنيم.

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت

بنام خدا

با سلام

در طراحي و پياده سازي هر سيستم نرم افزاري مي بايد با استفاده از روش مناسبي ، نسبت به استخراج و مستند سازي عمليات مختلف سيستم اقدام نمود با تجربياتي كه من در مدت كاري خود به آن رسيده ام نوشتن Use Case ها بصورت متني موجب فهم دقيق رويه ها توسط كليه افراد درگير در پروژه (تحليل گر ، برنامه نويس ، مديران پروژه ، كاربران نهايي ، مالك سيستم) مي گردد در اين سري مقالات چند Use Case پروژه سفارش غذاي رستوران آورده شده ، تا شما يك مثال از يك پروژه واقعي را ديده و موجب درك بهتر از Use Case ها گردد. لازم به ذكر است در مقالات ديگري مزايا ، الگوها و روش نوشتن Use Case هاي بهينه را به تفصيل توضيح خواهم داد ولي در حال حاضر به علت درخواست بعضي از دوستان در راستاي تكميل پروژه سيستم سفارش غذاي رستوران ، چند Use Case مهم آن را با هم مرور مي كنيم.

در ذيل لينك مقالات قبلي مرتبط با اين پروژه آورده شده است كه پيشنهاد مي شود ابتدا آنها را مطالعه نماييد.

 

مقالات مرتبط با مستند محدوده و چشم انداز سيستم (Scope and Vision Document) :

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت اول

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت دوم

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت سوم(آخر)

مقالات مرتبط بامستند مشخصات نيازمنديهاي نرم افزار(Software Requirement Specification) :

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت اول

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت دوم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت سوم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت چهارم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت پنجم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت ششم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت ششم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت هفتم و آخر

 

مقاله مرتبط با قوانين تجاري (Business Rules) :

قوانین تجاری و کسب و کار (Business Rules) - مثال عملی سیستم سفارش غذای آنلاین

 

 

تذكر مهم  : اگر چه Use Case ذيل از لحاظ آموزشي بسيار مفيد مي باشد ولي از نظر اينجانب داراي ابهاماتي مي باشد و لازم است اصلاحاتي در آن صورت پذيرد ولي در اين مرحله من متن اصلي را آورده ام و همانطور كه قبلا هم گفتم در يك سلسله مقالات روش نوشتن بهينه Use Case ها را با مثال آموزش خواهم داد ان شاء ....

 

 

شماره Use Case :	1
عنوان :	سفارش غذا
ايجاد كننده :                           آخرين بروز رساني كننده : تاريخ ايجاد :                            تاريخ آخرين بروز رساني :
راهبران اصلي :	مشتري
توضيح :	يك مشتري از طريق شبكه داخلي و يا از منزل به سيستم سفارش غذا دسترسي پيدا كرده و مي تواند بصورت اختياري فهرست غذاي روز مورد نظر را ديده ،‌آيتمهاي غذاي مورد نظر خود را انتخاب و يك سفارش براي غذا ايجاد نمايد تا در يكي از نوبت هاي زماني (نوبت ها 15 دقيقه اي) به محل مشخصي حمل گردد.
پيش شرط :	مشتري به سيستم سفارش غذا وارد شده است. مشتري براي پرداخت به روش كسر از حقوق ثبت نام نموده است.
پس شرط :	سفارش غذا با وضعيت تاييد شده در سيستم سفارش غذا ذخيره شده است. موجودي در دسترش آيتمهاي غذا با توجه به آيتمهاي سفارش داده شده ، بروز مي شود. تعداد نوبت تحويل باقي مانده با توجه به درخواست حمل ، بروزرساني مي شود.
سناريوي موفق اصلي :	1.0 سفارش يك غذا مشتري درخواست مشاهده فهرست غذاي روز مورد نظر را مي نمايد. سيستم فهرست غذاهاي در دسترس و غذاي ويژه را نمايش مي دهد. مشتري يك يا بيشتر از آيتمهاي غذا را از فهرست انتخاب مي نمايد. مشتري سفارش غذا را تاييد مي نمايد. سيستم آيتمهاي سفارش داده شده ، مبلغ هر كدام و مبلغ كل و هر گونه شارژ حمل را نمايش مي دهد. مشتري سفارش غذا را تاييد كرده و يا درخواست اصلاح سفارش غذا را مي دهد (برگشت به مرحله 3) سيستم تعداد نوبت تحويل باقي مانده براي تاريخ سفارش را نمايش مي دهد. مشتري يك نوبت تحويل را انتخاب نموده و محل تحويل را مشخص مي نمايد. مشتري روش پرداخت را مشخص مي نمايد. سيستم پذيرش سفارش را تاييد مي نمايد. سيستم يك تاييديه الكترونيكي شامل جزييات سفارش ، قيمت و دستورالعمل حمل به پست الكترونيك مشتري ارسال مي نمايد. سيستم سفارش را در بانك اطلاعاتي ذخيره نموده ، يك نامه الكترونيكي براي اطلاع پرسنل رستوران ارسال نموده و اطلاعات آيتمهاي غذا را به سيستم انبار رستوران فرستاده و تعداد نوبت تحويل باقي مانده را بروزرساني مي نمايد.
ساير حالتها :	1.1            سفارش بيش از يك غذا (منشعب از مرحله 4) مشتري تقاضاي سفارش غذاي ديگر را مي دهد. برگشت به مرحله 2 1.2            سفارش تعدادي از يك نوع غذا (بعد از مرحله 3) 1.  مشتري درخواست تعداد معيني از غذاي انتخابي را مي دهد. 2.     برگشت به مرحله 2 1.3            سفارش غذاي ويژه روز (بعد از مرحله 4) 1.     مشتري غذاي ويژه را از فهرست انتخاب مي نمايد. 2.     برگشت به مرحله 5
استثنا ها :	مرحله 1a : زمان فعلي بعد از زمان پايان سفارش مي باشد.           1 . سيستم مشتري را از اتمام وقت ايجاد سفارش براي امروز ، مطلع مي سازد. 2a. مشتري سفارش غذا را لغو مي نمايد. 2b. سيستم رويه را پايان مي دهد.     3a. مشتري روز ديگر را انتخاب مي نمايد. 3b.سيستم رويه را از ابتدا شروع مي نمايد.   مرحله 2a : ظرفيت تحويل روز تكميل گرديده است.   1 . سيستم مشتري را از تكميل بودن ظرفيت تحويل ، مطلع مي سازد. 2a. مشتري سفارش غذا را لغو مي نمايد. 2b. سيستم رويه را پايان مي دهد.           3.مشتري درخواست تحويل غذا در محل رستوران را مي       دهد.(پرش از مراحل 7و8)   مرحله 3a : به تعداد كافي از غذاي مشخص شده وجود ندارد.     1 . سيستم مشتري را از حداكثر مقدار ممكن جهت سفارش آن غذا ، مطلع مي سازد.   2. مشتري سفارش غذا را لغو مي نمايد و يا مقدار سفارش را تغيير مي دهد.
Use Case هاي فراخواني شونده :	وجود ندارد.
اولويت :	بالا
فراواني استفاده :	400 كاربر و بطور متوسط يك سفارش براي هر روز
قوانين تجاري مرتبط :	قوانين تجاري 1 و 2و3و4و8و11و12و33
نيازمنديها خاص :	مشتري مي بايد در هر مرحله اي قبل از تاييد امكان لغو سفارش را داشته باشد. مشتري مي بايد قادر به مشاهده كليه غذاهايي كه در 6 ماه گذشته سفارش داده را داشته و بتواند در سفارش جديد آنها را تكرار نمايد مشروط به اينكه كليه آيتمها در فهرست غذاي روز مورد نظر وجود داشته باشد(اولويت = متوسط)
فرضيات :	فرض بر  آنست كه 30 درصد از مشتريان غذاي ويژه روز را سفارش مي دهند (منبع : اطلاعات 6 ماه قبل رستوران)
يادداشت ها و ملاحضات :	1.  تاريخ پيش فرض سيستم در حالتي كه مشتري قبل از پايان زمان سفارش امروز سفارش بدهد تاريخ امروز بوده و در غير اينصورت تاريخ فردا خواهد بود. 2.  اگر مشتري تقاضاي تحويل در محل را نداشته باشد پيش شرط ثبت نام در روش كسر از حقوق كاربرد ندارد. 3.  حداكثر زمان استفاده از اين رويه بين ساعت 8:00 و 10:00 صبح به وقت محلي مي باشد.

 

 

خوب دوستان اينم از اين قسمت – ادامه اين مطلب را در مقالات بعد مرور خواهيم كرد.

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت

بنام خدا

با سلام

در طراحي و پياده سازي هر سيستم نرم افزاري مي بايد با استفاده از روش مناسبي ، نسبت به استخراج و مستند سازي عمليات مختلف سيستم اقدام نمود با تجربياتي كه من در مدت كاري خود به آن رسيده ام نوشتن Use Case ها بصورت متني موجب فهم دقيق رويه ها توسط كليه افراد درگير در پروژه (تحليل گر ، برنامه نويس ، مديران پروژه ، كاربران نهايي ، مالك سيستم) مي گردد در اين سري مقالات چند Use Case پروژه سفارش غذاي رستوران آورده شده ، تا شما يك مثال از يك پروژه واقعي را ديده و موجب درك بهتر از Use Case ها گردد. لازم به ذكر است در مقالات ديگري مزايا ، الگوها و روش نوشتن Use Case هاي بهينه را به تفصيل توضيح خواهم داد ولي در حال حاضر به علت درخواست بعضي از دوستان در راستاي تكميل پروژه سيستم سفارش غذاي رستوران ، چند Use Case مهم آن را با هم مرور مي كنيم.

در ذيل لينك مقالات قبلي مرتبط با اين پروژه آورده شده است كه پيشنهاد مي شود ابتدا آنها را مطالعه نماييد.

 

مقالات مرتبط با مستند محدوده و چشم انداز سيستم (Scope and Vision Document) :

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت اول

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت دوم

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت سوم(آخر)

مقالات مرتبط بامستند مشخصات نيازمنديهاي نرم افزار(Software Requirement Specification) :

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت اول

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت دوم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت سوم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت چهارم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت پنجم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت ششم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت ششم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت هفتم و آخر

 

مقاله مرتبط با قوانين تجاري (Business Rules) :

قوانین تجاری و کسب و کار (Business Rules) - مثال عملی سیستم سفارش غذای آنلاین

 

گروه هاي كاربري مختلف همراه با Use Case هاي مرتبط با آنها در جدول ذيل آمده است و هر گروه كاربري به عنوان بازيگر يا راهبر اصلي (Primary Actor) Use Case هاي مرتبط ، شناخته مي شوند.

 

راهبر اصلي	Use Cases
مشتري	سفارش غذا تغيير سفارش غذا لغو سفارش غذا مشاهده فهرست غذا ثبت نام براي كسر از حقوق لغو ثبت نام براي كسر از حقوق اشتراك براي غذاي متعارف اصلاح اشتراك غذا لغو اشتراك غذا
مدير فهرست غذا	ايجاد فهرست اصلاح فهرست تعريف غذاي ويژه
پرسنل رستوران	آماده نمودن غذا ايجاد درخواست پرداخت درخواست حمل ايجاد گزارشات رايج از سيستم
تحويل دهنده غذا	تحويل غذا ثبت تحويل غذا چاپ دستورالعمل حمل

 

 

 

شماره Use Case :	5
عنوان :	ثبت نام براي كسر از حقوق
ايجاد كننده :                           آخرين بروز رساني كننده : تاريخ ايجاد :                            تاريخ آخرين بروز رساني :
راهبران اصلي :	مشتري ، سيستم حقوق
توضيح :	مشتريان رستوران كه از سيستم غذاي سفارش غذاي رستوران استفاده مي نمايند و خواهان تحويل گرفتن غذا در  محل مي باشند مي بايست براي كسر از حقوق ثبت نام نمايند.براي خريدهاي غير نقدي كه در سيستم ثبت مي شود ، رستوران يك درخواست پرداخت به سيستم حقوق ارسال مي نمايد كه به موجب آن مبلغ سفارش از حقوق بعدي مشتري (پرسنل) كسر خواهد شد.
پيش شرط :	مشتري به سيستم سفارش غذا وارد شده است.
پس شرط :	ثبت نام مشتري براي كسر از حقوق صورت گرفته است.
سناريوي موفق اصلي :	5.0 ثبت نام براي كسر از حقوق مشتري درخواست ثبت نام براي كسر از حقوق مي نمايد. سيستم Use Case مربوط به اعتبار سنجي شناسه كاربري را فراخواني مي نمايد. سيستم از سيستم حقوق ،  واجد شرايط بودن مشتري براي ثبت نام روش كسر از حقوق را جويا مي شود. سيستم حقوق واجد شرايط بودن مشتري را تصديق مي نمايد. سيستم مشتري را از واجد شرايط بودن براي كسر از حقوق آگاه مي سازد. سيستم تاييد مشتري براي ثبت نام روش كسر از حقوق جويا مي شود. مشتري تمايل خود را براي ثبت نام روش كسر از حقوق تصديق مي نمايد. سيستم از سيستم حقوق مي خواهد تا روش كسر از حقوق را براي مشتري برقرار نمايد. سيستم حقوق برقراري روش كسر از حقوق براي مشتري را تصديق مي نمايد. سيستم مشتري را از برقراري امكان پرداخت به روش كسر از حقوق مطلع نموده و شماره تاييديه ترانزكشن ثبت نام را نمايش مي دهد.
ساير حالتها :	وجود ندارد.
استثنا ها :	مرحله 2a : اعتبار مشتري تاييد نمي شود : 1.  سيستم به كاربر دو شانس ديگر براي ورود شناسه كاربري صحيح مي دهد. 1.1     اگر تصديق صورت پذيرفت مشتري ساير مراحل را انجام مي دهد. 1.2     اگر تصديق بعد از 3 بار صورت نگرفت سيستم مشتري را مطلع نموده و تلاش براي ورود غير مجاز را ثبت نموده و رويه تمام مي شود.   مرحله 4a : مشتري واجد شرايط براي روش كسر از پرداخت نمي باشد. 1.  سيستم مشتري را از عدم واجد شرايط بودن براي روش كسر از حقوق مطلع مي نمايد. 2.     سيستم رويه را پايان مي دهد.   مرحله 4b : مشتري قبلا براي روش كسر از حقوق ثبت نام نموده است : 1.  سيستم مشتري را از اينكه در حال حاضر براي روش كسر از حقوق ثبت نام شده است مطلع مي نمايد. 2.     سيستم رويه را پايان مي دهد.
Use Case هاي فراخواني شونده :	اعتبار سنجي شناسه كاربري
اولويت :	بالا
فراواني استفاده :	بطور متوسط يك مرتبه براي هر پرسنل
قوانين تجاري مرتبط :	قوانين تجاري 88 و 86 كه مرتبط با شرايط واجد شرايط بودن براي ثبت نام در روش كسر از حقوق مي باشد.
نيازمنديها خاص :	1. اعتبار سنجي كاربر ، مطابق با استاندارد شركت براي نرم افزارهاي كاربردي با سطح امنيتي متوسط ، مي باشد.
فرضيات :	وجود ندارد.
يادداشت ها و ملاحضات :	1. انتظار مي رود به مدت 2 هفته از برپايي سيستم فراواني استفاده از اين Use Case بالا باشد.

 

خوب دوستان اينم از اين قسمت - در قسمت های بعد ادامه این مطلب را با هم مرور می کنیم.

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت

بنام خدا

با سلام

با توجه به اهميتي كه قوانين تجارت و كسب و كاري مجموعه اي كه شما براي آن سيستم را توسعه مي دهيد در روند طراحي و پياده سازي سيستم تاثير به سزايي دارد مي بايد قسمتي از مستند مشخصات نيازمنديها و يا مستند جداگانه اي را به قوانين كسب و كار آن مجموعه اختصاص دهيد در ذيل قسمتي از قوانين تجاري مربوط به سيسستم سفارش غذاي رستوران را كه در مقالات قبلي دو مستند محدوده و چشم انداز سيستم  (Scope and Vision Document) و مشخصات نيازمنديهاي نرم افزار (Software Requirement Specification) آن را به تفصيل بررسي نموديم ، آورده شده است توصيه مي شود در صورتي كه مقالات مربوطه به دو مستند قبلي را مطالعه ننموده ايد ابتدا آنها را مطالعه نماييد.

 

مقالات مرتبط با مستند محدوده و چشم انداز سيستم (Scope and Vision Document) :

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت اول

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت دوم

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت سوم(آخر)

مقالات مرتبط بامستند مشخصات نيازمنديهاي نرم افزار(Software Requirement Specification) :

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت اول

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت دوم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت سوم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت چهارم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت پنجم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت ششم

مستند مشخصات نيازمنديها نرم افزار - مثال عملي سيستم سفارش غذا آنلاين - قسمت ششم

 

قوانين تجارت و  كسب و كار (Business Rules) سيستم سفارش غذاي رستوران :

 

شماره شناسايي	تعريف قانون	نوع قانون	ثابت يا متغير	منبع
قانون تجاري 1	نوبت حمل يك محدوده 15 دقيقه اي مي باشد كه ابتداي هر يك از چهار ربع ساعت شروع مي شود.	واقعيت	ثابت	مدير رستوران
قانون تجاري 2	عمليات حمل مي بايد در محدوده ساعت 10 صبح تا 2 بعداز ظهر به اتمام برسد.	محدوديت	متغير	مدير رستوران
قانون تجاري 3	همه غذاهاي يك سفارش مي بايد به يك مقصد حمل شود.	محدوديت	ثابت	مدير رستوران
قانون تجاري 4	همه مبالغ مربوط به آيتمهاي يك سفارش غذا بايد به يك روش پرداخت گردند.	محدوديت	ثابت	مدير رستوران
قانون تجاري 8	غذاها مي بايد حداكثر براي 14 روز بعد از تاريخ سفارش ، سفارش داده شوند.	محدوديت	متغير	مدير رستوران
قانون تجاري 11	اگر يك غذا به محل مشتري ارسال شوذ مشتري بايد پرداخت را به روش كسر از حقوق انجام دهد.	محدوديت	متغير	مدير رستوران
قانون تجاري 12	قميت سفارش بدين صورت محاسبه مي شود : جمع مبالغ هر آيتم سفارش در تعداد آن آيتم به اضافه هزينه حمل در صورتي كه به محلي خارج از محدوده حمل رايگان ، ارسال گردد.	محاسبه	متغير	خط مشي رستوران
قانون تجاري 24	تنها كارمنداني از رستوران مجاز به ايجاد ، اصلاح و حذف فهرست غذا مي باشند كه بوسيله مدير رستوران بعنوان مدير فهرست مشخص شده اند.	محدوديت	ثابت	خط و مشي رستوران
قانون تجاري 33	انتقال اطلاعات شبكه اي كه دربرگيرنده اطلاعات مالي يا مشخصات پرسنلي مي باشند لازم است با استاندارد 128 بيت رمزگذاري شوند.	محدوديت	ثابت	خط و مشي امنيتي شركت
قانون تجاري 35	(جزييات درباره خط و مشي محدوديت هاي دسترسي به سيستم هاي كامپيوتري بايد اينجا آورده شود.)	محدوديت	ثابت	خط و مشي امنيتي شركت
قانون تجاري 86	تنها پرسنل دايمي شركت امكان ثبت نام براي پرداخت به روش كسر از حقوق را دارند.	محدووديت	قابت	مدير مالي شركت
قانون تجاري 88	يك كارمند در صورتي مي تواند براي روش كسر از حقوق ثبت نام نمايد كه بيشتر از 40 درصد حقوق ناخالص او بابت ساير موارد كسر نگردد.	محدوديت	متغير	مدير مالي شركت

 

 

 

خوب دوستان اينم از اين مطلب

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت

بنام خدا

با سلام

با توجه به اهميتي كه مستند مشخصات نيازمنديها دارد يك نمونه عملي از اين مستند را طي چند قسمت با هم مرور خواهيم كرد موضوع مورد نظر همان پروژه سيستم سفارش غذاي رستوران كه در مقالات اوليه  معرفي گرديد (در قالب سه قسمت تحت عنوان مستند محدوده و چشم انداز سيستم (Vision And Scope Document) ، مي باشد. لذا توصيه مي شود در صورتي كه آن مقالات را مطالعه ننموده ايد ابتدا آنها را مطالعه نماييد.

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت اول

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت دوم

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت سوم(آخر)

ادامه مستند مشخصات نيازمنديها :

ادامه ضميمه 1 : ديكشنري داده ها و مدل داده اي

شكل 2

قسمتي از مدل داده اي ويرايش 1 سيستم سفارش غذاي رستوران.

 

ضميمه 2 : مدلهاي فاز طراحي

شكل 3

دياگرام تغيير وضعيت براي سفارش غذا

خوب دوستان اينم از اين مطلب

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت

بنام خدا

با سلام

با توجه به اهميتي كه مستند مشخصات نيازمنديها دارد يك نمونه عملي از اين مستند را طي چند قسمت با هم مرور خواهيم كرد موضوع مورد نظر همان پروژه سيستم سفارش غذاي رستوران كه در مقالات اوليه  معرفي گرديد (در قالب سه قسمت تحت عنوان مستند محدوده و چشم انداز سيستم (Vision And Scope Document) ، مي باشد. لذا توصيه مي شود در صورتي كه آن مقالات را مطالعه ننموده ايد ابتدا آنها را مطالعه نماييد.

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت اول

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت دوم

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت سوم(آخر)

ادامه مستند مشخصات نيازمنديها :

ضميمه 1 : ديكشنري داده ها و مدل داده اي ( Data Dictionary and Data Model)

 

 

دستورالعمل حمل	= + + + +	نام مشتري شماره تلفن مشتري تاريخ تحويل غذا محل تحويل نوبت حمل
محل تحويل	=	ساختمان يا اتاقي كه سفارش غذا بايد به آنجا حمل شود.
نوبت حمل	=	يك محدوده زماني 15 دقيقه اي كه يك سفارش بايد در آن محدوده تحويل گردد. يك ساعت داراي 4 محدوده زماني مي باشد.
شماره پرسنلي(employee ID)	=	شماره شناسايي پرسنل شركت كه سفارش غذا داده اند. رشته عددي كاراكتري بطول 6
توضيح آيتم غذا	=	توضيح متني يك آيتم غذا در فهرست غذا – حداكثر 100 كاراكتر
قيمت آيتم غذا	=	ارزش يك عدد از آيتم غذاي موجود در فهرست غذا – برحسب تومان
تاريخ تحويل غذا	=	تاريخي كه غذا مي بايد تحويل داده / يا گرفته شود. فرمت YYYY/MM/DD – اگر زمان سفارش غذا به پايان نرسيده باشد پيش فرض آن روز جاري و در غير اين صورت روز بعد مي باشد- نبايد قبل از تاريخ جاري باشد.
سفارش غذا	= + + + + +	شماره سفارش غذا تاريخ سفارش تاريخ تحويل غذا آيتم غذاي سفارش داده شده (1:m) دستورالعمل حمل وضعيت سفارش غذا
شماره سفارش غذا	=	يك شماره صحيح ترتيبي منحصر به فرد كه سيستم به هر سفارش غذاي تاييد شده اختصاص مي دهد – مقدار اوليه 1
وضعيت سفارش غذا	=	]ناقص / تاييد شده/ آماده شده / مرحله تحويل / تحويل شده / لغو شده[ - به دياگرام وضعيت در ضميمه 2 نگاه كنيد.
پرداخت	= + +	مبلغ پرداختي روش پرداخت (شماره ترانزكشن كسر از حقوق)
فهرست غذا	= + +	تاريخ فهرست آيتم غذاي فهرست (1:m) ويژه – 0:1
تاريخ فهرست	=	تاريخ كه فهرست غذاي مورد نظر در دسترس مي باشد – فرمت YYYY/MM/DD
آيتم غذاي فهرست	= +	توضيح آيتم غذا قسمت آيتم غذا
زمان پايان سفارش	=	زماني از روز كه تا قبل از آن كليه سفارشات آن روز بايد مشخص شده باشد.
تاريخ سفارش	=	تاريخي كه مشتري سفارش خود را ثبت نموده است – فرمت YYYY/MM/DD
آيتم غذاي سفارش داده شده	= +	آيتم غذاي فهرست مقدار سفارش داده شده
مشتري	= + + + +	نام مشتري شماره پرسنلي شماره تلفن مشتري محل مشتري پست الكترونيكي مشتري
پست الكترونيكي مشتري	=	پست الكترونيكي مشتري كه سفارش را ايجاد كرده است – كاراكتر حرفي عددي به طول 50
محل مشتري	=	شماره ساختمان و اتاق كه پرسنل سفارش دهنده كار مي كند – كاركتر حرفي عددي به طول 50
نام مشتري	=	نام مشتري كه سفارش غذا داده است –كاراكتر حرفي عددي به طول 30
شماره تلفن مشتري	=	شماره تلفن مشتري كه سفارش غذا داده است – فرمت AAA-NNNNNNNN xXXXX به ترتيب كد منطقه – شماره تلفن – داخلي
مبلغ پرداختي	=	مبلغ كل يك سفارش به تومان – روش محاسبه در BR-12
روش پرداخت	=	]كسر از حقوق/نقدي[ - موارد ديگري در نسخه 2 اضافه خواهد شد.
شماره ترانزكشن كسر از حقوق	=	يك عدد صحيح ترتيبي 8 رقمي كه سيستم حقوق به هر ترانزكشن كسر از حقوق تخصيص مي دهد.
مقدار سفارش	=	تعداد از هر آيتم غذاي كه مشتري سفارش مي دهد – پيش فرض = 1 ،  ماكزيمم = موجودي فعلي انبار
ويژه	= +	توضيح حالت ويژه قيمت حالت ويژه مدير فهرست غذا امكان تعريف يك يا بيشتر غذاي ويژه را در هر فهرست غذا دارد بنحوي كه با تركيب چند آيتم غذا شامل تخفيف گردد.
توضيح حالت ويژه	=	شرح متني در خصوص غذاي ويژه روز – حداكثر 100 كاراكتر
قيمت حالت ويژه	=	قيمت يك واحد از غذاي ويژه روز به تومان

 

 

خوب دوستان اينم از اين قسمت – در قسمتهاي بعد ادامه اين مستند را با هم مرور مي كنيم

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت

بنام خدا

با سلام

با توجه به اهميتي كه مستند مشخصات نيازمنديها دارد يك نمونه عملي از اين مستند را طي چند قسمت با هم مرور خواهيم كرد موضوع مورد نظر همان پروژه سيستم سفارش غذاي رستوران كه در مقالات اوليه  معرفي گرديد (در قالب سه قسمت تحت عنوان مستند محدوده و چشم انداز سيستم (Vision And Scope Document) ، مي باشد. لذا توصيه مي شود در صورتي كه آن مقالات را مطالعه ننموده ايد ابتدا آنها را مطالعه نماييد.

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت اول

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت دوم

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت سوم(آخر)

ادامه مستند مشخصات نيازمنديها :

1. ساير نيازمنديهاي غير عملياتي :
1. نيازمنديهاي كارايي :

نيازمندي كارايي 1 : سيستم مي بايد در زمان استفاده حداكثري از سيستم كه مابين ساعت 8 تا صبح مي باشد جوابگوي 400 كاربر با مدت زمان ميانگين 8 دقيقه براي هر يك باشد.

نيازمندي كارايي 2 : كليه صفحات وب ايجاد شده مي بايد در يك ارتباط با سرعت 40 KBps در زماني كمتر از 10 ثانيه بصورت كامل دانلود و نمايش داده شود.

نيازمندي كارايي 3 : بعد از اينكه كاربر يك پرس وجو را تاييد نمود سيستم مي بايد در زمان كمتر از 7 ثانيه جواب مورد نظر را در نمايش دهد.

نيازمندي كارايي 4 : سيستم مي بايد ظرف مدت 4 ثانيه بعد از ارسال اطلاعات از طرف كاربر ، پيغام تاييد آن را نمايش دهد.

 

2. نيازمندي هاي ايمني :

هيچ نيازمندي ايمني تشخيص داده نشده است.

 

3. نيازمنديهاي امنيتي :

نيازمندي امنيتي 1 : كليه اطلاعات مرتبط با مسائل مالي و يا مشخصات پرسنلي كه تحت شبكه رد و بدل مي شوند بايد مطابق با BR-33 رمزگذاري گردند.

نيازمندي امنيتي 2 : كاربر براي انجام كليه عمليات (به جز مشاهده فهرست غذا) مي ايد مجبور به ورود(Log in) به سيستم باشد.

نيازمندي امنيتي 3 : مشتري مي بايد مطابق با دسترسي سيستمي محدوده شده كه در BR-35 آمده است به سيستم وارد شود.

نيازمندي امنيتي 4 : سيستم مي بايد تنها به آندسته از پرسنل رستوران كه جزو ليست مديران فهرست مي باشند اجازه ويرايش و يا ايجاد فهرست غذا را بدهد

 BR-24

نيازمندي امنيتي 5 : تنها كاربراني كه مجاز به دسترسي از منزل به شبكه محلي شركت را دارند اجاز استفاده از سيستم سفارش غذا را از محلهاي خارج از شركت دارند.

نيازمندي امنيتي 6 : سيستم مي بايد به مشتريان اجاز مشاهده سفارشات قبلي خودشان را بدهد نه سفارشات ايجاد شده توسط ساير  مشتريان

 

4. خصوصيات كيفي نرم افزار :

در دسترس بودن 1 : سيستم سفارش غذاي رستوران مي بايد همواره از طريق شبكه داخلي شركت در دسترس باشد. همچنين مي بايد براي كاربران با اتصال از طريق شماره گيري با احتمال 99.9 درصد از ساعت 5 صبح محلي  تا نيمه شب محلي و با احتمال 95 درصد از نيمه شب  محلي تا ساعت 5 صبح محلي در دسترس باشد.

استحكام 1 : اگر ارتباط كاربر با سيستم قبل از اينكه يك سفارش تاييد يا رد گردد قطع شود ، سيستم سفارش غذا مي بايد قادر باشد كه كاربر سفارش نيمه كاره را بازيابي نمايد.

 

 

خوب دوستان اينم از اين قسمت – در قسمتهاي بعد ادامه اين مستند را با هم مرور مي كنيم

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت

 

بنام خدا

با سلام

با توجه به اهميتي كه مستند مشخصات نيازمنديها دارد يك نمونه عملي از اين مستند را طي چند قسمت با هم مرور خواهيم كرد موضوع مورد نظر همان پروژه سيستم سفارش غذاي رستوران كه در مقالات اوليه  معرفي گرديد (در قالب سه قسمت تحت عنوان مستند محدوده و چشم انداز سيستم (Vision And Scope Document) ، مي باشد. لذا توصيه مي شود در صورتي كه آن مقالات را مطالعه ننموده ايد ابتدا آنها را مطالعه نماييد.

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت اول

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت دوم

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت سوم(آخر)

ادامه مستند مشخصات نيازمنديها :

1. نيازمنديهاي رابط هاي خارجي
   1. رابط هاي كاربري :

رابط كاربري 1 : شماي صفحات و فرمهاي سيستم سفارش غذاي رستوران مي بايد با استاندارد رابط هاي  كاربري نرم افزارهاي كاربردي شركت – نسخه 2.0 مطابقت داشته باشد.

رابط كاربري 2 : سيستم مي بايد در داخل هر صفحه HTML نمايش داده شده يك لينك راهنما به صفحه اي نحوه استفاده از صفحه را توضيح داده است داشته باشد.

رابط كاربري 3 ‌: كليه عمليات پيمايش اطلاعات و انتخاب آيتمهاي غذايي در صفحات وب مي بايست با استفاده از كي بورد قابل انجام باشد بعلاوه امكان استفاده از ماوس و كي بورد بصورت تركيبي نيز وجود داشته باشد.

 

2. رابط هاي سخت افزاري :

هيچ رابط سخت افزاري تشخيص داده نشده است.

 

3. رابط هاي نرم افزاري :

رابط نرم افزاري 1 : سيستم انبار(كنترل موجودي) رستوران

1.1     : سيستم سفارش غذا مي بايد مقدار آيتمهاي غذاي سفارش داده شده را به سيستم انبار رستوران بوسيله يك واسط برنامه اي ، انتقال دهد.

1.2     سيستم سفارش غذا مي بايد موجودي سيستم انبار رستوران را در راستاي تعيين در دسترس بودن آيتم غذاي درخواست شده ، استفاده نمايد.

1.3     هنگامي كه سيستم انبار رستوران اعلام نمود كه يك آيتم غذاي خاص ديگر در دسترس نمي باشد ، سيستم سفارش غذا مي بايد آن آيتم غذايي را از فهرست غذاي روز جاري خارج نمايد.

   رابط نرم افزاري 2 : سيستم حقوق و دستمزد

سيستم سفارش غذاي رستوران مي بايد در راستاي انجام فرايندهاي ذيل از طريق يك رابط برنامه اي با سيستم حقوق مرتبط گردد.

2.1            به مشتري اجاز ثبت نام در روش "پرداخت از طريق كسر از حقوق" را بدهد.

2.2            به مشتري اجاز لغو ثبت نام از روش "پرداخت از طريق كسر از حقوق" را بدهد.

2.3     براي بررسي ثبت نام يا عدم ثبت نام مشتري براي روش "پرداخت از طريق كسر از حقوق"

2.4            ايجاد درخواست پرداخت در راستاي كسر از حقوق

2.5     براي برگشت همه يا قمستي از هزينه هاي قبلي در حالتي كه مشتري يك غذا را نپذيرد يا از آن ناراضي بوده و يا به دليل اينكه غذا در زمان و مكان توافق شده تحويل نگرديده است.

 

4. رابط هاي ارتباطاتي :

رابط ارتباطي 1 : سيستم سفارش غذا در حالتي كه سفارش مورد تاييد مي باشد مي بايد ايميلي شامل سفارش ، قيمت و دستورالعمل حمل براي مشتري ارسال نمايد.

رابط ارتباطي 2 : سيستم سفارش غذا در صورتي كه مشكلي در خصوص سفارش غذا و يا تحويل آن (بعد از پذيرش سفارش)  ايجاد  گردد مي بايد ايميلي به مشتري ارسال گردد.

 

خوب دوستان اينم از اين قسمت – در قسمتهاي بعد ادامه اين مستند را با هم مرور مي كنيم

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت

بنام خدا

با سلام

با توجه به اهميتي كه مستند مشخصات نيازمنديها دارد يك نمونه عملي از اين مستند را طي چند قسمت با هم مرور خواهيم كرد موضوع مورد نظر همان پروژه سيستم سفارش غذاي رستوران كه در مقالات اوليه  معرفي گرديد (در قالب سه قسمت تحت عنوان مستند محدوده و چشم انداز سيستم (Vision And Scope Document) ، مي باشد. لذا توصيه مي شود در صورتي كه آن مقالات را مطالعه ننموده ايد ابتدا آنها را مطالعه نماييد.

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت اول

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت دوم

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت سوم(آخر)

ادامه مستند مشخصات نيازمنديها :

1. قابليتهاي سيستم
1. سفارش غذاها :

                                                              i.      تعريف و اولويت :

يك مشتري كه هويت او تاييد شده مي باشد مي تواند اقدام به سفارش غذا نموده تا در محل مشخصي از شركت به او تحويل داده شود و يا در محل رستوران تحويل گيرد. يك مشتري ممكن است تا قبل از آماده سازي سفارش ، نسبت به لغو و يا تغيير آن اقدام نمايد. اولويت : بالا

                                                            ii.      ترتيب محرك/پاسخ

محرك : مشتري درخواست ايجاد سفارش يك يا بيشتر غذا مي نمايد

پاسخ : سيستم از مشتري اطلاعات مربوط به جزييات سفارش ، نحوه پرداخت و دستورالعمل حمل (آدرس) را ، مي پرسد.

 

محرك : مشتري درخواست تغيير يك سفارش را مي دهد.

پاسخ : اگر وضعيت پذيرفته شده است ، سيستم اجازه ويرايش سفارش قبلي را مي دهد.

 

محرك : مشتري درخواست لغو سفارش را مي دهد.

پاسخ : اگر وضعيت پذيرفته شده است ، سيستم سفارش را لغو مي نمايد.

                                                          iii.      نيازمنديهاي عملياتي

 

Order.Place : سيستم به هر مشتري كه به سيستم وارد شده است اجازه ثبت سفارش براي يك يا چند غذا را مي دهد.

 

Order.Place.Register : سيستم مي بايد ثبت نام مشتري جهت كسر از حقوق را در هنگام ثبت سفارش ، بررسي و تاييد نمايد.

 

Order.Place.Register.No : اگر مشتري براي كسر از حقوق ثبت نام نكرده است سيستم بايد سه امكان مختلف را براي مشتري فراهم نمايد : 1- امكان ثبت نام را براي او فراهم نموده و سپس به ثبت سفارش اقدام نمايد 2- ثبت سفارش براي تحويل در محل رستوران 3- خروج از سيستم

 

Order.Place.Date : سيستم مي بايد تعيين تاريخ سفارش از جانب مشتري را اجباري نمايد.

 

Order.Place.Date.Cutoff : اگر تاريخ سفارش روز جاري بوده و زمان جاري بعد از زمان مجاز براي سفارش مي باشد سيستم مي بايد  مشتري را از اتمام زمان ثبت سفارش جهت امروز آگاه سازد.مشتري مي تواند نسبت به تغيير تاريخ سفارش و يا لغو آن اقدام نمايد.

 

Order.Deliver.Select : مشتري مي بايد مشخص نمايد كه سفارش را در محل كار و يا محل رستوران تحويل خواهد گرفت.

 

Order.Deliver.Location : اگر سفارش مي بايد در محل كار تحويل داده شود و هنوز زمان كافي براي تحويل در تاريخ مقرر وجود دارد ، مشتري مي بايد يك محل تحويل معتبر را معين نمايد.

 

Order.Deliver.Notimes : اگر امكان تحويل در محل كار وجود ندارد (به خاطر تكيمل ظرفيت تحويل )سيستم مي بايد به مشتري اطلاع دهد. مشتري مي تواند نسبت به لغو سفارش و يا تعيين تحويل در محل رستوران اقدام نمايد.

 

Order.Deliver.Times : سيستم مي بايد ظرفيت باقي مانده جهت تحويل در محل كار را براي روز جاري نمايش دهد. سيستم مي بايد به مشتري امكان انتخاب يكي از محدوده هاي زماني  مجاز جهت تحويل در محل كار ، تحويل در محل رستوران و يا لغو درخواست را فراهم نمايد.

 

Order.Menu.Date : سيستم مي بايد يك فهرست غذا براي روز تعيين شده نمايش دهد.

 

Order.Menu.Available : در فهرست غذاي روز جاري تنها مي بايد آيتمهايي نمايش يابد كه حداقل 1 عدد موجودي در سيستم انبار رستوران دارند.

 

Order.Units.Food : سيستم مي بايد به مشتري اجازه تعيين تعداد هر آيتم سفارش غذا را بدهد.

 

Order.Units.Multiple : سيستم بايد به مشتري اجازه سفارش چند عدد از يك غذا را حداكثر به مقدار در دسترس آن ، بدهد.

 

Order.Units.TooMany : اگر مشتري بيشتر از موجودي فعلي از يك آيتم درخواست دهد سيستم مي بايد مشتري را از حداكثر مقدار ممكن جهت سفارش آگاه سازد.

 

Order.Uints.Change : اگر موجودي فعلي جوابگوي تعداد سفارش داده شده نباشد مشتري مي تواند نسبت به تغيير تعداد درخواستي ، تغيير آيتم درخواستي و يا لغو سفارش اقدام نمايد.

 

Order.Confirm.Display : موقعي كه مشتري سفارش خود را كامل شده اعلام نمود سيستم مي بايد اطلاعات لازم شامل آيتمهاي سفارش داده شده ، قيمت هر يك از آيتمها ، مقدار كل پرداختي را محاسبه نمايد . رجوع قاعده تجاري 12

 

Order.Confirm.Prompt : سيستم مي بايد امكان تاييد سفارش را به مشتري بدهد.

 

Order.Confirm.Not : اگر مشتري سفارش را تاييد نكرد مشتري مي تواند نسبت به ويرايش و يا لغو آن اقدام نمايد.

 

Order.Confirm.More : سيستم مي بايد به مشتري اجاز ثبت سفارش غذا ديگر براي همان روز و يا روز ديگر را بدهد. قوانين تجاري 3و4 مرتبط با نحوه سفارش دهي چند غذا در يك سفارش مي باشد.

 

Order.Pay.Method : هنگامي كه مشتري اتمام سفارش را اعلام نموده سيستم مي بايد از مشتري بخواهد يك روش پرداخت را انتخاب نمايد.

 

Order.Pay.Deliver : به قانون تجاري 11 رجوع شود.

 

Order.Pay.Pickup : اگر سفارش جهت تحويل در محل رستوران مي باشد سيستم مي بايد به مشتري اجازه انتخاب پرداخت به روش كسر از حقوق و يا پرداخت نقدي در هنگام تحويل را بدهد.

 

Order.Pay.Details : سيستم مي بايد آيتمهاي سفارش داده شده ، مقدار پرداختي ، روش پرداخت و دستورالعمل حمل را نمايش دهد.

 

Order.Pay.Confirm.Deduct : اگر مشتري سفارش را تاييد كرده و روش پرداخت به صورت كسر از حقوق را انتخاب كرده باشد سيستم مي بايد يك درخواست پرداخت به سيستم حقوق ارسال نمايد.

 

Order.Pay.Confirm.Ok : اگر درخواست پرداخت پذيرفته شد سيستم مي بايد پيغامي مبني بر پذيرش سفارش همراه با شماره ترانزكشن كسر از حقوق نمايش دهد.

 

Order.Pay.Confirm.NG : اگر درخواست پرداخت رد شد سيستم مي بايد پيغامي شامل علت رد آن نمايش دهد.مشتري مي تواند نسبت به لغو سفارش و يا تغيير روش پرداخت به نقدي و درخواست تحويل در محل رستوران اقدام نمايد.

 

Order.Done : هنگامي كه مشتري سفارش را تاييد نمود سيستم مي بايد رويه هاي زير بصورت يك ترانزكشن انجام دهد.

 

Order.Done.Store : اختصاص اولين شماره سفارش ممكن (آخرين شماره + 1) به سفارش و ذخيره نمودن سفارش با وضعيت تاييد شده

 

Order.Done.Inventory : ارسال پيغامي به سيستم انبار (موجودي) شركت كه شامل تعداد درخواستي از هر آيتم سفارش غذا

 

Order.Done.Menu : بروزرساني فهرست غذاهاي روز جاري براي اعمال تاثير آيتمهايي كه در سيستم انبار موجودي ندارند.

 

Order.Done.Times : بروزرساني تعداد در دسترس جهت حمل براي تاريخ اين سفارش

 

Order.Done.Patron : ارسال يك پيغام پست الكترونيكي به مشتري همراه با اطلاعات سفارش و پرداخت

 

Order.Done.Cafeteria : ارسال يك پيغام پست الكترونيكي به رستوران همراه با اطلاعات سفارش

 

Order.Done.Failure : اگر هر كدام از مراحل فوق (Done) انجام نگرديد ، سيستم مي بايد كليه عمليات صورت گرفته را به حالت اول برگرداند و مشتري را از عدم موفقيت در قبول سفارش همراه با دليل آن آگاه سازد.

 

Order.Previous.Period : سيستم مي بايد به مشتري اجازه مشاهده كليه سفارشات خود را كه در طول 6 ماه گذشته بوده است بدهد . اولويت : متوسط

 

Order.Previous.Reorde : مشتري مي تواند نسبت به سفارش مجدد هر غذايي كه ظرف 6 ماه گذشته سفارش داده است اقدام نمايد مشروط به آنكه سيستم در دسترس بودن آنها را براي تاريخ سفارش تاييد نمايد. اولويت : متوسط

 

نيازمنديهاي مرتبط براي تغيير و لغو سفارش غذا در اين مثال آورده نشده است.

 

 

ساير نيازمنديهاي عملياتي در اين مثال آورده نمي شود.

 

خوب دوستان اينم از اين قسمت – در قسمتهاي بعد ادامه اين مستند را با هم مرور مي كنيم

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت

بنام خدا

با سلام

با توجه به اهميتي كه مستند مشخصات نيازمنديها دارد يك نمونه عملي از اين مستند را طي چند قسمت با هم مرور خواهيم كرد موضوع مورد نظر همان پروژه سيستم سفارش غذاي رستوران كه در مقالات اوليه  معرفي گرديد (در قالب سه قسمت تحت عنوان مستند محدوده و چشم انداز سيستم (Vision And Scope Document) ، مي باشد. لذا توصيه مي شود در صورتي كه آن مقالات را مطالعه ننموده ايد ابتدا آنها را مطالعه نماييد.

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت اول

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت دوم

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت سوم(آخر)

ادامه مستند مشخصات نيازمنديها :

2. مشخصات كلي :

1. چشم انداز محصول :

سيستم سفارش غذاي رستوران يك سيستم جديد مي باشد كه جايگزين روش دستي جاري و همچنين فرايند لبفني سفارش و تهيه غذا در رستوران شركت خواهد شد.  Context Diagram مربوطه بيانگر موجوديتهاي خارجي و رابط هاي سيستمي ويرايش اول نرم افزار مي باشد. انتظار مي رود سيستم طي چند ويرايش توسعه يافته و نهايتا از طريق خدمات سفارش اينترنتي امكان اتصال چند رستوران محلي و امكان استفاده از كارتهاي اعتباري (همراه با اعتبارسنجي) فراهم گردد.

 

 

2. مشخصات و گروه هاي كاربري :

 

مشتري	يك مشتري ، يكي از كارمندان شركت مي باشد كه خواهان سفارش غذا و حمل آن از طرف رستوران شركت مي باشد. اينجا در حدود 600 مشتري بالقوه وجود داشته و انتظار مي رود 400 نفر و بطور متوسط 4 بار در هفته از سيستم سفارش آنلاين غذا استفاده نمايند. ( منبع : اطلاعات مرتبط با استفاده از رستوران در حال حاضر). مشتريان در پاره اي موارد چند غذا جهت مراسم گروهي و يا مهمانان سفارش مي دهند.تخمين زده شده است كه 90% مشتريان از طريق اينترانت شركت غذا را سفارش داده و 10% مابقي از خانه اينكار انجام خواهند داد. همه مشتريان دسترسي به شبكه محلي را در محل كار خود دارند. بعضي از مشتريان خواهان تعيين غذاهاي روزه هاي آتي خود هستند كه مي تواند استفاده از يك غذا براي هر روز و يا غذاهاي مختلف باشد. مشتري مي بايست قادر به لغو غذاي سفارش داده شده يك روز خاص باشد.
شكل 1 : نمودار Context Diagram براي ويرايش اول سيستم سفارش غذاي رستوران سيستم سفارش غذا مشتري سيستم حقوق مدير فهرست غذا حمل كننده غذا كارمند  رستوران درخواست حمل درخواست كسر از حقوق درخواست پرداخت محتويات منو درخواست حمل درخواست پرداخت سفارش غذا منو سفارش غذا ثبت نام غذا اعلام كسر از حقوق سيستم انبار رستوران سفارش آيتمهاي غذا اطلاعات در دسترس بودن آيتمهاي غذا جواب درخواست كسر از حقوق بروز رساني وضعيت غذا كارمند رستوران	رستوران شركت در حال حاضر 20 كارمند دارد كه قرار است سفارش را از سيستم سفارش غذا دريافت ، غذاها را آماده و بسته بندي نموده و آدرس و درخواست حمل را چاپ نمايند. بيشتر كارمندان نياز به آموزش در زمينه استفاده از كامپيوتر ، نمايشگر وب و سيستم سفارش غذا دارند.
مدير فهرست غذا	مدير فهرست غذا يك كارمند رستوران مي باشد (كه ممكن است خود مدير رستوران باشد) كه مسئول ايجاد و بروز رساني منوي غذاي روزانه و همچنين زماني از روز كه در دسترس است ، مي باشد. بعضي از آيتمهاي منو ممكن است امكان حمل نداشته باشد. مدير فهرست همچنين معرفي دسرهاي روزانه رستوران را انجام مي دهد. مدير فهرست مي بايد بصورت دوره اي نسبت به ويرايش منو اقدام نموده تا اطلاع رساني لازم در خصوص غذاهايي كه در دسترس نيستند و يا قيمت آنها تغيير نموده ، صورت پذيرد
حمل كننده غذا	حمل كننده يكي از كارمندان رستوران و يا يك پيمانكار مي باشد. حمل كننده غذا و آدرس محل حمل هر غذا را دريافت و سپس به مشتري تحويل مي دهد. تعامل حمل كننده با سيستم عبارتست از چاپ مجدد آدرس حمل در بعضي از مواقع و همچنين تاييد تحويل شدن (يا نشدن) غذا مي باشد.

3. محيط عملياتي (Operating Environment) :

محيط عملياتي 1 : سيستم سفارش غذاي رستوران مي بايد در نمايشگرهاي وب ذيل قابل اجرا باشد : Microsoft Internet Explore 5.0,6.0 و Netscape 6,7

محيط عملياتي 2  : سيستم سفارش رستوران مي بايد در سرور فعلي شركت كه نسخه معتبري از Red Hat Linux و Appache WebServer بر روي آن نصب مي باشد قابل اجرا باشد.

محيط عملياتي 3  : سيستم سفارش غذا اجاز دسترسي كاربران را از شبكه داخلي شركت مي دهد همچنين در صورتي كه كاربر مجاز به دسترسي از خارج شركت مي باشد (در Firewall) ، كاربر مي تواند از طريق ارتباط اينترنتي از منزل به سيستم دسترسي داشته باشد.

4. محدوديت هاي طراحي و پياده سازي :

محدوديت 1 : فرمت مستند سازي مراحل طراحي ، كدنويسي و نگهداري مي بايست مطابق با استاندارد توسعه شركت ويرايش 1.3 باشد.

محدوديت 2 : سيستم مي بايد از نسخه بانك اطلاعاتي اوراكل كه در حال حاضر در شركت وجود دارد استفاده نمايد.

محدوديت 3 : همه كدهاي HTML مي بايد با HTML 4.0  استاندارد ، همخواني داشتته باشد.

محدوديت 4 : همه اسكريپت ها مي بايد با زبان Perl نوشته شود.

 

5. مستندات كاربري :

مستند كاربري 1 : سيستم مي بايد يك راهنماي آنلاين سلسله مراتبي با فرمت HTML داشته باشد كه توابع سيستمي را توضيح دهد.

مستند كاربري 2 : اولين باري كه يك كاربر به سيستم وارد مي شود در صورت درخواست كاربر ، سيستم مي بايد يك نسخه آموزشي آنلاين را در اختيار بگذارد كه به كاربر اجازه ثبت سفارش غذاي تمريني را بدهد. سيستم نبايد اين اطلاعات را در بانك اطلاعاتي ذخيره نمايد و يا از روي آنها سفارشي به رستوران ارسال نمايد.

6. فرضيات و وابستگي ها :

فرض 1 : رستوران در هر سه وعد صبحانه ، نهار و شام روزهاي كاري شركت كه انتظار مي رود كارمندان در شركت باشند باز مي باشد.

محدوديت 1 : عمليات سيستم سفارش غذا به تغييرات سيستم حقوق شركت (براي پذيرش درخواست پرداخت وجه سفارش غذا) وابسته مي باشد.

محدوديت 2 : عمليات سيستم سفارش غذا به تغييرات سيستم انبار(موجودي) شركت (براي بروزرساني دردسترس بودن آيتمهاي غذا در حالتي كه سفارشي تاييد مي گردد.) وابسته مي باشد.

 

خوب دوستان اينم از اين قسمت – در قسمتهاي بعد ادامه اين مستند را با هم مرور مي كنيم

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت

بنام خدا

با سلام

با توجه به اهميتي كه مستند مشخصات نيازمنديها دارد يك نمونه عملي از اين مستند را طي چند قسمت با هم مرور خواهيم كرد موضوع مورد نظر همان پروژه سيستم سفارش غذاي رستوران كه در مقالات اوليه  معرفي گرديد (در قالب سه قسمت تحت عنوان مستند محدوده و چشم انداز سيستم (Vision And Scope Document) ، مي باشد. لذا توصيه مي شود در صورتي كه آن مقالات را مطالعه ننموده ايد ابتدا آنها را مطالعه نماييد.

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت اول

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت دوم

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت سوم(آخر)

مستند مشخصات نيازمنديها شامل موارد ذيل مي باشد و شما مي توانيد با بررسي اين مثال يك الگو (Template)  براي پروژه هاي خود ايجاد نماييد.

فهرست :

1-     مقدمه

a.      هدف مستند

b.     محدوده پروژه و قابليتهاي محصول

c.      مراجع

2-     توضيحات كلي

a.      چشم انداز محصول

b.     مشخصات و گروههاي كاربري

c.      محيط اجرا

d.     محدوديتهاي طراحي و پياده سازي

e.      مستندات كاربري

f.       فرضيات و وابستگي ها

3-     قابليتهاي سيستم

a.      سفارش غذاها

b.     ايجاد ، مشاهده ، اصلاح و حذف ليست مشتركين

c.      ثبت نام براي روشهاي پرداخت

d.     درخواست تحويل غذا

e.      ايجاد ، مشاهده ، اصلاح و حذف از منوي رستوران

4-     نيازمنديها مرتبط با رابط هاي بيروني

a.      رابط هاي كاربري

b.     رابط هاي سخت افزاري

c.      رابط هاي نرم افزاري

d.     رابط هاي ارتباطي

5-     ساير نيازمنديهاي غير عملياتي

a.      نيازمنديهاي مرتبط با كارايي

b.     نيازمنديهاي ايمني

c.      نيازمنديهاي امنيتي

d.     خصوصيات كيفي نرم افزار

ضميمه 1 : مدل داده اي و ديكشنري داده

ضميمه 2 : مدلهاي آناليز

 

 

1-     مقدمه :

a.      هدف مستند :

 اين مستند در برگيرنده نيازمنديهاي عملياتي و غير عملياتي ويرايش اول سيستم سفارش غذاي رستوران مي باشد. اين مستند به منظور استفاده اعضاي تيم پروژه كه وظيفه پياده سازي و ارزيابي صحت عمليات سيستم مي باشند تهيه گرديده است. همه نيازمنديها ذكر شده در اين مستند (به غير از  مواردي كه چيز ديگري گفته شده است) داراي اولويت بالا بوده و جزء تعهدات نسخه اول مي باشد.

b.     محدوده پروژه و قابليتهاي محصول :

سيستم اجازه سفارش آنلاين غذا را به كارمندان داده كه بعد از سفارش مي تواند به محل كار وي حمل گردد. توضيحات كاملي از جزييات پروژه در مستند چشم انداز و محدوده پروژه آمده است (به سه  لينك ابتداي مقاله مراجعه شود.)

در قسمت محدوده ويرايش اوليه و ويرايش هاي بعدي ، قابليتهاي كه براي نسخه اول ، بصورت كامل و يا جزيي پياده سازي مي گردد آمده است.

c.      مراجع :

مستند چشم انداز و محدوده پروژه

مستند استانداردتوسعه تحت شبكه داخلي شركت ويرايش 1.3

كاتالوگ قوانين و قواعد تجاري شركت

استاندارد واسط كاربري برنامه هاي كاربردي تحت وب شركت ويرايش 2.0

 

 

خوب دوستان اينم از اين قسمت – در قسمتهاي بعد ادامه اين مستند را با هم مرور مي كنيم

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت

 

 

بنام خدا

با سلام

اين مقاله در خصوص چگونگي جمع آوري نيازمنديها و روشهاي برتر در استخراج نيازمنديها مي باشد. نويسنده مطلب تحقيقات زيادي بر روي مطالب نوشتاري مرتبط نموده و نهايتا با تركيب آن با تجارب عملي بكاربرده شده در ده ها پروژه ، اين مطالب را به نگارش در آورده است.در قسمتي از مقاله روشهاي توصيه شده درباره جمع آوري نيازمنديها آورده شده است.

تكنيك هاي جمع آوري نيازمنديها :

در ذيل يك مجموعه از تكنيكهاي استخراج نيازمنديها كه توصيه شده ، معرفي گرديده است در ميان بيش از 40 تكنيك موجود ، تنها كارايي بالاي تعدادي از آنها اثبات گرديده است.اين تكنيكها مي تواند بصورت تركيبي بكار رود.مزيت اين روشها ، كارايي در استخراج نيازهاي واقعي بوده كه توسعه برنامه ريزي شده را باعث مي گردد.

معرفي يك عقيده ابتكاري : براي آشنايي با يك روش ابتكاري استخراج نيازمنديها به مقاله اي تحت عنوان "A Quick,Accurate Way to Determine Customer Needs" مراجعه نماييد. نويسندگان مقاله بر اين عقيده اند كه مشتريان در طول مدت استخراج نيازمنديها چيزهايي را مي گويند و سپس در مرحله عمل كاملا متفاوت از آنچه گفته اند عمل مي نمايند.آنها احساس مي كنند كه اين مشكل عمدتا به خاطر تكيه نمودن بر روشهاي سنتي استخراج نيازمندي ها ، نظير مصاحبه و مميزي و بازديد محيط و گروه ها مي باشد زيرا اين روشها نمي توانند با تناقضات موجود در پاسخهاي افراد ، بصورت موثر سروكار داشته باشند.

نويسندگان از يك تكنولوژي جديد با عنوان Imprint Analysis طرفداري مي نمايند. Imprint به مجموعه اي از وابستگي ها و احساساتي كه بصورت ناخودآگاه با يك كلمه ، مفهوم و يا تجربه ، قرين مي باشند گفته مي شود. آنها بر اين باورند كه اين روش منجر به يافتن نتايجي مي شود كه با گذشت زمان تغيير نمي كند زيرا احساسات انساني را نيز به حساب آورده است. احساسات علت اعمال مي باشند. نويسندگان اعتقاد دارند كه Imprint Analysis واقعا توانايي پيش بيني رفتار مشتريان را داراست.

 

يك تذكر اخطاري :

كليه كساني كه در يك پروژه درگير مي باشند مي بايد از يك مجموعه از متدها و تكنيك هاي مشترك استفاده نمايند. براي اين امر مقتضي است كه جلسات بحث و گفتگو و همچنين جلسات آموزشي لازم را ، به منظور استقرار خط و مشي پروژه برگزار نماييد. در پروژه ها بايد از متدها و تكنيك هايي كه قبلا بصورت موفقيت آميز در سازمان بكار رفته اند استفاده نمايند.اگر هيچ تجربه اي در اين زمينه وجود نداشته ، لازم است يك نيروي خارج از سازمان كه داراي تجارب موفق قبلي است را بكار گيريد.من قويا توصيه مي كنم كه افرادي را در پروژه درگير نماييد كه تجارب  موفق قبلي در خصوص بكارگيري كليه متدها و تكنيك هاي مورد استفاده داشته باشد. برگزاري جلسات آموزش رسمي براي توسعه دهندگان سيستم ، كه لازم است از متدها و ابزارهاي جديد استفاده نمايند يك سرمايه گذاري ارزشمند محسوب مي شود.

 

ابزارهاي اتوماتيك سازي مديريت نيازمنديها :

من توصيه مي كنم از يك ابزار اتوماتيك سازي مديريت نيازمنديها براي پشتيباني فعاليتهاي مرتبط با توسعه سيستم با هر اندازه اي ، استفاده نماييد. پروژه هاي كوچك ممكن است بوسيله نرم افزارهاي MS Word و MS Excel پوشش داده شوند اما بيشتر پروژه ها به ابزارهاي سازماني قدرتمندي نظير DOORS ، Requisite Pro و يا Caliber RM كه قابليتهاي بيش از يك مدير نيازمنديها دارند نياز خواهند داشت.

استفاده از يك ابزار ، فرايند استخراج نيازمنديها را تسهيل مي نمايد زيرا امكان فهم بهتر نيازمنديها را براي مشتريان و توسعه دهندگان فراهم مي نمايد. همچنين ، يك ابزار كارا كمك شاياني به اين موارد مي نمايد : اولويت بندي نيازها ، قابليت رهگيري نيازها در طول مدت توسعه ، امكان تخصيص چند صفت به هر نيازمندي و تسهيل مديريت تغيير نيازمندي ها

 

نتيجه گيري و توصيه ها :

سعي نكنيد كه كليه كارها را به تنهايي انجام دهيد در عوض افراد تيم پروژه را به انتخاب و تعهد به چندين روش كه برايشان قابل قبول است تشويق نماييد.

چند معيار كه قابليت ارزيابي كارايي اجرا و همه گير بودن روش انتخاب شده را داشته باشد انتخاب نماييد به خاطر داشته باشيد كه هر چيزي كه اندازه گيري و رهگيري مي شود امكان بهبود را داراست. يك تلاش متمركز براي بهبود ارتباطات و كار تيمي را سازماندهي نماييد.يك تيم متعهد و با انگيزه توانايي انجام هر چيزي را دارد.

 

منبع : اين مقاله توسط Dr. Ralph R. Young از موسسه Northrop Grumman Information Technology نوشته شده است.

 

خوب دوستان اينم از اين مقاله – در مقالات بعدي نيز با باشيد.

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت

 

 

 

بنام خدا

با سلام

اين مقاله در خصوص چگونگي جمع آوري نيازمنديها و روشهاي برتر در استخراج نيازمنديها مي باشد. نويسنده مطلب تحقيقات زيادي بر روي مطالب نوشتاري مرتبط نموده و نهايتا با تركيب آن با تجارب عملي بكاربرده شده در ده ها پروژه ، اين مطالب را به نگارش در آورده است.در قسمتي از مقاله روشهاي توصيه شده درباره جمع آوري نيازمنديها آورده شده است.

تكنيك هاي جمع آوري نيازمنديها :

در ذيل يك مجموعه از تكنيكهاي استخراج نيازمنديها كه توصيه شده ، معرفي گرديده است در ميان بيش از 40 تكنيك موجود ، تنها كارايي بالاي تعدادي از آنها اثبات گرديده است.اين تكنيكها مي تواند بصورت تركيبي بكار رود.مزيت اين روشها ، كارايي در استخراج نيازهاي واقعي بوده كه توسعه برنامه ريزي شده را باعث مي گردد.

 

در مقاله قبلي چند روش شرح داده شد در اين مقاله تكنيك هاي ديگري را معرفي مي نماييم

 

نمونه سازي (Prototyping) : نمونه سازي ، تكنيكي براي ساخت سريع و ايجاد  نسخه تقريبي از سيستم مورد نياز و يا قسمتهايي از آن مي باشد.نمونه سازي تصويري از قابليتهاي سيستم را به كاربران و طراحان ارائه  مي دهد.اين تكنيك بصورت يك مكانيزم ارتباطي عمل مي نمايد بطوري كه كارشناسان با كمك آن فعل و انفعالات با سيستم را درك مي نمايد.

براي داشتن اطلاعات كاملتر در خصوص ايجاد و استفاده از مدل سازي به مقاله "Sommerville software engineering" مراجعه نماييد. اين تكنيك مي تواند بصورت موثري با ساير متد ها نظير JAD و Models تركيب گردد.

 

مورد كاربري ((Use Cases : يك Use Case تصويري از عملياتي كه سيستم (با تقابل با ايفا كننده آن عمل) انجام مي دهد را ارائه مي دهد. اين تصوير مي بايد با توضيحات كامل متني همراه باشد. همچنين اين تكنيك نبايد به تنهايي بكار رود. بسياري از توسعه دهندگان بر اين باورند كه Use Case ها و سناريو ها (Scenaries) (شرح توالي وقايع مربوط به Use Case) ارتباط بين افراد تيم را تسهيل مي نمايد. آنها با بيان توالي وقايع و عمليات مرتبط با يك نيازمندي ، فهم روشني از حالات مختلف را فراهم نموده و همچنين بصورت يك زبان مشترك بين كاربران و تيم فني ، عمل مي نمايد.

توجه داشته باشيد كه Use Case ها به تنهايي دربرگيرنده اطلاعات كافي براي كليه فعاليتهاي توسعه سيستم نمي باشد بنابراين لازم است از تكنيك هاي ديگر نيز در امتداد Use Case ها استفاده نماييد.

 

توجه : با انجام پروژه هاي مختلف و با بررسي روشهاي متنوع ، به نظر من يكي از بهترين و كاراترين روشها در فاز جمع آوري نيازمنديها و همچنين فاز تجزيه و تحليل سيستم استفاده از Use Case هاي توصيفي و يا همان سناريوها مي باشد. البته لازم است كمي اطلاعات جانبي به فرمت خود اضافه نماييد تا در برگيرنده اطلاعات تكميلي كه در فازهاي آتي (نظير توسعه سيستم) بكار مي رود نيز باشد. در مقالات كاملي سعي خواهم نمود اطلاعات مفصلي در خصوص دلايل برتري Use Case هاي توصيفي بر تصويري ، روشهاي برتر در نوشتن سناريوها ، الگوهاي Use Case نويسي و ... را گردآوري نموده و همچنين با مثالهاي متنوع و مربوط به پروژه هاي واقعي اين روش را معرفي نمايم.

 

 Ivy Hooks مشاور استخراج نيازمنديها توصيه كرده تا از مستند مفاهيم عملياتي (Operational Concepts) بعنوان روشي ساده و مقرون به صرفه براي ايجاد اجماع بين كليه ذينفعان سيستم استفاده نموده و همچنين با اين روش دو طبقه عمده خطاهاي استخراج نيازمنديها يعني نيازهاي از قلم افتاده و نيازمنديهاي متناقض را مديريت نماييد. مفاهيم عملياتي (Operational Concepts) شانس اعتبار سنجي را در همان مراحل اوليه فراهم نموده و شالوده لازم براي سناريو هاي تست محصول را ، بنا مي نمايد.

 

توجه : براي فهم بهتر Operational Concepts به تعريف ارائه شده ذيل توجه نماييد :

 

Operational Concept Description :

The Operational Concept Description (OCD) describes a proposed system in terms of the user needs it will fulfill, its relationship to existing systems or procedures and the ways it will be used
The OCD is used to obtain consensus among the acquirer, developer, support, and user agencies on the operational concept of a proposed system.

 

 

 

منبع : اين مقاله توسط Dr. Ralph R. Young از موسسه Northrop Grumman Information Technology نوشته شده است.

 

خوب دوستان اينم از اين قسمت – در قسمت بعد ادامه تكنيك ها را با هم مرور خواهيم نمود.

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت

 

 

بنام خدا

با سلام

اين مقاله در خصوص چگونگي جمع آوري نيازمنديها و روشهاي برتر در استخراج نيازمنديها مي باشد. نويسنده مطلب تحقيقات زيادي بر روي مطالب نوشتاري مرتبط نموده و نهايتا با تركيب آن با تجارب عملي بكاربرده شده در ده ها پروژه ، اين مطالب را به نگارش در آورده است.در قسمتي از مقاله روشهاي توصيه شده درباره جمع آوري نيازمنديها آورده شده است.

قسمتي از فرايند جمع آوري نيازمنديها ، اولويت بندي آنها مي باشد. اين موضوع از آنرو حائز اهميت است كه بندرت زمان و بودجه كافي براي انجام تمام آنچه درخواست شده ، وجود دارد.

بهتر است بر روي فوايد سيستم تمركز نموده ، نه به شكل ظاهري و خصوصيات غير ضرور . فوايد به نيازمنديهاي ضروري اطلاق مي شود.اضافه نمودن خواص غير ضروري منجر به افزايش مشكلات در زمان طراحي و افزايش هزينه ها مي شود.

طبق ارزيابي هاي صورت گرفته 85% از عيوب در توسعه نرم افزار از شناخت نيازمنديها نشات گرفته است.در حالتي كه عيوب در داخل نيازمنديها جاي گرفته اند به سختي قابل زدودن مي باشند. در اينحالت ، عيوب به سختي در فرايند تست شناسايي مي شوند.بنابراين آموزش مهندسين و تحليل گران نيازمنديها به منظور اجتناب از انواع خطاهاي متداول ، ضروري مي باشد.

خطاهاي متداول در اين فاز عبارتند از فرضيات غلط (49%) ، نيازهاي از قلم افتاده (29%) ، نيازهاي متناقض (13%) ، نيازهاي مبهم (5%)

از روشهايي نظير مرور دو جانبه (Peer Reviews) (هر كس كار نفر ديگر را ارزيابي نمايد) و بازبيني مجدد در راستاي كاهش عيوب استفاده نماييد. اين روشها بهترين روش در كاهش عيوب مي باشند. توصيه من ، استفاده از مرور دوجانبه در كليه مستندات پروژه مي باشد. ميزان بكارگيري مرور به ميزان بحراني بودن مستند وابسته مي باشد.مرورهاي دوجانبه روش بسيار موثري در كاهش هزينه هاي پروژه مي باشند زيرا آنها منجر به كشف سريعتر عيوب مي گردند.طبق ارزيابي ها ، 45% هزينه پروژه ها به خاطر دوباره كاري ها مي باشد.با استفاده از مرور دوجانبه ، نوشتن سناريوي كارها و تهيه نمونه هايي اوليه از محصولات به ارزيابي صحت نيازها كمك نموده كه نهايتا منجر به مشخصات نيازمنديهاي دقيقتر و رضايت بيشتري مشتري خواهد گرديد.

بازرسي (Inspection) ،نوع پيشرفته تري از مرور دو جانبه مي باشد كه بايد از جانب ارائه كنندگان نيازمنديها مورد توجه قرار گيرد.يك راهنماي بسيار عالي در زمينه بازرسي هر نوع مستند ، توسط دو نفر به نامهاي Gilb و Graham تهيه گرديده است. توانايي انجام بازرسي به روش Gilb نيازمند پنج روز آموزش رسمي و همچنين دقت زياد مي باشد. يك مزيت روش Gilb استفاده از نمونه از محصول نهايي به جاي ارزيابي كل محصول مي باشد. در اين روش عقيده بر اين است كه با مشخص شدن عيوب در نمونه اوليه و يا چند صفحه اول مستند ، نگارنده قادر است بازخورهاي دريافتي را بكاربرده و بتواند مشكلات مشابه را در كل مستند و يا محصول عملياتي رفع نمايد.

بعضي ها معتقدند كليه نيازمنديها مي بايست در يك مستند با عنوان مشخصات نيازمنديهاي نرم افزاري آورده شود. تجارب نشان داده است كه داشتن چند مستند كه شامل مشخصات نيازمنديها باشد مي تواند كمك شاياني نمايد. مستنداتي نظير محدوده پروژه ، ليست نيازمنديها و ساير ليست ها يا نوشته هايي كه توسط مشتريان و كاربران تهيه گرديده است.بطور مثال نمونه اي از اين ليست ها عبارتند از نيازمنديهايي كه توسط سيستم ها قبلي (موجود) پوشش داده شده اند و يا نيازمنديها واقعي كه توسط مدير و مهندس جمع آوري نيازمنديها تهيه گرديده است.

يكي از بزرگترين موضوعات مشكل ساز ، تمركز بر كار بيش از حد ، در راستاي افزايش هر چه بيشتر نيازمنديها به جاي آدرس دهي حداقل نيازمنديهاي كافي (پوشش دهنده نيازهاي واقعي) ، مي باشد.بنابراين ، حداقل نيازمنديهايي كه به نحو شايسته شناسايي شده باشند در نهايت به نفع مشتري مي باشد آنها كمك مي نماند تا از مشكلاتي نظير تاخير در تحويل ، كسري بودجه ، كاهش انگيزه كاربران و كيفيت نازل ، جلوگيري گردد.

 

روشهاي توصيه شده در جمع آوري نيازمنديها :

در ذيل يك ليست از روشهايي كه در جمع آوري نيازمنديها توصيه گرديده ، آمده است.آنها بر اساس مطالعات گسترده اي كه نويسنده داشته و تركيب آنها با تجارب عملي تحليل گراني كه در چندين پروژه مشاركت داشته اند تهيه گرديده است.

1. يك مستند محدوده و چشم انداز سيستم (Vision and Scope Document) تهيه نماييد.
2. يك واژه نامه براي پروژه خود ايجاد نموده و در آن تعريف و معناي كليه لغات بكار رفته را بياوريد اين تعريف مي بايست مورد قبول و استفاده مشتريان ، كاربران و توسعه دهندگان نرم افزار باشد.همچنين يك ليست از كلمات اختصاري (Acronyms) كه مي تواند موجب راحت تر نمودن ارتباطات گردد تهيه نماييد.
3. نيازها را طي يك  كار تيمي با مشاركت مشتريان/كاربران و توسعه دهندگان شناسايي نماييد.بر روي نيازهاي ضروري تمركز نماييد نه فرم ظاهري و نيازهاي غير ضروري . بر روي نيازهاي با اولويت بالا و حداقل نيازهاي كافي سرمايه گذاري نماييد تا نيازهاي واقعي مشتريان و كاربران برآورده شود.
4. منشا و علت هر نيازمندي را نيز مستند نمايد.
5. آموزشي براي تحليل گران نيازمنديها و مشتريان و كاربراني كه بيشتر درگير خواهند بود ترتيب داده به نحوي كه موارد ذيل را پوشش دهد :
   1. نقش و مسئوليت هاي تحليل گر نيازمنديها ، بطور مثال جمع آوري نيازمنديها با كمك مشتريان و كاربران صورت پذيرد نه اينكه بصورت انفرادي و مستقل ، نيازها را اختراع نماييد.
   2. چگونگي نوشتن و مستند نمودن نيازمنديها
   3. انواع خطاهاي متداول در تهيه نيازمنديها و روشهاي كاهش آنها
   4. تاكيد بر اهميت سرمايه گذاري بيشتر براي فرايند شناخت نيازمنديها
   5. تشريح چگونگي فرايند شناخت نيازمنديها كه در پروژه جاري بكار گرفته خواهد شد.
   6. توضيح روشها و تكنيك هايي كه بكار خواهيم برد.
   7. روش استفاده از ابزارهايي كه به خودكار سازي فرايند مستندسازي نيازمنديها كمك خواهند نمود.
   8. عمليات معتبر سازي (Validation) و رسيدگي و بازبيني (Verification) در حين شناخت و تعيين نيازمنديها
6. ايجاد مكانيزمي جهت كنترل تغييرات در نيازمنديها و يا نيازمنديهاي جديد
7. اولويت بندي نيازمنديها در راستاي تعيين مواردي كه مي بايست در اولين نسخه نرم افزار وجود داشته و آن دسته از نيازها كه مي توانند در آينده ايجاد شوند.
8. در مواردي كه نيازمنديها مدام در حال تغييرند (و حتي در مواردي  كه نيستند) ، از يك روش توسعه افزايشي (مانند RUP) استفاده نماييد.اين رويكرد بخاطر آنست كه تعدادي از نيازمنديها تا هنگامي كه مشتريان و كاربران شروع به كار با سيستم نمايند ناشناخته مي باشد.
9. در روال تهيه كليه مستند مرتبط با نيازمنديها از مرور دو جانبه و بازرسي استفاده نماييد.
10. از يك ابزار قوي خودكار سازي مستند نمودن نيازمنديها ، استفاده نماييد.
    1. به هر نيازمنديها خواص آن را نسبت دهيد.
    2. امكان رهگيري نيازها را فراهم نماييد.
    3. تاريخچه هر نيازمندي را نگهداري نماييد.
11. از روشهايي در جمع آوري نيازمنديها استفاده نماييد كه در سازمان شناخته شده بوده و قبلا صحت آنها اثبات شده است نظير تشكيل كارگاه ها (Workshops)، نمونه سازي (prototyping)و StoryBoards
12. نفرات تيم را مشخص نماييد (از جمله تحليل گر نيازها) بنحوي كه در موضوع و محدوده پروژه خبره باشند.
13. پروژه و روش سازماني پروژه را بر اساس كاربرد مناسب سياست ها ،‌فرايندها ، متدها ، تكنيك ها و ابزار ، پايه گذاري نماييد.مكانيزمي را جهت كار تيمي ترتيب دهيد بنحوي كه اطلاعات پروژه اشتراكي بوده و همواره از روشها و تجربيات برتر (Best Practices) در كار استفاده شود.
14. فرهنگ كار را بنحوي پايه گذاري نماييد كه بهبود مستمر ، روش كار گروهي و كيفيت ، خصوصيات آن باشد.
15. در طول مدت توسعه ، شتريان و كاربران را درگير نماييد.
16. فعاليتهاي ارزيابي و اعتبار سنجي را به منظور اطمينان از اينكه هر نيازمندي قابل تست مي باشد صورت دهيد.(در حين فرايند جمع آوري نيازمنديها)

 

منبع : اين مقاله توسط Dr. Ralph R. Young از موسسه Northrop Grumman Information Technology نوشته شده است.

 

خوب دوستان اينم از اين قسمت – در قسمت هاي بعد ادامه مطلب را با هم مرور خواهيم نمود.

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت

 

 

بنام خدا

با سلام

اين مقاله در خصوص چگونگي جمع آوري نيازمنديها و روشهاي برتر در استخراج نيازمنديها مي باشد. نويسنده مطلب تحقيقات زيادي بر روي مطالب نوشتاري مرتبط نموده و نهايتا با تركيب آن با تجارب عملي بكاربرده شده در ده ها پروژه ، اين مطالب را به نگارش در آورده است.در قسمتي از مقاله روشهاي توصيه شده درباره جمع آوري نيازمنديها آورده شده است.

دخيل نمودن مشتريان و كاربران سيستم در كل مدت زمان توسعه سيستم ، منجر به شناسايي و فهم بهتر نيازهاي واقعي مي گردد. توجه نماييد كه فعاليت هاي مرتبط با نيازمنديها مي بايست در كل مدت توسعه سيستم صورت پذيرفته و تنها مختص به شروع پروژه نباشد.

مستند نيازمنديها يكي از اجزاي ضروري در يك سيستم بوده و مستندي مي باشد كه بيانگر قابليت ها ، مشخصات و فاكتورهاي كيفي يك سيستم مي باشد كه براي كاربران ارزشمند و كاربردي مي باشد. به گفته Steve McConnell در مقاله اي با عنوان راهنماي بقاي پروژه نرم افزاري "مشكل ترين قسمت در جمع آوري نيازمنديها ، مستند سازي نياز كاربران نمي باشد. بلكه سخت ترين قسمت عبارتست از كمك كردن به كاربران براي تعيين نيازمنديها به نحوي كه بتوان آنرا بصورت موفقيت آميز با توجه به هزينه و زمان در دسترس تيم توسعه ، عملياتي نمود."

هر نياز مي بايست ضروري ، قابل بازبيني ، امكان پذير و شدني ، واضح ، صريح و بدون هر گونه ابهام ، كامل (جامع باشد) ، سازگار ، قابل پيگيري ، مختصر (مانع باشد) ، مستقل از روش پياده سازي و داراي يك شناسه منحصر به فرد باشد.

 لازم به ذكر است معني دقيق اين عبارات در مقالات قبلي در خصوص نيازمنديها آمده است

مقالات مرتبط :

کاهش ریسک پروژه ها با استخراج صحیح نیازمندیها بوسیله مثال - قسمت اول

 

کاهش ریسک پروژه ها با استخراج صحیح نیازمندیها بوسیله مثال - قسمت دوم

 

کاهش ریسک پروژه ها با استخراج صحیح نیازمندیها بوسیله مثال - قسمت دوم

 

علت اينكه نيازمنديها مي بايد  مستقل از پياده سازي باشد آنست كه نيازمندي بيانگري چيزي است كه بايد وجود داشته باشد و نه چگونگي پياده سازي آن – چگونگي يكي از جنبه هاي طراحي مي باشد.

مستند نمودن منشا و علت هر نيازمندي يك روش خوب براي كاهش تعداد نيازمندي ها مي باشد با استفاده از اين تكنيك شما مي توانيد تا 50% ليست نيازمنديها را كم نماييد (منبع Ivy Hook's experience)

 

اولين مرحله، درك و شناخت نيازهاي تجاري و كاري سازمان مي باشد .اين فعاليت ، منجر به ايجاد مستند Vision and Scope (در خصوص اين مستند نيز در مقاله اول و دوم همراه با مثال صحبت شده است) مي گردد كه شامل شرح پس زمينه ها و دلايلي كه منجر به تصميم گيري در خصوص توسعه يك سيستم جديد و يا اصلاح سيستم موجود گرديده ، بوده و همچنين شامل قابليت هاي مورد نظر و شرحي از سيستمي كه مي بايد توسعه يابد ، مي باشد.

مقالات مرتبط با مستند محدوده سيستم (Vision and Scope Document) :

 

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت اول

پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت دوم

 پیش نیازها ، انتظارات ، اهداف و محدوده پروژه هاي نرم افزاري - قسمت سوم(آخر)

 

اطمينان از فهم و شناخت قابليت ها يك موضوع بحراني در موفقيت پروژه مي باشد.در اين راستا جلسات مربوط به محدوده و اهداف سيستم را بصورت مستمر با حضور مشتريان و كاربران سيستم برگزار نماييد. فرايند استخراج نيازمنديها منجر به تفكر خلاقانه و جزيي تر در خصوص موضوعات مطرح ، شده و نهايتا مي تواند محدوده پروژه را تحت تاثير قرار دهد. همينطور كه راه حل هايي جديد از لحاظ امكان پذيري بررسي مي شوند نقاط تصميم گيري مختلفي وجود دارند كه مي بايست در خصوص گنجاندن يا عدم گنجانيدن آنها در محدوده سيستم تصميم گيري نمود.

 

مرحله بعد جمع آوري نيازهاي جديدي است كه توسط مشتريان و كاربران سيستم بيان گرديده است. در يك روش كاراي جمع آوري نيازمنديها ، بايد به روش مناسبي اينگونه نيازها (كه  هنوز صحت آنها مشخص نشده است ) از نيازهاي واقعي قابل تشخيص باشد. تجارب نشانداده كه اينگونه نيازها بايستي بصورت مشاركتي توسط مشتريان و توسعه دهندگان سيستم ارزيابي گرديده تا از صحت آن اطمينان حاصل گردد.

 

منبع : اين مقاله توسط Dr. Ralph R. Young از موسسه Northrop Grumman Information Technology نوشته شده است.

 

خوب دوستان اينم از اين قسمت – در قسمت هاي بعد ادامه مطلب را باهم مرور خواهيم نمود.

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت

 

بنام خدا

با سلام

يكي از مشكلات بزرگي كه در برنامه هاي كاربردي مشاهده مي شود باگها و يا غير قابل اطمينان و يا متناقض بودن نتايج عمليات و يا گزارشات سيستم مي باشد كه در بسياري موارد نتيجه طراحي غير اصولي بانك اطلاعاتي برنامه كاربردي بوده و هزينه هاي زماني و ريالي زيادي جهت پشتيباني اينگونه نرم افزارها مورد نياز است در اين سري مقالات سعي مي گردد با زباني ساده و روان روش طراحي بانك اطلاعاتي رابطه اي شرح داده شود و در اين مسير مثالهاي متعددي آورده شده است.

منبع : این مطالب از سایت مایکروسافت بوده که در مواردی موضوعات را بیشتر شرح داده و یا مثالهایی را به آن اضافه نموده ام همچنین اصل مقاله مرتبط با بانک اطلاعاتی اكسس بوده كه سعي شده موضوعات كلي تر شده و در مثالها از بانك SQL Server استفاده شود.

 

در اين بخش به مرحله آخر طراحي بانك يعني ارزيابي و تصحيح طراحي صورت گرفته مي پردازيم

 

پالايش طراحي صورت گرفته :

بعد از اين كه ما جداول ، فيلدها و ارتباط مورد نياز را در طراحي خود گنجانديم نوبت به مرور طراحي و يافتن هر نوع عيبي كه ممكن است باقي مانده باشد مي رسد.

براي اين منظور جداول خود را ايجاد نموده ، ارتباطات بين آنها را برقرار و سپس در هر يك از جداول چند ركورد اطلاعات وارد نماييد.حال بررسي نماييد كه آيا اين بانك توانايي پاسخگويي به تمام خواسته هاي(نيازمنديهاي اوليه) شما را داراست . در اين مرحله همچنين اطلاعات تكراري را يافته و آنها را حذف نماييد.

در حين آزمايش بانك اطلاعاتي طراحي شده ، احتمالا به مواردي بر مي خوريد كه نياز به بهبود دارند.در اينجا يكسري موارد براي بررسي آورده شده است :

• آيا فيلد هايي را از قلم انداخته ايد ؟ آيا اطلاعاتي وجود دارد كه شما به آن نيازمنديد ولي در حال حاضر وجود ندارد ؟ اگر اينطور است آيا آن متعلق به جداول موجود مي باشد؟ اگر اين اطلاعات مرتبط با چيز ديگري است ممكن است نياز باشد تا جدول جديدي ايجاد نماييد.
• آيا براي كليه جداول كليد اصلي انتخاب نموده ايد؟در صورتي كه از اين كليد اصلي براي جستجوي ركوردها استفاده مي شود آيا نوع آن صحيح بوده و همچنين از بر نمودن آن راحت مي باشد؟مطمئن شويد شما تحت هيچ شرايطي نياز به وارد نمودن داده تكراري در آن نخواهيد شد.
• آيا شما بطور مكرر در يكي از جداولتان داده هاي تكراري وارد مي نماييد؟اگر اينطور است احتمالا شما نياز داريد تا آن جدول را به دو جدول كه با هم رابطه يك به چند دارند تقسيم نماييد.
• آيا شما جداولي با تعداد فيلدهاي زياد ، تعداد ركورد(اطلاعات) كم و تعداد زيادي فيلد كه در ركوردهاي مختلف خالي مي مانند داريد ؟ اگر اينطور است در خصوص طراحي مجدد جدول مذكور اقدام نماييد بطوريكه تعداد كمتري فيلد داشته و ركورد هاي بيشتري داشته باشد.

مثال : بهبود جدول محصولات (Products)

هر محصول در شركت Northwind در قالب يك طبقه بندي كلي نظير نوشيدني ها ، ادويه ها و غذاهاي دريايي و ... قرار دارد. جدول محصولات شامل فيلدي است كه بيانگر طبقه هر كدام از محصولات مي باشد.

فرض نماييد كه در مرحله بررسي و بهبود طراحي ، شركت خواهان افزوده شدن توضيحاتي در خصوص هر طبقه گردد (يعني فيلد توضيحات علاوه بر فيلد طبقه بندي اضافه شود كه در فيلد توضيحات شرحي در خصوص طبقه مربوطه آورده شود)

اگر شما يك فيلد با عنوان توضيح طبقه (Category Description) به جدول محصولات (Products) اضافه نماييد شما مجبور خواهيد شد فيلد توضيح طبقه را بصورت تكراري براي هر محصولي  كه در آن طبقه قرار مي گيرد وارد نماييد كه به هيچ وجه روش مناسبي نمي باشد.

روش مناسبتر آن است كه به طبقه بندي بصورت يك موضوع قابل پيگيري در بانك اطلاعاتي نگريسته و نسبت به ايجاد يك جدول جديد اقدام نماييد كه بالطبع داراي كليد اصلي مخصوص به خود مي باشد سپس شما مي توانيد اين كليد اصلي را به جدول محصولات (Products) تحت عنوان كليد خارجي اضافه نماييد.

 

 

جدول طبقه بندي ها (Categories) و محصولات (‍Products) يك ارتباط يك به چند دارند : هر طبقه مي تواند شامل محصولاتي مختلفي باشد اما هر محصول خاص تنها متعلق به يك طبقه خاص مي باشد. مثلا همانطور كه در شكل فوق مي بينيد در طبقه Beverages دو محصول Chai و Chang قرار دارند ولي هر محصول مثلا Chai فقط متعلق به طبقه Beverages مي باشد.

 

خوب دوستان اينم از اين مطلب

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت

 

بنام خدا

با سلام

يكي از مشكلات بزرگي كه در برنامه هاي كاربردي مشاهده مي شود باگها و يا غير قابل اطمينان و يا متناقض بودن نتايج عمليات و يا گزارشات سيستم مي باشد كه در بسياري موارد نتيجه طراحي غير اصولي بانك اطلاعاتي برنامه كاربردي بوده و هزينه هاي زماني و ريالي زيادي جهت پشتيباني اينگونه نرم افزارها مورد نياز است در اين سري مقالات سعي مي گردد با زباني ساده و روان روش طراحي بانك اطلاعاتي رابطه اي شرح داده شود و در اين مسير مثالهاي متعددي آورده شده است.

منبع : این مطالب از سایت مایکروسافت بوده که در مواردی موضوعات را بیشتر شرح داده و یا مثالهایی را به آن اضافه نموده ام همچنین اصل مقاله مرتبط با بانک اطلاعاتی اكسس بوده كه سعي شده موضوعات كلي تر شده و در مثالها از بانك SQL Server استفاده شود.

 

در اين بخش به ادامه مرحله پنجم (تعيين و تشخيص ارتباطات مورد نياز) خواهيم پرداخت.

در اين جا نحوه تعيين و تشخيص ارتباطات بين جداول و همچنين چگونگي تشخيص فيلدهايي كه اين ارتباطات را پشتيباني مي نمايد شرح داده شده است.براي ايجاد و برقراري ارتباط بين جداول در MS SQL Server از قسمت Diagrams در بانك اطلاعاتي مورد نظر خود مي  توانيد استفاده نماييد.

ايجاد يك ارتباط يك به چند (One-to-Many or 1:N) : ارتباط يك به چند متداولترين نوع ارتباط در بانك هاي رابطه اي مي باشد.در اين ارتباط ، يك ركورد در جدول A مي تواند چند ركورد متناظر و مرتبط در جدول B داشته ولي يك ركورد در جدول B فقط و فقط يك ركورد متناظر در جدول A دارد.

بطور مثال ، جداول تامين كنندگان (Suppliers) و محصولات (Products) در بانك اطلاعاتي Northwind يك ارتباط يك به چند دارند.

به منظور برپايي اين ارتباط ، شما بايد فيلد يا فيلدهايي كه در جدول طرف اول ارتباط (one side) كليد اصلي مي باشند را به جدول طرف چندتايي ارتباط (many side) ، اضافه نماييد.در اين مثال شما بايد فيلد Supplier ID از جدول Supplier را به جدول Products اضافه نماييد زيرا يك تامين كننده ، تامين كننده چند محصول مي تواند باشد.بانك اطلاعاتي با توجه به فيلد Supplier ID در جدول Products توانايي يافتن محصولاتي كه توسط يك تامين كننده خاص ، تامين مي شود را دارا مي باشد.

 

 

همانطور كه در شكل فوق مشاهده مي نماييد تامين كننده شماره 1 يعني شركت Exotic Liquids تامين كننده سه محصول 1 : Chai و 2:Chang و 3 : Aniseed syrup مي باشد زيرا فيلد Supplier ID اين سه محصول در جدول Products برابر 1 مي باشد كه اين كد در جدول Suppliers

شركت Exotic Liquids را نشان مي دهد بديهي است فيلد Supplier ID در جدول Suppliers ، كليد اصلي (Primary Key) و در جدول Products ، كليد خارجي (Foreign Key) مي باشد.

 

ايجاد يك ارتباط چند به چند (Many-to-Many Or N:M) : در ارتباط چند به چند ، يك ركورد در جدول A بيش از يك ركورد متناظر در جدول B داشته و همچنين يك ركورد در جدول B مي تواند بيش از يك ركورد متناظر در جدول A داشته باشد. در اين نوع از ارتباط ، لازم است ابتدا طراحي بانك اطلاعاتي خود را تغييراتي داده تا بتوانيد بصورت صحيح اين نوع ارتباط را پوشش دهيد.براي يافتن ارتباط چند به چند بين جداول ، لازم است به دقت به هر دو سوي ارتباط بنگريد.

بطور مثال در شركت تجاري Northwind ، يك سفارش مي تواند شامل چندين محصول باشد لذا براي هر ركورد در جدول سفارشات (Orders) ، چندين ركورد در جدول محصولات (Products) مي تواند وجود داشته باشد. اما اين كل مطلب نيست زيرا هر محصول نيز مي تواند در سفارشات مختلف ظاهر شود لذا براي هر ركورد در جدول محصولات (Products) ، چندين ركورد در جدول سفارشات مي تواند وجود داشته باشد

در خصوص اين مثال بين دو جدول Orders و Products يك ارتباط چند به چند داريم و اين نشاندهنده يك مشكل در طراحي بانك اطلاعاتي مي باشد. براي فهم مشكل ، تصور كنيد براي برپايي اين ارتباط شما فيلد Product ID را به جدول سفارشات (Orders) اضافه نماييد در اينصورت چه اتفاقي خواهد افتاد‌ ؟

براي داشتن بيش از يك محصول در هر سفارش ، شما به بيش از يك ركورد براي هر سفارش در جدول سفارشات (Orders) نيازمنديد بنابراين براي هر سطر از سفارش كه متعلق به يك كالاست شما مي بايد كليه اطلاعات كلي سفارش –مانند شماره سفارش ، تاريخ سفارش ، خريدار و ...- را تكرار نماييد اين راه حل نمونه يك طراحي ضعيف مي باشد كه ما را به سمت داشتن داده هاي نادرست رهنمون مي سازد. حالت قرينه اين طراحي حالتي است كه شما فيلد Order ID را به جدول Products اضافه نماييد در اينحالت نيز مشكل وجود دارد زيرا شما مي بايست اطلاعات كلي محصول را به ازاي هر سطر سفارش در جدول محصولات (Products) تكرار نماييد.

روش صحيح حل اين مشكل چيست ؟

پاسخ ايجاد يك جدول جديد مي باشد كه ارتباط چند به چند موجود با واسطه جدول جديد به دو ارتباط يك به چند تبديل گردد در اينحالت شما كليد اصلي هر دو جدول را مي بايست به  جدول سوم ايجاد شده اضافه نماييد.

براي مثال فوق يك جدول با عنوان جزييات سفارش (Orde rDetails) به بانك اطلاعاتي افزوده مي گردد.هر ركورد در جدول جزييات سفارش (Order Details) نشاندهنده يك آيتم موجود در فرم سفارش مي باشد.كليد اصلي جدول جديد (Order Details) شامل دو فيلد مي باشد – كليد خارجي از جدول سفارشات (Orders) و محصولات (Products) – يعني فيلدهاي Order ID , Product ID

 

 

 

فيلد Order ID به تنهايي نمي تواند كليد اصلي اين جدول باشد زيرا هر سفارش مي تواند شامل چند آيتم باشد. فيلد Product ID نيز نمي تواند اين نقش را عهده دار گردد زيرا يك محصول مي تواند در سفارشات مختلف وجود داشته باشد ولي اجتماع اين دو فيلد هميشه يك مقدار منحصر به فرد را براي هر آيتم سفارش تشكيل مي دهند.

در بانك اطلاعاتي Northwind جداول سفارشات (Orders) و محصولات (Products) بصورت مستقيم با هم ارتباط نداشته بلكه از طريق جدول جزييات سفارش (Order Details) بصورت غير مستقيم با هم مرتبط مي باشند. همواره در بانك اطلاعاتي يك ارتباط چند به چند ، توسط دو ارتباط يك به چند پياده سازي مي گردد :

• جداول سفارشات (Orders) و جزييات سفارش (Orde rDetails) يك ارتباط يك به چند دارند زيرا هر سفارش مي تواند بيش از يك آيتم داشته باشد ولي هر آيتم موجود در يك سفارش تنها به همان سفارش مرتبط مي باشد.
• جداول محصولات (‍Products) و جزييات سفارش (Order Details) يك ارتباط يك به چند دارند زيرا هر محصول مي تواند در آيتمهايي از سفارشات مختلف وجود داشته باشد ولي هر آيتم سفارش تنها با يك محصول ارتباط دارد.

 

ايجاد يك ارتباط يك به يك (One-to-One or 1:1) :

در ارتباط يك به يك ، يك ركورد از جدول A نمي تواند بيش از يك ركورد متناظر در جدول B داشته باشد و همچنين يك ركورد در جدول B نمي تواند بيش از يك ركورد متناظر در جدول A داشته باشد. اين نوع از ارتباط غير معمول بوده و ممكن است منجر به تغييراتي در طراحي بانك اطلاعاتي شما گردد.

علت غير معمول بودن اين نوع ارتباط در اين است كه در بيشتر حالات ، اطلاعات اين دو جدول بسادگي قابل ادغام در يك جدول مي باشد. بطور مثال ، فرض كنيد شما يك جدول با عنوان PingPong در بانك اطلاعاتي Northwind اضافه نماييد كه شامل اطلاعات پرسنلي مي باشد كه در مسابقات پينگ پنك داخل شركت ، حضور مي يابند و در اين جدول اطلاعاتي نظير نام مستعار ، سطح بازي شخص ، زمان مناسب بازي و ... براي هر شخص ذخيره مي گردد يك راه اضافه كردن كليه فيلدهاي مورد نياز به جدول كارمندان مي باشد (Employees) ولي به دو دليل اين روش مناسب نمي باشد اول اينكه اطلاعات اين مسابقات مقطعي و موقت بوده و در آينده نيز كاربردي نخواهد داشت و دوم اينكه فيلدهاي اضافه شده براي بسياري از كارمندان خالي مي ماند زيرا تنها عده محدودي از كارمندان در مسابقات پينگ پنگ شركت خواهند كرد لذا ترجيح داده شده است كه جدول جديد اضافه گردد بديهي است ارتباط اين جدول با  جدول كارمندان يك ارتباط يك به يك مي باشد.

در حالتي كه شما دريافتيد كه به ارتباط يك يه يك در بانك اطلاعاتي خود نياز داريد ابتدا بررسي نماييد كه آيا ادغام اين دو جدول با هم منطقي مي باشد يا خير ، سپس در صورتي كه تصميم به جداسازي اين جداول گرفتيد شما براي برپايي ارتباط بين آنها ، به يكي از طرق ذيل مي توانيد اقدام نماييد :

• اگر دو جدول موضوع مشتركي دارند به احتمال زياد با استفاده از  كليد اصلي دو جدول كه يكسان مي باشند مي توانيد رابطه مذكور را ايجاد نماييد.
• اگر دو جدول موضوعات متفاوت با كليدهاي اصلي مختلفي دارند شما مي توانيد يكي از جداول را انتخاب كرده و كليد اصلي آنرا به جدول ديگر اضافه نماييد (كه در جدول ديگر كليد خارجي مي شود)

 

خوب دوستان اينم از اين قسمت – در قسمت بعد مطالب مرتبط با بازبيني و اصلاح طراحي بانك اطلاعاتي را با هم مرور مي كنيم.

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت