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!