1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.

Slides:



Advertisements
Similar presentations
Tracing CS4310 Fall What is Requirements Traceability? The ability to describe and follow the life of a requirement throughout the system lifecycle,
Advertisements

CS 411W - Notes Product Development Documentation.
Software Requirements
Lecture 5: Requirements Specifications
8/28/2005ECEN5543 Req Elicitation1 Targets of Requirements Engineering ECEN 5543 SW Engineering of Standalone Programs University of Colorado, Boulder.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
1 SYSTEM and MODULE DESIGN Elements and Definitions.
Business Area Analysis Focus: Domain View (selected business area) Goals: –Isolate functions and procedures that allow the area to meet its goals –Define.
Introduction to Software Engineering Dr. Basem Alkazemi
SE 555 – Software Requirements & Specifications Introduction
1 Software Requirements Specification Lecture 14.
1 SOFTWARE LIFE-CYCLES Elements and Definitions. 2 Requirements System Design Detailed Design Implementation Installation & Testing Maintenance The WATERFALL.
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
S R S S ystem R equirements S pecification Specifying the Specifications.
Requirement engineering for an online bookstore system
Gregor v. Bochmann, University of Ottawa Based on Powerpoint slides by Gunter Mussbacher (2009) with material from: IEEE Standard, Daniel Amyot.
Software Requirement Specification(SRS)
Software Configuration Management
1 College of Engineering and Computer Science Computer Science Department CSC 131 Computer Software Engineering Fall 2006 Lecture # 2 Chapter 6 & 7 System.
The Software Development Life Cycle: An Overview
SOFTWARE REQUIREMENTS SPECIFICATION (SRS)
Lecture 18: Specifications
RUP Requirements RUP Artifacts and Deliverables
CS 4310: Software Engineering Lecture 3 Requirements and Design.
Software Requirements Specification (SRS) Complete description of external behavior of software system Complete description of external behavior.
Typical Software Documents with an emphasis on writing proposals.
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
Software System Engineering: A tutorial
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
Requirements Engineering How do we keep straight what we are supposed to be building?
ECE450 – Software Engineering II
Instructor: Peter Clarke
1 Lecture 5.2.b: Requirements Specifications (IEEE 830) Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
Standard SRS Copyright, 2001 © Jerzy R. Nawrocki Requirements Engineering Lecture.
Software Requirements Engineering CSE 305 Lecture-2.
Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa REQUIREMENT SPECIFICATION Today: Requirements Specification.
IT Requirements Management Balancing Needs and Expectations.
Some Sub-Activities within Requirements Engineering 1.Prototyping 2.Requirements Documentation 3.Requirements Validation 4.Requirements Measurements 5.Requirements.
Lecture 7: Requirements Engineering
KS3 Phase4 Client Server Monitoring System October 1, 2008 by Stephen, Seema, Kam, Shpetim.
1 15 quality goals for requirements  Justified  Correct  Complete  Consistent  Unambiguous  Feasible  Abstract  Traceable  Delimited  Interfaced.
Requirement Handling
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
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.
(SRS) SOFTWARE REQUIREMENT SPECIFICATION(SRS) 1. Topics to be discussed.. What is an SRS? Purpose of an SRS Who reads the SRS? Who writes the SRS? Characteristics.
1 Quality Attributes of Requirements Documents Lecture # 25.
OHTO -01 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
1. The Requirements Process Requirements Input Example
Smart Home Technologies
System Requirements Specification
Software Requirements Specification Document (SRS)
CSC480 Software Engineering Lecture 7 September 16, 2002.
Software Engineering Lecture 10: System Engineering.
SwCDR (Peer) Review 1 UCB MAVEN Particles and Fields Flight Software Critical Design Review Peter R. Harvey.
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.
Requirement Specification SRS document is a contract between the development team and the customer How do we communicate the Requirements to others? Firm.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements (utvalgte foiler fra Kap 6 og 7 i Sommerville)
 System Requirement Specification and System Planning.
An Overview of Requirements Engineering Tools and Methodologies*
Requirements Analysis Scenes
IT 440: SYSTEM INTEGRATION
CSC480 Software Engineering
System Requirements Specification
Chapter 6: Principles of Requirements Analysis
Requirements Document
Requirement Analysis.
Requirements Engineering Lecture 6
Presentation transcript:

1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions

2 Requirements System Design Detailed Design Implementation Installation & Testing Maintenance Software Requirements Specification - SRS

3 Who does requirements engineering? requirements engineer customer system designer

4 What are the activities? problem analysis product description “complete” understanding of requirements consistent SRS customer needs

5 Problem Analysis: –understand the problem (space) –expand information –specify constraints: find them analyze them resolve conflicts –specify the solution space Product Description: –describe the problem –compress information –set limits: constraints assumptions –check completeness consistency

6 Levels of Software Requirements Business Needs Business Rules System Requirements Constraints- e.g., standards, architecture Customer Satisfaction User Satisfaction Tester Support Developers Support Vision & Scope Document Business Requirements Quality Attributes Use Case Document Software Requirements Specification User Requirements Functional Requirements Other Extra-functional Requirements User Expectations

7 Components of Requirements Engineering Requirements Engineering Requirements Management Requirements Development Elicitation Analysis Modeling & Specification Verification & Validation Change Control Version Control Tracing Status Tracking

8 Typical Methods & Techniques interviews hands-on experience documentation analysis scenarios (formal) description completeness and consistency checking conflict resolution techniques

9 The Product: SRS Standards: –IEEE / ANSI –DoD 2167A / DI-MCCR-80025A (SRS) –NASA SFW-DID-08 (SRS) –company internal standards?

10 Elements of an SRS user goals context description behavioral/functional requirements non-behavioral/extra-functional requirements constraints assumptions ===> WHAT

11 NOT included in an SRS: project management design information quality assurance plans staffing cost analysis ===> HOW

12 An SRS should be: correct non-ambiguous complete verifiable consistent understandable modifiable traceable annotated ===> formal vs. informal requirements specification

13 IEEE Std Introduction 1.1 Purpose of SRS 1.2 Scope of product 1.3 Definitions, acronyms, abbreviations 1.4 Overview

14 IEEE Std General description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 General constraints 2.5 Assumptions and dependencies

15 IEEE Std Specific requirements 3.1 Functional requirements 3.2 External interface requirements 3.3 Performance requirements 3.4 Design constraints 3.5 Attributes 3.6 Other requirements Alternatives!

16 End of Section 2a coming up: Data Flow Diagrams