What Are Requirements? SDLC?

Functional Requirement

In order to understand what requirements are, it is necessary to know why one needs them. Basically, requirements are statements that indicate that what a system needs to do in order to provide a capability (i.e utility or benefit). Requirements are generally prepared   during the early stages of a project’s system development life cycle (SDLC).

There are many different SDLC methodologies used in practice. They range from heavy weight ones, such as the Rational Unified Process (RUP), Waterfall and Spiral methodologies to more agile methodologies such as Exchange Programming (XP), SCRUM and Crystal. Regardless of the methodology employed there are generally six basic phases (note the descriptions oversimplify the activities that occur during each phase

1. Discovery – “What needs to be built?” Where the bulk of the analysis (requirements) occurs.

2. Planning – Perform planning to determine the tools, procedures, budget, and resourcing needs.

3. Design – “How are we going to get a solution?”

4. Build – Develop the solution

5. Implement – Deploy the solution into production

6. Warrantee – Monitor the solution to ensure that it functions properly, is reliable and predictable.

Requirements describe what users want a system to be able to do. Thus, well defined requirements are critical to the success of the project.

A large majority of all software defects and failures are directly attributed to bad requirements! 

In practice, the percentage of errors during a project’s SDLC are higher during the analysis phases than the later stages. Furthermore, the cost to fix an error increases the later the error is discovered.

Put another way, the cost to fix an error during the implementation stage is several magnitude larger than the cost to fix the same error during the analysis stage. 

I have seen many different names used for requirements documentation including: business requirements, user requirements, functional requirements etc.. Individual organizations will use these terms differently. Personally I view the distinction between different types of functional requirements to be based on the level of details provided.

For example, a high-level (business) requirement may be” The ability to maintain a product catalog”. A lower-level requirement (functional specification) would be, “The ability to specify a date range dictating when a product is available”. A good practice is to avoid mixing different types of requirements together in the same document.

Non- Functional Requirements 

Most of this post deals with functional requirements. There is another type known fittingly as non-functional requirements. Non-functional requirements describe system characteristics such as

(1) Productivity – How much a system aids users? For example, “We used to be able to handle 10 complaints in an hour and now we can handle 12.”

(2) Performance – How fast should the system be?

(3) Capacity – How much traffic must the system be able to handle?

(4) Scalability – How easily can the system be expanded to handle increased throughput?

(5) Availability – Does the system needs to be 24/7, weekdays only etc..?

(6) Recoverability – How quickly should the system be made operational after an outage?

(7) Integrity – How predictable and reliable should the system be?

(8) Exception handling -How will processing exceptions be handled?

(9) Logging – Do we need to have audit trails of activities?

(10) Security – What are the security characteristics?

(11) Manageability -How easy is it to manage the system ?

(12) Useability -What interfacing is required for end users?

(13) Interoperability -Does the system need to able to interface with other systems? How?

(14) Extensibility -Can the system be expanded to support new functionality?

(15) Maintainability – How readily can the system be understood? How extensive is the documentation?

(16) Upgradeability – How easy it is to upgrade the system?

(17) Portability – Can the system be moved to other platforms easily?

(18) Deployability – How can the system be deployed? In components or all at once?

(19) Data Currency – How up-to-date should the information be? Real-time?

(20) Data Retention? How long does data need to be kept for?

(21) Internationalization – Does the system need to support multiple time zones, languages and standards?


  • There are functional and non-functional requirements
  • Requirements are important to the success of the project
  • Requirements can be stated at varying levels of detail.

My next few posts will outline suggestions on how to write more effective requirements. Thanks for taking the time to read my blog