Chapter 3 Requirements Engineering – Software Engineering Chaichan Kusoljittakorn 13-Requirements Engineering

Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. This is inevitable as requirements may serve a dual function May be the basis for a bid for a contract - therefore must be open to interpretation; May be the basis for the contract itself - therefore must be defined in detail; Both these statements may be called requirements. 23-Requirements Engineering

Types of requirement User requirements Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. System requirements A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor. 3-Requirements Engineering3

User and system requirements This example from a mental health care patient management system (MHC-PMS) 3-Requirements Engineering4

Functional and non-functional requirements Functional requirements ( ความต้องการที่เป็นหน้าที่หลัก ) Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. May state what the system should not do. Non-functional requirements ( ความต้องการที่ไม่ใช่หน้าที่ หลัก ) C onstraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Often apply to the system as a whole rather than individual features or services. Domain requirements ( เงื่อนไขอื่นจากสภาวะแวดล้อมที่ทำ ให้ระบบทำงานได้ ) Constraints on the system from the domain of operation 3-Requirements Engineering5

Functional requirements Describe functionality or system services. Depend on the type of software, expected users and the type of system where the software is used. Functional user requirements may be high-level statements of what the system should do. Functional system requirements should describe the system services in detail. 3-Requirements Engineering6

Functional requirements for the MHC-PMS A user shall be able to search the appointments lists for all clinics. The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day. Each staff member using the system shall be uniquely identified by his or her 8-digit employee number. 3-Requirements Engineering7

Example-Functional Requirements Requirements must do ONE THING. – Bad: The system shall accept credit cards and accept pay pal – Good: The system shall accept credit cards The system shall accept pay pal. Requirements must be testable. Use precise language. – Bad: The system shall work with any browser – Good: The system shall work with Firefox The system shall work with IE – Bad: The system shall respond quickly to user clicks – Good: The system shall respond within 10ms to any user click 3-Requirements Engineering8

Non-functional requirements These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. Process requirements may also be specified mandating a particular IDE, programming language or development method. Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless. 3-Requirements Engineering9

Non-functional classifications Product requirements Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. Organisational requirements Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc. External requirements Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc. 3-Requirements Engineering10

Examples of nonfunctional requirements in the MHC-PMS Product requirement The MHC-PMS shall be available to all clinics during normal working hours (Mon–Fri, 0830–17.30). Downtime within normal working hours shall not exceed five seconds in any one day. Organizational requirement Users of the MHC-PMS system shall authenticate themselves using their health authority identity card. External requirement The system shall implement patient privacy provisions as set out in HStan priv. 3-Requirements Engineering11

Usability requirements The system should be easy to use by medical staff and should be organized in such a way that user errors are minimized. (Goal) Medical staff shall be able to use all the system functions after four hours of training. After this training, the average number of errors made by experienced users shall not exceed two per hour of system use. (Testable non-functional requirement) 3-Requirements Engineering12

The software requirements document เรียกได้อีกอย่างว่า “ ข้อกำหนดความต้องการ ซอฟท์แวร์ (System Requirement Specification: SRS)” The software requirements document is the official statement of what is required of the system developers. Should include both a definition of user requirements and a specification of the system requirements. It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it. 3-Requirements Engineering13

Users of a requirements document 3-Requirements Engineering14

IEEE Software Requirements Document ส่วนที่ 1 บทนำ วัตถุประสง ค์ ขอบเขต นิยาม สรุป 3-Requirements Engineering15 ส่วนที่ 2 รายละเอียด ทั่วไป สภาพแวดล้ อม ฟังก์ชั่น ข้อจำกัดใน การออกแบบ และสร้าง ส่วนที่ 3 ข้อกำหนด ความต้องการ Function requirement Non-Function requirement ส่วนที่ 4 ภาคผนวก

Writing Requirements ใช้ภาษาที่เป็นธรรมชาติ และใช้ Diagram และ Table ช่วยในการอธิบาย ปัญหา 3 อย่างที่อาจจะเกิดขึ้น เมื่อเขียนความ ต้องการ 1. ขาดความชัดเจน เอกสารที่ทำอ่านยาก 2. ความเข้ากันของความต้องการ ความต้องการที่แตกต่างกัน อาจจะต้องทำงานร่วมกัน 3. ความต้องการที่สับสน Functional and non-functional requirements เกิดการ รวมกัน 3-Requirements Engineering16

Templates are Essential Define a standard document structure Readers familiar with the document Acts as a checklist so that no sections are forgotten Define standard templates for the requirements description Easy to find information Nothing will be “forgotten” 3-Requirements Engineering17

ATM requirement (bad) 2.6 Withdrawal If the card is accepted, the user has entered the correct PIN, and there are sufficient funds in the account, the amount of cash shall be dispensed. If the card is invalid (in which case it should be ejected), the PIN does not match the one required for the card (in which case a tone shall sound and the user given the option to try again— the tries shall be limited to 3), or the balance is insufficient (in which case a tone shall sound and the user shall have the opportunity to enter a new amount) cash shall not be dispensed. 3-Requirements Engineering18

ATM requirement (good) 2.6: The System shall support cash withdrawals by the user 2.6.1: A withdrawal shall be allowed if and only if: The card can be validated (Req. 2.7) The PIN is valid for the card (Req. 2.8) The funds in the card account exceeds the funds requested in the withdrawal 2.6.2: If a withdrawal is allowed (2.6.1), the exact amount requested shall be dispensed 3-Requirements Engineering19

Train protection system 3-Requirements Engineering20

Requirements Template (suggestion) 3-Requirements Engineering21

3-Requirements Engineering22

3-Requirements Engineering23

Four Easy Requirements Guidelines Avoid requirements “fusion” One requirement per requirement specification Be precise ( ถูกต้อง ) No vague requirements Be rigorous in defining requirements test cases If you cannot define how to test if a requirement is satisfied, you probably have a poor requirement Attach a person to each requirement People are much less likely to add “the kitchen sink” if their name is there – no gold plating 3-Requirements Engineering24

Each Requirement Must Be Correct The requirement is free from faults. Precise, unambiguous, and clear Each item is exact and not vague; there is a single interpretation; the meaning of each item is understood; the specification is easy to read. Complete The requirement covers all aspects of the user function. Consistent No item conflicts with another item in the specification. 3-Requirements Engineering25

Each Requirement Must Be (2) Relevant Each item is pertinent to the problem and its solution. Testable During program development and acceptance testing, it will be possible to determine whether the item has been satisfied. Traceable Each item can be traced to its origin in the problem environment. Feasible Each item can be implemented with the available techniques, tools, resources, and personnel, and within the specified cost and schedule constraints 3-Requirements Engineering26

The SRS (as a document) Must Be Complete All user requirements have been included. Do not forget abnormal and boundary cases. Consistent No item conflicts with another item in the specification. The requirements shall be at a consistent level of detail Manageable and Modifiable Things will change and we must be able to accommodate the inevitable requirements evolution. 3-Requirements Engineering27

Example The product shall provide status messages at regular intervals not less than every 60 seconds Is this a good requirement? 3-Requirements Engineering28

Example Rewritten 1. Status Messages 1.1 The Background Task Manager shall display status messages in a designated area in the user interface at intervals of 60 plus or minus 10 seconds. 1.2 If background processing is progressing normally, the percentage of the background task processing that has been completed shall be displayed. 1.3 A message shall be displayed when the background task is complete. 1.4 An error message shall be displayed if the background task has stalled or failed. 3-Requirements Engineering29

Requirements Rationale It is important to provide rationale with requirements This helps the developer understand the application domain and why the requirement is stated in its current form Particularly important when requirements have to be changed The availability of rationale reduces the chances that change will have unexpected effects 3-Requirements Engineering30

Why Rationale? Market Requirements Definition 1.One person must be able to load the boat on the car rack (Software) Requirements Specification 1.1 The boat must be lighter than 100 lb. 1.2 The boat must have handles to help one person lift it 1.3 The car rack must be padded so the boat can easily slide into the rack 1.4 Etc. 3-Requirements Engineering31

แบบฝึกหัด Cruise Control System โดยรายละเอียดมีดังนี้ คนขับสามารถใช้ระบบนี้เมื่อกดปุ่ม Start cruising ที่แผงหน้ารถ โดยระบบ จะทำงานก็ต่อเมื่อรถกำลังวิ่งด้วยความเร็วอย่างน้อย 40 km/h และไม่แตะ เบรก เมื่อ Cruise Control ทำงาน ระบบเซตความเร็วที่ต้องการไปยัง ความเร็วปัจจุบัน และรักษาความเร็วที่วัดได้ไม่เกิน 1.5 km/h ของความเร็ว ที่ต้องการ ปุ่ม Start accelerating ถูกใช้สำหรับเพิ่มความเร็วโดยไม่แตะคันเร่ง เมื่อปุ่ม นี้ถูกกดและ Cruise Control ทำงานอยู่ รถจะเร่งความเร็วเพิ่ม 2m/s เรื่อย ๆ จนกระทั่งกดปุ่ม Stop accelerating เมื่อ Cruise Control ทำงานอยู่ คนขับ สามารถเร่งความเร็วเองได้โดยแตะคันเร่ง และถ้าถอนคันเร่งความเร็วจะ กลับมาเท่ากับก่อนที่จะแตะคันเร่ง ถ้าคนขับกดปุ่ม Stop cruising ระบบจะหยุดทำงานทันที ปุ่ม Start accelerating จะไม่สามารถใช้งานได้จนกว่า cruise control จะทำงานอีก ครั้ง และถ้าคนขับแตะเบรก ในขณะที่ cruise control ทำงาน ก็จะทำให้ ระบบหยุดทำงาน หรือถ้าเราดับเครื่อง ระบบก็หยุดทำงานเช่นกัน ให้เขียน Requirement document ของระบบตามการทำงานของระบบคือ Start cruising, Stop cruising, Store Cruising Speed, Start accelerating, Stop accelerating 3-Requirements Engineering32