Requirement engineering is the process of identifying stakeholders' needs and defining the requirements of a system. The presenter outlines key activities in requirement engineering including elicitation, analysis, modeling, communication, management, agreeing, and evolving requirements. Research focuses on improving elicitation techniques, quality requirements, risk analysis, scenario modeling, formal modeling, and bridging the gap between research and practice in requirements engineering.

1. Requirement
Engineering Evaluation
Presented by: Ishraq Fatafta

2. Agenda
O Introduction.
O Requirement Engineering Overview.
O Requirement Engineering activities.
O Research in Requirement Engineering.
O Requirement Engineering Emerging
trends.
O Conclusion and Future work.

3. Introduction
O What is Requirement engineering.
O Why we study Requirement engineering.
O Basis for this research paper:
O A roadmap by Bashar Nuseibeh and Steve
Easterbrook at year 2000.
O Evaluate work since the past 10 years.

4. Requirement Engineering
Roadmap
Nuseibeh and Easterbrook
O Trends from the past:
O Analysis and requirements should be
carried out in the context of the
Organization.
O Modeling the environment rather than
system functionality accompanied with a
shift toward stakeholders goals modeling.
O The need to consider requirement conflicts
and there is no complete requirement
model.

5. Requirement Engineering
Roadmap
Nuseibeh and Easterbrook
O RE challenges in the years ahead of
2000:
O Developing new techniques for formal
modeling and analysis.
O Bridging the gap between formal and
contextual requirement elicitation.
O More models for analyzing non-functional
requirements.
O Better understand the impact of software
architecture chosen.

6. Requirement Engineering
Roadmap
Nuseibeh and Easterbrook
O Requirement models Reuse.
O Multidisciplinary training for requirement
engineers.

7. Requirement Engineering
Overview
O Why RE is important
O Determine what the system will do.
O Requirements defined with regard to the
context.
O Error costs are enormous over time.
O Past project Experience.
O Large scale systems.

8. Requirement Engineering
Overview Cont.
O Why RE is difficult
O Abstract requirements at the beginning.
O Various sources of requirements.
O Requirements in regard to the context.
O Evolving nature of the system.
O Difficult to create requirement statement
understandable by both non-technical and
technical people.

9. Requirement Engineering
Activities
O Requirement engineering process: series of
activities that intends to identify the needs of
various stakeholders, analyze them and verify
their validity in the context of the system.
O Elicitation.
O Modeling and Analysis.
O Communication and management.
O Agreeing.
O Evolving.

10. RE Activity: Elicitation
O Requirement gathering from various users
and stakeholders.
O Elicitation techniques:
O Traditional techniques.
O Interviews, Surveys, Observation, RAD/JAD,
Focus group, Document Analysis.
O Contextual and Personal techniques.
O Ethnography, Interface analysis, Reverse
engineering.

11. RE Activity: Elicitation Cont.
O Elicitation techniques:
O Innovative techniques.
O Brainstorming, workshops.
O Feedback techniques.
O Prototypes, Storyboard, visual and use
models.

12. RE Activity: Elicitation Cont.
O Research findings:
O Complexity and difficulty of elicitation, situations and
context of elicitation variable.
O Each project has its own characteristics and properties.
O Stakeholders vary and the degree of communication with
analysts, their experience and maturity are important.
O Elicitation vary by technological advances and solutions.
O The gap between requirement elicitation research and
practice still exists due to many factors like missing
processes documentation, lack of reports and cases
about specific problems and the difficulty in transferring
knowledge in this regard.

13. RE Activity: Analysis and
Modeling
O Requirement Analysis:
O Identifying the specifications of the system
that satisfies the customers’ demands and
provide enough information to build the
system.
O Formal or semi-formal description of the
problem to be solved that is represented in
a way that is difficult to be understood by
customers.
O Elaborates on requirements collected at
earlier stages of the project.

14. RE Activity: Analysis and
Modeling Cont.
O Requirement Modeling:
O Inherits the same specifications as requirement
analysis.
O Result is easily understandable by both users
and engineers of the system.
O Modeling notations used to specify how the
system will be constructed and interpreted.
O Notations can be any symbols, text, characters
and abbreviated expressions that raise the
level of abstraction in the requirement
description.

15. RE Activity: Analysis and
Modeling Cont.
O Research Findings:
O Quality Requirement should be imposed in this
stage.
O Quality measures are different from various
stakeholder point of view.
O Result from requirement analysis should be
correct, complete, consistent and unambiguous
set of requirements that can be transformed later
into models.
O Researchers focus on finding new or improved
techniques for evaluating the quality of
requirements delivered at this stage.

16. RE Activity: Analysis and
Modeling Cont.
O Research Findings:
O Risk analysis
O Countermeasures to system design
approaches and fine-tuning of the system are
more likely to change during various
phases, once risk associated with them are
evaluated and documented during
requirement analysis, problems associated
with these defects and costs can be
prevented.

17. RE Activity: Analysis and
Modeling Cont.
O Research Findings:
O Scenario-based modeling
O Description to real world scenario and stories.
O When performed before the design phase
O better understanding how the future system will
operate.
O When it will fail to meet demands.
O Provide description on various user behaviors and
interactions.

18. RE Activity: Analysis and
Modeling Cont.
O Research Findings:
O Extended requirement models:
O State-oriented modeling, FSMs and FSMDs used in
Controls systems, StateCharts and Petri nets that
provides a mathematical basis for formal analysis.
O Activity-oriented modeling, DFDs and flowchart.
O Heterogonous modeling.
O Multiple view modeling, UML.
O Structure modeling, Component connectivity diagrams
(CCDs).

19. RE Activity: Analysis and
Modeling Cont.
O Research Findings:
O Requirement transformation: Use cases into object-
oriented classes/objects models.
O Usage of functional and behavioral notations in
requirement modeling is still in use.
O Progress in the usage of specialized notations of the
environment was slow.
O Development of new techniques for formal modeling and
analysis of non-functional requirements.
O The gap between functional and non-functional
requirement modeling has been narrowed: natural
language, semantic notations, formal design analysis
and quality attributes.

20. RE Activity: Communication
O RE is the most communication rich phase.
O Carried out in a structural way.
O Communication in global software
development is challenging.
O Tools should be developed to enhance
communication in distributed systems.

21. RE Activity: Management
O Identification of requirements, managing
of change and identifying traceability
between them can be utilized by using
management tools and automated
techniques.
O Tools are used for storing and recalling
requirements, annotating requirements
and assigning relationships between them
O Need to evaluate change, planning and
managing their effects throughout the
entire system.

22. RE Activity: Management
Cont.
O Global and distributed requirement
engineering issues should be addressed
when managing requirements.
O Requirements from large scale systems
involve a considerable flow of
requirements that need to be carefully
managed and evaluated.

23. RE Activity: Agreeing
O Verify and validate that requirements
analyze and model accurately what the
stakeholder need.
O Validation is subjective task that uses
informal specifications or undocumented
requirements.
O verification is made When a formal
description of the requirements exists.

24. RE Activity: Agreeing Cont.
O Research findings:
O Researchers focus on improving the type of
information given to stakeholders for feedback.
O graphical animation and simulation, Model checking .
O Improve quality of requirements by using verification
and validation techniques:
O Non-executable specifications are written in natural
language that is verified using experimental
requirement management (ERM) tool.
O executable specifications are written in declarative
languages such as java modeling languages and
requirements can be verified through developing
prototypes

25. RE Activity: Evolving
O Requirements Evolve as system evolve over
time.
O Globalization, scalability and outsourcing
when adapting to change.
O Researches focus on various interactions with
the stakeholders, consistent adaption of
change and the use of tools for presenting
information.
O Empirical analysis of requirement evolution
provides practical experience measures on
drivers of evolution
O no huge advances in this regard.

26. Research in Requirement
Engineering
O The gap between research and practice in
requirements engineering is huge.
O Empirical evidence about requirements
engineering practice is needed.
O Solution-based RE that usually includes
proofs and evidences to the applicability of
these solutions.
O Evaluation-based research that intends to
evaluate current practices and advances is
less common to be the subject of RE
researches.

27. Research Methods
O A large number of methods and
methodologies exists:
O Scientific method:
O Observing the world, propose a model or
theory, analyze and validate the model.
O Acquires knowledge about the world by
either provide assumptions based on
ontology and epistemology.
O Used when we try to understand software
process, product, people and the
environment.

28. Research Methods Cont.
O A large number of methods and
methodologies exists:
O Engineering method:
O Observing existing solutions, study them and
propose new better solutions that are
analyzed, modified and tested enough until no
further modification can be done on them.
O Used when the practice and implementation of
technologies introduce a number of research
problems that these methods try to simplify and
make it easily adapted by practitioners.
O Heuristics, patterns, visual formalisms.

29. Research Methods Cont.
O A large number of methods and
methodologies exists:
O Empirical methods:
O Aims to understand, explore and describe
natural, social or cognitive phenomena by
using evidence from observation or experience.
O Evolutionary in nature, new models are
proposed not necessarily based on existing
one.
O Suitable data collection techniques should be
used, Qualitative and quantitative measures
are used when collecting data needed for the
research.
O Empirical research requires proof its validity
and hence can be measurable and
interpretable.

30. Research Methods Cont.
O A large number of methods and methodologies
exists:
O Paradigm shift:
O Solutions that impose a radical change in new or
existing problem in technology.
O Evolutionary and rare and usually carried out when
existing technologies cannot make progress any more.
O Push PS: driven by the introduction of new technology
into community in which they have a great impact on
resolving problems. Ex. Global requirement
engineering.
O Pull PS: huge need for solution to a problem when
existing solution cannot resolve or even improve such
problems. Ex. Object oriented.

31. Research Methods Cont.
O A large number of methods and methodologies exists:
O Generalization:
O Successful organization and domain research methods
are generalized to be widely used and applied to different
areas of concern.
O Telecommunication notations using UML tools 2.0
O Evolutionary:
O Continuous improvements of existing technology.
O Existing requirements techniques, notations, approaches
will continue to improve and also can be supported be
new tools, patterns and methodologies.
O Basis for the paradigm shift methodology.

32. Empirical Research in RE
O Evaluation-based research in RE is
concerned with assessing the state of the
art in requirement engineering and
evaluate the practices developed in this
regard.
O Solution-based research that is concerned
with the technological advances in solving
requirement engineering problem.

33. Empirical Research in RE
Cont.
O “Evidence-Based Structuring and Evaluation of
Empirical Research in Requirements Engineering”
by Goeken and Patas
O Our knowledge of the appropriateness and desirability
of requirement engineering techniques are rare.
O Existing work is not unified, a lot of approaches and
techniques that have been developed based on
different principles and practices targeting the various
phases of requirement engineering and specific tasks
within them.
O This lack of empirical research leads to confusion as to
whether their results contribute to the solution of a
problem and whether it is suitable for practical use.

34. Empirical Research in RE
Cont.
O “Evidence-Based Structuring and Evaluation of
Empirical Research in Requirements
Engineering”
O Framework consisting of a set of
components, these components reflects whether
RE techniques evolved as a result of being
published in a book, evolved from standard
projects or being established as standards when
used for certification.
O “Technique, Result, Role, Activity, Purpose, Notati
on, Principle, Tool and Context”.

35. Empirical Research in RE
Cont.
O “Evidence-Based Structuring and Evaluation of Empirical
Research in Requirements Engineering”
O Techniques and activities have been studied the most since
that most.
O Notations have been studied less.
O Roles that are involved in assigning responsibilities are
rarely studied.
O Context and principles also needs more attention since they
are less considered in researches.
O Results as the research shows has a tight relation to both
techniques and activities since results are always evaluated
in experiments.
O Tools are frequently highlighted in research for their
important usage in activities and results.

36. Empirical Research in RE
Cont.
O Only about 10-15 % of the research work in
requirement engineering is an evaluation
based research that developed as a form of
practices and state of the art reports.
O These empirical researches help in highlighting
areas that need more attention and focus in
requirement engineering research.
O Help in the selection of the best solution based
techniques for various requirement engineering
problems.

37. Requirement Engineering
Emerging trends
O Globalization.
O Scale.
O Dynamic.
O Security.
O Requirement Reuse.
O COTS.

38. Globalization
O Team members located in separate geographical
workspace.
O Different culture and skills.
O The need to develop new roles and organizational
Models.
O The distributed requirements needs:
O Efforts to be gathered and managed.
O Communicating these requirements among various
distributed parties.
O Downstream activities such as design, implementation
and testing requires new RE methodologies to support
them.

39. Globalization Cont.
O Main challenges:
O Analysts and development teams are located in different
locations and geographical areas, requirements should
be communicated in an efficient way.
O Tools needed for eliciting, supporting and modeling
distributed requirements, managing and communicating
them, negotiating and quality should be developed.
O Conflicts can arise due to distance and poor collaboration
among various team members.
O Engineers may involve informally in change and
communicating this change across multiple sites may be
absent.
O New roles need to be created, assigning responsibilities
to right people could be of a great challenge.

40. Scale
O Large scale systems characterized by:
O Number of line of codes.
O Number of people employing the system
for different purposes.
O Amount of data
stored, accessed, manipulated, and
refined.
O Number of connections and
interdependencies among software
components.

41. Scale Cont.
O Major challenges:
O Scalability of huge number of requirements is not
supported by current tools, techniques and models
since they are difficult to be applied and do not support
the complexity, variability and uncertainty of
requirements.
O Existing requirement methodologies for requirement
specifications are costly and unlikely to be adapted to
large scale requirements.
O Large scale systems increases the reliance on the
environment, people, hardware and software are tightly
coupled that led to the emergent of new integrated
systems and techniques.
O Research regarding RE in large scale systems is not
satisfying, practical advices and guidelines are needed.
O Continuous requirement engineering and process
improvement, training and documentation, cultural
change is needed.

42. Dynamic
O RE is concerned with static elicitation, representation, and
analysis of requirements.
O Advances in technologies and systems that are highly
adaptive and dynamic with high rate of change.
O Four levels of requirement engineering needed to support
adaptive systems:
O Level one, (human) and related to activities associated
with elicitation and analysis of requirements.
O Level two, (system) when it is running and its ability to
adapt according to various inputs and behaviors.
O Level three, (human) and related to determining the
adaption elements of the adaptive system.
O Level four, (human) and associated with the general
understanding of adaptive systems and events.

43. Goal-based approaches
O Goal-based variability acquisition and analysis
was the center for several studies, identified a
set of types for roles associated with verb that
are used to identify the potential variability
related to stakeholders goals.
O Goal modeling:
O Models were developed to target various
requirement phases.
O New modeling techniques have been
developed to model separate goal-graphs.
O Several works has been carried out to relate
the goal-based models to the development of
dynamic adaptive systems

44. Aspect-oriented requirement
engineering
O Systematic means for
identification, modularization, representation, an
d composition of crosscutting concerns.
O Many researches have been carried out in
concern with requirement engineering for
Aspect-oriented development
O A set of models and use cases were developed
such as AOV-graphs and aspect-oriented uses
cases.

45. Requirement engineering for
agile methods
O Delivering fast products with high quality and
with a great involvement of stakeholders.
O Continuous involvement of stakeholders
requires a great attention for
eliciting, managing and communicating
requirements.
O Many existing and new tool ranging from UML
modeling tools, requirement negotiating
tools, instant messaging tools and project
management tools were developed to support
agile development practices.

46. Scenario-based requirement
engineering
O Scenarios and use cases are the most useful
tools used in requirement elicitation, validation
and documentation activities.
O Bridging the gap in requirement resulting from
model and goal oriented design.
O No agreed formal definition has been introduced.
O Scenario-based components should be looked at
as reusable components with consideration of
the context and domain in which it will be
deployed in.

47. Service-oriented requirement
engineering
O Understand and identify how requirements
of services can be developed.
O Little attention was given to related
requirement engineering activities.
O Researchers outlines that requirements
are affected by both service providers and
customers.
O Requirement engineering must be
capable to comply with all issues related
to changes applied to services.

48. Security
O Identifying potential security threats and
vulnerabilities, documenting them and suggest
countermeasures to protect against them and
recovery strategies.
O Security requirements change and evolve
overtime.
O The degree in which requirements involved in
determining and specifying security approaches
are not agreed upon also no general notion for
requirement security is determined yet.
O A number of tools and models were developed:
O Threat modeling, anti-models and trust
assumptions.

49. Requirement Reuse
O The reuse of existing and past requirements artifacts
for future usage is a common trend nowadays.
O Requirements should be developed in the most
abstract form.
O Most of the research in the area of reuse
requirements engineering was in the product lining
where group of products are treated as one
component and requirements can be derived from all
products for an individual product.
O For an artifact to be reused it should have a standard
pattern such as context, domain, problem, properties
and consequences.

50. COTS
O Software available in the market that can be reused
and integrated throughout the system.
O Not necessarily can accommodate all the needs of a
single customer.
O Huge modifications and changes made on them over
the time.
O No need to start with requirement gathering and then
selecting the appropriate COTS
O Requirements should be abstract to determine
market.
O Differences between these components will be
identified to choose the best product.
O More research should be taken in this regard for the
challenges that analyst faces when COTS are
selected and integrated in the system.

51. Conclusion
O Many of the research work and practical activities
evolved over time and some of them remain the
same due to changes and paradigm shifts in
technology and practice in software engineering
in general.
O Future Work:
O Centralized repository or index for RE research
work.
O The gap between researchers and practitioners
should be minimized.
O Knowledge Sharing through standardized channels
and repositories will be beneficiary.

52. Conclusion Cont.
O Future Work:
O More attention to evaluation-based and
empirical research.
O Requirement engineering activities and
methodologies should evolve too to comply
with these technological advances.