A Requirements Engineering Analysis Framework

A Requirements Engineering Analysis Framework This chapter describes a requirements engineering analysis framework which focuses on two aspects of requirements engineering: the product and the process. The framework provides the way to examine both aspects. For requirements engineering product, the framework provides the way to examine three dimensions of information models (the product of requirements engineering): (i) the subject of the model, (ii) the functiof the model, and (iii) the representation of the model.

For requirements engineering process, the framework provides the way to examine the specified way of working and/or the provided methods to carry out the process on every requirements engineering phase. This framework provides a basis for comparing different types of requirements engineering approaches and can further be used as a foundation in the development of a unified approach. Introduction This chapter describes a requirements engineering analysis framework which focuses on two aspects of requirements engineering: the product and the process. The framework provides the way to examine both aspects. For requirements engineering product, the framework provides the way to examine three dimensions of information models (the product of requirements engineering): (i) the subject of the model, (ii) the function of the model, and (iii) the representation of the model. For requirements engineering process, the framework provides the way to examine the specified ways of working and/or the provided methods to carry out the process on every requirements engineering phase.

This framework provides a basis for comparing different types of requirements engineering approaches and can further be used as a foundation in the development of a unified approach. A Holistic View on Requirements Engineering Requirements engineering, as defined in section resech2RequirementsEngineering , is the activities involving the finding out (discovery), analyzing, documenting, checking, and maintaining of a set of requirements . According to Wiegers, requirements engineering can be classified as: requirements development and requirements management . Requirements development involves any activities related to discovering, gathering, evaluating, and documenting the requirements. Requirements development can be divided into four activities, namely elicitation, analysis, specification, and verification and validation . Meanwhile, requirements management involves the activities of establishing and maintaining requirements of the project throughout development lifecycle. It includes maintain an agreement with the customer towards the requirements specifications . Requirements elicitation is the activity of identifying the needs and constraints of the various stakeholders for a software product or project and focuses on discovering user requirements . The aim of requirements elicitation is to understand the current condition of the system under consideration (which is trying to be improved) and also to find out the needs and constraints for the particular system.

The other aim is to understand the reasons to change/alter (improve) the running (current) system and ensure that they are addressed deliberately. The changes might be carried out to cope with the organizational/enterprise changes. They could also be taken to address the problem(s) found within the running (current) system. The reasons to change for coping with the organizational changes can be understood by performing strength-weakness-opportunity-threat (SWOT) analysis (identifying strength(s) and weakness(es) and examining opportunity(es) and threat(s)) on the running (current) system as a whole.

Meanwhile, the reasons to change for addressing the found problem(s) can be understood by identifying the problem(s) with their cause(s) on the problematic parts of the running (current) system . The processes of identifying problem(s) and their related cause(s) are carried out to each system components incrementally instead of being performed to the entire system as a whole as in SWOT analysis. Hence, the results of SWOT analysis apply to the entire system while the results of problem analysis only apply to the part(s) of the system where the problem is found. The identified strength(s), weakness(es), opportunity(es), threat(s), or problem(s) with their cause(s) can then be inferred to set the targets (goals) for change. Requirements elicitation requires information from various stakeholders since the knowledge about the system under consideration is spread out among them. Requirements analysis is the activity of elaborating and refining the requirements in order to ensure that they are understood by all stakeholders; and the process of scrutinizing them for errors, omissions, and other deficiencies . The aim of requirements analysis is to reach an agreement among various involved stakeholders on the requirements of the system under consideration. Requirements specification is the activity of specifying and documenting requirements in a structured, shareable, and manageable form . The aim of requirements specification is to map stakeholders’ needs onto operational system components (requirements specifications/models). A more comprehensive paradigm on requirements specification, both of system engineering and software engineering projects, goes further from the specification of functional requirements of individual software application to the organization’s/enterprise’s concerns and the context which describe the purpose of the system under consideration. Finally, requirements verification and validation is the activity of ensuring that the requirement statements are correct, demonstrate the desired quality characteristics, and will satisfy customer needs . The aim of requirements verification and validation is to ensure that the specified requirements conform to the original stakeholders’ needs and adhere to the organization/enterprise and the environmental constraints. An extensive description on the taxonomy of requirements domain can be found in . The Aim(s) of Requirements Engineering Phases In my perspective, requirements engineering should be able to deals with the management of environmental change Change of the environment where the system lives. . It handles the transformation of the system’s current condition (which need to be changed in some aspects) to a future (desired) condition that addresses the needs for change. Requirements engineering involves in the transformation of identified change needs (either derived from SWOT or problem analysis) to software requirements specification. In this perspective, the decision to develop software application(s) which will be implemented to the system under consideration is not something that is given.

Rather, that decision becomes part of the solution which addresses stakeholders’ concerns. Therefore, in general, requirements engineering has six purposes: begin item to understand the current condition of the system under consideration, item to understand the reasons for changing the current condition, item to set the targets (goals) for changes, item to understand the rationales on specifying a particular future (desired) condition, item to specify the future (desired) condition of the system under consideration, and item to ensure the conformance of the specified future (desired) condition against original stakeholders’ needs. end Most of the existing approaches provide support only for one requirements engineering purpose. For example, traditional approaches on requirements engineering provide assistance solely for the fulfillment of the fifth requirements engineering purpose, in which they only consider information regarding the mapping of stakeholders’ needs onto operational system components (requirements specifications/models). In other words, the approaches only capture and model information related to (and during) requirements specification phase. They tend to capture and model prescriptive (optative) Prescriptive (optative) information is information regarding the future condition of the system under consideration. and ignore descriptive (indicative) Descriptive (indicative) information is information regarding the current condition of the system under consideration. . emph The holistic approaches take different paradigm in which they belief that descriptive information could represent the environmental context that describe: the reasons for system change, the rationales of mapping stakeholders’ needs onto particular operational system components, and more importantly the purpose of the system under consideration. Therefore, information is captured and modeled throughout requirements engineering phases.

The resulted artefacts, particularly those produced during requirements elicitation and requirements analysis phase, would become valuable knowledge for the subsequent phases of system/software development (analysis, design, implementation, and testing). Hence, it is apparently important that information related to each requirements engineering phase to be captured and modeled. Most of the requirements engineering approaches which were developed to handle software engineering projects normally focus on individual software applications (as opposed to the more holistic views considering the entire organization/enterprise-wide aspects). In most cases, the approaches left the organization’s/enterprise’s concerns unaddressed. In general, the approaches limit their scope only to the aspects of individual software applications, disregarding broader aspects of organization’s/enterprise’s concerns. The approaches are suitable to handle small scale, individual software applications but not for organization/enterprise-scale systems. In the contrary, requirements engineering approaches which were originally developed to handle system engineering projects require a more comprehensive scope than those for software engineering projects. The approaches consider organization’s/enterprise’s concerns and the context that describe the purpose of the system under consideration as information which should be handled (eli d, captured, and modeled) in addition to the aspects of individual software applications. Hence, the approaches are deemed appropriate to deal with system engineering projects (such as the Business Process Reengineering (BPR) projects which require features that can handle information related to business objectives, plans, structures, processes and the associated supporting system(s). It is due to the fact that, when undertaking a system engineering project (such as the BPR), the development of a software application is only a part of the engineering efforts. The main objective is actually to change the organization/enterprise condition which is deemed as problematic (and hence need improvement) in which the development and implementation of individual software application for the system under consideration would improve the condition.

Therefore, information about the organization’s/enterprise’s concerns and the context that describes the purpose of the system under consideration should be considered when developing the associated software application. Based on the previous explanation, requirements engineering approaches for system engineering projects will obtain more benefits when adopting the holistic paradigm. The captured and modeled information produced during requirements elicitation and requirements analysis phase could represent the environmental context that describe the purpose of the system under consideration.

The holistic paradigm, nevertheless, can also be adopted by the requirements engineering approaches for software engineering projects. The adoption would also offer similar benefits in which the captured and modeled information regarding the environmental context could provide knowledge/insight for the subsequent stages of software development. The Analysis Framework Communication among various stakeholders has been reported as the major problem in requirements engineering problems . The problem emerges from the difficulties in sharing knowledge which is personal and subjective in nature whilst also spread among various involved stakeholders. The maps of stakeholders’ mental models (conceptual models) can be used to assist knowledge sharing process. Therefore, this paper proposes a requirements engineering analysis framework which focuses on the information models (the product of requirements engineering) as an implementation of stakeholders’ mental models. An analysis framework is developed as a basis to comprehend, compare, and possibly unify different types of requirements engineering approaches systematically.

The framework focuses on two aspects of requirements engineering: the product and the process. It provides the way to examine both aspects. For requirements engineering product, the framework provides the way to examine three dimensions of information models (the product of requirements).This thesis extends the conventional paradigm which beliefs that the product of requirements engineering is solely requirements specification. This thesis argues that information regarding the system under consideration and its development process which reflects the organization’s/enterprise’s concerns and the context that describes the purpose of the system under consideration are supposed to be eli d, captured and explicitly modeled. Therefore, within the context of this thesis, requirements specification becomes the part of the requirements engineering product along with other types of information models): (i) the subject of the model, (ii) the function of the model, and (iii) the representation of the model. For requirements engineering process, the framework provides the way to examine the specified ways of working and/or the provided methods to carry out the process on every requirements engineering phase. My framework actually adopts and modifies the framework proposed in which is originally developed for system engineering.

Mylopoulos’ framework focuses on requirements engineering product. It provides the way to examine four dimensions of information models (the product of requirements engineering): the usage, the subject, the representation, and the development. My framework adopts Mylopoulos’ framework in which it also prescribes the examination to some dimensions of information models. However, my framework modifies Mylopoulos’ framework in which it does not prescribe the examination to the development of information models. Instead, the examination to the development of information models is replaced with the examination to the requirements engineering process by reviewing the specified ways of working and/or the provided methods to carry out the process on every requirements engineering phase. Additionally, my framework also adopts and modifies the framework proposed in . Kavakli’s framework focuses on requirements engineering product. It is specifically constructed for dealing with goal-oriented approaches instead of requirements engineering approaches in general. My framework adopts Kavakli’s framework in which it uses similar methods (as in Kavakli’s framework) to examine information models. However, my framework modifies Kavakli’s framework in which it accommodates broader scope of requirements engineering approaches in addition to goal-oriented approaches. The Subject of the Model Each requirements engineering approach has different focus when capturing and modeling information.

Each approach concerns with particular subject matter(s) which, by each of the approaches mentioned in chapter are called as: viewpoint, concern, aspect, goal, scenario, object and theme. Perspective-oriented approaches concern with the concept of viewpoints ,concerns, and aspects’ when capturing and modeling information. A viewpoint is an encapsulation of partial information (knowledge) about a system from the perspective of a particular actor (stakeholder). A viewpoint focuses on information about the service or functional features of a system. A concern represents information about critical holistic requirements which apply to the system as a whole rather than to any specific sub-set of its services or the concept of concern in perspective-oriented approaches is different from the concept of concern in concern-oriented approaches, in which concerns are defined as any type of subject matters of interest which can range at various stages of software (system) development (analysis, design, implementation, etc. In concern-oriented approaches, the method to specify information may also be regarded as concern. Hence, the concept of concern in concern-oriented approaches has a broader scope than the concept of concern in perspective-oriented approaches. Hence, a concern focuses on information about organization-level non-functional features of a system. Therefore, the notion of concern in perspective oriented approaches is also different from the notion of concern in the CARE Framework in which the latter conveys any matter of interest in a software system which include functional and non-functional features. Some of the perspective-oriented approaches also focus on aspect when capturing and modeling information. An aspect is the modularization of crosscutting concerns and/or viewpoints. A few perspective-oriented approaches, however, treat viewpoints, concerns, and aspects uniformly with symmetric decomposition where all of them are handled in a similar way and uniformly called as concern. Goal-oriented approaches concern with the concept of goals when capturing and modeling information. A goal represents information on both functional and non-functional properties that should be provided by the proposed system. In some goal-oriented approaches, goals are classified according to a number of criteria. KAOS classifies goals based on their temporal behavior and hierarchical level.

Based on temporal behavior, KAOS classifies goals as achievement, cessation, maintenance, avoidance, and optimization. Achievement and cessation goals generate behaviors, meaning that the associated behaviors will be achieved or ceased sometime in the future.

Maintenance and avoidance goals restrict behaviors, meaning that the associated behaviors should always be satisfied or rejected in the future. Optimization goals compare two behaviors. Based on hierarchical level, goals are classified as system-level and private level goals. System-level goals are application-specific goals which must be achieved by the composite system. A composite system means software application(s) (automation) together with its environment . Private-level goals are agent-specific goals that might be achieved by the composite system.

Align with KAOS, GBRAM also classifies goals according to their temporal behavior. In GBRAM, goals are classified as achievement (objective) and maintenance (adverbial) goal. Similar as KAOS’ classification, achievement goals generate behaviors which will be achieved sometime in the future whilst maintenance goals restrict behaviors which should always be satisfied in the future. Cessation goals are the negative form of achievement goals whereas avoidance goals are the negative form of maintenance goals. Meanwhile, NFR Framework classifies goals according to their type of concern: hard and soft goals. Hard goals refer to functional goals whilst soft goals refer to non-functional goals. Scenario-based approaches concern with the concept of scenario when capturing and modeling information. A scenario is a sequence of actions which are performed to achieve one or more goals.

The captured information comprises sequences of actions (scenario) and events. Concern-oriented approaches concern with the concept of concern when capturing and modeling information. A concern is any matter of interest in a software system. The captured information comprises concerns and their relationships. Object-oriented approaches concern with the concept of object hen capturing and modeling information. An object is an entity that has particular behavior. The captured information comprises objects, their relationships, and their behavior. Linguistic analysis approaches are different from the other types of approaches in term of capturing and modeling information related to the development of software-intensive systems. They are heavily relied on the existing requirements documents instead of eliciting them directly from the actors (stakeholders). These approaches concern with a particular concept of subject matter when capturing and modeling information.

For example, Theme/Doc concerns with the concept of “theme”. A theme is a meaningful unit of cohesive functionality. The Function of the Model During requirements engineering, information regarding the system under consideration and its development process are supposed to be explicitly captured and modeled (represented) in a structured manner. Following the holistic paradigm in requirements engineering, information should be captured and modeled for each requirements engineering phase. The captured and modeled information should be able to support the fulfillment of six requirements engineering purposes. Hence, there should be at least five types of information models produced by requirements engineering process. Each of those models has the function to describe: (i) the current condition of the system under consideration, (ii) the targets (goals) for change (change requirements) The reasons of changing the running (current) system are indirectly described during the process of capturing and modeling the targets (goals) for change, (iii) the arguments used as the basis to select alternatives for specifying a particular future (desired) condition. The rationales on specifying a particular future (desired) condition are indirectly described by the arguments used as the basis to select alternatives (context which is used by the involved stakeholders to support their decision making (iv) the future (desired) condition of the system under consideration The mapping of stakeholders’ needs onto particular operational system components (requirements specifications/models) , and also (v) to describe the evaluation/assessment regarding the conformance of specified requirements to the original stakeholders’ needs and their adherence to the organizational/enterprise and environmental constraints.

The first three models represent the environmental context which describes the purpose of the system under consideration. The fourth model represents the requirements models which describe the relation between stakeholders’ needs with operational system components.

Meanwhile, the last model represents either information regarding the evaluation/assessment of the product or the process of requirements engineering. When the model represents information regarding the evaluation/assessment of requirements engineering process, it is orthogonal from the other type of information models since those other models are related to requirements engineering product. The last model, however, is beyond the scope of this thesis. As far as I am aware and able to determine, there is currently no approach which can completely capture and model five types of information regarding the current condition of the system under consideration, the targets (goals) for change, the arguments to select alternatives for future (desired) condition, the future (desired) condition of the system under consideration, and the evaluation/assessment parameters. Most approaches normally focus solely on information regarding the system under consideration (more specifically its future (desired) condition) while ignoring information related to the system’s development process (that provide the organization’s/enterprise’s concerns and the context which describe the purpose of the system under consideration). Current Condition Information models that represent the current condition of the system under consideration describe the knowledge regarding the running (current) system domain.

The knowledge is deemed important since it can be used as the basis for proposing a future (desired) condition of the system under consideration. Studies in the area of current condition modeling concentrate on the method to capture and represent domain knowledge and business process. There are currently two techniques which provide the way to elicit, capture, and model information regarding the current condition of the system under consideration: task-level analysis and system (enterprise)-level analysis technique. Task-level analysis technique is suitable to understand and describe human tasks. It is indeed has been widely practiced for Human-Computer Interface (HCI) design such as the task analysis technique used in GOMS . In the perspective of task-level analysis technique, a system is viewed as the composition of tasks performed by human which interact with computer. A task is a structured set of activities where actions. Actions are tasks with no problem solving or control structure. are performed in a particular sequence . Task-level analysis technique however focuses on describing routine human-computer interaction. Hence, it concerns on low level activities within a system which may suitable to analyze small scale but not enterprise/business-wide systems. Currently only one approach (which inadvertently is categorized as goal-oriented) applies task-level analysis technique to describe routine human-computer interaction . The approach applies a cognitive task analysis technique.

The technique decomposes tasks to simpler tasks in which eventually resulting a set of actions. An external task (a goal) is a state/condition that human/individual desires to achieve. Meanwhile, an internal task (a task) is the required activities to achieve the external task using a particular device (tool, instrument, agent, method, technique, skill, etc). System (enterprise)-level analysis technique is suitable to understand and describe enterprise/business-wide environment of the system under consideration. In the perspective of system (enterprise)-level analysis technique, a system is viewed as the cooperation among various enterprise actors (agents). An enterprise actor is entity that can carry out free action(s). An enterprise actor could have relationship with other actor(s). An enterprise actor might be a human/individual, a group of peoples with one role (workgroup/organization/institution), or a system which associated with the system under consideration. The ORDIT models a system as a set of cooperating humans/individuals by representing their activities, the utilized resources for those activities, and their functional and structural roles for those activities. Goals are not modeled explicitly in ORDIT. Instead, they are implicitly modeled as policies in the behavioral arrangement of activities with their participated humans/individuals and the responsibility of human/individual to others for some condition of relationships. The GBW approach models a system as the composition of a set of goals, actors, and resources. Actors act together with others to achieve their goals using available resources.

The approach focuses on actors and their goals instead of their activities and the related procedures. Unlike the ORDIT, goals are explicitly represented in the GBW approach. The explicit representation of goals, however, does not show the relation between goals with actors and the influence of goals to the cooperation between actors. The I/Tropos models a system as a collaboration between dependent actors. In the perspective of the I/Tropos, each actor has freedom of action in the social (inter-actors) environment. An actor does not strictly follow steps and procedures rather he/she acts with the intention to achieve his/her goals. However, actors depend on each other in order to attain their goals. They depend to other actors to provide intentional components (tasks to be performed, resources to be produced, goals to be achieved, and softgoals to be satisfied). The rationales of inter-actors relationships are described by actors’ internal intention models.

The models represent the actors’ internal tasks, goals, and softgoals. An actor’s internal intention can provides the reasons why such an actor has such a behavior and must cooperate with particular actor(s). The dependency collaboration among actors is represented by a strategic dependency model whereas the actors’ internal intentions are represented by rationale models. The GDC approach adopts the I/Tropos strategic dependency model to depict system’s business processes. The processes are performed to fulfill individual actors’ intentions.

Unlike the I/Tropos which only handles individual actors’ goals, the GDC approach captures and models organization/enterprise goals (global business objectives) in addition to individual actors goals. Organization goals are abstracted from the business processes by applying a reverse analysis strategy. Change Requirements Information models that represent the targets (goals) for change (change requirements) describe the requirements for changing the running (current) system. Those models also indirectly describe the reasons, background, and motivation of changing the running (current) system. The targets (goals) and the reasons for changing the running (current) system can be inferred from the identified strength(s) and weakness(es), the examined opportunity(es) and threat(s), or the identified problem(s) with their cause(s) which are found during requirements elicitation.

The aim of capturing and modeling the targets (goals) for change is to guarantee that the problems are identified and diagnosed properly and the concerns are addressed deliberately. Studies in the area of modeling the targets (goals) for change concentrate on problems and concerns identification and also organizational/enterprise planning, organization, and control. There are currently five approaches (all of which are categorized as goal-oriented) that provide the way to elicit, capture, and model information regarding the targets (goals) for change. Those approaches are: Information System work and Analysis of Changes (ISAC). Fuzzy to Formal (F3), Problem Situation (PS), Management by Objective (MBO), and GDC. There is also one non goal-oriented approach which provides the same feature: the Design Problem Solving (DPS) approach ISAC assists the identification of business goals and the problems which hinder the achievement of those goals. In ISAC, goal analysis is part of the business change analysis phase. Goals are captured and modeled in a goal model depicted using tree diagram where the root represents the business goal and the offsprings represent the subgoals. Goals and problems are related through a goal-problem matrix.

The matrix can shows the sets (clusters) of similar problems which relate to similar goals. Each cluster indicates the need for change the current condition in order to address the problems that hinder the fulfillment of the associated goals. These needs for change become the targets (goals) of changing the system and will be used as the criteria against which the change alternatives are evaluated/assessed. The drawback of ISAC is that its tree diagram does not differentiate the type of goals’ relationships and the arguments for those relationships. The F3 approach provides the way to capture, model, and reasoning about (understand the context) of organization/enterprise environment. F3 models comprise of objective model, concept model, activity and usage model, and actor model.

The objective model explicitly represents organization/enterprise goals. It describes the current goals of the organization/enterprise and their hindering problems. Using a problem analysis strategy, the problem(s), cause(s), weakness(es), opportunity(es), and threat(s) of the running (current) system are then identified. Those concerns are then inferred to acquire the targets (goals) for change. Each goal has a level of priority and a degree of criticality. In the F3 approach, each goal can be related to the stakeholder(s) who have a stake on the goal and all types of issues which influence the particular goal. Hence the F3 approach provides richer feature compared to the ISAC approach.

The objective model of the F3 approach is a good means for understanding the system’s current condition and identifying the future (desired) condition while the other models can assist the mapping of stakeholders’ needs onto particular operation system components. The DPS approach provides the way to define problem in a design problem solving process. In the perspective of DPS approach, problem definition is the critical aspect of problem solving. In order to assist in defining problems, the DPS approach defines a problem by simply stating the gap between current condition and future (desired) condition. This approach, however, only assist in defining problems and provide no assistance for problem solving.

The DPS approach has limitation in elaborating real world problems since they are very diverse to be fit into traditional representation such as decision tree. The PS approach provides better way to elaborate real world problems compared to the DPS approach. In the perspective of the PS approach, a problem is defined as the need to, or the failure to, achieve a goal. A goal articulates objective, desire, need, purpose, or value. In addition to goal and problem, the approach also considers other aspects involve in a problem situation, namely cause, effect, constraint, knowledge, and alternative actions. The modeling of relating aspects of problem situation hence provide better support for effective problem solving. The MBO is an approach that emphasizes goals for managing business. It provides the way for department manager to set the goals and organize their work to achieve enterprise (overall) business objectives. However, the MBO approach provides no method to identify and model goals. The GDC is an approach to describe intentional enterprise knowledge and a number of strategies to reason about the enterprise knowledge during organization change projects. The GDC approach explicitly captures and models the current goals of the enterprise, the targets (goals) for change, and information regarding the evaluation of the targets for change against the original stakeholders’ needs.

Using a reverse engineering strategy, the current goals are abstracted from the system’s current business processes. The SWOT analysis is then performed on the running (current) system to cope with the organizational change. The identified strength(s) and weakness(es) and the examined opportunity(es) and threat(s) are used to infer the targets for change. Using an impact analysis strategy, the targets for change are re-interpreted with respect to current condition and their impact on the running (current) system is analyzed. Eventually, the alternatives of the targets for change are evaluated based on a number of criteria, such as efficacy, efficiency, and effectiveness (3Es). However, the GDC approach does not provide a way to map stakeholders’ needs onto particular operational system components. Arguments for Selecting Alternatives Information models that represent the arguments used as the basis to select alternatives for specifying a particular future (desired) condition describe the context to be used by various involved stakeholders to reach an agreement.

Those models indirectly describe the rationales behind the mapping of stakeholders’ needs onto particular operational system components (requirements specifications/models). The models can later be used to trace the decision rationales, informing whether a particular future (desired) specification has or has not been selected deliberately from a set of alternatives. Studies in the area of rationale modeling concentrate on problem solving and decision making method. There are currently five approaches (all of which are categorized as goal-oriented) that provide the way to elicit, capture, and model information regarding the arguments used as the basis to select alternatives for specifying a particular future (desired) condition: SYBIL p lee91 , Representation and Maintenance of Process Knowledge (REMAP), The Non-Functional Requirements (NFR) Framework, Goal Frame, and GDC. SYBIL is a qualitative decision management system. It is an approach which provides the way to represent and handle the qualitative elements of decision making process. The considered elements are: the goals to be achieved, the alternatives of future (desired) condition, and the arguments to evaluate the alternatives with regards to the goals. The elements are articulated using a Decision Representation Language (DRL) and represented using a decision graph.

The decision graph explicitly captures and models information about the supporting and opposing arguments on selecting a set of alternatives in order to achieve a goal. A goal expresses a desired condition or property. A goal can be used to compare alternatives for solving a decision problem. An alternative expresses a considered option. A decision problem expresses a problem which needs to be decided. A goal could be decomposed into a number of subgoals. A number of alternatives propose the way to achieve a goal. Alternatives are assessed, with regard to the goal they want to achieve, by arguing about the claims (arguments) that the particular alternative is capable to achieve the goal. A claim can be argued using other claims which support or oppose it. It can also be argued by referring to its presupposed claims. DRL is an expressive language and has been used to represent design rationales. However, the scope of DRL is to support decision making instead of design rationale (generative approach), such as assisting a careful consideration before deciding on how to develop alternative designs. The REMAP is an approach to capture and model design rationales in a structured manner during requirements engineering. The REMAP approach uses goals to provide the context for the careful consideration of design decisions during requirements engineering. This approach adopts the Issue-Based Information System (IBIS) design rationale approach.

The IBIS approach provides the way to capture and model the process of resolving issues by capturing and modeling a number of aspects, namely issues, positions, and arguments. An identified issue may lead to a number of positions which should be taken to cope with it. An identified issue also forms a number of arguments which may support or oppose to the particular positions. The REMAP approach add some features of the IBIS approach by explicitly capture and model goals (requirements), assumptions, constraints, decisions, and design objects.

Goals provide the context for argumentation and drive the argumentation processes. An assumption provides the context for evaluating the arguments in a particular situation hence it can assists the evaluation of a position. The careful considerations that decide which positions are going to be selected produce a set of commitments. Those commitments become constraints on the design which should be fulfilled when developing a solution (design object). Hence, the constraints (commitments) produced by the issues resolving careful decision processes relate the careful decision processes to the development of design objects. The REMAP components are partly represented using a high-level Telos conceptual modeling language called as Concept-Base.

The Concept-Base interactively supports the instantiation, query, and modification of REMAP component instances hence allowing step by step process and application domain knowledge acquisition. The instances are represented in hypertext hence the knowledge base can be easily browsed. The use of Concept-Base supports the design decision in REMAP. The NFR is a framework which provides the way to represent non-functional requirements as interrelated goals. The NFR model comprises non-functional requirements goals, satisficing goals (design decisions), argumentation goals (the argument containing support or opposition to other goals), and goal relationships (the relations between goals). Goals are refined into other goals (subgoals) through refinement methods. The subgoals (and eventually the goals) can be evaluated to determine the degree to which a set of non-functional requirements are satisficed The word satisfice was coined by Herbert Simon . It means a good enough or adequate condition, instead of being optimal by a particular system design.

There are three types of refinement relationships in the NFR framework: AND/OR decomposition, satisficing relationship, and argument relationship. The NFR (parent) goals can be decomposed into a set of offspring goals using AND/OR decomposition method. The NFR goals can be refined into satisficing goals, resulting commitments to the particular operationalizations. The NFR goals can also be refined into argumentation goals, supplying rationales for supporting or opposing the particular satisficing goals.

The analysis of goals is supported by three methods: (i) domain dependent methods for refining goals into other goals, (ii) correlation rules for deducing potential relationships between goals, and (iii) a labeling procedure to determine the degree to which a non-functional requirement is satisficed by particular satisficing goals. The explicit representation of the arguments for satisficing goals makes the NFR framework provides support for decision making. However, similar as the DRL approach, the NFR framework provides no support for assisting a careful consideration before deciding on how to develop alternative satisficing goals. The Goal Frame is an approach which provides the way to record design rationales to be used for the decision during development process. This approach designs a system as a goal decomposition structure. Goals express requirements which should be satisfied, derived requirements produced by higher-level design decision, or constraints which should be considered.

Achieving a goal requires establishment of other goals (subgoals) which eventually forms a hierarchy or a network of goals. A goal network is developed by scrutinizing problems in the current description of system’s components working model to produce new goals (requirements) for the existing components. Goals are decomposed until each goal is supported by system components. In the goal frame approach, a goal is represented in a frame. A frame adopts the form of data structure as normally used in artificial intelligence. A frame contains a number of slots, each contains information regarding: the identifier of the frame, the identifier of the system, the identifier of directly related system (or the context), the goals to be achieved or explained, the list of alternative strategies, the rationale of each alternative strategy, the selected strategy, and the rationale for choosing the selected strategy.

The slot on the selected strategy contains reference to other frames. The references represent relations between frames which actually mean the relations between goals. Goal assertions are represented in first-order logic, eliminating ambiguity in goals representation. Hence, the reasoning of goal structure’s consistency and fulfillment can be performed automatically.

Goal assertions in first-order logic allow analysis of changes and their consequences using formal reasoning techniques. The explicit representation of rationales for alternative strategies makes the Goal Frame approach provides support for decision making. However, similar as the DRL approach, the Goal Frame approach provides no support for assisting a careful consideration before deciding on how to develop alternative strategies. The GDC approach provides the way to capture and model goal refinement’s arguments. Each refinement (either AND/OR decomposition or operationalization) can be associated with supporting or opposing arguments which provide information to reason about the particular AND/OR decomposition or operationalization. In other words, the arguments provides information to perform careful decisions in selecting operationalization goals from a set of alternatives by choosing one path from OR decomposition in a goal structure. The explicit representation of goal refinement’s arguments makes the GDC approach provides support for decision making.

However, similar as the DRL approach, the GDC approach provides no support for assisting a careful consideration before deciding on how to develop alternative path for OR decomposition. Future/Desired Condition Information models that represent the description of future (desired) condition of the system under consideration describe the mapping of stakeholders’ needs onto particular operational system components represent. The models are generally called as requirements. In most approaches, requirements models are the sole product of requirements engineering in which they also known as the requirements specification. Most of the requirements engineering approaches mentioned in this thesis (perspective-oriented, goal-oriented, scenario-based, concern-oriented, object-oriented, and linguistic analysis approaches) provide support for developing this type of information model. They supply the way to specify future (desired) condition of system under consideration. The exception is for some goal-oriented approaches which have been previously described, such as I/Tropos and GDC, in which they provide the way to develop the first three types of information model (modeling information related to the early requirements engineering phases) instead of the specification regarding the future (desired) system condition.

The goal oriented approaches which provide the way to develop information models related to the late requirements engineering phase are: KAOS, GBRAM, and NFR framework. There is a hybrid approach combining goal-oriented and scenario-based approach called as Goal-Scenario Coupling (GSC) which also provide the way to develop information models related to the late’ requirements engineering phase. Eventually, there is another goal-oriented approach that provides the way to develop information models related to the late requirements engineering phase, namely Goal-Question Metrics (GQM), but it supports requirements verification and validation instead of requirements specification. Most existing requirements engineering approaches provide support for requirements specification phase. It is reasonable since the main objective of requirements engineering is to produce requirements specification. Due to a large number of literature discussing approaches to support the development of requirements specification, hence, this type of information modeling will not be discussed further in this thesis. Evaluation Parameters Information models that represent the evaluation/assessment parameters describe the prescribed parameters The parameters are derived from the goals which are going to be achieved by the system under consideration. For checking the conformance of the future (desired) condition specification (requirements specifications/models) to the original stakeholders’ needs and their adherence to the organizational/enterprise and environmental constraints.

The model can be used as the basis for evaluating/assessing the requirements specification. There is currently one approach (which is inadvertently categorized as goal-oriented) that provides the way to evaluate/asses the conformance of the specified future (desired) condition against original stakeholders’ needs called as the GQM approach. The GQM approach uses goals to assist the identification of metrics using questions that refer to the associated goals.

The evaluation process is begun with defining (formulating) a measurement goal which is later refined and derived into a set of quantifiable questions representing the operational definition of the associated measurement goal. The GQM approach provides a template to define measurement goals and guidelines to refine and derive questions and metrics. In essence, a set of metrics are defined to measure system properties. A tool called GQ Maspect can be used to support the operation of GQM approach. Subject Matters Comparison Referring to the subjects of the models as discussed in section 2.A., the subject matters of each requirements engineering approaches can be classified based on the type of information they represent. The classification of the type of information is derived from the function of the model. In general, according to the function of the model, subject matters can be categorized as: system-related and process-related subject matter. The substance of a system-related subject matter is information regarding the product (system under consideration), either the current or the future (desired) condition.

Meanwhile, the substance of a process-related subject matter is information regarding the development process of the system under consideration, either the change requirements, the arguments for specifying the future (desired) condition, or the evaluation/assessment parameters. Based on the temporal classification, system-related subject matters can be classified as current and future (desired) subject matter. The substance of a current subject matter is information regarding the current condition of the running (current) system. Meanwhile, the substance of a future (desired) subject matter is information regarding the future (desired) condition of the system under consideration which is proposed by the actor(s) (stakeholder(s)). Most of the subject matters mentioned in this section are classified as system-related subject matter. In particular, most of the mentioned subject matters are future (desired) subject matters, representing information regarding the future (desired) condition of the system under consideration. Those subject matters, which are stated in the concepts of viewpoint, concern, aspect, scenario, object, and theme, are constructed to represent information related to the future (desired) system condition. An exception is the concept of goal where, in a number of goal-oriented approaches, is constructed and used to represent information related to system’s various states, ranging from the current condition of the system under consideration to the evaluation/assessment parameters. For example, the concept of goal in I/Tropos is constructed and used to represent elements, aspects, and issues related to the current condition of the running (current) system whereas the the concept of goal in KAOS and GBRAM is for the specification of future (desired) condition. In addition, the concept of goal in GQM is constructed and used to represent elements, aspects, and issues related to the evaluation/assessment parameters. The concepts of viewpoint, concern Both for perspective-oriented and concern-oriented approaches. , aspect, scenario, object, and theme are actually potential to represent the other types of information in addition to information regarding the future (desired) condition.

However, until recently, there is no requirements engineering approach which provide the method to represent various types of information using those mentioned concepts. Approaches summarizes the types of subject matters for each type of requirements engineering approaches begin table centering The Representation of the Model Information models can be expressed using various formats of representation. The notation which is used to express the models can be classified based on its formality. This framework, therefore, classifies notation as: formal, semi formal, and informal. Formal notation uses logical assertion to express models.

Models are defined using formal specification languages, for examples Telos language (which is used for I/Tropos, REMAP, and NFR), Theme/Doc (which is used by the Theme approach), and VIM specification language (which is used by VIM). Another example is KAOS specification language which is used to express KAOS goals in temporal logic. Aside from formal specification language, models can also be expressed using structured language. In a structured language, models can be expressed using templates that support formal manipulation of models hence allowing models indexing, retrieval, and checking for conflicts and similarities. Structured language is more flexible than formal specification in which the former has a format closer to natural language while the latter uses notation similar to mathematical assertion. The examples of structured language are those used by the GBRAM, GSC, and GQM approach. Formal notation has rigid, well defined semantics hence can provide good foundation to develop requirements engineering tools. Formal notation can provide unambiguous, precise, and consistent representation. Since formal notation has rigid semantic, hence it is less flexible in which it provide no support for flexible requirements elicitation (especially for eliciting conflicts and inconsistent requirements). Formal notation is also less simple, in which it is not easy to understand especially for novice users. Semi formal notation normally uses box and arrow diagram to express models.

Semi formal notation has a less rigid semantic compare to formal notation, hence it provides more flexible support for requirements elicitation. Using simpler notation than the formal notation, stakeholders can easily confirm their shared understanding and agree to the boundaries of requirements.

Even though the notation is simpler, it still provides a sufficient representation to be shared by various stakeholders. However, semi formal notation is more ambiguous and imprecise than formal notation in terms of its way to describe the meaning of its modeling elements and the way to define relationships between elements. The meaning of modeling elements is only described by the name assigned to the associated elements and the relationships between elements are loosely defined. Formal and semi formal notation can perhaps be complementary used to express information models since their advantages and drawbacks complement each other. Semi formal is the most utilized notation for expressing information models.

The perspective-oriented and scenario-based approaches mentioned in this thesis use semi formal notation to express models. Except for those which have been stated using formal notation, most of the goal-oriented and concern-oriented approaches use semi formal notation. Informal notation uses natural language or unstructured text to express models. Informal notation provides the most flexible support to elicit and represent requirements. However, informal notation is the most ambiguous, imprecise, and inconsistent among other types of notation. Informal notation is the least frequent used notation for expressing information models. It is reasonable due to the fact that conceptual modeling (either using formal or semi formal notation) provides better support for sharing knowledge (which is normally personal, subjective, and situation dependent) among various involved stakeholders. Conceptual modeling can provides better support since it has a common medium for modeling information hence assisting various stakeholders to obtain shared understanding about the problems from which they later can come up with an agreed set of requirements. As far as I know, there is only ISAC which uses informal notation to model the information. The Requirements Engineering Process This section describes an analysis framework which focuses on requirements engineering process.

The framework provides the way to examine the specified ways of working and the provided methods to carry out the process on every requirements engineering phase in each approach. The framework is applied to both requirements development and requirements management. Analysis to requirements development will be performed to the elicitation, analysis, and documentation/specification phases. Analysis to the elicitation phase examines the specified way to capture information from various actors (stakeholders). Analysis to the analysis phase examines the specified way to elaborate and refine abstract/general information to more specific requirements. The analysis also examines the way to identify and resolve conflicts which may occur during the elaboration and the refinement of abstract/general information to more specific requirements.

Eventually, analysis to the documentation/specification phase examines the specified way to document captured information. Further, analysis to requirements management examines the specified way to map and trace requirements. The analysis on requirements mapping examines the way to associate requirements to their subsequent artefacts of software development. Meanwhile, the analysis on requirements traceability examines the capability to link requirements with their sources and their subsequent artefacts of software development. It will looking at the capability to trace a particular artefact back to its origin (pre-traceability) and the capability to trace a requirement to its subsequent artefacts of software development (post-traceability). Most of the perspective-oriented approaches provide the way to identify and elicit comprehensive information from various actors (stakeholders) by introducing the concept of viewpoint. A viewpoint is a view of a particular actor. Perspective-oriented approaches assume that each actor have specific problem-related information which is incomplete and different from that of others, but equally valid. Information of a considered system will be gathered from various viewpoints.

However, perspective-based approaches only accommodate information related to a proposed product. There is no explicit example on the way to elicit and handle information related to the environmental context which describes the purpose and the context of developing the considered system.

For analysis phase, perspective-oriented approaches do not explicitly provide the way to elaborate and refine software development concerns to more specific requirements. Nevertheless, they provide the way to identify and resolve conflicts. Most of the perspective-oriented approaches use a concern projection matrix a matrix to project the influences of a concern to other concerns to identify any occurring conflicts between concerns. Conflicts are resolved based on the urgency of the conflicting concerns as represented by their weight in the concern projection matrix (a matrix to project the influences of a concern to other concerns). One of the approaches, i.e. VIM, uses a meta-integration framework with its set of viewpoint consistency rules to resolve inconsistencies (conflicts) between viewpoints.

For specification phase, perspective-oriented approaches provide the way to represent captured information (organizational concerns) using various templates called as containers. Perspective-oriented approaches provide three types of containers, namely concern, viewpoint, and aspect. Perspective-oriented approaches provide supports for requirements management. For requirements mapping, perspective-oriented approaches use containers (specifically concern templates) and guidelines to map requirements to the subsequent artefacts of software development. For requirements tracing, perspective-oriented approaches provide support for both pre and post traceability. They use containers as the means to trace back an artefact to its requirement sources. In general, most of the goal-oriented approaches do not provide explicit way to identify and elicit information from various stakeholders.

The I/Tropos and the GDC approach are the sole goal-oriented methods which explicitly describe the way to capture information from various actors (stakeholders). The GBRAM provides heuristics to elicit requirements from various sources of documents written in natural language. Hence, the GBRAM does not provide the way to elicit information directly from the actors (stakeholders) in participative manner such as by interview, workshop, or focus group discussion. For analysis phase, most of the goal-oriented approaches provide goal refinement method (either goal decomposition or goal hierarchy method) as the explicit ways to systematically elaborate and refine high-level functional goals and non-functional softgoals to derive more specific and/or operationalizable goals and requirements. Both organizational (system-level) and personal (private-level) goals are elaborated and refined using goal refinement method.

However, goal-oriented approaches are less supportive in elaborating and refining exceptions (e.g. when a particular goal cannot be achieved). A few goal-oriented approaches provide explicit way to resolve conflicts. For example, NFR Framework uses augmentation method as the way to add softgoals additional information such as the contribution weight. Conflicts between softgoals can then be resolved based on the additional information. Most of the goal-oriented approaches identify conflicts from the goal decomposition trees. Any identified conflicts are then resolved by evaluating each conflicting goals according to their importance (which are already elaborated and refined) as represented in their contribution weight in the goal decomposition trees.

However, conflicts are resolved from a single stakeholder’s perspective, hence do not consider the differences in the level of priority and criticality of a concern (goal and issue) from various stakeholders’ point of views. For specification phase, most of the goal-oriented approaches use goal refinement diagram (the goal decomposition tree or the goal hierarchy), those used during the analysis phase, as the frame for representing captured information (both organizational (system-level) and personal (private-level) goals). Goal-oriented approaches provide support for requirements managements.

For requirements mapping, most of the approaches use decomposition catalogues, operationalizations and contributions to map requirements to the subsequent artefacts of software development. For requirements tracing, goal-oriented approaches provide support for both pre and post traceability. They use goal decomposition trees to trace an artefact back to its origin. Until recently, there is no scenario-based approaches which provide explicit way to identify and elicit information from various stakeholders. Scenario-based approaches do not provide the way to elicit information directly from stakeholders in participative manner.

Hence, information is derived from various types of documents. For analysis phase, scenario-based approaches use scenario (which is intuitive for humans) to elaborate and refine high-level goals to detailed requirements. However, except for the Misuse Case approach, most of the scenario-based approaches are less supportive in elaborating and refining negative cases (e.g. when a particular scenario cannot be achieved). Scenario-based approaches also provide no way to identify and resolve conflicts. For specification phase, most of the scenario-based approaches use use case diagram to represent captured information (sequence of actions and events). Scenario-based approaches provide support for requirements management. For requirements mapping, scenario-based approaches use collaboration diagram and guideline to map requirements to the subsequent artefacts of software development.

For requirements tracing, scenario-based approaches only provide support for pre-traceability at user-level requirements. Concern-oriented approaches do not provide explicit way to identify and elicit information from various stakeholders. Concern-oriented approaches do not provide the way to elicit information directly from stakeholders in participative manner. Information are simply from various types of documents. For analysis phase, concern-oriented approaches do not explicitly provide the way to elaborate and refine general information to more specific requirements.

They also provide no support for conflicts identification and resolution. For specification phase, concern-oriented approaches use concern space (a space provided to express the structure of a concern) to represent captured information (concerns and their relationships). Concern-oriented approaches provide support for requirements management. For requirements mapping, concern-oriented approaches use concern relationships to record mapping decisions. For requirements tracing, concern-oriented approaches only provide support for post-traceability through concern relationships. There are no object-oriented approaches which provide explicit way to identify and elicit information from various stakeholders. The object-oriented approaches do not provide the way to elicit information directly from stakeholder in participative manner.

Information is derived from various types of documents. For analysis phase, object-oriented approaches do not provide explicit way to elaborate and refine general information to more specific requirements.

They also provide no explicit way to identify and resolve conflicts. For specification phase, object-oriented approaches use structural and behavior diagram to represent captured information (objects, their relationships, and their behavior). Object-oriented approaches provide support for requirements management. For requirements mapping, object-oriented approaches use translation rules (for translative approach) or design artefacts (for elaborative approach) to map requirements to the subsequent artefacts of software development. For requirements tracing, translative approach provide pre and post-traceability using translation rules but elaborative approach only provide post-traceability using design artefacts. Similar as scenario-based, concern-oriented, and object oriented approaches, linguistic analysis approaches provide no explicit way to identify and elicit information from various stakeholders.

Linguistic analysis approaches do not provide the way to elicit information directly from stakeholders in participative manner. Instead, they use various types of documents written in natural language as the source of information. For analysis phase, linguistic analysis phase do not explicitly provide the way to elaborate and refine general information to more specific requirements. The approaches also provide no way to identify and resolve conflicts. For specification phase, linguistic analysis approaches use action word diagram to represent captured information.

For example, the Theme/Doc approach uses theme view, action view, and clipped action view which are compiled from action words (verbs) and entities (nouns) to represent captured information (actions and entities). Linguistic analysis approaches provide support for requirements management. For requirements mapping, linguistic analysis approaches have a direct mapping of requirements to design artefacts. For requirements tracing, linguistic analysis approaches only provide support for post-traceability through the direct mapping of requirements to design artefacts. Related Work A number of requirements engineering analysis frameworks have been proposed, for examples in mylopoulos and kavakli. Mylopoulos’s framework focuses on requirements engineering product (information models). The framework provides the way to examine four dimensions of information models (the usage, the subject, the representation, and the development). The analysis to the usage view examines the usage of the models.

The analysis to the subject view examines the nature of the models. The analysis to the representation view examines the format of how the models are expressed. Finally, the analysis to the development view examines the way of developing the models. This framework was originally developed for system engineering. Mylopoulos’ framework has been adopted by Kavakli’s framework. Similar as Mylopoulos’ framework, Kavakli’ framework also focuses on requirements engineering product (information models). Kavakli’s framework provides the way to examine four dimensions of information models (usage, subject, representation, and development). The analysis to the usage view examines what the goal modeling achieved.

The analysis to the subject view examines the nature of the goals. The analysis to the representation view examines how the goals are expressed.

Finally, the analysis to the development view examines how the goal models are developed and used. If Mylopoulos’ framework is developed for system engineering, Kavakli’s framework is designed to accommodate either system engineering or software engineering projects. However, Kavakli’s framework was only constructed for goal-oriented approaches instead of requirements engineering approaches in general. Aside from those two mentioned frameworks, there are other works which were originally devoted to introduce the advantages of goal-oriented approaches for requirements engineering but implicitly propose a requirements engineering analysis framework at the same time. The work documented in compares various requirements engineering activities based on the use of goal analysis. It focuses on the usage dimension of information models. Meanwhile, the work documented in compares various goal oriented methodologies based on their goal modeling and specification approaches. It focuses on the representation and development dimension.

Nevertheless, those frameworks limit the analysis on specific dimension(s) hence does not comprehensively examine all dimensions of requirements engineering product/information models (function, subject, and representation) and requirements engineering process (the specified ways of working and/or the provided methods to carry out the process on every requirements engineering phase in each approach). Summary This chapter discusses a framework which is developed to comprehensively analyze the contribution of various requirements engineering approaches based on their product (information models) and process. The framework provides a comprehensive way to examine various dimensions of information models. The framework has a holistic view for examining information models in the sense that it considers a broad scope of knowledge state, spanning from the null state to the evaluation state. The framework also provides the way to examine the specified ways of working and/or the provided methods to carry out the process on every requirements engineering phase. The analysis to various types of requirements engineering approaches has shown that: (i) existing requirements engineering approaches have limited coverage on the support to capture and model information in which most of the approaches only provide support to capture and model information related to the future (desired) condition whilst only few of them which provide support to capture and model other types of information. (ii) among other, goal-oriented approaches capture and model information with the broadest scope of function and the most various ways of representation. Goal-oriented approaches also provides the ways of working and/or methods to carry out the process on every requirements engineering phase in which there is no other types of approaches provide as complete ways and/or techniques as them. (iii) there is a need to develop a requirements engineering method which provides support to capture and model various types of information (ranging from information regarding the current system condition to the evaluation parameters) in order to document the organization’s/enterprise’s concerns and the context which describe the purpose of the system under consideration. The analysis described in this chapter has provide a comprehensive picture of requirements engineering approaches. It shows that eliciting, capturing, and modeling information regarding the system under consideration and its development process (which represents the organization’s/enterprise’s concerns and the context that describes the purpose of the system under consideration) Complementing the requirements specification as the usual sole product of requirements engineering in conventional paradigm. is necessary, reflected by the flourishing studies in the area as describes in section.

However, there is no single approach with the capability to capture and model various types of information with comprehensive coverage. The analysis allows the identification of possible way to develop a method which provides support to comprehensively capture and model various types of information. The development of such method will be the topic of next chapter.

Cite this page