DOCSLIB.ORG

Automatic Generation of Sequence Diagrams and Updating Domain Model from Use Cases

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

SOFTENG 2015 : The First International Conference on Advances and Trends in Software Engineering Automatic Generation of Sequence Diagrams and Updating Domain Model from Use Cases Fabio Cardoso de Souza, Fernando Antonio de Castro Giorno Master’s Program in Software Engineering Institute for Technological Research (IPT) São Paulo, Brazil e-mail: [email protected], [email protected] Abstract —Software modeling allows for problem utilization of markups in Use Cases can allow for the decomposition in a way that facilitates analysis and automatic partial generation of the Analysis Model, as communication of the solution to developers and other demonstrated in the Mason and Supsrisupachai [20] work, interested parties. Models are widely used in engineering in where marked up Use Cases are automatic transformed into general, but in Software Engineering modeling has often been Sequence Diagrams. left out due to the pressures to improve deadlines. A method The automatic partial generation could reduce the and a tool that reduce the duration of this phase could help duration of the modeling phase, thus stimulating the adoption furthering the modeling phase. Use Cases are commonly of this phase in Object-Oriented development projects, as utilized for functional specifications in Object-Oriented suggested by a qualitative research [23] carried out with paradigm and the use of markups in Use Cases allow an requirements analysts, system analysts and project managers. automatic partial generation of Analysis Models, reducing the time of the modeling phase in this paradigm. This paper In this qualitative research, the majority of the interviewees proposes a combination of rules for marking up Use Cases and agreed that software modeling improves the quality of the one procedure for generating partial Sequence Diagrams with final product and most of them believe that the automatic analysis classes (one Sequence Diagram for each Use Case) and generation of the partial Analysis Model can help the the updating of the Domain Model with operations. A tool was adoption of the modeling phase in software development built to prove the concept and two experiments were carried projects. Due to space limitation, details of this research are out. omitted. This paper presents a set of rules for marking up Use Keywords-Analysis Model; Use Case; Sequence Diagram; Cases and a transformation procedure that permits deriving Model Driven Architecture. Sequence Diagrams with analysis classes from the marked- up Use Cases. It also permits the updating of the Domain I. INTRODUCTION Model with operations identified in the Sequence Diagrams, Software modeling permits the analyst to break the leading to the Class Diagram. Class Diagram and Sequence problem to be solved into parts which can be better analyzed. Diagrams are the main diagrams in an Object-Oriented It also allows the formal communication of a functional and analysis model. The diagrams generated do not take into technical solution based on the demanded requirements. consideration details of a possible implementation, which Model is a formal specification of the structure or function of must be done during the design phase. According to Booch a system [1]. A graphic representation can be used to provide et al. [4], the analysis must yield a statement of what the a visual body for the model. system does, not how. This research also presents a tool Despite being widely used in many areas of engineering, which implements the proposed procedure and with which modeling has been left out in Software Engineering. the experiments were realized. According Rosenberg and Stephens [2], in practice, there The rest of this paper is organized as follows. Section 2 never seems to be enough time to do modeling, analysis and presents concepts on which this research is based. This design and there is always pressure from management to section also presents the State of the Art in the topics Model jump to code prematurely because progress on software Driven Architecture and transformation of Use Cases into projects tends to get measured by how much code exists, Sequence Diagrams. Section 3 presents a proposal for leading to problems in the quality of software. marking up Use Cases and a transformation procedure. Use Cases are commonly used for functional Section 4 presents the tool and two experiments. The fifth specification in Object-Oriented developments. According to and final section presents the conclusion and suggestions for Sommerville [3], Use Cases are an effective technique for future researches. eliciting requirements and they are increasingly used since the Unified Modeling Language (UML) became a standard for Object-Oriented modeling. Yet according to Rosenberg and Stephens [2], the Use Cases are created over a Domain Model since this offers the use of a common vocabulary. The Copyright (c) IARIA, 2015. ISBN: 978-1-61208-449-7 85 SOFTENG 2015 : The First International Conference on Advances and Trends in Software Engineering II. CONCEPTS AND STATE OF THE ART control and entity. According to him, boundary classes respond to information and behaviors related to system This section starts presenting concepts related with Use boundary; entity classes respond to information that are Cases, Software Modeling and transforming requirements stored in the system and to behaviors surrounding these into software models approaches, and ends with state of the information; and control classes respond to behaviors which art on transformation subject. are not naturally incorporated into entities. These definitions A. Requirements Specification with Use Cases are complemented by Bruegge and Dutoit [9], for whom, boundary classes represents interfaces between systems and Requirements Engineering provides appropriate actors, and control classes are in charge of realizing Use mechanisms for [5]: understanding what the client wants; Cases. analysis of her/his needs; evaluation of feasibility; The boundary and control classes, as well as their negotiation of a reasonable solution; specification of behaviors (their operations) are evident during analysis, in requirements in a unambiguous manner; validation of the Analysis Model. specification and management of the requirements to be In this paper, these three types of objects are adopted in a implemented. way through which the Sequence Diagram can represent the Use Cases serves as functional specifications of software model with these three layers (boundary, control requirements in Object-Oriented paradigm and the Analysis and entities). Model is created based on them. Use Cases provide the Sequence Diagram is the second most important diagram external behavior expected by the system with respect to the of an Analysis Model and it is used to illustrate how objects vocabulary in a Domain Model. Rosenberg [2] states that interact with one another through messages, demonstrating Use Cases describes a way by which the users interacts with the internal behavior of one system functionality (one Use the system and how the system responds. Pressman [5] notes Case). that Use Cases does not tell how a system should realize the The sequence of messages in a Sequence Diagram can functionality. This emphasizes the importance of modeling. use a pattern of communication between the objects, how, According to Larman [6], Use Cases can be essential or for example, the pattern presented by Heinemann and concrete. Essential Use Cases do not consider mechanism Denham [10], where messages should follow the flow details (like User Interfaces), while Concrete Use Cases “boundary control entity”. This pattern is adopted consider them. In this paper, only Concrete Use Cases are in this work. contemplated. Yet, according to Rosenberg [2], Use Cases should be C. MDD and MDA written in the objects model context, referencing domain Model Driven Development (MDD) refers to the classes and boundary classes by their names. This approaches based on models as the main products of a recommendation is the base for this work as the objects development [11]. According to Milicev [12], MDD raises constituents of the Analysis Model are the objects referenced the level of abstraction in a development. in the Use Cases and existing in the Domain Model. Model Driven Architecture (MDA) is a MDD approach Use Cases makes explicit not only the objects involved in proposed by the Object Management Group (OMG) whose the system boundary but also the actors participating in the objective is to alleviate the problem of ruptures between functionality and their actions. An actor is any entity that design and code due to system migration from one platform communicates with the system and is external to it, and may to another [11]. be a device, a system or a person. A main actor is that which MDA advocates four layers of model: Computation interacts with the system in order to produce the result while Independent Model (CIM), Platform Independent Model secondary actors only support the system [5]. (PIM), Platform Specific Model (PSM) and Implementation B. Analysis Model Specific Model (ISM) as shown in Figure 1. In the CIM layer there lies the process models and Modeling is generally done in two levels of abstraction: requirements that are independent of computing. In the PIM Analysis Model and Design. layer there lies the Analysis Model which is in the The Analysis Model - or Software Architectural Design - computing field, therefore totally independent of platform. In is used to identify, in a high level of abstraction, the the PSM layer there lies the lower level models, which takes components of the software, describing how the software is into consideration the platform where the system would be decomposed and organized into components [7]. In the case introduced. Finally, the ISM layer is the layer where the code of Object-Oriented software, these components are Analysis is generated. The development focuses, on the MDA Classes with their attributes and operations. In this paper, a approach, is at a high level of abstraction, that is, in the CIM partial Analysis Model is the expected result of the and PIM layers.
Recommended publications
  • Writing and Reviewing Use-Case Descriptions

    Writing and Reviewing Use-Case Descriptions

    Bittner/Spence_06.fm Page 145 Tuesday, July 30, 2002 12:04 PM PART II WRITING AND REVIEWING USE-CASE DESCRIPTIONS Part I, Getting Started with Use-Case Modeling, introduced the basic con- cepts of use-case modeling, including defining the basic concepts and understanding how to use these concepts to define the vision, find actors and use cases, and to define the basic concepts the system will use. If we go no further, we have an overview of what the system will do, an under- standing of the stakeholders of the system, and an understanding of the ways the system provides value to those stakeholders. What we do not have, if we stop at this point, is an understanding of exactly what the system does. In short, we lack the details needed to actually develop and test the system. Some people, having only come this far, wonder what use-case model- ing is all about and question its value. If one only comes this far with use- case modeling, we are forced to agree; the real value of use-case modeling comes from the descriptions of the interactions of the actors and the system, and from the descriptions of what the system does in response to the actions of the actors. Surprisingly, and disappointingly, many teams stop after developing little more than simple outlines for their use cases and consider themselves done. These same teams encounter problems because their use cases are vague and lack detail, so they blame the use-case approach for having let them down. The failing in these cases is not with the approach, but with its application.
  • Document Title Requirements on Debugging in AUTOSAR

    Document Title Requirements on Debugging in AUTOSAR

    Requirements on Debugging in AUTOSAR AUTOSAR Release 4.2.2 Document Title Requirements on Debugging in AUTOSAR Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification No 332 Document Classification Auxiliary Document Status Final Part of AUTOSAR Release 4.2.2 Document Change History Release Changed by Change Description 4.2.2 AUTOSAR Marked the document as obsolete Release Management 4.2.1 AUTOSAR Editorial changes Release Management 4.1.2 AUTOSAR Updated reference to RS feature document Release Editorial changes Management 4.1.1 AUTOSAR Updated the format of requirements according Administration to TPS_StandardizationTemplate Updated the chapters 2 and 5 Replaced Complex Device Driver by Complex Driver 3.1.5 AUTOSAR Initial release Administration 1 of 19 Document ID 332: AUTOSAR_SRS_Debugging - AUTOSAR confidential - Requirements on Debugging in AUTOSAR AUTOSAR Release 4.2.2 Disclaimer This specification and the material contained in it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the companies that have contributed to it shall not be liable for any use of the specification. The material contained in this specification is protected by copyright and other types of Intellectual Property Rights. The commercial exploitation of the material contained in this specification requires a license to such Intellectual Property Rights. This specification may be utilized or reproduced without any modification, in any form or by any means, for informational purposes only. For any other purpose, no part of the specification may be utilized or reproduced, in any form or by any means, without permission in writing from the publisher. The AUTOSAR specifications have been developed for automotive applications only.
  • The Guide to Succeeding with Use Cases

    The Guide to Succeeding with Use Cases

    USE-CASE 2.0 The Guide to Succeeding with Use Cases Ivar Jacobson Ian Spence Kurt Bittner December 2011 USE-CASE 2.0 The Definitive Guide About this Guide 3 How to read this Guide 3 What is Use-Case 2.0? 4 First Principles 5 Principle 1: Keep it simple by telling stories 5 Principle 2: Understand the big picture 5 Principle 3: Focus on value 7 Principle 4: Build the system in slices 8 Principle 5: Deliver the system in increments 10 Principle 6: Adapt to meet the team’s needs 11 Use-Case 2.0 Content 13 Things to Work With 13 Work Products 18 Things to do 23 Using Use-Case 2.0 30 Use-Case 2.0: Applicable for all types of system 30 Use-Case 2.0: Handling all types of requirement 31 Use-Case 2.0: Applicable for all development approaches 31 Use-Case 2.0: Scaling to meet your needs – scaling in, scaling out and scaling up 39 Conclusion 40 Appendix 1: Work Products 41 Supporting Information 42 Test Case 44 Use-Case Model 46 Use-Case Narrative 47 Use-Case Realization 49 Glossary of Terms 51 Acknowledgements 52 General 52 People 52 Bibliography 53 About the Authors 54 USE-CASE 2.0 The Definitive Guide Page 2 © 2005-2011 IvAr JacobSon InternationAl SA. All rights reserved. About this Guide This guide describes how to apply use cases in an agile and scalable fashion. It builds on the current state of the art to present an evolution of the use-case technique that we call Use-Case 2.0.
  • INCOSE: the FAR Approach “Functional Analysis/Allocation and Requirements Flowdown Using Use Case Realizations”

    INCOSE: the FAR Approach “Functional Analysis/Allocation and Requirements Flowdown Using Use Case Realizations”

    in Proceedings of the 16th Intern. Symposium of the International Council on Systems Engineering (INCOSE'06), Orlando, FL, USA, Jul 2006. The FAR Approach – Functional Analysis/Allocation and Requirements Flowdown Using Use Case Realizations Magnus Eriksson1,2, Kjell Borg1, Jürgen Börstler2 1BAE Systems Hägglunds AB 2Umeå University SE-891 82 Örnsköldsvik SE-901 87 Umeå Sweden Sweden {magnus.eriksson, kjell.borg}@baesystems.se {magnuse, jubo}@cs.umu.se Copyright © 2006 by Magnus Eriksson, Kjell Borg and Jürgen Börstler. Published and used by INCOSE with permission. Abstract. This paper describes a use case driven approach for functional analysis/allocation and requirements flowdown. The approach utilizes use cases and use case realizations for functional architecture modeling, which in turn form the basis for design synthesis and requirements flowdown. We refer to this approach as the FAR (Functional Architecture by use case Realizations) approach. The FAR approach is currently applied in several large-scale defense projects within BAE Systems Hägglunds AB and the experience so far is quite positive. The approach is illustrated throughout the paper using the well known Automatic Teller Machine (ATM) example. INTRODUCTION Organizations developing software intensive defense systems, for example vehicles, are today faced with a number of challenges. These challenges are related to the characteristics of both the market place and the system domain. • Systems are growing ever more complex, consisting of tightly integrated mechanical, electrical/electronic and software components. • Systems have very long life spans, typically 30 years or longer. • Due to reduced acquisition budgets, these systems are often developed in relatively short series; ranging from only a few to several hundred units.
  • Plantuml Language Reference Guide (Version 1.2021.2)

    Plantuml Language Reference Guide (Version 1.2021.2)

    Drawing UML with PlantUML PlantUML Language Reference Guide (Version 1.2021.2) PlantUML is a component that allows to quickly write : • Sequence diagram • Usecase diagram • Class diagram • Object diagram • Activity diagram • Component diagram • Deployment diagram • State diagram • Timing diagram The following non-UML diagrams are also supported: • JSON Data • YAML Data • Network diagram (nwdiag) • Wireframe graphical interface • Archimate diagram • Specification and Description Language (SDL) • Ditaa diagram • Gantt diagram • MindMap diagram • Work Breakdown Structure diagram • Mathematic with AsciiMath or JLaTeXMath notation • Entity Relationship diagram Diagrams are defined using a simple and intuitive language. 1 SEQUENCE DIAGRAM 1 Sequence Diagram 1.1 Basic examples The sequence -> is used to draw a message between two participants. Participants do not have to be explicitly declared. To have a dotted arrow, you use --> It is also possible to use <- and <--. That does not change the drawing, but may improve readability. Note that this is only true for sequence diagrams, rules are different for the other diagrams. @startuml Alice -> Bob: Authentication Request Bob --> Alice: Authentication Response Alice -> Bob: Another authentication Request Alice <-- Bob: Another authentication Response @enduml 1.2 Declaring participant If the keyword participant is used to declare a participant, more control on that participant is possible. The order of declaration will be the (default) order of display. Using these other keywords to declare participants
  • Open Research Online UML in Practice Oro.Open.Ac.Uk

    Open Research Online UML in Practice Oro.Open.Ac.Uk

    Open Research Online The Open University’s repository of research publications and other research outputs UML in practice Conference Item How to cite: Petre, Marian (2013). UML in practice. In: 35th International Conference on Software Engineering (ICSE 2013), 18-26 May 2013, San Francisco, CA, USA (forthcoming), pp. 722–731. For guidance on citations see FAQs. c 2013 IEEE Version: Accepted Manuscript Link(s) to article on publisher’s website: http://2013.icse-conferences.org/ Copyright and Moral Rights for the articles on this site are retained by the individual authors and/or other copy- right owners. For more information on Open Research Online’s data policy on reuse of materials please consult the policies page. oro.open.ac.uk UML in Practice Marian Petre Centre for Research in Computing The Open University Milton Keynes, UK [email protected] Abstract—UML has been described by some as “the lingua UML “with rigor” (as he later expressed to the informant). In franca of software engineering”. Evidence from industry does contrast, the informant concluded that probably 45 of the 47 not necessarily support such endorsements. How exactly is UML were like him: “selective borrowers” … “who use some of the being used in industry – if it is? This paper presents a corpus of principles sometimes”. The IBM speaker and the informant interviews with 50 professional software engineers in 50 had very different models of what ‘using UML’ means in companies and identifies 5 patterns of UML use. practice, with different implications. Index Terms—UML, software development, software design, Budgen et al.
  • Tool Use in Software Modelling Education

    Tool Use in Software Modelling Education

    Tool use in software modelling education Seiko Akayama1, Birgit Demuth3, Timothy C. Lethbridge4, Marion Scholz2, Perdita Stevens5, and Dave R. Stikkolorum6 1 Kyushu University, Japan 2 Vienna University of Technology, Austria 3 Technische Universit¨atDresden, Germany 4 University of Ottawa Canada 5 University of Edinburgh Scotland 6 Leiden University The Netherlands Abstract. An important decision that must be taken by anyone design- ing a course involving (object oriented software) modelling is what tool support, if any, to use. Options include picking an industrial strength modelling tool, using a tool specifically designed for educational use, or eschewing tool use altogether in favour of pencil and paper. The best an- swer will depend on many factors, including the prior experience of the students (and staff), the length and organisation of the course, and the learning objectives. Moreover, decisions on tools have an impact on other aspects of course design. In this informal paper, the result of discussion at the MODELS Educators' Symposium 2013, we survey previous work on this question, discuss our own experience, and draw out some key issues that someone designing a new course involving modelling must consider. 1 Introduction Teaching object oriented design and modelling in a university is important not only because these are important skills that students will need if they pursue careers in software development, but also because this area is a key interface be- tween research and teaching. This double motivation { we might say, vocational and intellectual { for teaching design and modelling is itself a source of challenge for educators. We experience a tension between the desire to train students in the skills they will need after university, and the desire to have them reflect on the nature of design and modelling and the ways in which these activities could be improved with the help of cutting edge research.
  • Use Case Tutorial Version X.X ● April 18, 2016

    Use Case Tutorial Version X.X ● April 18, 2016

    Use Case Tutorial Version X.x ● April 18, 2016 Company Name Limited Street City, State ZIP Country phone: +1 000 123 4567 Company Name Limited Street City, State ZIP Country phone: +1 000 123 4567 Company Name Limited Street City, State ZIP Country phone: +1 000 123 4567 www.website.com [Company Name] [Document Name] [Project Name] [Version Number] Table of Contents Introduction ..............................................................................................3 1. Use cases and activity diagrams .......................................................4 1.1. Use case modelling ....................................................................4 1.2. Use cases and activity diagrams ..................................................7 1.3. Actors .......................................................................................7 1.4. Describing use cases.................................................................. 8 1.5. Scenarios ................................................................................10 1.6. More about actors ....................................................................13 1.7. Modelling the relationships between use cases ...........................15 1.8. Stereotypes .............................................................................15 1.9. Sharing behaviour between use cases........................................ 16 1.10. Alternatives to the main success scenario ..................................17 1.11. To extend or include? ...............................................................20
  • User-Stories-Applied-Mike-Cohn.Pdf

    User-Stories-Applied-Mike-Cohn.Pdf

    ptg User Stories Applied ptg From the Library of www.wowebook.com The Addison-Wesley Signature Series The Addison-Wesley Signature Series provides readers with practical and authoritative information on the latest trends in modern technology for computer professionals. The series is based on one simple premise: great books come from great authors. Books in the series are personally chosen by expert advi- sors, world-class authors in their own right. These experts are proud to put their signatures on the cov- ers, and their signatures ensure that these thought leaders have worked closely with authors to define topic coverage, book scope, critical content, and overall uniqueness. The expert signatures also symbol- ize a promise to our readers: you are reading a future classic. The Addison-Wesley Signature Series Signers: Kent Beck and Martin Fowler Kent Beck has pioneered people-oriented technologies like JUnit, Extreme Programming, and patterns for software development. Kent is interested in helping teams do well by doing good — finding a style of software development that simultaneously satisfies economic, aesthetic, emotional, and practical con- straints. His books focus on touching the lives of the creators and users of software. Martin Fowler has been a pioneer of object technology in enterprise applications. His central concern is how to design software well. He focuses on getting to the heart of how to build enterprise software that will last well into the future. He is interested in looking behind the specifics of technologies to the patterns, ptg practices, and principles that last for many years; these books should be usable a decade from now.
  • UNIT 1 UML DIAGRAMS Introduction to OOAD – Unified Process

    UNIT 1 UML DIAGRAMS Introduction to OOAD – Unified Process

    VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE UNIT 1 UML DIAGRAMS Introduction to OOAD – Unified Process - UML diagrams – Use Case – Class Diagrams– Interaction Diagrams – State Diagrams – Activity Diagrams – Package, component and Deployment Diagrams. INTRODUCTION TO OOAD ANALYSIS Analysis is a creative activity or an investigation of the problem and requirements. Eg. To develop a Banking system Analysis: How the system will be used? Who are the users? What are its functionalities? DESIGN Design is to provide a conceptual solution that satisfies the requirements of a given problem. Eg. For a Book Bank System Design: Bank(Bank name, No of Members, Address) Student(Membership No,Name,Book Name, Amount Paid) OBJECT ORIENTED ANALYSIS (OOA) Object Oriented Analysis is a process of identifying classes that plays an important role in achieving system goals and requirements. Eg. For a Book Bank System, Classes or Objects identified are Book-details, Student-details, Membership-Details. OBJECT ORIENTED DESIGN (OOD) Object Oriented Design is to design the classes identified during analysis phase and to provide the relationship that exists between them that satisfies the requirements. Eg. Book Bank System Class name Book-Bank (Book-Name, No-of-Members, Address) Student (Name, Membership No, Amount-Paid) OBJECT ORIENTED ANALYSIS AND DESIGN (OOAD) • OOAD is a Software Engineering approach that models an application by a set of Software Development Activities. YEAR/SEM: III/V CS6502-OOAD Page 1 VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE • OOAD emphasis on identifying, describing and defining the software objects and shows how they collaborate with one another to fulfill the requirements by applying the object oriented paradigm and visual modeling throughout the development life cycles.
  • Executing UML Models

    Executing UML Models

    Executing UML Models Miguel Pinto Luz1, Alberto Rodrigues da Silva1 1Instituto Superior Técnico Av. Rovisco Pais 1049-001 Lisboa – Portugal {miguelluz, alberto.silva}@acm.org Abstract. Software development evolution is a history of permanent seeks for raising the abstraction level to new limits overcoming new frontiers. Executable UML (xUML) comes this way as the expectation to achieve the next level in abstraction, offering the capability of deploying a xUML model in a variety of software environments and platforms without any changes. This paper comes as a first expedition inside xUML, exploring the main aspects of its specification including the action languages support and the fundamental MDA compliance. In this paper is presented a future new xUML tool called XIS-xModels that gives Microsoft Visio new capabilities of running and debugging xUML models. This paper is an outline of the capabilities and main features of the future application. Keywords: UML, executable UML, Model Debugging, Action Language. 1. Introduction In a dictionary we find that an engineer is a person who uses scientific knowledge to solve practical problems, planning and directing, but an information technology engineer is someone that spends is time on implementing lines of code, instead of being focus on planning and projecting. Processes, meetings, models, documents, or even code are superfluous artifacts for organizations: all they need is well design and fast implemented working system, that moves them towards a new software development paradigm, based on high level executable models. According this new paradigm it should be possible to reduce development time and costs, and to bring new product quality warranties, only reachable by executing, debugging and testing early design stages (models).
  • Use Cases, User Stories and Bizdevops

    Use Cases, User Stories and Bizdevops

    Use Cases, User Stories and BizDevOps Peter Forbrig University of Rostock, Chair in Software Engineering, Albert-Einstein-Str. 22, 18055 Rostock [email protected] Abstract. DevOps is currently discussed a lot in computer science communi- ties. BizDev (business development) is only mentioned once in a computer sci- ence paper in connection with Continuous Software Engineering. Otherwise it is used in the domain of business administration only. Additionally, there seems to be a different interpretation of the term in the two communities. The paper discusses the different interpretations found in the literature. Addi- tionally, the idea of BizDevOps is discussed in conjunction with further ideas of taking new requirements for software features into account. These requirements can be described by models on different level of granularity. Starting points are use cases, use-case slices, user stories, and scenarios. They have to be commu- nicated between stakeholders. It is argued in this paper that storytelling can be a solution for that. It is used in as well in software development as in manage- ment. Keywords: BizDev, DevOps, BizDevOps, Continuous Requirements Engineer- ing, Continuous Software Engineering, Agile Software Development, Storytell- ing. 1 Introduction Developing Businesses if often related with the development of software because nowadays business processes have to be supported by IT. Continuous requirements engineering has to be performed to provide continuously the optimal support. Contin- uous business development seems to be a good description for the combined devel- opment of software and business. This term is not used so very often. Nevertheless, it exists like in [17]. However, more often the abbreviation BizDev (business development) is used.