The Basics of Requirement Engineering

Quentin Lee - 8 October 2018

Last summer, I was asked to build a website for a client. Although I didn't have a lot of experience building websites (but now I have), I decided to accept the job. When setting up all requirements for the website, I realised I was not suitable for this job before I even started programming. Setting up all requirements before starting on the website did save me and my client a lot of time and money. I realised how important requirement engineering is and therefore this post will be about the basics of requirement engineering.

Requirement engineering consists of 4 phases.

  • Feasibility study
  • Requirement analysis
  • Requirement specification
  • Requirement validation

During the first phase, the feasibility study, you have to identify if you can build the software with the knowledge, budget and technology available. The output of the feasibility study should be a feasibility report which tells the client whether it is recommend to continue with the project. (In my situation, I already found out I didn't have enough knowledge to build the website, so my feasibility report discommmended to continue building the website)

After you have done the feasibility study and the outcome is positive, you can start with the requirement analysis. During the requirement analysis, you talk with users, managers, stakeholders and others to come up with requirements. After you’ve set up the requirements, you should organize the requirements and put requirements which relate to each other together. The next step is to prioritize all requirements. Which requirements are most important. Which are least important. You could use the MoSCoW method to prioritize the requirements. Using this method, you will prioritize the requirements on must have, should haves, could haves and won’t haves. You can find more information about the MoSCoW method here.

After prioritizing requirements, you can start with the requirement specification. Here you use multiple different diagrams and natural language to specify the requirements. You shouldn’t use difficult terms since your client should also understand what the requirement means. After all, you should put the requirements in a software requirements document which is often used as a contract between the developers and the client. Using this document, both developers and client know what is expected from each other.

At this moment, you’re done with setting up the requirements. The last phase is requirement validation. In this phase, you go through all requirements and check if all of the following is applied:

  • Validity: do the requirements have what the customer needs.
  • Consistency: the requirements shouldn’t conflict with each other.
  • Completeness: all requirements should be included.
  • Realism: checks whether it is still possible to implement the software with the technical skills, budget and technology.
  • Verifiability: requirements should be able to be verified. You should be able to test that a certain requirement is implemented.

After validating the requirements you should have a proper document containing all requirements to which both developer and client agree.

If you have any question about requirement engineering, leave a comment below or send me a message on Twitter.

Add a reaction