DAREED. Decision support Advisor for innovative business models and user engagement for smart Energy Efficient Districts

Size: px
Start display at page:

Download "DAREED. Decision support Advisor for innovative business models and user engagement for smart Energy Efficient Districts"

Transcription

1 DAREED Decision support Advisor for innovative business models and user engagement for smart Energy Efficient Districts Document Name DAREED REQUIREMENTS AND INTERFACES MANAGEMENT DEFINITION METHODOLOGY DEL. NR: D2.1 Submission date Classification: Work package related: Authors: Reviewers: PU WP2 Preslava Krahtova, KIT, Sankar Sivarajah, UBRUN Habin Lee, UBRUN, José Pablo Sánchez Gómez, ISOTROL

2 2 Contents 1 RATIONALE BEHIND THE DAREED METHODOLOGY FOR RM Literature overview Methodologies used in other FP7 projects Relevant standard for requirements management 10 2 DAREED METHODOLOGY Methodology definition DAREED process Principle for requirements specification 15 3 CONCLUSIONS 23 4 LITERATURE 24

3 3 LIST OF FIGURES FIG. 1: REQUIREMENTS MANAGEMENT PROCESS MODEL FOR SCENARIO-BASED APPROACH 8 FIG. 2: REQUIREMENTS SPECIFICATION STRUCTURAL TREE 12 FIG. 3: REQUIREMENT ENGINEERING METHODOLOGY 13 FIG. 4: DEFINITION OF A SCENARIO 16 FIG. 5: OVERVIEW OF DAREED COMPONENTS 17 FIG. 6: CREATION OF A NEW REQUIREMENT 18 FIG. 7: SUMMARY OF ALL REQUIREMENTS SET UP 22 FIG. 8: SUMMARY PAGE FOR EACH REQUIREMENT 22 FIG. 9: PARTNER OVERVIEW PAGE 25 LIST OF TABLES TABLE 1 COMPARISON BETWEEN RM METHODOLOGIES 10

4 4 Glossary This subsection provides the definitions of all the terminologies that are required to appropriately interpret the deliverable. This information may be provided by direct explanations or by references to one or more appendixes in the deliverable. Functional requirements: define the requested function and behaviour of a system. These requirements answer the question of which function the solution should be able to carry out. Non-functional requirements: are requirements regarding the quality in which the required functionality needs to be provided. These define the functional constraints such as look and feel, usability, performance, security, maintainability, legal, cultural issues. Thus, these answer the question how the functional requirements have to be implemented. User requirements: are statements made in a natural language, explaining what the system is expected to provide and the constraints under which it must operate. In the DAREED context, they represent the energy providers and policy makers of the project. Traceability: establishes links between various elements and ensures a coherent hierarchy and documentation. Ontology: Ontology formally represents knowledge as a set of concepts within a domain, and the relationships between those concepts. More theoretically expressed, ontology is a formal explicit specification of a shared conceptualization. Component: A component is an integral part of the DAREED solution, which is being developed or modified during the project in order to be integrated into the final Framework. A component is a piece of Software that realizes part of the DAREED concept.

5 5 Summary This deliverable identifies the methodology to be used for definition and review of all the requirements related to the DAREED platform information technology (IT) components. The main goal of this task is to provide a coherent and transparent process for the design phase but also draft the framework for integrating and validating the DAREED platform with verifiable conditions. Therefore, interfaces identification and correctness validation for the consistency of the requirements established is an important part of the methodology. The described methodology in this deliverable is considered as one of the backbones to the entire DAREED solution integration road map. The outline of the work presented is derived from both the IEEE 830 Standard for Software Requirements Specifications and analysis of the state of the art in the literature and in the frame of other FP7 projects requirements management methods. The final DAREED methodology for requirements management relies on the state of the art and is fully adapted to the concrete application field and necessities of the project. The DAREED methodology for requirements management has been realized through configuration of a semantic media wiki tool that has been fully adapted to the project concept for interfaces identification. The tool has been setup by KIT at M4 and will be used till the end of the development phase of the project by the relevant partners. Chapter 1 of this document derives an overall description of existing concepts in the literature and methodologies for requirements management used in similar FP7 projects. A brief description of the IEEE 830 Standard for Software Requirements Specifications is also provided as it was used as reference for the DAREED methodology. Chapter 2 of this deliverable focuses on the methodology for requirements specifications and management process established and gives an overview of the implemented semantic media wiki tool to support the technical management activities of the project.

6 6 1 Rationale behind the DAREED methodology for RM DAREED is an interdisciplinary research project with ambitious technological objectives involving several partners from different research and industrial fields. One of the main risks identified in such conditions (conclusion based on the consortium experience with other FP7 projects like KnoholEM, e-custom and Kno4Car) is to disregard the design phase and the interfaces specifications between partners and produce unnecessary complexity in the final modules and functionalities that do not entirely meet the project aims or good practices for technical management. Recognising this risk, the DAREED consortium made effort in the beginning of the project in order to mitigate it. This was achieved by developing a standard process for creation and monitoring of project requirements and specifications that meet the expectations of an interdisciplinary project and follow standardised software development process. Nevertheless, the implemented tool remains simple enough to be used directly by the project end-users who are not software engineers (in order to save time during the design phase) and capture their requirements in a structured and formalised way. The rationale to base the DAREED methodology for requirements specifications on state of the art methods for capturing different customers needs and maintaining synergy between different factors is the need to be able to provide in the end a holistic and common approach for all demo districts. Thus by taking into account that the project methodology for district modelling has to deal with complex and large data (i.e. three districts from three countries, completely different to each another with different strategies for development and energy savings) and monitor not only what is going on at district level (more general) but also to be able to monitor specific building s energy consumption (complex data requiring more detailed analysis). We believe that this is the first step for achieving our final objective to provide a replicable and sustainable solution for planning the energy performance at district level. 1.1 Literature overview Requirements management is often seen in the existing research as part of the engineering design related to capture customer needs in a more effective way [1]. As branch of the software engineering concerned with the real-world goals for, functions and constraints on software systems, it is also concerned with the relationship of these factors to precise specifications of software behaviour and its evolution over time [2]. Harold Halbleib

7 7 recognises that the process of managing requirements can determine the project success. It takes time and additional efforts, but provides solid foundation of every aspect of the project design, implementation, documentation, project management [3]. Capturing product specifications through both the end users or customers needs and designers views is a difficult process because these statements are often ambiguous and subjective and lack a formal and structural representation, which may lead to vague assumptions and implicit inference or even lead to the development of a wrong product [4]. Many methods based on artificial intelligence are applied for product specifications development such as fuzzy system and neural networks [5]. For years this problem has represented an intense research area in the field of software and information systems. However they can be applied for restricted cases and are more often to be used in large IT companies for software development. The standardised practices for requirements engineering in the context of a single software company working on an industrial project with specific client s needs does not entirely meet the same conditions as in the context of an interdisciplinary research project with more general objectives and more than one application fields. Methods based on artificial intelligence, could in that case produce more complexity for the project management than to provide a real added value for the need of formal representation of the requirements. One of the established practices, successfully applied in the context of interdisciplinary projects dealing with complex data, is the scenario-base requirements management process. Ze-Lin Liu et al. [4] divide it on elicitation phase, decomposition phase and formalization phase. The formal representation of this process model is presented on Fig. 1. The principle is that the initial statements of the customers go through an elicitation and decomposition phase that generates informal scenarios. On a later stage these are formalised and formal design specifications are generalized. This process although, not always explicitly described, is used in several European projects (e.g. Kno4Car, Skillpro, e-custom all FP7 projects for the benefit of the SME). However it lacks some of the basic recommendations from the IEEE Standard , namely the distribution of responsibilities and identification of interfaces that on a later stage of the implementation have to respond to the question - how does this software interact with people or other software?

8 8 Fig. 1: Requirements management process model for scenario-based approach (source: Ze-Lin Liu et al., 2012) Methodologies used in other FP7 projects Kno4Car, FP7 (Research for the benefit of the SME) The Kno4Car methodology is established in the context of an industry targeting project with interdisciplinary fields. Therefore, it is derived from the actual processes of the industrial partners which were described and analysed as current practices combined with the scenariobase requirements management process. Based upon the points of improvement, small use cases are derived that do not contain actual solution alternatives but show how the points may be avoided. Ultimately, the use cases serve as foundation for gathering the requirements in the Know4Car project. Furthermore, the use cases will be converged to be integrated into scenarios serving as validation scenario of the Know4Car project. The methodology distinguishes two types of requirements user requirements (that are transferred to system requirements on a later stage) and knowledge requirements that refer to the usage of data and include design knowledge to be captured [6]. User-intimate requirements hierarchy resolution framework - UI-REF methodology UI-REF is considered as methodology for requirements engineering and design, successfully adopted in several FP6 and FP7 projects (i.e. FASTMATCH - FP6, HYDRA - FP6, COMPANIONANBLE - FP7, D MEDIA SOUND AND VISION - FP7, ELLIOT - FP7, INTUITEL - FP7, MOSAIC - FP7,). The methodology is based on the work of Badii [7, 8] and it focuses on the prioritisation and hierarchy concept in order to optimise the requirements engineering process particularly to support user-intimate interactive systems codesign. UI-REF has been established to ensure that the most-deeply-valued needs of the

9 9 majority of stakeholders are elicited and ranked, and, the root rationale for requirements evolution is traceable and contextualised so as to help resolve stakeholder conflicts. Requirements prioritisation in UI-REF is fully resolved while a promotion path for lower priority requirements is delineated so as to ensure that as the requirements evolve, so will their resolution and prioritisation. The Jansson methodology The Jansson methodology is established in the context of a construction project and specific energy efficient norms [9]. The methodology is based on engineering design theories and its main objective is to enable traceability across disciplines. It defines the physical from the functional domains and the boundary conditions (constraints) to transfer the information. The definition of the requirements is mapped to the different constructional phases. For example requirements related to design parameters are analysed taking into account constraints like location and building system conditions. The following table presents a taxonomy highlighting the existing requirement management methodologies mentioned above and their limitations compared to the DARRED approach. Requirements Management Methodology Kno4Car methodology Principles Based on specific industrial practices and the scenariobased approach Scope of Application Automotive industry Limitations compared to DAREED scope The industrial practices used in the project are based on tools for requirements management done by and for large software companies (IBM Rationale and DOORS). These are very specific for the software development process and their usage in collaborative and interdisciplinary teams could lead to unnecessary complexity. An attempt to reduce complexity in the methodological approach has been done, but still remains very specific for the particular case. It also does not support identification of interfaces between the components of the system.

10 10 UI-REF Requirements management framework for construction Framework, Requirements Hierarchy Resolution, Usability Evaluation Functional Domain, Design Parameters Security, Robotics, Media Design Phase of energy efficient buildings It is focused on integrating user requirements with assessment and evaluation of these, which is linked to relatively big additional efforts for all partners, rather than structuring the information and interfaces identification. The methodology is very specific for the constructional projects. It provides traceability across disciplines, but still remains difficult to be implemented for Operational Phase of the buildings ( which is the case in DAREED) Table 1 Comparison between RM methodologies Relevant standard for requirements management The IEEE Standard (IEEE Std ) [10] highlights good practices and recommended approaches for specification of software requirements. It is not an organisational standard as it remains too general for that, but it is a general framework that can be tailored and adapted following particular organization or case. The basic issues identified are the following: Functionality: what the software is supposed to do? External interfaces: How does the software interact with people, the system, hardware, other hardware, and other software? Performance: What is the speed, availability, response time, recovery time of various software functions, etc.? Attributes: What are the portability, correctness, maintainability, security, etc. considerations? Design constraints imposed on an implementation. Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s) etc.? Specific requirements following the described good practice are related to cover functional, non-functional and interfaces related requirements and is considered as the most substantial part of the document because of the wide variability and organisational practice in the

11 11 industry. The main characteristic of a successful requirements management methodology is being able to meet the following parameters: Correctness Unambiguous Completeness Consistence Ranked for importance and stability Verifiable Modifiable Traceable The DAREED methodology relies on these main principles by following and capturing the suggested typology of the requirements in order to keep a synchronised and holistic approach for all different districts to be analysed in the frame of the project. 2 DAREED methodology The methodology definition identifies the type of groups, the content and content approval for each entry, and how requirements are connected to one another. It is described in the following sub-sections. 2.1 Methodology definition Following the established approaches in the literature, the first step in creating a requirement statement is to define the boundary around the system to be considered. A clear and consistent structure of the initial architecture shall determine whether it should belong to the requirements list or not [3]. The hierarchy is extremely important because a system requirement can express a wide granularity of software systems. The other positive aspect of grouping the requirements is that they become easier to locate and overlapping entries is also avoided. In doing so, the entire DAREED project will be split to sub-projects with different working groups. Responsible will be assigned for each one of the working groups. With the automated linking (ref. section 20(5) ) implemented through the semantic media wiki tool the hierarchy overview and export of groups of requirements is made considerably easier. One side describes the hierarchy of the system architecture components and the other describes the possible scenarios and use cases assigned to them. The requirements fit both the components (the name of each requirement is generated following the related component and

12 12 number of requirement for this component) and the applied use case. Fig. 2 represents the organisational logic of the creation of requirements. The main input comes from the end users needs and engineering and policy analysis done in parallel (WP1 and WP2) that is formalised in scenarios trough the Semantic Media Wiki from one side and set-up of initial software architecture from another (WP2 and WP3). The requirements are related to both IT main components, backbones of the DAREED software architecture, and the particular use cases, derived from the scenarios. Therefore each one of the finally approved requirements will be connected to a specific use case and related component. Thereby allowing better overview of the synergies and support the validation of the requirements, during the integration phase. Fig. 2 illustrates the tools derived from the DoW and can be renamed or changed during the project life cycle. Fig. 2: Requirements specification structural tree

13 DAREED process The main aim of the requirements management process is to structure information which is processed during the acquisition, derivation, analysis, co-ordination, updating, tracing, validating and verification of requirements over the entire project lifecycle. It should be a testable statement defining a process, performance or capacity related condition [3]. The methodology defines not only the process for definition of the requirements themself, but also parameters as correctness validation, prioritization and other processes where the final aim is to deliver a coherent, transparent and mature system with clear interfaces. With the finalisation of the requirements definition and review, validation criteria will be established that will serve as the main reference and input for future stages of the project. Fig. 3 defines the main steps in the requirements engineering methodology of the DAREED project. It is also stated at which stage of the methodology a deliverable is foreseen to be produced. The methodological approach is composed by the following steps: Fig. 3: Requirement Engineering Methodology 1) Scenarios description (D2.2): During this step, the necessity of the DAREED platform and what the expectations from the end-users will be analyzed. The output is a high level description of identified scenarios and desired implementations/improvements to serve as a base for identification of use cases. This will also give the initial description of the ICT architecture of the DAREED and the methodology for district modelling to be

14 14 identified on a later stage of WP1. After being created by its owner, each scenario is reviewed and approved by the technical committee of the project in order to be consistent. We use then the standard concept for scenario-based requirements management, described in the previous section, but introduce also roles and responsibilities during the creation for enable synergy and tractability on a later stage. 2) Identification of Use Cases (D2.2): The final use cases are verified again by the end users or the owners of each scenario. Output of this step is a formalized high-level (textual) description of use cases. o Mapping of the use cases with the project objectives. The output of this step is to analyze the technical status and envisioned improvements within the final DAREED system. This activity also aims to improve the project objectives in a way to make them more concrete and verifiable. o Initial Interfaces identification: The output of this inter-activity serves as input for the definition of the ICT platform architecture that will be presented at D2.3. The main interfaces and connections between all components will be identified and provide input for the creation of an appropriate structural tree and dependences of the entire system. 3) Requirements definition, approval and change (D2.4): requirements creation and approval activity are completed at every process or phase of the development and are understood as project management activities. During this step, requirements are created jointly by developers and end users and the main system design decisions are taken. General attributes of each requirement such as type, priority, risk level and description are given at this stage. Each of the created requirements shall be linked to an existing component from the DAREED architecture and one of the identified use cases, has author and assigned reviewers (at least two). This effort is needed at this stage of the project in order to keep coherence, correctness and tracing the requirements. Once a requirement is created and assigned for review, two reviewers (the WP leader and the organization responsible for the implementation of this functionality) should refine it or merge several requirements into a single one with the final aim to avoid unnecessary complexity and keep consistency. The change process is kept simple and represents a follow up of the current status of each requirement. After its review the requirement could be accepted, denied or a justifiable change should be assigned to the author.

15 15 During the identification of the particular system specifications (or functionalities in D2.4 and D2.3) a change could be assigned again. 2.3 Principle for requirements specification The following paragraph explains the scheme in which requirements are defined and thus delivers the basis for being able to understand the requirements in a common way. The schema is derived from the structural tree Fig. 2 and fully corresponds to the identified practices at the IEEE 830 Standard for software requirements specification. The technology used for managing this schema is a Semantic Media Wiki that is set-up and maintained by KIT at M3 of the project and configured for the purposes of the requirements management in the DAREED project. The methodology for deriving each requirement in the DAREED project is described within the following steps. (1) Scenarios description Fig. 4 illustrates a scenario defining the interest of a policy maker (one of the DAREED target groups) to allow for a transparent analysis of the current situation in a particular district and thus to support the process of decision making. Currently this scenario needs to be further refined and serves as an example for the methodology to be described in this deliverable. By creating a scenario, the user or its author states its name and main description as well as all additional information that the user considers important for this scenario. The structure identified is to provide a main description of the scenario, its main steps and some hints for the identification of requirements and functionalities later (if relevant). On the main page (as shown on Fig. 4), it can be observed (in the right corner) who is the author of this scenario and on a later stage (after its review and final approval) who has changed or approved the scenario with all relevant changes will be displayed also.

16 16 Fig. 4: Definition of a scenario (2) Architecture Components identification The output of the scenarios definition (that represent the end-users whishes) and the analysis of the political framework and plans for development (from WP1) serve as main contributions for the creation of a first approach of IT architecture and all relevant components to be developed in the frame of all work packages. The main IT tools that are identified in the DoW are presented in Fig. 5. The definition of each one of them is stated below: - Type of the component : o Framework component o External component - Relevant to which WP (from WP1 to WP6) - Leading organization (for the implementation of this component or tool) - Who are the main contributors?

17 17 Fig. 5: Overview of DAREED Components (3) Use Cases Identification The definition of use cases is strictly related to the existing scenarios (ref. Fig. 2) and therefore an automated check (whether such a scenario exist or not) has been configured. Again roles are identified as each use case has an author and a reviewer that is from the technical group. The aim is to improve the communication within the consortium during this initial phase of the project. (4) Requirements specification : Creation of a requirement The creation of a new requirement, shall take into account all components explained by current and additional factors such as risk, priority etc. that serve for the hierarchy and better formalization and structuring of the requirements (please ref. to Fig. 6). The following aspects need to be defined on that stage: - Name: Name of the requirement. The name is generated automatically once the requirement is referred to an existing Component from the structural tree presented in Fig. 2 and integrated to the semantic media wiki tool. A detailed name of the requirement is given by the user during the requirement creation process (for example:

18 18 Accessibility of the decision support layer) and will serve only for the purposes of the detailed description of the requirement. Fig. 6: Creation of a new requirement - Requirement Type ( choose from a top-down menu between): o Functional requirement: Defines the requested function and behavior of the DAREED platform. They answer the question of which functions the solution has to be able to carry out. This category will also define requirements related to interfaces specifications. o Non-functional requirement: Non-functional requirements are requirements regarding the quality in which the required functionality needs to be provided. These define the functional constraints such as look and feel, usability, performance, security, maintainability, legal, cultural issues. Thus, these answer the question how the functional requirements have to be implemented. o User Requirement: These requirements are special to the DAREED project and define functional, non-functional and knowledge requirements defined by the end-users and targeted groups. They are part of the functional and non-

19 19 functional requirements that will represent the know-how of the domain experts and end-users particular wishes for functionalities. - Description: In this section the user shall provide a full description of the requirement and its rationale using simple language. If the argumentation is vague and subjective, a change will be requested on a later stage of the process (i.e. the approval). - Related to Component: Here the user shall refer to an existing component from a top-down menu. If the technical groups and the end users consider some functionalities very important and they cannot be assigned to any of the existing component, there is the option to rework the architecture and create a new component and refer these requirements to it. However until that time, the system could not allow the review and final approval of this requirement. Again, if no component could be assigned to a requirement, then the author will be noticed that such a requirement cannot exist. This is also very important, because of the automated name generation (a name of each requirement is generated on the principle NameComponent_NumberRequirement ). As all components will be implemented from different working groups, the requirements list for each one of them has to be correct and full. - Priority: Priority of the requirement is set up as follows. This statement will be taken into account during the integration and validation phase. o Must Have means core functionality as well as discretionary functionality determined to be critical. o Should Have means non-core, discretionary functionality that should be deployed in the increment or sprint. o Nice to Have functionality that should be deployed but it is not mandatory. - Risk: in this field possible risks will be identified and prioritized. It is a very important stage because this statement will be taken into account during the validation of the project and also for proper analysis of the maturity of the system. The description of the justification or the rationale for the particular risk could also be provided in an optional field. The risks will be identified as follows: o High o Low

20 20 o None - Risk rationale: This category is optional and describes the rationale behind the chosen typology of risks. - Applied to use case: A list of all the Use cases defined are derived here. Following the established methodology and structure, the use cases are important input for each requirement. Therefore all owners of requirements should answer the question For which use case(s) is this requirement applicable? These can be changed or integrated during the project life cycle depending on the changes that can occur in the entire architecture. In this case the structure of the system tree (Fig. 2) needs also to be adapted. A completed list with all identified use cases will be presented at D Author: This field will display who has created the requirement and this means possess the role to change it if requested by the reviews. The user can choose from a top-down menu listing all organization s participating in the project. - Status: Reporting of the status of the requirement is one of the most important actions following the IEEE standard related to transparency of the work performed. Once the status has been changed, it has to be also reported so the requirement is considered as approved. The identified possible status is the following one: o Proposed o Approved o Rejected o Incorporated By default, during the creation of each requirement, the suggested status is proposed. The list will be considered as completed when all entrees have status approved. The author of each requirement has the responsibility to follow whether this requirements has been approved by the reviewers (automatically noticed for that) and has to be implemented or not. (5) Schema for Requirements Monitoring - Review assignment: the final stage during the creation of each requirement is to assign reviewers that have to approve it or comment on it. This is done by the author during the creation process. The common principle set-up by the consortium is that at least two reviewers are required to review the requirements in order to provide more

21 21 transparency and competences. The first one is the WP leader or the leader of the working group responsible for the implementation or incorporation (following the statuses) of this functionality and the second one is another domain expert( most often the Task Leader). Both these authors should analyze the suggested requirement and how correct it is related to the entire system logic. Again, organizations can be chosen from a top-down menu. It is important here to explain, that once an organization has been assigned for review as no matter first or second reviewer, the project leader from this partner organization is automatically notified that a review has been assigned to this organization. This appears also on their individual pages on the Semantic Wiki under Partners Overview (ref. ANNEX 1). - Approval procedure : Once the reviewers review the created requirement, they can choose to approve it, assign change needed, new assessment or reject it. This is relevant only for the review process and does not automatically lead to change of the requirement Status (as for this is his author responsible). However, the author is notified of the status of the review and if a change or rejection is assigned, a communication panel for discussion and re-assessment is open. There is a specific field Comment where the reviewers shall describe their arguments, and thus will improve the follow up of the history and evolution of the system development by providing documentation on the problems or on any inconsistency faced. Fig. 8 provides an example of the summary page of the first requirement related to the Component Knowledge Base to which all partners have access to obtain more information by clicking on a particular requirement. Purple denotes the given information related to the requirement self (for example Status, type, full name and related to which component and use case); in green is shown whether reviewers have been assigned and who they are, if not the fields will be red and notice that this should be done; in yellow is stated the status from the reviewers and their comments, if any. Fig. 8 represents a summary of all requirement set up in the Semantic Wiki. The most important information for all of them is presented here: name, related component, use case, author, status and reviews results. Respectively, depending on the particular request, they can be structured differently, following the related component or status etc.

22 22 Fig. 8: Summary Page for each requirement Fig. 7: Summary of all requirements set up

23 23 3 Conclusions The aim of this deliverable is to state the methodology (and configured tool) for requirements management to be used till the end of the project. Existing methods for RM from the literature and other projects have been analysed and arguments on whether they are suitable or not for the DAREED project have been provided. The presented methodology has been then inspired by these conclusions and also established good practices following the international Standard for software requirements specifications. Finally it represents an innovative concept for scenario based requirements management as part of the project technical management activities that has still not met in another project. The implemented semantic wiki tool has been also presented and the steps for the creation of these requirements have been explained. A real demo of the tool and first report on how it was used in the frame of the project is expected to be given during the first project review meeting at M13. Although this deliverable is public, access to the Semantic wiki tool is restricted to consortium partners only. The work performed for developing this methodology is part of WP2 and is restricted at this present timehowever, it will serve as a main backbone for the further integration scenario, interfaces identification and main input for D6.1 as it is considered as part of the technical management of the project.

24 24 4 Literature [1] C. C.-H. Jiao J, Customer requirement management in product development: a review of research issues., Cuncurrent Engineering: Research and Application, pp , [2] P. Zave, Classification of Research Efforts in Requirements engineering, ACM Computing Surveys, 29, pp , [3] H. Halbleib, "Requirements Management," Information Systems Management, pp. 8-14, [4] Z. Z. a. Y. C. Ze-Lin Liu, A scenario-based approach for requirements management in engineering design, Concurrent Engineering, [5] C. C.-H. a. Occena, A knowledge sorting process for a product design expert system, Expert Systems 16 (3), pp , [6] K. consortium, D1.3 Requirements on Extended Engineering Ontology, [7] A. Badii, User-intimate requirements hierarchy resolution framework (UI-REF), in AmI-08: Second European Conference on Ambient Intelligence, Nuremberg, Germany, [8] A. Badii, Online point-of-click web usability mining with PopEval-MB, WebEval-AB and the C-Assure methodology, American Conference on Information Systems ( AMCIS), August [9] G. S. J. O. T. Jansson, Requirements management for the design of energy efficient buildings, Journal of Information Technology in Construction (ITcon), pp. VOl.18, pg , [10] I.-S. S. Board, IEEE Recommended PRactice for Software Requirements Specifications, Software Engineering Standards Committee, [11] L. Bokhorst, Requirements Management method: Analysis Report, ITEA Information Technology for European Advancement, [12] B. A., Online point-of-click web usability mining with PopEval-MB, WebEval-AB and the C-Assure methodology, American Conference on Information Systems ( AMCIS), August 2000.

25 25 ANNEX 1 : Fig. 9: Partner overview page

Requirements Engineering

Requirements Engineering Requirements Engineering Professor Ray Welland Department of Computing Science University of Glasgow E-mail: ray@dcs.gla.ac.uk The Importance of Requirements Identifying (some) requirements is the starting

More information

Testing. CxOne Standard

Testing. CxOne Standard Testing CxOne Standard CxStand_Testing.doc November 3, 2002 Advancing the Art and Science of Commercial Software Engineering Contents 1 INTRODUCTION... 1 1.1 OVERVIEW... 1 1.2 GOALS... 1 1.3 BACKGROUND...

More information

version NDIA CMMI Conf 3.5 SE Tutorial RE - 1

version NDIA CMMI Conf 3.5 SE Tutorial RE - 1 Requirements Engineering SE Tutorial RE - 1 What Are Requirements? Customer s needs, expectations, and measures of effectiveness Items that are necessary, needed, or demanded Implicit or explicit criteria

More information

Framework for Measuring the Quality of Software Specification

Framework for Measuring the Quality of Software Specification Framework for Measuring the Quality of Software Specification E.Stephen, E.Mit Faculty of Computer Science and Information Technology, Universiti Malaysia Sarawak (UNIMAS), 94300 Kota Samarahan, Sarawak.

More information

Oi Requirements Communication in New Product Development

Oi Requirements Communication in New Product Development Steer Your Development! Goal-Oriented Oi Requirements Communication in New Product Development September 9, 2008 Samuel Fricker, Tony Gorschek, Martin Glinz Product Manager in Context: Simplified, Stylized

More information

Darshan Institute of Engineering & Technology for Diploma Studies Rajkot Unit-1

Darshan Institute of Engineering & Technology for Diploma Studies Rajkot Unit-1 Failure Rate Darshan Institute of Engineering & Technology for Diploma Studies Rajkot Unit-1 SOFTWARE (What is Software? Explain characteristics of Software. OR How the software product is differing than

More information

Requirements elicitation: Finding the Voice of the Customer

Requirements elicitation: Finding the Voice of the Customer Requirements elicitation: Finding the Voice of the Customer Establishing customer requirements for a software system Identify sources of user requirements on your project Identify different classes of

More information

Software Processes 1

Software Processes 1 Software Processes 1 Topics covered Software process models Process activities Coping with change 2 The software process A structured set of activities required to develop a software system. Many different

More information

What are Requirements? SENG1031 Software Engineering Workshop 1. My Notes. System Overview: The Big Picture

What are Requirements? SENG1031 Software Engineering Workshop 1. My Notes. System Overview: The Big Picture What are Requirements? SENG1031 Software Engineering Workshop 1 Requirements, An Overview Peter Ho CSE, UNSW 5 Aug 2010 Requirements are a collection of statements defined by the System Stakeholders. These

More information

Requirements Analysis and Design Definition. Chapter Study Group Learning Materials

Requirements Analysis and Design Definition. Chapter Study Group Learning Materials Requirements Analysis and Design Definition Chapter Study Group Learning Materials 2015, International Institute of Business Analysis (IIBA ). Permission is granted to IIBA Chapters to use and modify this

More information

Extended Enterprise Architecture Framework (E2AF) Essentials Guide. Structure of this Guide. Foreword

Extended Enterprise Architecture Framework (E2AF) Essentials Guide. Structure of this Guide. Foreword Extended Enterprise Architecture Framework (E2AF) Essentials Guide Based on the style elements of this guides, IFEAD has developed several methods, approaches to address specific EA topics. These Methods

More information

Verification and Validation

Verification and Validation System context Subject facet Usage facet IT system facet Development facet Validation Core activities Elicitation Negotiation Context of consideration Execution of RE activities Created requirements artefacts

More information

Defining Requirements

Defining Requirements Defining Requirements The scope of any project should represent the minimum amount of work needed to fulfil the customer s, or end user s requirements. Doing more work is wasteful; doing less means the

More information

Sistemi ICT per il Business Networking

Sistemi ICT per il Business Networking Corso di Laurea Specialistica Ingegneria Gestionale Sistemi ICT per il Business Networking Requirements Engineering Docente: Vito Morreale (vito.morreale@eng.it) 17 October 2006 1 UP Phases 1. Inception

More information

Lecture 1. In practice, most large systems are developed using a. A software process model is an abstract representation

Lecture 1. In practice, most large systems are developed using a. A software process model is an abstract representation Chapter 2 Software Processes Lecture 1 Software process descriptions When we describe and discuss processes, we usually talk about the activities in these processes such as specifying a data model, designing

More information

Developing a Business Case

Developing a Business Case Developing a Business Case Figures don t lie but liars figure. Attributed to Mark Twain and others The business case document is a formal, written argument intended to convince a decision maker to approve

More information

Digital Industries Apprenticeship: Occupational Brief. Software Development Technician. September 2016

Digital Industries Apprenticeship: Occupational Brief. Software Development Technician. September 2016 Digital Industries Apprenticeship: Occupational Brief Software Development Technician September 2016 1 Digital Industries Apprenticeships: Occupational Brief Level 3 Software Development Technician Apprenticeship

More information

EU CUSTOMS BUSINESS PROCESS MODELLING POLICY

EU CUSTOMS BUSINESS PROCESS MODELLING POLICY EUROPEAN COMMISSION MASP Revision 2014 v1.1 ANNEX 4 DIRECTORATE-GENERAL TAXATION AND CUSTOMS UNION Customs Policy, Legislation, Tariff Customs Processes and Project Management Brussels, 03.11.2014 TAXUD.a3

More information

Digital Industries Apprenticeship: Occupational Brief. Software Development Technician. September 2016

Digital Industries Apprenticeship: Occupational Brief. Software Development Technician. September 2016 Digital Industries Apprenticeship: Occupational Brief Software Development Technician September 2016 1 Digital Industries Apprenticeships: Occupational Brief Level 3 Software Development Technician Apprenticeship

More information

Passit4Sure.OG Questions. TOGAF 9 Combined Part 1 and Part 2

Passit4Sure.OG Questions. TOGAF 9 Combined Part 1 and Part 2 Passit4Sure.OG0-093.221Questions Number: OG0-093 Passing Score: 800 Time Limit: 120 min File Version: 7.1 TOGAF 9 Combined Part 1 and Part 2 One of the great thing about pass4sure is that is saves our

More information

8/30/2010. Lecture 1. Topics covered. Functional and non-functional requirements The software requirements document Requirements specification

8/30/2010. Lecture 1. Topics covered. Functional and non-functional requirements The software requirements document Requirements specification Topics covered Functional and non-functional requirements The software requirements document Chapter 4 Requirements Engineering Requirements specification Requirements engineering processes Lecture 1 Requirements

More information

Requirements Elicitation

Requirements Elicitation Requirements Elicitation Software Engineering I Lecture 4 14. November 2006 Bernd Bruegge Applied Software Engineering Technische Universitaet Muenchen 1 Outline Motivation Requirements elicitation challenges

More information

CMMI-DEV V1.3 CMMI for Development Version 1.3 Quick Reference Guide

CMMI-DEV V1.3 CMMI for Development Version 1.3 Quick Reference Guide processlabs CMMI-DEV V1.3 CMMI for Development Version 1.3 Quick Reference Guide CMMI-DEV V1.3 Process Areas Alphabetically by Process Area Acronym processlabs CAR - Causal Analysis and Resolution...

More information

V&V = the Verification and Validation of Deliverables

V&V = the Verification and Validation of Deliverables V&V = the Verification and Validation of Deliverables Verification and validation (V&V) are separated in the PMBOK Guide, but should be viewed as two integrated elements in the process of creating value

More information

Digital & Technology Solutions Specialist Integrated Degree Apprenticeship (Level 7)

Digital & Technology Solutions Specialist Integrated Degree Apprenticeship (Level 7) Digital & Technology Solutions Specialist Integrated Degree Apprenticeship (Level 7) Role Profile A Digital & Technology Solutions Specialist maintains digital and technology strategies through technology

More information

Developing a Business Case

Developing a Business Case Developing a Business Case Figures don t lie but liars figure. Attributed to Mark Twain and others The business case document is a formal, written argument intended to convince a decision maker to approve

More information

Space Product Assurance

Space Product Assurance EUROPEAN COOPERATION FOR SPACE STANDARDIZATION Space Product Assurance Software Product Assurance Secretariat ESA ESTEC Requirements & Standards Division Noordwijk, The Netherlands Published by: Price:

More information

CHAPTER 2 LITERATURE SURVEY

CHAPTER 2 LITERATURE SURVEY 10 CHAPTER 2 LITERATURE SURVEY This chapter provides the related work that has been done about the software performance requirements which includes the sub sections like requirements engineering, functional

More information

Deliverable: 1.4 Software Version Control and System Configuration Management Plan

Deliverable: 1.4 Software Version Control and System Configuration Management Plan Deliverable: 1.4 Software Version Control and System Configuration VoteCal Statewide Voter Registration System Project State of California, Secretary of State (SOS) Authors This document was prepared

More information

CMMI Version 1.2. Model Changes

CMMI Version 1.2. Model Changes Pittsburgh, PA 15213-3890 CMMI Version 1.2 Model Changes SM CMM Integration, IDEAL, and SCAMPI are service marks of Carnegie Mellon University. Capability Maturity Model, Capability Maturity Modeling,

More information

Introduction to Software Engineering

Introduction to Software Engineering Introduction to Software Engineering 2. Requirements Collection Mircea F. Lungu Based on a lecture by Oscar Nierstrasz. Roadmap > The Requirements Engineering Process > Functional and non-functional requirements

More information

Evolutionary Differences Between CMM for Software and the CMMI

Evolutionary Differences Between CMM for Software and the CMMI Evolutionary Differences Between CMM for Software and the CMMI Welcome WelKom Huan Yín Bienvenue Bienvenido Wilkommen????S???S??? Bienvenuto Tervetuloa Välkommen Witamy - 2 Adapting an An Integrated Approach

More information

CSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding Requirements Engineering

CSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding Requirements Engineering CSEB233: Fundamentals of Software Engineering Software Requirements Part 1 Understanding Requirements Engineering Objectives Discuss the concept of requirements and the types of requirements Explain what

More information

Introduction and Key Concepts Study Group Session 1

Introduction and Key Concepts Study Group Session 1 Introduction and Key Concepts Study Group Session 1 PDU: CH71563-04-2017 (3 hours) 2015, International Institute of Business Analysis (IIBA ). Permission is granted to IIBA Chapters to use and modify this

More information

CMMI-SVC V1.3 CMMI for Services Version 1.3 Quick Reference Guide

CMMI-SVC V1.3 CMMI for Services Version 1.3 Quick Reference Guide processlabs CMMI-SVC V1.3 CMMI for Services Version 1.3 Quick Reference Guide CMMI-SVC V1.3 Process Areas Alphabetically by Process Area Acronym processlabs CAM - Capacity and Availability Management...

More information

TOGAF 9.1 Phases E-H & Requirements Management

TOGAF 9.1 Phases E-H & Requirements Management TOGAF 9.1 Phases E-H & Requirements Management By: Samuel Mandebvu Sources: 1. Primary Slide Deck => Slide share @ https://www.slideshare.net/sammydhi01/learn-togaf-91-in-100-slides 1. D Truex s slide

More information

Computational Complexity and Agent-based Software Engineering

Computational Complexity and Agent-based Software Engineering Srinivasan Karthikeyan Course: 609-22 (AB-SENG) Page 1 Course Number: SENG 609.22 Session: Fall, 2003 Course Name: Agent-based Software Engineering Department: Electrical and Computer Engineering Document

More information

CMMI for Acquisition Quick Reference

CMMI for Acquisition Quick Reference AGREEMENT MANAGEMENT PROJECT MANAGEMENT (ML2) The purpose of Agreement Management (AM) is to ensure that the supplier and the acquirer perform according to the terms of the supplier agreement. SG 1 The

More information

0 Introduction Test strategy A Test Strategy for single high-level test B Combined testing strategy for high-level tests...

0 Introduction Test strategy A Test Strategy for single high-level test B Combined testing strategy for high-level tests... TPI Automotive Test Process Improvement Version: 1.01 Author: Sogeti Deutschland GmbH Datum: 29.12.2004 Sogeti Deutschland GmbH. Version 1.01 29.12.04-1 - 0 Introduction... 5 1 Test strategy...10 1.A Test

More information

Software Engineering (CSC 4350/6350) Rao Casturi

Software Engineering (CSC 4350/6350) Rao Casturi Software Engineering (CSC 4350/6350) Rao Casturi Recap UML Introduction Basic UML concepts 2 Basic Notations of UML Requirement Phase Analysis Phase Design Phase Object Design Phase 1. Use Case Diagrams

More information

Product Requirements. Requirements. Get it Right ASAP. Why Requirements are Difficult. Types of S/W Requirements. Levels of S/W Requirements

Product Requirements. Requirements. Get it Right ASAP. Why Requirements are Difficult. Types of S/W Requirements. Levels of S/W Requirements Requirements Overview importance of getting right difficulty of getting right types and levels of characteristics of good the Requirements Development Process inception gathering, classification evaluation

More information

Initial Report on Guidelines for Systems Engineering for SoS. Document Number: D21.3. Date: September Public Document

Initial Report on Guidelines for Systems Engineering for SoS. Document Number: D21.3. Date: September Public Document Project: COMPASS Grant Agreement: 287829 Comprehensive Modelling for Advanced Systems of Systems Initial Report on Guidelines for Systems Engineering for SoS Document Number: D2.3 Date: September 203 Public

More information

Requirement Engineering. L3 The requirement study. Change is constant. Communication problem? People are hard to understand!

Requirement Engineering. L3 The requirement study. Change is constant. Communication problem? People are hard to understand! Requirement Engineering L3 The requirement study Fang Chen Requirement are ubiquitous part of our lives Understand the requirement through communication Requirement Creation Communication problem? People

More information

What are requirements? Basics of Requirement Engineering. Definition of a Stakeholder. Stated Vs. Real Requirements. Stated Vs.

What are requirements? Basics of Requirement Engineering. Definition of a Stakeholder. Stated Vs. Real Requirements. Stated Vs. What are requirements? Basics of Requirement Engineering Muzaffar Iqbal Farooqi A requirement is a necessary attribute in a system, a statement that identifies a capability, characteristic, or quality

More information

Interoperability of business registers in the European Statistical System: the Eurostat VIP.ESBRs project

Interoperability of business registers in the European Statistical System: the Eurostat VIP.ESBRs project Interoperability of business registers in the European Statistical System: the Eurostat VIP.ESBRs project Amerigo LIOTTI - EUROSTAT Introduction Eurostat started in 2009 a reflection on the production

More information

Quality Assurance Plan D9.1.1

Quality Assurance Plan D9.1.1 Quality Assurance Plan D9.1.1 Deliverable Number: D9.1.1 Contractual Date of Delivery: month 3 Actual Date of Delivery: 27/07/2001 Title of Deliverable: Quality Assurance Plan Work-Package contributing

More information

Introduction to Software Engineering

Introduction to Software Engineering CHAPTER 1 Introduction to Software Engineering Structure 1.1 Introduction Objectives 1.2 Basics of Software Engineering 1.3 Principles of Software Engineering 1.4 Software Characteristics 1.5 Software

More information

Engineering. CMMI for Development V.1.2 Module 3. M03/Engineering/v1.2

Engineering. CMMI for Development V.1.2 Module 3. M03/Engineering/v1.2 Engineering CMMI for Development V.1.2 Module 3 M03/Engineering/v1.2 Agenda Global scope RD Development REQM Management TS Technical Solution PI Product Integration VER Verification VAL Validation SE Process

More information

This document describes the overall software development process of microcontroller software during all phases of the Company Name product life cycle.

This document describes the overall software development process of microcontroller software during all phases of the Company Name product life cycle. Maturity Process Owner Check Release Description Valid Name / Department Name / Department Name / Department Detailed procedure for software development Title: Software Development Procedure Purpose: This

More information

Requirements Knowledge Model. Business. Event. Business. responding. Business. Use Case 1.. Business tracing * * * * Requirement

Requirements Knowledge Model. Business. Event. Business. responding. Business. Use Case 1.. Business tracing * * * * Requirement Requirements Knowledge Model This model provides a language for communicating the knowledge that you discover during requirements-related activities. We present it here as a guide to the information you

More information

Architecture Development Methodology for Business Applications

Architecture Development Methodology for Business Applications 4/7/2004 Business Applications Santonu Sarkar, Riaz Kapadia, Srinivas Thonse and Ananth Chandramouli The Open Group Practitioners Conference April 2004 Topics Motivation Methodology Overview Language and

More information

CMMI for Services Quick Reference

CMMI for Services Quick Reference CAPACITY AND AVAILABILITY MANAGEMENT PROJECT & WORK MGMT (ML3) The purpose of Capacity and Availability Management (CAM) is to ensure effective service system performance and ensure that resources are

More information

TOGAF 9 Training: Foundation

TOGAF 9 Training: Foundation TOGAF 9 Training: Foundation Part I: Basic Concepts Document version control information Document Name Document Status Document Owner Part I: Basic Concepts Final IT Management Group TOGAF Lead Trainer

More information

The Three Dimensions of Requirements Engineering: 20 Years Later

The Three Dimensions of Requirements Engineering: 20 Years Later The Three Dimensions of Requirements Engineering: 20 Years Later Klaus Pohl and Nelufar Ulfat-Bunyadi Abstract Requirements engineering is the process of eliciting stakeholder needs and desires and developing

More information

WORK PLAN AND IV&V METHODOLOGY Information Technology - Independent Verification and Validation RFP No IVV-B

WORK PLAN AND IV&V METHODOLOGY Information Technology - Independent Verification and Validation RFP No IVV-B 1. Work Plan & IV&V Methodology 1.1 Compass Solutions IV&V Approach The Compass Solutions Independent Verification and Validation approach is based on the Enterprise Performance Life Cycle (EPLC) framework

More information

Core Design Requirements At the start of a project, it is important to specify those parameters and properties that:

Core Design Requirements At the start of a project, it is important to specify those parameters and properties that: Design & Innovation Fundamentals Lecture 3 Requirements Analysis Design Process Expression of need Engineer translates need into a definition of problem, including statement of desired outcome Engineer

More information

TOGAF Foundation. Part I: Basic Concepts 1 /

TOGAF Foundation. Part I: Basic Concepts 1 / TOGAF Foundation Part I: Basic Concepts 1 / Enterprise and Enterprise Architecture An Enterprise is any collection of organizations that has a common set of goals, for example: Government agency Whole

More information

Software Metrics & Software Metrology. Alain Abran. Chapter 10 Analysis of Quality Models and Measures in ISO 9126

Software Metrics & Software Metrology. Alain Abran. Chapter 10 Analysis of Quality Models and Measures in ISO 9126 Software Metrics & Software Metrology Alain Abran Chapter 10 Analysis of Quality Models and Measures in ISO 9126 1 Agenda This chapter covers: Introduction to ISO 9126 The analysis models in ISO 9126 as

More information

TOGAF 9.1 in Pictures

TOGAF 9.1 in Pictures TOGAF 9. in Pictures The TOGAF ADM Cycle Stage Set up an EA team and make sure it can do its work The ADM is about understanding existing architectures and working out the best way to change and improve

More information

A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 2.0 Skillport

A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 2.0 Skillport A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 2.0 by The International Institute of Business Analysis (IIBA) International Institute of Business Analysis. (c) 2009. Copying

More information

BCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2

BCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2 BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2 Friday 30 th September 2016 - Morning Answer any THREE questions

More information

ADM The Architecture Development Method

ADM The Architecture Development Method ADM The Development Method P Preliminary Phase Preliminary Phase Determine the Capability desired by the organization: Review the organizational context for conducting enterprise architecture Identify

More information

QUALITY ASSURANCE PLAN OKLAHOMA DEPARTMENT OF HUMAN SERVICES ENTERPRISE SYSTEM (MOSAIC PROJECT)

QUALITY ASSURANCE PLAN OKLAHOMA DEPARTMENT OF HUMAN SERVICES ENTERPRISE SYSTEM (MOSAIC PROJECT) QUALITY ASSURANCE PLAN OKLAHOMA DEPARTMENT OF HUMAN SERVICES ENTERPRISE SYSTEM (MOSAIC PROJECT) MOSAIC Quality Assurance Plan v04.02 Prepared by: Approved by: QUALITY ASSURANCE PLAN APPROVALS QA/QC Program

More information

Model for conflict resolution in aspects within Aspect Oriented Requirement engineering

Model for conflict resolution in aspects within Aspect Oriented Requirement engineering Master Thesis Software Engineering Thesis no: MSE-2008-11 June 2008 Model for conflict resolution in aspects within Aspect Oriented Requirement engineering Faisal Hameed Mohammad Ejaz School of Engineering

More information

This resource is associated with the following paper: Assessing the maturity of software testing services using CMMI-SVC: an industrial case study

This resource is associated with the following paper: Assessing the maturity of software testing services using CMMI-SVC: an industrial case study RESOURCE: MATURITY LEVELS OF THE CUSTOMIZED CMMI-SVC FOR TESTING SERVICES AND THEIR PROCESS AREAS This resource is associated with the following paper: Assessing the maturity of software testing services

More information

TOGAF Foundation Exam

TOGAF Foundation Exam TOGAF Foundation Exam TOGAF 9 Part 1 (ESL) Time Limit 90 minutes Number of questions 40 Pass-through 22 1. Which of the following best describes the meaning of "Initial Level of Risk" in Risk Management?

More information

COMPLIANCE WITH THIS PUBLICATION IS MANDATORY

COMPLIANCE WITH THIS PUBLICATION IS MANDATORY BY ORDER OF THE COMMANDER AIR FORCE RESEARCH LABORATORY AIR FORCE RESEARCH LABORATORY INSTRUCTION 33-401 13 MARCH 2014 Communications and Information ENTERPRISE BUSINESS INFORMATION TECHNOLOGY REQUIREMENTS

More information

T Software Testing and Quality Assurance Test Planning

T Software Testing and Quality Assurance Test Planning T-76.5613 Software Testing and Quality Assurance 10.10.2007 Test Planning Juha Itkonen Outline Test planning, purpose and usage of a test plan Topics of test planning Exercise References: IEEE Std 829-1998,

More information

REQUIREMENT DRIVEN TESTING. Test Strategy for. Project name. Prepared by <author name> [Pick the date]

REQUIREMENT DRIVEN TESTING. Test Strategy for. Project name. Prepared by <author name> [Pick the date] REQUIREMENT DRIVEN TESTING Test Strategy for Project name Prepared by [Pick the date] [Type the abstract of the document here. The abstract is typically a short summary of the contents of

More information

R214 SPECIFIC REQUIREMENTS: INFORMATION TECHNOLOGY TESTING LABORATORY ACCREDITATION PROGRAM

R214 SPECIFIC REQUIREMENTS: INFORMATION TECHNOLOGY TESTING LABORATORY ACCREDITATION PROGRAM A2LA R214 Specific Requirements: Information Technology Testing Laboratory Accreditation Document Revised: 3/5/18 Page 1 of 34 R214 SPECIFIC REQUIREMENTS: INFORMATION TECHNOLOGY TESTING LABORATORY ACCREDITATION

More information

Software Processes. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1

Software Processes. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Objectives To introduce software process models To describe three generic process models and when they may be

More information

7. Model based software architecture

7. Model based software architecture UNIT - III Model based software architectures: A Management perspective and technical perspective. Work Flows of the process: Software process workflows, Iteration workflows. Check Points of The process

More information

Improving the Test Process with TMMi

Improving the Test Process with TMMi Improving the Test Process with TMMi BCS SIGiST 19 th September 2012 Presented by Geoff Thompson Listen Challenge Understand Interpret Create Experimentus Ltd 17a Dorset Square London NW1 6QB T: +44 (0)207

More information

Chapter 6. Software Quality Management & Estimation

Chapter 6. Software Quality Management & Estimation Chapter 6 Software Quality Management & Estimation What is Quality Management Also called software quality assurance (SQA) s/w quality:- It is defined as the degree to which a system, components, or process

More information

EUROCONTROL Guidance Material for Short Term Conflict Alert Appendix B-1: Safety Argument for STCA System

EUROCONTROL Guidance Material for Short Term Conflict Alert Appendix B-1: Safety Argument for STCA System EUROPEAN ORGANISATION FOR THE SAFETY OF AIR NAVIGATION EUROCONTROL EUROCONTROL Guidance Material for Short Term Conflict Alert Appendix B-1: Safety Argument for STCA System Edition Number : 1.0 Edition

More information

Functional requirements and acceptance testing

Functional requirements and acceptance testing Functional requirements and acceptance testing Lecture 3 Software Engineering TDDC88/TDDC93 autumn 2007 Department of Computer and Information Science Linköping University, Sweden Message from the course

More information

EXTENDING SHAREPOINT TECHNOLOGIES TOWARDS PROJECT MANAGEMENT CAPABILITIES. Wido Wirsam 1

EXTENDING SHAREPOINT TECHNOLOGIES TOWARDS PROJECT MANAGEMENT CAPABILITIES. Wido Wirsam 1 EXTENDING SHAREPOINT TECHNOLOGIES TOWARDS PROJECT MANAGEMENT CAPABILITIES Wido Wirsam 1 Modern groupware systems serve as universal information sharing platforms by providing manifold capabilities for

More information

1 Management Responsibility 1 Management Responsibility 1.1 General 1.1 General

1 Management Responsibility 1 Management Responsibility 1.1 General 1.1 General 1 Management Responsibility 1 Management Responsibility 1.1 General 1.1 General The organization s management with executive The commitment and involvement of the responsibility shall define, document

More information

Chapter 4 Requirements Elicitation

Chapter 4 Requirements Elicitation Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 4 Requirements Elicitation Outline Today: Motivation: Software Lifecycle Requirements elicitation challenges Problem statement

More information

Knowledge mechanisms in IEEE 1471 & ISO/IEC Rich Hilliard

Knowledge mechanisms in IEEE 1471 & ISO/IEC Rich Hilliard Knowledge mechanisms in IEEE 1471 & ISO/IEC 42010 Rich Hilliard r.hilliard@computer.org Two Themes Knowledge mechanisms in IEEE 1471 and ISO/IEC 42010 2000 edition and on-going revision Toward a (bigger)

More information

Software Development Life Cycle:

Software Development Life Cycle: Software Development Life Cycle: The systems development life cycle (SDLC), also referred to as the application development life-cycle, is a term used in systems engineering, information systems and software

More information

PHD. THESIS -ABSTRACT-

PHD. THESIS -ABSTRACT- Investeşte în oameni! Proiect cofinantat din Fondul Social European prin Programul Operaţional Sectorial pentru Dezvoltarea Resurselor Umane 2007 2013 Eng. Lavinia-Gabriela SOCACIU PHD. THESIS -ABSTRACT-

More information

Design of an Integrated Model for Development of Business and Enterprise Systems

Design of an Integrated Model for Development of Business and Enterprise Systems International Journal of Research Studies in Computer Science and Engineering (IJRSCSE) Volume 2, Issue 5, May 2015, PP 50-57 ISSN 2349-4840 (Print) & ISSN 2349-4859 (Online) www.arcjournals.org Design

More information

CS 351 Requirements Engineering

CS 351 Requirements Engineering CS 351 Requirements Engineering Instructor: Joel Castellanos e-mail: joel@unm.edu Web: http://cs.unm.edu/~joel/ 4/13/2017 2 1 Designing Large Programs: Essence & Accidents "The hardest single part of building

More information

IIBA Global Business Analysis Core Standard. A Companion to A Guide to the Business Analysis Body of Knowledge (BABOK Guide) Version 3

IIBA Global Business Analysis Core Standard. A Companion to A Guide to the Business Analysis Body of Knowledge (BABOK Guide) Version 3 IIBA Global Business Analysis Core Standard A Companion to A Guide to the Business Analysis Body of Knowledge (BABOK Guide) Version 3 International Institute of Business Analysis, Toronto, Ontario, Canada.

More information

WEBINARS. Model Based Requirements Engineering (MBRE) Tuesday, 06 February 2018

WEBINARS. Model Based Requirements Engineering (MBRE) Tuesday, 06 February 2018 Model Based Requirements Engineering (MBRE) Tuesday, 06 February 2018 Introduction: Webinar rules Webinar rules: The Webinar will start in few minutes You ll be muted all along the Webinar There s a chatting

More information

Critical Skills for Writing Better Requirements (Virtual Classroom Edition)

Critical Skills for Writing Better Requirements (Virtual Classroom Edition) Critical Skills for Writing Better Requirements (Virtual Classroom Edition) Eliminate Costly Changes and Save Time by Nailing Down the Project Requirements the First Time! Critical Skills for Writing Better

More information

SE curriculum in CC2001 made by IEEE and ACM: What is Software Engineering?

SE curriculum in CC2001 made by IEEE and ACM: What is Software Engineering? SE curriculum in CC2001 made by IEEE and ACM: Overview and Ideas for Our Work Katerina Zdravkova Institute of Informatics E-mail: Keti@ii.edu.mk What is Software Engineering? SE is the discipline concerned

More information

Copyright Software Engineering Competence Center

Copyright Software Engineering Competence Center Copyright Software Engineering Competence Center 2012 1 Copyright Software Engineering Competence Center 2012 5 These are mapped categories to the waste categories of manufacturing. An excellent overview

More information

WP2: Automatic Code Structure and Workflow Generation from Models

WP2: Automatic Code Structure and Workflow Generation from Models OPAALS Project (Contract n IST-034824) OPAALS PROJECT Contract n IST-034824 WP2: Automatic Code Structure and Workflow Generation from Models Del2.5 - Extended automated code/workflow generation example

More information

This chapter illustrates the evolutionary differences between

This chapter illustrates the evolutionary differences between CHAPTER 6 Contents An integrated approach Two representations CMMI process area contents Process area upgrades and additions Project management concepts process areas Project Monitoring and Control Engineering

More information

Introduction and Key Concepts Study Group Session 1

Introduction and Key Concepts Study Group Session 1 Introduction and Key Concepts Study Group Session 1 PD hours/cdu: CH71563-01-2018 (3 hours each session) 2015, International Institute of Business Analysis (IIBA ). Permission is granted to IIBA Chapters

More information

Software Processes. Objectives. Topics covered. The software process. Waterfall model. Generic software process models

Software Processes. Objectives. Topics covered. The software process. Waterfall model. Generic software process models Objectives Software Processes To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software

More information

Appendix C: MS Project Software Development Plan and Excel Budget.

Appendix C: MS Project Software Development Plan and Excel Budget. 1. Introduction. Appendix C: MS Project Software Development Plan and Excel Budget. Project: PickUp Game App The Project plan for this Application consist of 76 days; In this plan is defined how long each

More information

Objectives. The software process. Topics covered. Waterfall model. Generic software process models. Software Processes

Objectives. The software process. Topics covered. Waterfall model. Generic software process models. Software Processes Objectives Software Processes To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software

More information

Chapter 4 Document Driven Approach for Agile Methodology

Chapter 4 Document Driven Approach for Agile Methodology Chapter 4 Document Driven Approach for Agile Methodology In this chapter, 4.1. Introduction 4.2. Documentation Selection Factors 4.3. Minimum Required Documents 4.4. Summary 4.1. Introduction In all, the

More information

ENA Future Worlds Consultation

ENA Future Worlds Consultation ENA Future Worlds Consultation Section 2: The Future Worlds We have set out five potential Future Worlds. Do you believe these provide a reasonable spread of potential futures? They provide us with a good

More information

Quality Frameworks: Implementation and Impact

Quality Frameworks: Implementation and Impact Committee for the Coordination of Statistical Activities Conference on Data Quality for International Organizations Newport, Wales, United Kingdom, 27-28 April 2006 Session 1: Quality assurance frameworks

More information

Architecture. By Glib Kutepov Fraunhofer IESE

Architecture. By Glib Kutepov Fraunhofer IESE Architecture By Glib Kutepov Glib.kutepov@iese.fraunhofer.de Outline 1. Why Architecture? 2. What is Architecture? 3. How to create an Architecture? Alignment Modeling and Structuring Architectural Views

More information

2014 Oct.31 International Symposium on Practical Formal Approaches to Software Development. Copyright Prof. Dr. Shuichiro Yamamoto 2014

2014 Oct.31 International Symposium on Practical Formal Approaches to Software Development. Copyright Prof. Dr. Shuichiro Yamamoto 2014 2014 Oct.31 International Symposium on Practical Formal Approaches to Software Development Nagoya University Dr. Prof. Shuichiro Yamamoto 1 Agenda Assurance case Pitfalls of assurance case Generic derivation

More information