CMPT 275 Software Engineering

Slides:



Advertisements
Similar presentations
CMPT 275 Software Engineering
Advertisements

Evaluating Requirements. Outline Brief Review Stakeholder Review Requirements Analysis Summary Activity 1.
Information System Design IT60105 Lecture 3 System Requirement Specification.
© Janice Regan, CMPT 102, Sept CMPT 102 Introduction to Scientific Computer Programming The software development method algorithms.
1 / 26 CS 425/625 Software Engineering Software Requirements Based on Chapter 5 of the textbook [Somm00] Ian Sommerville, Software Engineering, 6 th Ed.,
CS 425/625 Software Engineering Software Requirements
1 CS 425 Software Engineering Project Preparation Use Case Modeling [Based on Chapters 3 & 4, Arlow and Neustadt, “UML and the Unified Process,” Addison-Wesley,
Software Requirements
1 Software Requirements Specification Lecture 14.
Software engineering Olli Alm Lecture 2: requirements, modelling & representation.
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
Software Requirement Specification(SRS)
1 CMPT 275 Software Engineering Requirements Analysis Phase Overview of Requirements Analysis Activity System Context Diagrams.
CMPT 275 Software Engineering
CMPT 275 Software Engineering
CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Tuesday Class will start momentarily. Please Stand By … CS 8532: Advanced Software.
The Software Development Life Cycle: An Overview
Requirements Elicitation. Requirement: a feature or constraint that the system must satisfy Requirements Elicitation: specification of the system that.
Project Analysis Course ( ) Week 2 Activities.
Typical Software Documents with an emphasis on writing proposals.
1 CMPT 275 Software Engineering Software life cycle.
1 Phases in Software Development Lecture Software Development Lifecycle Let us review the main steps –Problem Definition –Feasibility Study –Analysis.
Topics Covered: Software requirement specification(SRS) Software requirement specification(SRS) Authors of SRS Authors of SRS Need of SRS Need of SRS.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
1 REQUIREMENT ENGINEERING Chapter 7. 2 REQUIREMENT ENGINEERING Definition Establishing what the customer requires from a software system. OR It helps.
ITEC224 Database Programming
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Class Project OO Design Document Here is what you need to do for your class.
 Explain the role of a system analyst.  Identify the important parts of SRS document.  Identify the important problems that an organization would face.
1 CMPT 275 Phase: Design. Janice Regan, Map of design phase DESIGN HIGH LEVEL DESIGN Modularization User Interface Module Interfaces Data Persistance.
1 CMPT 275 Software Engineering Requirements Analysis Phase Requirements Analysis Activity (Identifying Objects, Scenarios) Janice Regan,
1 CMPT 275 Software Engineering Requirements Gathering Activity Janice Regan,
Deliverable #9 – Detail Design Subsystem Design and Realization ALL of your design class model elements must have the package or subsystem they are associated.
Requirement Elicitation Process Lesson 3. Requirements Elicitation  Is the process to find out the requirements for an intended software system by communicating.
1 CMPT 275 Software Engineering Requirements Analysis Phase Requirements Analysis activity Janice Regan,
CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Class Project OO Design Document Here is what you need to do for your class project.
CS 4850: Senior Project Fall 2014 Object-Oriented Design.
1 15 quality goals for requirements  Justified  Correct  Complete  Consistent  Unambiguous  Feasible  Abstract  Traceable  Delimited  Interfaced.
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
1 CMPT 275 High Level Design Phase Modularization.
Capturing the requirements  Requirement: a feature of the system or a description of something the system is capable of doing in order to fulfill the.
Requirements Engineering Lesson 2. Terminologies:  Software Acquisition is where requirement engineering significantly meets business strategy.  Software.
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
Systems Development Life Cycle
1 Quality Attributes of Requirements Documents Lecture # 25.
1 Chapter 8 Building the Analysis Model (1) Analysis Concepts and Principles.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
System Requirements Specification
Evaluating Requirements
Software Requirements Specification Document (SRS)
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
CSIS 4850: CS Senior Project – Spring 2009 CSIS 4850: Senior Project Spring 2009 Object-Oriented Design.
Software Engineering, COMP201 Slide 1 Software Requirements BY M D ACHARYA Dept of Computer Science.
1 Unified Modeling Language Michael K. Wildes University of California, Riverside – Extension Program Presentation 2.
Documenting Software Architectures. Outline  Introduction  Uses of Architectural Documentation  Views  Choosing the Relevant Views  Documenting a.
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
Requirements. Outline Definition Requirements Process Requirements Documentation Next Steps 1.
1 Use Cases Object-Oriented Modeling and Design with UML (Second Edition) Blaha & Rumbaugh Sections 7.1, 8.1.
Bernd Bruegge and Allen Dutoit Requirements Process The requirements process consists of two activities: Requirements Elicitation: Definition of the system.
CMPE 280 Web UI Design and Development August 29 Class Meeting
Prepared by Rand E Winters, Jr. ASR Senior Auditor October 2014
Requirements Elicitation and Elaboration
Software Engineering Summarized Slides.
The Process of Object Modeling
Requirements Analysis
CS 8532: Advanced Software Engineering
Object-Oriented Software Engineering
CS 425 Software Engineering
CS 425/625 Software Engineering
Presentation transcript:

CMPT 275 Software Engineering Requirements Analysis Phase Requirements Specification Activity

Project: Requirements Analysis You will be using an object oriented paradigm for your class project Informal scenarios will be used to help you derive your software requirements specifications Janice Regan, 2008

Requirements Gathering/Specification 6 1 Project Description 2 Client/User Software Developer 5 Questions 4 8 Informal Scenarios 3 7 4 8 Requirements Specification Document 3 7 4 Client meeting Janice Regan, 2008 Client requirements review meeting 8

Project: Requirements Analysis Requirements gathering and specification will allow you to build an ‘analysis model’. This model represents the user’s/client’s view of the system You will end up with a list of functional requirements. Each requirement will represent one function/activity This is your ‘analysis model’ Functional requirements are not dependent on specific methods of implementation Janice Regan, 2008

Project: Requirements Analysis Your list of functional requirements will Describe the required interactions between the system and its environment (independent of implementation) You will also need a list of non-functional requirements QUALITY REQUIREMENTS: Usability, reliability, performance, maintainability CONSTRAINTS or PSEUDO REQUIREMENTS: Implementation (tools, languages), interface (to external systems), operation (admin, management), packaging, Legal Janice Regan, 2008

Project: Requirements Analysis You requirements must be Complete: all required features must be described Consistent: no two requirements in the specification may contradict each other Unambiguous: no requirement can be interpreted in two different and contradictory ways Correct: Only features desired by the client / developer are included not unintended extra features (problems) Janice Regan, 2008

Project: Requirements Analysis Later you will proceed using use case centered development (UCCD) to analyze your requirements and assure that they are complete consistent, unambiguous and correct System context diagram Identifying actors Identifying Primary classes (initial analysis objects) Identifying Scenarios and Use Cases Identifying Relationships between use cases and actors. Using these relationships to build the use case diagram Identifying relationships between classes and building a Class (object) diagram Janice Regan, 2008

Project Deliverable #2 - #4 Deliverable #2 is a partial Requirements Specification Document, version 1 Deliverable #3 is a “client requirements review" done with your client Deliverable #4 is a completed System Requirements Specification (SRS) Janice Regan, 2008

Steps in requirements analysis - 1 For your project Clarify requirements in your first client meeting Write a list of requirements in the needed format (discussed later), to be included in deliverable 2 Begin your requirements analysis based on the list of requirements you made for deliverable 2 Your requirements analysis will be added to the SRS you submitted as deliverable 2 (remember to update your revision history and requirements) to give the SRS you will submit as deliverable 4 Janice Regan, 2008

Steps in requirements analysis - 2 For your project Your requirements analysis will also help you to determine a list of more detailed questions and a list of use cases you can use to explain the context of those questions Your requirements review meeting will allow your group to present the use cases you developed and ask the related detailed questions Use the information you discover in the requirements review meeting to update the requirements analysis already added to your SRS before submitting your SRS as deliverable 5 Janice Regan, 2008

SRS format for your term project - 1 Cover Page 2 Revision History 2 Table of contents 2 Requirements Specification 2 Functional Requirements Prioritization of Functional Requirements Non-Functional Requirements (numbers indicate first deliverable in which the contents of the section are included.) Janice Regan, 2008

SRS format for your term project - 2 Requirements Analysis Scenarios (not “informal scenarios”) 4 Use Cases 4 Use Case diagram 4 Class diagram 4 User Interface Description 4 All sections prepared in deliverable 3 must be updated as necessary and included in deliverable 5 Janice Regan, 2008

Requirements Specification Format: Requirements specifications are given in a structured format requirements are numbered. Finer details are shown as subsections Finer details within subsections are shown as subsections of subsections ... Functional and non-functional requirements are listed separately. Both lists use the same format. For your term project you will compile a detailed list of functional and a detailed list of non-functional requirements using this format. These lists can then be checked for traceability. Janice Regan, 2008

List of Requirements The requirements you discover become part of a document Documents are important, so you can refer to them and so new members and other members can refer to them The software engineering document that includes the project requirements is usually called the Software Requirements Specification Document or SRS Janice Regan, 2008

An example system A system that manages an election The system tabulates the votes that the voters have cast The system determines who has won the election The system archives information about candidates (people competing in the election), and about people managing the election Janice Regan, 2008

Example: Functional Requirements Update Riding Information 1.1 An election official can update any or all of the following information for any chosen riding: 1.1.1 The names of a candidate 1.1.1.1 The party affiliations of that candidate 1.1.2 A map of the riding 1.1.3 The number of eligible voters in the riding 1.1.4 The number of representatives for the riding 1.2 An elections official will update one riding at a time 1.3 An elections official may preview her changes before saving them in the riding repository Janice Regan, 2008

Format for your SRS Please use the format on the previous slide for the requirements in your SRS Janice Regan, 2008

Clarifying the Requirements: Other questions need to be answered to specify detailed requirements. For example: What sort of Human computer interface is needed? Are there any other pieces of data that need to be recorded or updated? What is the maximum number of candidates in a riding? Can the same candidate run in more than one riding? And so on Answers to such questions may raise additional questions so this is by nature an iterative process Janice Regan, 2008