software

Development Requirement

posted on 22 Dec 2009 01:52 by techinnoreview in MITT

Credit http://khomkrit.blogspot.com 

 

บันทึกนี้จะกล่าวถึงเรื่องของหลักการสร้างและพัฒนา (หรือเขียน) requirements ขึ้นมา ซึ่งจะบันทึกไว้ทั้งหมด 10 หัวข้อหลักๆที่เราควรทำตอนสร้าง requirement

 

  • การเขียน requirement ถ้าเขียนไม่ครบ ไม่เคลียร์ ระบบไม่เคย success ดังนั้นเรื่องนี้จึงสำคัญมาก

1. Domain Analysis

  • เราจำเป็นที่เราจะต้องเข้าใจ background ของ application และเข้าใจระบบเข้าใจ domain ก่อน
  • ข้อดีก็คือ (”เร็ว ดี”)
    • Faster development เนื่องจากเราได้ขอบเขตจากคนที่รู้จริงเกี่ยวกับระบบ
    • Better System ถ้าดีตั้งแต่เริ่มต้นแล้ว โอกาสผิดพลาดก็จะน้อย การแก้ไขก็น้อยตาม
    • เพิ่มขยายต่อไปทำได้ง่าย เพราะเราเข้าใจระบบได้ดีแล้ว การคิดต่อ ทำต่อก็ง่ายตามไปด้วย

Domain Analysis Document

  • มองในเรื่องของ domain name และ motivation (โดย motivation อย่าเขียนลอยๆ ควรมีข้อข้อมูลสนับสนุนด้วย บางครั้งเขียนแค่ว่า อดีตคืออะไร ปัจจุบันคืออะไร และอนาคตจะเป็นยังไง ก็พอ)
  • domain หรือองค์กรอื่นที่เกี่ยวข้องคือที่ไหนบ้าง อย่างน้อยถ้าเราสร้างใหม่ต้องไม่ด้อยกว่าเค้า
  • ดูความต้องการปัจจุบันว่ามีอะไรบ้าง
  • เทคนิค, software, hardware จะใช้อะไรบ้าง
  • คิดว่า data ต้องมีอะไรบ้าง และ data นั้นจะได้จากแหล่งไหน
  • อย่าเขียนมากไป เพราะจะเสียเวลา และห้ามผิดพลาด ถ้าผิดพลาดแล้วต้องปรับแก้อีกยาว นั่นคือ สั้นๆ แต่สื่อความหมาย

2. The Starting Point for Software Projects

picture-3

โดยรวมๆแล้วจุดกำเนิดของ Software จะเป็นไปดังรูป โดย A กับ B (การพัฒนาใหม่ตั้งแต่ต้น) จะเกิดขึ้นน้อยมาก ส่วน C กับ D (การปรับปรุงดูแลรักษา) จะเกิดขึ้นบ่อยๆ

3. Defining the Problem and the Scope

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

Defining the Scope

  • เมื่อมีปัญหาแล้ว ให้มากำหนด scope ต่อ
  • เวลาเขียนกรอบงานต้อง clear ว่าต้องมีอะไรบ้าง เขียนให้ชัดเจน
  • อะไรก็ตามที่กว้างไปก็ลดให้เล็กลง อะไรก็ตามที่เล็กเกินไป ก็เพิ่มขยายเข้าไป

4. What is a Requirement?

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

Requirement Engineering

  • สิ่งที่เราต้องรู้ก็คือ ทำอย่างไร requirement ถึงจะทำออกมาได้กระชับ และตรงตามความต้องการของ user?
  • เมื่อเขียน requirement เสร็จแล้ว ท้ายสุดเราต้อง validate เพื่อให้มั่นใจว่า requirement นั้นๆตรงตามที่ user ต้องการจริงๆ

5. Type of Requirement

  • Function บอกว่าระบบจะทำอะไรบ้าง
  • Non-Function จะอ้างอิงจาก PIECES (Performance, Information, Economic, Control/Security, Efficiency, Security)

Functional Requirement
ให้แยกออกเป็น 2 ส่วน คือ Data กับ Transformations

  1. Data โดยให้พิจารณาว่าข้อมูลจะเข้ามาในระบบได้อย่างไร จะเก็บไว้ที่ไหน แล้วข้อมูลนั้นจะออกไปไหน เช่นระบบต้องสามารถรับข้อมูล xxx ได้ และระบบต้องออก report xxx ได้ เป็นต้น
  2. Transformations ระบบนี้จะประมวลผลอะไรบ้าง เช่นระบบนี้ต้องประมวลผลดอกเบี้ยได้ ต้องทำแบบนั้นแบบนี้ได้ ซึ่งก็คือกระบวนการทั้งหมดเลย ซึ่งก็คือการ transform ให้ได้สิ่งที่ต้องการนั่นเอง และถ้าเป็นไปได้ให้มองในเรื่องของการ consequence, parallelism ระบบนี้ทำงานพร้อมๆกันได้กี่งาน กี่คนด้วย
  3. exception handling ถ้ามีข้อผิดพลาดเกิดขึ้นแล้ว ให้ทำอะไรต่อ? มองหาว่าอะไรผิดปกติแล้วมีอะไรบ้าง แล้วเราจะแก้ไขอย่างไร?

Non-functional Requirements: Quality
คือ business framework ซึ่งก็คือเงื่อนไขบังคับนั่นเอง

  • ปกติ non-function จะไม่ต่างกันเท่าไหร่ในแต่ละโปรเจ็ค จะต่างกันก็ตรงการ tune-up นิดหน่อยในเรื่องของตัวเลข
  • เชิง SE จะมอง usability, efficiency, reliability, maintainability, reusability
  • ให้มองที่ PIECES เป็นหลัก
  • โดยทั่วๆไปก็หนีไม่พ้นเรื่องเกี่ยวกับ response time ดี throughput ดี เชื่อถือได้ พร้อมใช้เสมอ ระบบล้มแล้วต้องกลับมาใช้ใหม่ได้ maintain ง่าย reuse ง่าย ใช้ resource น้อย ใช้กับ user ได้พร้อมๆกันกี่คน รับโหลดได้มากแค่ไหน
  • ในเรื่องของ capacity เราจะมองว่าระบบให้บริการ user ได้พร้อมๆกันกี่คน
  • Security & Safety
  • Training
  • Interface เราจะมอง 3 ด้านคือ
    1. User Interface สำหรับ user
    2. Hardware
    3. Software

ความต่างระหว่าง requirement กับ scope งาน ต่างกันอย่างไร?
Scope งานจะบอกเป็น eye bird view ภาพกว้างว่าจะทำอะไรบ้าง แล้วเอาภาพกว้างมาเจาะลึก ซึ่งก็คือ requirement นั่นเอง ส่วน requirement จะบอกว่าต้องการอะไรเท่านั้น ไม่ได้บอกว่าเราจะทำมันอย่างไร

6. Some Techniques for Gathering and Analyzing Requirements
  • observation สิ่งที่ได้มาคือ requirement ปัจจุบัน เห็นยังไงก็เอามาทำแบบนั้น
  • interviewing เราจะได้ requirement เพิ่มเติมจาก need ใหม่ๆของ user ได้

แต่อย่างไรก็ตามไม่จำเป็นต้องใช้วิธีการเดียวใช้ทั้งสองแบบก็ได้

Gathering and Analyzing Requirement

  • Brainstorming(meeting) แบบนี้ใช้กันมาก เอาคนที่เกี่ยวข้องโดยตรงมาคุย โดยอ้อมไม่เอา และ conflict ที่เกิดขึ้น ณ ตอนนั้นจะได้แก้ไขได้ในตอนนั้นเลย คำที่ใช้อย่างเป็นทางการสำหรับ brainstorming ก็คือ JAD
  • Prototyping กรณีที่ requirement ไม่เคลียร์ หรือ user ไม่เข้าใจระบบเท่าไหร่ เราก็จะทำ model นั่นเอง ที่ basic ที่สุดก็จะใช้ กระดาษ+ดินสอวาดให้ดูเลย และสิ่งที่เกี่ยวข้องส่วนมาก(ที่ทำเป็น prototype) ก็คือ ทำ User Interface นั่นเอง การเก็บข้อมูลทางเทคนิคปกติ user ไม่ค่อยสนใจเท่าไรนัก
  • Informal use case analysis ใช้ use-case ช่วยในการเก็บ requirement ด้วย
    • case ที่ว่านี้ให้เรามองประเด็นที่เราสนใจ หรือจะมองเป็น task หรือ function งานหลักๆก็ได้
    • ใช้ use case แทน context diagram
    • use case เป็น informal technique (จะมีหรือไม่มีในเอกสารก็ได้)
    • use case จะเริ่มจากเราต้องหาให้ได้ว่าใครเป็น user, actor และระบุให้ได้ว่า actor แต่ละคนเกี่ยวข้องกับระบบในมุมมองไหนบ้าง
      • เช่นระบบห้องสมุดก็จะมี case หลักๆคือ คืน ยืม ต่ออายุ และทำ catalog หนังสือ ส่วน actor ก็จะมีแค่ นักศึกษากับบรรณารักษ์เท่านั้น และบรรณารักจะยุ่งอยู่กับแค่ case ของการทำ catalog หนังสือเท่านั้น เนื่องจาก case อื่นๆแม้บรรณารักษ์จะมีส่วนเกี่ยวข้องก็จริง แต่ก็ไม่ได้เกี่ยวโดยตรง (ไม่ใช่คนกระทำเองตรงๆ เป็นแค่ helper เท่านั้น)

Documenting Requirements

  • ถ้าเป็นไปได้ ควรใช้มาตรฐานขององค์กร อะไรที่องค์กรมีให้ใช้ตามองค์กร
  • บันทึกกการเก็บ requirement เอกสารต่างๆ รายงารการประชุม details และของ requirement ต่างๆที่เรามี ก็เอามาเก็บไว้ในภาคผนวกด้วย


ตัวอย่าง. Interview Note (ตัวอย่าง ไม่จำเป็นต้องเหมือนกันทีเดียว)

เวลาไปสัมภาษณ์เราจะต้องทำ และบันทึกสิ่งต่างๆ เช่น

  • เราไปสัมภาษณ์ใคร, contact person คือใคร
  • ใส่ version ที่สัมภาษณ์ด้วย (บ่อยครั้งเราจะสัมภาษณ์มากกว่า 1 ครั้ง)
  • หน่วยงานที่ไปสัมภาษณ์ทำอะไร
  • มองระบบปัจจุบันที่เป็นอยู่ รายละเอียดย่อๆให้เข้าใจก่อน ทั้งทางด้าน hardware, software, network สถานภาพปัจจุบันต่างๆ
  • อย่าไปกระดาษเปล่า ค้นหาจากเว็บ หาข้อมูลก่อนไป รู้เขา รู้เรา
  • ปัญหาที่มีคืออะไร
  • เค้าอยากเห็นอะไรในระบบงานใหม่เพิ่มเติมจากระบบงานเก่าที่มีอยู่
  • เอกสารต่างๆที่มีที่เราได้มาจาก user


7. Types of Requirement Document

มี 2 ประเภท หลักๆ คือ

  1. Requirement Definition เขียนแค่ 1-2 บรรทัด สั้นๆเป็น eye bird view สำหรับผู้บริหารระดับสูง มอง requirement หลักของ user คืออะไรบอก user อยากได้อะไรบ้าง ไม่ได้ลงรายละเอียดอะไรมากนัก
  2. Requirement Specification อันนี้คือ requirement ที่เราต้องการในระดับที่เอาไปใช้ปฏิบัติงานได้

The Content of Requirement Documents - เนื้อหาใน requirement มีอะไร

  • ปัญหามีอะไรบ้าง
  • background เป็นอย่างไร?
  • สภาพงาน และระบบเป็นอย่างไร?
  • Functional Requirement
  • Non-functional Requirement
  • เวลาเขียน requirement จะต้องเขียนให้ชัดเจน ไม่อย่างนั้นเอามาวัดผลยาก (พยายามเขียนแต่ในสิ่งที่วัดผลได้เท่านั้น)
  • requirement ถือว่าเป็นสัญญาที่เรารับปากว่าจะทำให้ user และเอาไว้ประเมินตอนหลังด้วย
  • พยายามอย่าใส่เทคนิคลงไปใน requirement เพราะมันเป็นสัญญา user ต้องอ่านได้เข้าใจด้วย


8. Reviewing Requirement

หลังจากเก็บ requirement เสร็จแล้ว เราควรที่จะต้องมา review อีกครั้ง โดยดูจากเรื่องหลักๆต่อไปนี้

  • ลงทุนพัฒนาคุ้มค่าหรือเปล่า
  • ความสำคัญของปัญหา
  • ใน requirement จะต้องเคลียร์ ใช้สัญลักษณ์ที่สอดคล้องกันตลอดทั้งเล่ม
  • ไม่กำกวม อ่านแล้วชัดเจน เข้าใจง่าย วัดผลได้ตรงๆ
  • logically - บอกแค่ logic ห้ามบอกว่าจะ implement อย่างไร ให้มองแต่ what เท่านั้น
  • details ต้องเพียงพอ
  • requirement ที่ได้จะต้อง implement ได้ด้วยทรัพยากร และ technology ที่มีอยู่ในมือ คือสามารถหาได้ ณ ตอนนั้น
  • ไม่ over constraints ไม่มีเงื่อนไขบังคับเยอะ เพราะมันจะทำให้ยืดหยุ่นน้อย
  • จัดเรียงดี และ user ทุกคนต้องเห็นชอบด้วย

ปกติแล้วเราจะ validate โดยดูว่าตรง need จริงของ user หรือเปล่า และ verify โดยดูว่าตรงตาม spec ที่กำหนดไว้หรือเปล่า

Poor Requirement Document
requirement แย่ๆเป็นอย่างไร?

  • Unstructured Specifications - เขียนเป็บพรรณาโวหาร ดูยาก แก้ยาก ควรที่จะเขียนเป็นข้อๆแทนจะเข้าใจและอ่านได้ง่ายกว่า
  • Noise - อะไรไม่ต้องการ ให้เอาออก อย่าให้มีมากเกินไป requirement ที่เกินความจำเป็นไม่ได้ช่วยแก้ปัญหาอะไรเลย
  • Silence - สิ่งที่เราต้องการมันหายไป
  • Over-Specification - เอา design (หรือ how) มาใส่
  • Contradictions - มีอะไรที่ขัดแย้งกันเองในเอกสาร
  • Ambiguity - กำกวม
  • Forward References reference - ควรอ้างอิงจาก source เป็นหลัก
  • Wishful Thinking - requirement ที่เป็นไปไม่ได้


9. Managing Changing Requirement

ถ้าทำ requirement เสร็จสิ้นแล้วภายหลัง user ต้องการเปลี่ยน requirement เราจะต้องคิดก่อน ว่าควรเปลี่ยนหรือไม่ ซึ่งถ้าหากว่าจะเปลี่ยน ก็อาจจะต้องต่อรองกับ user ด้วย โดยมองที่ cost เป็นหลัก (cost หลักๆก็คือ เวลา)
ปกติแล้ว Requirement จะเปลี่ยนก็เพราะ 3 อย่างหลักๆนี้

  1. Business process เปลี่ยน
  2. Technology เปลี่ยน
  3. เรา (ทั้งคนเก็บ requirement และ user ที่ให้ requirement) ไม่เข้าใจงานดีพอตอนที่เราทำ requirement

อย่างไรก็ตามเราจะหลีกเลี่ยง requirement กระดื๊บ (creep) ห้ามเพิ่ม requirement เกินความจำเป็น ห้ามเพิ่มทีละนิดๆ วิธีการแก้ไขก็คือเขียน scope งานให้กระชับ และเสร็จสิ้นตั้งแต่ตอนแรก


10. Difficulties and Risks in Domain and Requirements Analysis

อุปสรรคของ requirement ที่ทำมา มักจะเกิดจากสิ่งต่อไปนี้

  • ไม่เข้าใจเนื้องาน ทั้ง user และคนเก็บ
  • requirement เปลี่ยนบ่อย (ถ้าเป็นแบบนี้ควรทำระบบแบบ incremental) ทำให้งานไม่เสร็จสักที
  • เก็บ requirement ไม่ครบ (แบบนี้เจอบ่อยมาก)
  • พยายามทำบางอย่างมากเกิน แม้มันจะไม่จำเป็นต้องทำ
  • requirement ขัดแย้งกันเอง (หลายครั้งเราเก็บ requirement มาจากคนมากกว่า 1 คน ซึ่งแต่ละคนอาจให้ requirement ที่ขัดแย้งกันได้)
  • ยากที่จะเข้าใจ requirement ที่ยาวๆ เป็นพรรณาโวหารได้ แก้โดยการเขียนประโยคสั้นๆก็พอ ให้เข้าใจได้ง่ายๆ

ตัวอย่าง Use CASE Diagram และ State Diagram

posted on 22 Dec 2009 01:33 by techinnoreview in MITT

 

 จะเห็นได้ว่ามี ผู้ใช้ระบบ ที่เป็นคน แบ่งแยกออกมาอย่างชัดเจนในระบบ

 ในระบบก็จะมี sub system แยกออกมาตามกรณีการใช้งานระบบอย่างชัดเจน

 

ระบบนี้ มี process หลักคือ place order หรือการสั่งสินค้า

และจัดให้มี sub system หรือระบบรอง 3 ส่วน

 

1. supply Customer Data ซึ่งคือการเรียกดูหรืออัพเดทประวัติลูกค้า *รวมถึงเรื่องสมาชิกด้วย

2. Order Product ซึ่งแตกออกมาจาก process หลักโดยตรง

3. Arrange Payment คือการกระทำธุรกรรม โดยอาจแยกได้เป็นเงินสด กับเครดิต

 

ทั้งนี้อาจจะมาในส่วนของ extend ในที่นี้ ยกตัวอย่างการ ขอข้อมูล Catalog เพื่อ ประกอบการตัดสินใจ

 

หรือเพื่อแสดงข้อมูลให้กับพนักงานขายในการบริการลูกค้า

 

State Diagram 

 

 

 State Diagram นั้นเขียนได้หลายแบบ แต่ทั้งสิ้นล้วนเกิดจาก จุดเริ่มต้นไปจนจบกระบวนการ

 

ต่างจาก DFD ที่เป็นการใหลข้อข้อมูล

 State Diagram จะมุ่งเน้นไปที่การแบ่งแยกการทำงานของแต่ละ process 

 

1. หัวของช่องสี่เหลี่ยมคือชื่อของ state

2. กรอบด้านล่างนั้น บ่งบอกการกระทำใน state นั้นๆ ว่าต้องทำอะไร

3. ลูกศรลากออกนั้น หมายถึงเมื่อทำโปรเสสนั้นๆเสร็จแล้ว จะก้าวไปสู่ state ถัดไปด้วยข้อแม้ใด