Chapter 4: Requirements Elicitation

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

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

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

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

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

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

7. Traceability Enables: Show system is complete Show the system complies with its requirements Record the rationale behind the system Assess the impact of change 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

8. Two-line display (time and date) 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? II- Maintaining Traceability SatWatch Single-line display + Button Traceability would enable answering those questions:

9. II- Maintaining Traceability Cross-reference Documents Code Artifacts Models Requirement Component Class Operation Test case (1) (2) (3) (4) (5) Dependencies # of Source Element # of Target Element

10. II- Maintaining Traceability Cross-reference expensive Time PersonPower Small Project Large-scale Project Developers can observe benefits early Specialized database tools

11. 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 RAD Audience Client Users Project Management System Analysts System Designer

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

13. RAD Example • 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 • 3.3.1 Usability • 3.3.2 Reliability • 3.3.3 Performance • 3.3.4 Supportability • 3.3.5 Implementation • 3.3.6 Interface • 3.3.7 Packaging • 3.3.8 Legal • 3.4 System Models • 3.4.1 Scenarios • 3.4.2 Use Case Model • 3.4.3 Object Model • 3.4.4 Dynamic Model • 3.4.5 User-Interface – navigational paths and screen mock-ups • 4. Glossary