Types of Software Requirements
If you work in IT as a Systems or Business Analysts, you will be asked to provide many different types of requirements for many different types of solutions. One key to being a good systems or business analyst is understanding the different types of requirements, their ultimate purpose, their value, and how to write them.
In a nutshell, here are the big three requirement types:
For the purpose of this article let's start with business requirements. Look for subsequent articles to address the other types of requirements.
Business requirements determine what needs to appear within a enterprise system (manual or automated). The greatest mistake to avoid with business requirements is generating them too specialized or generating them in a way that that is really design. The actual focus on should be on the 'what' and not the 'how.'
A fantastic way to discover business requirements is to ask the end-user (usually a customer or enterprise partner), to evaluation how the preferred end results would be obtained by a individual being with nothing more than a note pad, a pen, and a cellphone. This is fantastic method to absolutely sure the end-user does not concern the features of a programmed presentation with the actual objective they are trying to obtain.
Excellent business requirements will take counsel activities, information, selections and regulations that management an enterprise technique. These are items that must always be actual regardless of whether the technique is being programmed by mainframe applications, or web services.
What happens when this is not done, can be troubling. You end up with individuals who are not technologists determine how a software solution should be designed and implemented. This is like asking the software architecture or programmer across the world in India to design the company’s marketing plan. Not only will the end result be less the optimal, it will lead to unrealistic expectations from the business users or clients. Also, instead of focusing on what the really want to accomplish for their business they end up wasting a lot their valuable time thinking of the 'how.'
“The system should allow for customer service representatives to capture customer complaints.” This is actually a well formed requirement. Although it does not go into extreme detail, it is a legitimate high-level business requirement.
“The system should add a new table to its database for customer complaints.” This is not a business requirement but instead is a dictation of design. It does not speak what needs to be done for whom in pure logical business terms. Instead it makes a bold technical assumption of how certain type of data should store in a systems internal database. With the lack of clarity around why or what exactly needs to be captured about a compliant, who can say whether a single table is appropriate or not. These are certainly very dangerous business requirements.
So, next up will be an article on functional requirements and how those build off of the types of pure business requirements discussed in this article. Until then, ciao and happy specifying.