What is a Requirements Engineer and what does he do?
What is a Requirements Engineer
A professional who, in collaboration with stakeholders, defines, documents, validates and manages requirements. In most cases it is considered a role and not a job title.
A requirements engineer is characterized by:
- having in-depth knowledge of RE (Requirements Engineering), to apply appropriate RE practices properly.
- their ability to bridge the gap between a problem and potential solutions.
Typically the role of requirements engineer is part of several other roles that occur in practice. For example, business analysts, application specialists, product owners, and systems engineers frequently have to act as requirements engineers.
While this may seem like a very simple question, few people ever take the time to ask or to understand “what is a requirement”.
A requirement in our personal life could be to get a coffee every morning, but in software engineering a requirement can be defined as ‘A condition or capability needed by a stakeholder to solve a problem or achieve an objective’
A requirement, may relate to any number of problem domains that vary both by type and by scope, such as: Business Processes, Business Rules, Roles/Stakeholders and many more. The possibilities are nearly endless. Additionally, a requirement can be defined at whatever level of detail or depth. It can be defined at an enterprise level, a divisional level, a process level, an activity level, a task level, etc.
But now we know what a requirement is, where do these requirements now come from? As all the requirements arise from a need, we need to understand those Business Needs or the Business Problem Statement. Unless there is a need, we can’t think of fulfilling it. A Requirements Engineer starts with a broad and general description of what needs to be done and then starts working with key stakeholders to define the project scope and needs.
Talking about stakeholders, it’s important to know about who they are and to be aware how critical their involvement is in the project. Be aware that a stakeholder is any person or organisation that has some type of impact on the project. Different people have different ideas of requirements.
- For a product owner, requirement is as simple as the ability to use or sell the product that helps with the business and revenues.
- For a project manager working on that solution, requirements are to get the solution developed with best quality that meets all the expectations of the client and minimize resource allocation to bring most benefits to the company.
- For a team lead, requirements are to identify the technical challenges, build a maintainable architecture and get the solution developed smoothly.
- For a developer, requirements are to develop the assigned feature or make changes in the software as requested.
- For a user, supportteam, administrator, security officer, cloud provider, regulatory body or any other stakeholder, different requirements might apply.
Identifying the responsible stakeholders is an important first step. Since not all stakeholders are important for every project, it is a primary task to identify the right stakeholders and their say in the decisions to keep things smooth in the long run. When too many or incorrect stakeholders are heard, it becomes real hard to get the requirements clear and come to any conclusion.
Once the project outline and the stakeholders are known the following tasks need to be performed: Elicit, Group, Analyze and Document requirements. As I am mostly involved withing Agile projects, I see this as an ever repeating proces covering ever changing or deepening stakeholder needs.
Once the stakeholders are known, you need their input to get an overview of all the requirements. This search for requirements is referred to as ‘requirements elicitation’. It is the practice of researching and discovering the requirements of a system. Since each stakeholder plays a different role in the project, they can have different requirements too. The biggest challenge for a Requirement Engineer is to extract useful information from all these stakeholders that matches the overall project goal. This is because each of them view the project from their own perspective. Try to get the most valuable information using techniques such as interviews, questionnaires, joint group discussions, prototypes or use cases.
As this requirements elicitation process may appear simple, issues may arise that complicate the process.
- Problems of scope. The boundary of the system is ill-defined or stakeholders specify unnecessary technical details that may confuse, rather than clarify, overall system objectives.
- Problems of understanding. The stakeholders are not completely sure of what is needed, don’t have a full understanding of the problem domain, have trouble communicating needs, omit information that is believed to be “obvious,” specify requirements that conflict with the needs of other stakeholders, or specify requirements that are ambiguous or not testable.
- Problems of volatility. The requirements change over time. The rate of change is sometimes referred to as the level of requirement volatility.
As requirements become more and more available and clear, a good way to organize this growing amount of valuable information is essential.
In agile software development approaches, there is always more to do than there is time or funding to permit, so I would suggest to use the MoSCoW method to categorize the requirements. The MoSCoW method is a prioritization technique used in management, business analysis, project management, and software development to reach a common understanding with stakeholders on the importance of each requirement. The term MoSCoW is an acronym derived from the first letter of each of four prioritization categories (Must have, Should have, Could have, and Won’t have). All requirements are important, but they are prioritized to deliver the greatest and most immediate business benefits early.
An other simultaneously usable approach to categorize the requirements in to epics. As Epic is a big chunk of work that has one common objective, all related requirements can be grouped within this Epic. And as Epics are detailed further in User Stories the requirements can be logically and functionally structured this way.
The Requirements Engineer should analyze the requirements whether they are clear, complete, unambiguous, consistent and testable. And if not make sure to take appropriate steps to make sure they are.
These requirements have to be documented and made available to all stakeholders. Changes are welcomed in an agile environment, but the impact has to be clear and appropriate actions have to be taken to make sure it is clear at all times what the current state of the requirements is.
Use cases are a popular technique for documenting and understanding requirements. Use case diagrams depict who will use the system and in what ways expects to interact with the system. The benefit of using ‘use cases’ to document requirements, is that both business and technical users are able to really understand them and provide feedback on them. As Requirements Engineer you can use them as a communication tool, as a common language about what the software will do.
Do the requirements really define the system that the customer really wants. To verify before, during and after development, what we are building is actually what we are supposed to build, it is key to keep the stakeholders close at all times. A requirements engineer in an agile project is always aware that requirements might need deepening or changing as the project progresses, and he needs to be on top of the impact of these changes.
To validate requirements are still correct, and what is expected from the product the following checks can be performed:
- Completeness checks
- Consistency checks
- Validity checks
- Realism checks
- Ambiguity checks
The output of this validation is the list of problems and agreed on actions of detected problems.
There are several techniques that can be used to find, as early as possible, problems with the requirements.
- Test case generation: create test cases as early as possible, as it is generally believed that if the test is difficult or impossible to design than, this usually means that requirement will be difficult to implement and it should be reconsidered.
- Requirements Reviews: the reviewer systematically analyses if all is clear, complete, unambiguous, consistent and testable.
- Early delivery: the sooner the product is showed the quicker feedback can be given.
Requirements quality can be improved through these approaches:
- Visualization. Using tools that promote better understanding of the desired end-product such as visualization and simulation.
- Consistent language. Using simple, consistent definitions for requirements described in natural language and use the business terminology that is prevalent in the enterprise.
- Guidelines. Following organizational guidelines that describe the collection techniques and the types of requirements to be collected. These guidelines are then used consistently across projects.
- Consistent use of templates. Producing a consistent set of models and templates to document the requirements.
- Documenting dependencies. Documenting dependencies and interrelationships among requirements.
- Analysis of changes. Performing root cause analysis of changes to requirements and making corrective actions.
Managing requirements involves the transition of stakeholder requests into a set of key stakeholder needs and system features. These, in turn, are detailed into specifications for functional and non-functional requirements. And functional requirements are then detailed into use case specifications, which are the basis for system design, implementation, system testing and user documentation.
This can be visually depicted in the Requirement triangle
Solution space includes any product or representation of a product that is used by or intended for use by a customer. Any product designs, build product exists in solution space. Problem space is where all the customer needs that you’d like your product to deliver live. Customers are also not likely to serve you their problem space needs on a silver platter. It’s therefore the product team’s job to elicit these needs and define the problem space. The reality is that customers are much better at giving you feedback in the solution space. The feedback you gather in the solution space actually helps you test and improve your problem space hypotheses.