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

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

הבנה נפוצה

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

תשומת לב לכל הפרטים

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

אילו יש?

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

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

דרישות: איפה ניתן להשיג אותם?

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

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

לא כל כך פשוט

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

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

איך זה נראה?

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

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

עבודה ממשיכה

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

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

צעד אחר צעד

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

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

נקודות הפניה

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

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

גישה אלטרנטיבית

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

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

לעבוד עם נקודות מבט

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

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

קח את הזמן שלך!

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

אישור דרישות

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

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