Requirements Modeling Framework OPM Requirements Modeling Framework Research Overview Dudi Amid – dudia@{tx, rafael.co.il} Instrcutors: Dr. Iris Reinhartz-Berger, Prof. Dov Dori

Requirements Engineering (RE) Requirements engineering is the process of discovering the purpose for which the software system was intended, by identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation (Nuseibeh, B., Easterbrook, S. Requirements Engineering: A Roadmap)

Requirements Modeling Requirements modeling is the process of constructing abstract description of system requirements that are amenable to interpretation. A requirement model captures as much of the real world semantics as possible. can be viewed as a means to bridge between the requirement analysis, design, and testing phases (Requirements Engineering@UTS - http://research.it.uts.edu.au/re/ )

Requirements Modeling Methods Scenario-based Eliciting information about the tasks users currently perform and those that they might want to perform Rich & Informal Implementations: UML use cases. Goal-oriented denote the objectives a system must meet. focuses the requirements engineer on the problem domain and the needs of the stakeholders. Hard to elicit Stakeholders have difficulties expressing them

Requirements Modeling with OPM OPM supports scenario-based modeling Treats object and processes equally important  Enables a balanced specification of system’s structure and behavior. Refinement\Abstraction mechanisms enable the drill-down of a scenario to any desired level of detail.

An OPM based Requirement Metamodel Structures the Requirements Engineering Process, thus: Improve the deliverables of the Requirements Engineering process. Enable the education of good Requirements Engineering techniques Reduce mistakes done by the Requirements Engineer. Combines concepts from Requirements engineering Domain analysis OPM

Domain Domain - is a set of applications that use a common jargon for describing the concepts and problems. The definition of domain can be extended to a set of models that use a common terminology.  Requirement engineering can be treated as a domain.

Domain Analysis Domain analysis identifies a domain and captures its ontology by: Identifying the basic elements of the domain Organizing an understanding of the relationships among these elements Representing this understanding in a useful way. Applying domain analysis methods on a domain create a Domain Model.

Domain Model Domain model consists of two sets: Domain Artifact set - contains the domain building blocks Domain Constraint set - contains the language constraints (OPM in our case) and the domain (RE in our case) constraints

An OPM based Requirement Metamodel Combines concepts from requirements engineering, domain analysis and OPM. Provides building blocks for defining functional requirements more accurately. Establishes a mechanism for enforcing constraints on the requirement modeling process

A little terminology… Scenario - is an interaction between the system and its users. Scenario is general in nature and is usually elaborated to courses. A scenario has a set of pre-conditions and post-conditions. Pre-condition - defines the required system state in order for a scenario or one of its courses to commence. Post-condition - defines the system state at the end of the scenario (or one of its courses) execution. A post-condition usually represents information needed to be sent to the system users.

More terminology… Course - is a fragment of a given scenario. It either starts the scenario or emerges from an insertion point within the scenario. It usually ends with a certain post-condition, but it might also end with an insertion point. In contrast to a scenario, which does not consist of other scenarios, a course can be decomposed into other courses or actions. Insertion point - is an object which signifies a decision point in real life. It controls the workflow of events by breaking a scenario/course into different courses.

Yet More Terminology…. Action - is the basic building block of the dynamic facet of the system. As such, an action is treated as an atomic operation (process) in the scope of the requirement analysis phase. During subsequent phases of the software engineering process (e.g. design and implementation), an action will be thoroughly investigated. In contrast to courses, actions can interact amongst themselves and even invoke each other.

Top level diagram of OPM-based requirements model A functional requirement can be modeled as a scenario or a course, depending on its complexity. The level of granularity is therefore controlled by the RE modeler and is determined by his/her perception of the complexity at hand. Figure 1 is the top level diagram of the OPM-based requirement metamodel. According to this diagram, a Scenario, which is a process in the OPM terminology, is triggered by a Human Trigger or a Non-Human Trigger, both of which are specializations of a Trigger. After being triggered, the Scenario is executed only if the Pre-Condition is fulfilled (i.e., the object Pre-Condition is in its fulfilled state). The end of the Scenario execution yields Post Condition objects. As indicated by the letter m at the upper left corner, each object/process can appear many times in each requirement model

Scenario in-zoomed Zooming into the Scenario process, Figure 2 depicts the internal structure and behavior of a Scenario. A Scenario zooms into Courses and Insertion Points. The execution of Course affects an Insertion Point by consuming it, yielding it, or both (i.e., consume one Insertion Point and yield another Insertion Point at the end of the executing). The end of the Course execution yields Post Condition objects.

Course in-zoomed Zooming into Course, Figure 3 depicts the internal structure and behavior of a Course. A Course zooms into Action processes and optionally other Course processes. An Action process affects an Action Result by consuming it, yielding it or both. An Action can invoke (i.e., start) another Action. The end of the Action or Course execution might yield Post Condition objects.

Domain Analysis revisited An example of a Domain Artifact building block is Trigger. A Trigger is modeled as an object, usually physical and external. Triggers are specialized into Human Triggers, i.e., human users of the system, also known in OPM terminology as agents, and Non-Human Triggers, e.g., other inanimate systems that communicate with the modeled system. An example for a domain-specific constraint is that a Trigger activates a Scenario by an event link (in case of a Non-Human Trigger) or an agent link (in case of a Human Trigger). When applying the requirement metamodel to a given system requirement model, all the scenarios which are missing a trigger can be identified. REMINDER - a domain model consists of two sets: (1) the Domain Artifact set, which contains the domain building blocks, and (2) the Domain Constraint set, which contains the language constraints (OPM in our case) and the domain (RE in our case) constraints.

A case study Electronic Auction and Sales system (EAS), is an online Web-based trading forum that holds auctions and sales. People can visit the home page of EAS, where they can read general information and formally register as users. It permits buyers to bid on or directly buy items sold by sellers over the Internet. Once registered, the same person can play the role of a buyer or a seller. A buyer can bid on items being auctioned, buy items at direct sales, and place sealed offers at decreasing-price sales. A seller auctions items or sells them directly.

The top level System Diagram (SD) of the EAS system Each process is classified as scenario, as noted in the upper left corner of each entity. Each scenario is specified along with its triggers, pre-conditions, and post-conditions. For example, a Buyer, who is a human trigger (an OPM agent), activates the Bidding scenario, whose pre-condition is an opened Auction (i.e., an auction whose state is "opened"), while its post-condition is the same Auction (which may be changed by the Bidding scenario, as the effect link indicates).

The Bidding scenario in-zoomed The Bidding scenario is in-zoomed in Figure 5, showing its three alternative courses[1]: Offer, Withdraw, and Review Seller History. Offer affects Auction, i.e. the Auction exists both before and after the Offer course activation, but its state might change. Withdraw gets opened Auctions and might change the auction's state. Review Seller History gets Seller Information as its input (pre-condition) and outputs History Sheet as its post-condition. Although more refined, Figure 5 preserves the abstract definition of Bidding defined in Figure 4. As indicated in [‎17], OPM defines precedence order of procedural links based on their abstraction level. Hence, if two entities in the same diagram are supposed to be connected by more than one procedural link (when a process is abstracted), the most abstract link prevails. [1] The vertical axis within an in-zoomed process in OPM defines the execution order: The sub-processes of a sequential process are depicted in the in-zoomed frame of the process stacked on top of each other with the earlier process on top of a later one, while alternative or parallel processes appear side-by-side.

The Log On scenario in-zoomed into the Log On scenario, showing its three sequential actions. First Receive LogOn Info is activated, resulting in an action result called LoggedOn. LoggedOn is a Boolean object which enables the activation of Show Home Page when it is true and of Show Access Denied Page when it is false

Requirements Framework The Bottom Line: (or if you remember one thing out of this lecture remember this!) Requirements Framework will augment OPM principle: One View To Rule Them All

OPM-based Metamodel of the Requirement Engineering Process