Pages

Friday, July 11, 2014

Requirements (Part 2)

Documenting Requirements


Now, we have idea about the requirements of our user. As professionals, we would like to write them down so that we don’t miss anything from our valuable user. We have to publish a document that can be used as a basis for discussions between developers, the end users and the project sponsors. There are different ways for this.


Swedish computer scientist, Ivar Jacobson proposed the concept of use cases to capture the requirements. Use cases help us to describe a particular use of the system in an abstract fashion. But his book was a little vague, which created different opinions among different people.


One way of looking at use cases is to emphasize on their goal driven nature. Templates can be used as a starting place. Use of a formal template ensures that we include all the information needed in a use case.


Over Specifying


Never be too specific, at least in the case of requirements! Good requirement documents remain abstract. They consist of simplest statements which reflect the business need clearly. But also make sure that the requirements are not vague.


Requirements are not architecture, Requirements are not design, nor are they the user interface. Requirements are need.


- summary of Digging for Requirements, from The Pragmatic Programmer: from Journeyman to Master

No comments:

Post a Comment