A Guide to Understanding Business and Technical Requirements for Projects

Business Requirements vs Technical Requirements

Project business requirements are the same as customer requirements or end user requirements, and these list what the project will accomplish. The process of drawing up project business requirements including identifying the key stakeholders, capturing their requirements through various methods such as interviews, focus groups, and building prototypes, and prioritizing such requirements for implementation based on commercial and other considerations.

One important point to consider regarding project business requirements is that the end user need not necessarily be the external customer. The end user for a project could be an internal customer fulfilling a critical process which serves to fulfill a critical business requirement.

Project technical requirements specify how the project would accomplish the business requirement or meet its intended purpose. It details the technical issues that need resolving to implement the project. Two key dimensions of technical requirements are the project architecture, and interface with other systems and software. The project architecture lists out the different modules or components involved in the project and the relationship among these modules. For instance, a standard web application has three layers: an user interface layer, an application logic layer where the actual processing takes place, and a database layer to store data.

Project technical requirements are different from functional, operational and transitional requirements. Functional requirements specify how the deliverable should function, operational requirement list out the activities that need to run to keep the deliverables functioning, and transitional requirements specify the steps involved in implementing the new system.

The concept of requirements for projects is best illustrated by an example. The project charter might specify a deliverable of the project to create a widget that emits a sound when clicked. This is the business requirement. The technical requirements for this project that may also find mention in the project plan would be to display the image of a panda bear, incorporating a sound playback module by using Macromedia Flash, and using the Flash sound library to interface with the hardware.

Example

Assume that a store uses stand-alone billing software, and manage stocks and accounts manually using MS-Excel. The store now wants to integrate its accounts, inventory management, and billing functions, and automate the processes.

The business analyst studies how the present system functions and draws up the improvements or functionalities required by the user. The business analyst here recommends developing an integrated software application that serves as billing, inventory, and accounting software, automatically updating accounts and inventory at the time of billing, adding fresh stock, and making payments. This constitutes the business requirement.

The business analyst now hands over the project to the programmers or the technical experts, who determine the structure and the blueprint of the project. Development of such a system might require bar coding each inventory item to allow input of stock when the product reaches the store, and identification of the product at time of billing. The system would require three user interfaces, one to add stocks when items enter the store, one for inputting cash inflows and outflows other than normal sales transactions, and third, the main billing interface. If the store plans for branches and a centralized inventory warehouse, the application needs accessing through the web, and as such scripting in PHP. On the other hand, if the store requires only a desktop application, the scripting language is C++. The application requires databases for inventory, bill log, and cash flow. The best option for databases is MySQL. All these constitute the technical requirements of the project.

Best Practices

Reconciling business and technical requirements for projects is a challenge, for what constitutes good business requirements may be difficult to execute technically, and what is possible technically may not be enough to fulfill customer requirements.

The best project business requirements are simple, clear, and broad in scope. The more detailed and complex the business requirement, the harder the technical implementation. For instance, if the business requirement is for call center customer service executives to retrieve customer details faster, a good business requirement would be “make changes to software code to reduce customer detail search time by 30 seconds.” Specifying details such as “making changes to user interface to allow for faster input of strings,” “changing search algorithm for better search,” or specifying the color combination of user interface are all technical specifications, changes to which do not impact the business requirement, and are therefore best left to the project design team. Including such details in business requirements place unnecessary restrictions on the design team.

The best project technical requirements are that which remain flexible, and allow reversability or process backtracking, to incorporate changes in business requirements or scope creep that may come about when the project is in implementation stage. For instance, in the example of the store quoted in the first page, the store might initially want a desktop application, and the technical requirement would be to code the software in C++. A best practice is to code in PHP, to allow the possibility of converting the application as web-based if the store decides to open branches.

The best approach is to make gathering business requirements and drawing up technical requirements for projects a collaborative approach, with both business managers and technical experts having a say. The project fails if business managers dominate the project planning process and set project targets impossible to attain technically, or if project managers concern themselves with technical requirements, keeping business requirements secondary.

References

1. “Building Widgets: Business Requirements vs. Technical Requirements.” https://www.startupcto.com/processes/business-vs-technical-requirements. Retrieved April 21, 2011.
2. MindTools.com “Business Requirements Analysis.” https://www.mindtools.com/pages/article/newPPM_77.htm. Retrieved April 21, 2011.

Image Credit:

• Page 1: flickr.com/Ryan Stubbs
• Page 2: [freedigitalphotos.net/Salvatore Vuono](/tools/Assume that a store uses stand-alone billing software, and manage stocks and accounts manually using MS-Excel. The store now wants to integrate its accounts, inventory management, and billing functions, and automate the processes. The first step is for the business analyst to study how the present system functions and draw up the improvements or functionalities required by the user. The business analyst here recommends developing an integrated software application that serves as billing, inventory, and accounting software, automatically updating accounts and inventory at the time of billing, adding fresh stock, and making payments. This constitutes the business requirement. The business analyst now hands over the project to the programmers or the technical experts, who determine the structure and the blueprint of the project. Development of such a system might require bar coding each inventory item to allow input of stock when the product reaches the store, and identification of the product at time of billing. The system would require three user interfaces, one to add stocks when items enter the store, one for inputting cash inflows and outflows other than normal sales transactions, and third, the main billing interface. If the store plans for branches and a centralized inventory warehouse, the application needs accessing through the web, and as such scripting in PHP. On the other hand, if the store requires only a desktop application, the scripting language is C++. The application requires databases for inventory, bill log, and cash flow. The best option for databases is MySQL. All these constitute the technical requirements of the project.)