SE 555 – Software Requirements & Specifications Introduction

Slides:



Advertisements
Similar presentations
Lecture # 2 : Process Models
Advertisements

Software Requirements
SE 555 Software Requirements & Specification1 Use-Case Modeling: Overview and Context.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
Analysis Stage (Phase I) The goal: understanding the customer's requirements for a software system. n involves technical staff working with customers n.
SE 555 Software Requirements & Specification Requirements Quality Attributes.
Software Requirements
Business Area Analysis Focus: Domain View (selected business area) Goals: –Isolate functions and procedures that allow the area to meet its goals –Define.
SE 555 Software Requirements & Specification 1 Overview of Requirements Engineering Activities.
SE 555 Software Requirements & Specification Requirements Validation.
Major Exam II Reschedule 5:30 – 7:30 pm in Tue Dec 5 th.
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
Introduction to Software Testing
S R S S ystem R equirements S pecification Specifying the Specifications.
Chapter 4 Capturing the Requirements 4th Edition Shari L. Pfleeger
1 College of Engineering and Computer Science Computer Science Department CSC 131 Computer Software Engineering Fall 2006 Lecture # 2 Chapter 6 & 7 System.
Requirements Elicitation. Requirement: a feature or constraint that the system must satisfy Requirements Elicitation: specification of the system that.
Software Engineering Week 9 – Brief Introduction of Requirement #1 A.A. Gde Bagus Ariana, S.T.
Topics Covered: Software requirement specification(SRS) Software requirement specification(SRS) Authors of SRS Authors of SRS Need of SRS Need of SRS.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 A Discipline of Software Design.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
An Introduction to Software Architecture
Software System Engineering: A tutorial
Business Analysis and Essential Competencies
Requirements Elicitation. Who are the stakeholders in determining system requirements, and how does their viewpoint influence the process? How are non-technical.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
Software Requirements Engineering: What, Why, Who, When, and How
1 CSE 403 Software Requirements Reading: Pragmatic Programmer Ch. 7: Before the Project These lecture slides are copyright (C) Marty Stepp, 2007, with.
Lecture 7: Requirements Engineering
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 05. Review Software design methods Design Paradigms Typical Design Trade-offs.
Historical Aspects Origin of software engineering –NATO study group coined the term in 1967 Software crisis –Low quality, schedule delay, and cost overrun.
Chapter 4 Software Requirements
Software Requirements: A More Rigorous Look 1. Features and Use Cases at a High Level of Abstraction  Helps to better understand the main characteristics.
Requirements Engineering Lesson 2. Terminologies:  Software Acquisition is where requirement engineering significantly meets business strategy.  Software.
1 Quality Attributes of Requirements Documents Lecture # 25.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
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 Introduction to Design. 2 Outline Basics of design Design approaches.
Software Engineering REQUIREMENT ENGINEERING. Software Engineering Phases.
Lecture 4: Requirements Engineering COSI 120b, Principles of Software Engineering.
System Requirements Specification
1 The Requirements Problem Chapter 1. 2 Standish Group Research Research paper at:  php (1994)
Software Requirements Specification Document (SRS)
Requirements Analysis
Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates.
Search Engine Optimization © HiTech Institute. All rights reserved. Slide 1 Click to edit Master title style What is Business Analysis Body of Knowledge?
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
1 CEN 4020 Software Engineering PPT4: Requirement analysis.
Software Engineering Lecture 10: System Engineering.
Requirement Discipline Spring 2006/1385 Semester 1.
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 Software Requirements Engineering (CS 708) Dr. Ghulam Ahmad Farrukh.
Introduction to Software Requirement Engineering Nisa’ul Hafidhoh Teknik Informatika
1 Software Requirements Descriptions and specifications of a system.
 System Requirement Specification and System Planning.
Requirements Introduction Emerson Murphy-Hill. Scope of Software Project Failures WHY PROJECTS FAIL % 1. Incomplete Requirements Lack of user involvement12.4.
Chapter 5 – Requirements Engineering
Rational Unified Process
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Requirements Analysis
Software Requirements Specification Document
Requirements Engineering Introduction
Software Engineering Furqan Rustam.
Introduction to Requirements Management
Software Engineering Lecture #3
Subject Name: SOFTWARE ENGINEERING Subject Code:10IS51
Presentation transcript:

SE 555 – Software Requirements & Specifications Introduction

What is Requirements Engineering? SE 555 Software Requirements & Specification

Requirements Engineering [DACS] SE 555 Software Requirements & Specification

SE 555 Software Requirements & Specification What is a Requirement? SE 555 Software Requirements & Specification

SE 555 Software Requirements & Specification What is a Requirement? A condition or capability needed by a user to solve a problem or achieve and objective. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. A documented representation of a condition or capability as in (1) or (2). See also: design requirement, functional requirement, implementation requirement, interface requirement, performance requirement, physical requirement. [IEEE-STD-610.12-1990 Software Engineering Glossary] SE 555 Software Requirements & Specification

SE 555 Software Requirements & Specification What is a Requirement? What the system should do and what it should not do Capabilities Constraints Does not deal with how the system does what it does (this is design) Requirements analysis involves some design decisions in order to organize, manage, and partition requirements Identify and separate functional elements and interfaces Applies architectural styles (layers, tiers, aspects, etc.) SE 555 Software Requirements & Specification

SE 555 Software Requirements & Specification What is a Requirement? A requirement describes a condition or capability to which a system must conform Either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document A desired feature, property, or behavior of a system Software requirement A specification of an externally observable behavior of the system For example, inputs to the system, outputs from the system, functions of the system, attributes of the system, or attributes of the system environment [RUP] SE 555 Software Requirements & Specification

What is a Specification? A document that specifies, in a complete, precise, verifiable manner, the requirements, design, behavior, or other characteristics of a system or component, and, often, the procedures for determining whether these provisions have been satisfied. See also:  formal specification, product specification, requirements specification [IEEE-STD-610.12-1990 Software Engineering Glossary] SE 555 Software Requirements & Specification

“Requirements” “Specification” Note: the term “Specifications” is often used as a shorthand for “Requirements Specifications” This is sloppy Based on the previous definitions, a specification is a carefully crafted formal document describing something.  A requirement is a need a system (or subsystem) must satisfy.   So, a requirements specification is a formal document describing the needs (requirements) a system or subsystem must satisfy.   A requirements specification is valid if it correctly (and completely and unambiguously and ...) captures the needs the system must satisfy. SE 555 Software Requirements & Specification

“Requirements” “Specification” A document that specifies the requirements for a system or component.  Typically included are functional requirements, performance requirements, interface requirements, design requirements, and development standards. Contrast with: design description. [IEEE-STD-610.12-1990 Software Engineering Glossary] SE 555 Software Requirements & Specification

Design Specification Design Description: A document that describes the design of a system or component. Typical contents include system or component architecture, control logic, data structures, input/output formats, interface descriptions, and algorithms. Syn: design document; design specification. Contrast with: requirements specification. [IEEE-STD-610.12-1990 Software Engineering Glossary] SE 555 Software Requirements & Specification

Characterizing Requirements: FURPS+ One way to categorize requirements: FURPS+ Functionality Usability Reliability Performance Supportability “+” Design constraints Implementation requirements Interface requirements Physical requirements Quality requirements “-ilities” Non-functional Requirements [RUP] SE 555 Software Requirements & Specification

Another Way to Characterize Requirements: CRUPIC STMPL Operational categories Capability Reliability Usability Performance Installability Compatibility Developmental categories Supportability Testability Maintainability Portability Localizability Customer and user requirements Mostly visible at run-time Developer and support requirements Mostly visible at build-time [RUP] SE 555 Software Requirements & Specification

Why Engineer Requirements? SE 555 Software Requirements & Specification

Why Engineer Requirements? The most significant contributors to project failure relate to requirements (Standish Group’s CHAOS Reports) Most projects fail Many fail utterly and completely Most failed projects fail due to changing customer requirements Meeting your project’s requirements defines success Not meeting them defines failure We can engineer a high probability of success “Project Engineering” SE 555 Software Requirements & Specification

Factors that Cause Projects to Fail Lack of User Input 12.8% Incomplete Requirements & Specifications 12.3% Changing Requirements & Specifications 11.8% Lack of Executive Support 7.5% Technology Incompetence 7.0% Lack of Resources 6.4% Unrealistic Expectations 5.9% Unclear Objectives 5.3% Unrealistic Time Frames 4.3% New Technology 3.7% Other 23.0% [Standish] SE 555 Software Requirements & Specification

SE 555 Software Requirements & Specification “The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, … No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.” [Brooks 1995] SE 555 Software Requirements & Specification

Software Requirements Knowledge Area (from SWEBOK 2001 version) Engineering Process Requirements Elicitation Requirements Analysis Requirements Specification Requirements Validation Requirements Management Process Models Process Actors Process Support and Management Process Quality and Improvement Requirements Sources Elicitation Techniques Requirements Classification Conceptual Modeling Architectural Design and Allocation Negotiation Requirements Definition Document Software Requirements Specification (SRS) Document Structure and Standards Document Quality Conduct Requirements Reviews Prototyping Model Validation Acceptance Tests Change Management Requirements Attributes Requirements Tracing SE 555 Software Requirements & Specification

Requirements Discipline in the Unified Process SE 555 Software Requirements & Specification

Requirements Discipline Workflow in RUP Focus on these SE 555 Software Requirements & Specification

Requirements Artifacts & Roles in RUP Focus on these SE 555 Software Requirements & Specification

Requirements Artifacts & Roles in RUP Focus on these SE 555 Software Requirements & Specification

What Will We Do In This Course? Learn some “systematic, disciplined, quantifiable approaches” to engineering of software requirements. SE 555 Software Requirements & Specification

What Will We Do In this Course? Understand requirements and their role in the context of software development Understand requirements engineering processes Study and practice various techniques for engineering requirements Elicitation Especially “Interaction Intensive” systems Specification Requirements models Use cases Extreme Programming stories, etc. Analysis Object-oriented analysis models Validation Review-based techniques Management As teams, review and develop requirements specifications As teams, study and present a topic in requirements engineering SE 555 Software Requirements & Specification