AgendaO Introduction.O Requirement Engineering Overview.O Requirement Engineering activities.O Research in Requirement Engineering.O Requirement Engineering Emerging trends.O Conclusion and Future work.
IntroductionO 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.
Requirement Engineering Roadmap Nuseibeh and EasterbrookO 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.
Requirement Engineering Roadmap Nuseibeh and EasterbrookO 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.
Requirement Engineering Roadmap Nuseibeh and EasterbrookO Requirement models Reuse.O Multidisciplinary training for requirement engineers.
Requirement Engineering OverviewO 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.
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.
Requirement Engineering ActivitiesO 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.
RE Activity: ElicitationO 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.
RE Activity: Elicitation Cont.O Elicitation techniques: O Innovative techniques. O Brainstorming, workshops. O Feedback techniques. O Prototypes, Storyboard, visual and use models.
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.
RE Activity: Analysis and ModelingO 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.
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.
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.
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.
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.
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).
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.
RE Activity: CommunicationO 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.
RE Activity: ManagementO 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 themO Need to evaluate change, planning and managing their effects throughout the entire system.
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.
RE Activity: AgreeingO 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.
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
RE Activity: EvolvingO 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.
Research in Requirement EngineeringO 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.
Research MethodsO 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.
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.
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.
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.
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.
Empirical Research in REO 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.
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.
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”.
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.
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.
GlobalizationO 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.
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.
ScaleO 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.
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.
DynamicO 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.
Goal-based approachesO 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
Aspect-oriented requirement engineeringO 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 developmentO A set of models and use cases were developed such as AOV-graphs and aspect-oriented uses cases.
Requirement engineering for agile methodsO 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.
Scenario-based requirement engineeringO 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.
Service-oriented requirement engineeringO 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.
SecurityO 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.
Requirement ReuseO 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.
COTSO 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 COTSO 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.
ConclusionO 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.
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.