Writing Effective Use Cases

download

of 49

  • date post

    01-Nov-2014
  • Category

    Technology
  • view

    12.053
  • download

    5

Embed Size (px)

description

Use-Case Writing

transcript

  • 1. Harsh Jegadeesans CLASSROOM EFFECTIVE USE-CASE WRITING BITS Pilani Off-Campus Work-Integrated Learning Programmes
  • 2. AGENDA Requirements Engineering What is a Use-Case? Sections in a Use-Case Goals & Scope of Use-Case 4 Steps to Use-Cases Supplementary Specification 2 9/22/2008 Object Oriented Analysis & Design
  • 3. ACKNOWLEDGEMENT This part of the lecture is based on: Integrated Requirements Engineering: A Tutorial Ian Sommerville, Lancaster University International Requirements Engineering Conference (RE 04). A copy of this could be got from: IEEE Software January- February 2005 3 9/22/2008 Object Oriented Analysis & Design
  • 4. MOTIVATION FOR REQUIREMENTS ENGINEERING Before any software system is developed: We must understand what the system is supposed to do How its use can support goals of individuals / organizations This involves: Understanding Application Domain Systems Operational Constraints Specific Functionality Required by stake-holders Essential characteristics like performance, security, reliability and dependability 4 9/22/2008 Object Oriented Analysis & Design
  • 5. WHAT IS REQUIREMENTS ENGINEERING? Requirements Engineering is the structured set of activities which: Help develop system understanding Identifying stake-holders and needs Document system specification for stake-holders and engineers involved Challenges: Numerous and distributed stake-holders Varying and conflicting goals Difficulties in Articulating these goals 5 9/22/2008 Object Oriented Analysis & Design
  • 6. RELATIVE COSTS OF FIXING SOFTWARE FAULTS 200 30 10 3 4 1 2 6 Requirements Specification Planning Design Implementation Integration Maintenance 9/22/2008 Object Oriented Analysis & Design
  • 7. THE FUNDAMENTAL PROCESS DISCLAIMER RE varies significantly with: - Size and type of the application developed - Size and Culture of the companies involved - The Software Acquisition Process For Instance, Large Military and Aerospace Projects Formal RE Small Companies RE is Brainstorming 7 9/22/2008 Object Oriented Analysis & Design
  • 8. THE RE ACTIVITY CYCLE 8 Courtesy: The Integrated Requirements Engineering: A Tutorial 9/22/2008 Object Oriented Analysis & Design
  • 9. ELICITATION Process: Identify sources of information about the system and discover requirements from these Identifying stakeholders & user classes Customers or Clients Developers Users - novice users, expert users, occasional users, disabled users Goals & Tasks Focus on Problem domain And needs of stakeholders 9 Scenarios & Use cases 9/22/2008 Object Oriented Analysis & Design
  • 10. ELICITATION -TECHNIQUES Elicitation Techniques Traditional techniques Questionnaires, surveys, interviews, documents Group elicitation techniques Prototyping Model-driven techniques Cognitive techniques Contextual techniques Need for guidance on use of these Techniques 10 9/22/2008 Object Oriented Analysis & Design
  • 11. THE RE ACTIVITY CYCLE Courtesy: The Integrated Requirements Engineering: A Tutorial 11 9/22/2008 Object Oriented Analysis & Design
  • 12. ANALYSIS Process: Understand the Requirements their overlaps and conflicts Enterprise Modeling Organizational Structure Business Rules Data Modeling Entity-Relationship-Attribute Behavioral Modeling Functional behavior of Stakeholders. Existing Required 12 9/22/2008 Object Oriented Analysis & Design
  • 13. ANALYSIS [2] Domain Modeling Abstract description of the world Advantage: Requirement reuse within a domain Advantage: detailed reasoning about the domain Modeling Non-Functional Requirement Difficult to measure and test Analyzing Requirement Models Requirement animation, automated reasoning 13 Knowledge based critique, consistency check 9/22/2008 Object Oriented Analysis & Design
  • 14. THE RE ACTIVITY CYCLE Courtesy: The Integrated Requirements Engineering: A Tutorial 14 9/22/2008 Object Oriented Analysis & Design
  • 15. VALIDATION Process: Go back to system stake-holders and find out whether requirements are what they really need A prototype may be needed to capture requirements depending on the software process that is followed. Validation of requirements could be done using a throw-away prototype or through incremental development 15 9/22/2008 Object Oriented Analysis & Design
  • 16. THE RE ACTIVITY CYCLE Courtesy: The Integrated Requirements Engineering: A Tutorial 16 9/22/2008 Object Oriented Analysis & Design
  • 17. NEGOTIATION Process: Inevitably, stakeholders views will differ, and proposed requirements might conflict. Try to reconcile conflicting views and generate a consistent set of requirements. Negotiation must be done using techniques like group discussions whereby all the stake-holders are in a common platform. This helps in the emergence of a clear holistic view from the stake- holders end. 17 9/22/2008 Object Oriented Analysis & Design
  • 18. THE RE ACTIVITY CYCLE Courtesy: The Integrated Requirements Engineering: A Tutorial 18 9/22/2008 Object Oriented Analysis & Design
  • 19. DOCUMENTATION AND MANAGEMENT Write down the requirements in a way that stakeholders and software developers can understand. Control the requirements changes that will inevitably arise. This leads to effective communication of requirements (Improving Requirements Engineering Communication in Multiproject Environments) 19 9/22/2008 Object Oriented Analysis & Design
  • 20.