Gathering the software requirements before starting the development of an enterprise application can be a tedious task, and a failure to do so adequately can have severe consequences, such as increased costs due to delays that are caused by identifying requirements later in the development cycle of the application. Applications that lack the important features to improve the business process workflow will lead users to stop using the application in the worst case.
The requirement-gathering process is complex and tedious, and can take months to complete in an organization. Covering all the steps involved in the process is beyond the scope of this book. This section tries to give a brief description about some of the important steps in the process of gathering software requirements.
For an application inside an organization, there might be various users who are stakeholders, and can define the requirements of the application. These users can be broadly split into two categories:
The workforce: These are the users who usually use the application to achieve a certain set of tasks. They are not concerned with all the features provided by the application, but rather what they focus upon is how well the application fits into their individual workflows. These users can provide requirements specific to what they work on, but may not be able to provide ideas about what they might require in the future, or what the other teams may require.
The management: The management consists of people who understand the business process of the organization and have a much broader view ofwhat the application should be able to do. These users may not be able to define the requirements of a particular use case, but can provide requirements considering what the application should do now and what future features might be needed.
Involving both kinds of stakeholders in the requirement-gathering process is important, and something that will define how well the enterprise application meets the demands of its users.
Once the users have been surveyed for what they would like to have in the application, the next step is to categorize these requirements. Broadly, the requirements can be categorized into two parts:
Functional requirements: These are the requirements that define the features and functionality of the application. For example, BugZot has the following functional requirements:
- Providing functionality for filing bugs by internal and external users
- Providing support for roles and permissions
- Providing functionality for dealing with file uploads
- Integrating with the email system to send emails when a bug changes its status, and much more
Nonfunctional requirements: These are those sets of requirements that do not affect the functionality of the software, but rather are implicit or explicit characteristics based on the functional requirements. For example, in BugZot, the following may be defined as some of the nonfunctional requirements:
- The application should provide security against common web attack vectors, such as XSS and CSRF
- The operational costs for the application should not exceedN% of the total budget
- The application should be able to generate backups in case a recovery is needed after a crash
Once the requirements are identified and categorized into functional and nonfunctional requirements, they then need to be prioritized according to their importance in the application. If this prioritization is not performed, it will lead to increased costs of development, delayed deadlines, and reduced productivity in the organization. Broadly, we can classify the requirements under the following categories:
- Must have:These are those requirements that are critical to the success of the application and that must be present in the application when it ships.
- Should have: These are those requirements that will enhance the functionality of the application but that need some further discussion about whether they should be added to the application.
- Could have: These are those requirements that are mostly enhancements, and the presence or absence of which won't affect the functionality of the application. These requirements can be taken care of in later updates to the application.
- Wish list: These are those requirements that are considered features that can be added at some later point in time, but which are not mission critical to the application. These features can be reviewed later for inclusion in the application update cycle.
Once the requirements have been identified, grouped, and prioritized, a document known as the software requirement specification is generated. This document describes the intended purpose, requirements, and nature of the software that needs to be developed.
The software requirement specification (SRS) will describe the following information:
- The intended purpose of the applications
- The conventions that are used in the document that are specific to the business process of the organization
- The features of the application
- The user classes who will be using the application
- The environment in which the application will operate
- The functional and nonfunctional requirements of the application
Once the SRS has been generated, it is sent for review and further negotiations. Once they are successfully completed, the application moves into the design phase, where an application mock-up is devised.