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
 Support project 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
Project A Project B
 team of analysts model the requirements, then
document themCrystallizes
Purpose of spec in a 500-page
programmer’s SRS
understanding; feedback
Build-to document; must
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

•Identify the software product

 Title •Enumerate what the system will and will not do
•Describe user classes and benefits for each
 Table of Contents
 1. Introduction
 1.1 Purpose
 1.2 Scope •Define the vocabulary of the SRS
(may reference appendix)
 1.3 Definitions. Acronyms, and Abbreviations
 1.4 References •List all referenced documents including sources
 1.5 Overview (e.g., Use Case Model and Problem Statement; Experts
in the field)
 2. Overall Description
 3. Specific Requirements •Describe the content of the rest of the SRS
•Describe how the SRS is organized
 Appendices
 Index
IEEE 830-1998 Standard – •Present the business case and operational concept of the system
• Describe how the proposed system fits into the business context

Section 2 of SRS • Describe external interfaces: system, user, hardware, software, communication
• Describe constraints: memory, operational, site adaptation

•Summarize the major functional capabilities

 Title •Include the Use Case Diagram and supporting narrative
(identify actors and use cases)
 Table of Contents •Include Data Flow Diagram if appropriate
 1. Introduction
 2. Overall Description •Describe and justify technical skills and
capabilities of each user class
 2.1 Product Perspective
 2.2 Product Functions
States assumptions about availability of certain
 2.3 User Characteristics resources that, if not satisfied, will alter system
requirements and/or effect the design.
 2.4 Constraints
 2.5 Assumptions and Dependencies •Describe other constraints that will limit developer’s options;
e.g., regulatory policies; target platform, database, network
 3. Specific Requirements software and protocols, development standards requirements
 4. Appendices
 5. Index
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

 …
•Include detailed specifications of each use
 1. Introduction case, including collaboration and other
diagrams useful for this purpose
 2. Overall Description
 3. Specific Requirements
•Include:
 3.1 External Interfaces a) Types of information used
 3.2 Functions b) Data entities and their relationships

 3.3 Performance Requirements

 3.4 Logical Database Requirements •Should include:
a) Standards compliance
 3.5 Design Constraints b) Accounting & Auditing procedures
 3.6 Software System Quality Attributes
 3.7 Object Oriented Models •The main body of requirements organized in a variety of possible
ways:
 4. Appendices a) Architecture Specification
b) Class Diagram
 5. Index 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