1

INTRODUCTION

Software Engineering is an engineering discipline concerned with all aspects of software
production, from the early stages of system specification through to maintaining the system after
it has gone into use. Contained in Software Engineering is a further concept Requirements
Engineering.

Requirements engineering is the practice of establishing the services that the customer needs
from a system and the constraints under which it operates and is developed. The requirements
for a system themselves are the descriptions of what the system should do the services that it
provides and the constraints that are generated during the requirements engineering process.
These requirements tend to reflect the essential needs of customers for a system that serves a
certain specified purpose. Requirements may range from a high-level abstract statement of a
service or of a system constraint to a more detailed mathematical functional specification.

Focus is given to two main types of requirements user requirements and software system
requirements. Software system requirements are commonly presented as a structured
document that lays out explicit descriptions and explanations of the systems functions, services
and operational constraints. They help define exactly what needs to be implemented in the
software to be developed, and therefore they are usually part of a contract signed between the
client and the contractor. Software system requirements are often classified as functional
requirements or nonfunctional requirements.






2

FUNCTIONAL REQUIREMENTS

Functional requirements refer to very important system requirements and statements of services
in a software engineering process the system should provide, how the system should behave in
reaction to particular inputs and how the system should perform when presented with specific
situations. When expressed as user requirements, functional requirements are usually described
in an abstract way that can be understood by system users. However, more specific functional
requirements may contain calculations, technical details, data manipulation and processing and
other specific functionality that define what a system is supposed to accomplish, and sometimes
might specify what the system should not do. The key goal of determining functional
requirements in a software product design and implementation is to capture the required
behavior of a software system in terms of functionality and the technology implementation of
the business processes.

Normally, the Software Engineer makes use of the Use Cases and Scenarios generally following
standard UML notations, in order to capture the functional requirements through a system
analysis process. A typical functional requirement will contain a unique name and number, a brief
summary, and a rationale. This information is used to help the reader understand why the
requirement is needed, and to track the requirement through the development of the system.

As functional requirements must specify particular results of a system, the description of the
required behavior needs to be completely clear and readable. The described behavior may come
from organizational or business rules, or it may be discovered through elicitation sessions with
users, stakeholders, and other experts within the organization. Many requirements may be
uncovered during the use case development. When this happens, a placeholder requirement
with a name and summary may be created and the details researched later, to be filled in when
the requirements are better known.

3

Functional requirements are usually in the form of "system shall do <requirement>", an individual
action of part of the system, perhaps explicitly in the sense of a mathematical function, a black
box description input, output, process and control functional model or IPO Model.

An example of a system using functional requirements is the list of a possible Sales applications
functional requirements as shown:

1. Application shall capture appropriate information and produce Comparative Analysis
(current month and year-to-date compared to same month last year and year-to-date last
year) and Trend Analysis reports by: Product (units sold and dollars), Product Type,
Product Family, Customer, Salesman, Territory, and Discount Type.
2. Application shall show Trend Analysis by Customer and Product, including profitability by
customer.
3. Application shall show Trend Analysis by Product and Customer, including profitability by
product.
4. Application shall show Monthly Detail by Customer and Invoice.
5. Application shall show Graphic Trend Charts by Customer, Salesman, Product Type and
others.
6. Application shall show Sales of Products by Vendor, by Postal Code.
7. Application shall show Sales by Source Code (for Mail Order companies).
8. Application shall show Sales Analysis by province








4

NON-FUNCTIONAL REQUIREMENTS

In requirements engineering, a non-functional requirement is a requirement that specifies the
standards that can be used to judge a systems operation, rather than specific behaviors.
Basically, non-functional requirements define how a system is supposed to be as opposed to what
it is supposed to do. They are generally informally stated, often contradictory, and difficult to
enforce during development and evaluate for the customer prior to delivery. They are usually
specified or constrained by the characteristic behavior of the required software, system
requirements derived from policies and procedures in the customers and developers
organization, or from external sourceswhich includes all requirements that are derived from
factors external to the system and its development process.

Non-functional requirements define system properties and constraints (for example reliability,
response time and storage requirements), and requirements instructing a specific IDE,
programming language or development method may be detailed. They may be more critical than
functional requirements in the sense that if non-functional requirements are not met, the system
may be rendered practically useless.

Non-functional requirements drive the technical architecture of a system, which means that they
tend to affect the whole architecture of a system, as opposed to only the separate specific
components. For instance, to ensure that optimum performance requirements are met, the
system might need to be arranged in such a way that communications amid components are
lessened, eliminating unnecessary communications. A single non-functional requirement may
spawn several related functional requirements that define required system services, and may
also generate requirements that restrict existing requirements.

In order to specify efficient non-functional requirements, there are a few merits that must be
considered. These include the system's availability or "uptime" (the amount of time that it is

5
operational and available for use), efficiency (specifies how well the software utilizes scarce
resources), flexibility (enables the organization to extend the functionality of the software after
it is deployed), portability (specifies the ease with which the software can be installed on all
necessary platforms, and the platforms on which it is expected to run), integrity (defines the
security attributes of the system, restricting access to features or data to certain users and
protecting the privacy of data entered into the software), performance (specifies the timing
characteristics of the software), reliability (specifies the capability of the software to maintain its
performance over time), reusability (indicates the extent to which software components should
be designed in such a way that they can be used in applications other than the ones for which
they were initially developed), robustness (enables the system to handle error conditions
gracefully, without failure), scalability (gives the ability to handle a wide variety of system
configuration sizes), and usability (addresses the factors that constitute the capacity of the
software to be understood, learned, and used by its intended users).

Non-functional requirements appear in the form of "system shall be <requirement>", an overall
property of the system as a whole or of a particular aspect and not a specific function. The
diagram below provides an example of non-functional requirements as implored in a proposed
solution for a general application.




6

CONCLUSION

Functional requirements drive the application architecture of a system, while non-functional
requirements drive the technical architecture of a system. The functional requirements describe
the behavior of the system as it relates to the system's functionality, while the non-functional
requirements elaborate the performance characteristic of the system. If there is any one thing
any project must have in order not to be doomed to failure, it is a sensible and comprehensive
collection of both the functional and non-functional requirements. Any projects requirements
need to be well thought out, balanced and clearly understood by all involved, but perhaps of
most importance is that they are not dropped or compromised halfway through the project.



















7
REFERENCES

Debono, M. (2012, April 5). Functional Requirements vs. Non-Funtional Requirements. Retrieved
from ReQTest: http://www.reqtest.com/blog/functional-vs-non-functional-
requirements/



Functional Requirements. (2008, February 6). Retrieved from Toolbox.com:
http://it.toolbox.com/wiki/index.php/Functional_Requirements



Sommerville, I. (2011). Software Engineering. Boston, Massachusetts: Pearson Education Inc.



Stellman, A. (2010, February 17). Understanding Nonfunctional Requirements. Retrieved from
O'Reilly Community: http://broadcast.oreilly.com/2010/02/nonfunctional-
requirements-how.html