How to define Functional requirements? Where to start?

November 10, 2010


Developing software or any project requires you a work of a journalist, taking

notes of details and maintaining a list of the functionalities and behaviors

of the project/system to be developed. This is the first and main step of

developing a project/system is when we gather the Requirements to be translated

later to a working component.

During the fact-finding process system users will reveal what they would like

the system to do and how they would like the system to do it. These needs and

desires -requirements- can be further broken down into two subgroups, Functional

Requirements and Nonfunctional Requirements.

Functional requirements are functions or features that must be included in a

system in order to satisfy the business needs and be acceptable to the system

users.Typical functional requirements types are:

• Technical Specifications

• System Parameters

• System Constraints

• Calculations

• Data manipulation and processing

When learning about functional requirements it helps to remember that they

should be descriptive. Normally they are identified in terms of inputs, outputs,

processes and stored data.

In comparison, Nonfunctional requirements focus on the properties or qualities a

system must have. Typical Nonfunctional requirements types are:

• Efficiency

• Services

• Control

• Information

• Performance

So, what are the Functional Requirements?

First of all you need to understand the needs of your client, the one who made

the request for the software. Requirements are the most basic understanding

about the business logics of the problem to be solved. That’s a tough job,

because clients have a tricky habit of asking for things that don’t necessarily

fit their needs. Time and time again It’s observed by the people on their teams

tease the real needs out of users who, to be honest, didn’t really understand

what they wanted. And that’s a really tough job. It requires some very solid

elicitation skills, and a good familiarity with software requirements engineering

tools and practices (like this one, this one and this one). Because the other

part of the job is taking those needs and turning them into a functional

requirements that can be implemented in software. Functional Requirements only

talk about “what” is needed, not “how” or “why” and “when” etc. Requirements

Document is a binding agreement between what is needed (by the clients) and what

is actually being delivered (by software).

Where to start?

1. Start with the interview with the client, taking notes of the

functionalities they want on their system; It can be from a text that they

provide, explaining the kind of system they want etc;

2. The next step is to create the user stories/ Use cases. They are

going to your own understanding about the software to be developed;

3. Create the list of Functional and Non-Functional Requirements, extracted

during the interview and/or documentation provided by your client. In some SDLC

models Functional Requirements are driven of Business Requirements.

4. Represent these requirements using diagrams such as Use Case Diagrams

from UML/ User stories.

How do you define them?

Name Name and number of the functional requirement
Summary Brief description of the requirement
Rationale Description of the reason that the requirement is needed
Requirements The behavior required of the software
References Use cases or other functional or nonfunctional requirements that are relevant to understanding this one

The name, summary, and rationale of each functional requirement are used in the

same way as those of the use cases. The behavior that is to be implemented should

be described in plain English in the “Requirements” section. Most requirements

are only relevant to a small number of use cases—these should be listed by name

and number in the “References” section. (Some requirements are not associated with

use cases.)


Building a house requires a detailed plan. Without a detailed plan, the outcome of

the building may produce unwanted results and a faulty structure. Particularly

enterprise projects can cost many times as much as a house. Creating solid Functional

requirements is a simple method for developing a blueprint for any new project. The

project does not necessarily need to be a software application, yet all projects

use some technology to develop a blueprint about its use and scope.





Sudheer Amireddy
Birmingham, Alabama


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: