Requirements Engineering Southern Methodist University CSE 7316 – Chapter 3.

Slides:



Advertisements
Similar presentations
Requirements Engineering Process
Advertisements

SWEN 5130 Requirements EngineeringSlide 1 Software Prototyping u Animating and demonstrating system requirements.
Chapter 4 Design Approaches and Methods
SECOND MIDTERM REVIEW CS 580 Human Computer Interaction.
Software Processes Coherent sets of activities for specifying, designing, implementing and testing software systems.
Alternate Software Development Methodologies
Case Tools Trisha Cummings. Our Definition of CASE  CASE is the use of computer-based support in the software development process.  A CASE tool is a.
Use-case Modeling.
Systems Analysis and Design in a Changing World, Fourth Edition
Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Overview of Software Requirements
IS550: Software requirements engineering Dr. Azeddine Chikh 4. Validation and management.
Lead Black Slide. © 2001 Business & Information Systems 2/e2 Chapter 13 Developing and Managing Information Systems.
Slides for: Software requirements - Styles and techniques Soren Lauesen 3. Functional requirement styles January 2007 Slides covered by the compendium.
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
Software Development, Programming, Testing & Implementation.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
Rapid Prototyping Model
Software Engineering 2003 Jyrki Nummenmaa 1 USE CASES In this lecture: Use cases - What are use cases? - Why to use use cases? - How to write.
1 Structured Analysis Techniques. 2 Data Flow Diagrams.
Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.
Chapter 8: Systems analysis and design
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Chapter 6 Requirements Engineering Process.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
Output and User Interface Design
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 8 Slide 1 Software Prototyping l Animating and.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa REQUIREMENT SPECIFICATION Today: Requirements Specification.
10/12/ Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 1. Interviews & questionnaires.
Use cases - a waste of time? Søren Lauesen, Februar 2010 IT-University of Copenhagen
Moving into Implementation SYSTEMS ANALYSIS AND DESIGN, 6 TH EDITION DENNIS, WIXOM, AND ROTH © 2015 JOHN WILEY & SONS. ALL RIGHTS RESERVED.Roberta M. Roth.
Requirements – Scenarios and Use Cases
Approaching a Problem Where do we start? How do we proceed?
Midterm Stats Min: 16/38 (42%) Max: 36.5/38 (96%) Average: 29.5/36 (78%)
Systems Life Cycle. Know the elements of the system that are created Understand the need for thorough testing Be able to describe the different tests.
Chapter 7 Software Engineering Introduction to CS 1 st Semester, 2015 Sanghyun Park.
7 Systems Analysis and Design in a Changing World, Fifth Edition.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 1: Introduction to Use-Case Modeling.
Discovering object interaction. Use case realisation The USE CASE diagram presents an outside view of the system. The functionality of the use case is.
Chapter 1 Applying UML and Patterns. The Need for Software Blueprints Knowing an object-oriented language and having access to a library is necessary.
SOFTWARE ENGINEERING MCS-2 LECTURE # 4. PROTOTYPING PROCESS MODEL  A prototype is an early sample, model or release of a product built to test a concept.
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
CMSC 345 Fall 2000 Requirements Overview. Work with customers to elicit requirements by asking questions, demonstrating similar systems, developing prototypes,
Chapter 4 Software Requirements
Systems Development Life Cycle
Software Prototyping Rapid software development to validate requirements.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Prof. Hany H. Ammar, CSEE, WVU, and
Requirements Analysis
Chapter 4 Requirements Engineering (1/3) Yonsei University 2 nd Semester, 2015 Sanghyun Park.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Requirements in the product life cycle Chapter 7.
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
Application Analysis. Application Interaction Model The purpose of analysis is to understand the problem so.
Dillon: CSE470: ANALYSIS1 Requirements l Specify functionality »model objects and resources »model behavior l Specify data interfaces »type, quantity,
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements (utvalgte foiler fra Kap 6 og 7 i Sommerville)
Requirements Analysis Requirements Engineering (CI 2323) Daniel Siahaan.
Bernd Bruegge and Allen Dutoit Requirements Process The requirements process consists of two activities: Requirements Elicitation: Definition of the system.
Overview of Standards and Guidelines
CMPE 280 Web UI Design and Development August 29 Class Meeting
Requirements Engineering Process
Chapter 5 유스케이스 개요 Introduction to Use Cases
Use Case Model.
Software acquisition and requirements SR3_Functions - except tasks
Software Prototyping Animating and demonstrating system requirements.
Design and Implementation
Lecture 23 CS 507.
Presentation transcript:

Requirements Engineering Southern Methodist University CSE 7316 – Chapter 3

Introduction Pervading issue of how work is divided between human and computer Decided through requirements No automatic way of identifying “correct” functions in the product Some creativity is required! Requirements engineer decides on functions/screens in the product and therefore much of the future human work

Context diagrams Show the product as a black box surrounded by user groups and external systems with which it communicates Arrows show how data flow between product and surroundings (transfer of data) Excellent overview of the required product interfaces Outline context diagram early in the project and keep updated during analysis

Advantages and disadvantages Verification; context diagram gives an overview of the interfaces and serves as a high level checklist Validation; most customers can readily understand the context diagram, spot missing interfaces, discuss what is delivered and what is outside the product

Event list and function list Events to be handled by the product (or a list of product functions) Events to be handled by human + computer (or a list of user tasks) Product events are design level issues Event is something that requests a system to perform some function (usually also has data) Domain events arrive at the domain from the surroundings Product events arrive at the product from the domain

Advantages and disadvantages Developers can easily check that each event/function on the list is supported or implemented May find it difficult to check whether all events are included Many variants in each event (which can be confusing) The event list for the UI is a design issue Lists may give you a false sense of security

Feature requirements Text form; the product shall record/show/compute.. Many people believe that this is the only acceptable type of requirement Can lead to a false sense of security for user and analyst Difficult to ensure that users are adequately supported and business goals covered

Advantages and disadvantages Validation; customers love features, they use the customers language Verification; straightforward to check that all the features are implemented in the final product (but time consuming) Easy to dream up too many features Hard to understand how that meet the business goals

Screens and prototypes Screen features and what the “buttons” do Excellent as design-level requirements if carefully tested Not suited for COTS based systems

A good user interface Careful analysis of the tasks to be supported Early prototypes, preferably as mockups Usability tests to see that the prototype actually allows typical users to perform all the tasks w/o assistance Several revisions of the prototype and new tests

Advantages and disadvantages Validation; customer can ensure that the screens are able to support the tasks and provide high usability Verification; straightforward to verify that the final user interface is an specified Don’t use this approach for COTS product Tasks must be well defined

Task descriptions Structured text describing user tasks Easy to understand for user as well as developer Easy to specify variants and complexity Simple to verify Domain level requirements, also suited for COTS

Task descriptions Task; what user and product do together to achieve some goal Use case; mostly the products part of the task Human task; user’s part of the task

Advantages Validation; customers find it easy to validate the task descriptions Trace to development; easy to see a screen supports a specific task Verification; checking the final system against the task descriptions Suitable for COTS Can specify complexity

Disadvantages No data specified Non-task activities Design is harder

Features from task descriptions Product features explained by means of task descriptions Improves understanding and validation of the features You can rarely guess user tasks from the features

Tasks and support Structured text describing tasks, domain problems, and possible support for them Identifies critical issues Discusses product features in a structured way Easy to understand for user as well as developer Easy specification of variants and complexity Simple to verify Domain level requirements

Advantages Easy to understand what customer really needs Possible to trace between requirements and business goals Supplier can specify advantages of solution by relating it to user tasks Supplier can also show where solution exceeds the customers expectations

Disadvantages No data specified, non-task activities More work for the supplier More work for the consumer Unusual reply format

Scenarios A case study illustrating one or more user tasks or a specific case to be tested Improves developer intuition Not requirements

Good tasks Closed task = meaningful user goal Check that you have identified all tasks Bundle small related tasks Don’t program the user dialog

High level tasks Total business cases as seen by the clients Independent of existing user tasks Idea generating – business process re- engineering (BPR) Rarely used as requirements