Requirements Classification
1.Business Requirement
Statements of goals, objectives or needs of the enterprise
- Reasons why a project is initiated
- The objectives that the project will achieve
- The metrics which will be used to measure its success
e.g. The taxi company noticed that the ride-sharing service providers, such as Uber, are gradually taking over the market; Considering such situations, the Taxi company plans to go into ride-sharing, also. This is their business requirement. From it, it indicates that Business requirements enable the organization to remain profitable, relevant and then also continue to stay within the business space.
2.Stakeholder Requirement
Describe needs that a given stakeholder has and how that stakeholder will interact with a solution. They are developed and defined through requirements analysis.
e.g. If we want to develop a ride-sharing application, we may need a development team in the first place, putting consideration of the needs of service customers, local legal policy, etc. In short, the stakeholder requirement is the needs of stakeholders, ranging from external to internal related person.
3.Solution Requirement
Describe the characteristics of a solution that meet business requirements and stakeholder requirements. They are developed and defined through requirement analysis.
They are frequently divided into sub-categories:
3.1 Functional requirements: Describe the behavior and information that the solution will manage. They describe capabilities the system will be able to perform in terms of behaviors or operations.
e.g. For the newly-developed ride sharing app, the users are able to request for rides, in other words, users are able to make their payments using this app; Users are able to review the order, give the feedback on the performance of driver and even can get the information on how far away the vehicles are, etc.
All of these are refer to Functional requirements. In essence, the functional requirements are the designs that we are going to come up to meet the particular business needs. In other words, it describe what the solutions does "features" or characters.
3.2 Non-functional requirements: capture conditions that don't directly relate to the behavior or functionality of the solution., but rather describe environmental conditions under which solution must remain effective or qualities that the system must have.
e.g. When we are using the ride-sharing app under weak internet, it's requested to have a technology in place, making it effectively work still.
4. Transition requirements
describe the capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to a desired future state, but that will not be needed once the transition is complete.
They are developed through solution assessment and validation.
e.g. Before the developing work, it's required to provide training to developers, clarifying how the new solution would be done, how we are going to bring in this new solution without disruption to the service in any way. These are generally named as “Change Strategy”; Also, in future, the app should be upgradable, for example can upgrade from version one to version two without losing data and won' t make users be distraught. In a nutshell, transiting from current to a desired future state, it refer to as transit request.
Requirement Documents
BRD
- Focused on the business perspective;
- Captures the needs/expectations from the customers
- Address what's the business wants to achieve.
FSD
- What's needed by the system users
- Requested properties of inputs and outputs
SRS
- What's the solution will do to effectively meet stakeholders expectations/needs
- Processes: develop process, solution process, etc.
