DOCSLIB.ORG

The Use Case Technique: an Overview

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Use Case Technique: an Overview The Use Case Technique: An Overview Sponsored by: Karl Wiegers Principal Consultant, Process Impact www.processimpact.com Sponsor: RequirementOne Save time. Capture use cases quickly in intuitive Word format and accurately with all attributes in one central location Quick to implement. Less than 2 minutes to create account + add first requirement Free 30 day trial Cloud based platform WEBINAR EXCLUSIVE… st Sign up by 1 August & get an hour $45/project/month with a requirements expert to make Unlimited users sure your first paid project is a success! Visit www.requirementone.com to get your session. 2 Featured Speaker Karl Wiegers Principal Consultant, Process Impact www.processimpact.com Phone #: 503-698-9620 E-mail: [email protected] Blog: Consulting Tips & Tricks Blog: www.karlconsulting.blogspot.com Downloadable Process Goodies: www.processimpact.com/goodies.shtml 3 Sponsored By Source Books Software Requirements,2 nd Ed., by Karl E. Wiegers (Microsoft Press, 2003) More about Software Requirements , by Karl E. Wiegers (Microsoft Press, 2006) Use Cases: Requirements in Context, 2 nd Ed., by Daryl Kulak and Eamonn Guiney (Addison-Wesley, 2003) 4 Sponsored By Agenda Use cases defined Benefits of the use case approach User classes and actors Scenarios and use cases Use case elicitation workshops Elements of a use case Use cases and functional requirements 5 Sponsored By Three Levels of Software Requirements Business Requirements Vision and Scope Document Business Rules User Requirements Quality Attributes Use Case Document External Interfaces Functional Requirements Constraints Software Requirements Specification 6 Sponsored By Eliciting Requirements Through Use Cases Use cases came from object-oriented world, apply to general requirements analysis. Provides a method to capture user requirements. Focus on actual, but abstracted, usage scenarios. Ask users: “Describe a goal you wish to accomplish with the system.” not: “What do you want the system to do?” Explore sequences of ‘actor’ actions and system responses. Derive functional requirements and tests from use cases. 7 Sponsored By What Use Cases Are and Are Not Definition : A description of a set of interaction sequences that a system performs to provide a result of observable or measurable value to one or more actors. Use cases describe: user goals the user’s view of the system a set of task-related activities Use cases do not describe: user interface designs technology solutions application architecture 8 Sponsored By Benefits from the Use Case Approach User-centric: user’s terminology is applied Task-centric: reveals requirements to get work done Helps analysts understand application domain Helps avoid building unnecessary functionality Permits early drafting of functional tests Helps set implementation priorities on functional requirements 9 Sponsored By Appropriate Use Case Applications Use cases work well for: end-user applications web sites devices with which users must interact Use cases aren’t as valuable for: batch processes computationally-intensive systems event-driven real-time systems 10 Sponsored By Examples of Use Cases Intuit QuickBooks “activities”: Write a Check Create an Invoice Enter Credit Card Charge Receive Payment Amazon.com options for an accepted order: Check Order Status Change Shipping Options Cancel Unshipped Items Track Package Buy a product online: Search Catalog Place Item in Shopping Cart Pay for Items in Shopping Cart 11 Sponsored By Naming Use Cases Name properties: reflect the actor’s goal from the actor’s perspective describe a valuable transaction Hi! My name is: be general enough to cover related scenarios Form: active verb + object “Generate Usage Report,” not “Usage Report Generation” use strong verbs and specific nouns Good Examples: Not So Good Examples: Reserve Rental Car Enter PIN Print Invoice Submit Form 37 Check Flight Status Process Deposit 12 Sponsored By User Classes and Actors User Classes: Distinct communities of users for the product. Actors: Entities outside the system that interact with it for the purpose of completing an event. User Classes Actors Account Owner Bank Customer Loan Applicant Depositor Chemist Technician Chemical Stockroom Staff Requester Lab Manager 13 Sponsored By Scenarios and Use Cases - 1 A scenario is: one specific path through a use case, or a story about a specific instance of a use case execution, perhaps with actual users identified and specific data Each use case typically includes multiple scenarios. could be successful or could be failure modes 14 Sponsored By Scenarios and Use Cases - 2 More Abstract Prepare a mailing label Prepare a mailing label to send a package by second- day UPS. Chris wants to send a 2.5-pound package by Less second-day UPS from Portland, OR, to Rochester, Abstract NY. She wants it insured for $75 and she wants a return receipt. The package is marked fragile. 15 Sponsored By Use Case Elicitation Workshop Use Case: View an order. Actor: Requester Frequency: 5/user/day Preconditions: system contains orders; user’s identity is verified Postconditions: order has been shown Actor Actions System Responses user enters order display order number he wants details to view user enters order error message: number, but it order number doesn’t exist not found etc. for all normal and exception pathways 16 Sponsored By Products from Use Case Analysis Draft SRS Verified SRS Draft Tests Verified Shared Models Vision Use Case Use Case Draft Models Workshops Descriptions Business Rules Data Dictionary 17 Sponsored By Use Case Template Use Case ID: Use Case Name: Created By: Last Updated By: Date Created: Date Last Updated: Actors: Description: Trigger: Preconditions: Postconditions: Normal Flow: Alternative Flows: Exceptions: Includes: Priority: Frequency of Use: Business Rules: Special Requirements: Assumptions: Notes and Issues: 18 Sponsored By Sample Use Case for an ATM - 1 Name: Withdraw Cash Actor: Account Owner Description: The user withdraws a specific amount of cash from a specified account. Trigger: Account Owner selects Withdrawal action. Preconditions: 1. The Account Owner is logged in to the ATM. 2. The Account Owner has at least one account with a positive balance. 3. The ATM contains cash. Postconditions: 1. The requested amount of cash has been dispensed. 2. The account balance is reduced by the amount withdrawn plus any fees. 3. The ATM cash balance is reduced by the amount withdrawn. Priority: High 19 Sponsored By Sample Use Case for an ATM - 2 Normal Flow: 1. System displays user’s accounts. 2. Account Owner selects desired account. 3. System asks user to choose amount to withdraw from a list. 4. Account Owner chooses amount to withdraw. 5. System dispenses cash. 6. Account Owner removes cash from dispenser. 20 Sponsored By Sample Use Case for an ATM - 3 Alternative Flows: at step 3, actor can choose to enter a custom amount describe where the branch takes place, what happens, and where the alternative flow rejoins the main flow Exceptions: amount is not a multiple of $20 amount exceeds daily withdrawal limit amount exceeds account balance amount exceeds cash available in ATM indicate the step number where the exception could take place and how the system handles it 21 Sponsored By Use Cases and Functional Requirements - 1 Two schools of thought: Use cases are the functional requirements. Use cases reveal the functional requirements. User View Developer View Use Cases Functional Requirements 22 Sponsored By Use Cases and Functional Requirements - 2 Precondition “The system shall verify that the account is set up for ATM withdrawals.” Steps in Flow “The system shall display a list of standard withdrawal amounts. The user shall select one of these amounts or ‘Other’.” Postcondition “The system shall reduce the total cash remaining in the ATM by the amount of the withdrawal.” Business Rule “The system shall print the available balance on the receipt, unless the account is a business account.” 23 Sponsored By Organizing Information: Use Case and SRS Use Case Organization SRS Organization Pre ~~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~~~~ Normal ~~~~~~~~~~~~ Flow ~~~~~~~~~~~~ ~~~~~~~~~ A ~~~~~~~~~ ~~~~~~~~~ ~~~~~~~~~ ~~~~~~~~~ E ~~~~~~~~~ Post ~~~~~~~~~~~~ ~~~~~~~~~~~~ Rules ~~~~~~~~~~~~ ~~~~~~~~~~~~ Other 24 Sponsored By The Use Case Technique: An Overview NONO NO SURPRISES! 25 Sponsored By Sponsor: RequirementOne Execute Karl’s recommendations TODAY! Get for your free 30 day trial www.requirementone.com Benefit from an hour with a requirements expert to make sure your next project goes like a dream! 26 Q & A 27 Sponsored By.
Load more

Recommended publications
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • Metamodeling Variability to Enable Requirements Reuse
    Metamodeling Variability to Enable Requirements Reuse Begoña Moros 1, Cristina Vicente-Chicote 2, Ambrosio Toval 1 1Departamento de Informática y Sistemas Universidad de Murcia, 30100 Espinardo (Murcia), Spain {bmoros, atoval}@um.es 2 Departamento de Tecnologías de la Información y las Comunicaciones Universidad Politécnica de Cartagena, 30202 Cartagena (Murcia), Spain [email protected] Abstract. Model-Driven Software Development (MDSD) is recognized as a very promising approach to deal with software complexity. The Requirements Engineering community should be aware and take part of the Model-Driven revolution, enabling and promoting the integration of requirements into the MDSD life-cycle. As a first step to reach that goal, this paper proposes REMM, a Requirements Engineering MetaModel, which provides variability modeling mechanisms to enable requirements reuse. In addition, this paper also presents the REMM-Studio graphical requirements modeling tool, aimed at easing the definition of complex requirements models. This tool enables the specification of (1) catalogs of reusable requirements models (modeling for reuse facet of the tool), and (2) specific product requirements by reusing previously defined requirements models (modeling by reuse facet of the tool). Keywords: Model-Driven Software Development (MDSD), Requirements Engineering (RE), Requirements MetaModel (REMM), Requirements Reuse, Requirements Variability. 1 Introduction Model-Driven Software Development (MDSD) aims at raising the level of abstraction at which software is conceived, implemented, and evolved, in order to help managing the inherent complexity of modern software-based systems. As recently stated in a Forrester Research Inc. study “model-driven development will play a key role in the future of software development; it is a promising technique for helping application development managers address growing business complexity and demand ” [1].
    [Show full text]
  • 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.
    [Show full text]
  • Practical Agile Requirements Engineering Presented to the 13Th Annual Systems Engineering Conference 10/25/2010 – 10/28/2010 Hyatt Regency Mission Bay, San Diego, CA
    Defense, Space & Security Lean-Agile Software Practical Agile Requirements Engineering Presented to the 13th Annual Systems Engineering Conference 10/25/2010 – 10/28/2010 Hyatt Regency Mission Bay, San Diego, CA Presented by: Dick Carlson ([email protected]) Philip Matuzic ([email protected]) BOEING is a trademark of Boeing Management Company. Copyright © 2009 Boeing. All rights reserved. 1 Agenda Boeing Defense, Space & Security| Lean-Agile Software . Introduction . Classic Requirements engineering challenges . How Agile techniques address these challenges . Overview / background of Agile software practices . History and evolution of Agile software Requirements Engineering . Work products and work flow of Agile Requirements Engineering . Integration of Agile software Requirements Engineering in teams using Scrum . Current status of the work and next steps Copyright © 2010 Boeing. All rights reserved. 2 Introduction Boeing Defense, Space & Security| Lean-Agile Software . A large, software-centric program applied Agile techniques to requirements definition using the Scrum approach . This presentation shows how systems engineering effectively applies Agile practices to software requirements definition and management . An experience model created from the program illustrates how failures on a large software program evolved into significant process improvements by applying specific Agile practices and principles to practical requirements engineering Copyright © 2010 Boeing. All rights reserved. 3 Requirements Reality Boeing Defense, Space & Security| Lean-Agile Software “The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, machines, and other software systems. No other part of the work so cripples the resulting system if done wrong.
    [Show full text]
  • 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
    [Show full text]
  • 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
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • Modeling System Requirements Using Use Cases and Petri Nets
    ICSEA 2016 : The Eleventh International Conference on Software Engineering Advances Modeling System Requirements Using Use Cases and Petri Nets Radek Koˇc´ıand Vladim´ır Janouˇsek Brno University of Technology, Faculty of Information Technology, IT4Innovations Centre of Excellence Czech Republic email: {koci,janousek}@fit.vutbr.cz Abstract—The fundamental problem associated with software executable form, which can then be tested and debugged. All development is a correct identification, specification and sub- changes that result from validation process are hard to transfer sequent implementation of the system requirements. To specify back into the models. It is a problem because the models requirement, designers often create use case diagrams from become useless over the development time. Unified Modeling Language (UML). These models are then developed by further UML models. To validate requirements, Similar work based on ideas of model-driven develop- its executable form has to be obtained or the prototype has to be ment deals with gaps between different development stages developed. It can conclude in wrong requirement implementations and focuses on the usage of conceptual models during the and incorrect validation process. The approach presented in this simulation model development process—these techniques are work focuses on formal requirement modeling combining the called model continuity [8]. While it works with simulation classic models for requirements specification (use case diagrams) models during design stages, the approach proposed in this with models having a formal basis (Petri Nets). Created models can be used in all development stages including requirements paper focuses on live models that can be used in the deployed specification, verification, and implementation.
    [Show full text]
  • Identify and Manage the Software Requirements Volatility Proposed Framework and Casestudy
    (IJACSA) International Journal of Advanced Computer Science and Applications, Vol. 7, No. 5, 2016 Identify and Manage the Software Requirements Volatility Proposed Framework and CaseStudy Khloud Abd Elwahab Mahmoud Abd EL Latif Sherif Kholeif MSc student /Information system Associate Professor of information Assistant Professor of information Department system department system Faculty of computers and Faculty of computers and Faculty of computers and information, Helwan University line information, Helwan University information, Helwan University 3: Cairo, Egypt Cairo, Egypt Cairo, Egypt Abstract—Management of software requirements volatility a framework focus on how to manage requirements volatility through development of life cycle is a very important stage. It during the software development life cycle and to limit the helps the team to control significant impact all over the project implications thereof. The remainder paper is structured as (cost, time and effort), and also it keeps the project on track, to follows: Section 2 presents the motivation to search for the finally satisfy the user which is the main success criteria for the requirements volatility topic. Section 3 explains the software project. requirements volatility definition, factors, causes, and the In this research paper, we have analysed the root causes of measures, and finally explains the impact of that on software requirements volatility through a proposed framework development process. Section 4 contains proposed framework presenting the requirements volatility causes and how to manage and presents a case study in explanation of the benefits of this requirements volatility during the software development life framework. Section 5 concludes our results and provides some cycle. Our proposed framework identifies requirement error types, open research directions causes of requirements volatility and how to manage these II.
    [Show full text]