Focus on Well Documented Functional Requirements
by Nathan Weller
Every software product, no matter what its type or application, has Requirements. A Requirement is literally “that which is required; a thing demanded or obligatory”. Every software product created has a purpose – that which it is constructed to achieve – and thus will contain at least one Requirement. After all, if there is no purpose to a product, then it is not constructed – for to do so expends time, money and energy for no return.
Therefore, every software product has an aim. From this, it could easily be assumed that success of the product depends entirely upon the product achieving its preconceived aim. However, the real world is a lot more complex.
| Attachment | Size |
|---|---|
| Focus_on_well_documented_Functional_Requirements.pdf | 158.37 KB |
always making things more complicated than they need to be
IT projects usually fail when the IT team fails to learn the business.
If the IT team understands the business reasonably well, then there's a very good chance the IT team will respond with a good solution that meets the needs of the business.
The requirements phase should demonstrate that IT understand the business. They must understand the "current state" of the business, as well as the desired "future state" of the business. Requirements document the difference between the "current state" and the "future state".
It seems everbody is trying to come up with some new way of thinking - some "silver bullet" to solve this problem.
However, there's no substitute for understanding the business, the changes needed to the business, and then responding with a good design.