SOFTWARE REQUIREMENTS ENGINEERING

BY

KHAQAN ZAHEER
Requirement Specification
 SRS document is a contract between the
development team and the customer
 How do we communicate the Requirements to
others?
 Firm foundation and baseline for design phase and
latter phases
 Supportproject management and control evolution
of system
 Approximately 20-25% of the project time should
be allocated to requirement Specification
 SRS have different audiences(Technical and non-
technical)
Mapping Requirements to Specifications
Essentials for Writing Requirements
 Requirements are read more often than they are
written
 Readers of requirements come from diverse
backgrounds
 Writing clearly and concisely is not easy and is time
consuming and cost effective
 Different organizations write requirements at
different levels of abstraction
 Writing good requirements requires a analytic
thought
Activities of SRS
 Adopt SRS template
 Identify sources of requirements
 Uniquely label each requirement
 Record business rules
 Specify functional requirements
 Specify quality attributes
Specification Principles
 Separate functionality from implementation
 Develop model of desired behavior of the system
 Define the environment in which system operates
 Create a cognitive model
 Content & structure of a specifications should be
amenable to change
Appropriate Specification
 Consider two different projects:
 A) Tiny project, 1 programmer, 2 months work
 programmer talks to customer, then writes up
a 2-page memo
 B) Large project, 50 programmers, 2 years work
 team of analysts model the requirements, then
document them in a 500-page SRS
Project A Project B

Purpose of spec Crystallizes programmer’s Build-to document; must

understanding; feedback contain enough detail for
to customer all the programmers

Management view Spec is irrelevant; have Will use the spec to

already allocated estimate resource needs
resources and plan the
development
Benefits of SRS
 Reduce the development effort
 Forces the users to consider their specific requirements carefully
 Provide a basis for estimating costs and schedules
 Enhances communication between the Purchaser and System developers
 Provides a firm foundation for the system design phase
 Enables planning of validation, verification, and acceptance procedures
 Serve as a basis for enhancement requests
 Usable during maintenance phase
SRS Standards
 ANSI/IEEE SRS Standard 830-1984
 BS 6719: 1986
 European Space Agency Standards
 (ESA PSS-05-0, Jan 1987)
 US DoD-Std-7935A
 NASA Standard
 Canadian Standard(Z242.15.4-1979)
 Vlore Standard
 …………………
IEEE Standard
 Introduction
 General Description
 Specific Requirements
 Appendices
 Index
IEEE 830-1998 Standard –
Section 1 of SRS •Describe purpose of this SRS
•Describe intended audience

 Title
•Identify the software product
 Table of Contents •Enumerate what the system will and will not do
•Describe user classes and benefits for each
 1. Introduction
 1.1 Purpose
 1.2 Scope
 1.3 Definitions. Acronyms, and Abbreviations •Define the vocabulary of the SRS (may
 1.4 References reference appendix)

 1.5 Overview
•List all referenced documents including sources
 2. Overall Description (e.g., Use Case Model and Problem Statement; Experts in
the field)
 3. Specific Requirements
 Appendices
•Describe the content of the rest of the SRS
 Index •Describe how the SRS is organized
IEEE 830-1998 Standard –
Section 2 of SRS •Present the business case and operational concept of the system
• Describe how the proposed system fits into the business context
• Describe external interfaces: system, user, hardware, software,
 Title communication
• Describe constraints: memory, operational, site adaptation
 Table of Contents
 1. Introduction •Summarize the major functional capabilities
•Include the Use Case Diagram and supporting narrative
 2. Overall Description (identify actors and use cases)
•Include Data Flow Diagram if appropriate
 2.1 Product Perspective
 2.2 Product Functions •Describe and justify technical skills and
capabilities of each user class
 2.3 User Characteristics
 2.4 Constraints States assumptions about availability of certain
resources that, if not satisfied, will alter system
 2.5 Assumptions and Dependencies requirements and/or effect the design.
 3. Specific Requirements
 4. Appendices
 5. Index •Describe other constraints that will limit developer’s options;
e.g., regulatory policies; target platform, database, network
software and protocols, development standards requirements
IEEE 830-1998 Standard –
Section 3 of SRS (1)
Specify software requirements in sufficient
 … detail to enable designers to design a system to satisfy those
requirements and testers to verify
 1. Introduction requirements
 2. Overall Description State requirements that are externally perceivable by users,
 3. Specific Requirements operators, or externally connected systems

 3.1 External Interfaces Requirements should include, at a minimum, a description of

every input (stimulus) into the system, every output (response)
 3.2 Functions from the system, and all functions performed by the system in
 3.3 Performance Requirements response to an input or in support of an output

 3.4 Logical Database Requirements (a) Requirements should have characteristics of

high quality requirements
 3.5 Design Constraints
(b) Requirements should be cross-referenced to
 3.6 Software System Quality Attributes their source.
(c) Requirements should be uniquely identifiable
 3.7 Object Oriented Models (d) Requirements should be organized to
maximize readability
 4. Appendices
 5. Index
IEEE 830-1998 Standard –
Section 3 of SRS (2)
•Detail all inputs and outputs
 … (complement, not duplicate, information presented in section 2)
•Examples: GUI screens, file formats
 1. Introduction
 2. Overall Description
•Include detailed specifications of each use
 3. Specific Requirements case, including collaboration and other
 3.1 External Interfaces diagrams useful for this purpose

 3.2 Functions •Include:

a) Types of information used
 3.3 Performance Requirements b) Data entities and their relationships
 3.4 Logical Database Requirements
 3.5 Design Constraints •Should include:
a) Standards compliance
 3.6 Software System Quality Attributes b) Accounting & Auditing procedures
 3.7 Object Oriented Models
 4. Appendices •The main body of requirements organized in a variety of possible ways:
 5. Index a) Architecture Specification
b) Class Diagram
c) State and Collaboration Diagrams
d) Activity Diagram (concurrent/distributed)
Specification Techniques
 Informal Specifications
 Semi-formal ( graphical, tabular)
 Formal Specifications
 Algebraic approach
 The system is specified in terms of its operations
and their relationships
 Model-based approach
 The system is specified in terms of a state model
that is constructed using mathematical constructs
such as sets and sequences.
 Operations are defined by modifications to the
system’s state
Informal Specifications
 Textual descriptions and informal diagrams are easy for understanding
 These specifications are often ambiguous, imprecise and lengthy
 They lack support of abstraction and there is minimal or no automated
tool support for such specifications
Semi-Formal Specifications
 Most of the semiformal specifications are based on UML
 The specifications based on UML are supported by different tools
 They do not provide information on high level concepts such as intent,
usability and consequences
Formal Specifications
 Formal specification is part of a more general collection of techniques that
are known as formal methods
 Formal specification forces an very details analysis of the system
requirements at an early stage. Correcting errors at this stage is cheaper.
Formal methods include
Formal specification
Specification analysis and proof
Transformational development
Program verification
Specification in the software process
Requirements Formal
specification specification

Requirements High-level
definition design

System Architectural
modelling design
Development costs with Formal Specification

Cost Validation

Design and
Implementation Validation

Design and
Implementation
Specification

Specification

Without formal With formal

specification specification
What not to include in SRS
 Project development plans
 Staffing, Methods, Tools etc.
 Product quality assurance plans
 Configuration Management, Verification & Validation
 Designs information
 Requirements and designs have different audiences
Characteristics of good requirement
specification documents
 Complete
 Description of all major requirements relating to functionality, performance etc.
 Consistent
 A software requirement specification is consistent if none of the requirements
conflict
 Traceable
 Origin and all references are available
 Unambiguous
 Having two or more meanings
 Verifiable
 All requirements are verifiable

• Modifiable
 Should be flexible for modifications
Conclusion
 SRS have several purposes (Communication, Contractual, Verification,
Basis for change control)
 SRS have several audiences
 It is hard to write good specification
 Use standard templates for writing specifications
Papers
 IEEE Recommended Practice for Software
Requirements Specifications
 Software specification and design for imaging
systems
 Software Requirements Specification