Course 254 451 Software Engineering Class 5 / Requirements Engineering Michael Bruecknerphone055-261 000-4 (ext. 3233) อ. มิช่า

งานนำเสนอเรื่อง: "Course 254 451 Software Engineering Class 5 / Requirements Engineering Michael Bruecknerphone055-261 000-4 (ext. 3233) อ. มิช่า"— ใบสำเนางานนำเสนอ:

1 Course 254 451 Software Engineering Class 5 / Requirements Engineering Michael Bruecknerphone055-261 000-4 (ext. 3233) อ. มิช่า emailmichaelb@nu.ac.th officeSC2-417, by appointment

2 (c) Michael Brueckner 2005/2006 - Software Engineering 2 Overview of Today  Terminology ( คำศัพท์เฉพาะทาง )  Requirements Engineering  Functional การทำงาน Requirements  Non-Functional Requirements

3 (c) Michael Brueckner 2005/2006 - Software Engineering 3 Terminology  Requirements Engineering is the process in the software development life cycle where we find out, analyze, organize and check ตรวจสอบ the constraints ความยับยั้งชั่งใจ / ข้อจำกัด of the system  The Requirements Engineering Process consists of 5 distinct steps:  Requirements Elicitation ( เคลื่อนย้ายออกไปจาก )  Requirements Analysis and Negotiation ( การเจรจาต่อรอง )  Requirements Specification  Requirements Validation ( การให้เหตุผล )  Requirements Management

4 (c) Michael Brueckner 2005/2006 - Software Engineering 4 Requirements Engineering-1  Requirements engineering leads to  a description of the user requirements which are expressed in terms of user concepts (in natural language and diagrams)  a detailed description of the system requirements which show what the system should do (in a precise แม่นยำ language)

5 (c) Michael Brueckner 2005/2006 - Software Engineering 5 Requirements Engineering-2  Purpose ความต้องการ of RE  identify ระบุชื่อ which data and processes we need  determine ค้นความจริงอย่างแน่วแน่ the functional and non-functional requirements  show several business options in „user language“  specify กำหนด requirements without computer language or technology details

6 (c) Michael Brueckner 2005/2006 - Software Engineering 6 Requirements Elicitation-1  Determine what  users want and  what they need  (difference?) difference Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation Requirements Management

7 (c) Michael Brueckner 2005/2006 - Software Engineering 7 How Programs Are Usually Written … The requirements specification was defined like this The developers understood it in that way This is how the problem was solved before. This is how the problem is solved now That is the program after debugging This is how the program is described by marketing department This, in fact, is what the customer wanted … ;-)

8 (c) Michael Brueckner 2005/2006 - Software Engineering 8 Requirements Elicitation-2  Important:  Investigate สืบสวน the current way of work at the user‘s side  Processes  Information flow  How?  Interviews  Paper work  Observation What is happening in the company? Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation Requirements Management

9 (c) Michael Brueckner 2005/2006 - Software Engineering 9 Interviews-1  Most important way to specify requirements  Important to understand the current way of work or „system“  Almost the only way to investigate problems with situation ... but who are the right persons to interview?

10 (c) Michael Brueckner 2005/2006 - Software Engineering 10 Interviews-2  Best case:  Staff members who will work with our system  Managers who understand the current system  Typical case for completely new systems:  Managers because staff is not yet hired จ้าง

11 (c) Michael Brueckner 2005/2006 - Software Engineering 11 Interviews-3  How to interview (attention: psychology!)  Always do your homework before the interview (learn about the company and its environment)  Know something about the person and department you are going to see  Do not assume ( ทึกทักเอา ) too much about your own knowledge  Maybe you don‘t understand the problems  Someone may have misinformed ให้ข้อมูล ผิดๆ you

12 (c) Michael Brueckner 2005/2006 - Software Engineering 12 Interviews-4  Do not tell the interviewee what he/she should tell you  He/She knows - not you  Your task is to find out  If you tell something you might never know the truth ( แก้ไขให้ ถูกต้อง )  The right question is  „What happens in your department?“ No interruptions!

13 (c) Michael Brueckner 2005/2006 - Software Engineering 13 Paper Work  Very important:  Collect ไปนำมา all different types of working papers  forms  memos  notes  reports  Where do they come from  Where do they go to Information flow Forms Memos Reports

14 (c) Michael Brueckner 2005/2006 - Software Engineering 14 Observation  Watch what happens  Follow people as they do their work within the current system  Maybe you can set up a small „dummy“* system to watch the staff carefully as they work their tasks *) dummy = the very first prototype

15 (c) Michael Brueckner 2005/2006 - Software Engineering 15 Result of Requirement Elicitation-1  Statement แถลงการณ์ of need and feasibility ซึ่งเป็นไปได้  Paper with the scope ( ขอบเขต ) of the system or product  A list of customers, users and other stakeholders who participated มีส่วน in the requirements elicitation activity

16 (c) Michael Brueckner 2005/2006 - Software Engineering 16 Result of Requirement Elicitation-2  A description of the system‘s technical environment  A list of requirements (organized by function) and the constraints ( ข้อจำกัด ) that apply to each  A set of usage scenarios ( บทภาพยนตร์ ) that give insight ความเข้าใจลึกซึ้ง into the use of the system or product under different conditions สถานการณ์ Each of these results is reviewed by all people who have participated in process Each of these results is reviewed by all people who have participated in process

17 (c) Michael Brueckner 2005/2006 - Software Engineering 17 Requirements Analysis-1  Organize the requirements out of the work products into related subsets ( ตัวเลขที่อยู่ภายใต้ตัวเลขอื่น ( คณิตศาสตร์ )), e.g. through classification  Explore สำรวจ each requirement in relationship to others  Examine พินิจพิจารณา for  consistency ( ความสอดคล้อง )  omissions ( การละเลย )  ambiguity ( ความกำกวม ) Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation Requirements Management  Propose a priority ( การมาก่อน ) for each requirement according to the needs of customers/users

18 (c) Michael Brueckner 2005/2006 - Software Engineering 18 Requirements Analysis-2  Relevant questions to be asked and answered during analysis:  Is each req. consistent with overall objective เป้าหมาย of the system/product? *  Are all req. specified at the right level of abstraction นามธรรม ? (Is there to much technical detail in a req.?)  Is the req. necessary จำเป็น or is it an add-on to the objective of the system/product? * * Negotiation needed!

19 (c) Michael Brueckner 2005/2006 - Software Engineering 19 Requirements Analysis-3  Is each req. bound เป็นพรหมลิขิต and unambiguous?  Does each req. have a reference (a „source“, typically staff member or a working document)?  Do any req. conflict ขัดแย้ง with other req.? *  Can we achieve สำเร็จ each req. in the technical environment of the system/product?  Is each req. testable after it is implemented? * Negotiation needed!

20 (c) Michael Brueckner 2005/2006 - Software Engineering 20 Requirements Specification-1 ... or „Requirements description“  Requirements description is the definitive ที่สรุปขั้นสุดท้าย document for everything which is needed from the new system  Most important document  Every requirement usable as a benchmark เกณฑ์ มาตรฐาน of the new system Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation Requirements Management

21 (c) Michael Brueckner 2005/2006 - Software Engineering 21 Requirements Specification-2  Standard template แผ่นที่เจาะเป็นแม่แบบรูป ต่างๆ or natural language document (= text)  what the new system has to do („functional req‘s“)  the level of performance การทำให้บรรลุผล สำเร็จ and resource ทรัพยากร usage การใช้ („non-functional req‘s“) Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation Requirements Management

22 (c) Michael Brueckner 2005/2006 - Software Engineering 22 Functional Requirements ... are descriptions of required functions ... outline ร่างภาพ reports (online and print- outs) ... show online queries คำถาม and updates ... consider data storage, retrieval and transfer Requirements Elicitation Requirements Analysis and Negotiation Reqirements Specification Requirements Validation Requirements Management

23 (c) Michael Brueckner 2005/2006 - Software Engineering 23 Non-Functional Requirements ... show often limitations ข้อจำกัด or constraints ความยับยั้งชั่งใจ of the new system ... are „global properties of the system“  Examples:  response times  mean time to failure  security needs  access for disabled พิการ users Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation Requirements Management

24 (c) Michael Brueckner 2005/2006 - Software Engineering 24 Requirements Validation-1  Formal technical review of the working documents of previous steps  by system engineers, users, customers and other stakeholders  looking for  errors in content or interpretation  areas where clarification (=more explanation) is needed  missing ขาดแคลน information  inconsistencies ความไม่สอดคล้องกัน  conflicting or unrealistic ซึ่งไม่แท้ requirements Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation Requirements Management

25 (c) Michael Brueckner 2005/2006 - Software Engineering 25 Requirements Validation-2  Typical questions  Are req. stated บอกกล่าว clearly อย่าง ชัดเจน, can they be interpreted in a wrong way („misinterpreted“)?  Has the final statement of the req. been checked against the source?  Is the req. bounded in quantitative terms?  „a lot of users“ – „not more than 30 users“ Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation Requirements Management

26 (c) Michael Brueckner 2005/2006 - Software Engineering 26 Requirements Validation-3  Which other req. relate to this req.? Is this clearly noted via a cross-reference list or other means?  Is the req. testable? If so, can we specify criteria to use the system with the req.?  Which req. seem to be implicit ซึ่งบอกเป็นนัย ?  Are req. associated with system performance, behaviour and operational characteristics ลักษณะนิสัย ? Are they clearly stated?

27 (c) Michael Brueckner 2005/2006 - Software Engineering 27 Requirements Management-1  Why?  Requirements usually change during the lifecycle of the system/product  The requirements (and their changes!) must be  identified ระบุชื่อ  controlled ตรวจสอบ  tracked ติดตาม Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation Requirements Management

28 (c) Michael Brueckner 2005/2006 - Software Engineering 28 Requirement Management-2  Identification / Example <requirement-type><requirement-number><requirement-type>:  F = functional  D = data requirement  I = interface requirement Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation Requirements Management

29 (c) Michael Brueckner 2005/2006 - Software Engineering 29 Requirements Management-3  Make a table for keeping track of req. A01A02A03Ann R01V R02Vv R03vvV R04Vv R05V Rnnvv Requirements Specific aspects of system/product

30 (c) Michael Brueckner 2005/2006 - Software Engineering 30 Problems of RE  The boundary ( ขอบเขต ) of the system is poorly described  Customers/Users specify unnecessary ที่เกิน จำเป็น technical details that confuse ( ผสมปนเป กัน ) rather than clarify  Customers/users are not completely อย่างเสร็จ สมบูรณ์ sure what is needed  Customers/users omit ( ละเลยไป ) information that they think is „obvious“ ชัดเจน  Requirements change over time