Is rapid prototyping incompatible with software requirements specification?

Question

From what I've learned last term on SWE courses, a big part of it is writing documents, so it seems that a software requirements specification (SRS) should earn points for my end-of-course project.

However, I will be more comfortable if I use prototyping, i.e., I make a small thing that works for the most trivial of situations and gradually add up features and improvements. LVS 68:1996 doesn't seem to recommend mixing these two things together.

Is it possible to still maintain my preferred approach to development, and have some usable requirement specification document?

Answer 1

SRS is used to put on paper the requirements for the whole project. Prototyping is used to prove that you're on the right path.

When you write the SRS, you may not always be sure whether:

• The feature is feasible,

  What if, technically, it is feasible, but your team will spend years developing it, because of the constraints of the language, the platform or the framework? A prototype let you know quickly that you're on the wrong path.

• The approach you chose within the SRS is the right one,

  There may be several solutions for the same problem, and it may be unclear, without further research, which one of them is right.

  While SRS shouldn't enter in the implementation details, it is often difficult to be abstract enough to let developers pick the right approach. In order to avoid losing days, weeks or months later, creating several prototypes may lead you towards the most viable solution. It won't always get it right, but still mitigates the risk to write requirements which encourage the wrong solution.

• The feature, as you describe it, is indeed what customers need.

  Often, stakeholders don't know what they want.

  One way is to write SRS, sign it, ship the product and when stakeholders will tell that it's useless, because it doesn't answer their needs, reply that it's conform to the SRS they signed.

  Another way is to use Agile. It gives you the flexibility to adapt your product to the actual needs of the customers, and it gives the stakeholders the flexibility to adjust their needs based on something concrete.

  Finally, a third possibility is to prototype parts of the application where stakeholders are not sure of their needs or don't agree among themselves, and only then sign the SRS.

In those cases, prototyping comes prior to SRS to make things clear.

Answer 2

If you don't have a requirements spec, you don't know what you're supposed to be doing. Requirements come before everything else.

Prototyping is a valid way of proving whether something can be done, but this is not part of the requirements, its part of the solution delivery. Sometimes you're given a specification and tasked to writing a solution document to describe how you will implement the requested features. This is where some prototyping comes in, as you determine your solution (and to be fair, I tend to "prototype" my solution before documenting what I "will do" ;) )

Answer 3

If you don't know what you are doing, then the last thing you should do is write a requirements spec, as all that will give you is a requirements spec written by someone who doesn't know what they are doing.

Maybe someone else knows what they are doing - if so, they should write the spec. If not, you have to learn what needs to be done. And for this it makes little difference whether its a new activity that literally noone knows how to do, or there theoretically is someone who could tell you, but you don't have the budget to pay them to spend time doing so.

The problem with requirements specification as as a learning activity is that it doesn't give any feedback as to whether what you have specified is right or wrong. There is no such thing as a requirements compiler or test tool that comes back and says 'this is wrong, it makes no sense, doesn't solve the problem, or noone will like it'.

Exploratory prototyping is one technique that suits some people as a means of learning enough about a domain to write a useful requirements spec. But you shouldn't assume it will be the best in any particular case without considering alternatives. And you certainly shouldn't be expecting to get much use out of any software produced as a byproduct of that learning process, any more than you should expect to be able to sell the notes you made in class for some fraction of the price of a university education.