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