The document discusses key aspects of software requirement engineering including requirement elicitation, analysis, specification, and validation. It describes the purpose of a Software Requirement Specification (SRS) document as a contract between developers and customers. Various techniques are covered for specifying requirements such as informal, semi-formal, and formal specifications. The document also outlines best practices for writing requirements and standards for SRS documents.

1. Software Requirement Engineering

2. Requirements Engineering Activities
Requirements
Elicitation
Requirements
Analysis and
Negotiation
Requirements
Specification
Requirements
Validation
User Needs,
Domain Information,
Existing System
Information, Regulations,
Standards, Etc.
Requirements
Document
Agreed
Requirements

3. 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
•The SRS document is known as black-box
specification
•SRS have different audiences(Technical and
non-technical)

4. Mapping Requirements to Specifications

5. 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 lot of
analytic thought

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

7. Activities of SRS
•Adopt SRS template
•Identify sources of requirements
•Uniquely label each requirement
•Record business rules
•Specify functional requirements
•Specify quality attributes

8. Benefits of SRS
•Forces the users to consider their specific
requirements carefully
•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
•Enables project planning eg. estimates of cost
and time, resource scheduling
•Usable during maintenance phase

9. Specification Techniques
• Informal Specifications
•Semi-formal ( graphical, tabular)
•Formal Specifications
•Algebraic approach
•Model-based approach

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

11. Semi-Formal Specifications
•Most of the semiformal specifications are based
on UML
•The specifications based on UML are supported
by different tools

12. Formal Specifications
•Formal specification is part of a more general
collection of techniques that are known as
formal methods
•Formal specification forces a very detailed
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

13. Use of Formal Methods
•Their principal benefits are in reducing the
number of errors in systems so their main area
of applicability is critical systems:
Air traffic control information systems,
Railway signalling systems
Spacecraft systems
Medical control systems
•In this area, the use of formal methods is most likely to
be cost-effective

14. Algebraic approach
The system is specified in terms of its operations
and their relationships

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

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

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

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