Requirement Engineering
Dr.Fatima Sabir
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
– 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
•Define the vocabulary of the SRS (may
– 1.3 Definitions. Acronyms, and Abbreviations reference appendix)
– 1.4 References
– 1.5 Overview •List all referenced documents including sources
(e.g., Use Case Model and Problem Statement; Experts in
• 2. Overall Description the field)
• 3. Specific Requirements •Describe the content of the rest of the SRS
• Appendices •Describe how the SRS is organized
• Index
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, communication
•Describe constraints: memory, operational, site adaptation
• Title
•Summarize the major functional capabilities
• Table of Contents •Include the Use Case Diagram and supporting narrative
(identify actors and use cases)
• 1. Introduction •Include Data Flow Diagram if appropriate
• 2. Overall Description
•Describe and justify technical skills and
– 2.1 Product Perspective capabilities of each user class
– 2.2 Product Functions
– 2.3 User Characteristics
– 2.4 Constraints
– 2.5 Assumptions and Dependencies
•Describe other constraints that will limit developer’s options;
• 3. Specific Requirements e.g., regulatory policies; target platform, database, network
software and protocols, development standards requirements
• 4. Appendices
• 5. Index States assumptions about availability of certain
resources that, if not satisfied, will alter system
requirements and/or effect the design.
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
requirements
• 1. Introduction
State requirements that are externally perceivable by users,
• 2. Overall Description operators, or externally connected systems
• 3. Specific Requirements Requirements should include, at a minimum, a description of
every input (stimulus) into the system, every output (response)
– 3.1 External Interfaces from the system, and all functions performed by the system in
– 3.2 Functions response to an input or in support of an output
– 3.3 Performance Requirements (a) Requirements should have characteristics of
high quality requirements
– 3.4 Logical Database Requirements (b) Requirements should be cross-referenced to
their source.
– 3.5 Design Constraints (c) Requirements should be uniquely identifiable
– 3.6 Software System Quality Attributes
(d) Requirements should be organized to
maximize readability
– 3.7 Object Oriented Models
• 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
•Include detailed specifications of each use
• 2. Overall Description case, including collaboration and other
diagrams useful for this purpose
• 3. Specific Requirements
– 3.1 External Interfaces •Include:
– 3.2 Functions a) Types of information used
b) Data entities and their relationships
– 3.3 Performance Requirements
– 3.4 Logical Database Requirements •Should include:
– 3.5 Design Constraints a) Standards compliance
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
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
Z (“zed”) Notation
• Formal specification language
– most successful one -> easy to find faults, can prove
correctness
• Requires set theory, functions, & discrete math
– difficult to learn because of special symbols
• Z specifications consists of 4 sections
– given sets, data types, and constants
• sets that get defined in detail
– state definition
• variable declarations & predicates that constrain values
– initial state
– operations
Specification in Z
• Scenario: We maintain a membership list
and an associated phone database.
[Person, Phone]
|----PhoneDB-----------------------------------
|members: P Person (‘set of’ person)
|phones : Person Phone (relation)
|-------------------------------------------------------
|dom phones ⊆ members (invariant)
|---------------------------------------------------
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
Requirement Specification Checklist
– Do stated goals and objectives for software remain consistent
with system goals and objectives?
– Have important interfaces to all system elements been
described?
– Have all data objects been described? Have all attributes been
identified?
– Do major functions remain within scope and has each been
adequately described?
– Have functions been refined (elaborated) to an appropriate level
of detail?
– Is information flow adequately defined for the problem domain?
– Are diagrams clear; can each stand alone without
supplementary text?
– Is the behavior of the software consistent with the information it
must process and the functions it must perform?
Requirement Specification Checklist
– Have events and states been identified?
– Are design constraints realistic?
– Have technological risks been fully defined?
– Have alternative software requirements been considered?
– Have validation criteria been stated in detail; are they
adequate to describe a successful system?
– Have inconsistencies, omissions or redundancy been
identified and corrected?
– Is the customer contact complete?
– Has the user reviewed the Preliminary User's Manual or
prototype?
– How are the Software Project Plan estimates affected?
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
