המדריך השלם ביותר לניהול דרישות ועקיבות
הנדסת דרישות
תוכן העניינים
על מנת לייצר מוצר איכותי, חשוב שיהיו דרישות מדויקות מהלקוח. זה מתחיל בתהליך הנדסת הדרישות, אותו ניתן לחלק לחמישה שלבים: איסוף דרישות, תיעוד דרישות, ניתוח ואימות דרישות, ניהול שינויים בדרישות וסגירת שלב הדרישות. בפוסט זה בבלוג, נדון בכל אחד מהשלבים הללו בפירוט ונראה כיצד הם עוזרים לייצר מוצר באיכות גבוהה.
מהן הנדסת דרישות ודרישות?
יש כאן שני מונחים, "דרישה" ו"הנדסת דרישות". דרישה מוגדרת במדויק כתנאי או יכולת שמשתמש צריך כדי לפתור בעיה או להשיג מטרה. במילים אחרות, דרישות הן תנאים או יכולות שמערכת חייבת לעמוד בהן או להחזיק בהן כדי לעמוד בחוזה, תקנים, מפרטים ותיעוד פורמלי אחר.
הנדסת דרישות מוגדרת כתהליך של הגדרה, תיעוד ותחזוקה של הדרישות. הדיסציפלינה כוללת את כל הטכניקות, השיטות והנהלים הקשורים להגדרה וניהול צורכי המשתמשים הקשורים למערכת הנלמדת.
בסך הכל, הנדסת דרישות היא קבוצה של פעילויות שעניינן זיהוי ותקשורת המטרה של מערכת או תוכנה וההקשר שבו ייעשה בהן שימוש.
לכן, הנדסת דרישות פועלת כגשר בין הצרכים האמיתיים של המשתמשים, הלקוחות ומחוזות אחרים המושפעים מתוכנה או מהמערכת לבין היכולות וההזדמנויות שמעניקות הטכנולוגיות עתירות התוכנה.
מהם העקרונות של הנדסת דרישות?
שני העקרונות הבסיסיים של הנדסת דרישות הם הבעיה והפתרון של הנדסת הדרישות.
- כדאי להפריד בין הבעיה לפתרון בעת איסוף הדרישות.
- הפרדה זו לעולם אינה יכולה להיות מושגת במלואה בחיים המעשיים.
הנדסת דרישות עוסקת בבניית המערכת הנכונה. בעצם, מדובר בבניית מערכת שמתאימה לבעיות של המשתמש. זה חלק מכוון לבעיה. מדובר בעצם בתכנון, אימות, הטמעה ותחזוקה של המערכת שנוצרת כדי לוודא שהיא מתאימה לבעיות של המשתמש. זה החלק המכוון לפתרון.
תהליך הנדסת דרישות
יש כמה פעילויות שעומדות בפנינו כשעובדים עם הדרישות. במחזור הנדסת דרישות, ישנן חמש פעילויות עיקריות, כלומר,
- דרישות רישוי - זהו תהליך הבדיקה, התיעוד וההבנה של בעלי העניין והצרכים והאילוצים של המשתמשים לעונה. משתמשים צריכים מידע על דומיין, מידע מערכת קיים, תקנות, תקנים וכו'. בהתבסס על מידע זה, אנו מעלים את הדרישות. לאחר מכן, אנו עוברים לניתוח דרישות ומשא ומתן.
- ניתוח דרישות ומשא ומתן - ניתוח הוא תהליך חידוד הצרכים והאילוצים של המשתמש על בסיס מידע שנאסף ומתקבל. לאחר מכן, אנו עוברים לפעילות התיעוד.
- דרישות תיעוד/מפרט - לאחר קבלת מפרטי הדרישה, אנו עוברים לחלק התיעוד. אנו מתעדים את הצרכים והאילוצים של המשתמש בצורה ברורה ומדויקת.
- אימות דרישות - לבסוף, בפעילות האימות, אנו מכניסים שדרישות העונה מלאות, תמציתיות וברורות.
- ניהול דרישות – ניהול דרישות הוא דרך לאסוף, ניתוח, חידוד ותעדוף כל המוצרים או הדרישות, בשלב הפיתוח.
כאשר אנו מסיימים את חמש הפעילויות הללו, אנו חוזרים עליהן שוב ושוב עד שנקבל אוסף של מסמכי דרישה מוסכמים שהם מפרטים פורמליים.
דרישות רישוי
כפי שדיברנו קודם, הוצאת דרישות היא תהליך של סקירה, תיעוד והבנת צרכי המשתמש והאילוצים לעונה. משתמשים צריכים מידע על דומיין, מידע מערכת קיים, תקנות, תקנים וכו'. בהתבסס על מידע זה, אנו מעלים את הדרישות. אנו משתמשים במילה 'גיוס' במקום 'התכנסות' מכיוון שהאיסוף מתפרש כאיסוף הדרישות והכנסתן למסמך. מצד שני, elicitation הוא תהליך מורכב יותר. אתה לא מקבל את הדרישות בקלות כמו שאתה מקבל בזמן איסוף. זה דורש מאמץ נוסף.
במהלך הגיוס, אתה שואל את המשתמש או הלקוח:
- מה המטרות שלהם למערכת/מוצר?
- מה יש להשיג?
- כיצד משתלבים הצרכים העונתיים לצרכי העסק?
- כיצד יש להשתמש במוצר/מערכת העונתית על בסיס קבוע?
זה נשמע פשוט, אבל זה ממש לא!
לפי איאן זומרוויל ופיט סוייר, הוצאת דרישות היא תהליך של גילוי הדרישות למערכת על ידי תקשורת עם הלקוחות, משתמשי המערכת ואחרים שיש להם חלק בפיתוח המערכת. מכיוון ש'איסוף' או 'לכידה' לא נשמעים מדויקים במיוחד, אנו משתמשים במילה 'גיוס'.
"אני יודע שאתה מאמין שהבנת את מה שאתה חושב שאמרתי, אבל אני לא בטוח שאתה מבין שמה ששמעת הוא לא מה שהתכוונתי" - רוברט מקלסקי, דובר מחלקת המדינה.
מה שהוא התכוון בציטוט שלו זה לפעמים אנשים מבינים לא נכון מה אנשים אחרים אומרים להם. לפעמים מה שהם אומרים זה לא מה שהם חושבים. בסופו של דבר, כל התקשורת השגויה הזו הובילה לטעות באיסוף הדרישות.
מהם השלבים במהלך הגיוס?
שלב 1
מקור הדרישות:
ישנם מקורות שונים שמהם נוכל לאסוף את הדרישות שלנו. חלק מהם כוללים:
- בעלי עניין
- מערכות קיימות
- מסמכים קיימים
- מתחרים ומערכות דומות אחרות
- ממשקים עם המערכות
- חוקים ותקנים
- מדיניות החברה
שלב 2
הגדר את היקף הפרויקט:
ניתן לבצע את השלבים הבאים על מנת להגדיר את היקף הפרויקט:
- גלה מדוע הפרויקט מתחיל
- נכס מגדיר את המטרות העיקריות שיש להשיג באמצעות הפרויקט
- שרטטו הצהרת עבודה עבור הפרויקט שתעזור לכם בפירוק הולם את העבודה בין חברי הצוות
- רשום את הפריטים שיסופקו בסוף הפרויקט
- בחר את אבני הדרך העיקריות שיש להשיג
- זהה את האילוצים והמגבלות העיקריים שהצוות יכול להתמודד איתם במהלך פיתוח הפרויקט
- צור רשימה של פריטים שאינם נכללים ברשימת פריטי ההיקף
- בקש מבעלי העניין לחתום על מסמך ההיקף שכן הוא מספק אישור שהם מעודכנים לגבי הפרויקט ותכניו.
שלב 3
משימות גיוס:
גיוס תכנון:
- מדוע צריך ליישם את הדרישה הספציפית הזו ואת היתרונות שהיא תספק? – מטרות הפרויקט
- מי יהיה אחראי ליצירתו? – אנשי מקצוע למאמצי גירוש
- מתי יהיה הזמן הטוב ביותר ליישם את זה? - תזמן מקורות הערכה
- איך זה ייושם? - אסטרטגיות ונהלים
- והסיכונים
במהלך הגיוס:
- אשר את כדאיות הפרויקט. גלה אם הפרויקט באמת שווה את זה או לא
- הבן את הבעיות והנושאים מנקודת מבט של בעל עניין
- חלץ את מהות הדרישות שצוינו על ידי בעלי העניין
- גלה דרכים טובות יותר לעשות את העבודה עבור המשתמשים
- חדשנות היא המפתח לניצחון
לאחר גילוי:
- נתח את התוצאות כדי להבין נכון את המידע שנאסף
- לנהל משא ומתן על מערכת קוהרנטית של דרישות המקובלות על מחזיקי העניין. קבעו גם את סדרי העדיפויות
- רשום את התוצאות במפרט הדרישות
גירוש הוא תהליך מצטבר. עליך לחזור על שלב זה ככל שיידרש.
כעת, בחר סט טכניקות מתאים לכל מקור דרישות. קבע את הטכניקה הזו על סמך המקור, המערכת שתפתח וכו'. זכור כי לא ניתן להשתמש בכל הטכניקות בכל מצב.
שלב 4
תיעוד הדרישות -
השלב האחרון בתהליך הגיוס הוא לסיים את כל הדרישות בצורה של מסמך. מסמך זה מכיל בעיקר את ההערות ודרישות המשתמש. והדרישות האלה יהיו לא שלמות, לא עקביות ולא מאורגנות. אבל זו רק נקודת ההתחלה. ניתן לערוך את המסמך מדי פעם, וניתן להוסיף או לשנות דברים.
ניתוח דרישות ומשא ומתן
ניתוח דרישות הוא בדרך כלל הליך של ניתוח, אימות והתאמה של הדרישות המתועדות בשלב של הוצאת דרישות. במילים אחרות, ניתוח דרישות הוא תהליך של לימוד והבנה של הדרישות המוצהרות על ידי בעלי העניין. ניתוח דרישות דורש תקשורת תכופה עם מחזיקי העניין ומשתמשי הקצה על מנת להגדיר את הציפיות, לפתור את הקונפליקטים ולבסוף, לתעד את הדרישות המרכזיות. הפתרונות עשויים לכלול בעיות כמו:
- סוגים שונים של הגדרות עבור זרימת העבודה בחברה
- הקמת מערכת חדשה שאמורה לשמש מעתה ואילך וכו'.
דבר אחד שצריך לזכור הוא שגיוס דרישות וניתוח דרישות עובדים יחד. שניהם מאכילים אחד את השני. כאשר אנו מתחילים לאסוף את הדרישות, אנו מעלים אותן ומנתחים אותן בו-זמנית.
מטרות ניתוח דרישות
- המטרה הראשונה והעיקרית של ניתוח הדרישות היא להבין את הדרישות והצרכים של המשתמשים
- כאשר אנו משתמשים במקורות שונים כדי לאסוף את הדרישות, עשויות להיות כמה התנגשויות ביניהן. ניתוח דרישות עוסק במציאת התנגשויות אלו בין הדרישות שצוינו על ידי המשתמשים ופתרונן.
- לנהל משא ומתן על הדרישות עם המשתמשים ובעלי העניין. אין מצב שהמערכת שלנו יכולה לעמוד בכל הדרישות באופן המדויק שהן מוסברות על ידי בעלי העניין והמשתמשים.
- נצטרך לנהל משא ומתן ולתעדף את הדרישות. חלק מהדרישות אולי לא גדולות עבורנו אבל הן יכולות להיות די חשובות עבור משתמשי הקצה. כדי להבין אותם, עלינו לנתח ולתעדף את הדרישות של בעלי העניין.
- עלינו לפרט את הדרישות שנקבעו על ידי המשתמשים והמערכת. זה עוזר תוך תיעוד הדרישות במפרטי הדרישות. כמו כן, זה עוזר למפתחים לפתח, לעצב ולבדוק טוב יותר כשהם מבינים את הדרישות בצורה משוכללת וטובה יותר.
- עלינו לסווג את הדרישות לקטגוריות שונות ותתי-קטגוריות שונות ולהקצות את הדרישות הללו לתתי-מערכות שונות.
- כמו כן, עלינו להעריך את הדרישות לאיכות הרצויה על ידי הארגון.
- לבסוף, עלינו להבטיח לא לפספס שום דבר חשוב.
דרישות תיעוד/מפרט
מפרט דרישות, המכונה גם תיעוד, הוא תהליך של רישום של כל דרישות המערכת והמשתמש בצורה של מסמך. דרישות אלו חייבות להיות ברורות, מלאות, מקיפות ועקביות.
במהלך פעילות הלכידה אנו אוספים את כל הדרישות ממקורות שונים. במהלך פעולות הניתוח והמשא ומתן, אנו מנתחים ומבינים את הדרישות הללו. כעת, עלינו להכין מסמך רשמי המסביר את הדרישות הללו. זה מה שמפרט הדרישות. אם לדייק, מדובר בתהליך של תיעוד כל צרכי המשתמש והמערכת והאילוצים בצורה ברורה ומדויקת.
שיטה לתיעוד דרישות
אוזניים תהיה כאן מתודולוגיה יעילה. זה מייצג גישה קלה לתחביר דרישות. בשיטה זו אנו כותבים שפה ברורה, תמציתית ומובנת. זה משפר את כל זרימת העבודה ההנדסית של הדרישות ומפשט את העבודה על ידי כך שהדברים די קלים להבנה.
כדי להשיג זאת, הנה כמה עקרונות שיש לזכור בעת כתיבת הדרישות. הם כוללים:
כל דרישה חייבת להיות בצורה של משפט שלם. אין להשתמש בכדורים, ראשי תיבות, קיצורים או מילות באזז. נסו לעשות משפטים קצרים, ישירים ושלמים.
ודא שלכל דרישה יש נושא, פרדיקט ופועל מתאימים. הנושא יהיה סוג המשתמש או המערכת שעליה אנחנו מדברים. הפרדיקט יהיה התנאים או הפעולות או התוצאות הרצויות להן אנו מצפים. עלינו להשתמש במילים כמו 'יעשה', 'ירצה' ו'חייב' כדי לבטא איזשהו הכרח, ובמילים כמו 'רשאי' כדי לבטא אופציונליות בדרישה.
כל דרישה חייבת להסביר ביעילות את התוצאה הסופית שאנו רוצים מהמערכת.
כמו כן, הדרישה חייבת לתאר את האיכות שאנו מצפים מהמערכת. זה עוזר כאשר אנו מודדים את התוצאה הסופית ורואים אם הדרישה מיושמת כראוי או לא.
אימות דרישות
אימות הוא תהליך המשמש לבדיקה אם המערכת עומדת בסימן או לא. אימות עונה על השאלה "האם אנחנו בונים את המערכת הנכונה?" מדובר בבדיקה ותיקוף של המערכת ולראות האם המערכת שבנינו נכונה או לא והאם היא עונה על ציפיות הלקוח או לא. שיטות שונות המשמשות לאימות המערכת כוללות בדיקת קופסה שחורה, בדיקת קופסה לבנה, בדיקת אינטגרציה ובדיקת יחידות. אימות תמיד מגיע לאחר אימות.
אימות הוא תהליך המשמש לבדיקה אם המערכת משיגה את יעדיה הצפויים או לא ללא באגים או בעיות. אימות עונה על השאלה "האם אנחנו בונים את המוצר נכון?" מדובר בבדיקה ואימות אם המערכת עומדת בדרישותיה ללא בעיות. שיטות שונות המשמשות לאימות המערכת כוללות סקירות, הדרכה, בדיקות ובדיקות שולחן. אימות הוא תהליך ידני שנעשה לפני אימות.
טכניקות אימות
ישנן טכניקות שונות שניתן להשתמש בהן כדי לאמת את הדרישות. הם כוללים:
- בדיקות - תוך כדי בדיקת הדרישות, אנו קוראים הגהה במסמכי הדרישות כדי להבטיח שלא תפספסו הערות הסרה. במהלך בדיקות אלו אנו בודקים גם את רמת העקיבות בין כל הדרישות. לשם כך נדרשת יצירת מטריצת עקיבות. מטריצה זו מבטיחה כי כל הדרישות נשקלו ברצינות וכל מה שצוין מוצדק. אנו בודקים גם את פורמט הדרישות במהלך בדיקות אלו. אנו רואים אם הדרישות ברורות וכתובות היטב או לא.
- פרוטוטייפ – זוהי דרך לבנות מודל או סימולציה של המערכת שאמורה להיבנות על ידי המפתחים. זוהי טכניקה פופולרית מאוד לאימות דרישות בקרב בעלי עניין ומשתמשים שכן היא עוזרת להם לזהות בקלות את הבעיות. אנחנו יכולים פשוט לפנות למשתמשים ולבעלי עניין ולקבל את המשוב שלהם.
- עיצוב מבחן - במהלך תכנון הבדיקות, אנו עוקבים אחר הליך קטן שבו אנו מסיימים תחילה את צוות הבדיקות, ולאחר מכן בונים כמה תרחישי בדיקה. ניתן לגזור בדיקות פונקציונליות ממפרט הדרישות עצמו כאשר לכל דרישה יש מבחן משויך. להיפך, קשה לבדוק את הדרישות שאינן פונקציונליות, שכן כל בדיקה חייבת להיות מקורה בדרישה שלה. המטרה של זה היא להבין את השגיאות במפרט או את הפרטים שהוחמצו.
- סקירת דרישות – במהלך סקירת הדרישות, קבוצה של אנשים בעלי ידע מנתחת את הדרישות בצורה מובנית ומפורטת ומזהה את הבעיות הפוטנציאליות. לאחר מכן, הם מתאספים כדי לדון בנושאים ולמצוא דרך לטפל בבעיות. ערוך רשימת בדיקה המורכבת מתקנים שונים והבודקים מסמנים את התיבות כדי לספק סקירה רשמית. לאחר מכן, מתבצעת אישור סופי.
ניהול דרישות
לדברי איאן זומרוויל, "ניהול דרישות הוא תהליך של ניהול דרישות משתנות במהלך תהליך הנדסת הדרישות ופיתוח המערכת."
המטרה העיקרית של ניהול הדרישות היא להבטיח דרישות ברורות, תמציתיות וללא שגיאות לצוות המהנדסים, כך שיוכלו לדאוג לזהות שגיאות במערכת ועלול להפחית את עלות הפרויקט כמו גם את הסיכון.
הדאגות העיקריות של ניהול דרישות
יש כמה חששות לגבי ניהול דרישות. הם כוללים:
- ניהול השינויים בדרישות המוסכמות
- ניהול הקשר בין כל הדרישות
- ניהול התלות בין מסמכי הדרישות המופקים בתהליך הנדסת המערכת.
סוגי דרישות
יש בגדול שני סוגים של דרישות:
- דרישות מערכת – דרישות המערכת יכולות להיקרא הגרסה המורחבת של דרישות המשתמש. דרישות המערכת משמשות כנקודת התחלה לכל עיצוב מערכת חדש. דרישות אלו מהוות תיאור מפורט של דרישות המשתמש שהמערכת צריכה לעמוד בהן.
- דרישות משתמש – דרישת המשתמש היא שילוב של דרישות פונקציונליות ולא פונקציונליות. דרישות המשתמש הללו חייבות להיות מתוכננות בצורה כזו שהן ניתנות להבנה בקלות למשתמשים שאין להם כל סוג של ידע טכני. לפיכך, הם חייבים להיכתב בשפה טבעית באמצעות טבלאות, טפסים ודיאגרמות פשוטות. כמו כן, ודא שאין במסמך פרטים על עיצוב המערכת, תוכנה או סימון רשמי.
דרישות ה-Visure ALM Platform
דרישות ה-Visure ALM Platform היא אחת מפלטפורמות ALM המודרניות המהימנות ביותר המתמחות בניהול דרישות עבור ארגונים בכל הגדלים ברחבי העולם.
זהו כלי חובה לצוותים הבונים מוצרים, מערכות ותוכנה מורכבים, הדורשים מעקב מקצה לקצה מהתפיסה ועד לבדיקה ופריסה, כל הדרך לקוד המקור, יחד עם תאימות לאישורים סטנדרטיים.
Visure Requirements הוא כלי מוכח גמיש ושלם להנדסת דרישות, המסוגל לייעל את תהליך דרישות התוכנה כחלק מתהליך ההגדרה של החומרה והמכאן. Visure Requirements מסייעים לשיתוף פעולה יעיל בפרויקט ומגדילים את איכות התוכנה באמצעות לכידת דרישות, ניתוח, מפרט, אימות ואימות, ניהול ושימוש חוזר.
Visure Solutions יכול לעזור להתגבר על האתגרים של פיתוח מוצרים ופיתוח משובץ,
- שפר את איכות ההגדרה כצעד ראשון חיוני בהגברת איכות התוכנה
- להחזיר את השליטה בתהליכי פיתוח ורגולציה
- תקן ואכוף את הגדרת הדרישות ברחבי הארגון
- תומך בשימוש יעיל בדרישות בין צוותי הפרויקט וקווי המוצרים והווריאציות
- פורמל מבנה מפרט דרישות נפוץ וטיפול בשינויים לאורך מחזור החיים
- להשיג יכולת מעקב מלאה דרך כל המרכיבים, מדרישות לבדיקה ועד לביצוע
- עקוב אחר כל היבטי הפיתוח בקלות, החל בגרפיקה של חישוב סיכונים ועד לדוחות דרישות יתומים
- הימנע ממלכודות והפחת סיכונים בכל הרמות, מכתיבת דרישות טובות יותר ותעדוף צרכים ועד לשינוי יכולות ניתוח ההשפעה.
יתרונות השימוש בדרישות Visure לפיתוח מוצרים ומשובצים
- תמיכה בהסמכה עבור תקני התעשייה, כגון DO-178B/C, IEC 61508, ISO 26262, IEC 62304, FMEA ו-GAMP5
- פלטפורמה שלמה אחת לכל הפעילויות הקשורות לדרישות
- אכיפת תהליכים באמצעות פתרון גמיש התומך במודלים שונים של תהליכים לרבות Automotive SPICE, CMMI, V-model, Agile ואד-הוק
- תקשורת צוותית משופרת ושיתוף פעולה באמצעות יכולות מבוססות תפקידים
- תמיכה במוצרים באיכות טובה יותר, והפחתת פגמי תוכנה.
חברות המשתמשות באופן פעיל ב-Visure, טוענות להשפעה ברורה עם אספקת פרויקטים בזמן, תאימות לפרויקט וירידה בעלויות הפיתוח ובזמני המחזור.
סיכום
הנדסת דרישות היא תהליך קריטי כדי להבטיח שהמוצרים והמערכות שאנו בונים הם מה שהלקוחות שלנו צריכים. תהליך חמשת השלבים המתואר במאמר זה יכול לעזור לך להתחיל את הפרויקט שלך טוב על ידי קבלת משוב מבעלי עניין מוקדם ולעתים קרובות ושימוש במשוב זה כדי ליצור דרישות ברורות ותמציתיות. אם אתה מחפש כלי שיעזור לך לנהל את תהליך הנדסת הדרישות שלך, Visure Requirements ALM Platform יכולה לעזור. בקש שלך ללא תשלום 30 יום המשפט היום כדי לראות כיצד הפלטפורמה שלנו יכולה להפוך את הפרויקט הבא שלך להצלחה.
אל תשכחו לשתף את הפוסט הזה!
