Requirement Engineering: A Roadmap

1. Requirement Engineering: A Roadmap Bashar Nuseibeh, Steve Easterbrook 2000 آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

2. Introduction • The primary measure of success of a software system is the degree to which it satisfies its customers • This is difficult • Often, their goals and technical needs may not be explicit • may be difficult to articulate. • may be constrained by a variety of factors outside their control آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

3. Core RE Activities • Core Activities are: • Eliciting Requirements • Modeling and Analyzing Requirements • Communicating requirements • Agreeing Requirements • Evolving Requirements • practical reality dictates that these activities are • actually interleaved, • iterative, • and may span the entire software systems development life cycle. آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

4. RE Definition • Zave defines RE as: • Requirements engineering is the branch of software engineering concerned with the real world goals for, functions of, and constraints on software systems. It is also concerned with the relationship f theses factors to precise specifications of software behavior, and to their evolution overtime and across software families. آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

5. Requirements need Engineering • Definitions of engineering refer to the creation of cost effective solutions to practical problems by applying scientific knowledge • The use of the term engineering in RE serves as a reminder that RE is an important part of Engineering process آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

6. RE is a multi- disciplinary process • system engineering • to deliver some systems behavior to its stakeholders. • Computer science • provides the framework to assess the feasibility of requirements • logic • improve the rigour of the analysis performed and to make the reasoning steps explicit. • systems theory and practice • This includes work on characterizing systems identifying their boundaries and managing their development life cycle. آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

7. RE is a multi- disciplinary process (2) • Cognitive psychology • Anthropology • Sociology • RE needs to e sensitive to how people perceive and understand the world around them. how they interact and how the sociology of the workplace affects their actions. • Linguistics • Interpreting and understanding stakeholder terminology, concepts, viewpoints and goals آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

8. Core RE Activities • Eliciting Requirements • Modeling and Analyzing Requirements • Communicating requirements • Agreeing Requirements • Evolving Requirements آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

9. Eliciting Reuirements آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

10. RE Elicitation • “first” step in the RE process. • The term “elicitation” is preferred to “capture”, • Information gathered during requirements elicitation often has to be • interpreted, • analysed, • modelled and • validated آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

11. Requirements to Elicit • a system’s boundaries. • Identifying stakeholders • Goals which denote the objectives a system must meet • tasks users currently perform and those that they might want to perform آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

12. Elicitation Techniques • Common techniques are: • Existing documentation • Interviews • Questionnaires and surveys • Meetings • Ethnography • Prototypes • Techniques for knowledge acquisition for knowledge based systems • Laddering • Card Sorting • RAD/JAD • Depends on • Time • Resources • Kind of information that needs to be elicited آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

13. Elicitation Process • There are lot of methods which some guidance on their use is needed. • Methods provide one way of delivering such guidance. • Methods provide a systematic approach to combine different techniques and notations. • Each method itself has its strengths and weaknesses, and is normally best suited for use in particular application domains. • Some methods are: • Use cases and scenarios • Inquiry Cycle • CREWS • Requirements Engineer needs to select the appropriate technique or techniques most suitable for the elicitation process in hand آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

14. Modeling and Analyzing Requirements آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

15. Modeling • the construction of abstract descriptions that are amenable to interpretation • is a fundamental activity in RE • So much so that a number of RE textbooks focus almost entirely on modeling methods and their associated analysis techniques. • many modeling approaches are used as elicitation tools • where the modeling notation and partial models produced are used as drivers to prompt further information gathering. آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

16. Enterprise Modeling • Enterprise modelling is often used to capture the“purpose” of a system, by describing the behaviour of theorganisation in which that system will operate • Enterprise modelling andanalysis deals with • understanding an organisation’s structure, • the business rules that affect its operation, • thegoals, tasks and responsibilities of its constituentmembers, • and the data that it needs, generates andmanipulates. آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

17. Behavioral Modeling • modelling the dynamic or functional behaviourof stakeholders and systems (existing and required). • modelling methods • structured methods • object-oriented methods • formal methods. • These methods provide different levels of precision and are amenable to differentkinds of analysis. • Formal methods (for example, based onZ) can be difficult to construct, but are also amenable toautomated analysis • Soft methodsprovide “rich” representations that non-technicalstakeholders find appealing, but are often difficult tocheck automatically. آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

18. Domain Modeling • A significant proportion of the REprocess is about developing “domain descriptions” • A model of the domain provides an abstract description ofthe world in which an envisioned system will operate. • Benefits : • to understand the context of requirements • to identify opportunities for requirements reuse. • Domain-specific models have also been shown to be essential for building automated tools, • provide the ability to restrict analysis and reasoning, thereby making it tractable آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

19. Modeling Non- functional Req. • Quality, or non-functional, requirements are global attributes of a required system • NFRs, such as safety, security, reliability and usability • more difficult requirements to express in a measurable way, making them more difficult to analyse • However, it has emphasised the need to model NFRs and express them in a form that is measurable or testable. آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

20. Communicating Requirements آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

21. Communicating Req. • RE is also a process of facilitating effective communication of these requirements among different stakeholders. • The way in which requirements are documented plays an important role in ensuring that they can be read, analyzed, (re-) written, and validated. • with a variety of formal, semi-formal and informal languages, From Logic to Natural Language آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

22. Managing Documents • requirements management – • write requirements • in a form that is readable and traceable bymany. • achieve readability by documentation standards that provide guidelines for structuring requirements documents • Requirements traceability determines how easy requirements documentation is to read, navigate, query and change. آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

23. Managing Documents (2) • RT defines as “the ability to describe and follow the life of a requirement in both forwards and backwards direction (i.e., from its origins, through its development and specification, to its subsequent deployment and use, and through all periods of on-going refinement and iteration in any of these phases)”. • Providing RT in requirements documentation is a means of achieving integrity and completeness of that documentation, and has an important role to play in managing change آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

24. Agreeing Requirement آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

25. Agree on Requirements • validation is the process of establishing that the requirements (model) elicited provides an accurate account of stakeholder requirements. • Describing the requirements is an important step towards getting agreement and precondition for resolving conflicts between stakeholders آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

26. Techniques • Techniques such as inspection and formal analysis tend to concentrate on the coherence of the requirements Descriptions • are they consistent, • and are they structurally complete. • The formal method SCR illustrates this approach – the SCR tool provides automated checking that the formal model is syntactically consistent and complete. • Techniques such as prototyping, specification animation, and the use of scenarios are geared towards testing a correspondence with the real world problem • have we covered all the aspects of the problem that the stakeholders regard as important. آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

27. RE Validation is difficult • The first is philosophical and concerns the question of truth and what is knowable. • logical positivist approach:requirements describe some objective problem that exists in the world and that validation is the task of making sufficient empirical observations to check that this problem has been captured correctly. • Popper’s view was that scientific theories can never be proved correct through observation, but can only be refuted • that observation is not value-free, rather it is theory-driven. • Requirements engineers, methods and tools they use dominate the way that they see and describe problems. • Shifts requirements statements to a problem of convincing stakeholders that the chosen representation for requirements models is appropriate. آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

28. RE Validation is difficult (2) • second reason is social, and concerns the difficulty of reaching agreement among different stakeholders with conflicting goals. • Goal Hierarchy diagram models this • In the KAOS approach In the KAOS approach for example, these are modeled as obstacles: the modeling process includes an explicit analysis of potential obstacles to each goal • Negotiation is the solution • Model each stakeholder contribution separately not all in one model • Boehm introduces Win-Win solution, which each win condition for each stakeholder is defined. آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

29. Evolving Requirements آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

30. Change sources and effects • Source of Changes • Environments • Stakeholder Requirements • Effects • Documents should manage • Techniques and tools are need • Therefore: • recognizing change through continued requirements elicitation, re-evaluation of risk, and evaluation of the systems in their operational environment. آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

31. Software Changes • change in software descriptions • problem that needs to be fixed (typically an inconsistency of some kind), • or new requirements need to be added (as part of evolutionary development or to cope with changing stakeholder needs) آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

32. Integrated Requirements Engineering آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

33. Methods and Tools • method engineering plays an important role in designing the RE process to be deployed for a particular problem or domain. • Jacskon, for example, uses problem frames to structure • Another popular approach to RE is to support explicitly multiple perspectives or views of requirements • Tools provide capabilities for documenting requirements, managing their change, and integrating them in different ways depending on project needs • DOORS • Requisite Pro • Craddle آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

34. Conclusion • determining how the RE process should be conducted. • The novelty of many software applications, • the speed by which they need to be developed, • and the degree to which they are expected to change, آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

35. RE Ideas in 1990 decay • Modelling and analysis cannot be performed adequately in isolation from the organisational and social context in which any new system will have to operate. • emphasised the use of contextualised enquiry techniques,including ethnomethodology and participant observation • RE should not focus on specifying the functionality of a new system, but onmodelling indicative and optative properties of the environment • shift in emphasis away from modelling information flow and system state, and towards modellingstakeholders’ goals and scenarios • attempt to build consistent and complete requirements models is futile, • RE has to take seriouslythe need to analyse and resolve conflicting requirements • support stakeholder negotiation, • reason with models that contain inconsistencies آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap

36. Major Challenges for RE • Development of new techniques forformally modelling and analysing properties of the environment • Bridging the gap between requirements elicitation approachesbased on contextual enquiry and more formal specification and analysis techniques. • Richer models for capturing and analysing non-functional requirements. • Better understanding of the impact of software architecturalchoices on the prioritisation and evolution of requirements. • Reuse of requirements models. • Multidisciplinary training for requirements practitioners. آزمايشکاه سيستم های هوشمند (http://ce.aut.ac.ir/islab) Requirements Engineering : A Roadmap