Imagine the following scenario: For the past few months, you have been thinking of creating a new mobile app. You have not spoken to any potential customer yet but you believe there is a real problem in the market and your app is just the perfect solution. You already have in mind the name, the logo, and even how the app would look. Since you read my previous article about why creating a requirements document is essential for the success of a project, you decided first to understand the needs of your potential customers and write a requirements document before starting to build your app.
Just before you start writing the requirements document, you ask yourself two questions:
- What information should the requirement document include?
- Which technique can be used for eliciting requirements?
It is good you have decided to create a requirements document before starting to build your app, but if it is incomplete and incorrect, it is useless. Therefore, in today's article, I describe techniques for eliciting requirements as well as the content that a requirements document should include.
What information should a Requirements Document Include?
I have a question for you: what comes to your mind when you think on a requirements document? Most likely you think of a document containing a list of statements expressing the functionality the system shall have. Some examples of those statements include: The system shall be able to allow the user to create a profile, The system shall display the date in 24-hour format, or As a user, I want to create an account in order use the service.
Statements as the ones shown above are known as "functional requirements" because they specify the functions the system should have. Although functional requirements are important, they are not the only information that a requirements document should include. So, what other information should be included?
- Data Requirements: They specify the type of data the system should accept as input as well as the data the system should output. Additionally, data requirements should specify the format of the data . For example, if you are building an app for storing books, most likely the data that your system will handle includes the name of books, date of publishing, and author name. Your requirements document should specify these data and its format.
- Background Information: Serve to facilitate the reading of the document. It is recommended to include a glossary, diagrams, and tables to help the reader better understand the content and context. Additionally, including a rationale for each requirement help the reader better understand the purpose of each requirement and their relationship to the goals of the project.
- Functional Requirements: This is the type of requirement that is commonly found in a requirements document. They specify the functions of the system; i.e., the tasks the system should be able to perform . Back to the book storing app example, possible functional requirements may include: The system shall allow users to search for books by name. The system shall allow users to sort books by publication year.
- Non-Functional Requirements: Also known as "Quality Requirements." This type of requirements specifies how well the system should perform its intended functionality. Non-functional requirements are associated with internal quality aspects of the system such as performance, usability, maintainability, and availability.
Non-functional requirements do not add new functionality to the system. Instead, they improve the way the system operates. It is essential to keep in mind that the certain quality requirement may be challenging to define as a result of the difficulty to measure them. For example, how do you objectively specify the "easiness" for repairing defects when you do not even know the defects that you might encounter?
What are Requirement Elicitation techniques?
Requirement elicitation is the process of finding and formulating requirements. Ideally, the elicitation process starts by finding out information about the goals of the project, the problem to be solved, and how the problem is affecting the customer. Once this information is gathered, the next step is to formulate possible solutions to the problem. Finally, a solution is selected, and requirements are written. In real life, the process is not linear. Goals change, the environment changes, technology improves, and priorities change. All of these aspects affect the direction of the project .
The following table shows various elicitation techniques and the kind of information you can elicit with each one. Keep in mind that each technique has its pros and cons. Depending on the information you are trying to elicit one technique
might be more appropriate than another.
Challenges during the Elicitation Process
If you think eliciting requirements is as easy as asking the user what they want, think twice. Some factors that make the elicitation process challenging include the following:
- Frequently, stakeholders are unable to express what they want clearly. Moreover, sometimes the problem they think they have is not the real problem.
- Many users have difficulty expressing what they do and why they do it.
- Stakeholders might find difficulty imagining new and different ways of doing things. Additionally, stakeholders might reject a proposal just because they are resisting to change.
- It is common for different stakeholders to have conflicting requirements.
- Stakeholders frequently express a long list of requirements and consider all of them to be of high priority, which is not usually the case.
To have a complete and useful requirements documents, it is essential to include information regarding functional requirements, non-functional requirements, data requirements, and background information. Such information would allow readers to understand the context and purpose of the project better. There are various elicitation techniques that you can use for finding information and the technique to be used depends on the information you want to find out. Eliciting requirements is not an easy process as a result of the challenges you will encounter when interacting with stakeholders.
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 one.
 Software Requirements: Styles and Techniques, chapter 1 & 8 by Soren Lauesen
How would you rate this article?