Elic… what? that sounds complicated. Well, it actually isn’t. I’ve talked about functional and non-functional requirements before, but this is something completely different.
As you may remember, the first step of the SDLC is collecting infomation, requirements elicitation and specification are part of this step.
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.
Requirements elicitation practices include:
- User observation
- Use cases
- Role playing
Once you know what the customer wants, you’ll be able to do the software requirement specification (SRS), which is a process of recording the client’s requirements in any form, like a document, a graphical representation, a graph, a pie, a cake, brownies, etc.
SRS also contains the functional and non-functional requirements and other specification types, for example: performance, maintainability, reliability, resource, etc.