Business Analysis #2: What actually are “Requirements”?
We always hear about the word “requirements” when it comes to a project. And as someone who is looking to go into a role of a Business Analyst, “requirements” will play the biggest role in your job. That being said, this blog explores what “requirements” actually are, the different types of requirements and the importance of them. Without further ado, let’s dive in!
Let’s start with an example that manifests the importance of properly identifying requirements.
A user who is using an already released software (which is a personnel system) calls the developer and says that there is a “bug” in the system. The “bug” as the user says is that an employee has legally changed her last name, but the system does not accept that change. The system only accepts a name change only if someone’s marital status has changed. Anyhow, without the system accepting the changed name of the employee, her paycheck is unable to be cashed.
The developer says that it is not a “bug” and blames the user on why they didn’t inform of such a possibility. The user on the other hand says they thought the developer would know that people could change their name legally anytime they want. The developer argues back on the statement that he is unable to read anyone’s mind.
These kinds of situations are not uncommon in the software industry. What do you think is the problem here?
Well, the system’s capability to change a previously entered name is a requirement of the project. The problem here is that the requirements are not properly identified. The problem areas might include informal information gathering, implied functionality, miscommunicated assumptions and poorly specified requirements. The inadequacy of user inputs and the shortcomings in specifying customer requirements are major contributors to unsuccessful projects.
It is hard to have all requirements identified in one go and the entire process could be ambiguous. But with experience and knowledge gathered, the mistakes could be fewer.
In this blog, we will be delving into what “requirements” actually are.
Different people have different interpretations of “requirement”. One of the definitions is that it is “a property that a product/system/software must have to provide value to a stakeholder”. Ian Sommerville and Pete Sawyer said that,
“Requirements are a specification of what should be implemented. They are descriptions of how the system should behave, or a system property or attribute. They may be a constraint on the development process of the system”.
The above definition can be considered much more thorough. A requirement should be looked at from both the user’s and the developer’s point of view. While the user views the external system behavior, the developer views more internal characteristics.
Levels and types of requirements
(as given in the “Software Requirements, Third Edition” by Karl Wiegers and Joy Beatty)
Software Requirements are of 3 distinct levels: business requirements, user requirements and functional requirements. Also, every system has several non-functional requirements.
Business Requirements
These requirements describe why an organization is implementing the system; that is, the business benefits the organization is planning to achieve. For example, a restaurant might want to streamline their ordering process for customers and improve operational efficiency. This goal might lead to the idea of implementing an online ordering system. Business requirements typically come from the funding sponsor for a project, the manager of the actual users, the marketing department, or the business executives. Business requirements are usually documented in a vision and scope document. These requirements are just a high-level understanding of the overall necessity, but definitely not enough for the actual development process.
User Requirements
They describe goals or tasks the users must be able to perform with the product and would provide value. User requirements include descriptions of the system’s attributes or characteristics that are important for user satisfaction. Use cases, user stories and event response tables can be used to represent them.
User requirements should be provided by the actual users of a system. They describe what the user will be able to do with the system. For example, for a mobile check deposit feature, the user story of the requirement might read as: “As a customer of the bank, I want the mobile banking application to include a feature that allows me to deposit checks remotely using my smartphone camera. This feature should enable me to take photos of the front and back of the check, enter the deposit amount, select the account for deposit, and submit the deposit electronically. Upon successful submission, I expect to receive immediate confirmation of the deposit, including the deposit amount, transaction reference number and expected processing time”.
It's also important to note that a project might have multiple user classes; other stakeholders whose needs also must be taken into account. Apart from the direct users who provide requirements, other stakeholders involved in the project one way or other will provide their requirements as well.
Functional Requirements
These requirements describe the behaviors the system will exhibit under specific circumstances. They should showcase what the developers must implement to let users accomplish their tasks (user requirements). For example, the functional requirement of a product search and filtering functionality will read as: “The e-commerce website should allow users to search for products using keywords, apply various filters to refine search results and sort products based on different attributes”. Note that the BA should define what the filters and sort options should be.
The functional requirements are documented in a Software Requirements Specification (SRS) or a Functional Requirements Specification (FRS). This is also called Business Requirements Document, Functional Spec, requirements document, etc. This document describes as much in detail as possible the expected behavior of a software system and is used in development, testing, quality assurance, project management and other related functions.
System Requirements
These requirements describe the requirements for a product of multiple components or subsystems. For example, a cashier’s workstation in a supermarket has a bar code scanner with a scale, a hand-held bar code scanner, a keyboard, a display, and a cash drawer. These hardware devices are all interacting under software control.
Business Rules
These include corporate policies, government regulations, industry standards and computational algorithms. Although business rules are not software requirements themselves, the system must have functionalities to comply with these rules. Thus, looking at the business rules thoroughly will provide the BA with a handful of requirements for the system.
Non-Functional Requirements/Quality Attributes
These are the quality factors, the quality of service requirements and constraints. They describe the product’s characteristics such as performance, safety, availability, portability, scalability, etc. For example, a CRM system shall be designed to support scalability and ensure optimal performance to accommodate increasing user loads and growing data volumes.
To demonstrate the use of the 3 distinct levels of requirements, consider the implementation of a project collaboration platform. The business requirement can be that the software serves as a centralized platform for managing and collaborating on projects across different teams and departments. The user requirements could be that the users should be notified of new task assignments, upcoming deadlines, changes to task statuses, set personalized reminders, etc. The functional requirements can be to include a gantt chart visualization feature to provide users with a graphical representation of project timelines, dependencies and milestones. It should allow users to create, edit and update project schedules, allocate resources and visualize critical path analysis.
In conclusion, we need to understand that every project has requirements. Yes, it is hard to determine what the requirements are. But without them, you can’t tell when the project is done and whether it has met its goals. If someone thinks that the time spent on requirements are too much, they should definitely think about the money wasted when the project doesn’t pay enough attention to requirements. Thus, the requirements serve as the foundation upon which the entire development process is built and they are the fundamental to the success of any project.
