Chapter 4: Requirements Elicitation 4.5: Managing Requirements Elicitation Supervised by: Dr. Qutaibah Malluhi Software Engineering Done by: Sarah Al-Aqailly Qatar University

4.4: Requirements Elicitation Activities 1. Identifying actors 2. Identifying Scenarios 3. Identifying Use Cases 4. Refining Use Cases 7. Identify Nonfunctional Requirements 6. Identifying Initial Analysis Objects 5. Identifying Relationships Among Actors & Use Cases

4.5: Managing Requirements Elicitation 1 1 Negotiating Specifications with Clients 2 2 Maintaining Traceability 3 3 Documenting Requirements Elicitation

I- Negotiating Specifications with Clients: JAD Joint Application Design Users Developers ClientsLeader Requirements Specification Document Complete Definition of data elements Interface Screens Work Flow

Joint Application Design Negotiating Specifications with Clients: JAD Final Document Preparation Session Preparation Research Project Definition

Negotiating Specifications with Clients: JAD Project Definition Research Management Definition guide Session Agenda Preliminary Specification Preparation Working document Session script Session Script forms Final document preparation Final document

II- Maintaining Traceability Traceability: is the ability to follow the life of a requirements. This include tracing where the requirements came from; to which aspects it affects. 1-Developers 2-Testers 3-Designers 4- Maintainers Show system is complete Show the system complies with its requirements Record the rationale behind the system Assess the impact of change Traceability Enables:

II- Maintaining Traceability SatWatch Two-line display (time and date) Single-line display + Button  Who originated the two-line display requirements?  Did any implicit constraints mandate this requirements?  Which components must be changes because of the additional button and display?  Which test cases must be changed? Traceability would enable answering those questions:

# of Source Element # of Target Element II- Maintaining Traceability Cross-reference Documents Models Code Artifacts RequirementComponentClass OperationTest case Dependencies (1) (2) (3) (4)(5)

Developers can observe benefits early II- Maintaining Traceability Cross-reference expensive TimePersonPower Small Project Specialized database tools Large-scale Project

III- Documenting Requirements Elicitation Requirements Analysis Document (RAD) 1- describe the system in terms of functional and nonfunctional 2- serves as contractual Basis between the client and developers ClientUsersProject Management System AnalystsSystem Designer RAD Audience

III- Documenting Requirements Elicitation First Part of Document Includes: Use Cases & Nonfunctional Requirements Written During: Requirements Elicitation Second Part of Document Includes: Formalization of the specification in terms of object Models Written During: Analysis

RAD Example 1.Introduction 1.1 Purpose of the system 1.2 Scope of the System 1.3 Objective and success criteria of the project 1.4 Definitions, acronyms, and abbreviations 1.5 References 1.6 Overviews 2. Current System 3. Proposal System 3.1 Overview 3.2 Functional Requirements 3.3 Nonfunctional Requirements Usability Reliability Performance Supportability Implementation Interface Packaging Legal 3.4 System Models Scenarios Use Case Model Object Model Dynamic Model User-Interface – navigational paths and screen mock-ups 4. Glossary