Requirement Engineering

Iftikhar Ahmed koondhar

Levels of Software Requirements
Software requirements are defined at various levels of detail and granularity.
Requirements at different level of detail also mean to serve different purposes.
We first look at these different levels and then will try to elaborate the difference
between these.
(insufficient user involvement leads to unacceptable products)
Busines Requirements
User Requirements
Functional requirements (individual feature, functionality design)
Non-Functional Requirements (framwork, architecture)
Levels of Software Requirements
Busines Requirements:
Top level of requirements ( other requirements are after this), related to
Vision, why business require this system, objectives to be achieved??
These are used to state the high-level business objective of the organization
or customer requesting the system or product.
They are used to document main system features and functionalities
without going into their nitty-gritty details.
 They are captured in a document describing the project vision and scope.
Levels of Software Requirements
User Requirements:
 functions performed by user to achieve Bussiness vision/objectives.
What operations/sections are going to be automated by software.
User requirements add further detail to the business requirements.
 They are called user requirements because they are written from a user’s
perspective and the focus of user requirement describe tasks the user must be
able to accomplish in order to fulfill the above stated business requirements.
 They are captured in the requirement definition
See the system from user point-of-view
Levels of Software Requirements
Functional Requirements:
How the system is going to help to improve the system?
The next level of detail comes in the form of what is called functional
requirements.
 They bring-in the system’s view and define from the system’s perspective
the software functionality the developers must build into the product to
enable users to accomplish their tasks stated in the user requirements -
thereby satisfying the business requirements
Levels of Software Requirements
Non-Functional Requirements: (performance, usabilty)
 As we know that software requirement as a document that describes all the
services provided by the system along with the constraints under which it must
operate.
That is, the requirement document should not only describe the functionality
needed and provided by the system, but it must also specify the constraints under
which it must operate.
Constraints are restrictions that are placed on the choices available to the
developer for design and construction of the software product.
These kinds of requirements are called Non-Functional Requirements.
 These are used to describe external system interfaces, design and
implementation constraints, quality and performance attributes.
 These also include regulations, standards, and contracts to which the product
must conform.
Non-Functional Requirements
Non-functional requirement play a significant role in the development of the
system. If not captured properly, the system may not fulfill some of the basic
business needs.
If proper care is not taken, the system may collapse. They dictate how the system
architecture and framework.
As an example of non-functional requirements, we can require software to run on
Sun Solaris Platform. Now it is clear that if this requirement was not captured
initially and the entire set of functionality was built to run on Windows, the
system would be useless for the client.
 It can also be easily seen that this requirement would have an impact on the
basic system architecture while the functionality does not change.
While writing these requirements, it must always be kept in mind that all
functional requirements must derive from user requirements, which must
themselves be aligned with business requirements.
Non-Functional Requirements
It must also be remembered that during the requirement engineering (definition
phase of the software development), the focus is on what and not how.
Therefore, requirements must not include design or implementation details and the
focus should always remain on what to build and not how to build.
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: user will be able
to correct spelling errors in a document efficiently. Hence, the Spell checker will
be included as a feature in the product.
In the next step we need to describe what tasks must be included to accomplish the
above-mentioned business requirement?
 The resulting user requirement could be as follows: finding spelling errors in the
document and decide whether to replace each misspelled word with the one chosen
from a list of suggested words.
It is important to note that this requirement is written from a user’s perspective.
Non-Functional Requirements
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. It 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.
Finally, a non-functional requirement of the system could require that it must be
integrated into the existing word-processor that runs on windows platform.
Business Vision and
Requirements Scope document

User Quality
Requirements Attributes

Other
Non-functional
Use Case document Requirements

System Functional
Requirements Requirements Constraints

Functional Specification
Documents
Risks from Inadequate Requirement
Process
Following is a list of some of the risks of adopting an inadequate
requirement process:
1.Insufficient user involvement leads to unacceptable products.
2.Creeping user requirements contribute to overruns and degrade product
quality.Requirement creep is one of the most significant factors in budget and
time overruns.
3.Ambiguous requirements lead to ill-spent time and rework.
4.Gold-plating by developers and users adds unnecessary features.
5.Minimal specifications lead to missing key requirements and hence result in an
unacceptable product.
6.Overlooking the needs of certain user classes (stake holders) leads to
dissatisfied customers.
7.Incompletely defined requirements make accurate project planning and
tracking impossible.
 Management Marketing

provides business Provides Business

requirements and Requirements and
project parameters Project Parameters

Software
Holders

Requirements
Stake

describe user Specifies hardware

allocate system
requirements and interfaces the software
requirements to software
quality attributes must respect

System Eng. Users Hardware Eng.

Req: Statement and Req: Specification Doc

Different levels of software requirements are documented in different

documents.
 The two main documents produced during this phase are Requirement
Statement and Requirement Specification.
 They are also called Requirement Definition and Functional Specification
and are used to document user requirements and functional requirements
respectively.
 Requirement Statement Charactersitics
Complete - Each requirement must fully describe the functionality to be delivered.
Correct - Each requirement must accurately describe the functionality to be built.
Feasible - It must be possible to implement each requirement within the known
capabilities and limitations of the system and its environment.
Necessary -Each requirement should document something that the customer really
need or something that is required for conformance to an external system requirement
or standard.
Prioritized - An implementation priority must be assigned to each requirement, feature
or use case to indicate how essential it is to a particular product release.
Unambiguous - All readers of a requirement statement should arrive at a single,
consistent interpretation of it.
Verifiable – User should be able to devise a small number of tests or use other
verification approaches, such as inspection or demonstration, to determine whether the
requirement was properly implemented.
 Requirement Specification Charactersitics
Complete - No requirement or necessary information should be missing.
Consistent – No requirement should conflict with other software or higher-level system
or business requirements.
Let us try to understand this with the help of some examples. The following set of (non-functional)
requirements was stated for a particular embedded system.
All programs must be written in Ada.
The program must fit in the memory of the embedded micro-controller.
These requirements conflicted with one another because the code generated by the Ada
compiler was of a large footprint that could not fit into the micro-controller memory.
Following is another set of (functional) requirements that conflicted with one another:
System must monitor all temperatures in a chemical reactor.
System should only monitor and log temperatures below -200 C and above 4000 C
In this case the two requirements clearly conflict with each other in stating what
information needs to be monitored and stored
 Requirement Specification Charactersitics
Modifiable - One must be able to revise the Software Requirement Specification when
necessary and maintain a history of changes made to each requirement.
Traceable - One should be able to link each requirement to its origin and to the design
elements, source code, and test cases that implement and verify the correct
implementation of the requirement.
Mixed level of Abstraction:
It is important to recognize that all requirements in a requirement document are stated at
a uniform level of abstraction. This difference in detail falsely implies the relative
importance of these requirements and hence misguides all involved in the development
process. The following set of requirements clearly demonstrates violation of this principle:
The purpose of the system is to track the stock in a warehouse.
When a loading clerk types in the withdraw command he or she will communicate the
order number, the identity of the item to be removed, and the quantity removed. The
system will respond with a confirmation that the removal is allowable.