Tech tutorials Differentiating and Defining Requirements
By Insight Editor / 24 Jun 2015 , Updated on 16 May 2019 / Topics: Agile
By Insight Editor / 24 Jun 2015 , Updated on 16 May 2019 / Topics: Agile
The success of a project can be directly related to how well business analysts can elicit and communicate both the business and system requirements. The overwhelming volume of requirements can be inundating and cause some to focus solely on the functions and features to be delivered. As a result, major requirements could be overlooked and impact project time, scope and schedule.
For these reasons, I’ll try to simplify and put into perspective the different types of requirements that should be taken into consideration when eliciting and documenting requirements for a new solution.
In general, requirements are statements regarding what a system must do or what characteristics are necessary to achieve a desired functionality. Well-defined requirements are necessary for any solution. Whether a client needs an enhancement or an entirely new application, it’s imperative to define requirements early in the project. Requirements drive the estimation of time and cost for implementation of a system and, ultimately, establish a common vision for the entire project.
Requirements can be further classified as business, functional or nonfunctional. A business requirement is simply focused on the high-level needs of the user (often the business user or nontechnical users). They describe “what” will provide value to the organization. As the requirements phases progress, the business analyst will create functional requirements that detail how the business requirements will be implemented. Example of business requirements:
Functional requirements relate directly to a process the system needs to perform by defining the capabilities the system should possess. During the analysis phase of the lifecycle, functional requirements evolve into use cases, process models and data models.
Use cases will define system behavior as a sequence of actions related to a specific user role. The use cases will trace back to a previously defined business need or requirement and, thus, allow you to verify the implementation fulfills those requirements. Examples of functional requirements:
Nonfunctional requirements define the operation of the system, such as quality, security, scalability, etc. These influence the design phase and are often used to help make decisions surrounding the User Interface (UI) and the underlying system architecture. Examples of nonfunctional requirements:
Business rules are frequently confused with business requirements. It’s important to understand the two are not synonymous. A business rule is a parameter placed upon the business by laws, regulations or other impositions. The rules enforce the desired behavior of system users and provide guidelines for ensuring compliance to the business requirements. Additionally, business rules are used within data modeling and help define the kinds of relationships different data entities share. Example of business rule vs. business requirement:
Eliciting and refining requirements is not innate — it’s a skill that’s worth refining and one that will render you an indispensable team asset.
Let’s look at five best practices you can use to help strengthen the completeness of requirements elicitation and improve the success of the solution delivery process: