« Back to blog

Requirements Engineering

"In my debate team during undergrad i had a senior who told me that the issue with most debaters is not that they cannot speak to put forward their point. Their issue is that they do not know which point(s) to put forward."

To know what is required, in order to achieve an over all goal is probably the most difficult thing to do in any area of work. IEEE610, 1990: a requirement (in the context of software engineering) is a condition or capability which allows users to solve problems or achieve a goal.
Requirements Engineering is a phase in which the effort is to understand the problems(requirements) to be solved(satisfied) in order for us to arrive at a solution(working software system).  
The 'user' here may reffer to many different kinds of people:
a) the end user
b) the customer who pays the bill for the software
c) other stakeholders in the system.
Most requirements come from the end user for whom the software is finally meant for use. Other requirements are stated by the various other stake holders.
The word 'requirement' itself is a misnomer. A requirement is always given and cannot change once stated. But the world of software engineering, where software has to evolve, does not allow such a luxury. There are many factors changing the requirements of any project, such as:
a) Time to market,
b) Cost,
c) Conflicts in quality standards,
d) Conflicts in stakeholders' needs, etc.
These factors compel a trade off between the requirements that evolve and/or are in contention.

REQUIREMENT SPEC - The Document
a) The net requirements for any project are recorded in a document called REQUIREMENT SPEC. 
b) A requirement specification is, in an ideal world, the end product of the Requirements Engineering Phase.
c) It serves as the contract, formal/informal, between the client and the analyst; directing them towards a clear understanding of the problem at hand and thus, a solution to the same.
d) A high level design document:
It serves as the pivot around which the Design of the system is created. There can be no distinction between Requirements engineering and design as the two are deeply intertwined with each other. The reqs are viewed as a high level design of the system, based on which an overall design of the system is constructed. This design then consists of various components and the interfaces via which the components interact. This design is again used in creating a refinement of the requirements themselves. Such a process is greatly observed when prototyping techniques are used in building software. The two phases inherently revolve around each other in the case of agile methods of software development, where the two are constantly evolving in the presence of working system/solution.
Requirement Engineering and Design are presented distinctly, as consecutive stages of software development only for the sake of convinience.
e) The req spec is finally used in the acceptance testing of the system, when the working system is pitted against the req.spec. to validate and verify the system with the requirements.

REQ.ENGG. & ITS EXTENT 
Requirements engg is more than a simple analysis of the requirements of the system to be built. It is an iterative and co-operative process of: 
i) Analyzing a problem; 
ii) Recording the observations of such an analysis; 
iii) Checking/validating the understanding gained by the above two steps.

Furthermore, it is also goes beyond the idea just of recording requirements. It also encompasses the social and cognitive elements in the process of understanding the problem domain.

ELEMENTS OF REQ.ENGG.
Req engg contains a few fundamental facets to it: 
1) The most obvious of these happens to be the outlining of end-user requirements. Without these, this phase is useless and not complete. 
2) This being said, there are other functional requirements which emerge from stakeholders apart from the 'end user'. These are generally the managers and the administrators of the system. For instance, a manage would like to see how effective the system is on solving the problem for which it was created in the first place. An administrator may have to manage more functions such as managing user privilleges, maintaining proper logs of the system, etc. Such tasks are not required for a regular user of the system and hence they do not figure in the core feature list of the system.
3) Non-Functional Requirements: these requirements emerge from how the system will interface and interact with its enviroment. The system will have to interface with existing systems in order to fit into an existing infrastructure of solutions. For instance, in an online shopping store the product catalog will have to interface with existing check out and order management systems in order to give the customer a complete shopping experience. The product catalog, while being a self suffucient system in itself, alone cannot be effective when it comes to selling products online. The other set of requirements are to do with how the system interacts with the infrastructure on which it is deployed. Will respond well to a certain DBMS or an OS are important considerations which need to be accounted for. How will the system fare on various such technology stacks? What are the costs involved in maintaining such a system? How will the system scale as the data it manages acrues? 

While the 3rd set of requirements, the non-functional requirements, do not seem that important, it is essential that such things are looked with gross seriousness right from the very beginning. Sometimes this alson is the difference between successful and failed products.

GROUND REALITIES:
Apart from the above mentioned cats. of requirements and their sources, there are other ground realities about developing software:
1) Like we have seen time and time again, SOFTWARE EVOLVES because the REQUIREMENTS CHANGE. You cannot predefine a set of requirements and call it a day. Even is domains where the analyst is experienced, there can and will always be variations which need to be taken of care of effectively. These variations are in essence subtle and minor and thus go un-noticed. But their impact on the system is much larger and many-a-times at a very fundamental level. If such subtle changes in the requirements, especially in a 'known' domain, are not taken into account, then you are asking for trouble.
2) No one these days is interested in telling you what they want by going into the technicalities of things and solutions. What they are interested in is the final solution or product. Thus, unlike before where the customer/end-user and the analyst would discuss and outline the requirements, most requirements these days are derived out of market forces. In simpler terms, the process of requirement engg has now become market-driven rather than customer driven, more so anyway.
3) Also, you might decide to use COTS (commercial off the shelf) components for the building of the system, which might have its own set of constraints which will ultimately effect the requirements.
4) There are differences of opinion among various shareholders as well, which lead to a negotiation of requirements between the stakeholders and the analyst.

The Iteration cycle in requirement engg.: Elicitation -> Specification -> Validation -> Negotiation -> Elicitation...