You may have heard this story before: A business stakeholder has a new project for the website or software application. The business stakeholder writes up a brief, detailing their experiences for the project and promptly delivers these to the developer.
The developer reads through the brief and immediately starts work, not bothering to ask questions about the assumptions they are making nor the assumptions implied by the brief.
Soon the project is nearing completion, and the business stakeholder is frustrated—why is the project not delivered to their specification? Well, the answer is simple: they did not engineer the requirements to build a solid bridge of understanding between the developer and the business stakeholder.
The bridge, or missing link, in this scenario, was a requirements engineer.
What is a Requirements Engineer?
It is not uncommon for business stakeholders to document their expectations for a project initiative for a website or software application in a brief, to be handed straight to a developer—no middleman included.
The developer takes those written specifications, and because he’s read the documentation, and perhaps even heard the contents of the documentation, believes he and the stakeholders have a shared understanding of what the expectations are for the project.
That is until the project unravels—costs overrun, deadlines extend, and the website or application doesn’t come close to meeting the functionality or appearance expected.
Now the two are looking at each other with blame—the stakeholders are frustrated with the developer for not delivering their expectations, and the developer is frustrated because the brief lacked depth and definition of the technological infrastructure and deployment steps that needed to take place in order for a successful delivery.
What has occurred here is gross miscommunication; they needed a requirement gathering expert to extract out of the stakeholders what requirements they wanted to see in the project. Specifically, what the system must do, how it must behave, the properties it must exhibit, the qualities it must possess, and the constraints the system and its development must satisfy.
Then, after a thorough investigation of the system and both the physical and organizational units that are affected by the existing problem puts all these valuable details into a written document that can be understood by all members, including the business and its stakeholders, as well as the requirements engineer’s own development team.
He must also verbally express those requirements in depth to all members, clearly defining what the stakeholders' needs mean in terms of system design.
The requirements engineer’s job does not stop here. He is charged with frequently communicating with stakeholders and the development team throughout the project’s lifecycle to ensure:
- Feature expectations are being met along the way
- Conflict or ambiguity in requirements are promptly resolved
- Feature creep is avoided
- The final system or product conforms to the stakeholder’s needs, rather than attempting to mold user expectations to fit the requirements
- Every aspect of the project development process is documented from start to finish
For instance, you are a large retail company that has an existing computerized billing system that was acquired from a company that no longer exists. Your company has recently started a new direct marketing service over the internet and needs to adjust the billing system to handle the new service.
A requirements engineer would be called in, and he would go through the following process:
- Elicitation: discovering, reviewing, documenting, and understanding the user's needs and constraints of the system.
- Analysis: refining the user's needs and constraints.
- Specification: documenting the user's needs and constraints clearly and precisely.
- Verification: ensuring that the system requirements are complete, correct, consistent, and clear.
- Management: scheduling, coordinating, and documenting the requirements engineering activities
At the end of the project, the retail company receives a new, tested version of the system that successfully handles the internet-based sales. Additionally, the company has detailed specifications of the billing system to help in the future maintenance of the software.
So, as you can see, the requirements engineer acts as a bridge between the real-world needs of users, customers, and other constituencies affected by a software system, and the capabilities and opportunities afforded by software-intensive technologies. He adeptly gathers software requirements, effectively balancing the needs of business stakeholders with the limitation of various technologies.
Why Might You Need a Requirements Engineer?
A requirements engineer facilitates the development of human-centered, human-focused designs, which makes him best suited for businesses looking to improve human activities in some way. This could be:
- A large charity that wishes to introduce a system to provide its employees and stakeholders with better access to personnel records and payroll calculations.
- A retail company who needs to modify its billing system to handle a new direct marketing service over the internet
- A real estate agency that needs an application to manage its clients and properties, and to keep track of details/data
- A car manufacturer that needs a computer-aided system to manage and track its fleet of vehicles.
What Value Can a Requirements Engineer Bring to Your Business?
The number one cause of project failure is due to miscommunication between developers and the stakeholders.
And when you think about it, you can understand how such occurs: stakeholders see their system at the surface level and thus describe things with simplicity, like “I want a checkout feature and blocks to display our products.” But this means very little to the developer who works below the surface with the infrastructure and carrying out the deployment steps.
The stakeholders and the developers are in two different area codes, as the saying goes.
A requirements engineer has one foot on each side and has the ability to put business analysis systems in place to collect requirements, prioritize them, and push them to the development and delivery teams to drive growth in key performance indicators per your stakeholders.
The system resolution he brings about with appropriate technologies often means leaner operations and, in turn, reduced waste by ensuring requirements which are clearly tied to business goals make it into the project—and those that don’t support business goals do not make it in.