Requirement Engineering: Specifications in which form?



The day before we started the new project, my team member got curious. He asked, “Are we going to receive requirement specifications from customer? How will the specifications look like? Let us make sure that there are no communication gaps.”

I responded, “In a document with text, and UML notations in our standard format. We will get wireframes too.”

We had a short pause. I continued, “We will have a look at existing data and reports. We will do our best to reduce communication gaps.” He nodded silently.

I could read his mind. We had serious gaps in understanding requirements in our recent project and the result was a huge schedule over run. We wanted to do it better this time.

Specifications come in what form? Obviously in documents with UML diagrams, wireframes, etc. When it comes to requirements, we cannot afford to say, “Let us not worry about form. Substance is critical.”  Both form and substance are equally important.

“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to go rectify later”, says Fredrick P. Brooks, Jr. in his book ‘The Mythical Man-Month (Addison-Wesley, 1995).’ He adds, “I would go a step further and assert that it is really impossible for clients, even those working with software engineers, to specify completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product they are specifying.”

Can Rapid Prototyping help? Yes. It can help to a certain extent. In fact, Rapid Prototyping can be done at the time of Requirement Gathering and Elicitation. Products meant for this purpose are available in the market these days.

When we combine the power of such tools with the way we create software using methodologies based on iterative and incremental delivery, we get an opportunity to deliver working software early and frequently. Delivering working software early at regular intervals is a way to make your specifications powerful. This is when you reduce the gap between what is specified, what is delivered and what is needed.

When you have specifications in written text, UML notations or wireframes for more than a month or two, chances are that they become obsolete. You need to get them validated. When you do rapid prototyping (on a case-to-case basis) and focus on short-iterations to deliver working software you get an opportunity to demonstrate working software and get feedback. You get to improve what you did.

It is easier said than done. I agree with Brooks. He said it right. Right?