פתרונות Visure


תמיכה
הירשם
התחברות
התחל ניסיון חינם

מעבר מדרישות טובות לדרישות גדולות

זום ספטמבר 29, 2022 מספר פעמים זמין חופשי

תוכן העניינים

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

מדוע פרויקטים של הנדסת מערכות נכשלים?

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

ניתוח איכות הפרויקט

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

מהו מפרט דרישות?

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

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

מפרט דרישות

תהליך הנדסת דרישות

הנדסת דרישות

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

  1. דרישות רישוי – זהו תהליך איסוף, סקירה והבנה של הצרכים והאילוצים של בעלי העניין והמשתמשים לעונה. משתמשים צריכים מידע על דומיין, מידע מערכת קיים, תקנות, תקנים וכו'. בהתבסס על מידע זה, אנו מעלים את הדרישות. לאחר מכן, אנו עוברים לניתוח דרישות ומשא ומתן. 
  2. ניתוח דרישות ומשא ומתן - ניתוח הוא תהליך של חידוד צרכי המשתמש ואילוצים על בסיס מידע שנאסף ומתקבל. לאחר מכן, אנו עוברים לפעילות התיעוד. 
  3. דרישות תיעוד/מפרט - לאחר קבלת מפרטי הדרישה, אנו עוברים לחלק התיעוד. אנו מתעדים את הצרכים והאילוצים של המשתמש בצורה ברורה ומדויקת. 
  4. אימות דרישות – לבסוף, בפעילות האימות, אנו מכניסים שדרישות העונה מלאות, תמציתיות וברורות. 
  5. ניהול דרישות – ניהול דרישות הוא דרך לאסוף, ניתוח, חידוד ותעדוף כל המוצרים או הדרישות, בשלב הפיתוח. בשלב זה נוצרת גם מעקב מוצק בין הדרישות ומקורות המידע. 

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

למה חשוב לכתוב דרישות טובות?

ישנם יתרונות רבים של מפרט דרישות טוב. כמה מהם מפורטים להלן:

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

מה אנחנו משיגים על ידי כתיבת דרישות גדולות?

יש הרבה דברים שדרישות גדולות עוזרות להשיג. כמה מהם מפורטים להלן:

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

אתגרים בעת כתיבה דרישות

ישנם אתגרים שונים שעומדים בפני אנשים בעת כתיבת דרישות.

כתיבה דרישות

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

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

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

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

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

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

אנליסטים עסקיים צריכים תמיד לזכור להפריד בין דרישות עיצוב ופונקציונליות בתיעוד שלהם. על ידי שימוש בכלים כלליים יותר כגון דיאגרמות, סיפורי משתמשים או אבות-טיפוס Low Fi ולא טיוטות עיצוב, הם יכולים לשמור על התמקדות בהיבטים הפונקציונליים של איסוף דרישות.

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

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

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

תקנים לדרישות כתיבה?

EARS תהיה מתודולוגיה יעילה כאן. זה מייצג Eאסי Aלגשת ל Rמשוואות Syntax, מאת אלאסטיר מרווין. בשיטה זו אנו כותבים שפה ברורה, תמציתית ומובנת. זה משפר את כל זרימת העבודה ההנדסית של הדרישות ומפשט את העבודה על ידי כך שהדברים קלים למדי להבנה. 

כדי להשיג זאת, הנה כמה עקרונות שיש לזכור בעת כתיבת הדרישות. הם כוללים:

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

רכיבים חיוניים של מסמך דרישות:

הסעיפים העיקריים של מפרט דרישות תוכנה הם:

  • עסקי נהגים – הסיבות לכך שהלקוח מחפש לבנות מערכת מתוארות בסעיף זה. סעיף זה כולל עוד את הבעיות שהלקוח מתמודד עם המערכת הנוכחית ואת ההזדמנויות שהמערכת החדשה תספק.
  • מודל עסקי – המודל העסקי שהמערכת אמורה לתמוך בו נדון בחלק זה. זה כולל עוד פרטים שונים כמו ההקשר הארגוני והעסקי, פונקציות עסקיות עיקריות ודיאגרמות זרימת תהליכים של המערכת.
  • דרישות פונקציונליות ומערכת – חלק זה מפרט בדרך כלל דרישות המאורגנות במבנה היררכי. הדרישות הפונקציונליות הן ברמה העליונה ודרישות המערכת המפורטות רשומות כתתי פריטי.
  • מקרי שימוש במערכת – סעיף זה מורכב מתרשים שימוש ב-UML (Unified Modeling Language) המסביר את כל הישויות החיצוניות המרכזיות שיקיימו אינטראקציה עם המערכת ואת מקרי השימוש השונים שהם יצטרכו לבצע.
  • דרישות טכניות – סעיף זה דן בכל הדרישות הלא פונקציונליות המרכיבות את הסביבה הטכנית ובמגבלות הטכניות שבהן התוכנה תפעל.  
  • איכויות מערכת – בסעיף זה מוגדרות האיכויות הרבות של המערכת כגון אמינות, שירות, אבטחה, מדרגיות, זמינות ותחזוקה.
  • מגבלות והנחות – כל המגבלות המוטלות על תכנון המערכת מנקודת מבטו של הלקוח מתוארות בסעיף זה. גם ההנחות השונות של צוות ההנדסה לגבי מה לצפות במהלך הפיתוח נדונות כאן.
  • קריטריונים לקבלה – פרטים על כל התנאים שיש לעמוד בהם לפני מסירת המערכת ללקוחות הסופיים נדונים בחלק זה.

מאפיינים של מסמך מפרט דרישות תוכנה:

פירוט דרישות תוכנה
  • נקה - דרישות הכתוב חייבות להיות ברורות, קלות לקריאה ומובנות. ציין בבירור את המידע באמצעות משפטים חיוביים שיש להחליף בין השחקנים. כל דרישה חייבת לתאר קריטריונים ברורים להצלחה. נסו להשתמש באוצר מילים פשוט והימנע מקיצורים. לדוגמה, "המשתמש יוכל להציג את דוח יומן הביקורת".
  • אטומי – יש להתייחס לכל דרישה כמקרה מבחן בדיד. אין להשתמש בצירופים כגון ו, או וכן הלאה מכיוון שהם עלולים להוביל להחמצת דרישות. זה חיוני במיוחד מכיוון שמונחים כאלה עלולים לגרום למפתחי תוכנה ולבודקים להתעלם מהדרישות. פיצול צרכים מסובכים לחלקים קטנים יותר עד שניתן לבדוק כל אחד מהם בנפרד היא אחת הדרכים למנוע את זה.
  • חד משמעית - דרישות לא ברורות, לא שלמות או סותרות עלולות להוביל לשגיאות ולעיבודים מחדש. כדי למנוע זאת, דרישות צריכות להיבדק על ידי כל מחזיקי עניין לפני שייגמרו באופן סופי. זה יעזור לזהות את הפערים בשלב מוקדם שניתן לטפל בהם.
  • ניתן לאמת – לכל צוות הפיתוח צריכה להיות גישה למסמך כדי שיוכלו להפנות אליו בתדירות הנדרשת. מכיוון שהדרישות חייבות להיות ברורות, חברי הצוות לא רוצים מידע נוסף. כולם צריכים להיות נגישים במסמך SRS.
  • הכרחי – כל דרישה חייבת לתעד משהו שהמשתמשים באמת צריכים או משהו שנדרש למלא צורך בתקן או אינטגרציה עקב קיומו של ממשק חיצוני. כמו כן, חשוב שלכל דרישה יהיה מקור מורשה.
  • עצמאי בעיצוב - כל דרישה חייבת להגדיר מה הכרחי, לא איך היא תיושם. הדרישות חייבות להגדיר את מאפייני המערכת שייבדקו מבחוץ, ולא את הפרטים הפנימיים.
  • אפשרי - כל דרישה חייבת להיות ניתנת לביצוע מבחינה טכנית ויש ליישם בהתחשב בתקציב, דדליין ומגבלות אחרות המשפיעות על הפרויקט. הדרישות צריכות לשקף את מצב העניינים בפועל, כולל עלות, ציר זמן וטכנולוגיה. הם לא צריכים להיות תלויים בהתקדמות טכנולוגית עתידית.
  • להשלים – מסמך הדרישות צריך לכלול מספיק מידע לצוות הפיתוח והבודקים שלך כדי להשלים את המוצר ולהבטיח שהוא עומד בדרישות המשתמש ללא באגים.
  • נכון - הדרישות המפורטות במסמכים צריכות להיות מדויקות מאוד כדי למנוע כל סוג של בלבול. אסור שיהיו להם פרצות, אי בהירות, סובייקטיביות, סופרלטיבים או השוואות. מכאן שכדי לכתוב דרישות נכונות, עלינו לקבל מידע נכון ולתעד נכון את המידע שנאסף.

כללים למערכת הדרישות הנכונות

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

  • להשלים – מסמך הדרישות צריך לכלול מספיק מידע לצוות הפיתוח והבודקים שלך כדי להשלים את המוצר ולהבטיח שהוא עומד בדרישות המשתמש ללא באגים.
  • עֲקֵבִיוּת - שמור על רמת פירוט עקבית. לדוגמה, עבור דרישות המשתמש, משתמש קצה צריך להיות הנושא של כל משפט. באופן דומה, עבור דרישות מערכת, מערכת צריכה להיות הנושא של כל משפט.
  • יכולת שינוי - הדרישות יכולות להשתנות לאורך מחזור החיים של הפרויקט. יש לאחסן את יומן הדרישות ולהתאפשר ניתוח של השפעת השינויים שנעשו בו על דרישות ומרכיבי פרויקט אחרים.
  • סדרי עדיפויות – יש לסווג את הדרישות מנקודת מבט של חשיבות. לא כל המאפיינים הרצויים למערכת חשובים באותה מידה. לשם כך, יועיל לקבוע כלל להגדרת סדרי עדיפויות של דרישות ברמה הארגונית ולהתאים אותה לכל פרויקט. ועבוד עם המשתמשים כדי שיוכלו לתעדף את הדרישות.

דרישות ה-Visure ALM Platform

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

קורסי הכלים של Visure

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

סיכום

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

אל תשכחו לשתף את הפוסט הזה!

תוכנת IBM Rational Doors
חולצות