SE 555 – Software Requirements & Specificationsse555/Requirements Introduction.pdf · SE 555 – Software Requirements ... SE 555 Software Requirements & Specification ... Specification

SE 555 Software Requirements & Specification

SE 555 – Software Requirements & Specifications

Introduction


What is Requirements Engineering?


Requirements Engineering

[DACS]


What is a Requirement?



1. A condition or capability needed by a user to solve a problem orachieve and objective.

2. 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.

3. 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]



• 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.)



• 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]


What is a Specification?

• 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



“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.


“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.



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.



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-functionalRequirements

[RUP]


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]


Why Engineer Requirements?


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”


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]


“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]


Software Requirements Knowledge Area (from SWEBOK 2001 version)

Software Requirements

RequirementsEngineering

Process

RequirementsElicitation

RequirementsAnalysis

RequirementsSpecification

RequirementsValidation

RequirementsManagement

Process Models

Process Actors

Process Support and Management

Process Quality and Improvement

RequirementsSources

ElicitationTechniques

RequirementsClassification

ConceptualModeling

ArchitecturalDesign andRequirementsAllocation

RequirementsNegotiation

RequirementsDefinitionDocument

Software Requirements Specification (SRS)

Document Structure and Standards

Document Quality

Conduct Requirements Reviews

Prototyping

Model Validation

Acceptance Tests

Change Management

Requirements Attributes

Requirements Tracing


Requirements Discipline in the Unified Process


Requirements Discipline

Workflow in RUP

Focus on these


Requirements Artifacts & Roles in RUP

Focus on these


Requirements Artifacts & Roles in RUP

Focus on these


What Will We Do In This Course?

Learn some “systematic, disciplined, quantifiable approaches” to engineering of

software requirements.


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

Documents

SE 555 – Software Requirements & Specificationsse555/Requirements Introduction.pdf · SE 555 – Software Requirements ... SE 555 Software Requirements & Specification ... Specification