Software requirements elicitation and specification

Yeah, more requirements, you may have thought that functional and non-functional requirements were the only thing you need to know; buy don’t need to worry because those are easier to understand.

9593217572_a2bc170950_z
flickr photo by ChrisL_AK https://flickr.com/photos/fncll/9593217572 shared under a Creative Commons (BY) license

To explain this better, you need to remember the first step of the software life-cycle (you can see my post here): gathering information. As I wrote on a previous post, in this step, you obtain the functional and non-functional requirements for your software, but that is not all, Software requirement elicitation and requirements specification are also part of the gathering phase.

Requirement elicitation, is actually the first thing you have to do in the software life-cycle and is the practice of finding out what the customer or user wants. In an informal concept, is more like a wish list of requirements. But there are many problems that are almost impossible to avoid because it depends more of the customer, for example: he doesn’t know exactly what he wants, he thinks that some specifications are obvious or his needs changed and want the software to do something else.

After knowing what the customer wants, you are ready to do the Software Requirement Specification or for short SRS, which is a process of recording the requirements in any form, and it can be in a document, a graphical representation, etc.

RS also contains the functional and non-functional requirements and other specification types, for example: performance, maintainability, reliability, resource, etc.

According to the this page:

A software requirements specification SRS is a document that captures complete description about how the system is expected to perform. It is usually signed off at the end of requirements engineering phase

For more information you can visit those pages: