Introduction to Software Engineering (Lecture 4) 2024f PDF

SWE3002-42: Introduction to Software Engineering Lecture 4 – Requirements Engineering Sooyoung Cha Department of Computer Science and Engineering  Chapter 4. Requirement Engineering Topics covered 01 Requirements engineering 05 Requirements specif...

SWE3002-42: Introduction to Software Engineering Lecture 4 – Requirements Engineering Sooyoung Cha Department of Computer Science and Engineering  Chapter 4. Requirement Engineering Topics covered 01 Requirements engineering 05 Requirements specification 02 Functional and non-functional requirements 06 Requirements validation Requirements 03 engineering processes 07 Requirements change 04 Requirements elicitation Chapter 4. (p.101 ~ p.137) 2  Chapter 4-1. Requirements engineering Requirements engineering [Requirement]  The descriptions of the services that a system should provide and the constraints on its operation. Abstract statement of A detailed formal definition a service or a constraint of a system function “user requirements” “system requirements” [Requirement Engineering (RE)]  The process of finding out, analyzing, documenting and checking these services and constraints. (The first stage of the software engineering process) 3 (The very first stage, feasibility study, of the software engineering process)  Chapter 4-1. Requirements engineering User and system requirements [Example of user and system requirements]  MentCare: A medical system that maintains information about patients suffering from mental health problems and their treatments. 4  Chapter 4-1. Requirements engineering Types of requirements [Why are these two requirements necessary?]  Different types of readers use the requirements in different ways. ? ? How will the system be implemented? Reader A Reader B (User) (System) 5  Chapter 4-1. Requirements engineering Types of requirements [System stakeholders for MentCare]  Any person or organization who is affected by the system in some way and who has a legitimate interest Patients whose information is recorded in the system. Doctors who are responsible for assessing and treating patients. Nurses who coordinate the consultations with doctors. Receptionists who manage patients’ appointments. IT staff who are responsible for installing the system. 6  Chapter 4-2. Functional and non-functional requirements Functional and non-functional requirements [SW system requirements]  Functional requirements. Statements of services the system should provide. (e.g., input/output) Statements of what the system should not do. A statement limiting access to authorized users?  Non-functional requirements. Constraints on the services offered by the system. (e.g., timing constraint) Constraints that apply to the entire system rather than individual system features. 7  Chapter 4-2. Functional and non-functional requirements Functional requirements [Functional requirements]  Describing what the system should do.  Varying from general requirements to very specific requirements. [Example of functional requirements for Mentcare system]  (R1) A user is able to search the appointments lists for all clinics.  (R2) For each clinic and day, the system generates a list of patients who are expected to attend appointments that day.  (R3) Each staff member is uniquely identified by his eight-digit employee number. 8  Chapter 4-2. Functional and non-functional requirements Functional requirements [Functional requirements]  Imprecision in the requirements Leading to disputes between customers and SW developers. Delaying system delivery and increases costs.  Example of Imprecision in the requirements for Mentcare system (R1) A user is able to “search” the appointments lists for all clinics. Search for the name in all After choosing the clinic user attended, appointments at all clinics. search for the name in the clinic. 9  Chapter 4-2. Functional and non-functional requirements Functional requirements [ (Ideal) functional requirements ]  Completeness in requirements All services required by the user should be defined.  Consistency in requirements Requirements should not be contradictory. In practice, it is impossible to achieve requirements consistency and completeness for large systems. Easy to make mistakes. Have many stakeholders. 10  Chapter 4-2. Functional and non-functional requirements Non-functional requirements [Non-functional requirements]  Constrain characteristics of the system as a whole. Response time, memory use, reliability,...  Non-functional requirements > individual functional requirements. Failing to meet the requirement mean that the whole system is unusable.  Non-functional requirements arise through user needs. ex) budget constraints, organizational policies, safety regulations, privacy legislation. 11  Chapter 4-2. Functional and non-functional requirements Non-functional requirements [Types of non-functional requirements]  Product requirements Specifying the runtime behavior of the software. ex) execution speed, memory usage, acceptable failure rate, …  Organizational requirements Deriving from policies in the customer’s and developer’s organizations. ex) programming language, process standards to be used,...  External requirements Deriving from factors external to the system. ex) nuclear safety authority, legislative requirements,... 12  Chapter 4-2. Functional and non-functional requirements Non-functional requirements [Examples of non-functional requirements]  Mentcare system Product requirement The Mentcare system shall be available to all clinics during normal working hours (Mon–Fri, 08:30–17:30). Downtime within normal working hours shall not exceed five seconds in any one day. Organizational requirement Users of the Mentcare system shall authenticate themselves using their health authority identity card. External requirement The system shall implement patient privacy provisions as set out in HStan- 03-2006-priv. 13  Chapter 4-2. Functional and non-functional requirements Non-functional requirements [Types of non-functional requirements] 14  Chapter 4-2. Functional and non-functional requirements Non-functional requirements [Problems in non-functional requirements]  Stakeholders propose requirements as general goals. ex) ease of use, rapid user response,... The system should be easy to use by medical staff and should be organized in such a way that user errors are minimized. “testable” non-functional requirement. Medical staff shall be able to use all the system functions after two hours of training. After this training, the average number of errors made by experienced users shall not exceed two per hour of system use. 15  Chapter 4-2. Functional and non-functional requirements Non-functional requirements [Solutions in non-functional requirements]  Writing non-functional requirements quantitatively for testing.  Translating the customer’s goals into measurable requirements. Property Measure Speed Processed transactions/second, Screen refresh time, User/event response time Size Mbytes/ Number of ROM chips Ease of use Training time, Number of help frames Reliability Mean time to failure, Probability of unavailability, Rate of failure occurrence, Time to restart after failure, Percentage of events causing failure, Robustness Probability of data corruption Portability Percentage of target dependent statements, Number of target systems 16  Chapter 4-3. Requirements engineering processes Requirements engineering processes [Three key activities in requirements engineering]  Elicitation and analysis Interacting with stakeholders.  Specification Converting these requirements into a standard form.  Validation Checking that the requirements define the system that customer wants. In practice, RE is an iterative process in which the activities are interleaved. 17  Chapter 4-3. Requirements engineering processes Requirements engineering processes [A spiral view of the requirements engineering process] (Chapter 4-5) (Chapter 4-4) (Chapter 4-6) 18  Chapter 4-4. Requirements elicitation Requirements elicitation [Goal]  Understanding the work that stakeholders do and how they use a new system to help support that work. [Problems]  Stakeholders don’t know what they really want from a SW system.  Stakeholders express requirements in their own terms.  Different stakeholders express their requirements in different ways.  Political factors may influence the system requirements.  The requirements dynamically change during the analysis process. 19  Chapter 4-4. Requirements elicitation Requirements elicitation [The requirements elicitation and analysis process] 20  Chapter 4-4. Requirements elicitation Requirements elicitation [The requirements elicitation and analysis process] Requirements discovery and understanding Interacting with stakeholders to discover their requirements. Requirements classification and organization Grouping related requirements and organizing them into coherent clusters. Requirements prioritization and negotiation Prioritizing requirements and resolving requirements conflicts. Requirements documentation Documenting requirements. (e.g., early draft of SW requirement, whiteboard, wikis) 21  Chapter 4-4. Requirements elicitation Requirements elicitation techniques [Two fundamental approaches to requirements elicitation]  Interviewing (= Talking to people about what they do.) Closed interviews, where the stakeholder answers predefined questions. Open interviews, in which there is no predefined agenda.  Observation or Ethnography Watching people doing their job to see what artifacts they use, how they use them, and so on 22  Chapter 4-4. Requirements elicitation Requirements elicitation techniques [Eliciting domain knowledge through interviews is difficult]  Usage of domain specific terminologies.  Difficulty for explaining some familiar domain knowledge.  Omitting to mention fundamental knowledge to stakeholders. 23  Chapter 4-4. Requirements elicitation Stories and scenarios [Stories and scenarios]  A description of how the system can be used for a particular task. Stories: narrative text for a high-level description of system use. Scenarios: specific information collected such as inputs and outputs. [The purpose of Stories]  Facilitating discussion of how the system might be used.  Acting as a starting point for eliciting the requirements for that system. 24  Chapter 4-4. Requirements elicitation Stories and scenarios [iLearn:The stories for photo sharing in the classroom] Jack is a primary school teacher in northern Scotland. He has decided that a class project should be focused on the fishing industry in the area, looking at the history, development, and economic impact of fishing. As part of this project, pupils are asked to gather and share reminiscences from relatives, use newspaper archives, and collect old photographs related to fishing and fishing communities in the area. Pupils use an iLearn wiki to gather together fishing stories and SCRAN to access newspaper archives and photographs. However, Jack also needs a photo-sharing site because he wants pupils to take and comment on each other’s photos and to upload scans of old photographs that they may have in their families. Jack sends an email to a primary school teachers’ group, which he is a member of, to see if anyone can recommend an appropriate system. Two teachers reply, and both suggest that he use KidsTakePics, a photo-sharing site that allows teachers to check and moderate content. As KidsTakePics is not integrated with the iLearn authentication service, he sets up a teacher and a class account. He uses the iLearn setup service to add KidsTakePics to the services seen by the pupils in his class so that when they log in, they can immediately use the system to upload photos from their mobile devices and class computers. 25  Chapter 4-4. Requirements elicitation Stories and scenarios [Scenarios]  A structured form of the user stories.  The common characteristics of a scenario. A description of what the system expect when the scenario starts. A description of the normal flow of events in the scenario. A description of what can go wrong. Information about other activities that are going on at the same time. A description of the system state when the scenario ends. 26  Chapter 4-4. Requirements elicitation Stories and scenarios [The scenario for uploading photos to KidsTakePics]  Initial assumption: A user or a group of users have one or more digital photographs to be uploaded to the picture sharing site. These are saved on either a tablet or laptop computer. They have successfully logged on to KidsTakePics.  Normal: The user chooses to upload photos and is prompted to select the photos to be uploaded on the computer and to select the project name under which the photos will be stored. Users should also be given the option of inputting keywords that should be associated with each uploaded photo. Uploaded photos are named by creating a conjunction of the user name with the filename of the photo on the local computer. On completion of the upload, the system automatically sends an email to the project moderator asking them to check new content and generates an on-screen message to the user that this has been done. 27  Chapter 4-4. Requirements elicitation Stories and scenarios [Uploading photos to KidsTakePics]  What can go wrong: No moderator is associated with the selected project. An email is automatically generated to the school administrator asking them to nominate a project moderator. Users should be informed that there could be a delay in making their photos visible. Photos with the same name have already been uploaded by the same user. The user should be asked if they wish to re-upload the photos with the same name, rename the photos or cancel the upload. If they chose to re-upload the photos, the originals are overwritten. If they chose to rename the photos, a new name is automatically generated by adding a number to the existing file name.  Other activities: The moderator may be logged on to the system and may approve photos as they are uploaded.  System state on completion: User is logged on. The selected photos have been uploaded and assigned a status ‘awaiting moderation’. Photos are visible to the moderator and to the user who uploaded them. 28  Chapter 4-5. Requirements specification Requirements specification [Requirements specification]  The process of writing down the user and system requirements.  User requirements They are usually written in natural language They have to be understandable by end-users.  System requirements Expanded versions of the user requirements. The part of the contract for the implementation of the system. 29  Chapter 4-5. Requirements specification Requirements specification [Notations for writing system requirements] Notation Description Natural The requirements are written using numbered sentences in natural language language. Each sentence should express one requirement. Structured The requirements are written in natural language on a standard form natural or template. Each field provides information about an aspect of the language requirement. Graphical models, supplemented by text annotations, are used to define the Graphical functional requirements for the system; UML use case and notations sequence diagrams are commonly used. These notations are based on mathematical concepts such as finite- Mathematical state machines or sets. Although these unambiguous specifications can specifications reduce the ambiguity in a requirements document, most customers don’t understand a formal specification. 30  Chapter 4-5. Requirements specification Natural language specification [Natural language]  The most widely used way of specifying SW requirements. (+) expressive, intuitive, and universal. (- ) vague, ambiguous. [Guidelines for writing natural language requirements]  Use language consistently to distinguish between mandatory and desirable requirements. (e.g., shall vs should)  Use text highlighting to identify key parts of the requirement.  Do not assume that readers understand technical SE language.  Associate a rationale with each user requirement. (e.g., why? who?) 31  Chapter 4-5. Requirements specification Natural language specification [Example requirements for the insulin pump SW system] The system shall measure the blood sugar and deliver insulin, if required, every 10 minutes. (Changes in blood sugar are relatively slow, so more frequent measurement is unnecessary; less frequent measurement could lead to unnecessarily high sugar levels.) 32  Chapter 4-5. Requirements specification Structured specifications [Structured specifications]  A way of writing system requirements where requirements are written in a standard way rather than as free-form text. A description of the function or entity being specified. A description of its inputs and outputs. The information needed for the computation. A description of the action to be taken. A precondition, post-condition. A description of the side effects (if any) of the operation. 33  Chapter 4-5. Requirements specification Structured specifications [The structured specification of a requirement for an insulin pump] 34  Chapter 4-5. Requirements specification Structured specifications [The tabular specification]  Useful when there are a number of possible alternative situation.  Useful when complex computations are to be specified. Example requirements for the insulin pump software system 35  Chapter 4-5. Requirements specification Use cases [Use cases]  A way of describing interactions between users and a system. Actor (human or other systems), Each class of interaction “Use cases for the Mentcare system” 36  Chapter 4-5. Requirements specification The software requirements document [The software requirements document]  An official statement of what the system developers should implement. (The software requirements specification or SRS)  Including both the user and system requirements.  Having a diverse set of users. Customers, managers, engineers, test engineers, …. 37  Chapter 4-5. Requirements specification The software requirements document [Users of a requirements document]  Showing possible users of the document and how they use it. 38  Chapter 4-5. Requirements specification The software requirements document [Users of a requirements document]  Showing possible users of the document and how they use it. 39  Chapter 4-5. Requirements specification The software requirements document [The structure of a requirements document] Chapter Description This should define the expected readership of the document and Preface describe its version history, including a rationale for the creation of a new version and a summary of the changes made in each version. This should describe the need for the system. It should briefly describe the system’s functions and explain how it will work with other systems. Introduction It should also describe how the system fits into the overall business or strategic objectives of the organization commissioning the software. This should define the technical terms used in the document. You Glossary should not make assumptions about the experience or expertise of the reader. 40  Chapter 4-5. Requirements specification The software requirements document [The structure of a requirements document] Chapter Description Here, you describe the services provided for the user. The nonfunctional system requirements should also be described in this User requirements section. This description may use natural language, diagrams, or other definition notations that are understandable to customers. Product and process standards that must be followed should be specified. This chapter should present a high-level overview of the anticipated system architecture, showing the distribution of functions across System architecture system modules. Architectural components that are reused should be highlighted. 41  Chapter 4-5. Requirements specification The software requirements document [The structure of a requirements document] Chapter Description This should describe the functional and nonfunctional requirements System requirements in more detail. If necessary, further detail may also be added to the specification nonfunctional requirements. Interfaces to other systems may be defined. This might include graphical system models showing the relationships between the system components and the system and System models its environment. Examples of possible models are object models, data-flow models, or semantic data models. This should describe the fundamental assumptions on which the system is based, and any anticipated changes due to hardware System evolution evolution, changing user needs, and so on. This section is useful for system designers as it may help them avoid design decisions that would constrain likely future changes to the system. 42  Chapter 4-5. Requirements specification The software requirements document [The structure of a requirements document] Chapter Description These should provide detailed, specific information that is related to the application being developed; for example, hardware and database descriptions. Hardware requirements define the minimal and Appendices optimal configurations for the system. Database requirements define the logical organization of the data used by the system and the relationships between data. Several indexes to the document may be included. As well as a Index normal alphabetic index, there may be an index of diagrams, an index of functions, and so on. 43  Chapter 4-6. Requirements validation Requirements validation [Requirements validation]  The process of checking whether requirements define the system that the customer really wants.  Critical process in a requirements document. The errors can lead to extensive rework costs when these problems are discovered after the system is in service. [Requirements validation techniques] Requirements reviews Prototyping Test-case generation 44  Chapter 4-6. Requirements validation Requirements validation [Different types of checks in requirements validation] Validity The requirements reflect the real needs of system users. Consistency Requirements in the document should not conflict. Completeness Requirements define all functions and the constraints. Realism Requirements can be implemented within the budget. checks Requirements should always be written so that they are Verifiability verifiable. (e.g., a set of test-cases) 45  Chapter 4-7. Requirements Change Requirements Change [Requirements Change]  The requirements for large software systems are always changing. Interfacing the system with other systems. New legislation and regulations may be introduced. People who pay for a system and the users of that system are not same.... 46 “Requirements evolution”  Chapter 4-7. Requirements Change Requirements Change [Issues for requirements management planning]  Requirements identification Each requirement must be uniquely identified so that it can be cross- referenced with other requirements.  A change management process This is the set of activities that assess the impact and cost of changes.  Tool support Requirements management involves the processing of large amounts of information about the requirements. (e.g., shared spreadsheets) 47 Chapter 4. Requirements Engineering Summary Requirements Engineering Elicitation Specification Validation User System Functional Non-Functional Requirements Requirements Requirements Requirements Thank You