วศวกรรมความตองการ
บทท 3
ผศ.ดร.อนนตกล อนทรผดงwww.anantakul.net
2
Basics of Requirements Engineer
Requirements
Analysis
Software
Design
System
Engineering
What
How
3
การก าหนดความตองการ
สามารถแบงออก 3 ระดบ
1. Requirement Definition คอ เอกสารทอธบายลกคาวาอะไรบางทระบบตองม
2. Requirement Specification คอ เอกสารอธบายรายละเอยดหนาทและเงอนไขตางทระบบตองท า โดยมงสอใหนกออกแบบเขาใจ
3. Software Specification คอ อธบายวธการพฒนาในทมงานวศวกร
4
Requirements specification
Defines requirements on different levels of abstraction, for example
Customer requirements
Component requirements
Each level intended for a different class of readers
5
Customer requirements document
Defines system to be built from the customer perspective
Customer needs to understand the document
Basis of contract between customer and system developer
Requirements ought to be complete and consistent!!!
6
Customer requirements
A complete understanding of software requirements is essential for the success of the project!
Users are not satisfied by a well designed and well coded software system
Users want systems that fulfill their needs
7
Software requirements analysis process
เปนกระบวนการสรางขอก าหนดความตองการ โดยบรรจไวในเอกสาร ซงถอวาเปนจดเรมตนของการพฒนา
โดยลกษณะของกระบวนการจะตอง คนหาใหพบ (discovery) ละเอยดรอบคอม (refinement) มรปแบบ (modeling) มการก าหนดทชดเจน (specification)
Customer and developer have active roles
8
Requirement Engineering Process
ทมา: อนนตกล อนทรผดง (2556 : 23)
9
Requirement Definition
เปนการสรางเอกสารทเกยวของกบผวาจางและผบรหารโครงการ ประกอบไปดวย ความตองการระบบ 2 แบบ คอ Function Requirement คอ ระบบถง สงตางๆหรอการ
บรการทผใชระบบความหวงวาจะไดรบ Non- Function Requirement คอ เงอนไขหรอกฏเกณฑ
ตางๆทระบบตองท า เชน เรองของเวลา หรอ มาตรฐานทจะใชในการพฒนาระบบ
10
ขนตอนในการวเคราะห (Analysis steps)
จดจ าปญหา (Problem recognition)
เขยนความสมพนธของความตองการโดยใชโมเดลมาตราฐาน (Modeling)
ก าหนดความตองการจรงๆ (Customer requirements specification)
ทบทวนและลงนาม (Review & sign off)
11
Communication basics
Listen to your customer! Hearing ¹ Understanding
Prepare meetings Know your customer and contacts
Read available documents
Think about the goals of the meeting
Think about problems
Be on time
12
Initiating communication
First meeting may be awkward No knowledge about partner
Different expectations
But: both want success
Basic understanding of the problem Who is behind the request for this work?
Who will use the solution? Benefits?
What would be a “good” solution?
What will be the solution’s environment?
Constraints? Performance issues?
Right person to talk to? Answers “official”?
Did I miss some questions? Too many?
Who else to talk to?
13
Guidelines
Understand the problem before you begin to create requirements specification Don’t solve the wrong problem
Develop user-interface prototypes User interface often determines “quality”
Record origin of and reason for requirements
Use multiple views on requirements Reduces risk to miss something
Prioritize requirements
Work to eliminate ambiguity
14
โมเดลรง (Modeling)
Create models of the real world to be represented by the system
Often: Graphical representations ER, Data flow, Use Cases, Class ……
Cover Function: Transformation of data
Behavior: Responses to events
Key data structures
15
Analysis models are used for ….
Understanding the problem
Specification of customer requirements
Reviews
Communication with customers
Basis for design and implementation
16
Software prototyping
Objective: requirements specification & validation, feasibility
Especially: Requirements on user interfaces Paper-based “prototypes”
GUI builder for mock-up
Preliminary user manual
Throw-away versus evolutionary prototype
Tools: 4GL for databases
GUI builder
Formal specification & prototyping environments
17
Specification principles
Separate functionality from implementation
Develop cognitive models (not implementation)
Establish context by defining interfaces
Define environment of the system
Specification must be extendable Because it is always incomplete
18
Specification representation
Format and content should be relevant for the problem
There are different application domains
Nested information, multiple layers
Consistent notation in diagrams
Representation tool should support changes
19
Requirements notations
natural language+ easy to read and understand
- ambiguity
- difficult to change (implicit dependencies)
formal languages+ unambigous
- syntax hard to read and understand
+ tests on consistency etc.
semi-formal language specifications, e.g. use cases our approach
20
Nonfunctional customer requirements
Restriction or constraint on a system service Hardware platform, response times, MTBF,
...
Reasons: user needs, budget constraints, etc.
Should be quantifiable not: quick response time
ตวอยางการก าหนด Problem Domain
21
นโยบายของกรมปศสตว และเพอใหสอดคลองกบสถานการณในปจจบน กรมปศสตวจงม ความประสงคทจะจดท าระบบบรการรบแจงและใหความรกบประชาชนเรองโรคระบาดสตว เพอใหประชาชนทพบเหนสตวเจบปวย ลมตาย หรอสถานการณทแนวโนมวาจะเกดการระบาดของโรคระบาดสตวโดยเฉพาะโรคตดตอระหวางสตวและคน สามารถแจงใหกรมปศสตวทราบและเขาไปตรวจสอบ ควบคม ปองกนแระระบาดของโรคไดทนทวงท และเพอเปนการใหความรกบประชาชนในเรองโรคระบาดสตว โดยชองทางการแจงและศกษาหาความรของประชาชนนน สามารถท าไดทงทางโทรศพท E-mail และ Internet Web Application ของกรมปศสตว โดยเจาหนาทและประชาชนสามารถระบจดและดพนททเกดการระบาด และพนททเสยงตอการเกดการระบาดไดบนแผนทระบบสารสนเทศภมศาสตร (GIS) ผานเครอขายระบบอนเทอรเนตได ท าใหประชาชนทงประเทศสามารถมสวนรวมเพอชวยหยดย งการระบาดของโรคระบาดสตวโดยเฉพาะโรคตดตอระหวางสตวและคนได
Domain Model
22
การก าหนดความตองการ
ระบบสามารถรบแจงโรคหรอกลมอาการของโรคระบาดสตว และสามารถระบต าแหนงทเกดเหตและแสดงสถานทใกลเคยงกบจดทโรคระบาดได สามารถเพมเตมโรคระบาดสตวในอนาคตได
มระบบควบคมสทธของผใชงานโดยสามารถก าหนดสทธแบงตามประเภทไดดงน ผใชงานทวไป เชน ประชาชน ผทถอบตรประชาชน หรอผทเปนสมาชก ผใชงานทเปน อาสาสมครจากหนวยงานอนๆ ผใชงานทเปนเจาหนาทและผบรหารของกรมปศสตว ผดแลระบบ
23
การก าหนดความตองการ (ตอ)
มระบบทพฒนามสวนบรหารและจดการขอความผาน SMS เพอแจงใหกบผรบ และกลมผรบ
มระบบแจงเตอนดวยสญลกษณและสถานะของการแจง เพอใหทราบถง ประเภทของโรคระบาดสตวขอมลทยงไมไดเปดอาน ขอมลทถกอานแลวโดยเจาหนาท และมการแจงผาน SMS แลว
มระบบบรหารจดการขอมลสถานทตงตางๆ บนแผนท เพอชวยใหงายตอการแจงขอมลโรคระบาด
มระบบบรหารจดการขอมลเพอเผยแพรความรใหกบประชาชนผานทางระบบอนเตอรเนต
24
แนะน าหนงสอทหาอานเพมเตม อนนตกล อนทรผดง (2556) การวเคราะหและออกแบบระบบเชงวตถ, กรงเทพฯ
: ส านกพมพมาสเตอรกอบป พรฤด เนตโสภากล.ผศ.ดร.(2549). วศวกรรมซอฟตแวร ทฤษฎ หลกการ และ
การประยกตใช. กรงเทพฯ : ส านกพมพทอบ สมชาย กตตชยกลกจ. ดร.(2550), เรองการพฒนาซอฟตแวรมแคน,สมาคม
สงเสรมเทคโนโลย(ไทย-ญปน) Ian Sommerville, Software Engineering (7 Edition), Addison Wesley; 2006. Booch et al: Unified Modeling Language Users Guide, Addison-Wesley, 1999 Schach: Classical and Object-Oriented SE, McGraw Hill, 1999 James F.Peters,Witold Pedrycz: Software Engineering
ประเดนค าถาม
26
Top Related