SE 555 Software Requirements & Specification Requirements Analysis.

Slides:



Advertisements
Similar presentations
Chapter 7 Structuring System Process Requirements
Advertisements

Chapter 4 Enterprise Modeling.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
Communication Notation Part V Chapter 15, 16, 18 and 19.
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
PROCESS MODELING Transform Description. A model is a representation of reality. Just as a picture is worth a thousand words, most models are pictorial.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models September 29, 2008.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Systems Analysis and Design in a Changing World, 6th Edition
Use Case Analysis – continued
Chapter 7 Structuring System Process Requirements
6 Systems Analysis and Design in a Changing World, Fourth Edition.
Traditional Approach to Requirements Data Flow Diagram (DFD)
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 6: The Traditional Approach to Requirements
System Analysis Overview Document functional requirements by creating models Two concepts help identify functional requirements in the traditional approach.
Systems Analysis and Design in a Changing World, Fifth Edition
The Traditional Approach to Requirements
Chapter 6 The Traditional Approach to Requirements
Systems Analysis and Design in a Changing World, Fifth Edition
Lesson 7 Guide for Software Design Description (SDD)
Typical Software Documents with an emphasis on writing proposals.
Implementation Yaodong Bi. Introduction to Implementation Purposes of Implementation – Plan the system integrations required in each iteration – Distribute.
ANALYSIS REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 7 Structuring System Process Requirements
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.
ITEC224 Database Programming
ITEC 3220M Using and Designing Database Systems
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions.
Programming in Java Unit 3. Learning outcome:  LO2:Be able to design Java solutions  LO3:Be able to implement Java solutions Assessment criteria: 
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.
6 Systems Analysis and Design in a Changing World, Fifth 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.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Source: Peter Eeles, Kelli Houston, and Wojtek Kozaczynsky, Building J2EE Applicationa with the Rational Unified Process, Addison Wesley, 2003 Prepared.
Requirements Capture. Four Steps of requirements capture List candidate requirements Understand system context Capture functional requirements Capture.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
1 6 Systems Analysis and Design in a Changing World, 2 nd Edition, Satzinger, Jackson, & Burd Chapter 6 The Traditional Approach to Requirements.
A Use Case Primer 1. The Benefits of Use Cases  Compared to traditional methods, use cases are easy to write and to read.  Use cases force the developers.
Lecture 4 Conceptual Data Modeling. Objectives Define terms related to entity relationship modeling, including entity, entity instance, attribute, relationship,
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
Business Analysis with For PG MDI, Gurgaon Kamna Malik, Ph.D.
Unified Modeling Language User Guide Section 4 - Basic Behavioral Modeling Chapter 16 - Use Cases Chapter 17 - Use Case Diagrams.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
1 Technical & Business Writing (ENG-715) Muhammad Bilal Bashir UIIT, Rawalpindi.
Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich.
Analysis Yaodong Bi. Introduction to Analysis Purposes of Analysis – Resolve issues related to interference, concurrency, and conflicts among use cases.
UML - Development Process 1 Software Development Process Using UML.
UML Course Instructor: Rizwana Noor. Overview  Modeling  What is UML?  Why UML?  UML Diagrams  Use Case  Components  Relationships  Notations.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
Main tasks of system analysis ? 1-study exit=sting information system 2-identify problem 3-spelify system requirement 4-asalysis decision ========= How.
6 Systems Analysis and Design in a Changing World, Fourth Edition.
Your Interactive Guide to the Digital World Discovering Computers 2012 Chapter 12 Exploring Information System Development.
© 2005 by Prentice Hall Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
1 Requirements Analysis Lecture # Recap of Requirements Elicitation - 1 Requirements elicitation deals with discovering requirements for a software.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1 Use Case Analysis – Part 4 Analysis Mechanisms.
Process Modeling Graphically represent the processes that capture, manipulate, store, and distribute data between a system and its environment Models DFDs.
Systems Analysis and Design in a Changing World, Fourth Edition
Chapter 6 The Traditional Approach to Requirements.
Unified Modeling Language
Abstract descriptions of systems whose requirements are being analysed
Software Development Process Using UML Recap
Presentation transcript:

SE 555 Software Requirements & Specification Requirements Analysis

SE 555 Software Requirements & Specification Goals of Requirements Analysis Create requirements containing sufficient detail and of high enough quality to allow realistic project planning as well as successful design and implementation. Scrutinize requirements for errors, conflicts, omissions and boundaries.

SE 555 Software Requirements & Specification Requirements Analysis Practices Analyze feasibility Allocate requirements to subsystems Create prototypes where necessary Model the requirements Prioritize the requirements Define system boundaries and interfaces Create consistent data definitions

SE 555 Software Requirements & Specification Requirements Analysis Checklist Premature Design – Does the requirement include premature design or implementation information? Combined Requirements – Does the description of a requirement describe a single requirement or could it be broken down into several different requirements? Unnecessary Requirements – Is the requirement “gold plating”? That is, is the requirement a cosmetic addition to the system which is not really necessary. Use of Non-standard Components – Does the requirement mean that non-standard hardware or software must be used?

SE 555 Software Requirements & Specification Requirements Analysis Checklist – cont’d Conformance with Business Goals – Is the requirement consistent with the business goals defined in the introduction to the requirements document/ Requirements Ambiguity – Is the requirement ambiguous i.e. could it be read in different ways by different people? Requirements Realism – Is the requirement realistic given the technology which will be used to implement the system? Requirements Testability – Is the requirement testable? Is it stated in such a way that a test can be derived to show if the system meets the requirement?

SE 555 Software Requirements & Specification Requirements Analysis Artifacts System Boundaries – Context Diagram Requirements Modeling – Class Diagrams, Activity State Diagrams, Interaction Diagrams, Sequence Diagrams, Data Flow Diagrams, Entity-Relationship Diagrams Data Definition – Data Dictionary Requirements Priority – Prioritization Matrix Requirements Definition, Risk Mitigation, Feasibility – Prototypes

SE 555 Software Requirements & Specification Context Diagram - Purpose Highlights the boundary between the system and the outside world. Highlights the people, organizations, and outside systems that interact with the system under development. Special case of the data flow diagram.

SE 555 Software Requirements & Specification Context Diagram - Notation Process - Represents the proposed system Terminator - Represents the external entities Flow - Represents the in and out data flows

SE 555 Software Requirements & Specification Context Diagram - Example Credit Card Processing Customer Collection Company Corporate Accounting System Store Customer Service Application Bills Payment Transaction Payment Overdue Accounts Credit Account Summary

SE 555 Software Requirements & Specification Use-Case Analysis Use-case analysis is where the requirements meet object-orientation Recall: in the Unified Process, the use-case model is the primary artifact in the requirements model In use-case analysis, identify the classes which perform a use-case flow of events Distribute the use-case behavior to those classes Identifying the responsibility of the classes Develop use case realizations that model the collaborations between instances of the identified classes How the class instances work together to deliver the requirements The result is a first-draft, rough-cut of the system object model An abstraction of the design model; refined during design

SE 555 Software Requirements & Specification Use-Case Analysis - Steps Supplement the Use-Case Description For each use-case realization Find classes from use-case behavior Distribute use-case behavior to classes For each resulting analysis class Describe responsibilities Describe attributes and associations Qualify architectural analysis mechanisms Unify analysis classes Checkpoints

SE 555 Software Requirements & Specification Analysis Classes: A First Step Towards Executables Use-CasesAnalysis Classes Design Elements Source Code Executables Use-Case Analysis

SE 555 Software Requirements & Specification Data Flow Diagram - Purpose Provides a means for functional decomposition. Primary tool in analysis to model data transformation in the system.

SE 555 Software Requirements & Specification Data Flow Diagram - Notation Represents the external entities that the System communicates with Represents data flows Represents functions in the system (transforms Inputs into Outputs) Represents data stores (a collection of data at “rest”)

SE 555 Software Requirements & Specification DFD Example from Text

SE 555 Software Requirements & Specification Data Dictionary A repository that defines the data elements or attributes used in the system It is not the project glossary Makes it easy to find info about the data Avoids redundancy and maintenance issues, over being in various func. req. Have it as an appendix in your SRS (project)

SE 555 Software Requirements & Specification DD Notation Primary data element Where an element does not need or require further decomposition Defined with a comment * text * Data type, size, range of values etc. are presented. Composition: + Used to show multiple data items Optional items are enclosed in () Iteration: min:max {item} Used to show that mult instances of an item can appear Selection: [item | item] When a data element can be of a set of discrete values

SE 555 Software Requirements & Specification DD Examples Customer Name Phone Number

SE 555 Software Requirements & Specification DD Notation Entry comprised of: (and listed in alphabetical order) Name: its name Aliases: if it goes by another name as well Used in: the use cases it is present in, by id and name Description: the notation goes here Notes: any special notes about it

SE 555 Software Requirements & Specification Entity Relationship Diagram (ERD) - Purpose A graphical representation of the data layout of a system at a high level of abstraction. Defines data elements and their inter-relationships in the system.

SE 555 Software Requirements & Specification Entity Relationship Diagram - Text Example