การวิเคราะห์ธุรกิจ - คู่มือฉบับย่อ

Business Analysis คืออะไร?

การวิเคราะห์ธุรกิจคือชุดของงานความรู้และเทคนิคที่จำเป็นในการระบุความต้องการทางธุรกิจและกำหนดแนวทางแก้ไขปัญหาทางธุรกิจขององค์กร แม้ว่าคำจำกัดความทั่วไปจะคล้ายคลึงกัน แต่การปฏิบัติและขั้นตอนอาจแตกต่างกันไปในอุตสาหกรรมต่างๆ

ในอุตสาหกรรมเทคโนโลยีสารสนเทศโซลูชันมักรวมถึงองค์ประกอบการพัฒนาระบบ แต่อาจประกอบด้วยการปรับปรุงกระบวนการหรือการเปลี่ยนแปลงองค์กร

นอกจากนี้ยังอาจทำการวิเคราะห์ธุรกิจเพื่อทำความเข้าใจสถานะปัจจุบันขององค์กรหรือเพื่อใช้เป็นพื้นฐานในการระบุความต้องการทางธุรกิจ อย่างไรก็ตามในกรณีส่วนใหญ่การวิเคราะห์ทางธุรกิจจะดำเนินการเพื่อกำหนดและตรวจสอบความถูกต้องของโซลูชันที่ตรงกับความต้องการเป้าหมายหรือวัตถุประสงค์ทางธุรกิจ

นักวิเคราะห์ธุรกิจคือใคร?

นักวิเคราะห์ธุรกิจคือผู้ที่วิเคราะห์องค์กรหรือโดเมนธุรกิจ (จริงหรือสมมุติ) และจัดทำเอกสารเกี่ยวกับธุรกิจกระบวนการหรือระบบประเมินรูปแบบธุรกิจหรือการผสมผสานกับเทคโนโลยี อย่างไรก็ตามชื่อองค์กรจะแตกต่างกันไปเช่นนักวิเคราะห์นักวิเคราะห์ธุรกิจนักวิเคราะห์ระบบธุรกิจหรืออาจจะเป็นนักวิเคราะห์ระบบ

ทำไมต้องเป็นนักวิเคราะห์ธุรกิจ

องค์กรต่างๆใช้การวิเคราะห์ธุรกิจด้วยเหตุผลดังต่อไปนี้ -

  • เพื่อทำความเข้าใจโครงสร้างและพลวัตขององค์กรที่ต้องปรับใช้ระบบ

  • เพื่อทำความเข้าใจปัญหาปัจจุบันในองค์กรเป้าหมายและระบุศักยภาพในการปรับปรุง

  • เพื่อให้แน่ใจว่าลูกค้าผู้ใช้ปลายทางและนักพัฒนามีความเข้าใจร่วมกันเกี่ยวกับองค์กรเป้าหมาย

ในช่วงเริ่มต้นของโครงการเมื่อมีการตีความข้อกำหนดโดยทีมโซลูชันและทีมออกแบบบทบาทของนักวิเคราะห์ธุรกิจคือการตรวจสอบเอกสารโซลูชันทำงานอย่างใกล้ชิดกับนักออกแบบโซลูชัน (ทีมไอที) และผู้จัดการโครงการเพื่อให้แน่ใจว่า ข้อกำหนดมีความชัดเจน

ในองค์กรไอทีขนาดใหญ่ทั่วไปโดยเฉพาะอย่างยิ่งในสภาพแวดล้อมการพัฒนาคุณจะพบทีมจัดส่งในสถานที่และนอกชายฝั่งที่มีบทบาทดังกล่าวข้างต้น คุณสามารถค้นหา“ นักวิเคราะห์ธุรกิจ” ที่ทำหน้าที่เป็นบุคคลสำคัญที่ต้องเชื่อมโยงทั้งสองทีม

บางครั้งเขาจะโต้ตอบกับผู้ใช้ทางธุรกิจและในบางครั้งผู้ใช้ทางเทคนิคและในที่สุดก็ให้ผู้มีส่วนได้ส่วนเสียทั้งหมดในโครงการได้รับการอนุมัติและพยักหน้าสุดท้ายก่อนดำเนินการจัดทำเอกสาร

ดังนั้นบทบาทของ BA จึงมีความสำคัญอย่างยิ่งในการเริ่มต้นโครงการใด ๆ ที่มีประสิทธิผลและประสบความสำเร็จ

บทบาทของนักวิเคราะห์ธุรกิจไอที

บทบาทของนักวิเคราะห์ธุรกิจเริ่มต้นจากการกำหนดและกำหนดขอบเขตพื้นที่ธุรกิจขององค์กรจากนั้นรวบรวมข้อกำหนดวิเคราะห์และจัดทำเอกสารข้อกำหนดสื่อสารข้อกำหนดเหล่านี้ไปยังผู้มีส่วนได้ส่วนเสียที่เหมาะสมระบุโซลูชันที่เหมาะสมจากนั้นตรวจสอบความถูกต้องของโซลูชันเพื่อดูว่า ข้อกำหนดเป็นไปตามมาตรฐานที่คาดหวัง

แตกต่างจากอาชีพอื่นอย่างไร?

การวิเคราะห์ธุรกิจแตกต่างจากการวิเคราะห์ทางการเงินการจัดการโครงการการประกันคุณภาพการพัฒนาองค์กรการทดสอบการฝึกอบรมและการพัฒนาเอกสาร อย่างไรก็ตามนักวิเคราะห์ธุรกิจอาจทำหน้าที่ที่เกี่ยวข้องบางส่วนหรือทั้งหมดนี้ทั้งนี้ขึ้นอยู่กับองค์กร

นักวิเคราะห์ธุรกิจที่ทำงานด้านการพัฒนาระบบซอฟต์แวร์เพียงอย่างเดียวอาจเรียกว่านักวิเคราะห์ธุรกิจไอทีนักวิเคราะห์ธุรกิจด้านเทคนิคนักวิเคราะห์ธุรกิจออนไลน์นักวิเคราะห์ระบบธุรกิจหรือนักวิเคราะห์ระบบ

การวิเคราะห์ธุรกิจยังรวมถึงการทำงานประสานงานระหว่างผู้มีส่วนได้ส่วนเสียทีมพัฒนาทีมทดสอบ ฯลฯ

วงจรชีวิตของการพัฒนาซอฟต์แวร์

Software Development Life Cycle (SDLC) เป็นกระบวนการที่เกิดขึ้นในโครงการซอฟต์แวร์ภายในองค์กรซอฟต์แวร์ ประกอบด้วยแผนโดยละเอียดที่อธิบายถึงวิธีการพัฒนาบำรุงรักษาเปลี่ยนและแก้ไขหรือปรับปรุงซอฟต์แวร์เฉพาะ เป็นการกำหนดวิธีการในการปรับปรุงคุณภาพของซอฟต์แวร์และกระบวนการพัฒนาโดยรวม

  • SDLC เป็นกระบวนการที่นักวิเคราะห์ไอทีใช้เพื่อพัฒนาหรือออกแบบระบบซอฟต์แวร์คุณภาพสูงใหม่ซึ่งตรงตามความต้องการของลูกค้าและในโลกแห่งความเป็นจริง

  • จะคำนึงถึงแง่มุมที่เกี่ยวข้องทั้งหมดของการทดสอบซอฟต์แวร์การวิเคราะห์และการบำรุงรักษาหลังกระบวนการ

ขั้นตอนที่สำคัญของ SDLC แสดงอยู่ในภาพประกอบต่อไปนี้ -

ขั้นตอนการวางแผน

ทุกกิจกรรมต้องเริ่มต้นด้วยแผน การไม่วางแผนคือการวางแผนที่จะล้มเหลว ระดับของการวางแผนแตกต่างกันไปในแต่ละรุ่น แต่สิ่งสำคัญมากที่จะต้องมีความเข้าใจอย่างชัดเจนเกี่ยวกับสิ่งที่เรากำลังจะสร้างโดยการสร้างข้อกำหนดของระบบ

การกำหนดเวที

ในขั้นตอนนี้เราจะวิเคราะห์และกำหนดโครงสร้างของระบบ เรากำหนดสถาปัตยกรรมส่วนประกอบและวิธีที่ส่วนประกอบเหล่านี้ประกอบเข้าด้วยกันเพื่อสร้างระบบการทำงาน

ขั้นตอนการออกแบบ

ในการออกแบบระบบมีการอธิบายรายละเอียดฟังก์ชันการออกแบบและการดำเนินงานรวมถึงเค้าโครงหน้าจอกฎทางธุรกิจไดอะแกรมกระบวนการและเอกสารอื่น ๆ ผลลัพธ์ของขั้นตอนนี้จะอธิบายระบบใหม่ว่าเป็นชุดของโมดูลหรือระบบย่อย

เวทีอาคาร

นี่คือขั้นตอนการพัฒนา เราเริ่มการสร้างโค้ดตามการออกแบบของระบบโดยใช้คอมไพเลอร์ล่ามผู้ดีบั๊กเพื่อทำให้ระบบมีชีวิต

การนำไปใช้

การนำไปใช้งานเป็นส่วนหนึ่งของขั้นตอนการสร้าง ในขั้นตอนนี้เราเริ่มการสร้างโค้ดตามการออกแบบของระบบโดยใช้คอมไพเลอร์ล่ามผู้ดีบั๊กเพื่อทำให้ระบบมีชีวิต

ขั้นตอนการทดสอบ

เมื่อส่วนต่างๆของระบบเสร็จสมบูรณ์ พวกเขาผ่านการทดสอบหลายชุด ได้รับการทดสอบตามข้อกำหนดเพื่อให้แน่ใจว่าผลิตภัณฑ์สามารถแก้ปัญหาความต้องการได้จริงในระหว่างขั้นตอนความต้องการ

  • แผนการทดสอบและกรณีทดสอบใช้เพื่อระบุจุดบกพร่องและเพื่อให้แน่ใจว่าระบบทำงานตามข้อกำหนด

  • ในขั้นตอนนี้จะมีการทดสอบประเภทต่างๆเช่นการทดสอบหน่วยการทดสอบด้วยตนเองการทดสอบการยอมรับและการทดสอบระบบ

การติดตามข้อบกพร่องในการทดสอบ

รายงานการทดสอบซอฟต์แวร์ใช้เพื่อสื่อสารผลลัพธ์ของแผนการทดสอบที่ดำเนินการ ในกรณีนี้รายงานควรมีข้อมูลการทดสอบทั้งหมดที่เกี่ยวข้องกับระบบปัจจุบันที่กำลังทดสอบ ความสมบูรณ์ของรายงานจะได้รับการตรวจสอบในเซสชันการฝึกปฏิบัติ

การทดสอบโครงการพยายามบรรลุเป้าหมายหลักสองประการ -

  • ตรวจจับความล้มเหลวและข้อบกพร่องในระบบ

  • ตรวจจับความไม่สอดคล้องกันระหว่างข้อกำหนดและการนำไปใช้งาน

ผังงานต่อไปนี้แสดงถึงไฟล์ Defect Tracking Process -

เพื่อให้บรรลุเป้าหมายหลักกลยุทธ์การทดสอบสำหรับระบบที่นำเสนอมักประกอบด้วยระดับการทดสอบสี่ระดับ

นี่คือการทดสอบหน่วยการทดสอบการรวมการทดสอบการยอมรับและการทดสอบการถดถอย ส่วนย่อยต่อไปนี้สรุประดับการทดสอบเหล่านี้ซึ่งทีมพัฒนามีหน้าที่รับผิดชอบในการพัฒนาและดำเนินการและเกณฑ์ในการพิจารณาความสมบูรณ์

การปรับใช้

หลังจากสิ้นสุดขั้นตอนการทดสอบระบบจะถูกปล่อยและเข้าสู่สภาพแวดล้อมการผลิต เมื่อผลิตภัณฑ์ได้รับการทดสอบและพร้อมที่จะนำไปใช้งานแล้วผลิตภัณฑ์จะได้รับการเผยแพร่อย่างเป็นทางการในตลาดที่เหมาะสม บางครั้งการปรับใช้ผลิตภัณฑ์จะเกิดขึ้นเป็นขั้นตอนตามกลยุทธ์ทางธุรกิจขององค์กร

ผลิตภัณฑ์อาจวางจำหน่ายในกลุ่มที่ จำกัด ก่อนและทดสอบในสภาพแวดล้อมทางธุรกิจจริง (UAT- การทดสอบการยอมรับของผู้ใช้) จากนั้นตามความคิดเห็นอาจมีการเปิดตัวผลิตภัณฑ์ตามที่เป็นอยู่หรือมีการปรับปรุงที่แนะนำในกลุ่มตลาดเป้าหมาย

โพสต์กระบวนการ SDLC

หลังจากที่ผลิตภัณฑ์ออกสู่ตลาดแล้วการบำรุงรักษาจะดำเนินการสำหรับฐานลูกค้าเดิม

เมื่ออยู่ในสภาพแวดล้อมการใช้งานจริงระบบจะได้รับการแก้ไขเนื่องจากข้อบกพร่องที่ตรวจไม่พบหรือเหตุการณ์ที่ไม่คาดคิดอื่น ๆ ระบบได้รับการประเมินและมีการทำวงจรซ้ำสำหรับการบำรุงรักษาระบบ

บทบาทของนักวิเคราะห์ธุรกิจระหว่างกระบวนการ SDLC

ดังที่เราเห็นแผนภาพด้านล่าง BA มีส่วนร่วมในการผลักดันความต้องการทางธุรกิจและแปลงเป็นข้อกำหนดของโซลูชัน

เขามีส่วนร่วมในการแปลคุณสมบัติของโซลูชันเป็นข้อกำหนดของซอฟต์แวร์ จากนั้นนำไปสู่ขั้นตอนการวิเคราะห์และการออกแบบกำหนดในการพัฒนาโค้ดจากนั้นทำตามขั้นตอนการทดสอบระหว่างการแก้ไขข้อบกพร่องในฐานะตัวแทนการเปลี่ยนแปลงในทีมโครงการและตอบสนองความต้องการของลูกค้าได้ในที่สุด

การวิเคราะห์ธุรกิจ - บทบาท

บทบาทของนักวิเคราะห์ธุรกิจในโครงการไอทีสามารถทำได้หลายเท่า เป็นไปได้ที่สมาชิกในทีมโครงการจะมีบทบาทและความรับผิดชอบหลายอย่าง ในบางโครงการ BA อาจรับบทบาทเป็น Business Intelligence Analyst, Database Designer, Software Quality Assurance Specialist, Tester และ / หรือ Trainer เมื่อมีทรัพยากรที่ จำกัด

นอกจากนี้ยังเป็นไปได้ที่ผู้ประสานงานโครงการหรือหัวหน้าการพัฒนาแอปพลิเคชันหรือนักพัฒนาสามารถรับบทบาทเป็นนักวิเคราะห์ธุรกิจในโครงการเฉพาะได้

การวิเคราะห์ทางธุรกิจมีความซับซ้อนอย่างมากกับการวิเคราะห์ข้อกำหนดของธุรกิจเพื่อให้ทำงานได้ตามปกติและเพื่อเพิ่มประสิทธิภาพวิธีการทำงาน ตัวอย่างการวิเคราะห์ธุรกิจ ได้แก่ -

  • การสร้างสถาปัตยกรรมทางธุรกิจ
  • การเตรียมกรณีธุรกิจ
  • การประเมินความเสี่ยง
  • ข้อกำหนดการปล่อย
  • การวิเคราะห์กระบวนการทางธุรกิจ
  • เอกสารข้อกำหนด

บทบาทสำคัญของ BA

บทบาทสำคัญของนักวิเคราะห์ธุรกิจส่วนใหญ่คือการประสานงานระหว่างธุรกิจและนักพัฒนาด้านเทคนิค นักวิเคราะห์ธุรกิจจะทำงานร่วมกันกับลูกค้าธุรกิจเพื่อรวบรวม / กำหนดข้อกำหนดของระบบหรือกระบวนการเพื่อเพิ่มผลผลิตในขณะเดียวกันก็ทำงานร่วมกับทีมเทคนิคเพื่อออกแบบและใช้ระบบ / กระบวนการ

ในฐานะผู้ร่วมให้ข้อมูล

ความรับผิดชอบหลักของ BA คือการมีส่วนร่วมในการพัฒนาผู้ใช้ทางธุรกิจ / ผู้ใช้หลักในการระบุปัญหาทางธุรกิจความต้องการและหน้าที่เข้าใจข้อกังวลและข้อกำหนดของผู้มีส่วนได้ส่วนเสียเพื่อระบุโอกาสในการปรับปรุงและสนับสนุนข้อมูลทางธุรกิจสำหรับการพัฒนากรณีทางธุรกิจสำหรับไอที โครงการพัฒนาระบบ.

ในฐานะผู้อำนวยความสะดวก

นักวิเคราะห์ธุรกิจควรจะอำนวยความสะดวก / ประสานงานในการกระตุ้นและวิเคราะห์ข้อกำหนดการทำงานร่วมกันและการสื่อสารกับผู้มีส่วนได้ส่วนเสียและเพื่อจัดการความคาดหวังและความต้องการของพวกเขาและตรวจสอบให้แน่ใจว่าข้อกำหนดนั้นสมบูรณ์ไม่คลุมเครือและจับคู่กับความต้องการทางธุรกิจแบบเรียลไทม์ ขององค์กร

ในฐานะนักวิเคราะห์

บทบาทที่สำคัญอีกประการหนึ่งคือการประเมินระบบที่เสนอและความพร้อมขององค์กรสำหรับการนำระบบไปใช้และให้การสนับสนุนผู้ใช้และประสานงานกับเจ้าหน้าที่ไอที

เพื่อช่วยตรวจสอบและจัดหาข้อมูลในการออกแบบระบบไอทีที่นำเสนอจากมุมมองทางธุรกิจการแก้ไขปัญหา / ความขัดแย้งระหว่างผู้มีส่วนได้ส่วนเสียช่วยจัดระเบียบ UAT ที่ครอบคลุมและมีคุณภาพผ่านการช่วยเหลือผู้ใช้ในการพัฒนากรณีทดสอบและช่วยจัดการฝึกอบรมโดยมีวัตถุประสงค์เพื่อให้มั่นใจว่า ปรับใช้ระบบไอทีซึ่งสามารถตอบสนองความต้องการทางธุรกิจและข้อกำหนดรวมทั้งตระหนักถึงประโยชน์ที่คาดว่าจะได้รับ

วางแผนและติดตามกิจกรรมการวิเคราะห์ธุรกิจสำหรับการพัฒนาขอบเขตกำหนดการและแนวทางในการดำเนินกิจกรรมที่เกี่ยวข้องกับการวิเคราะห์ธุรกิจสำหรับโครงการพัฒนาระบบไอทีติดตามความคืบหน้าประสานงานกับผู้จัดการโครงการภายในและรายงานเกี่ยวกับรายได้ผลกำไรความเสี่ยงและประเด็นต่างๆ เหมาะสม

ความรับผิดชอบหลักของนักวิเคราะห์ธุรกิจ

ชุดความรับผิดชอบของนักวิเคราะห์ธุรกิจต้องการให้เขาปฏิบัติหน้าที่ที่แตกต่างกันในระยะต่างๆของโครงการและมีรายละเอียดด้านล่าง -

ระยะเริ่มต้น

ระยะนี้จะเป็นจุดเริ่มต้นของโครงการใหม่และนักวิเคราะห์ธุรกิจจะแตกต่างกันไปตามความรับผิดชอบต่อไปนี้ -

  • ช่วยในการวิเคราะห์ต้นทุน - ผลประโยชน์ของโครงการ
  • ทำความเข้าใจกรณีธุรกิจ
  • ตรวจสอบความเป็นไปได้ของโซลูชัน / โครงการ / ผลิตภัณฑ์
  • ช่วยในการสร้างกฎบัตรโครงการ
  • ระบุผู้มีส่วนได้ส่วนเสียในโครงการ

ขั้นตอนการวางแผน

ขั้นตอนนี้จะเกี่ยวข้องกับการรวบรวมข้อกำหนดและการวางแผนวิธีดำเนินการและจัดการโครงการ ความรับผิดชอบของเขาจะรวมถึงหน้าที่ด้านล่าง -

  • ดำเนินการตามข้อกำหนด
  • วิเคราะห์จัดระเบียบและจัดทำเอกสารข้อกำหนด
  • จัดการข้อกำหนดโดยการสร้าง Use-cases, RTM, BRD, SRS และอื่น ๆ
  • ประเมินโซลูชันที่เสนอ
  • ติดต่อประสานงานและปรับปรุงการสื่อสารกับผู้มีส่วนได้ส่วนเสีย
  • ช่วยในการกำหนดแผนการจัดการโครงการ
  • ช่วยในการค้นหาขอบเขตข้อ จำกัด สมมติฐานและความเสี่ยงของโครงการ
  • ช่วยในการออกแบบประสบการณ์ของผู้ใช้โซลูชัน

กำลังดำเนินการเฟส

ระยะนี้นับเป็นการพัฒนาโซลูชันตามข้อกำหนดที่รวบรวม หน้าที่ความรับผิดชอบประกอบด้วย -

  • อธิบายข้อกำหนดให้กับทีมไอที / ผู้พัฒนา

  • ชี้แจงข้อสงสัยข้อกังวลเกี่ยวกับการเสนอแนวทางแก้ไขที่จะพัฒนา

  • อภิปรายและจัดลำดับความสำคัญของการเปลี่ยนแปลงขอบเขตโครงการและรับข้อตกลง

  • สร้างสคริปต์การทดสอบเบต้าสำหรับการทดสอบเบื้องต้น

  • แบ่งปันโมดูลที่กำลังพัฒนากับผู้มีส่วนได้ส่วนเสียและขอความคิดเห็น

  • ทำตามกำหนดเวลาและจัดการความคาดหวังของผู้มีส่วนได้ส่วนเสีย

  • แก้ไขความขัดแย้งและจัดการการสื่อสารกับทีมโครงการ

การตรวจสอบและควบคุมเฟส

ในขั้นตอนนี้โครงการจะถูกวัดและควบคุมสำหรับการเบี่ยงเบนจากแผนเริ่มต้น ระยะนี้ทำงานไปพร้อมกันจนถึงขั้นตอนการดำเนินการ

  • การพัฒนาสคริปต์ทดสอบและดำเนินการทดสอบโมดูลและการรวมที่ครอบคลุม

  • ดำเนินการ UAT (ใช้การทดสอบการยอมรับ) และสร้างรายงานการทดสอบ

  • รับการยอมรับ / อนุมัติสิ่งที่ส่งมอบจากลูกค้า

  • อธิบายคำขอการเปลี่ยนแปลงให้กับทีมพัฒนา

  • ตรวจสอบการพัฒนาคำขอการเปลี่ยนแปลงและตรวจสอบการดำเนินการตามวัตถุประสงค์ของโครงการ

ปิดเฟส

ระยะนี้นับเป็นการปิดโครงการ หน้าที่ความรับผิดชอบคือ -

  • นำเสนอโครงการที่เสร็จสมบูรณ์ให้กับลูกค้าและได้รับการยอมรับ

  • จัดทำคู่มือการฝึกอบรมผู้ใช้เอกสารการใช้งานและคู่มือการใช้งานอื่น ๆ

  • ดำเนินการทดสอบการรวมอย่างละเอียดในสภาพแวดล้อมการผลิต

  • สร้างเอกสารผลิตภัณฑ์ขั้นสุดท้ายเรียนรู้บทเรียนโครงการเอกสาร

BA คาดว่าจะส่งมอบอะไร?

นักวิเคราะห์ธุรกิจทำหน้าที่เป็นสะพานเชื่อมระหว่างผู้ใช้ทางธุรกิจกับคนไอทีด้านเทคนิค การปรากฏตัวของพวกเขาจะมีส่วนสำคัญต่อความสำเร็จของโครงการไอที มีประโยชน์มากมายของการมีนักวิเคราะห์ธุรกิจโดยเฉพาะ นักวิเคราะห์ธุรกิจโดยเฉพาะสามารถ -

  • มอบขอบเขตโครงการที่ชัดเจนจากมุมมองทางธุรกิจ

  • พัฒนากรณีธุรกิจที่ดีและการประมาณทรัพยากรและผลประโยชน์ทางธุรกิจที่เป็นจริงมากขึ้น

  • จัดทำรายงานที่ดีขึ้นเกี่ยวกับการกำหนดขอบเขตโครงการการวางแผนและการจัดการในแง่ของต้นทุนและกำหนดเวลาโดยเฉพาะอย่างยิ่งสำหรับโครงการไอทีขนาดใหญ่

  • จัดทำข้อกำหนดที่ชัดเจนและรัดกุมซึ่งจะช่วยให้ข้อกำหนดที่ชัดเจนและแม่นยำยิ่งขึ้นหากโครงการไอทีได้รับการว่าจ้างจากภายนอก

  • ตอบสนองความต้องการทางธุรกิจที่แท้จริงจากผู้ใช้และจัดการความคาดหวังของผู้ใช้อย่างมีประสิทธิภาพ

  • ปรับปรุงคุณภาพของการออกแบบสำหรับระบบไอทีที่นำเสนอเพื่อให้ตรงตามความต้องการของผู้ใช้

  • ตรวจสอบคุณภาพของระบบที่พัฒนาก่อนส่งต่อไปยังผู้ใช้ปลายทางเพื่อตรวจสอบและยอมรับ

  • จัดให้มีการทดสอบคุณภาพที่ครอบคลุมในระบบที่จัดส่งและให้ข้อเสนอแนะแก่บุคลากรด้านเทคนิคด้านไอที

การวิเคราะห์ธุรกิจ - เครื่องมือและเทคนิค

นักวิเคราะห์ธุรกิจควรคุ้นเคยกับเครื่องมือวิเคราะห์ต่างๆและเทคโนโลยีที่เกี่ยวข้องเมื่อคุณสวมหมวก BA ฉันหมายถึงถ้าคุณดำรงตำแหน่งนี้

ดังที่เราได้เรียนรู้ไปแล้วก่อนหน้านี้การวิเคราะห์ธุรกิจเป็นกระบวนการที่คุณพยายามทำความเข้าใจองค์กรธุรกิจและระบุโอกาสประเด็นปัญหาปัญหาและการพบปะผู้คนที่หลากหลายซึ่งมีบทบาทและความรับผิดชอบที่หลากหลายเช่น CEO รองประธานกรรมการและ เข้าใจความต้องการทางธุรกิจของตน

โดยพื้นฐานแล้วการวิเคราะห์ธุรกิจมี 3 ประเภทซึ่งเราสามารถแบ่งออกเป็น -

  • Strategic Analysis- การวิเคราะห์ธุรกิจเชิงกลยุทธ์เกี่ยวข้องกับงานก่อนโครงการ เป็นวิธีการหรือกระบวนการในการระบุปัญหาทางธุรกิจการกำหนดกลยุทธ์ทางธุรกิจเป้าหมายและวัตถุประสงค์เพื่อช่วยเหลือผู้บริหารระดับสูง จัดทำรายงานข้อมูลการจัดการสำหรับกระบวนการตัดสินใจที่มีประสิทธิภาพ

  • Tactical Analysis - เกี่ยวข้องกับความรู้เกี่ยวกับเทคนิคการวิเคราะห์ธุรกิจเฉพาะเพื่อนำไปใช้ในเวลาที่เหมาะสมในโครงการที่เหมาะสม

  • Operational Analysis- ในการวิเคราะห์ธุรกิจประเภทนี้เรามุ่งเน้นไปที่ด้านธุรกิจโดยใช้ประโยชน์จากเทคโนโลยีสารสนเทศ นอกจากนี้ยังเป็นกระบวนการศึกษาระบบการปฏิบัติงานโดยมีจุดมุ่งหมายเพื่อระบุโอกาสในการปรับปรุงธุรกิจ

สำหรับการวิเคราะห์แต่ละประเภทจะมีชุดเครื่องมือที่มีอยู่ในตลาดและขึ้นอยู่กับความต้องการและข้อกำหนดขององค์กรซึ่งจะใช้

อย่างไรก็ตามในการกำหนดข้อกำหนดทางธุรกิจให้เป็นข้อมูลที่เข้าใจได้ BA ที่ดีจะใช้เทคนิคการค้นหาข้อเท็จจริงการสัมภาษณ์การทบทวนเอกสารแบบสอบถามการสุ่มตัวอย่างและการวิจัยในกิจกรรมประจำวันของพวกเขา

ข้อกำหนดด้านฟังก์ชันและไม่ใช้งาน

เราสามารถแบ่งความต้องการออกเป็นสองประเภทหลัก ๆ เช่นข้อกำหนดด้านฟังก์ชันและข้อกำหนดไม่ทำงาน

สำหรับโครงการเทคโนโลยีทั้งหมดข้อกำหนดด้านฟังก์ชันและไม่ใช้งานจะต้องแยกและวิเคราะห์แยกกัน

การกำหนดเครื่องมือที่เหมาะสมและเทคนิคที่เหมาะสมอาจเป็นความท้าทายที่น่ากลัว ไม่ว่าคุณจะใช้แอปพลิเคชันใหม่เอี่ยมหรือทำการเปลี่ยนแปลงแอปพลิเคชันที่มีอยู่ การพิจารณาเทคนิคที่เหมาะสมสำหรับกระบวนการทำงานเป็นศิลปะด้วยตัวมันเอง

ภาพรวมของเทคนิคการวิเคราะห์ธุรกิจที่ใช้กันอย่างแพร่หลายในตลาดปัจจุบัน -

กระบวนการ เทคนิค การส่งมอบตามกระบวนการ (ผลลัพธ์)
เพื่อกำหนดข้อกำหนดในการทำงานและไม่ใช้งานได้
  • JAD เซสชัน
  • สถานการณ์และกรณีการใช้งาน
  • การสร้างแบบจำลององค์กร
  • การสร้างแบบจำลองขอบเขต
  • การสลายตัวตามหน้าที่
  • Interviews
  • การสังเกต (Job Shadowing)
  • กลุ่มเป้าหมาย
  • การยอมรับและการประเมินผล
  • แผนภาพลำดับ
  • เรื่องราวของผู้ใช้
  • Brainstorming
  • Storyboarding
  • Prototyping
  • Walk-through ที่มีโครงสร้าง
  • การวิเคราะห์เหตุการณ์
  • การวิเคราะห์กฎทางธุรกิจ
  • การประชุมเชิงปฏิบัติการความต้องการ
  • การวิเคราะห์ความเสี่ยง
  • การวิเคราะห์สาเหตุที่แท้จริง

Business Requirements Documents -

  • ข้อกำหนดทางธุรกิจและการทำงาน
  • ข้อกำหนดที่ไม่ใช่หน้าที่
  • กฎทางธุรกิจ
  • ข้อกำหนด Matrix Traceability

Common Template -

  • เอกสารข้อกำหนดทางธุรกิจ

การใช้เครื่องมือและกระบวนการ

แม้ว่านักวิเคราะห์ธุรกิจจะมีเครื่องมือและขั้นตอนต่างๆมากมาย แต่ทุกอย่างขึ้นอยู่กับแนวทางปฏิบัติในปัจจุบันขององค์กรและวิธีที่พวกเขาต้องการใช้

ตัวอย่างเช่น, root-cause analysis ใช้เมื่อมีความต้องการที่จะเจาะลึกลงไปในพื้นที่หรือหน้าที่สำคัญบางอย่าง

อย่างไรก็ตามเอกสารข้อกำหนดทางธุรกิจเป็นวิธีที่ได้รับความนิยมและได้รับการยอมรับมากที่สุดในการวางข้อกำหนดในรูปแบบเอกสาร

ในบทต่อ ๆ ไปเราจะพูดคุยเกี่ยวกับเทคนิคข้างต้นในเชิงลึก

การวิเคราะห์ธุรกิจ - เซสชัน JAD

Joint Application Development (JAD) เป็นกระบวนการที่ใช้ในการรวบรวมข้อกำหนดทางธุรกิจในขณะที่พัฒนาระบบข้อมูลใหม่สำหรับ บริษัท กระบวนการ JAD อาจรวมถึงแนวทางในการเพิ่มการมีส่วนร่วมของผู้ใช้การเร่งการพัฒนาและการปรับปรุงคุณภาพของข้อกำหนด ความตั้งใจของเซสชั่น JAD คือการรวมผู้เชี่ยวชาญในหัวข้อ / นักวิเคราะห์ธุรกิจหรือผู้เชี่ยวชาญด้านไอทีเพื่อนำเสนอโซลูชัน

นักวิเคราะห์ธุรกิจคือผู้ที่มีปฏิสัมพันธ์กับทั้งกลุ่มและรวบรวมข้อมูลวิเคราะห์และนำออกเอกสาร เขามีบทบาทสำคัญมากในเซสชั่น JAD

การใช้ JAD Session

เซสชัน JAD เป็นเวิร์กช็อปที่มีโครงสร้างสูงและอำนวยความสะดวกซึ่งรวบรวมผู้มีอำนาจตัดสินใจของลูกค้าและเจ้าหน้าที่ไอทีเพื่อผลิตสิ่งส่งมอบที่มีคุณภาพสูงในช่วงเวลาสั้น ๆ

กล่าวอีกนัยหนึ่งเซสชัน JAD ช่วยให้ลูกค้าและนักพัฒนาสามารถตกลงกันได้อย่างรวดเร็วเกี่ยวกับขอบเขตวัตถุประสงค์และข้อกำหนดพื้นฐานของโครงการหรือในกรณีที่ไม่เกิดข้อตกลงซึ่งหมายความว่าโครงการจะต้องได้รับการประเมินใหม่

พูดง่ายๆคือเซสชัน JAD สามารถทำได้

  • Simplify - รวมการประชุมและการโทรศัพท์หลายเดือนไว้ในเวิร์กชอปที่มีโครงสร้าง

  • Identify - ประเด็นปัญหาและผู้เข้าร่วม

  • Quantify - ความต้องการข้อมูลและการประมวลผล

  • Clarify - ตกผลึกและชี้แจงข้อกำหนดทั้งหมดที่ตกลงกันในเซสชั่น

  • Unify - เอาต์พุตจากเฟสหนึ่งของการพัฒนาจะถูกป้อนไปยังขั้นต่อไป

  • Satisfy- ลูกค้ากำหนดระบบ ดังนั้นจึงเป็นระบบของพวกเขา การมีส่วนร่วมร่วมกันนำมาซึ่งส่วนแบ่งในผลลัพธ์ พวกเขามุ่งมั่นที่จะทำให้ระบบประสบความสำเร็จ

ผู้เข้าร่วมในเซสชัน JAD

ผู้เข้าร่วมที่เกี่ยวข้องในเซสชัน JAD มีดังนี้ -

ผู้สนับสนุนผู้บริหาร

ผู้สนับสนุนผู้บริหารคือผู้ที่ขับเคลื่อนโครงการ─เจ้าของระบบ โดยปกติพวกเขามาจากตำแหน่งที่สูงกว่าและสามารถตัดสินใจและจัดหากลยุทธ์การวางแผนและทิศทางที่จำเป็น

ผู้เชี่ยวชาญเรื่อง

เหล่านี้คือผู้ใช้ทางธุรกิจและผู้เชี่ยวชาญภายนอกที่จำเป็นสำหรับการประชุมเชิงปฏิบัติการที่ประสบความสำเร็จ ผู้เชี่ยวชาญด้านเนื้อหาคือกระดูกสันหลังของเซสชัน JAD พวกเขาจะขับเคลื่อนการเปลี่ยนแปลง

วิทยากร

เขาเป็นประธานการประชุม เขาระบุปัญหาที่สามารถแก้ไขได้โดยเป็นส่วนหนึ่งของการประชุม ผู้อำนวยความสะดวกไม่ให้ข้อมูลในการประชุม

ผู้ใช้หลัก

ผู้ใช้หลักหรือเรียกอีกอย่างว่าผู้ใช้ขั้นสูงในบางกรณีถูกใช้แทนกันได้และยังคงแตกต่างกันไปในแต่ละ บริษัท โดยทั่วไปผู้ใช้หลักคือผู้ใช้ทางธุรกิจที่มีความสอดคล้องกับโครงการไอทีและรับผิดชอบในการกำหนดค่าโปรไฟล์ของสมาชิกในทีมระหว่างโครงการ

ตัวอย่างเช่นสมมติว่า John เป็นผู้ใช้หลักและ Nancy Evan เป็นผู้ใช้ระบบ SAP ในกรณีนี้ Nancy และ Evan ไม่มีสิทธิ์เข้าถึงเพื่อเปลี่ยนฟังก์ชันการทำงานและโปรไฟล์ในขณะที่ John ที่เป็นผู้ใช้หลักสามารถเข้าถึงเพื่อแก้ไขโปรไฟล์ด้วยการอนุญาตเพิ่มเติม

แนวทางของ JAD เมื่อเปรียบเทียบกับแนวทางปฏิบัติแบบเดิม ๆ แล้วคิดว่าจะนำไปสู่เวลาในการพัฒนาที่รวดเร็วขึ้นและความพึงพอใจของลูกค้ามากขึ้นเนื่องจากลูกค้ามีส่วนร่วมตลอดกระบวนการพัฒนา ในการเปรียบเทียบแนวทางดั้งเดิมในการพัฒนาระบบนักพัฒนาจะตรวจสอบความต้องการของระบบและพัฒนาแอปพลิเคชันโดยข้อมูลของลูกค้าประกอบด้วยชุดการสัมภาษณ์

เทคนิคการรวบรวมความต้องการ

เทคนิคอธิบายวิธีการปฏิบัติงานภายใต้สถานการณ์เฉพาะ งานอาจไม่มีเทคนิคที่เกี่ยวข้องอย่างน้อยหนึ่งอย่าง เทคนิคควรเกี่ยวข้องกับงานอย่างน้อยหนึ่งงาน

ต่อไปนี้เป็นเทคนิคการรวบรวมข้อกำหนดที่รู้จักกันดี -

การระดมความคิด

การระดมความคิดใช้ในการรวบรวมความต้องการเพื่อให้ได้แนวคิดจากกลุ่มคนให้ได้มากที่สุด โดยทั่วไปใช้เพื่อระบุวิธีแก้ปัญหาที่เป็นไปได้และชี้แจงรายละเอียดของโอกาส

การวิเคราะห์เอกสาร

การตรวจสอบเอกสารของระบบที่มีอยู่สามารถช่วยได้ในการสร้างเอกสารกระบวนการ AS – IS ตลอดจนการวิเคราะห์ช่องว่างสำหรับการกำหนดขอบเขตของโครงการการโยกย้าย ในโลกแห่งอุดมคติเราจะทบทวนข้อกำหนดที่ผลักดันการสร้างระบบที่มีอยู่ซึ่งเป็นจุดเริ่มต้นในการจัดทำเอกสารข้อกำหนดปัจจุบัน ข้อมูลนักเก็ตมักถูกฝังอยู่ในเอกสารที่มีอยู่ซึ่งช่วยให้เราถามคำถามโดยเป็นส่วนหนึ่งของการตรวจสอบความสมบูรณ์ของข้อกำหนด

กลุ่มเป้าหมาย

กลุ่มโฟกัสคือการรวมตัวกันของบุคคลที่เป็นตัวแทนของผู้ใช้หรือลูกค้าของผลิตภัณฑ์เพื่อรับคำติชม สามารถรวบรวมข้อเสนอแนะเกี่ยวกับความต้องการ / โอกาส / ปัญหาเพื่อระบุความต้องการหรือสามารถรวบรวมเพื่อตรวจสอบและปรับแต่งข้อกำหนดที่ได้รับมาแล้ว รูปแบบของการวิจัยตลาดนี้แตกต่างจากการระดมความคิดตรงที่เป็นกระบวนการจัดการกับผู้เข้าร่วมที่เฉพาะเจาะจง

การวิเคราะห์อินเทอร์เฟซ

อินเทอร์เฟซสำหรับผลิตภัณฑ์ซอฟต์แวร์อาจเป็นมนุษย์หรือเครื่องจักร การผสานรวมกับระบบและอุปกรณ์ภายนอกเป็นเพียงอินเทอร์เฟซอื่น แนวทางการออกแบบที่เน้นผู้ใช้มีประสิทธิภาพมากในการสร้างซอฟต์แวร์ที่ใช้งานได้ การวิเคราะห์อินเทอร์เฟซ - การตรวจสอบจุดติดต่อกับระบบภายนอกอื่น ๆ เป็นสิ่งสำคัญเพื่อให้แน่ใจว่าเราไม่มองข้ามข้อกำหนดที่ผู้ใช้มองไม่เห็นในทันที

สัมภาษณ์

การสัมภาษณ์ผู้มีส่วนได้ส่วนเสียและผู้ใช้มีความสำคัญต่อการสร้างซอฟต์แวร์ที่ยอดเยี่ยม หากไม่เข้าใจเป้าหมายและความคาดหวังของผู้ใช้และผู้มีส่วนได้ส่วนเสียเราก็ไม่น่าจะทำให้พวกเขาพอใจได้ นอกจากนี้เรายังต้องตระหนักถึงมุมมองของผู้ให้สัมภาษณ์แต่ละคนเพื่อที่เราจะได้ชั่งน้ำหนักและระบุข้อมูลของพวกเขาได้อย่างเหมาะสม การฟังเป็นทักษะที่ช่วยให้นักวิเคราะห์ที่ยอดเยี่ยมได้รับคุณค่าจากการสัมภาษณ์มากกว่านักวิเคราะห์ทั่วไป

การสังเกต

จากการสังเกตผู้ใช้นักวิเคราะห์สามารถระบุขั้นตอนกระบวนการขั้นตอนจุดเจ็บปวดและโอกาสในการปรับปรุง การสังเกตอาจเป็นแบบพาสซีฟหรือแอคทีฟ (ถามคำถามขณะสังเกต) การสังเกตแบบพาสซีฟจะดีกว่าสำหรับการรับข้อเสนอแนะเกี่ยวกับต้นแบบ (เพื่อปรับแต่งข้อกำหนด) ซึ่งการสังเกตเชิงรุกจะมีประสิทธิภาพมากกว่าในการทำความเข้าใจกระบวนการทางธุรกิจที่มีอยู่ สามารถใช้วิธีใดก็ได้

การสร้างต้นแบบ

การสร้างต้นแบบเป็นเทคนิคที่ค่อนข้างทันสมัยในการรวบรวมข้อกำหนด ในแนวทางนี้คุณรวบรวมข้อกำหนดเบื้องต้นที่คุณใช้เพื่อสร้างโซลูชันเวอร์ชันเริ่มต้น - ต้นแบบ คุณแสดงสิ่งนี้ให้กับลูกค้าซึ่งจะให้ข้อกำหนดเพิ่มเติมแก่คุณ คุณเปลี่ยนแอปพลิเคชันและวนรอบกับไคลเอนต์อีกครั้ง กระบวนการซ้ำ ๆ นี้ดำเนินต่อไปจนกว่าผลิตภัณฑ์จะตรงตามความต้องการทางธุรกิจจำนวนมากหรือสำหรับการทำซ้ำตามจำนวนที่ตกลงไว้

การประชุมเชิงปฏิบัติการความต้องการ

การประชุมเชิงปฏิบัติการจะมีประสิทธิภาพมากสำหรับการรวบรวมความต้องการ มีโครงสร้างมากกว่าเซสชันการระดมความคิดฝ่ายที่เกี่ยวข้องร่วมมือกันเพื่อจัดทำเอกสารข้อกำหนด วิธีหนึ่งในการจับภาพการทำงานร่วมกันคือการสร้างสิ่งประดิษฐ์แบบจำลองโดเมน (เช่นไดอะแกรมแบบคงที่ไดอะแกรมกิจกรรม) การประชุมเชิงปฏิบัติการจะมีประสิทธิภาพมากกว่ากับนักวิเคราะห์สองคนมากกว่าหนึ่งคน

วิศวกรรมย้อนกลับ

เมื่อโครงการย้ายข้อมูลไม่สามารถเข้าถึงเอกสารที่เพียงพอของระบบที่มีอยู่วิศวกรรมย้อนกลับจะระบุสิ่งที่ระบบทำ จะไม่ระบุว่าระบบควรทำอะไรและจะไม่ระบุว่าระบบทำสิ่งผิดพลาดเมื่อใด

แบบสำรวจ / แบบสอบถาม

เมื่อรวบรวมข้อมูลจากคนจำนวนมาก - มากเกินไปที่จะสัมภาษณ์ด้วยข้อ จำกัด ด้านงบประมาณและเวลา - สามารถใช้แบบสำรวจหรือแบบสอบถามได้ แบบสำรวจสามารถบังคับให้ผู้ใช้เลือกจากตัวเลือกให้คะแนนบางสิ่งบางอย่าง (“ เห็นด้วยอย่างยิ่งเห็นด้วย…”) หรือมีคำถามปลายเปิดที่ให้คำตอบในรูปแบบอิสระ การออกแบบแบบสำรวจเป็นเรื่องยากคำถามอาจทำให้ผู้ตอบมีอคติ

เอกสารข้อกำหนดการใช้งาน

เอกสารข้อกำหนดการใช้งาน (FRD) เป็นคำสั่งอย่างเป็นทางการของข้อกำหนดการทำงานของแอปพลิเคชัน มีวัตถุประสงค์เดียวกับสัญญา ที่นี่นักพัฒนาตกลงที่จะให้ความสามารถที่ระบุ ลูกค้าตกลงที่จะพบผลิตภัณฑ์ที่น่าพอใจหากมีความสามารถที่ระบุไว้ใน FRD

ข้อกำหนดในการทำงานจะจับพฤติกรรมที่ตั้งใจไว้ของระบบ พฤติกรรมนี้อาจแสดงเป็นบริการงานหรือฟังก์ชันที่ระบบจำเป็นต้องดำเนินการ เอกสารควรได้รับการปรับแต่งให้เหมาะสมกับความต้องการของโครงการนั้น ๆ พวกเขากำหนดสิ่งต่างๆเช่นการคำนวณระบบการจัดการและการประมวลผลข้อมูลส่วนต่อประสานกับผู้ใช้และการโต้ตอบกับแอปพลิเคชัน

เอกสารข้อกำหนดการใช้งาน (FRD) มีลักษณะดังต่อไปนี้ -

  • แสดงให้เห็นว่าแอปพลิเคชันให้คุณค่าในแง่ของวัตถุประสงค์ทางธุรกิจและกระบวนการทางธุรกิจในอีกไม่กี่ปีข้างหน้า

  • ประกอบด้วยชุดข้อกำหนดที่สมบูรณ์สำหรับแอปพลิเคชัน มันไม่มีที่ว่างสำหรับใครที่จะถือว่าสิ่งที่ไม่ได้ระบุไว้ใน FRD

  • เป็นโซลูชันที่เป็นอิสระ ERD คือคำแถลงว่าแอปพลิเคชันต้องทำอะไรไม่ใช่วิธีการทำงาน FRD ไม่ผูกมัดนักพัฒนาในการออกแบบ ด้วยเหตุนี้การอ้างอิงใด ๆ เกี่ยวกับการใช้เทคโนโลยีเฉพาะจึงไม่เหมาะสมอย่างสิ้นเชิงใน FRD

ข้อกำหนดการใช้งานควรมีดังต่อไปนี้ -

  • คำอธิบายของ data ที่จะเข้าสู่ระบบ

  • คำอธิบายของ operations ดำเนินการโดยแต่ละหน้าจอ

  • คำอธิบายของ work-flows ดำเนินการโดยระบบ

  • คำอธิบายของ system reports หรือเอาต์พุตอื่น ๆ

  • ใครสามารถเข้าสู่ไฟล์ data เข้าสู่ระบบ?

  • ระบบตรงตามความเหมาะสมอย่างไร regulatory requirements?

ข้อกำหนดการใช้งานได้รับการออกแบบมาเพื่อให้ผู้ชมทั่วไปอ่านได้ ผู้อ่านควรเข้าใจระบบ แต่ไม่จำเป็นต้องมีความรู้ทางเทคนิคในการทำความเข้าใจเอกสารนี้

ข้อกำหนดการทำงานที่ส่งมอบ

เอกสารข้อกำหนดทางธุรกิจ (BRD) ประกอบด้วย -

  • Functional Requirements- เอกสารที่มีข้อกำหนดโดยละเอียดสำหรับระบบที่กำลังพัฒนา ข้อกำหนดเหล่านี้กำหนดคุณสมบัติการทำงานและความสามารถที่ระบบต้องมี ตรวจสอบให้แน่ใจว่าสมมติฐานและข้อ จำกัด ใด ๆ ที่ระบุใน Business Case ยังคงถูกต้องและเป็นปัจจุบัน

  • Business Process Model - แบบจำลองสถานะปัจจุบันของกระบวนการ ("ตามสภาพ" แบบจำลอง) หรือแนวคิดว่ากระบวนการควรจะเป็นอย่างไร ("เป็น" แบบจำลอง)

  • System Context Diagram - แผนภาพบริบทแสดงขอบเขตของระบบเอนทิตีภายนอกและภายในที่โต้ตอบกับระบบและกระแสข้อมูลที่เกี่ยวข้องระหว่างเอนทิตีภายนอกและภายในเหล่านี้

  • Flow Diagrams (as-is or to-be)- แผนภาพแสดงลำดับขั้นตอนของการดำเนินการหรือการเคลื่อนไหวของข้อมูลในกระบวนการทางธุรกิจ รวมแผนภาพการไหลอย่างน้อยหนึ่งรายการขึ้นอยู่กับความซับซ้อนของแบบจำลอง

  • Business Rules and Data Requirements - กฎทางธุรกิจกำหนดหรือ จำกัด ลักษณะบางอย่างของธุรกิจและใช้เพื่อกำหนดข้อ จำกัด ของข้อมูลค่าเริ่มต้นช่วงค่าจำนวนสมาชิกประเภทข้อมูลการคำนวณข้อยกเว้นองค์ประกอบที่จำเป็นและความสมบูรณ์เชิงสัมพันธ์ของข้อมูล

  • Data Models - แผนภาพความสัมพันธ์ของเอนทิตีคำอธิบายเอนทิตีแผนภาพคลาส

  • Conceptual Model - การแสดงผลระดับสูงของเอนทิตีที่แตกต่างกันสำหรับฟังก์ชันทางธุรกิจและความสัมพันธ์ระหว่างกัน

  • Logical Model - แสดงให้เห็นถึงเอนทิตีคุณลักษณะและความสัมพันธ์เฉพาะที่เกี่ยวข้องกับฟังก์ชันทางธุรกิจและแสดงถึงคำจำกัดความลักษณะและความสัมพันธ์ของข้อมูลในสภาพแวดล้อมทางธุรกิจทางเทคนิคหรือแนวความคิด

  • Data Dictionary and Glossary - การรวบรวมข้อมูลโดยละเอียดเกี่ยวกับองค์ประกอบข้อมูลฟิลด์ตารางและเอนทิตีอื่น ๆ ที่ประกอบด้วยแบบจำลองข้อมูลที่อยู่ภายใต้ฐานข้อมูลหรือระบบการจัดการข้อมูลที่คล้ายคลึงกัน

  • Stakeholder Map- ระบุผู้มีส่วนได้ส่วนเสียทั้งหมดที่ได้รับผลกระทบจากการเปลี่ยนแปลงที่เสนอและระดับอิทธิพล / อำนาจของพวกเขาสำหรับข้อกำหนด เอกสารนี้ได้รับการพัฒนาในขั้นตอนการเริ่มต้นของ Project Management Methodology (PMM) และเป็นของ Project Manager แต่ทีมงานของโครงการจำเป็นต้องได้รับการปรับปรุงเนื่องจากมีการระบุผู้มีส่วนได้ส่วนเสียใหม่ / ที่เปลี่ยนแปลงตลอดทั้งกระบวนการ

  • Requirements Traceability Matrix - ตารางที่แสดงการเชื่อมโยงเชิงตรรกะระหว่างข้อกำหนดการทำงานของแต่ละบุคคลและสิ่งประดิษฐ์ระบบประเภทอื่น ๆ รวมถึงข้อกำหนดด้านการทำงานอื่น ๆ กรณีการใช้งาน / เรื่องราวของผู้ใช้องค์ประกอบสถาปัตยกรรมและการออกแบบโมดูลโค้ดกรณีทดสอบและกฎทางธุรกิจ

ข้อกำหนดข้อกำหนดของซอฟต์แวร์

ข้อกำหนดข้อกำหนดของซอฟต์แวร์ (SRS) คือเอกสารที่ใช้เป็นสื่อกลางในการสื่อสารระหว่างลูกค้า ข้อกำหนดข้อกำหนดซอฟต์แวร์ในรูปแบบพื้นฐานที่สุดคือเอกสารที่เป็นทางการที่ใช้ในการสื่อสารข้อกำหนดซอฟต์แวร์ระหว่างลูกค้าและผู้พัฒนา

เอกสาร SRS มุ่งเน้นไปที่ WHAT ต้องทำและหลีกเลี่ยงวิธีแก้ปัญหาอย่างระมัดระวัง (how to do). ทำหน้าที่เป็นสัญญาระหว่างทีมพัฒนาและลูกค้า ข้อกำหนดในขั้นตอนนี้เขียนขึ้นโดยใช้คำศัพท์เฉพาะของผู้ใช้ปลายทาง หากจำเป็นต่อไปจะมีการพัฒนาข้อกำหนดข้อกำหนดอย่างเป็นทางการจากนั้น

SRS เป็นคำอธิบายที่สมบูรณ์เกี่ยวกับลักษณะการทำงานของระบบที่จะพัฒนาและอาจรวมถึงชุดของกรณีการใช้งานที่อธิบายการโต้ตอบที่ผู้ใช้จะมีกับซอฟต์แวร์

วัตถุประสงค์ของ SRS

SRS เป็นเครื่องมือสื่อสารระหว่างลูกค้า / ลูกค้านักวิเคราะห์ธุรกิจนักพัฒนาระบบทีมซ่อมบำรุง นอกจากนี้ยังสามารถเป็นสัญญาระหว่างผู้ซื้อและซัพพลายเออร์

  • มันจะให้รากฐานที่มั่นคงสำหรับขั้นตอนการออกแบบ
  • รองรับการจัดการและควบคุมโครงการ
  • ช่วยในการควบคุมและวิวัฒนาการของระบบ

ข้อกำหนดข้อกำหนดของซอฟต์แวร์ควรสมบูรณ์สอดคล้องตรวจสอบย้อนกลับได้ไม่คลุมเครือและตรวจสอบได้

สิ่งต่อไปนี้ควรระบุไว้ในข้อกำหนดของระบบ -

  • กำหนดหน้าที่ของระบบ
  • กำหนดการแบ่งพาร์ติชันฟังก์ชันฮาร์ดแวร์ / ซอฟต์แวร์
  • กำหนดข้อกำหนดประสิทธิภาพ
  • กำหนดพาร์ติชันประสิทธิภาพของฮาร์ดแวร์ / ซอฟต์แวร์
  • กำหนดข้อกำหนดด้านความปลอดภัย
  • กำหนด User Interface (คู่มือผู้ใช้)
  • จัดเตรียมภาพวาด / คำแนะนำในการติดตั้ง
  • เทมเพลตข้อกำหนดข้อกำหนดซอฟต์แวร์

ประวัติการแก้ไข

วันที่ คำอธิบาย ผู้เขียน ความคิดเห็น
<วันที่> <เวอร์ชัน 1> <ชื่อของคุณ> <การแก้ไขครั้งแรก>

การอนุมัติเอกสาร

ข้อกำหนดข้อกำหนดซอฟต์แวร์ต่อไปนี้ได้รับการยอมรับและรับรองโดยสิ่งต่อไปนี้ -

ลายเซ็น พิมพ์ชื่อ หัวข้อ วันที่
<ชื่อของคุณ> Lead Software Eng.
เดวิด ผู้สอน

การวิเคราะห์ธุรกิจ - การใช้งานกรณี

หนึ่งในเก้าแผนภาพของ UML คือ Use-case Diagram สิ่งเหล่านี้ไม่เพียง แต่เป็นข้อกำหนดที่สำคัญ แต่จำเป็นสำหรับโครงการซอฟต์แวร์ โดยทั่วไปจะใช้ในวงจรชีวิตของซอฟต์แวร์ ดังที่เราทราบว่ามีหลายช่วงในวงจรการพัฒนาและขั้นตอนที่ใช้มากที่สุดสำหรับกรณีการใช้งานจะอยู่ในช่วงการรวบรวมข้อกำหนด

Use-Case คืออะไร?

use-case อธิบายลำดับของการกระทำที่ดำเนินการโดยระบบที่ให้คุณค่าแก่นักแสดง กรณีการใช้งานอธิบายถึงพฤติกรรมของระบบภายใต้เงื่อนไขต่างๆเมื่อตอบสนองต่อคำร้องขอจากผู้มีส่วนได้ส่วนเสียที่เรียกว่าprimary actor.

นักแสดงคือใครของระบบกล่าวอีกนัยหนึ่งคือเขาเป็นผู้ใช้ปลายทาง

ในวิศวกรรมซอฟต์แวร์และระบบ use-case คือรายการของขั้นตอนโดยทั่วไปจะกำหนดการโต้ตอบระหว่างบทบาท (รู้จักกันในชื่อ UML ว่า "ผู้แสดง") และระบบเพื่อให้บรรลุเป้าหมาย นักแสดงจะเป็นมนุษย์หรือระบบภายนอกก็ได้

use-case ระบุโฟลว์ของเหตุการณ์ในระบบ เกี่ยวข้องกับสิ่งที่ระบบดำเนินการมากขึ้นเพื่อดำเนินการตามลำดับขั้นตอน

ประโยชน์ของ Use-Case

กรณีการใช้งานให้ประโยชน์ดังต่อไปนี้ -

  • เป็นวิธีที่ง่ายในการจับความต้องการในการทำงานโดยเน้นที่มูลค่าเพิ่มให้กับผู้ใช้

  • กรณีการใช้งานค่อนข้างง่ายในการเขียนและอ่านเมื่อเทียบกับวิธีความต้องการแบบเดิม

  • กรณีการใช้งานบังคับให้นักพัฒนาคิดจากมุมมองของผู้ใช้ปลายทาง

  • กรณีใช้งานมีส่วนร่วมกับผู้ใช้ในกระบวนการความต้องการ

กายวิภาคของกรณีการใช้งาน

ชื่อ: ชื่อที่สื่อความหมายที่แสดงวัตถุประสงค์ของกรณีการใช้งาน

คำอธิบาย: อธิบายสิ่งที่ use-case ทำในสองประโยค

นักแสดง: รายชื่อนักแสดงที่เข้าร่วมในกรณีการใช้งาน

เงื่อนไขเบื้องต้น: เงื่อนไขที่ต้องปฏิบัติตามก่อนเริ่มกรณีการใช้งาน

กระแสของเหตุการณ์: คำอธิบายการโต้ตอบระหว่างระบบและนักแสดง

Post Condition : อธิบายสถานะของระบบหลังจาก use-case ได้รันหลักสูตรแล้ว

คำแนะนำสำหรับเทมเพลตกรณีการใช้งาน

บันทึกกรณีการใช้งานแต่ละรายการโดยใช้เทมเพลตที่ให้ไว้ในตอนท้ายของบทนี้ ส่วนนี้ให้คำอธิบายของแต่ละส่วนในเทมเพลตกรณีใช้งาน

การระบุกรณีใช้งาน

  • Use-Case ID- กำหนดตัวระบุตัวเลขที่ไม่ซ้ำกันให้แต่ละกรณีการใช้งานในรูปแบบลำดับชั้น: XY กรณีการใช้งานที่เกี่ยวข้องสามารถจัดกลุ่มในลำดับชั้นได้ ข้อกำหนดการใช้งานสามารถตรวจสอบย้อนกลับไปยัง use-case ที่มีข้อความกำกับ

  • Use-Case Name- ระบุชื่อที่กระชับและมุ่งเน้นผลลัพธ์สำหรับกรณีการใช้งาน สิ่งเหล่านี้สะท้อนให้เห็นถึงงานที่ผู้ใช้ต้องการเพื่อให้บรรลุโดยใช้ระบบ รวมกริยาการกระทำและคำนาม ตัวอย่างบางส่วน -

    • ดูข้อมูลหมายเลขชิ้นส่วน

    • ทำเครื่องหมายที่มาของไฮเปอร์เท็กซ์ด้วยตนเองและสร้างลิงก์ไปยังเป้าหมาย

    • สั่งซื้อซีดีพร้อมซอฟต์แวร์เวอร์ชันอัพเดต

ประวัติการใช้กรณีศึกษา

ในที่นี้เรากล่าวถึงชื่อบุคคลที่เป็นผู้มีส่วนได้ส่วนเสียในเอกสาร Usecase

  • Created By - ระบุชื่อของบุคคลที่บันทึกกรณีการใช้งานนี้ในตอนแรก

  • Date Created - ป้อนวันที่ที่บันทึกกรณีการใช้งานครั้งแรก

  • Last Updated By - ระบุชื่อของบุคคลที่ทำการอัปเดตล่าสุดสำหรับคำอธิบายกรณีการใช้งาน

  • Date Last Updated - ป้อนวันที่ที่มีการอัปเดตกรณีการใช้งานล่าสุด

นิยามกรณีใช้งาน

ต่อไปนี้เป็นคำจำกัดความของแนวคิดหลักของ Use-Case -

นักแสดงชาย

นักแสดงคือบุคคลหรือหน่วยงานอื่นที่อยู่ภายนอกระบบซอฟต์แวร์ที่ระบุว่าใครโต้ตอบกับระบบและดำเนินการกรณีใช้งานเพื่อให้งานสำเร็จ ผู้แสดงที่แตกต่างกันมักจะสอดคล้องกับคลาสหรือบทบาทของผู้ใช้ที่แตกต่างกันซึ่งระบุจากชุมชนลูกค้าที่จะใช้ผลิตภัณฑ์ ตั้งชื่อนักแสดงที่จะแสดง usecase นี้

คำอธิบาย

ให้คำอธิบายสั้น ๆ เกี่ยวกับเหตุผลและผลลัพธ์ของกรณีการใช้งานนี้หรือคำอธิบายระดับสูงของลำดับของการดำเนินการและผลลัพธ์ของการดำเนินการกรณีการใช้งาน

เงื่อนไขเบื้องต้น

ระบุกิจกรรมที่ต้องเกิดขึ้นหรือเงื่อนไขใด ๆ ที่ต้องเป็นจริงก่อนที่จะเริ่มใช้กรณีการใช้งาน หมายเลขเงื่อนไขเบื้องต้นแต่ละรายการ

Examples

  • ยืนยันตัวตนของผู้ใช้แล้ว
  • คอมพิวเตอร์ของผู้ใช้มีหน่วยความจำว่างเพียงพอที่จะเปิดใช้งาน

เงื่อนไขการโพสต์

อธิบายสถานะของระบบในตอนท้ายของการดำเนินการกรณีใช้งาน ระบุเงื่อนไขการโพสต์แต่ละรายการ

Examples

  • เอกสารมีแท็ก SGML ที่ถูกต้องเท่านั้น
  • ราคาของสินค้าในฐานข้อมูลได้รับการอัปเดตด้วยค่าใหม่

ลำดับความสำคัญ

ระบุลำดับความสำคัญสัมพัทธ์ของการใช้ฟังก์ชันที่จำเป็นเพื่อให้สามารถเรียกใช้ usecase นี้ได้ รูปแบบลำดับความสำคัญที่ใช้จะต้องเหมือนกับที่ใช้ในข้อกำหนดข้อกำหนดของซอฟต์แวร์

ความถี่ในการใช้งาน

ประมาณจำนวนครั้งที่นักแสดงจะใช้กรณีนี้ต่อหน่วยเวลาที่เหมาะสม

หลักสูตรปกติของกิจกรรม

ให้คำอธิบายโดยละเอียดเกี่ยวกับการดำเนินการของผู้ใช้และการตอบสนองของระบบที่จะเกิดขึ้นระหว่างการดำเนินการกรณีการใช้งานภายใต้เงื่อนไขปกติที่คาดไว้ ลำดับการโต้ตอบนี้จะนำไปสู่การบรรลุเป้าหมายที่ระบุไว้ในชื่อกรณีการใช้งานและคำอธิบายในท้ายที่สุด คำอธิบายนี้อาจเขียนเป็นคำตอบสำหรับคำถามสมมุติฐาน“ ฉันจะ <ทำงานที่ระบุไว้ในชื่อกรณีการใช้งาน> ให้สำเร็จได้อย่างไร?” วิธีนี้ทำได้ดีที่สุดโดยเป็นรายการการกระทำที่เป็นตัวเลขของนักแสดงสลับกับการตอบสนองที่ระบบจัดเตรียมไว้ให้

หลักสูตรทางเลือก

จัดทำเอกสารสถานการณ์การใช้งานอื่น ๆ ที่ถูกต้องตามกฎหมายซึ่งสามารถเกิดขึ้นภายในกรณีการใช้งานนี้แยกกันในส่วนนี้ ระบุหลักสูตรทางเลือกและอธิบายความแตกต่างตามลำดับขั้นตอนที่เกิดขึ้น หมายเลขหลักสูตรทางเลือกแต่ละหลักสูตรโดยใช้รหัสกรณีการใช้งานเป็นคำนำหน้าตามด้วย“ AC” เพื่อระบุว่า“ หลักสูตรทางเลือก” ตัวอย่าง: XYAC.1.

ข้อยกเว้น

อธิบายเงื่อนไขข้อผิดพลาดที่คาดว่าจะเกิดขึ้นระหว่างการดำเนินการของ usecase และกำหนดว่าระบบจะตอบสนองต่อเงื่อนไขเหล่านั้นอย่างไร นอกจากนี้อธิบายว่าระบบจะตอบสนองอย่างไรหากการดำเนินการกรณีใช้งานล้มเหลวด้วยเหตุผลบางประการที่ไม่คาดคิด หมายเลขแต่ละข้อยกเว้นโดยใช้รหัสกรณีการใช้งานเป็นคำนำหน้าตามด้วย“ EX” เพื่อระบุ“ ข้อยกเว้น” ตัวอย่าง: XYEX.1

รวม

ระบุกรณีการใช้งานอื่น ๆ ที่รวมอยู่ด้วย (“ เรียกว่า”) โดยกรณีการใช้งานนี้ ฟังก์ชันการทำงานทั่วไปที่ปรากฏในกรณีการใช้งานหลายกรณีสามารถแบ่งออกเป็นกรณีการใช้งานที่แยกจากกันซึ่งรวมอยู่ในฟังก์ชันที่ต้องการฟังก์ชันทั่วไปนั้น

ความต้องการพิเศษ

ระบุข้อกำหนดเพิ่มเติมใด ๆ เช่นข้อกำหนดที่ไม่สามารถใช้งานได้สำหรับกรณีการใช้งานที่อาจจำเป็นต้องได้รับการแก้ไขในระหว่างการออกแบบหรือการนำไปใช้งาน สิ่งเหล่านี้อาจรวมถึงข้อกำหนดด้านประสิทธิภาพหรือคุณลักษณะด้านคุณภาพอื่น ๆ

สมมติฐาน

ระบุสมมติฐานที่เกิดขึ้นในการวิเคราะห์ที่นำไปสู่การยอมรับกรณีการใช้งานนี้ลงในคำอธิบายผลิตภัณฑ์และเขียนคำอธิบายกรณีการใช้งาน

หมายเหตุและปัญหา

แสดงความคิดเห็นเพิ่มเติมเกี่ยวกับกรณีการใช้งานนี้หรือปัญหาที่ยังเปิดอยู่หรือ TBDs (To Be Determined) ที่ต้องได้รับการแก้ไข ระบุว่าใครจะแก้ไขปัญหาแต่ละอย่างวันที่ครบกำหนดและความละเอียดในท้ายที่สุดคืออะไร

การจัดการการเปลี่ยนแปลงและการควบคุมเวอร์ชัน

การควบคุมเวอร์ชันคือการจัดการการเปลี่ยนแปลงเอกสารเว็บไซต์ขนาดใหญ่และการรวบรวมข้อมูลอื่น ๆ โดยปกติการเปลี่ยนแปลงจะระบุด้วยตัวเลขหรือรหัสตัวอักษรเรียกว่าหมายเลขแก้ไขหรือระดับการแก้ไข การแก้ไขแต่ละครั้งจะเชื่อมโยงกับการประทับเวลาและบุคคลที่ทำการเปลี่ยนแปลง

Use-Case Diagrams

ส่วนสำคัญของ Unified Modeling Language (UML) คือสิ่งอำนวยความสะดวกสำหรับการวาด usecase ไดอะแกรม กรณีการใช้งานถูกใช้ในระหว่างขั้นตอนการวิเคราะห์ของโปรเจ็กต์เพื่อระบุและแบ่งการทำงานของระบบ พวกเขาแยกระบบออกเป็นตัวแสดงและกรณีการใช้งาน นักแสดงแสดงบทบาทที่ผู้ใช้ระบบสามารถเล่นได้

ผู้ใช้เหล่านั้นอาจเป็นมนุษย์คอมพิวเตอร์เครื่องอื่นฮาร์ดแวร์หรือแม้แต่ระบบซอฟต์แวร์อื่น ๆ เกณฑ์เดียวคือต้องอยู่ภายนอกกับส่วนของระบบที่แบ่งเป็น use-cases พวกเขาต้องจัดหาสิ่งเร้าให้กับส่วนนั้นของระบบและต้องได้รับผลลัพธ์จากมัน

กรณีการใช้งานแสดงถึงกิจกรรมที่นักแสดงดำเนินการด้วยความช่วยเหลือของระบบของคุณในการแสวงหาเป้าหมาย เราจำเป็นต้องกำหนดสิ่งที่ผู้ใช้ (นักแสดง) เหล่านั้นต้องการจากระบบ กรณีการใช้งานควรสะท้อนถึงความต้องการและเป้าหมายของผู้ใช้และควรเริ่มต้นโดยนักแสดง ธุรกิจนักแสดงลูกค้าที่เข้าร่วมในกรณีการใช้งานทางธุรกิจควรเชื่อมต่อกับกรณีการใช้งานโดยการเชื่อมโยง

การวาด Use-Case Diagrams

รูปด้านล่างแสดงให้เห็นว่า use-case อาจมีลักษณะเป็น UML schematic form ตัวเคสมีลักษณะเป็นวงรี นักแสดงจะวาดเป็นรูปแท่งเล็ก ๆ นักแสดงเชื่อมต่อกับเคสการใช้งานด้วยเส้น

Use-case 1 - เสมียนขายตรวจสอบรายการ

  • ลูกค้ากำหนดรายการที่เคาน์เตอร์
  • «ใช้» Swipe UPC Reader
  • ระบบค้นหารหัส UPC ในฐานข้อมูลการจัดหาคำอธิบายรายการและราคา
  • ระบบจะส่งเสียงบี๊บ
  • ระบบประกาศคำอธิบายรายการและราคาผ่านเอาต์พุตเสียง
  • ระบบเพิ่มราคาและประเภทสินค้าในใบแจ้งหนี้ปัจจุบัน
  • ระบบเพิ่มราคาเพื่อแก้ไขยอดรวมภาษี

ดังนั้นความสัมพันธ์«ใช้»จึงเหมือนกับการเรียกใช้ฟังก์ชันหรือรูทีนย่อยมาก

กรณีการใช้งานที่ใช้ในรูปแบบนี้เรียกว่ากรณีการใช้งานนามธรรมเนื่องจากไม่สามารถมีอยู่ได้ด้วยตัวเอง แต่ต้องใช้กรณีการใช้งานอื่น ๆ

ตัวอย่าง─กรณีใช้การถอน

เป้าหมายของลูกค้าที่เกี่ยวข้องกับตู้หยอดเงิน (ATM) ของเราคือการถอนเงิน ดังนั้นเราจึงเพิ่มWithdrawalกรณีใช้งาน การถอนเงินจากตู้หยอดเหรียญอาจเกี่ยวข้องกับธนาคารสำหรับธุรกรรมที่จะทำ ดังนั้นเราจึงเพิ่มนักแสดงอีกคน -Bank. นักแสดงทั้งสองที่เข้าร่วมในกรณีการใช้งานควรเชื่อมต่อกับกรณีการใช้งานโดยการเชื่อมโยง

ตู้หยอดเงินให้กรณีการใช้การถอนสำหรับลูกค้าและผู้ดำเนินการธนาคาร

ความสัมพันธ์ระหว่างนักแสดงและกรณีการใช้งาน

สามารถจัดระเบียบกรณีใช้งานโดยใช้ความสัมพันธ์ต่อไปนี้ -

  • Generalization
  • Association
  • Extend
  • Include

ลักษณะทั่วไประหว่าง Use-Cases

อาจมีบางกรณีที่นักแสดงเกี่ยวข้องกับกรณีการใช้งานที่คล้ายคลึงกัน ในกรณีเช่นนี้ Child use-case สืบทอดคุณสมบัติและพฤติกรรมของการใช้พาเรนต์ ดังนั้นเราจำเป็นต้องพูดถึงนักแสดงทั่วไปเพื่อแสดงการสืบทอดหน้าที่ พวกมันแสดงด้วยเส้นทึบที่มีหัวลูกศรสามเหลี่ยมกลวงขนาดใหญ่

การเชื่อมโยงระหว่างกรณีการใช้งาน

ความสัมพันธ์ระหว่างผู้แสดงและกรณีการใช้งานจะระบุไว้ในแผนภาพกรณีใช้งานด้วยเส้นทึบ การเชื่อมโยงเกิดขึ้นเมื่อใดก็ตามที่นักแสดงมีส่วนเกี่ยวข้องกับการโต้ตอบที่อธิบายโดยกรณีการใช้งาน

ขยาย

มีฟังก์ชันบางอย่างที่เรียกใช้ทางเลือก ในกรณีเช่นนี้จะใช้ความสัมพันธ์แบบขยายและแนบกฎส่วนขยาย สิ่งที่ต้องจำไว้ก็คือกรณีการใช้งานพื้นฐานควรสามารถทำหน้าที่ได้ด้วยตัวเองแม้ว่าจะไม่ได้เรียกใช้ usecase ที่ขยายออกมาก็ตาม

ความสัมพันธ์การขยายจะแสดงเป็นเส้นประโดยมีหัวลูกศรเปิดที่นำจากกรณีการใช้งานที่ขยายไปยังกรณีการใช้งานที่ขยาย (ฐาน) ลูกศรมีป้ายกำกับด้วยคำหลัก«ขยาย»

รวม

ใช้เพื่อแยกชิ้นส่วน use-case ที่ซ้ำกันในหลายกรณีการใช้งาน นอกจากนี้ยังใช้เพื่อลดความซับซ้อนของกรณีการใช้งานขนาดใหญ่โดยการแยกออกเป็นกรณีการใช้งานหลาย ๆ กรณีและเพื่อแยกส่วนทั่วไปของพฤติกรรมของกรณีการใช้งานสองกรณีขึ้นไป

รวมความสัมพันธ์ระหว่างกรณีการใช้งานซึ่งแสดงโดยลูกศรประกับหัวลูกศรเปิดจากกรณีการใช้งานพื้นฐานไปจนถึงกรณีการใช้งานที่รวมไว้ ลูกศรมีป้ายกำกับด้วยคำหลัก«รวม»

กรณีการใช้งานจัดการเฉพาะในข้อกำหนดการใช้งานสำหรับระบบเท่านั้น ข้อกำหนดอื่น ๆ เช่นกฎทางธุรกิจข้อกำหนดด้านคุณภาพของบริการและข้อ จำกัด ในการใช้งานจะต้องแสดงแยกกัน

แผนภาพที่แสดงด้านล่างเป็นตัวอย่างของแผนภาพกรณีใช้งานอย่างง่ายที่มีองค์ประกอบทั้งหมดที่ทำเครื่องหมายไว้

หลักการพื้นฐานสำหรับการประยุกต์ใช้กรณีการใช้งานให้ประสบความสำเร็จ

  • ทำให้มันง่ายโดยการบอกเล่าเรื่องราว
  • มีประสิทธิผลโดยไม่ต้องสมบูรณ์แบบ
  • เข้าใจภาพรวม
  • ระบุโอกาสในการใช้ซ้ำสำหรับกรณีการใช้งาน
  • เน้นคุณค่า
  • สร้างระบบเป็นชิ้น ๆ
  • ส่งมอบระบบทีละน้อย
  • ปรับให้เข้ากับความต้องการของทีม

เทมเพลต Use-Case

ที่นี่เราได้แสดงเทมเพลตตัวอย่างของ Use-Case ซึ่งนักวิเคราะห์ธุรกิจสามารถกรอกข้อมูลเพื่อให้ข้อมูลเป็นประโยชน์สำหรับทีมเทคนิคในการตรวจสอบข้อมูลเกี่ยวกับโครงการ

รหัสกรณีการใช้งาน:
ชื่อกรณีใช้งาน:
สร้างโดย: อัปเดตล่าสุดโดย
วันที่สร้าง: วันที่ปรับปรุงล่าสุด
นักแสดงชาย:
คำอธิบาย:
เงื่อนไขเบื้องต้น:
เงื่อนไขการโพสต์:
ลำดับความสำคัญ:
ความถี่ในการใช้งาน:
หลักสูตรปกติของกิจกรรม:
หลักสูตรทางเลือก:
ข้อยกเว้น:
รวมถึง:
ความต้องการพิเศษ:
สมมติฐาน:
หมายเหตุและประเด็น:

การวิเคราะห์ธุรกิจ - ความต้องการการจัดการ

การรวบรวมข้อกำหนดซอฟต์แวร์เป็นรากฐานของโครงการพัฒนาซอฟต์แวร์ทั้งหมด การร้องขอและรวบรวมข้อกำหนดทางธุรกิจเป็นขั้นตอนแรกที่สำคัญสำหรับทุกโครงการ เพื่อลดช่องว่างระหว่างข้อกำหนดทางธุรกิจและทางเทคนิคนักวิเคราะห์ธุรกิจจะต้องเข้าใจความต้องการของธุรกิจอย่างเต็มที่ภายในบริบทที่กำหนดปรับความต้องการเหล่านี้ให้สอดคล้องกับวัตถุประสงค์ทางธุรกิจและสื่อสารความต้องการอย่างเหมาะสมกับทั้งผู้มีส่วนได้ส่วนเสียและทีมพัฒนา

ผู้มีส่วนได้ส่วนเสียที่สำคัญต้องการให้ใครบางคนสามารถอธิบายความต้องการของลูกค้า / ลูกค้าเป็นภาษาอังกฤษธรรมดา สิ่งนี้จะเป็นประโยชน์ต่อพวกเขาจากการเข้าใจคุณค่าในระดับสูงหรือไม่? นี่จะเป็นจุดสนใจหลักเนื่องจากพวกเขาจะพยายามทำแผนที่เอกสารประกอบกับข้อกำหนดและวิธีที่ BA สามารถสื่อสารด้วยวิธีที่ดีที่สุด

เหตุใดโครงการจึงล้มเหลว

มีสาเหตุหลายประการที่ทำให้โครงการล้มเหลว แต่พื้นที่ส่วนกลางบางส่วนมีดังต่อไปนี้ -

  • ความล้มเหลวของตลาดและกลยุทธ์
  • ความล้มเหลวขององค์กรและการวางแผน
  • ความล้มเหลวด้านคุณภาพ
  • ความล้มเหลวในการเป็นผู้นำและการกำกับดูแล
  • ทักษะความรู้และความสามารถล้มเหลว
  • การมีส่วนร่วมการทำงานเป็นทีมและความล้มเหลวในการสื่อสาร

แก่นของปัญหาคือโครงการมีความซับซ้อนมากขึ้นการเปลี่ยนแปลงเกิดขึ้นและการสื่อสารเป็นสิ่งที่ท้าทาย

เหตุใดทีมที่ประสบความสำเร็จจึงจัดการความต้องการ

การจัดการความต้องการเป็นเรื่องเกี่ยวกับการรักษาทีมของคุณ in-sync และให้ visibility กับสิ่งที่เกิดขึ้นภายในโครงการ

เป็นสิ่งสำคัญอย่างยิ่งต่อความสำเร็จของโครงการของคุณสำหรับทั้งทีมในการทำความเข้าใจว่าคุณกำลังสร้างอะไรและทำไม - นั่นคือวิธีที่เรากำหนดการจัดการข้อกำหนด "เหตุผล" มีความสำคัญเนื่องจากให้บริบทของเป้าหมายข้อเสนอแนะและการตัดสินใจเกี่ยวกับข้อกำหนด

สิ่งนี้จะเพิ่มความสามารถในการคาดเดาความสำเร็จในอนาคตและปัญหาที่อาจเกิดขึ้นทำให้ทีมของคุณสามารถแก้ไขปัญหาต่างๆได้อย่างรวดเร็วและทำโครงการของคุณให้เสร็จทันเวลาและภายในงบประมาณ ในฐานะที่เป็นจุดเริ่มต้นทุกคนที่เกี่ยวข้องมีความเข้าใจพื้นฐานว่าข้อกำหนดคืออะไรและจะจัดการได้อย่างไร

เริ่มต้นด้วยพื้นฐาน

ข้อกำหนดคือเงื่อนไขหรือความสามารถที่จำเป็นสำหรับผู้มีส่วนได้ส่วนเสียในการแก้ปัญหาหรือบรรลุวัตถุประสงค์ เงื่อนไขหรือความสามารถที่ต้องปฏิบัติตามหรือครอบครองโดยระบบหรือระบบ ส่วนประกอบเพื่อให้เป็นไปตามสัญญามาตรฐานข้อกำหนดหรือเอกสารอื่น ๆ ที่กำหนดอย่างเป็นทางการ

ข้อกำหนดสามารถแสดงเป็นข้อความภาพร่างการจำลองหรือแบบจำลองโดยละเอียดข้อมูลใด ๆ ที่สื่อสารกับวิศวกรได้ดีที่สุดว่าจะสร้างอะไรและให้ผู้จัดการ QA ทดสอบสิ่งใด คุณอาจใช้คำศัพท์ที่แตกต่างกันเพื่อตอบสนองความต้องการทั้งนี้ขึ้นอยู่กับขั้นตอนการพัฒนาของคุณ

ความต้องการระดับสูงบางครั้งเรียกง่ายๆว่า needs หรือ goals. ภายในแนวทางปฏิบัติในการพัฒนาซอฟต์แวร์ข้อกำหนดอาจเรียกว่า "กรณีการใช้งาน" "คุณสมบัติ" หรือ "ข้อกำหนดด้านการทำงาน" โดยเฉพาะอย่างยิ่งในวิธีการพัฒนาแบบคล่องตัวข้อกำหนดมักถูกจับเป็นepics และ stories.

ไม่ว่าทีมของคุณจะเรียกพวกเขาว่าอะไรหรือคุณใช้กระบวนการอะไรก็ตาม ข้อกำหนดมีความสำคัญต่อการพัฒนาผลิตภัณฑ์ทั้งหมด หากไม่มีการกำหนดข้อกำหนดอย่างชัดเจนคุณอาจผลิตผลิตภัณฑ์ที่ไม่สมบูรณ์หรือมีข้อบกพร่องได้ ตลอดกระบวนการอาจมีคนจำนวนมากที่เกี่ยวข้องกับการกำหนดข้อกำหนด

ผู้มีส่วนได้ส่วนเสียอาจร้องขอคุณลักษณะที่อธิบายว่าผลิตภัณฑ์จะให้คุณค่าในการแก้ปัญหาอย่างไร นักออกแบบอาจกำหนดข้อกำหนดตามลักษณะหรือประสิทธิภาพของผลิตภัณฑ์ขั้นสุดท้ายจากมุมมองด้านการใช้งานหรืออินเทอร์เฟซผู้ใช้

นักวิเคราะห์ธุรกิจอาจสร้างข้อกำหนดของระบบที่เป็นไปตามข้อ จำกัด ทางเทคนิคหรือข้อ จำกัด ขององค์กร สำหรับผลิตภัณฑ์และแอปพลิเคชันซอฟต์แวร์ที่มีความซับซ้อนในปัจจุบันมักจะต้องใช้ข้อกำหนดหลายร้อยหรือหลายพันรายการเพื่อกำหนดขอบเขตของโครงการหรือรุ่นต่างๆให้เพียงพอ ดังนั้นจึงมีความจำเป็นที่ทีมจะต้องสามารถเข้าถึงทำงานร่วมกันอัปเดตและทดสอบข้อกำหนดแต่ละข้อจนถึงเสร็จสิ้นเนื่องจากข้อกำหนดจะเปลี่ยนแปลงไปตามธรรมชาติและมีวิวัฒนาการอยู่ตลอดเวลาในระหว่างกระบวนการพัฒนา

ตอนนี้เราได้กำหนดคุณค่าของการจัดการข้อกำหนดไว้ในระดับสูงแล้วเรามาเจาะลึกถึงปัจจัยพื้นฐาน 4 ประการที่สมาชิกในทีมและผู้มีส่วนได้ส่วนเสียทุกคนจะได้รับประโยชน์จากความเข้าใจ -

  • การวางแผนข้อกำหนดที่ดี:“ เรากำลังสร้างอะไรกันแน่”
  • การทำงานร่วมกันและการซื้อใน:“ แค่อนุมัติสเป็คแล้ว!”
  • การตรวจสอบย้อนกลับและการจัดการการเปลี่ยนแปลง:“ เดี๋ยวก่อนนักพัฒนารู้ไหมว่ามีการเปลี่ยนแปลงหรือไม่”
  • การประกันคุณภาพ:“ สวัสดีมีใครทดสอบสิ่งนี้บ้างไหม”

ทุกคนรู้หรือไม่ว่าเรากำลังสร้างอะไรและทำไม? นั่นคือคุณค่าของการจัดการความต้องการ

การทำงานร่วมกันและการซื้อจากผู้มีส่วนได้ส่วนเสีย

ทุกคนอยู่ในวงหรือไม่ เราได้รับการอนุมัติข้อกำหนดในการก้าวไปข้างหน้าหรือไม่? คำถามเหล่านี้เกิดขึ้นระหว่างรอบการพัฒนา จะดีมากถ้าทุกคนเห็นด้วยกับข้อกำหนด แต่สำหรับโครงการขนาดใหญ่ที่มีผู้มีส่วนได้ส่วนเสียจำนวนมากมักจะไม่เกิดขึ้น การพยายามให้ทุกคนเห็นพ้องกันอาจทำให้การตัดสินใจล่าช้าหรือแย่กว่านั้นคือไม่ได้ทำเลย การได้รับฉันทามติในทุกการตัดสินใจไม่ใช่เรื่องง่ายเสมอไป

ในทางปฏิบัติคุณไม่จำเป็นต้องต้องการ "ฉันทามติ" คุณต้องการ "ซื้อใน" จากกลุ่มและการอนุมัติจากผู้ที่มีอำนาจควบคุมเพื่อให้คุณสามารถเดินหน้าโครงการต่อไปได้ ด้วยฉันทามติคุณพยายามให้ทุกคนประนีประนอมและเห็นด้วยกับการตัดสินใจ ด้วยการ Buy-in คุณพยายามให้ผู้คนสนับสนุนวิธีแก้ปัญหาที่ดีที่สุดตัดสินใจอย่างชาญฉลาดและทำในสิ่งที่จำเป็นเพื่อก้าวไปข้างหน้า

คุณไม่จำเป็นต้องให้ทุกคนเห็นด้วยว่าการตัดสินใจนั้นดีที่สุด คุณต้องการให้ทุกคนช่วยสนับสนุนการตัดสินใจ การทำงานร่วมกันเป็นทีมสามารถช่วยในการรับการสนับสนุนในการตัดสินใจและการวางแผนข้อกำหนดที่ดี

ทีมที่ทำงานร่วมกันทำงานอย่างหนักเพื่อให้แน่ใจว่าทุกคนมีส่วนได้ส่วนเสียในโครงการและให้ข้อเสนอแนะ ทีมที่ทำงานร่วมกันแบ่งปันความคิดอย่างต่อเนื่องโดยทั่วไปจะมีการสื่อสารที่ดีขึ้นและมีแนวโน้มที่จะสนับสนุนการตัดสินใจเนื่องจากมีความรู้สึกผูกพันและเข้าใจเป้าหมายของโครงการร่วมกัน

เมื่อนักพัฒนาผู้ทดสอบหรือผู้มีส่วนได้ส่วนเสียอื่น ๆ รู้สึกว่า“ ไม่อยู่ในวงล้อม” ว่ามีปัญหาด้านการสื่อสารเกิดขึ้นผู้คนจะหงุดหงิดและโครงการล่าช้า เมื่อทุกคนซื้อในขอบเขตของงานแล้วจำเป็นที่จะต้องมีข้อกำหนดที่ชัดเจนและมีการจัดทำเอกสารอย่างดี การติดตามข้อกำหนดทั้งหมดเป็นสิ่งที่ยุ่งยาก

ลองนึกภาพว่ามีรายการสิ่งที่ต้องทำยาวเป็นไมล์ซึ่งเกี่ยวข้องกับการทำงานร่วมกันกับหลาย ๆ คนเพื่อทำให้เสร็จสมบูรณ์ คุณจะรักษารายการทั้งหมดให้ตรงได้อย่างไร? คุณจะติดตามได้อย่างไรว่าการเปลี่ยนแปลงรายการหนึ่งจะส่งผลต่อส่วนที่เหลือของโครงการอย่างไร นี่คือจุดที่การตรวจสอบย้อนกลับและการจัดการการเปลี่ยนแปลงเพิ่มมูลค่า

การวางแผนความต้องการที่ดี

แล้วอะไรคือความต้องการที่ดี? ข้อกำหนดที่ดีควรมีคุณค่าและนำไปปฏิบัติได้ ควรกำหนดความต้องการรวมทั้งจัดเตรียมเส้นทางสู่การแก้ปัญหา ทุกคนในทีมควรเข้าใจความหมาย ข้อกำหนดแตกต่างกันไปตามความซับซ้อน

  • เอกสารข้อกำหนดที่ดีสามารถเป็นส่วนหนึ่งของกลุ่มที่มีข้อกำหนดระดับสูงซึ่งแบ่งออกเป็นข้อกำหนดย่อย

  • นอกจากนี้ยังอาจรวมถึงข้อกำหนดที่ละเอียดมากซึ่งรวมถึงชุดข้อกำหนดการทำงานที่อธิบายถึงพฤติกรรมหรือส่วนประกอบของผลิตภัณฑ์ขั้นสุดท้าย

  • ข้อกำหนดที่ดีต้องรัดกุมและเฉพาะเจาะจงและควรตอบคำถามว่า“ เราต้องการอะไร” แทนที่จะเป็น "เราจะเติมเต็มความต้องการได้อย่างไร"

  • ข้อกำหนดที่ดีทำให้มั่นใจได้ว่าผู้มีส่วนได้ส่วนเสียทั้งหมดเข้าใจในส่วนของแผน หากชิ้นส่วนไม่ชัดเจนหรือตีความผิดผลิตภัณฑ์ขั้นสุดท้ายอาจมีข้อบกพร่องหรือล้มเหลว

การป้องกันความล้มเหลวหรือการตีความข้อกำหนดที่ผิดพลาดสามารถช่วยได้โดยการรับคำติชมจากทีมงานอย่างต่อเนื่องตลอดทั้งกระบวนการเมื่อข้อกำหนดมีการเปลี่ยนแปลง การทำงานร่วมกันอย่างต่อเนื่องและการซื้อร่วมกับทุกคนคือกุญแจสู่ความสำเร็จ

การรวบรวมและวิเคราะห์ความต้องการ

ข้อกำหนดคือเงื่อนไขหรือความสามารถที่ผู้มีส่วนได้ส่วนเสียต้องการในการแก้ปัญหาหรือบรรลุวัตถุประสงค์ขององค์กร เงื่อนไขหรือความสามารถที่ต้องปฏิบัติตามหรือครอบครองโดยระบบ

การวิเคราะห์ความต้องการในวิศวกรรมซอฟต์แวร์ครอบคลุมงานที่เกี่ยวข้องกับการกำหนดความต้องการหรือเงื่อนไขที่จะตอบสนองสำหรับผลิตภัณฑ์ใหม่หรือที่เปลี่ยนแปลงโดยคำนึงถึงข้อกำหนดที่อาจขัดแย้งกันของผู้มีส่วนได้ส่วนเสียต่างๆการวิเคราะห์การจัดทำเอกสารการตรวจสอบความถูกต้องและการจัดการซอฟต์แวร์หรือข้อกำหนดของระบบ

ข้อกำหนดควรเป็น -

  • Documented
  • Actionable
  • Measurable
  • Testable
  • Traceable

ข้อกำหนดควรเกี่ยวข้องกับความต้องการหรือโอกาสทางธุรกิจที่ระบุและกำหนดไว้ในระดับรายละเอียดที่เพียงพอสำหรับการออกแบบระบบ

นักวิเคราะห์ธุรกิจรวบรวมข้อมูลผ่านการสังเกตระบบที่มีอยู่ศึกษาขั้นตอนที่มีอยู่การพูดคุยกับลูกค้าและผู้ใช้ปลายทาง นักวิเคราะห์ควรมีทักษะในการจินตนาการและความคิดสร้างสรรค์หากไม่มีระบบการทำงาน การวิเคราะห์ความต้องการที่รวบรวมเพื่อค้นหาลิงก์ที่ขาดหายไปคือการวิเคราะห์ความต้องการ

Eliciting Approach

เพื่อให้บรรลุวัตถุประสงค์ให้ถามผู้เชี่ยวชาญทางธุรกิจผู้จัดการฝ่ายพัฒนาและผู้สนับสนุนโครงการด้วยคำถามต่อไปนี้ -

  • โครงการนี้จะช่วยให้บรรลุวัตถุประสงค์ทางธุรกิจอะไรของ บริษัท ?

  • ทำไมเราถึงทำโครงการนี้ตอนนี้?

  • จะเกิดอะไรขึ้นถ้าเราทำในภายหลัง?

  • ถ้าเราไม่ทำเลยจะเป็นอย่างไร?

  • ใครจะได้รับประโยชน์จากโครงการนี้?

  • คนที่จะได้รับประโยชน์จากมันถือว่าเป็นการปรับปรุงที่สำคัญที่สุดที่จะทำได้ในเวลานี้หรือไม่?

  • เราควรทำโครงการอื่นแทนหรือไม่?

วัตถุประสงค์ที่เป็นไปได้อาจเป็นการลดต้นทุนปรับปรุงการบริการลูกค้าทำให้ขั้นตอนการทำงานง่ายขึ้นแทนที่เทคโนโลยีที่ล้าสมัยการนำเทคโนโลยีใหม่และอื่น ๆ อีกมากมาย นอกจากนี้ตรวจสอบให้แน่ใจว่าคุณเข้าใจอย่างถ่องแท้ว่าโครงการที่เสนอจะช่วยให้บรรลุวัตถุประสงค์ที่ระบุไว้ได้อย่างไร

ข้อกำหนดประเภทต่างๆ

ประเภทความต้องการที่พบบ่อยที่สุดที่นักวิเคราะห์ธุรกิจสนใจมีดังต่อไปนี้ -

ข้อกำหนดทางธุรกิจ

ข้อกำหนดทางธุรกิจเป็นกิจกรรมที่สำคัญขององค์กรที่ต้องดำเนินการเพื่อให้บรรลุวัตถุประสงค์ขององค์กรในขณะที่โซลูชันยังคงเป็นอิสระ เอกสารข้อกำหนดทางธุรกิจ (BRD) ให้รายละเอียดโซลูชันทางธุรกิจสำหรับโครงการรวมทั้งเอกสารเกี่ยวกับความต้องการและความคาดหวังของลูกค้า

ความต้องการของผู้ใช้

ข้อกำหนดของผู้ใช้ควรระบุข้อกำหนดเฉพาะที่ผู้ใช้คาดหวัง / ต้องการจากซอฟต์แวร์ที่จะสร้างจากโครงการซอฟต์แวร์ ข้อกำหนดของผู้ใช้ควรสามารถตรวจสอบได้ชัดเจนและรัดกุมสมบูรณ์สอดคล้องตรวจสอบได้และทำงานได้

เอกสารข้อกำหนดของผู้ใช้ (URD) ​​หรือข้อกำหนดข้อกำหนดของผู้ใช้เป็นเอกสารที่มักใช้ในวิศวกรรมซอฟต์แวร์ที่ระบุสิ่งที่ผู้ใช้คาดหวังให้ซอฟต์แวร์สามารถทำได้

ความต้องการของระบบ

ข้อกำหนดของระบบเกี่ยวข้องกับการกำหนดข้อกำหนดทรัพยากรซอฟต์แวร์และข้อกำหนดเบื้องต้นที่ต้องติดตั้งบนคอมพิวเตอร์เพื่อให้แอปพลิเคชันทำงานได้อย่างเหมาะสม

ความต้องการการทำงาน

ข้อกำหนดในการทำงานจะจับภาพและระบุพฤติกรรมที่ต้องการเฉพาะของระบบที่กำลังพัฒนา พวกเขากำหนดสิ่งต่างๆเช่นการคำนวณระบบการจัดการและการประมวลผลข้อมูลส่วนต่อประสานกับผู้ใช้และการโต้ตอบกับแอปพลิเคชันและฟังก์ชันเฉพาะอื่น ๆ ที่แสดงให้เห็นว่าความต้องการของผู้ใช้เป็นอย่างไร กำหนดหมายเลขประจำตัวเฉพาะสำหรับแต่ละข้อกำหนด

ข้อกำหนดที่ไม่ใช่หน้าที่

ข้อกำหนดที่ไม่ใช้งานได้คือข้อกำหนดที่ระบุเกณฑ์ที่สามารถใช้ในการตัดสินการทำงานของระบบมากกว่าพฤติกรรมเฉพาะ สถาปัตยกรรมระบบพูดถึงแผนการดำเนินการตามข้อกำหนดที่ไม่สามารถใช้งานได้

ข้อกำหนดที่ไม่ใช้งานได้พูดถึงลักษณะของระบบว่าควรมีลักษณะอย่างไรหรืออาจกล่าวถึงเช่น“ ระบบจะต้องเป็น” ข้อกำหนดที่ไม่ใช้งานได้ถูกเรียกว่าเป็นคุณสมบัติของระบบ

ข้อกำหนดการเปลี่ยนแปลง

ข้อกำหนดในการเปลี่ยนแปลงจะอธิบายถึงความสามารถที่โซลูชันต้องปฏิบัติตามเพื่ออำนวยความสะดวกในการเปลี่ยนจากสถานะปัจจุบันขององค์กรไปสู่สถานะในอนาคตที่ต้องการ แต่จะไม่จำเป็นเมื่อการเปลี่ยนแปลงเสร็จสมบูรณ์

มีความแตกต่างจากข้อกำหนดประเภทอื่น ๆ เนื่องจากมีลักษณะชั่วคราวเสมอและเนื่องจากไม่สามารถพัฒนาได้จนกว่าจะมีการกำหนดโซลูชันที่มีอยู่และใหม่ โดยทั่วไปจะครอบคลุมการแปลงข้อมูลจากระบบที่มีอยู่ช่องว่างของทักษะที่ต้องได้รับการแก้ไขและการเปลี่ยนแปลงอื่น ๆ ที่เกี่ยวข้องเพื่อไปสู่สถานะในอนาคตที่ต้องการ ได้รับการพัฒนาและกำหนดผ่านการประเมินและการตรวจสอบโซลูชัน

การตรวจสอบย้อนกลับและการจัดการการเปลี่ยนแปลง

การตรวจสอบย้อนกลับข้อกำหนดเป็นวิธีการจัดระเบียบจัดทำเอกสารและติดตามความต้องการทั้งหมดของคุณตั้งแต่การสร้างไอเดียเริ่มต้นจนถึงขั้นตอนการทดสอบ

เมทริกซ์ความสามารถในการติดตามข้อกำหนด (RTM) จัดเตรียมวิธีการในการติดตามข้อกำหนดการทำงานและการนำไปใช้งานผ่านกระบวนการพัฒนา ข้อกำหนดแต่ละข้อจะรวมอยู่ในเมทริกซ์พร้อมกับหมายเลขส่วนที่เกี่ยวข้อง

ในขณะที่โครงการดำเนินไป RIM จะได้รับการอัปเดตเพื่อแสดงสถานะของข้อกำหนดแต่ละข้อ เมื่อผลิตภัณฑ์พร้อมสำหรับการทดสอบระบบเมทริกซ์จะแสดงข้อกำหนดแต่ละข้อส่วนประกอบของผลิตภัณฑ์ใดที่อยู่และสิ่งที่ทดสอบยืนยันว่ามีการนำไปใช้อย่างถูกต้อง

รวมคอลัมน์สำหรับแต่ละรายการต่อไปนี้ใน RTM -

  • คำอธิบายความต้องการ
  • การอ้างอิงความต้องการใน FRD
  • วิธีการตรวจสอบ
  • การอ้างอิงความต้องการในแผนการทดสอบ

Example- การเชื่อมต่อจุดเพื่อระบุความสัมพันธ์ระหว่างรายการภายในโครงการของคุณ มันเป็นตัวเชื่อมต่อของการไหลล่องทั่วไป

ความต้องการของแนวคิดการออกแบบทดสอบวัตถุประสงค์ทางธุรกิจ

คุณควรจะสามารถติดตามความต้องการแต่ละข้อกลับไปสู่วัตถุประสงค์ทางธุรกิจเดิมได้

โดยการติดตามข้อกำหนดคุณจะสามารถระบุการเปลี่ยนแปลงของผลกระทบระลอกคลื่นดูว่าข้อกำหนดได้เสร็จสมบูรณ์หรือไม่และมีการทดสอบอย่างเหมาะสมหรือไม่ ความสามารถในการตรวจสอบย้อนกลับและการจัดการการเปลี่ยนแปลงช่วยให้ผู้จัดการอุ่นใจได้และมีการมองเห็นที่จำเป็นในการคาดการณ์ปัญหาและรับประกันคุณภาพอย่างต่อเนื่อง

การประกันคุณภาพ

การได้รับความต้องการในครั้งแรกอาจหมายถึงคุณภาพที่ดีขึ้นรอบการพัฒนาที่เร็วขึ้นและความพึงพอใจของลูกค้าที่มีต่อผลิตภัณฑ์ที่สูงขึ้น การจัดการความต้องการไม่เพียง แต่ช่วยให้คุณทำงานได้ถูกต้อง แต่ยังช่วยให้ทีมของคุณประหยัดเงินและปวดหัวอีกมากมายตลอดกระบวนการพัฒนา

ข้อกำหนดเฉพาะที่รัดกุมสามารถช่วยให้คุณตรวจพบและแก้ไขปัญหาได้ตั้งแต่เนิ่นๆแทนที่จะแก้ไขในภายหลังเมื่อมีค่าใช้จ่ายสูงกว่ามากในการแก้ไข นอกจากนี้ยังมีราคาสูงถึง100 times เพื่อแก้ไขข้อบกพร่องในขั้นตอนการพัฒนาในภายหลังหลังจากที่ได้รับการเข้ารหัสแล้วมากกว่าที่จะแก้ไข แต่เนิ่นๆในขณะที่มีข้อกำหนด

การรวมการจัดการข้อกำหนดเข้ากับกระบวนการประกันคุณภาพจะช่วยให้ทีมของคุณเพิ่มประสิทธิภาพและลดการทำงานซ้ำได้ ยิ่งไปกว่านั้นการทำใหม่เป็นจุดที่ปัญหาต้นทุนส่วนใหญ่เกิดขึ้น

กล่าวอีกนัยหนึ่งทีมพัฒนากำลังเสียงบประมาณส่วนใหญ่ไปกับความพยายามที่ไม่ได้ดำเนินการอย่างถูกต้องในครั้งแรก ตัวอย่างเช่นผู้พัฒนาโค้ดคุณลักษณะตามเอกสารข้อกำหนดเก่าเพื่อเรียนรู้ในภายหลังว่าข้อกำหนดสำหรับคุณลักษณะนั้นมีการเปลี่ยนแปลงเท่านั้น ปัญหาประเภทนี้สามารถหลีกเลี่ยงได้ด้วยแนวทางปฏิบัติที่ดีที่สุดในการจัดการข้อกำหนดที่มีประสิทธิภาพ

โดยสรุปแล้วการจัดการข้อกำหนดอาจฟังดูเป็นระเบียบวินัยที่ซับซ้อน แต่เมื่อคุณนำแนวคิดง่ายๆมาใช้นั่นคือการช่วยให้ทีมตอบคำถามว่า“ ทุกคนเข้าใจหรือไม่ว่าเรากำลังสร้างอะไรและทำไม” ตั้งแต่นักวิเคราะห์ธุรกิจผู้จัดการผลิตภัณฑ์และหัวหน้าโครงการไปจนถึงนักพัฒนาผู้จัดการ QA และผู้ทดสอบตลอดจนผู้มีส่วนได้ส่วนเสียและลูกค้าที่เกี่ยวข้องบ่อยครั้งที่สาเหตุหลักของความล้มเหลวของโครงการคือความเข้าใจผิดเกี่ยวกับขอบเขตของโครงการ

เมื่อทุกคนทำงานร่วมกันและมีบริบทที่สมบูรณ์และสามารถมองเห็นการอภิปรายการตัดสินใจและการเปลี่ยนแปลงที่เกี่ยวข้องกับข้อกำหนดตลอดวงจรชีวิตของโครงการนั่นคือเมื่อความสำเร็จเกิดขึ้นอย่างสม่ำเสมอและคุณรักษาคุณภาพอย่างต่อเนื่อง นอกจากนี้กระบวนการยังราบรื่นขึ้นโดยมีแรงเสียดทานและความยุ่งยากน้อยลงสำหรับทุกคนที่เกี่ยวข้อง

Note- การวิจัยพบว่าทีมโครงการสามารถขจัดข้อบกพร่องของโครงการได้ 50-80% โดยการจัดการข้อกำหนดอย่างมีประสิทธิภาพ จากข้อมูลของสถาบันวิศวกรรมซอฟต์แวร์ Carnegie Mellon“ 60-80 เปอร์เซ็นต์ของค่าใช้จ่ายในการพัฒนาซอฟต์แวร์อยู่ระหว่างการปรับปรุงใหม่”

การได้รับความต้องการ Signoff

การลงนามความต้องการกำหนดข้อตกลงโดยผู้มีส่วนได้ส่วนเสียในโครงการอย่างเป็นทางการว่าเนื้อหาและการนำเสนอข้อกำหนดตามที่บันทึกไว้มีความถูกต้องและสมบูรณ์ ข้อตกลงอย่างเป็นทางการช่วยลดความเสี่ยงที่ผู้มีส่วนได้ส่วนเสียจะแนะนำข้อกำหนดใหม่ (ก่อนหน้านี้ที่ไม่ได้โต้แย้ง) ในระหว่างหรือหลังจากนั้น

โดยทั่วไปการได้รับการลงนามข้อกำหนดจะเกี่ยวข้องกับการทบทวนข้อกำหนดขั้นสุดท้ายแบบตัวต่อตัวตามที่ได้บันทึกไว้กับผู้มีส่วนได้ส่วนเสียของโครงการแต่ละโครงการ ในตอนท้ายของการทบทวนแต่ละครั้งผู้มีส่วนได้ส่วนเสียจะถูกขอให้อนุมัติเอกสารข้อกำหนดที่ได้รับการทบทวนอย่างเป็นทางการ การอนุมัตินี้อาจถูกบันทึกทางร่างกายหรือทางอิเล็กทรอนิกส์

โดยทั่วไปการขอรับการลงนามความต้องการถือเป็นงานขั้นสุดท้ายภายในการสื่อสารความต้องการ นักวิเคราะห์ธุรกิจจะต้องการผลลัพธ์จากการทบทวนข้อกำหนดอย่างเป็นทางการรวมถึงที่พักของความคิดเห็นหรือข้อคัดค้านใด ๆ ที่เกิดขึ้นในระหว่างกระบวนการตรวจสอบ

การวิเคราะห์ธุรกิจ - การสร้างแบบจำลอง

Business Model สามารถกำหนดให้เป็นตัวแทนของธุรกิจหรือโซลูชันที่มักมีส่วนประกอบกราฟิกพร้อมกับข้อความสนับสนุนและความสัมพันธ์กับส่วนประกอบอื่น ๆ ตัวอย่างเช่นหากเราต้องเข้าใจรูปแบบธุรกิจของ บริษัท เราต้องการศึกษาเนื้อหาต่อไปนี้เช่น -

  • ค่านิยมหลักของ บริษัท
  • มันทำหน้าที่อะไร?
  • อะไรคือชุดที่แตกต่างกัน?
  • ทรัพยากรที่สำคัญ
  • ความสัมพันธ์ที่สำคัญ
  • ช่องทางการจัดส่ง

ด้วยความช่วยเหลือของเทคนิคการสร้างแบบจำลองเราสามารถสร้างคำอธิบายที่สมบูรณ์ของโครงสร้างองค์กรกระบวนการและข้อมูลที่องค์กรมีอยู่และที่นำเสนอมาใช้

Business Model เป็นรูปแบบโครงสร้างเช่นเดียวกับพิมพ์เขียวสำหรับผลิตภัณฑ์ขั้นสุดท้ายที่จะพัฒนา ให้โครงสร้างและพลวัตสำหรับการวางแผน นอกจากนี้ยังเป็นรากฐานสำหรับผลิตภัณฑ์ขั้นสุดท้าย

วัตถุประสงค์ของการสร้างแบบจำลองทางธุรกิจ

การสร้างแบบจำลองทางธุรกิจใช้ในการออกแบบสถานะขององค์กรในปัจจุบันและอนาคต แบบจำลองนี้ใช้โดยนักวิเคราะห์ธุรกิจและผู้มีส่วนได้ส่วนเสียเพื่อให้แน่ใจว่าพวกเขามีความเข้าใจที่ถูกต้องเกี่ยวกับรูปแบบ "As-Is" ปัจจุบันขององค์กร

ใช้เพื่อตรวจสอบว่าผู้มีส่วนได้ส่วนเสียมีความเข้าใจร่วมกันเกี่ยวกับ“ การเป็นทางออกของการแก้ปัญหาหรือไม่

การวิเคราะห์ความต้องการเป็นส่วนหนึ่งของกระบวนการสร้างแบบจำลองทางธุรกิจและเป็นจุดโฟกัสหลัก ข้อกำหนดการทำงานจะถูกรวบรวมระหว่าง "สถานะปัจจุบัน" ข้อกำหนดเหล่านี้จัดทำโดยผู้มีส่วนได้ส่วนเสียเกี่ยวกับกระบวนการทางธุรกิจข้อมูลและกฎทางธุรกิจที่อธิบายถึงฟังก์ชันการทำงานที่ต้องการซึ่งจะได้รับการออกแบบในอนาคต

ทำการวิเคราะห์ GAP

หลังจากกำหนดความต้องการทางธุรกิจแล้วต้องระบุสถานะปัจจุบัน (เช่นกระบวนการทางธุรกิจในปัจจุบันหน้าที่ทางธุรกิจคุณลักษณะของระบบปัจจุบันและบริการ / ผลิตภัณฑ์ที่นำเสนอและเหตุการณ์ที่ระบบต้องตอบสนอง) เพื่อทำความเข้าใจว่าคนกระบวนการและเทคโนโลยีโครงสร้างอย่างไร และสถาปัตยกรรมกำลังสนับสนุนธุรกิจโดยการแสวงหาข้อมูลจากเจ้าหน้าที่ไอทีและผู้มีส่วนได้ส่วนเสียอื่น ๆ ที่เกี่ยวข้องรวมถึงเจ้าของธุรกิจ

จากนั้นจะทำการวิเคราะห์ช่องว่างเพื่อประเมินว่ามีช่องว่างใดที่ขัดขวางไม่ให้บรรลุความต้องการทางธุรกิจโดยเปรียบเทียบสถานะปัจจุบันที่ระบุกับผลลัพธ์ที่ต้องการ

หากไม่มีช่องว่าง (เช่นสถานะปัจจุบันเพียงพอที่จะตอบสนองความต้องการทางธุรกิจและผลลัพธ์ที่ต้องการ) ก็คงไม่จำเป็นต้องเปิดตัวโครงการไอที มิฉะนั้นควรระบุปัญหา / ประเด็นที่ต้องแก้ไขเพื่อเชื่อมช่องว่าง

สามารถใช้เทคนิคต่างๆเช่น SWOT (Strengths, Weaknesses, Opportunities and Threats) และการวิเคราะห์เอกสาร

เพื่อประเมินระบบที่เสนอ

BA ควรช่วยทีมโครงการไอทีในการประเมินระบบไอทีที่นำเสนอเพื่อให้แน่ใจว่าตรงกับความต้องการทางธุรกิจและเพิ่มคุณค่าที่ส่งมอบให้กับผู้มีส่วนได้ส่วนเสีย นอกจากนี้ BA ควรทบทวนความพร้อมขององค์กรในการรองรับการเปลี่ยนไปใช้ระบบไอทีที่นำเสนอเพื่อให้แน่ใจว่าการติดตั้งระบบเป็นไปอย่างราบรื่น

BA ควรช่วยทีมโครงการไอทีในการพิจารณาว่าตัวเลือกระบบที่เสนอและการออกแบบระบบระดับสูงสามารถตอบสนองความต้องการทางธุรกิจและให้มูลค่าทางธุรกิจเพียงพอที่จะพิสูจน์การลงทุนหรือไม่ หากมีตัวเลือกระบบมากกว่าหนึ่งตัว BA ควรทำงานร่วมกับเจ้าหน้าที่ไอทีเพื่อช่วยระบุข้อดีข้อเสียของแต่ละตัวเลือกและเลือกตัวเลือกที่ให้คุณค่าทางธุรกิจสูงสุด

แนวทางหลักการสำหรับการสร้างแบบจำลองธุรกิจ

บทบาทหลักของการสร้างแบบจำลองทางธุรกิจส่วนใหญ่อยู่ในขั้นตอนการเริ่มต้นและขั้นตอนการดำเนินโครงการอย่างละเอียดและจะจางหายไปในระหว่างการก่อสร้างและขั้นตอนการเปลี่ยนแปลง ส่วนใหญ่จะเกี่ยวข้องกับการวิเคราะห์ทางธุรกิจรวมกับการทำแผนที่ทางเทคนิคของแอปพลิเคชันหรือโซลูชันซอฟต์แวร์

  • Domain and User variation- การพัฒนารูปแบบธุรกิจมักจะเปิดเผยประเด็นความขัดแย้งหรือความสับสนระหว่างผู้มีส่วนได้ส่วนเสีย นักวิเคราะห์ธุรกิจจะต้องจัดทำเอกสารเกี่ยวกับรูปแบบต่างๆต่อไปนี้ในแบบจำลองตามสภาพ

  • Multiple work units perform the same function- บันทึกความแปรปรวนในแบบจำลอง AS-IS ซึ่งอาจเป็นหน่วยงานหรือภูมิภาคที่แตกต่างกัน

  • Multiples users perform the same work − Different stakeholders may do similar work differently. The variation may be the result of different skill sets and approaches of different business units or the result of differing needs of external stakeholders serviced by the enterprise. Document the variances in the AS-IS model.

  • Resolution Mechanism − The Business Analyst should document whether the ToBe solution will accommodate the inconsistencies in the current business model or whether the solution will require standardization. Stakeholders need to determine which approach to follow. The To-Be model will reflect their decision.

Example of BA role in Modelling ERP Systems

A Business analyst is supposed to define a standard business process and set up into an ERP system which is of key importance for efficient implementation. It is also the duty of a BA to define the language of the developers in understandable language before the implementation and then, utilize best practices and map them based on the system capabilities.

A requirement to the system is the GAAP fit analysis, which has to balance between −

  • The need for the technical changes, which are the enhancements in order to achieve identity with the existing practice.

  • Effective changes, which are related to re-engineering of existing business processes to allow for implementation of the standard functionality and application of process models.

Functional Business Analyst

Domain expertise is generally acquired over a period by being in the “business” of doing things. For example,

  • A banking associate gains knowledge of various types of accounts that a customer (individual and business) can operate along with detailed business process flow.

  • An insurance sales representative can understand the various stages involved in procuring of an Insurance policy.

  • A marketing analyst has more chances of understanding the key stakeholders and business processes involved in a Customer Relationship Management system.

  • A Business Analyst involved in capital markets project is supposed to have subject matter expertise and strong knowledge of Equities, Fixed Income and Derivatives. Also, he is expected to have handled back office, front office, practical exposure in applying risk management models.

  • A Healthcare Business Analyst is required to have basic understanding of US Healthcare Financial and Utilization metrics, Technical experience and understanding of EDI 837/835/834, HIPAA guidelines, ICD codification – 9/10 and CPT codes, LOINC, SNOMED knowledge.

Some business analysts acquire domain knowledge by testing business applications and working with the business users. They create a conducive learning environment though their interpersonal and analytical skills. In some cases, they supplement their domain knowledge with a few domain certifications offered by AICPCU/IIA and LOMA in the field of Insurance and financial services. There are other institutes that offer certification in other domains.

Other Major Activities

Following a thorough examination of current business processes, you can offer highly professional assistance in identifying the optimal approach of modelling the system.

  • Organizing the preparation of a formalized and uniform description of business processes in a manner ensuring efficient automation in the system.

  • Assistance to your teams in filling out standard questionnaires for the relevant system as may be furnished by the developers.

  • Participation in working meetings requirements towards the developers are defined.

  • Check and control as to whether the requirements set by you have been properly “reproduced” and recorded in the documents describing the future model in the system (Blueprints).

  • Preparation of data and assisting for prototyping the system.

  • Assistance in preparation of data for migration of lists and balances in the format required by the system.

  • Review of the set-up prototype for compliance with the requirements defined by the business process owners.

  • Acting as a support resource to your IT teams in preparing data and actual performance of functional and integration tests in the system.

In the next section, we will discuss briefly about some of the popular Business Modelling Tools used by large organizations in IT environments.

Tool 1: Microsoft Visio

MS-Visio is a drawing and diagramming software that helps transform concepts into a visual representation. Visio provides you with pre-defined shapes, symbols, backgrounds, and borders. Just drag and drop elements into your diagram to create a professional communication tool.

Step 1 − To open a new Visio drawing, go to the Start Menu and select Programs → Visio.

Step 2 − Move your cursor over “Business Process” and select “Basic Flowchart”.

The following screenshot shows the major sections of MS-Visio application.

Let us now discuss the basic utility of each component −

A − the toolbars across the top of the screen are like other Microsoft programs such as Word and PowerPoint. If you have used these programs before, you may notice a few different functionalities, which we will explore later.

Selecting Help Diagram Gallery is a good way to become familiar with the types of drawings and diagrams that can be created in Visio.

B − The left side of the screen shows the menus specific to the type of diagram you are creating. In this case, we see −

  • Arrow Shapes
  • Backgrounds
  • Basic Flowchart Shapes
  • Borders and Titles

C − The center of the screen shows the diagram workspace, which includes the actual diagram page as well as some blank space adjacent to the page.

D − The right side of the screen shows some help functions. Some people may choose to close this window to increase the area for diagram workspace, and re-open the help functions when necessary.

Tool 2: Enterprise Architect

Enterprise architect is a visual modeling and design tool based on UML. The platform supports the design and construction of software systems, modeling business processes and modeling industry based domains. It is used by business and organizations to not only model the architecture of their systems. But to process the implementation of these models across the full application development life cycle.

The intent of Enterprise architect is to determine how an organization can most effectively achieve its current and future objectives.

Enterprise architect has four points of view which are as follows −

  • Business perspective − The Business perspective defines the processes and standards by which the business operates on day to day basis.

  • Application Perspective − The application perspective defines the interactions among the processes and standards used by the organization.

  • Information Perspective − This defines and classifies the raw data like document files, databases, images, presentations and spreadsheets that organization requires in order to efficiency operate.

  • Technology Prospective − This defines the hardware, operating systems, programming and networking solutions used by organization.

Tool 3: Rational Requisite Pro

The process of eliciting, documenting organizing tracking and changing Requirements and communicating this information across the project teams to ensure that iterative and unanticipated changes are maintained throughout the project life cycle.

Monitoring status and controlling changes to the requirement baseline. The Primary elements are Change control and Traceability.

Requisite Pro is used for the above activities and project administration purposes, the tool is used for querying and searching, Viewing the discussion that were part of the requirement.

In Requisite Pro, the user can work on the requirement document. The document is a MS-Word file created in Reqpro application and integrated with the project database. Requirements created outside Requisite pro can be imported or copied into the document.

In Requisite Pro, we can also work with traceability, here it is a dependency relationship between two requirements. Traceability is a methodical approach to managing change by linking requirements that are related to each other.

Requisite Pro makes it easy to track changes to a requirement throughout the development cycle, so it is not necessary to review all your documents individually to determine which elements need updating. You can view and manage suspect relationships using a Traceability Matrix or a Traceability Tree view.

Requisite Pro projects enable us to create a project framework in which the project artifacts are organized and managed. In each project the following are included.

  • General project information
  • Packages
  • General document information
  • Document types
  • Requirement types
  • Requirement attributes
  • Attribute values
  • Cross-project traceability

Requisite Pro allows multiple user to access the same project documents and database simultaneously hence the project security aspect is to very crucial. Security prevents the system use, potential harm, or data loss from unauthorized user access to a project document.

It is recommended that the security is enabled for all RequisitePro projects. Doing so ensures that all changes to the project are associated with the proper username of the Individual who made the change, thereby ensuring that you have a complete audit trail for all changes.