True story: On Monday last week a lady came to my house to check out a microwave I was selling online. After a few minutes of inspecting it, she decided to buy it. After giving me the money, she then asks "do you have a bag for the microwave?" I told her I did not have a bag big enough but still offered her one from the grocery store (I knew it was not going to fit in there). Since she was unable to fit the microwave into the bag I gave her, she got a bit upset and started complaining. We both started getting frustrated and just before getting into a heated argument, she started forcing one end of the microwave into the grocery store bag. Just before tearing apart the bag she then asked for another one an started forcing the other end of the microwave into the other bag. At that moment I had no idea was she was trying to accomplish and for me, it did not even make sense how she was planning to hold the bag(s) and carry the microwave. At that moment my girlfriend had the brilliant idea of asking her "do you want the bag for carrying the microwave or do you want to protect it while carrying it?" To what she responded, "I just want to protect it." ... Everything made sense. Her problem was not finding a way of carrying the microwave. Instead, it was finding a way of protecting it while she was on her way home.
In the context of the above scenario, the lady failed to express her real problem explicitly. On the other hand, I was unable to identify her real needs and the rationale behind her request. She was asking for a bag but what she needed was a way of protecting the microwave. Putting it inside a bag is one of many possible ways she could have protected the microwave.
In essence, the lady was frustrated because, although I was given her the bag she was asking for, I was failing to solve her real problem: finding a way to protect the microwave. This scenario brings me to today's topic: Requirement Engineering. This is a phase in the development process that is not taken as seriously as other phases of the development process. But if done inappropriately, it could have devastating consequences. If you think I am exaggerating then let me tell you that 42% of startups fail because the market does not need or want the product or service they offer . In other words, either:
- The product or service provided does not solve any real problem.
- The product or service addresses the correct problem, but it is not a problem that causes real pain.
- The product or service is targeted to the wrong audience.
Regardless of why the market did not want the product, the possibilities of failing could have been reduced with good requirement engineering practices. So what is requirements engineering? How is it related to the success and failure of a project? What are the challenges associated with it? These are some of the questions we will be exploring in today's article.
What is Requirements Engineering?
Requirements engineering is the branch of software engineering concerned about the goals and constraints of a software system . Requirement engineering activities are essentials to ensure that the to-be-developed software system satisfies the needs and expectations of its stakeholders and users. Requirements engineering is more than just asking customers what their problem is and what they want in their system. There are a series of activities that are part of the requirement engineering process, but what are those activities?
Requirement Engineering Activities
Some of the activities that take part in the requirement engineering process include the following :
- Requirement Elicitation & Analysis: Finding and structuring the requirements of the system. Part of the elicitation process includes identifying key stakeholders and users and identifying their needs and business goals.
- Requirement Tracing: This activity involves comparing requirements against other information. For example, tracing requirement to goals is a way of ensuring that all requirements are associated with at least one goal. Doing requirement traceability is essential to ensure all requirements have a purpose and not goals have been left unmet.
- Requirement Validation: During validation stakeholders and users check that the requirements match their demands.
- Requirement Verification: This activity is carried out to ensure the final product fulfills the requirements and needs of its stakeholders and users. It is recommended to not leave verification activities until the end of the development process. Instead, the product should be continuously verified are various stages of development. The reasons for doing so is that if changes to the software are required, making those changes at the end of the development process is more costly and time-consuming than making them early in the process.
- Requirement Management: It is common for business goals to change, for requirements to change, and for customers to request unrealistic or conflicting demands. Therefore, requirement management involves dealing with such issues, while ensuring the system is developed on-schedule and on-budget.
What are the challenges associated with Requirement Engineering?
There are challenges associated to all engineering disciplines, and requirements engineering is not the exception. The type of challenge experienced in requirement engineering depends on the kind of activity been done. Some examples associated with requirement engineering include the following :
- Stakeholders typically have difficulty expressing their needs. In other words, they do not know what they want or what their real needs are.
- As a result of not knowing what they want, stakeholders typically ask for solutions that do not meet their real needs.
- Stakeholders may have conflicting demands. As the number of demands and number of stakeholders increases so does the possibility of having conflicting demands.
- Sometimes the product to-be-developed is entirely new in a given domain; i.e., there are no users of the product. In such cases, eliciting and validating requirement becomes challenging because there are no users.
- Human language is ambiguous. Such ambiguity can result in misunderstandings and confusions that lead to writing unprecise requirements. Unprecise requirements increase the possibility of creating systems that do not satisfy user's needs.
- A requirements specification document shall contain "what" the system needs to satisfy and "why." It shall not, however, contain information regarding "how" the system should do it. It is common for the analyst to include in the specification document information about "how." Doing so adds unnecessary constraints to the system.
In order for a project to succeed it is necessary to identify the key stakeholders of the project, their goals, and needs. Failing to do so, could result in building a system that targets the wrong audience, solves the wrong problem or no problem, or does not solve the problem correctly.
For your next project instead of starting by writing code or designing the interface. Identify who you main stakeholders are, understand their needs and goals, and then determine what the best approach to solving such a problem is.
If you enjoyed this article, please recommend and share. Don't forget to subscribe and follow me on Twitter to stay up-to-date with my latest posts. See you in the next article.
 Software Requirements: Styles and Techniques, chapter 1 by Soren Lauesen
How would you rate this article?