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

สมมติว่าฉันมีเอนทิตีที่มีแอตทริบิวต์ "ประเภท" อาจมีประเภทที่เป็นไปได้มากกว่า 20 รายการ ตอนนี้ฉันขอให้ใช้สิ่งที่จะอนุญาตให้เปลี่ยนประเภทจาก A-> B ซึ่งเป็นกรณีการใช้งานเท่านั้น ดังนั้นฉันควรใช้สิ่งที่อนุญาตให้มีการเปลี่ยนแปลงประเภทโดยพลการตราบเท่าที่พวกเขาเป็นประเภทที่ถูกต้อง? หรือฉันควรอนุญาตให้เปลี่ยนจาก A-> B ตามความต้องการและปฏิเสธการเปลี่ยนแปลงประเภทอื่นเช่น B-> A หรือ A-> C ฉันเห็นข้อดีและข้อเสียของทั้งสองฝ่ายซึ่งวิธีการแก้ปัญหาทั่วไปจะหมายถึงการทำงานน้อยลงในกรณีที่ความต้องการที่คล้ายกันเกิดขึ้นในอนาคต แต่มันก็หมายถึงโอกาสที่จะผิดพลาดมากขึ้น (แม้ว่าเราจะควบคุมผู้โทร 100% จุด). วิธีแก้ปัญหาเฉพาะนั้นมีแนวโน้มที่จะเกิดข้อผิดพลาดน้อยลง แต่ต้องการงานมากขึ้นในอนาคตหากมีข้อกำหนดที่คล้ายกันเกิดขึ้น ฉันได้ยินมาว่านักพัฒนาที่ดีควรพยายามคาดการณ์การเปลี่ยนแปลงและออกแบบระบบเพื่อให้สามารถขยายได้ง่ายในอนาคตซึ่งดูเหมือนว่าโซลูชันทั่วไปเป็นหนทางไปสู่อะไร แก้ไข: การเพิ่มรายละเอียดเพิ่มเติมในตัวอย่างที่ไม่เฉพาะของฉัน: โซลูชัน "ทั่วไป" ในกรณีนี้ต้องใช้งานน้อยกว่าโซลูชัน "เฉพาะ" เนื่องจากโซลูชันเฉพาะต้องมีการตรวจสอบความถูกต้องกับประเภทเก่าและชนิดใหม่ในขณะที่โซลูชันทั่วไป จะต้องตรวจสอบประเภทใหม่เท่านั้น

124 programming-practices  api-design  requirements 

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

122 requirements  specifications 

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

74 project-management  iphone  frameworks  ios  requirements 

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

61 agile  project-management  scrum  requirements 

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

34 requirements 

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

33 requirements  user-story  requirements-management 

วิธีใดที่ดูเหมือนว่าจะดีที่สุดในการเกลี้ยกล่อมข้อกำหนดจากคนที่ไม่มีเทคโนโลยี ฉันกำลังทำงานกับทีมที่พยายามหาข้อมูลจำเพาะสำหรับโครงการ ทุกครั้งที่เราพบกันและมันก็เป็นความคาดหวังสำหรับการประชุมครั้งต่อไปเราขอให้นักธุรกิจนำความต้องการของพวกเขากลับมา พวกเขามักจะตอบสนองสิ่งนี้:“ คุณคิดว่าพวกคุณสามารถสร้างต้นแบบขึ้นมาเพื่อที่เราจะได้เห็นสิ่งที่เราชอบในสัปดาห์หน้า…คุณรู้ไม่ใช่ข้อมูลหรืออะไรเลยเพราะมันเป็นต้นแบบเพียงแค่การใช้งาน” เป็นโครงการบวก 6 เดือนเพื่อให้เห็นได้ชัดว่าเป็นไปไม่ได้ (เราจะต้องพัฒนาทุกสิ่ง!) และเราไม่รู้ด้วยซ้ำว่าจะต้องทำอะไรหากไม่มีสเป็คบางอย่าง ตรงไปตรงมาฉันคิดว่าเหมือนคนส่วนใหญ่พวกเขามีความคิดบางอย่างของสิ่งที่พวกเขาต้องการพวกเขาไม่ได้คิดเกี่ยวกับมันในวิธีที่มุ่งเน้นที่จำเป็นในการรวบรวมความต้องการที่แท้จริง เป็นอีกทางเลือกหนึ่งในการบอกพวกเขา “ ให้สิ่งที่คุณต้องการหรือเราไม่สามารถ / ไม่ทำงาน” (เราต้องการให้พวกเขามีความสุขกับผลลัพธ์) มีวิธีที่ช่วยให้พวกเขาตัดสินใจในสิ่งที่พวกเขาต้องการหรือไม่? ตัวอย่างเช่นเราสามารถบอกพวกเขาได้: “ วาดบางหน้าจอ (ใน Powerpoint บนผ้าเช็ดปากหรืออะไรก็ได้) ที่แสดง UI ที่คุณต้องการด้วยข้อมูลทั้งหมดที่คุณต้องการดูและคำอธิบายเกี่ยวกับการทำงานในระยะขอบ จากนี้เราจะขัดมันขึ้นมาและสร้างแบ็กเอนด์ขึ้นอยู่กับความต้องการด้านพฤติกรรมนี้” หรือ “ ไม่ต้องกังวลว่าจะเป็นอย่างไรในตอนนี้ (หมายเลข 1 วางสาย) เพียงแค่ให้รายการของข้อมูลทั้งหมดที่คุณต้องการเกี่ยวกับแต่ละสิ่งที่โปรแกรมติดตาม ดังนั้นสำหรับ“ ลูกค้า” คุณอาจมีรายชื่อ: ชื่อที่อยู่หมายเลขโทรศัพท์คำสั่งซื้อ ฯลฯ ไม่จำเป็นต้องเป็นโครงสร้างฐานข้อมูลที่สมบูรณ์แบบ แต่เราสามารถทำอะไรบางอย่างออกมาจากสิ่งนี้และรับทราบว่าคุณกำลังมองหาอะไร” ทำอย่างใดอย่างหนึ่งในวิธีการทางเลือกเหล่านี้เพื่อให้นักธุรกิจมุ่งเน้นไปที่สิ่งที่พวกเขาต้องการทำให้รู้สึก? มีทางเลือกอื่นที่คุณเห็นในการกระทำหรือไม่

27 design  business  requirements 

ฉันมีสองเรื่อง (ฉันรู้ว่าพวกเขาหายไปส่วนผลประโยชน์) ในฐานะผู้ใช้การจัดการเครดิตฉันสามารถดูความแตกต่างของเงินเดือนปัจจุบันและก่อนหน้าสำหรับสำนักงาน ในฐานะผู้ใช้การจัดการเครดิตฉันสามารถรับอีเมลที่มี PDF ของความแตกต่างของเงินเดือนปัจจุบันและก่อนหน้าสำหรับสำนักงาน ทั้งสองเกี่ยวข้องกันซึ่งจะมีเกณฑ์การสืบค้น / ตัวกรองเหมือนกัน ข้อแตกต่างเพียงอย่างเดียวคือในเรื่อง "มุมมอง" ผลลัพธ์จะปรากฏต่อผู้ใช้และในเรื่อง "อีเมล" ผลลัพธ์จะถูกเขียนลงใน PDF ที่ส่งถึงผู้ใช้ทางอีเมล ฉันกำลังดิ้นรนกับการแยกแง่มุมทั่วไปของสองเรื่องนี้หรือถ้าฉันควรทำเช่นนั้น ตัวอย่างเช่นพวกเขาทั้งสองจะมีข้อความค้นหาเดียวกันสิ่งที่พวกเขาทำกับผลลัพธ์ต่างกัน ฉันควรแยกคำถามออกเป็นเรื่องอื่นที่เป็นเรื่องทางเทคนิคหรือไม่? การสร้าง PDF และการส่งอีเมลควรทำแบบออฟไลน์นั่นควรเป็นเรื่องทางเทคนิคหรือไม่ ฉันเห็นการแบ่งเรื่องราวสองเรื่องเหล่านี้ออกเป็น 2 เรื่องและเรื่องราวทางเทคนิค 2 เรื่อง ในฐานะระบบฉันสามารถคำนวณความแตกต่างในบัญชีเงินเดือนปัจจุบันและก่อนหน้าสำหรับสำนักงาน ในฐานะผู้ใช้การจัดการเครดิตฉันสามารถดูความแตกต่างในการจ่ายเงินเดือนปัจจุบันและก่อนหน้าสำหรับสำนักงาน ในฐานะที่เป็นระบบฉันสามารถสร้างเอกสาร PDF ของความแตกต่างในบัญชีเงินเดือนปัจจุบันและก่อนหน้าสำหรับสำนักงาน ในฐานะผู้ใช้ด้านการจัดการเครดิตฉันสามารถขอรับอีเมลที่มี PDF ของความแตกต่างในการจ่ายเงินเดือนปัจจุบันและก่อนหน้าสำหรับออฟฟิศ ปัญหาที่ฉันกลับมาเรื่อย ๆ ก็คือเรื่องทั้งสี่นั้นไม่ได้เป็นอิสระและไม่ "ฝานเค้ก" ดังนั้นฉันไม่แน่ใจว่าจะจัดการกับสองสิ่งนี้อย่างไร

27 agile  requirements  user-story 

ในแอปพลิเคชันของฉันมีเทมเพลตนิพจน์ที่กำหนดไว้ล่วงหน้าที่สามารถใช้กรองข้อมูลได้ หนึ่งในนั้นคือ " between x and y" วิศวกรควบคุมคุณภาพอ้างว่ามีข้อบกพร่องในคำจำกัดความเนื่องจาก " between 100 and 200" ให้ผลลัพธ์ที่แตกต่างจาก " between 200 and 100" นิพจน์ได้รับการแปลภายในเป็น " value >= x and value <= y" อย่างชัดเจนดังนั้นจึงไม่มีผลลัพธ์เมื่อขอบเขตที่สองต่ำกว่าขอบเขตแรก ฉันได้ตรวจสอบว่าพฤติกรรมเดียวกันนี้อยู่ใน SQL - " between x and y" ถือว่า y> = x หรือไม่มีผลลัพธ์ หมายความว่าตัวดำเนินการไม่ได้เป็นอย่างน้อยใน SQL ดังนั้นการควบคุมคุณภาพที่ถูกต้องว่า " between x and y" …

26 requirements 

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

26 web-applications  requirements  hardware  technical-support 

คนที่ไม่ใช่ด้านเทคนิคสามารถเรียนรู้การเขียนรายละเอียดสำหรับโครงการขนาดเล็กได้อย่างไร เพื่อนของฉันกำลังพยายามที่จะ outsource การพัฒนาบางอย่างในโครงการสถิติ โดยเฉพาะอย่างยิ่งเขาทำงานหนักใน excel และต้องการ outsource การสร้างสคริปต์เพื่อทำสิ่งที่เขาทำตอนนี้ด้วยมือ อย่างไรก็ตามเพื่อนของฉันเป็นคนที่ไม่ใช่ด้านเทคนิค เขาเป็นคนยากจนที่เขียนรายละเอียดทางเทคนิค เมื่อเขาเขียนสเป็คมันจะถูกเขียนในแบบที่คุณจะอธิบายการทำอะไรใน excel (ไปที่เซลล์นี้แล้วคัดลอกค่าไปยังเซลล์นั้น) มันเป็น verbose มากเกินไปและทำตัวอย่างหลายครั้ง ฉันไม่แน่ใจว่าเขาอธิบายกรณีมุมอย่างถูกต้องหรือไม่ โครงการแรกที่เขาจ้างคือความล้มเหลว ฉันคิดว่าเขาอธิบายรายละเอียดบางอย่าง แต่ก็อธิบายกรณีมุมน้อยเกินไป และ / หรือ coder ที่เขาจ้างไม่ได้คิดผ่านมุมและถามคำถามที่เหมาะสม ฉันไม่แน่ใจ. ฉันได้ IM กับเขาและฉันใช้เวลาครึ่งชั่วโมงกว่าจะขุดคำอธิบายที่ควรใช้เวลาห้านาทีหรือน้อยกว่าในการอธิบาย ฉันเขียนสคริปต์ให้เขาตอนท้าย แต่ไม่ได้ตรวจสอบว่าทำไมกระบวนการของเขากับผู้เขียนโค้ดล้มเหลว เขาขอความช่วยเหลือจากฉัน อย่างไรก็ตามฉันปฏิเสธที่จะมีส่วนร่วมเพราะการใช้สเป็คของเขาและแปลมันเป็นข้อกำหนดที่ชัดเจนนั้นมีผลงานมากกว่าการเขียนสเป็คที่ชัดเจน 10 เท่า วิธีที่เหมาะสมสำหรับเขาที่จะเรียนรู้คืออะไร? มีทรัพยากรที่เขาสามารถใช้ได้หรือไม่? มีวิธีที่เขาสามารถเรียนรู้จากโครงการฝึกซ้อมขนาดเล็กและความดันต่ำพร้อมโคเดอร์หรือไม่? สคริปต์ส่วนใหญ่ของเขาเป็นสถิติและการประมวลผลข้อมูล เช่นใช้คอลัมน์นี้และเรียกใช้โดยเฉลี่ย ลบแถวเหล่านี้ภายใต้เงื่อนไขเหล่านี้ ดังนั้นความท้าทายจึงแตกต่างจากการระบุแอปพลิเคชันเว็บ

24 requirements  specifications  outsourcing 

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

24 agile  requirements  government 

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

23 design  requirements  issue-tracking 

ฉันทำงานใน บริษัท ขนาดกลาง แต่ใช้งานไอทีเพียงเล็กน้อย ปีที่แล้ว (2011) ฉันเขียนแอปพลิเคชันที่ได้รับความนิยมอย่างมากกับกลุ่มผู้ใช้ปลายทางจำนวนมาก เรามีกำหนดส่งถึงสิ้นปีที่แล้วและฟังก์ชั่นบางอย่าง (ฉันจะเรียก funcA นับจากนี้เป็นต้นไป) ไม่ได้ถูกเพิ่มเข้าไปในแอปพลิเคชันที่ต้องการในตอนท้าย ดังนั้นแอปพลิเคชันนี้ทำงานในการแสดงสด / ผลิตตั้งแต่ปลายปี 2011 ฉันอาจเพิ่มโดยไม่มีปัญหา เมื่อวานนี้ผู้ใช้กลุ่มทั้งหมดเริ่มบ่นว่า funcA ที่ไม่เคยอยู่ในแอปพลิเคชันไม่ทำงานอีกต่อไป ลำดับความสำคัญของเราที่ บริษัท นี้คือหากใบสมัครถูกทำลายจะต้องได้รับการแก้ไขก่อนที่จะจัดลำดับความสำคัญของโครงการ ฉันเปรียบเทียบโค้ดและข้อความค้นหาและไม่มีความแตกต่างตั้งแต่ปี 2011 ซึ่งเป็น ProofA จากนั้นฉันก็สามารถรับหนึ่งในผู้ใช้ปลายทางที่จะยอมรับว่ามันไม่ทำงานพิสูจน์ข แต่หลังจากนั้นผู้ใช้ปลายทางก็กลับไปและบอกว่ามันใช้งานได้ก่อนหน้านี้ ... ฉันเชื่อว่าฝูงชนของผู้ใช้ปลายทางได้หลอมรวม เธอ ฉันยังได้ตรวจสอบบันทึกย่อของฉันสำหรับโครงการนี้ซึ่งมีข้อกำหนดและอัพเดทรายวันเกี่ยวกับโครงการที่ระบุว่า "funcA ไม่ประสบความสำเร็จเนื่องจากข้อ จำกัด ด้านเวลา", proofC ฉันได้พูดกับพวกเขาหลายคนและฉันสามารถดูว่าพวกเขาอาจจะสับสนเพราะพวกเขาอยู่ไกลจากพื้นหลังการเขียนโปรแกรม แต่ฉันก็รู้ว่าพวกเขามีความฉลาดพอที่จะทำในกลุ่มเพื่อหลีกเลี่ยงคำสั่งจัดลำดับความสำคัญของโครงการ ฟังก์ชั่นที่พวกเขาต้องการทำให้งานของพวกเขาง่ายขึ้น ส่วนที่แย่ที่สุดคือตอนนี้กลุ่มคิดว่ามีการตั้งค่าและหัวหน้าของฉันและหัวหน้าฝ่ายไอทีก็เริ่มเชื่อพวกเขาแม้ว่าจะไม่มีการเปลี่ยนแปลงรหัสหรือการสืบค้น เท่าที่ตรวจสอบสถานะของตรรกะมันถูกตัดและแห้งไปจนถึงจุดที่ 1 = 1 funcA จะไม่ทำงาน ดังนั้นนี่คือจุดสิ้นสุดของคำอธิบายของสถานการณ์ของฉัน แต่ฉันพยายามที่จะไม่ทำ …

22 project-management  requirements  maintenance 

คำถามนี้ถูกโยกย้ายจาก Stack Overflow เพราะสามารถตอบได้ใน Software Engineering Stack Exchange อพยพ 6 ปีที่แล้ว ฉันส่งอีเมลแจ้งเตือนนักพัฒนาของเราว่าการใช้คำว่า 'จะ' ในข้อกำหนดที่ได้รับของคุณไม่ควรทำตามข้อกำหนดด้านการใช้งานของคุณ เมื่อเขียนข้อกำหนดของฟังก์ชันคำว่า 'ต้องใช้' จะใช้เพื่ออธิบายฟังก์ชันที่ข้อกำหนดที่ได้รับจะต้องทำ ที่ได้มา = ความต้องการของระบบจะเป็นความต้องการใช้งาน = ระบบจะต้องทำ requirment มันถูกส่งกลับโดยผู้อาวุโสของเราคนหนึ่งว่านั่นเป็นสิ่งที่ผิดและควรจะใช้ในทุก ๆ ความต้องการ ฉันผิดตรงนี้และควรใช้ทุกความต้องการ ฉันไม่สามารถค้นหาข้อมูลสำรองได้

22 requirements