1. SE 555 – Software Requirements & Specifications Introduction

2. What is Requirements Engineering?
SE 555 Software Requirements & Specification

3. Requirements Engineering
[DACS]
SE 555 Software Requirements & Specification

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

5. 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 Software Engineering Glossary]
SE 555 Software Requirements & Specification

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

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

8. 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 Software Engineering Glossary]
SE 555 Software Requirements & Specification

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

10. “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 Software Engineering Glossary]
SE 555 Software Requirements & Specification

11. 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 Software Engineering Glossary]
SE 555 Software Requirements & Specification

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

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

14. Why Engineer Requirements?
SE 555 Software Requirements & Specification

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

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

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

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

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

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

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

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

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

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