Scribd
Upload
20 views24 pages

Software Security Chapter 4

The document discusses requirements specification and documentation. It defines requirements specification as writing down requirements gathered during analysis into a document called a requirements document. It describes characteristics of a good requirements document such as being unambiguous, complete, verifiable, consistent, modifiable and traceable. The document also discusses methods for requirements specification such as using unrestricted natural language or structured natural language.

Uploaded by

nabongirma2
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
20 views24 pages

Software Security Chapter 4

The document discusses requirements specification and documentation. It defines requirements specification as writing down requirements gathered during analysis into a document called a requirements document. It describes characteristics of a good requirements document such as being unambiguous, complete, verifiable, consistent, modifiable and traceable. The document also discusses methods for requirements specification such as using unrestricted natural language or structured natural language.

Uploaded by

nabongirma2
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 24

REQUIREMENTS ENGINEERING

JIMMA UNIVERSITY

JIMMA INSTITUTE OF TECHNOLOGY

FACULTY OF COMPUTING AND INFORMATICS

CHAPTER FOUR

REQUIREMENTS SPECIFICATION & DOCUMENTATION


Topics we will cover

 Requirements Specification

 Requirements Document

 Methods for Software requirements Specification


 Free documentation in unrestricted natural language
 Disciplined documentation in structured natural language
Requirements Specifications
3
 A software requirements specification is a collection of the set of all

requirements that are to be imposed on the design and verification of the


product/software.
 Requirements specification: It's the activity of writing down the

requirements gathered during the elicitation and analysis activity into a


document that defines a set of requirements.
 Input for requirement specification are outputs of requirement analysis &

negotiation
 Output of requirement specification is a complete description of a system

to be developed: : Requirements Document


What do you think are the activities for
requirements4specification?

Discussion
Requirements Specifications

 During software requirements specification :

 Define your product's purpose and scope.


 Describe what you're building.
 Details the requirements.
 Supporting information.
Results a requirements document
Requirements Document

 Requirements document is a reference document.


 Once the a requirement document is approved by the customer,
 any subsequent controversies are settled by referring the document.
 Purpose of SRS:
 Interface (communication) between the Customer, requirement
engineers Analyst, designers, system developers, testers and
maintainers.
 Agreement between Purchaser and Supplier

 Support verification and validation of requirements.

 Support system testing activities

 Support project management activities

 Controlling the evolution of overall system


Characteristics of a Software
Requirements Specification
7
Document

Discussion

What do you mean by good requirements, and what are


characteristics of a good software requirements specification
document?
Characteristics of a Software
Requirements Specification Document

 A good SRS is:

 Unambiguous,
 Complete,
 Verifiable,
 Consistent,
 Modifiable, and
 Traceable
Unambiguous

 Every requirement has only one interpretation.

 Each characteristics of the final product is described using a

single unique term.


 A glossary should be used when a term used in a particular

context could have multiple meanings.


Complete

 A complete SRS must possess the following qualities:

 Inclusion of all significant requirements,


 Definitions of the responses of the software to all realizable
classes of input,
 Conformity to any standard that applies to it.
 Full labeling and referencing of all tables and diagrams and
definitions of all terms.
Verifiable

 Every requirement must be verifiable.

 There must exist some finite cost- effective process with

which a person or machine can check that the software


meets the requirement.
Consistent

 No set of individual requirements described in the SRS can be in

conflict.
 Types of likely conflicts:
 Two or more requirements describe the same real world
object in different terms.
 The specified characteristics of real world objects might
conflict.
 There may be a logical or temporal conflict between two
specified actions.
Modifiable

 The structure and style of the SRS are such that any necessary

changes to the requirements can be made easily, completely and


consistently.
 Requirements:

 A coherent and easy-to-use organization(including a table of


contents, index and cross-referencing),
 Not be redundant-this can lead to errors.
Traceable

 The origin of each requirement must be clear.

 The SRS should facilitate the referencing of each requirement in future

development or enhancement documentation.


 Types:

1. Backward traceability: each requirement must explicitly reference


its source in previous documents.

2. Forward traceability: each requirement must have an unique name


or reference number.
Problems without a SRS document

 The important problems that an organization would face if it does not

develop a SRS document are as follows:


 Without developing the SRS document, the system would not be implemented
according to customer needs.
 Software developers would not know whether what they are developing is what
exactly required by the customer.
 Without SRS document, it will be very much difficult for the maintenance
engineers to understand the functionality of the system.
 It will be very much difficult for user document writers to write the users’
manuals properly without understanding the SRS document.
Methods for Software requirements
Specification
16

 The formality and format of a specification varies with the size and
the complexity of the software to be built.
 For large systems, disciplined documentation in structured natural
language may be the best methods.
 For small systems or product, free documentation in unrestricted
natural language
Free documentation
in unrestricted natural language
 Unconstrained prose writing in natural language.
 Unlimited expressiveness, communicability, no training needed
 Prone to many of the spec errors & flaws

 Cons: Frequent confusions among logical connectives in natural


language and order of the contents.
 Example: case analysis:

if Case1:then <Statement1>
AND
if Case2: then <Statement2>
Use Disciplined documentation in
structured in natural languages
 Use standardized statement templates.
 Title of standard:

 “IEEE Recommended Practice for Software


Requirements Specification”
 Describes the content and qualities of a good SRS
 Presents several sample SRS outlines
IEEE 830-1998 Standard – Structure of the
SRS
IEEE 830-1998 Standard – Structure of the SRS
IEEE 830-1998 Standard – Structure of
the SRS
IEEE 830-1998 Standard – Structure of the
SRS
Key Points

 Requirements Specification

 Requirements Document

 Methods for Software requirements Specification


Any Question?

You might also like