1 / 32

Requirements Engineering: A Roadmap

Requirements Engineering: A Roadmap. By: Abbas Rasoolzadegan. The Meaning of RE. The primary measure of success of a software system is the degree to which it meets the purpose for which it was intended

ava-herman
Télécharger la présentation

Requirements Engineering: A Roadmap

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Requirements Engineering: A Roadmap By: Abbas Rasoolzadegan Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  2. The Meaning of RE • The primary measure of success of a software system is the degree to which it meets the purpose for which it was intended • Software systems requirements engineering is the process of discovering the above purpose by: • Stakeholders • Identifying them • Identifying their needs • Documenting, amenable for • analysis • communication • subsequent implementation Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  3. RE difficulties Stakeholders may be numerous and distributed Their goals may vary and conflict, depending on their perspectives of the environment in which they work and the tasks they wish to accomplish Their goals may not be explicit or may be difficult to articulate satisfaction of these goals may be constrained by a variety of factors outside their control Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  4. Core RE activities eliciting requirements modeling and analyzing requirements communicating requirements agreeing requirements evolving requirements Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  5. Role of RE • Requirements engineering is • the branch of software engineering concerned with : • the real-world goals for, • functions of, • constraints on software systems. • concerned with the relationship of the above factors to • precise specifications of software behavior • their evolution over time and across software families Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  6. Formalism • Since software is a formal description, analysis of its behavior is amenable to formal reasoning • Logic providesa vehicle for performing such analysis to • improve the rigor of the analysis performed • make the reasoning steps explicit Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  7. Formalism (Cont.) RE must span the gap between the informal world of stakeholder needs, and the formal world of software behavior the key question over the use of formal methods is not whether to formalize, but when to formalize Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  8. Context of RE • The context in which RE takes place is usually a human activity system • RE needs to be sensitive to • how people perceive and understand the world around them • how they interact • how the sociology of the workplace affects their actions Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  9. Eliciting Requirements • most often regarded as the first step in the RE process • requirements are not out there to be collected simply by asking the right questions • Information gathered during requirements elicitation often has to be • interpreted • analyzed • modeled • validated Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  10. Eliciting Requirements (Cont.) • One of the most important goals of elicitation is to find out what problem needs to be solved, and hence identify system boundaries • Identifying and agreeing a system's boundaries affects identification of • Stakeholders • user classes • goals • tasks • scenarios • use cases Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  11. Elicitation Techniques • The choice of elicitation technique depends on • the time and resources available to the requirements engineer • the kind of information that needs to be elicited • Some classesof elicitation techniques • Traditional techniques • Group elicitation techniques • Prototyping • Model-driven techniques • Cognitive techniques • Contextual techniques Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  12. Traditional techniques • questionnaires • surveys • interviews • analysis of existing documentation • organizational charts • process models • standards • user or other manuals of existing systems Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  13. Group elicitation techniques • aim to foster stakeholder agreement • brainstorming • RAD/JAD workshops Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  14. Prototyping • used for elicitation • where there is a great deal of uncertainty about the requirements • where early feedback from stakeholders is needed Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  15. Model-driven techniques • provide a specific model of the type of information to be gathered • goal-based methods • scenario-based methods Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  16. Cognitive techniques • a series of techniques originally developed for knowledge acquisition for knowledge-based systems • protocol analysis • expert thinks aloud while performing a task, to provide the observer with insights into the cognitive processes used to perform the task • Laddering • using probes to elicit structure and content of stakeholder knowledge • cardsorting • asking stakeholders to sort cards in groups, each of which has name of some domain entity • repertorygrids • constructing an attribute matrix for entities Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  17. Contextual techniques • emerged in the 1990's as an alternative to both traditional and cognitive techniques • ethnographic techniques • ethnomethodogy and conversation analysis Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  18. Elicitation Process With a plethora of elicitation techniques available to the requirements engineer, some guidance on their use is needed Elicitation techniques should be selected regarding particular application domain Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  19. Modeling and Analyzing Requirements • Modeling • the construction of abstract descriptions that are amenable to interpretation - is a fundamental activity in RE • The key question to ask for any modeling approach is "what is it good for?“ • Categories of RE modeling • Enterprise Modeling • Data Modeling • Behavioral Modeling • Domain Modeling • Modeling Nonfunctional Requirements • Analyzing Requirements Models Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  20. Communicating Requirements RE is not only a process of discovering and specifying requirements, it is also a process of facilitating effective communication of these requirements among different stakeholders The focus of requirements documentation research is often on specification languages and notations the ability, not only to write requirements but also to do so in a form that is readable and traceable by many Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  21. Communicating Requirements (Cont.) • Requirements traceability (RT) • is another major factor that determines how easy • it is to read • Navigate • Query • Change requirements documentation • Gotel defines requirements traceability as • the ability to describe and follow the life of a requirement in both forwards and backwards direction Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  22. Agreeing Requirements • As requirements are elicited and modeled, maintaining agreement with all stakeholders can be a problem • especially where stakeholders have divergent goals • Requirements validation is difficult for two reasons • Philosophical • what is knowable? • Social • difficulty of reaching agreement among different stakeholders with conflicting goals Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  23. Agreeing Requirements (Cont.) • Jackson argues that descriptions used in RE should be refutable • those that are not refutable are vague, and should only be treated as rough sketches • win-win approach • win conditions for each stakeholder are identified • software process is managed and measured to ensure that all the win conditions are satisfied, through negotiation among the stakeholders Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  24. Evolving Requirements • Managing change is a fundamental activity in RE because • Successful software systems always evolve as the environment in which these systems operate changes and stakeholder requirements change • Changes to requirements documentation need to be managed. this involves providing techniques and tools for • configuration management • version control • exploiting traceability links to monitor and control the impact of changes in different parts of the documentation Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  25. Evolving Requirements (Cont.) • Traceability links does not support automated reasoning • The links carry little semantic information • ViewPoints framework address this problem • In ViewPoints relationships between chunks of a specification are expressed operationally • automated support for propagation of change becomes possible Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  26. Evolving Requirements (Cont.) • Managing changing requirements is not only a process of managing documentation, it is also a process of: • Recognizing change through continued requirements elicitation • Reevaluation of risk • evaluation of systems in their operational environment • Nowadays one of the key research issues in software engineering is identifying core requirements in order to develop architectures that are: • stable in the presence of change • flexible enough to be customized and adapted to changing requirements Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  27. RE during the last decade • The 1990's saw several important and radical shifts in the understanding of RE • By the early 1990's, RE had emerged as a field of study in its own right, as witnessed by the emergence of two series of international meetings • IEEE • Springer • By the late 1990's, the field had grown enough to support a large number of additional smaller meetings and workshops in various countries Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  28. RE during the last decade (Cont.) • Three radical new ideas • modeling and analysis cannot be performed adequately in isolation from the organizational and social context • The notion that RE should not focus on specifying the functionality of a new system, but instead should concentrate on modeling indicative and optative properties of the environment • RE has to take seriously the need to analyze and resolve conflicting requirements Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  29. Future Challenges • Development of new techniques for formally modeling and analyzing properties of the environment, as opposed to the behavior of the software • Bridging the gap between requirements elicitation approaches based on contextual enquiry and more formal specification and analysis techniques • Richer models for capturing and analyzing non-functional requirements Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  30. Future Challenges (Cont.) • Better understanding of the impact of software architectural choices on the prioritization and evolution of requirements • Reuse of requirements models • Multidisciplinary training for requirements practitioners Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  31. Reference • Bashar Nuseibeh , Steve Easterbrook, “Requirements engineering: a roadmap”, Proceedings of the Conference on The Future of Software Engineering, p.35-46, June 04-11, 2000, Limerick, Ireland Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  32. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

More Related