Requirement engineering evaluation


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • -Requirement Engineering is the process of identifying the goal behind a software system by identifying different stakeholders of the system, evaluate their needs with regard to the context to which the system will operate in, state the system services and constraints and finally communicate the resulted findings in form of requirements throughout the development life cycle of the software system.-Many organizations and practitioners realizes the importance of requirements engineering to the success or failure of software projects, and hence many researches have been carried out in this regard in order to shed the light on the significant role RE
  • If we developed our project based on incomplete, vague and even worse wrong requirements, then our project is 100% guaranteed to either fail, go over budget, and delivered late.
  • discovery of requirements that resides in the brain of stakeholders, business in use, flowcharts and business documents to be made after conducting surveys and meetings. This requires a thorough understanding of the system to be developed combined with careful extracting of requirements and business rules and constraints. Usually, in this stage the model to be used in later processes is developed.identify various sources of requirements and make sure that anyone affected by the system is involved in the elicitation process. understanding of the existing system in use, if exists, can be obtained using these techniquesrespect to a specific context or environment and even for a specific user. Also, integration with other environments and systems should be analyzed and integration requirements should be extracted.
  • requirements that help making the system more acceptable and attractive to stakeholdersto get users and stakeholders opinion regarding the system developed.
  • business process modeling, use case modeling, class or data modeling
  • In order for requirement analysis be able to reflect what the stakeholder want and not end up with unwanted or un desired systemLast: and therefore are able to identify these defects before they propagate throughout later stages.
  • State-oriented modeling, where the system is modeled around a set of states and transition between these states based on certain criteria. Activity-oriented modeling, where the system is modeled around a set of activities related by data or dependency relation. Heterogonous modeling employs various modeling techniques in one system representation. multiple view modeling uses a different set of models to represent different characteristics of the system. UML is an example of multiple view modeling.Structure modeling, where this model is concerned with the physical structure of the system and the characteristics of its components.
  • Mapping stakeholder requirements into design models usually needs several decisions that are not easily done by a tool or a method.
  • defects of un structured communication where requirement defects are delayed to later phases.
  • for managing large volume of requirements from various phases and different location are very important
  • as graphical animation that is used to validate the design model against the informal requirements simulation in which the modeling language is based on semantics for the simulator to be able to execute the system model Model checking in which state models are checked automatically and model satisfiabilty in which complex models for a system are defined within some other formal system, typically set theory
  • The aim of these methodologies is to understand current technologies in order to better benefit from them, evaluate and enhance these technologies to anticipate new changes and problems and the introduction of new methodologies that either better utilizes existing approaches or add new knowledge to the state of the art.
  • acquires knowledge about the world by either provide assumptions based on ontology (what we believe exists) and epistemology (how beliefs are acquired and how we justify them)
  • Paradigm shift innovations need time before being adapted since a level of maturity should be reached before being widely spread and used.
  • Techniques and activities have been studied the most since that most Requirement engineering approaches are process or product driven.Notations have been studied less although the important role they play in requirement elicitation, documentation and validation of the system.Principles like agility and iterative approaches are less being studied in researches.
  • Techniques and activities have been studied the most since that most Requirement engineering approaches are process or product driven.Notations have been studied less although the important role they play in requirement elicitation, documentation and validation of the system.Principles like agility and iterative approaches are less being studied in researches.
  • The rapid revolution of technology nowadays and its impact on the software industry is very tremendous. The need to adapt and live with these advances requires the software industry to evolve to meet these emerging needs. Existing trends may change or enhanced, new trends may develop and in a way or another will affect the software engineering process and hence have a direct and great impact on requirement engineering.
  • Globalization has quickly become a significant practice among various industries, the technological revolution in telecommunication and infrastructure make it easier for these industries to expand their work worldwide. Different needs of stakeholders had a great affect toward globalization of software developmentdecision of outsourcing specific tasks or in-house is crucial to the success of these projects.
  • Different cultures, timing and language should be taken into consideration. Poor defined requirements have a great impact on the final system as it will not match what stakeholders want and the cost of re-work will increase.
  • Many challenges are facing requirement engineering due to the large number of people and distributed teams, assigned roles and responsibilities and communication with stakeholders.
  • Many challenges are facing requirement engineering due to the large number of people and distributed teams, assigned roles and responsibilities and communication with stakeholders.
  • One of the remarkable works on this field was carried by Daniel berry, Betty Cheng and Ji Zhang Level three, (human) and related to the previous level by determining the adaption elements of the adaptive system.
  • Goal-based requirement engineering is not a new trend, in which basic goal based requirement engineering classified both functional and non-functional requirements into hard and soft goals respectivelyAdvances in this approach were concerned with various phases in the requirement process. These models can also uncover hidden requirements when they are integrated
  • New emerging trends in software engineering accommodated these advances and requirement engineering architecture design and design are affected with the topic of aspect-oriented developmentMany researches have been carried out in concern with requirement engineering for Aspect-oriented development
  • Requirements are continuously changed and evolve; it is important to be assured that no requirements are wastedThe need for prioritizing requirements so that the most valuable features are delivered first is very crucial
  • A scenario is a series of interactions between the user and the system whereas use cases are an abstraction that describes these scenariosScenario-based requirement engineering can be defined as an approach that represents requirements based on a real world example or storyNatural language, pictures, use cases, behavior and sequence diagrams
  • collection of services that communicate with each other delivering service or value to subscribers over the internet. On one hand, providers will try to design services that can suit multiple customers but their effort to standardize services will not suit all customers. On the other hand, customers are looking for services that accommodate their needs and based on service providers, they will have to change their processes to suit these services
  • increased reliance on technology and software in our everyday tasks and the increased deployment of technology in processing and storing customers’ data. Security threats and attacks are increasing and changing, the need to secure our systems is of a crucial importance.
  • Huge modifications and changes made on them over the time that are not in the hand of the customer and therefore the need by analyst to understand these components and changes made on them in order to determine the degree to which this component will still satisfy the needs of the client No need to start with requirement gathering and then selecting the appropriate COTS to meet these requirement since no product will satisfy all the needsrequirements should be abstract and capable of determining which market to search for the COTS without specifying internal details and quality measurements. Once a market is identified, differences between these components will be identified and used to choose the best product that will satisfy customer needs. More research should be taken in this regard for the challenges that analyst faces when COTS are selected and integrated in the system.
  • In this paper, we made an overview on requirement engineering evolution over the past ten years. Based on a roadmap by Nuseibeh and Easterbrook, we evaluate requirement engineering challenges, research directions and evolving trends. Requirement engineering field is very huge, the need to have some sort of centralized repository or index to the work in this field can help researchers utilize research time in evaluating work and find solutions.The gap between researchers and practitioners should be minimized. The need for collaborative efforts between them will help researchers obtain a better understanding of problems and challenges. Real data and cases provided by customers can help researchers in clarifying various data impacts on problems to be solved.A lot of solutions and models have been developed addressing specific context and scenarios, the need to share this knowledge through standardized channels and repositories will be beneficiary.
  • More attention should be given to evaluation-based and empirical research as evident throughout the paper. Technological advances and new trends are leading the change now. Requirement engineering activities and methodologies should evolve too to comply with these changes.In conclusion, requirement engineering is a huge field in which changes and advances affecting it are significant and make it susceptible to change all the time. We tried to sum up most of these changes in this paper but still a lot of work need to be done in this regard. The research opportunities in this field are divers and huge and more work can be done since the reliance on technology and software will remain for a quite long time.
  • Requirement engineering evaluation

    1. 1. RequirementEngineering Evaluation Presented by: Ishraq Fatafta
    2. 2. 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.
    3. 3. 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.
    4. 4. 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.
    5. 5. 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.
    6. 6. Requirement Engineering Roadmap Nuseibeh and EasterbrookO Requirement models Reuse.O Multidisciplinary training for requirement engineers.
    7. 7. 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.
    8. 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. 9. 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.
    10. 10. 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.
    11. 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. 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. 13. 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.
    14. 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. 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. 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. 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. 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. 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. 20. 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.
    21. 21. 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.
    22. 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. 23. 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.
    24. 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. 25. 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.
    26. 26. 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.
    27. 27. 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.
    28. 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. 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. 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. 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. 32. 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.
    33. 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. 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. 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. 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. 37. Requirement Engineering Emerging trendsO Globalization.O Scale.O Dynamic.O Security.O Requirement Reuse.O COTS.
    38. 38. 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.
    39. 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. 40. 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.
    41. 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. 42. 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.
    43. 43. 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
    44. 44. 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.
    45. 45. 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.
    46. 46. 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.
    47. 47. 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.
    48. 48. 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.
    49. 49. 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.
    50. 50. 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.
    51. 51. 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.
    52. 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.