Software requirement arises out of a business need. Someone from the business sector feels that some critical business requirement can be met by building an application and shall provide some amount of automation and enhancement as compared to the manual process. They further desire it to be built by either internal software development team or an external/outsourced team. A business requirement document is then prepared to provide both ‘What Is’ and ‘What Needs To Be’ scenarios.

( Read more:   How Should a CISO choose the right Anti-Malware Technology? )

‘What Is’ cites the current process as it is – end to end as happening in the business i.e. manually or in a legacy standalone system. Due to this critical business process happening manually a lot of effort goes into translating the manual business information into some kind of system to acquire sensible reports and analysis out of this. The latter might also not be happening in an application; it might be drawn out through an excel sheet with the help of certain functions and queries.

( Read more:  Annual Survey on Cloud Adoption Status Across Industry Verticals )

This business requirement is then to be given to the project manager/product manager/development manager to discuss it with the business team and their teams so as to prepare a technical document based on which the development work begins. The 'Two Ends of The Bridge' need to be well connected and have a strong connecting factor in between having a 50:50 knowledge of both ends. He must be able to identify what exactly is the requirement, what does the technical translation intend to deliver and if there is any gap between the two in shape of a risk.
For Example, a vehicle starting from one end and after covering the 80% of bridge learns some disastrous fact about the bridge!

Have a new insight to share with the information security community? Share your views under the bridge, in the comments below or write your article