Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and Verification. CEN 4010 Class 9 – 09/27

CEN 4010 Class /272 Overview of Requirements Elicitation A requirement is a feature that the system must have or a constraint that it must satisfy to be accepted by the client. Requirements engineering aims at defining the requirements of the system under construction. Requirements engineering consists of requirements elicitation and analysis.

CEN 4010 Class /273 Overview of Requirements Elicitation Focuses on describing the purpose of the system. During requirements elicitation the developers gain an understanding of how the system should work. The descriptions of the services and constraints of the system are referred to as the requirements. The requirements are defined in the software requirements specification (SRS).

CEN 4010 Class /274 Overview of Requirements Elicitation cont SRS serves as a contract between the client and the developers. SRS is structured and formalized during analysis to produce the analysis model. SRS is written in structured natural language – supports communication with client and users. Analysis model is usually expressed in a formal or semiformal notation e.g. an object diagram – supports communication with developers. See figure 4-1 on Page 123.

CEN 4010 Class /275 Overview of Requirements Elicitation cont Requirement elicitation activities: Identifying actors – different types of users the systems will support. Identifying scenarios – developers observe users and develop a set of detailed scenarios for typical functionality provided by the future system. Identifying use cases – developers create use cases based on the scenarios, i.e., use detailed examples to describe the behavior of the system.

CEN 4010 Class /276 Overview of Requirements Elicitation cont Refining use cases – ensures the system’s behavior is complete, i.e., describe the behavior of the system in the presence of errors and exceptional conditions. Identifying relationships among use cases – consolidate the use case model by eliminating redundancies. Ensures the specification is consistent.

CEN 4010 Class /277 Overview of Requirements Elicitation cont Identifying nonfunctional constraints – aspects of the systems visible to the user but not directly related to the functionality. Constraints include: –performance –documentation –resources –security –quality

CEN 4010 Class /278 Functional Requirements Functional requirements describe interactions between the system and its environment independent of its implementation. Three levels of requirements: 1.User requirements – statements in natural language plus diagrams. (target client, end users) 2.System requirements (or functional specification) – sets out system services and constraints in detail. Contract between system buyer and developer. (target end users, clients, s/w developers.)

CEN 4010 Class /279 Functional Requirements 3.Software design specification – abstract description of software design. (target s/w developers) Example of a user requirement: The system shall provide a means to send a request to the Support Services helpdesk. Example of a system requirement: 1.The system shall provide the CS user with a template for data entry (See appendix A).

CEN 4010 Class /2710 Functional Requirements Example of a system requirement cont: 2.The system shall provide the CS User with a screen to enter the following data: user id, name, machine name (if any), location, and a short description of the problem. (The highlighted words are the required fields.) 3.The CS user shall send the request by selecting the send button. 4.The system shall notify the CS user if the request was submitted correctly by displaying a message on screen. 5.When the request is received the system shall generate a request record and allocate a unique request id.

CEN 4010 Class /2711 Nonfunctional Requirements Not directly concerned with the specific functions delivered by the system. Nonfunctional requirements relate to the system as a whole rather than individual system features. Note failure to meet an individual functional requirement may degrade the system, failure to meet a non-functional requirement may make the whole system unusable.

CEN 4010 Class /2712 Nonfunctional Requirements Usability – the ease with which a user learn to operate, prepare inputs for, and interpret outputs of a system or component. Reliability – the ability of a system or component to perform its required functions under stated conditions for a specified period of time. Performance – concerned with quantifiable attributes of the system, e.g., response time, throughput, availability and accuracy.

CEN 4010 Class /2713 Nonfunctional Requirements Supportability – concerned with the ease of changes to the system after deployment.  Adaptability – the ability to change a system to deal with additional domain concepts.  Maintainability – the ability to change the system to deal with the new technology or to fix defects.

CEN 4010 Class /2714 Nonfunctional Requirements cont PropertyMeasure SpeedProcessed transactions/sec., Screen refresh time SizeK bytes, Number of RAM Chips Ease of UseTraining Time, Number of help frames ReliabilityMean time to failure, Probability of unavailability, Rate of failure occurrence, Availability RobustnessTime to restart after failure, Percentage of events causing failure, Probability of data corruption on failure PortabilityPercentage of target-dependent statements, Number of target systems Sommerville 2001

CEN 4010 Class /2715 Software Requirements Document 1. Introduction 1.1 Purpose of system 1.2 Scope of system 1.3 Definitions, acronyms, and abbreviations 1.4 Overview of document 2. Current System (limitations and problems) 3. Proposed system 3.1 Overview 3.2 Functional requirements (in terms of use cases) 3.3 Nonfunctional requirements 3.4 System models e.g., use case, object 4. Glossary 5. Appendix The outline we will use for the SRD is online - Project Deliverable 1.

CEN 4010 Class /2716 Requirements Validation Involves checking that the specification is correct, complete, consistent, unambiguous, and realistic. Correct – accurately represents the client’s view of the system. Complete – all possible scenarios are described including exceptional behavior. Consistent – does not contradict itself.

CEN 4010 Class /2717 Requirements Validation cont Unambiguous – exactly one system is defined. Realistic – system can be implemented with constraints. Requirement validation techniques: –Requirement reviews –Prototyping –Test case generation –Automated consistency analysis (e.g. Rose)

CEN 4010 Class /2718 Requirements Validation cont Requirement Reviews:  Verifiability – Is the requirement as stated realistically testable?  Comprehensibility – Is the requirement properly understood by the clients or end-users of the system.  Traceability – Is the origin of the requirement clearly stated?  Adaptability – Can the requirement be changed without large-scale effects on other system requirements?

CEN 4010 Class /2719 Realism, Verifiability and Traceability Note the SRS should be realistic, verifiable and traceable. Realistic – system can be implemented within constraints. Verifiable – once the system is built, repeatable tests can be designed to demonstrate that the system fulfills the SRS. Traceability – each requirement can be traced throughout the s/w development to its corresponding system function(s) and vice versa.