This document provides an overview of requirement elicitation, analysis, and specification for object-oriented software engineering. It discusses techniques for requirement elicitation including questionnaires, task analysis, interviews, scenarios, and use cases. It also describes requirement elicitation activities such as identifying actors, scenarios, use cases, and refining requirements. Additionally, it covers functional and non-functional requirements, correctness, completeness, consistency and other concepts related to requirement specification. Finally, it includes a requirements analysis document template.

1. Object Oriented Software
Engineering
Yoseph K, Instructor
yosefkrs@outlook.com
Office Hours: Monday - Saturday
1

2. Lecture 3: Requirement Elicitation, Analysis
and Specification
´In this chapter, we will focus on:
´Requirement Elicitations and analysis
´Techniques in requirement elicitation
´Requirement elicitation activities and concepts
´Documentation template
2

3. Requirement
´ Requirement is a necessity or prerequisite which specifies a verifiable constraint on an
implementation of a system.
´ Requirement is a feature that the system must have or a constraint that it must satisfy to
be accepted by the client.
´ Requirement engineering can be described into two distinct ways.
´ Requirements elicitation :
´ Focuses on describing the purpose of the system.
´ Definition of the system in terms understood by the customer
´ Requirements specification
´ Requirements analysis :
´ results into an analysis model which developers can interpret
´ Definition of the system in terms understood by the developer
´ Technical specification
3

4. Techniques to elicit Requirements
´ The following below provide tools for requirement elicitation.
´ Questionnaires: Asking end user a list of pre-selected questions
´ Task Analysis: Observing end users in their operational environment
´ Interview: official face to face meeting with customers
´ Scenarios: describes an example of system use in terms of a series of interactions
between the user and the system.
´ Use case: is an abstraction that describes a class of scenarios.
4

5. An overview of requirements elicitation
´ Requirements elicitation focuses on describing the purpose of the system.
´ The client, the developers, and the users identify a problem area and define a system that
addresses the problem.
´ Such a definition is called a system specification and serves as a contract between the
client and the developers.
´ The system specification is structured and formalized during analysis to produce an analysis
model.
´ Both system specification and analysis model represent the same information. They differ
only in the language and notation they use.
´ The system specification is written in natural language, where as the analysis model is
usually expressed in a formal or semiformal notation.
´ The system specification supports the communication with the client and users.
´ The analysis model supports the communication among developers.
5

6. Cont’d
´ Requirements elicitation and analysis focus only on the user’s view of the
system:
´ The system functionality.
´ The interaction between the user and the system.
´ The errors that the system can detect and handle.
6

7. Requirements elicitation activities:
´ The following are part of the requirement elicitation activities.
´ Identifying actors- During this activity, developers identify the different types of users the
future system 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- Once developers and users agree on a set of scenarios,
developers derive from the scenarios a set of use cases that completely represent the
future system.
´ Refining use cases- developers ensure that the system specification is complete, by
detailing each use case and describing the behaviour of the system in the presence of
errors and exceptional conditions.
´ Identifying relationships among use cases- developers combine the use case model by
eliminating redundancies. This ensures that the system specification is consistent.
´ Identifying non-functionalrequirements- developers, users, and clients agree on aspects
that are visible to the user but not directly related to functionality.
7

8. Scenario-Based Design
´ A scenario is a concrete, focused, informal description of a single feature of the system from
the viewpoint of a single actor.
´ Simply, we can define a scenario as an instance of a use case.
´ Scenarios and use cases provide tools for bridging this gap. A scenario describes an
example of system use in terms of a series of interactions between the user and the system. A
use case is an abstraction that describes a class of scenarios. Both scenarios and use cases
are written in natural language, a form that is understandable to the user.
´ Scenarios can have many different uses during requirements elicitation and during other
activities of the life cycle.
´ Below is a selected number of scenario types :
´ As-is scenarios describe the current situation.
´ Visionary scenarios describe the future system.
´ Evaluation scenarios describe user tasks against which the system is to be evaluated.
´ Training scenarios are tutorials used for introducing new users to the system.
8

9. Requirements elicitation concepts
´ In this section, we describe the main requirements elicitation concepts we use in this
chapter. In particular, we describe:
´ Functional requirements
´ Non-functional requirements
´ Pseudo requirements (Constraints)
´ Correctness, completeness, consistency, clarity and realism.
´ Greenfield engineering, reengineering, and interface engineering
9

10. Functional requirements
´ Describe the interactions between the system and its environment independent of its
implementation.
´ The environment includes the user and any other external system with which the system
interacts.
Non-Functional requirements
Ø Describe user-visible aspects of the system that are not directly related with the functional
behavior of the system.
Ø Nonfunctional requirements include quantitative constraints, such as response time (i.e.,
how fast the system reacts to user commands) or accuracy (i.e., how precise are the
system’s numerical answers).
10

11. § Pseudo Requirements:
§ Are requirements imposed by the client that restrict the implementation of the
system.
§ Typical pseudo requirements are the implementation language and the platform
on which the system is to be implemented.
§ Pseudo requirements have usually no direct effect on the users’ view of the
system.
11

12. Basic terminologies in Requirement
specification
qRequirementsSpecifications should be:
ü Complete: - All possible scenarios in the system are described
ü Consistent: It doesn’t contradict it self, implies fault tolerance.
ü Clear: - System is exactly defined. It is should be unambiguous.
ü Correct: - It represents accurately the system that the client needs and that
developments intended to build.
ü Realistic: - The system can be implemented within constraints.
ü Verifiable: - Once the system is built, repeatable test can be designed to demonstrate
that the system fulfills the requirement
ü Traceable: - each system function can be traced to its corresponding set of
requirements.
12

13. 13

14. Requirements Analysis Document Template
´ Introduction
´ Current system
´ Proposed system
´ Overview
´ Functional requirements
´ Nonfunctional requirements
´ Constraints (pseudo requirements)
´ System models
´Scenarios
´Use case model
´Object model
´Data dictionary
´Class diagrams
´Dynamic models
´User interface
´ Glossary
14

15. An overview of Design Concepts
´ Analysis
´ Focus on understanding the problem (Idealized design)
´ Focus on Behavior and system structure
´ Functional requirements and for a small model
´ Design
´ Focus on understanding the solution
´ Operations and Attributes (performance)
´ Close to real code and object lifecycles
´ Non-functional requirements and a large model
15

16. Types of design concepts
´ Abstraction:
´ Abstraction refers to the act of representing essential features without including the
background details.
´ The abstraction concept is usually used during analysis and design:
´ i.e deciding only with application domain, not making implementation decision.
´ Divide a single problem to many simple sub-tasks.
´ collect essential elements composing to a compound data
´ Information hiding (Encapsulation)
´ Packaging related data and operations together
´ It hides the internal data from external by methods (interface).
16

17. Cont’d
´ Cohesion
´ It is the strength of dependencies within a subsystem/module.
´ A measure of functional strength; strive for high cohesion
´ If a subsystem contains many objects that are related to each other and perform similar
tasks, its coherenceis high.
´ If a subsystem contains a number of unrelated objects, its coherenceis low.
´ A desirable property of subsystem decomposition is that it leads to subsystems with high
coherence.
17

18. Cont’d
´ Coupling
´ Coupling is the degree of interaction between modules/subsystems
´ The term coupling refers to the act of joining things together, such as the links of a
chain.
´ In the software world, coupling typically refers to the degree to which software
components depend upon each other.
´ There are different types of coupling architectures.
´ Tightly coupling
´ Loosely coupling
18