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 system’s 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 application’s

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 system’s 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 customer’s and developer’s

organization, or from external sources––which 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 project’s 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