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

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

כלל הפרטים המרכיבים את החזון הזה שייצרו בסופו של דבר את התוכנה החדשה, הוא למעשה אפיון תוכנה או SRS – Software Requirements Specification.

אז מהו בעצם אפיון תוכנה?

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

• פונקציונליות התוכנה – מה התוכנה תעשה וכיצד?
• רמות ביצועים נדרשות – הגדרה מראש של ביצועי התוכנה הרצויים כמו מהירות הטעינה, קצב ריענון והתאוששות ויכולות העיבוד שלה.
• אילוצי תכנון – מערכות ההפעלה עליהן תוכל לרוץ התוכנה, שפות, שיקולי עיצוב ומאפיינים אחרים שעשויים להשפיע על חוויית המשתמש ושיש להתייחס אליהם בתהליך הפיתוח.
• שיקולי איכות נוספים: כלל הגורמים הלא פונקציונליים המשמשים להערכת ביצועי התוכנה, כגון עיצוב, אבטחה, ניידות, חוויית משתמש וכו’.

חשיבות מסמך SRS בתהליך פיתוח תוכנה

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

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

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

כאשר מנסחים SRS כהלכה, הסיכויים שיהיה עלינו לבצע שינויים בעיצוב ובתכנון ולתקן שלל טעויות אחרות של מתכנתים פוחתים באופן משמעותי.

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

SRS כאמצעים לתיאום ציפיות והבנות

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

רכיבים מרכזיים במסמך SRS

אלו כמה נקודות עיקריות שיופיעו ברוב המקרים במהלך כתיבת אפיון תוכנה.

מבוא ותיאור כולל

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

פונקציונליות

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

פלטפורמת הפיתוח וממשקי חומרה ומשתמש

האם תפותח עם Vue, React או אולי בכלל ב-Angular?
דרישות המערכת יכתיבו במידה רבה את הפלטפורמות שישמשו לפיתוח. זהו גם המקום להגדיר על אילו מכשירים תופעל התוכנה ובאילו סביבות הפעלה.

דרישות אבטחה

מפרט כלל פתרונות האבטחה שיעמדו לרשות המשתמשים.