"A requirements-driven framework bridging model-based strategic representations with software development practices" Nguyen Huynh Anh, Vu ABSTRACT Information Technology (IT) Governance is closely intertwined with Requirements Engineering. Aligning the latter with the former indeed allows proposing management rules for evaluating a software development's relevance in alignment with the organization's long-term strategy. Typically, the goal of governance of software engineering is to ensure that the results of a software development align with the strategic requirements of the organization in terms of business process support and technology adoption. Requirements-driven software development processes, such as (I-)Tropos, are using coarse-grained (i., high-level) and social-oriented models to drive the software life-cycle both in terms of project management and forward engineering techniques.
To support the governance of software developments realized with I-Tropos in terms of business and IT alignment as well as investment decision, this thesis proposes a process framework called GI-Tropos including a meta-model formalization of relevant process elements, the process description itself as well as its application onto two examples. CITE THIS VERSION Nguyen Huynh Anh, Vu. A requirements-driven framework bridging model-based strategic representations with software development practices. : Kolp, Manuel ; Wautelet, Yves http:// hdl.1/229358 Le dépôt institutionnel DIAL est destiné au dépôt DIAL is an institutional repository for the deposit et à la diffusion de documents scientifiques and dissemination of scientific documents from émanant des membres de l'UCLouvain.
Toute UCLouvain members. Usage of this document utilisation de ce document à des fins lucratives for profit or commercial purposes is stricly ou commerciales est strictement interdite. User agrees to respect copyright L'utilisateur s'engage à respecter les droits about this document, mainly text integrity and d'auteur liés à ce document, principalement le source mention. Full content of copyright policy droit à l'intégrité de l'œuvre et le droit à la is available at Copyright policy paternité.
La politique complète de copyright est disponible sur la page Copyright policy Available at: http://hdl.1/229358 [Downloaded 2023/11/02 at 02:06:34 ] A Requirements-Driven Framework Bridging Model-Based Strategic Representations with Software Development Practices Vu NGUYEN HUYNH ANH Doctoral Thesis 05 | 2020 Université catholique de Louvain LO U V A I N R E S E A R C H I NS T I T U T E I N MA NA GE ME NT A N D OR G A NI Z A T I O NS 1. Problem Identification & Motivation 2. Definition of the objectives for a solution 3. Communication Background Chapter 1 Chapter 2 Framework Specification & Validation Chapter 4 Chapter 3 (SEKE 2018 Chapter 5 Chapter 6 (ICSOFT 2017) & ICEIS 2018) Conclusion Chapter 7 1.
Meeting Stakeholder Needs 5. Covering Governance the From Enterprise Management End to End COBIT5 Principles 3. Enabling a Single Holistic Integrated Approach Framework Designed for: Designed by: Date: Version: The Business Model Canvas Key Partners Key Activities Value Propositions Customer Relationships Customer Segments Key Resources Channels Cost Structure Revenue Streams This work is licensed under the Creative Commons Attribution-Share Alike 3. To view a copy of this license, visit: http://creativecommons.org/licenses/by-sa/3.0/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.
g by: Strategyzer AG The makers of Business Model Gener ation and Strategyzer strategyzer.com PROJECT ENVIRONMENT Business Progress Case Change Organization PRINCE2 PROCESSES Risks Quality Plans PRINCE2 THEMES PRINCE2 PRINCIPLES Corporate / Programme Management Direction Level Project Board Directing a Project Project Manager Managing Starting Up Initiating Controlling Closing Stage a Project a Project a Stage a Project Boundaries Management Level Team Manager Managing Product Delivery Delivery Level Planning Planning Monitoring Enter Phase / and Exit Phase / Initiating Closing Start Project Controlling End Project Executing Stage Description Understand what are required for the system-to-be in terms of functionalities and other constraints. This phase can split up into several smaller activities, Requirement for example: feasibility study, requirement capture, requirement analysis, engineering requirement specification and requirement validation. It is also called as software specification. Adapt the software specification into the detailed software structures Design (architectural design, interface design, component design, data structure design, algorithm design) that can be directly implemented.
Transform the outcomes from the design phase into the executable releases. Implementation At the end of this phase, a complete version of the system is expected ready to be validated in the next phase. Compare the implemented system with the specification to realize if the built software can perform and give the correct outcomes as defined in the Validation specification document. At the end of this phase, the built system is ready to deliver and deploy.
Document new requirements if they arise during the system operation. They Evolution will be used for the next version of the system. Requirement Analysis Design Implementation Validation Evolution Design Acecptance Requirement Aceptance Tests Testing Design System Specification System Tests Testing Architectural Design Integration Design Testing Integration Tests Detailed Design Unit Design Unit Tests Testing Implementation System Analysis Maintenance Design Deployment Implementation Testing Assembly Archiving Frameworking Selection/ Catalog/ Adaptation Storage Domain Engineering Requirement Customer Communication Analysis Customer Validation Design Implemetation & Testing Analysis Design Code Test Increment-1 Analysis Design Code Test Increment-2 Analysis Design Code Test Increment-3 Planning Analysis Planning Analysis Planning Analysis Iteration 1 Iteration 2 Iteration 3 Testing Design Testing Design Testing Design Building Building Building PHAS E S SETTING BLUEPRINTING BUILDING SETUPING Organizational Organizational Organizational Organizational Organizational Organizational Organizational Modeling Modeling Modeling Modeling Modeling Modeling Modeling Requirements Requirements Requirements Requirements Requirements Requirements Requirements Engineering Engineering Engineering Engineering Engineering Engineering Engineering D Architectural Architectural Architectural Architectural Architectural Architectural Architectural Design Design Design Design Design Design Design I S Detailed Detailed Detailed Detailed Detailed Detailed Detailed Design Design Design Design Design Design Design C I Implementation Implementation Implementation Implementation Implementation Implementation Implementation P L I Test Test Test Test Test Test Test N E Deployment Deployment Deployment Deployment Deployment Deployment Deployment S Software Project Software Project Software Project Software Project Software Project Software Project Software Project Test Management Management Management Management Management Management Management ITERATION Major Major Major Major Milestone Milestone Milestone Milestone Phase Role Identifying and specifying most stakeholder’s requirements, have a first Setting approach of the environment scope, identify and evaluate threats and identify and evaluate quality factors. Producing a consistent architecture based on the identified requirements, Blueprinting eliminate riskiest features in priority and evaluate blueprints/prototypes to stakeholders.
Building and evaluating each aspect of a working application and validate Building developments; Setuping Finalising production, train users and document the system. Discipline Description The purpose of Organizational Modelling discipline is to understand the Organizational problem by studying the existing organizational setting based on Modelling understanding services that motivate system requirements. The purpose of Requirements Engineering discipline is to extend models Requirements created previously by including the system to-be, modelled as one or more Engineering actors. The purpose of Architectural Design discipline is to construct the system’s Architectural architecture specification with the purpose of fit functional and non- Design functional requirements of the system by forming the dependencies between the several identified sub-actors.
Detailed The purpose of Detailed Design discipline is to define the behaviour of each Design architectural component in further detail. The purpose of Implementation discipline aims to produce an executable Implementation release of the software system based on the detailed design specification. The purpose of Test discipline is to evaluate the quality of the executable Test release. The purpose of Deployment discipline is to test the software system in its Deployment final operational environment.
Structured Methods Agile Methods 1. Waterfall model Generic Project 2. Scrum Software Project 5 9. I-Tropos Use Case <<include>> Generalization <<extend>> Association Actor Login Create Account View History <<extend>> Client Administrator View Account Delete User <<include>> Close Account Element Description An actor is an active entity that carries out activities to achieve goals by Actor exercising its know-how. It is used to illustrate a person, an organization, or a system that is player of some activities. A resource is a physical or informational entity that the actor requires in Resource order to perform a task. It is a factor required in a relationship by an actor in order to achieve the desired outcome.
A task represents a functional activity that the actor performs. It is an Task actor’s achievement by an activity coming from the relationship that the actors have together. A goal is a state of affairs that the actor wants to achieve and that has clear- Goal cut criteria of achievement. A quality is an unclear objective of an actor relating to the relationship with another actor.
It is an attribute for which an actor desires some level of achievement. The level of achievement may be defined specifically or kept Quality vague. Qualities can lead to the ways of finding to achieve goals, and they also aid as criteria for evaluating alternative ways of achieving goals. Qualities illustrate non-functional requirements.
Therefore, they are implemented indirectly. The depender depends on the dependee for the availability of a physical or informational entity (Resource dependency), or carrying out an activity Dependency (Task dependency), or generating a certain state in the world (Goal dependency), or performing some task that achieves a quality (Quality dependency). Element Description Specifying a relationship between an end, and a means for achieving it. The "means" is stated in the form of a task and with the "end" is stated as a goal.
Means-end In the graphical notation, the arrowhead points from the means to the end. If there is more than one means to specify the different ways to obtain the end, an OR relation will be used. Corresponding to means-end links where the end is a quality enables Contribution expressing explicitly if the contribution is negative or positive (+,-). Expressing the decomposition of a task into different intentional elements: Task goal, task, resource and quality.
An AND relation will be used to illustrate a decomposition task is decomposed. Element Description Actors are used to model people, organizations, or systems that are players of some activities. Service Depender or Service Dependee, the main Actor stakeholders for the Service, are instances of Actor in the context of service modelling. They are involved in the dependency relationship.
Service is described as "an abstract set of functionalities that are provided by a specific actor" while "an actor can be an organizational entity… that uses Service or offers services" [21, 47]. Services need to fulfill goals and softgoals, achieve tasks, or furnish resources for some actors’ activities. A Quality Expectation (QE) is a constraint of particular service through an Quality agreement. A Threat describes an occurrence that can be negative for the Expectation proper fulfillment of a service.
A service fulfillment is aimed to the and Threats satisfaction of a QE or help lowering the probability of occurrence of the threat by a series of softgoals, goals, tasks, and resources at tactical level.* +cre a te s Risk 0.* Stage - level: {governance, management} 0.* fu lfills +o btains 1.* Knowledge Phase - life-cycle objective: String GI-Tropos Framework Setting Blueprinting Building Setuping Operation GI-Tropos Governance Process Strategic level Evaluate Strategic Direct Monitor Performance Sevice Model Decision Levels Transformation GI-Tropos Management Process Tactical level Strategic Dependency Model Proposals Refining Policies Operational level Strategic Rationale Plan Deploy Deliver Model Assess G O V E R N A Strategic Services Diagram N C Strategic E Level M A Tactical Level Strategic Dependency Diagram N A G E Strategic Rationale Diagram M Operational Level E N T Phase Goal Aligning software development-based services with strategic business goals; identifying and specifying most stakeholders’ requirements, have a Setting first approach of the environment scope, identify and evaluate threats and identify and evaluate quality factors. Producing a consistent architecture based on the identified software development-based IT services and their internal / operational behavior, Blueprinting eliminate riskiest features in priority and evaluate blueprints/prototypes to stakeholders. Implementing the software development-based services that are in the Building backlog of each iteration and validate them; they are at the end of each iteration ready to be put in production. Setuping Finalising production, delivering document, and training users.