Requirements Analysis Going from “what” to “how”.

Slides:



Advertisements
Similar presentations
Inception: Starting a New Project Needs Features Vision.
Advertisements

System Modelling System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers. Different.
Mastering Object-Oriented Analysis and Design with UML Module 4: Analysis and Design Overview.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/18 Use Case Analysis – continued Control Classes.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
SE 555 Software Requirements & Specification1 Use-Case Modeling: Overview and Context.
Capturing the requirements
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models September 29, 2008.
Unified Software Practices v 5.0 Copyright  1998 Rational Software, all rights reserved 1 R Introduction to Rational Unified Process.
1 SWE Introduction to Software Engineering Lecture 5.
© Copyright Eliyahu Brutman Programming Techniques Course.
Use Case Analysis – continued
Object Oriented Analysis and Design Using the UML
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System modeling 1.
Domain-Specific Software Engineering Alex Adamec.
Unified Software Practices v 5.0-D Copyright  1998 Rational Software, all rights reserved 1 19 Chapter 2 Text Introduction to Rational Unified Process.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
The Software Development Life Cycle: An Overview
UML - Development Process 1 Software Development Process Using UML (2)
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
Rational Unified Process Fundamentals Module 4: Disciplines II.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions.
Requirements Analysis Visual Modeling] Lab 02 Visual Modeling (from Visual Modeling with Rational Rose and UML) A way of thinking about problems using.
CSC 480 Software Engineering OOAD Process. Topics Overview: OOAD Process The object model Identifying classes Responsibilities and collaborations Hierarchy:
Chapter 7 System models.
System models l Abstract descriptions of systems whose requirements are being analysed.
Pertemuan 19 PEMODELAN SISTEM Matakuliah: D0174/ Pemodelan Sistem dan Simulasi Tahun: Tahun 2009.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
Modeling Shari L. Pfleeger and Joanne M. Atlee, Software Engineering: Theory and Practice, 4 th edition, Prentice Hall, Hans Van Vliet, Software.
Systems Analysis and Design in a Changing World, 3rd Edition
Software Engineering, 8th edition Chapter 8 1 Courtesy: ©Ian Somerville 2006 April 06 th, 2009 Lecture # 13 System models.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
Unified Modeling Language* Keng Siau University of Nebraska-Lincoln *Adapted from “Software Architecture and the UML” by Grady Booch.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
Computing and SE II Chapter 9: Design Methods and Design Models Er-Yu Ding Software Institute, NJU.
Unified Software Practices v 5.0-D Copyright  1998 Rational Software, all rights reserved 1 Chapter 2 Text Introduction to Rational Unified Process.
J. Scott Hawker p. 1Some material © Rational Corp. Rational Unified Process Overview See and use the RUP Browser on lab machines.
Introduction to OOAD & Rational Rose cyt. 2 Outline RUP OOAD Rational Rose.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
1 Technical & Business Writing (ENG-715) Muhammad Bilal Bashir UIIT, Rawalpindi.
Introduction to Rational Unified Process
Lecture 14 22/10/15. The Object-Oriented Analysis and Design  Process of progressively developing representation of a system component (or object) through.
Rational Unified Process Fundamentals Module 3: Core Workflows I - Concepts Rational Unified Process Fundamentals Module 3: Core Workflows I - Concepts.
CS223: Software Engineering
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 4: Analysis and Design Overview.
Object Oriented Analysis and Design Introduction to Rational Rose.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
1 Architectural Blueprints—The “4+1” View Model of Software Architecture (
Modeling Shari L. Pfleeger and Joanne M. Atlee, Software Engineering: Theory and Practice, 4 th edition, Prentice Hall, Hans Van Vliet, Software.
OOAD Using the UML - Describe Concurrency, v 4.0 Copyright  Rational Software, all rights reserved 1 R Thread Process X Thread Process ZProcess.
From Use Cases to Implementation 1. Mapping Requirements Directly to Design and Code  For many, if not most, of our requirements it is relatively easy.
UML (Unified Modeling Language)
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
GOVT. ENGINEERING COLLEGE, AJMER. A SEMINAR PRESENTATION ON UNIFIED MODELING LANGUAGE(UML) SUBMITTED TO:-PRESENTED BY:- Dr. REENA DADHICHPALLAVI VASHISTHA.
Engineering, 7th edition. Chapter 8 Slide 1 System models.
Abstract descriptions of systems whose requirements are being analysed
Rational Unified Process
System models October 5, 2005.
Rational Rose 2000 Instructor Notes Use Case Realization Structure
Software Development Process Using UML Recap
Presentation transcript:

Requirements Analysis Going from “what” to “how”

Where are we? RUP phases and core workflows: We are here!

A Requirements Baseline means we have established, in the users language, a statement of the system functionality and operating constraints The Requirements Baseline SRS Business Vision / Roadmap Informal Requirements Feasibility/Cost Analysis Project Plans Requirements Analysis Contract(s) Customers Business Stakeholders QA Requirements Analysts ArchitectUsers Everybody depends on it!

Requirements Analysis Overview Requirements vs. Design  Comes down to “what” vs. “how”  In practice, your are placed under constraints from other stakeholders as to “how” - design constraints “restrictions on the design of a system, or the process by which a system is developed, that do not affect the external behavior of the system but that must be fulfilled to meet technical, business, or contractual obligations” (L&W, p. 241) Requirements Analysis a collection of activities whose objective is to provide a communicative model to bridge the chasm between business stakeholders and implementers. Many do not see the value, or consider as part of requirements specification!

Analysis, Architecture, and Design Problem:  How do we take requirements, expressed as the needs of a software system in a domain, and translate them into software products? Answer (version 1):  We give the requirements to our programmers and let them have at it! “Some amount of Magic happens…” Requirements Code

Analysis, Architecture, and Design Answer (version 2):  We create abstractions that allow us to map the complexity of the requirements to the space of software design Start with high-level analysis (initial design) Uncover architectural components and patterns Do more detailed design of each component Requirements Code “Let’s follow a top-down method”

Analysis, Architecture, and Design Answer (version 3):  “Instead of expending a lot of energy modeling the world, let’s rapidly build solutions to smaller, well- defined problems and integrate the results as we go up” “Let’s follow a Bottom-up approach first and integrate later”

Analysis, Architecture, and Design Answer (version 4):  “I want to do structured analysis and design, but I have a legacy set of components that I need to leverage as part of the solution.” Maps into analysis model legacycomponents

Example methods A LOT of analysis methods and notations exist  ER, DFD, Activity diagrams, Statecharts, OOA&D, UI analysis, stimulus-response, Petri nets, IDEF, PDL, Data Dictionaries, Zed, Jackson System Design (JSD), Axiomatic specifications, grammars, predicate logic, Event tables, MDA, Warnier diagrams, … Prevaling wisdom is that many models may be needed to express multiple perspectives  Examples: RUP 4+1 view of system architecture, analysis models Structured Analysis Method (SAM): Data, Behaviors, Flow XP: YAGNI!

RUP 4+1 View Model An architectural view is an abstraction of a system from a particular perspective covering particular concerns, and omitting entities that are not relevant to this perspective. Views are “slices” of models Process ViewDeployment View Logical View Use-Case View Implementation View End-user Functionality Programmers Software management Performance Scalability Throughput System integrators System topology Delivery, installation communication System engineering Analysts/Designers Structure

Analysis Methods Taxonomy Catalog of analysis modeling techniques:  Data/object models: Captures data in the given domain and relationships between them. Examples: Entity-Relationship, OOA&D, Data Dictionaries  Behavioral models: Captures system behaviors, states, and state transitions Examples: Use case models, statecharts, S-R  Flow models: Captures functional task flows and/or dataflows Examples: Process/workflow models (IDEF0), Dataflow diagrams (DFD), Sequence/Collaboration diagrams, Activity diagrams What about methods?  SAM, RUP, JSD  RUP example at end

Data Model Example: ER Description: “At Arizona State University, faculty members teach many students. Each faculty member has a unique employee tax ID, a rank, an assigned academic unit, name, , and phone number. Each student has a unique ASU ID number, a name, a year in school, a degree program, and an address. A faculty member teaches a student over the course of a given semester, identified by term and year (example: Fall 2010).” FacultyStudent teach (0,n) (1,n) TaxIDrankunitDegreeYearNameASUID FnameLname Name FnameLname

Behavioral Example: State Machines Applied accepted H rejected retired Hired Assistant Professor Tenured Professor maxPapers seniority Hiatus H takeSabbatical return Faculty Members 1.“Flat” SM Apply for Job 1.Add Applied State Which position? 1.Add Superstate 2.Add History Faculty on Sabbatical 1.Add external transition 2.Add History Tie up Lifecycle 1.Add final state

Flow Example: Dataflow Diagram Data that comes from outside the system is called a source. A sink is where data goes - a destination A conversion of data from one form to another - a processing element. Direction data travels, possibly with some indication of which data A place to put transient data for later use by the system Image Filter Convert Image New Image Histogram Pixel count Information Source or Sink Data Transform Information Flow Information Store

Class Diagrams Sequence Diagrams Use Case Collaboration Diagrams RUP Analysis: Use-Case Realization Use-Case ModelDesign Model Use CaseUse-Case Realization Object Oriented Analysis and Design Using the UML v2000 Copyright © 2000 Rational Software, all rights reserved

Example: RUP Analysis Classes The complete behavior of a use case has to be distributed to analysis classes Object Oriented Analysis and Design Using the UML v2000 Copyright © 2000 Rational Software, all rights reserved System boundary Use-case behavior coordination System information >  Does not have to be of one of these stereotypes  Focus on identifying responsibilities, not interface or method definitions