การเขียนข้อกำหนดความต้องการซอฟต์แวร์


15

ฉันมีคำถามสองสามข้อเกี่ยวกับการเขียนข้อกำหนดและพวกเขาคือ:

  1. เมื่อเราเขียนข้อกำหนดซอฟต์แวร์ภายใต้หัวข้อ "ข้อกำหนดของผู้ใช้ข้อกำหนด" เราต้องระบุ "ฟังก์ชั่น" และ "ข้อ จำกัด " เท่านั้นหรือไม่

  2. "ส่วนต่อประสานผู้ใช้" ตกลงไปใน "ฟังก์ชั่น" หรือ "ข้อ จำกัด " หรือไม่?

  3. พื้นที่สำคัญที่สำคัญ (ข้อกำหนด) คืออะไรซอฟต์แวร์สามารถแบ่งออกเป็น (เช่น UI)?


บทความนี้อาจเป็นประโยชน์: 10 ข้อผิดพลาดทั่วไปใน Specs
yegor256

คำตอบ:


16

ในขณะที่ฉันไม่ได้เป็นแฟนตัวยงของการรวบรวมความต้องการทั้งหมดในรายละเอียดล่วงหน้า (เนื่องจากอาจมีการเปลี่ยนแปลงอย่างมากในโครงการที่ไม่สำคัญ) หากคุณกำลังเขียนเอกสารข้อกำหนดเทมเพลตข้อกำหนดของ Volere เป็นคู่มือที่ยอดเยี่ยม .

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

นี่คือลิงค์ไปยังข้อมูลเพิ่มเติมเกี่ยวกับเทมเพลต:

http://www.volere.co.uk/template.htm

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

นี่คือบทสรุปของส่วนต่างๆในนั้น (อ้างอิงจากลิงก์ด้านบน):

  1. วัตถุประสงค์ของโครงการ

  2. ผู้มีส่วนได้เสีย

  3. ข้อบังคับที่ จำกัด

  4. อนุสัญญาการตั้งชื่อและคำจำกัดความ

  5. ข้อเท็จจริงที่เกี่ยวข้องและข้อสมมติฐาน

  6. ขอบเขตของงาน

  7. ตัวแบบข้อมูลธุรกิจและพจนานุกรมข้อมูล

  8. ขอบเขตของผลิตภัณฑ์

  9. หน้าที่และข้อกำหนดด้านข้อมูล

  10. รูปลักษณ์และความต้องการ

  11. ข้อกำหนดการใช้งานและมนุษยชาติ

  12. ต้องการประสิทธิภาพการทำงาน

  13. ข้อกำหนดการดำเนินงานและสิ่งแวดล้อม

  14. การบำรุงรักษาและข้อกำหนดการสนับสนุน

  15. ข้อกำหนดด้านความปลอดภัย

  16. ข้อกำหนดทางวัฒนธรรมและการเมือง

  17. ข้อกำหนดทางกฎหมาย

  18. เปิดประเด็น

  19. โซลูชั่นแบบ off-the-Shelf

  20. ปัญหาใหม่

  21. งาน

  22. การโยกย้ายไปยังผลิตภัณฑ์ใหม่

  23. ความเสี่ยง

  24. ค่าใช้จ่าย

  25. เอกสารผู้ใช้และการฝึกอบรม

  26. ห้องรอ

  27. แนวคิดสำหรับการแก้ปัญหา


10

ฉันแนะนำให้อ่าน Joel กับซอฟต์แวร์ ฉันไม่แน่ใจว่ามันตอบคำถามของคุณโดยเฉพาะหรือไม่ แต่เขามีภาพรวมที่ยอดเยี่ยมเกี่ยวกับการเขียนข้อกำหนดการใช้งาน :

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

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

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

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

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


@gnat ฉันไม่คิดว่าจำเป็นต้องอ้างจากบทความ หากคุณต้องการเน้นข้อความที่ตัดตอนมาฉันแนะนำให้คุณโพสต์คำตอบของคำถาม
Jonathan Swinney

ลองพิจารณาการอ่าน คำตอบของคุณที่ปราสาทอื่น: คำตอบไม่ใช่คำตอบเมื่อไหร่? "ให้ฉันชัดเจน: การตอบสนองประเภทนี้ไม่ใช่คำตอบถ้าคุณเห็นนี่ให้ตั้งค่าสถานะผู้ดูแลถ้าคุณเห็นการตั้งค่าสถานะลบออก "
gnat

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

6

เมื่อเราเขียนข้อกำหนดซอฟต์แวร์ภายใต้หัวข้อ "ข้อกำหนดของผู้ใช้ข้อกำหนด" เราจะต้องระบุ "ฟังก์ชั่น" และ "ข้อ จำกัด " เท่านั้น?

ข้อกำหนดคือการรวมกันของสองสิ่ง ...

  1. มันทำอะไร ความต้องการการทำงาน
  2. มันทำได้ดีแค่ไหน ข้อกำหนดด้านการใช้งานไม่ได้หรือ "ข้อ จำกัด "

"ส่วนต่อประสานผู้ใช้" ตกลงไปใน "ฟังก์ชั่น" หรือ "ข้อ จำกัด " หรือไม่?

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

พื้นที่สำคัญที่สำคัญ (ข้อกำหนด) คืออะไรซอฟต์แวร์สามารถแบ่งออกเป็น (เช่น UI)?

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

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


4

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

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

ฉันคิดว่าส่วนต่อประสานผู้ใช้มีข้อกำหนดในทั้งสองหมวด

ข้อ จำกัด :

  • "หน้าจอเริ่มต้นจะแสดงสองปุ่ม:" เริ่มต้น "และ" หยุด "
  • "แบบอักษรที่แสดงต้องไม่เล็กกว่า 10 จุด"

ฟังก์ชั่น:

  • "เมื่อStartกดปุ่มซอฟต์แวร์จะสร้างการเชื่อมต่อ TCP / IP กับWOPR "

ตัวอย่างของคุณไม่ใช่ข้อกำหนดพวกมันออกแบบมา ข้อมูลเฉพาะเกี่ยวกับความต้องการที่จะทำให้สำเร็จคือการตัดสินใจออกแบบไม่ใช่ข้อกำหนด ดังนั้น "สองปุ่ม" คือการตัดสินใจออกแบบ มันจะชัดเจนเมื่อคุณรู้ว่ามีวิธีที่ถูกต้องอื่น ๆ อีกมากมายในการบรรลุเป้าหมายเดียวกัน (เริ่มต้นหรือหยุดบางสิ่งบางอย่าง) ดังนั้นเพื่อให้เป็นข้อกำหนดมากขึ้นคุณจะต้องพูดว่า "UI จะเป็นเครื่องมือในการเริ่มต้นและหยุดบางสิ่งบางอย่าง" แต่ฉันจะไปต่อเพราะการใช้ UI เป็นการตัดสินใจออกแบบ ดังนั้นสำหรับความต้องการของระบบมันจะเป็น "ระบบจะจัดให้มีวิธีการเริ่มต้นและหยุดบางสิ่งบางอย่าง"
Dunk
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.