1 / 19

Requirement Elicitation

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

elashonda
Download Presentation

Requirement Elicitation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Overview of Requirements Elicitation • Arequirementis 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 9 - 09/27

  3. 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 softwarerequirements specification (SRS). CEN 4010 Class 9 - 09/27

  4. 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 9 - 09/27

  5. 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 9 - 09/27

  6. 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 9 - 09/27

  7. 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 9 - 09/27

  8. Functional Requirements • Functional requirements describe interactions between the system and its environment independent of its implementation. • Three levels of requirements: • User requirements – statements in natural language plus diagrams. (target client, end users) • 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 9 - 09/27

  9. Functional Requirements • 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: • The system shall provide the CS user with a template for data entry (See appendix A). CEN 4010 Class 9 - 09/27

  10. Functional Requirements Example of a system requirement cont: • 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.) • The CS user shall send the request by selecting the send button. • The system shall notify the CS user if the request was submitted correctly by displaying a message on screen. • When the request is received the system shall generate a request record and allocate a unique request id. CEN 4010 Class 9 - 09/27

  11. 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 9 - 09/27

  12. 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 9 - 09/27

  13. 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 9 - 09/27

  14. Nonfunctional Requirements cont Sommerville 2001 CEN 4010 Class 9 - 09/27

  15. 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 9 - 09/27

  16. 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 9 - 09/27

  17. 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 9 - 09/27

  18. 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 9 - 09/27

  19. 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. CEN 4010 Class 9 - 09/27

More Related