คำถามติดแท็ก requirements-management

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

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

4
การจัดการความต้องการทำงานในระยะยาวกับโครงการ Agile อย่างไร
การจัดการความต้องการในระยะสั้นสำหรับโครงการ Agile ดูเหมือนจะเป็นปัญหาที่แก้ไขแล้วสำหรับฉัน จากข้อกำหนดใหม่ในมุมการต่อสู้หรือการเปลี่ยนแปลงข้อกำหนดที่มีอยู่จะถูกส่งผ่านเรื่องราวของผู้ใช้ และเรื่องราวของผู้ใช้ที่จัดกลุ่มภายใต้มหากาพย์หรือฟีเจอร์ช่วยอำนวยความสะดวกในการส่งมอบความต้องการที่ซับซ้อนมากขึ้น แน่นอนเรื่องราวของผู้ใช้ไม่ใช่เอกสารข้อกำหนดทางเทคนิค มันคือการจัดกลุ่มงานที่จัดการได้ซึ่งแมปกับสิ่งที่มักเรียกว่าVertical Sliceของฟังก์ชันการทำงาน และขอบเขตของเรื่องราวเหล่านี้สามารถกำหนดได้อย่างชัดเจนผ่านการใช้เกณฑ์การยอมรับ (AC) ดังนั้นแม้ว่าเรื่องราวของผู้ใช้จะไม่เป็นข้อกำหนดที่เป็นทางการ แต่การเรียกดูผ่านเรื่องราวเหล่านั้นสามารถให้แนวคิดที่ชัดเจนเกี่ยวกับข้อกำหนดพื้นฐานของพวกเขาได้ ในระยะสั้น. ฉันพูดในระยะสั้นเพราะในขณะที่โครงการดำเนินไปเรื่อย ๆ จำนวนเรื่องราวของผู้ใช้เพิ่มขึ้น ดังนั้นการเรียกดูรายการเรื่องราวที่เพิ่มขึ้นเรื่อย ๆ เพื่อค้นหาสิ่งที่ต้องการจะน้อยลงและมีประสิทธิภาพน้อยลงเมื่อเวลาผ่านไป ปัญหานี้เกิดขึ้นเมื่อคุณพิจารณาเรื่องราวของผู้ใช้ที่ขยายขึ้นแทนที่หรือแม้แต่คัดค้านเรื่องราวก่อนหน้า ตอนนี้ลองนึกภาพช่องว่าง 2 ปีระหว่างการทำซ้ำการพัฒนาในโครงการ (มีความเสถียรในการผลิต) ทีมเดิมหมดไปแล้วและเป็นความรู้ทั้งหมด หากทีมดั้งเดิมรู้ว่าสิ่งนี้จะเกิดขึ้น (เช่นเป็นลักษณะของธุรกิจ) แล้วพวกเขาจะใช้มาตรการอะไรเพื่อช่วยทีมต่อไป แน่นอนว่างานในมือจะให้ข้อมูลบางอย่าง แต่แทบจะไม่ได้อยู่ในรูปแบบที่เรียกดูได้ง่าย ดังนั้นสิ่งที่สามารถทำได้เพื่อช่วยให้ทีมต่อมาเข้าใจถึงสถานะของโครงการรวมถึงสาเหตุและวิธีการไปถึงที่นั่น? จากประสบการณ์ของฉันสิ่งต่อไปนี้ใช้ไม่ได้: กรูมมิ่ง Backlogเพื่อลบหรืออัปเดตเรื่องราวผู้ใช้ก่อนหน้าเพื่อให้สามารถอ่าน Backlog เป็นเอกสารข้อกำหนดได้ Documentation Sprintsที่สมาชิกในทีมได้รับมอบหมายด้วยการบันทึกสถานะปัจจุบันของระบบ เอกสารผ่านการทดสอบพฤติกรรม วิธีนี้เป็นวิธีเดียวที่ฉันได้เห็นมาใกล้กับการทำงาน น่าเสียดายที่การทดสอบพฤติกรรมการใช้รหัสเป็นเหยื่อของปัญหาการตั้งชื่อ แม้ว่าการทดสอบอาจจัดทำเอกสารระบบอย่างถูกต้อง แต่ให้ทีมนักพัฒนาที่มีความผันผวนในการเขียนการทดสอบตามคำศัพท์โดเมนถ้อยคำและรูปแบบที่เหมือนกันนั้นแทบเป็นไปไม่ได้ ดังนั้นเพื่อย้ำ: หนึ่งจะจัดการความต้องการโครงการเปรียวในระยะยาวได้อย่างไร

2
อะไรคือความแตกต่างระหว่างข้อกำหนดด้านการใช้งานการปฏิบัติงานและด้านเทคนิค?
ฉันทำงานต่าง ๆ ตาม Java แต่ผู้อาวุโสของฉันมอบหมายให้ฉันรวบรวมข้อกำหนดสำหรับการสร้างเครื่องมือติดตามบั๊กที่เป็นสากล ฉันได้อ่านความต้องการหลายประเภทจาก Wikipedia และเว็บไซต์ mindtoolsแต่มันสับสนมาก อะไรคือความแตกต่างที่แน่นอนระหว่างข้อกำหนดการใช้งานข้อกำหนดการปฏิบัติงานและข้อกำหนดทางเทคนิค

4
ข้อกำหนดของวลีเกี่ยวกับการเข้ารหัสชื่อไฟล์
ฉันอยู่ในขั้นตอนการเขียนข้อกำหนดเฉพาะและฉันมีปัญหาในการใช้ถ้อยคำเป็นส่วนหนึ่งของข้อกำหนด สถานการณ์จำลอง: เราดาวน์โหลดไฟล์จากเว็บไซต์และไฟล์ที่ดาวน์โหลดต้องแนบกับรายการในเครื่องมือ CM ที่เรามี ไฟล์ที่ดาวน์โหลดมีชื่อซึ่งสามารถเป็น ASCII, ISO-8859-1, ญี่ปุ่นและอื่น ๆ ในถ้อยคำด้านล่าง "non-ASCII" ครอบคลุมทุกสถานการณ์หรือไม่? ชื่อไฟล์ที่ดาวน์โหลดอาจมีอักขระที่ไม่ใช่ ASCII และการประมวลผลจะไม่ทำให้แอปพลิเคชันเสียหาย

4
ฉันต้องการอธิบายว่าเพราะเหตุใดข้อกำหนดจึงต้องไม่เปลี่ยนแปลงในระหว่างการพัฒนา
ฉันต้องการอธิบายว่าเพราะเหตุใดจึงไม่มีการเปลี่ยนแปลงข้อกำหนดในระหว่างช่วงเวลาการพัฒนากับพนักงานฝ่ายวางแผนใหม่

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

4
ฉันจะโน้มน้าวทีมของฉันได้อย่างไรว่าข้อกำหนดคุณสมบัติไม่จำเป็นหากเรานำเรื่องราวของผู้ใช้ไปใช้
เราวางแผนที่จะนำเรื่องราวของผู้ใช้ไปใช้เพื่อจับภาพ 'เจตนา' ของผู้มีส่วนได้ส่วนเสียในรูปแบบที่มีน้ำหนักเบามากกว่า SRS ที่หนักหน่วง (ข้อกำหนดคุณสมบัติซอฟต์แวร์) อย่างไรก็ตามดูเหมือนว่าแม้ว่าพวกเขาจะเข้าใจคุณค่าของเรื่องราว แต่ก็ยังมีความปรารถนาที่จะ 'เปลี่ยน' เรื่องราวให้เป็นภาษาที่เหมือน SRS ด้วยคุณลักษณะทั้งหมดลำดับความสำคัญอินพุตอินพุตเอาต์พุตแหล่งปลายทาง ฯลฯ เรื่องราวของผู้ใช้ 'กำจัด' ความต้องการ SRS ที่เป็นทางการอย่างเช่นสิ่งประดิษฐ์ที่จะเริ่มต้นด้วยดังนั้นอะไรคือจุดที่มี SRS ฉันจะโน้มน้าวทีมของฉันได้อย่างไร (ซึ่งเป็นกลุ่ม CS ที่มีคุณสมบัติตามที่ต้องการ - ทั้งจากการศึกษาและการปฏิบัติ) ที่ SRS จะ 'ถูกกำจัด' ถ้าเรานำเรื่องเล่าของผู้ใช้มาใช้เพื่อจับความต้องการการทำงานของระบบ (สามารถบันทึก NFRs และอื่น ๆ ได้เช่นกัน แต่นั่นไม่ใช่จุดประสงค์ของคำถาม) ดังนั้นนี่คืออาร์กิวเมนต์ 'ขั้นตอนการทำงาน' ของฉัน: จับภาพความต้องการเริ่มต้นเป็นเรื่องราวของผู้ใช้และอธิบายรายละเอียดภายหลังเพื่อใช้กรณี (ซึ่งจะต้องมีการบันทึกไว้ในระดับต่ำเช่นอธิบายการโต้ตอบกับต้นแบบ UI / mockups และโพสต์ที่ส่งมอบได้ การใช้งาน) ดังนั้นจะเปลี่ยนจากเรื่องราวของผู้ใช้เป็นกรณีใช้มากกว่าเรื่องราวของผู้ใช้ไปยัง SRS ไปยังกรณีใช้งาน ตอนนี้คุณเป็นอย่างไรบ้างที่จะรวบรวมเรื่องราวของผู้ใช้ในที่ทำงานของคุณ …
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.