วศวกรรมความตองการ

บทท 3

ผศ.ดร.อนนตกล อนทรผดงwww.anantakul.net

anantakul@gmail.com

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