What are requirements? SDLC?

Functional Requirements

In order to understand what requirements are, it is necessary to know why one needs them. Basically, requirements are statements that indicate 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 lifecycle (SDLC.)

There are many different SDLC methodologies that are 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 Extreme 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 build?" Where the bulk of the analysis (requirement gathering) 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 a 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 magnitudes 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 disctintion between different types of functional requirements to be based on the level of detail 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) Availabilty - Does the system need 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 be 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 is it 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?

Summary

  • There are functional and non-functional requirements.
  • Requirements are important to the success of a 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.

P.S. I would also like to thank the colleague of mine who created the list of non-functional requirements that I have represented in my post!

11 comments:

Sofien BEJI said...

There are some NFR in the list which belong to others, e.g the integrity is a sub-goal of security.

baggy said...

hey thanks a lot for the explanation. could you send me any informatiom about COTS and its drawbacks..

bhargavmitra@gmail.com

Anonymous said...

A requirement is a decision. It's a decision about What (functional) or How Well (non-functional). With COTS or APIs or mashups, you are letting other people's decisions drive yours at some scope. The decsions that led to the COTs application are implicit, or opaque to you. The issue becomes one of can I make my own faster than I can understand theirs. Usually, you are stuck with theirs.

Adam Lee said...

I think the most important non-functional requirement in industry is "profitability".

But yet the ones listed above are pretty good. Keep it up!

Georgia said...

Hi there. In the last few days I've been browsing the net to find some find some good information about non-functionals. From all the info I found, your blog is the best. I'm actually using some of your info to write my requirements. Thanks!
Georgia
www.panamoqa.com

Marcus Ting-A-Kee said...

I'm glad it's helpful to you Georgia.

Brajendra said...

Thanks for sharing

Arvind said...

Hi Marcus,

It was great reading your inputs on requirement analysis.I am working as a CRM implementation trainee at a firm which is involved in customization of CRM/ERP packages according to the client's business process.
I gather the requirements and report to the project manager.As you can see,my profile doesn't deal with software development(not exactly), i would be grateful if you could give some tips on gathering requirements specification for customization of CRM.My clients are from various sectors as in from Manufactoring to Trading verticals including Automotive,Core Engineering sectors also.

Thanks Mate..!!

Krishna

Anonymous said...

plea can u tell me about collobrative online file sharing system their functional .non functional requirement its scope and usage scenario

tomcruse said...

Great information.Thanks for sharing this useful information about SDLC

tomcruse said...

Great information.Thanks for sharing this useful information about SDLC