ולידציה – ספציפיקציה פונקציונלית

ולידציה – ספציפיקציה פונקציונלית (Functional Specification)

ספציפיקציה פונקציונלית (Functional Specification) (שנקראת לפעמים ספציפיקציות פונקציונליות) היא מסמך פורמלי שמשמש לתיאור מדויק, עבור מפתחי התוכנה, את היכולות, המראה והאינטראקציה עם המשתמשים הנדרשים מהמוצר. הספציפיקציה הפונקציונלית היא סוג של קו מנחה ובהמשך נקודת יחוס עבור המפתחים שכותבים את קוד התוכנה. (לפחות קבוצת פיתוח אחת של מוצר עיקרי השתמשה בגישה “התחל מכתיבת המדריך”. לפני  קיום המוצר, המפתחים כתבו מדריך למשתמש עבור מערכת עיבוד האות, ואח”כ הצהירו שמדריך זה היה הספציפיקציה פונקציונלית.  המפתחים אותגרו לפתח מוצר שיתאים לתיאורים שהופיעו במדריך למשתמש). בצורה אופיינית, הספציפיקציה הפונקציונלית לתוכנית אפליקציה עם סדרה של חלונות אינטראקטיביות ודיאלוגים עם המשתמש אמורה להראות את הצורה הוויזואלית של ממשק המשתמש, ולתאר כ”א מפעילויות הכניסה האפשריות של המשתמש ופעילויות התגובה של התוכנית. הספציפיקציה הפונקציונלית יכולה גם לכלול תיאורים פורמליים של מטלות המשתמש, תלות במוצרים אחרים, וקריטריונים לשימוש. לחברות רבות יש מדריך למפתחים שמתאר איזה נושאים צריכים להיכלל  בספציפיקציה הפונקציונלית של כל מוצר.

כדי להמחיש את הצורה שבה הספציפיקציה הפונקציונלית משתלבת בתהליך הפיתוח, להלן סדרה אופיינית של צעדים שצריכים להיכלל בפיתוח מוצר תוכנה:

• דרישות: זו הצהרה פורמלית של מה שמתכנני המוצר, לפי ידיעתם על המצב בשוק ומידע ספציפי על של לקוחות קיימים או פוטנציאליים, מאמינים לגבי התכונות הנדרשות למוצר חדש או לוורסיה חדשה של מוצר קיים. דרישות אלו מוצגות בד”כ באופן יחסית כללי.
• מטרות: המטרות כתובות ע”י מתכנני המוצר בתגובה לדרישות. הן מתארות באופן יותר ספציפי את תכונות המוצר. המטרות יכולות לתאר את האדריכלות, פרוטוקולים וסטנדרטים שאליהם המוצר חייב להתאים.  מטרות שניתנות למדידה הן אלו שקובעות קריטריונים שלפיהם ניתן להעריך את המוצר הסופי.  אפשרות למדידה ניתנת לביטוי במונחי אינדקס של שביעות רצון הלקוח או במונחים של יכולות וזמני ביצוע. לצורך עמידה במטרות, חייבים לקחת בחשבון את מגבלות הזמן והמשאבים. לו”ז הפיתוח הוא בד”כ חלק או מסקנות מהמטרות.
• ספציפיקציה פונקציונלית: ספציפיקציה פונקציונלית היא התגובה הפורמלית למטרות. היא מתארת את כל ממשקי המשתמש החיצוני והתוכנה שבהם המוצר חייב לתמוך.
• בקשות לשינוי עיצוב: במשך תהליך הפיתוח, כאשר מופיע צורך לשינוי הספציפיקציה הפונקציונלית , שינוי פורמלי מתואר בבקשה לשינוי עיצוב.
• ספציפיקציה לוגית: מבנה התוכנה (לדוגמה, קבוצות עיקריות של מודולי קוד שתומכים בפונקציה דומה), מודולי קוד אינדיבידואלים והיחס ביניהם, ופרמטרים של נתונים שהם מעבירים ביניהם ניתנים לתיאור במסמך פורמלי שנקרא ספציפיקציה לוגית. מסמך זה מתאר את הממשקים הפנימיים, ומשתמשים בו רק המפתחים, בקרים, ובהמשך, במידה מסוימת, המתכנתים שעוסקים במוצר ומספקים תיקוני קוד לשדות.
• תיעוד למשתמש: באופן כללי, כל המסמכים הקודמים (חוץ מהספציפיקציה הלוגית) משמשים כחומר מקור עבור המדריכים הטכניים והמידע המקוון (online) (כגון דפי עזר) שמכינים עבור המשתמשים במוצר.
• תכנית בדיקה: לרוב קבוצות הפיתוח יש תכנית בדיקה פורמלית שמתארת דוגמאות בדיקה לצורך תרגול עם התוכנה שנכתבה. הבדיקה נערכת ברמת מודול (או יחידה), ברמת רכיב, וברמת מערכת בהקשר עם מוצרים אחרים. ניתן להתייחס לבדיקה כזו כ לבדיקת alpha. התכנית יכולה לאפשר גם בדיקת beta. חברות מסוימות מספקות וורסיה מוקדמת של המוצר לקבוצה נבחרת של לקוחות לצורך בדיקה “בעולם האמיתי”.
• המוצר הסופי: באופן אידאלי, המוצר הסופי הוד יישום מלא של הספציפיקציה הפונקציונלית והבקשות לשינוי עיצוב, שחלקם יכולות לנבוע מבדיקה פורמלית ובדיקת beta.

סדרת צעדים זו יכולה לחזור על עצמה בוורסיה הבאה של המוצר, החל מהצהרת הדרישות, שבאופן אידאלי מתייחסת למשוב חוזר מהלקוחות לגבי המוצר בשימוש, להחלטה על הצורך או רצון הלקוחות בהמשך.

רוב כותבי התוכנה דבקים לתהליך פיתוח פורמלי דומה לזה המתואר מעל. תהליך פיתוח החומרה דומה, אך מכיל שיקולים נוספים לביצוע מיקור חוץ ווידוא לתהליך היצור עצמו.

לפירוט נוסף בנושא  תוכנה מומלץ לקרוא גם את ולידציה – הבטחת איכות תוכנה – QA