Requirements Specification 1
Requirements Specification 1
Requirements Specification 1
Software Requirements
User requirements
System requirements
User Requirement:
Let us assume that we have a word-processing system that does
not have a spell checker. In order to be able to sell the product, it is
determined that it must have a spell checker. Hence the business
requirement could be stated as:
System Requirement:
After documenting the user’s perspective in the form of user
requirements, the system’s perspective: what is the functionality
provided by the system and how will it help the user to accomplish
these tasks. Viewed from this angle, the functional requirement for
the same user requirement could be written as follows:
The spell checker will find and highlight misspelled words. Right
clicking a misspelled word, will then display a dialog box with
suggested replacements. The user will be allowed to select from the
list of suggested replacements. Upon selection it will replace the
misspelled word with the selected word. It will also allow the user to
make global replacements.
Library System (LIBSYS) shall keep track of all data required by copyright licensing
agencies.
- LIBSYS request forms shall be stored on the system for five years from
the date of the request.
- All LIBSYS request forms must be indexed by user, by the name of the
material requested and by the supplier of the request.
- LIBSYS shall maintain a log of all requests that have been made to the
system.
- For material where authors’ lending rights apply, loan details shall be sent
monthly to copyright agencies that have registered with LIBSYS
Functional requirements
• Statements of services the system should provide, how the system should
react to particular inputs and how the system should behave in particular
situations.
Example: LIBSYS used by students and faculty to order books and documents
from other libraries.
A library system that provides a single interface to a number of databases of
articles in different libraries.
Users can search for, download and print these articles for personal study.
The user shall be able to search either all of the initial set of databases or
select a subset from it.
The system shall provide appropriate viewers for the user to read documents
in the document store.
Product requirements
• Requirements which specify that the delivered product must
behave in a particular way e.g. execution speed, reliability, etc.
Organisational requirements
• Requirements which are a consequence of organisational
policies and procedures e.g. process standards used,
implementation requirements, etc.
External requirements
• Requirements which arise from factors which are external to
the system and its development process e.g. interoperability
requirements, legislative requirements, etc.
Lack of clarity
• Precision is difficult without making the document difficult to read.
Requirements confusion
• Functional and non-functional requirements tend to be mixed-up.
Requirements amalgamation
• Several different requirements may be expressed together as a single
requirement.
They add detail and explain how the user requirements should be
provided by the system.
Ambiguity
• The readers and writers of the requirement must interpret the same
words in the same way. NL is naturally ambiguous so this is very
difficult.
Over-flexibility
• The same thing may be said in a number of different ways in the
specification.
Lack of modularisation
• NL structures are inadequate to structure system requirements.
Notation Description
Structured natural This approach depends on defining standard forms or templates to express the
language requirements specification.
Design This approach uses a language like a programming language but with more abstract
description features to specify the requirements by defining an operational model of the system.
languages This approach is not now widely used although it can be useful for interface
specifications.
Graphical A graphical language, supplemented by text annotations is used to define the
notations functional requirements for the system. An early example of such a graphical
language was SADT. Now, use-case descriptions and sequence diagrams are
commonly used .
Mathematical These are notations based on mathematical concepts such as finite-state machines or
specifications sets. These unambiguous specifications reduce the arguments between customer and
contractor about system functionality. However, most customers don’t understand
formal specifications and are reluctant to accept it as a system contract.