Okay, so you’ve come to my blog post. You want to know about software requirements elicitation and specification? Then stay with me.
I’ve talked about software requirements before, so what’s this deal with elicitation and specification, then?
First, let me explain the elicitation process. We start by gathering the requirements through discussions with the client and end users (through interviews, surveys, etc), then we make some sort of prioritization on these (through task analysis, etc). Now that we have all this, a discussion/negotiation with the stakeholders is made (here you might want to come up with some prototype to have more valuable feedback). At any point you might realize you have to go back to a previous phase to do modifications, or repeat them entirely. Everything must be documented.
Now, software requirement specification is supposed to be this document you create ONCE the requirements have been collected. This document will have specifications on how the intended software will interact with hardware, external interfaces, response time, limitations, etc. You can imagine things get pretty technical at this point, so it’s preferred that this document is written by some sort of system analyst. You’re going to want this document to be useful for the software development team, so…
This document’s appendix would hopefully look something like:
- user requirements in natural language
- technical requirements in structured language
- design description in pseudo code
- GUI screen prints
- conditional and mathematical notations
You definitely don’t want this to happen:
All this is meant to be valuable information upon which you’ll know what has to be accomplished. Even if done simultaneously with other phases of the project (agile) or all focus is put on this phase until it’s complete (waterfall), this phase is one you definitely don’t want to miss. Knowing what your users want and what think of your product is vital.
If you want to take your readings any further, these were my sources:
