Requirements
Understanding requirements is the beginning of all information technology projects, right?
Most of us pay lip service to requirements, some more than others. One of my favorite books when I was learning business analysis was Gerald Weinberg's Exploring Requirements: Quality Before Design. It had a big impact on my thinking and approach to systems development. It still does.
This morning I was reading some jokes about programming as a first step in application development. They are deserved. It's not only IT people who suffer. I've had clients who had no tolerence for requirements let alone design. They were impatient to see programmers working and cranking out code. It's like asking someone to build a house and insisting that the basement be poured immediately. Where are the blueprints? There are none. How big is the basement? The driver of the cement truck is expected to know. Just get started. We want to see results.
On one project I asked for funds to at least develop a business data model before starting development. It was a relatively large project and I was prepared to walk away if the answer was no. Fortunately the funds were forthcoming and we proceeded. But it was a hard sell in an organization that wanted to see programmers at work.
A data model is the most essential aspect of an application area to understand. A data model that accurately reflects business objects and events leads to a solid database design. The exercise of discussing business objects and their relationships drives out process. And while an organization structure and technology will often change, the data model and data structure rarely do.
The essence of requirements is understanding what needs to be done before deciding how it should be done. Development, whether it be a small website or a multi-million dollar application, is a continual process of translating the what at one level into the how at the next level.
You can see that I put a lot of emphasis on understanding requirements. But I'm also a pragmatic. It helps to start building things for people to see. One of the best ways of driving out requirements is show something that triggers thoughts like "but what I really need is ...". In today's world, requirements are often driven by what's possible. Providing a mock up shows that.
When the term architecture is used in an IT context, most people think of technology architecture. I think of requirements. Clear definition of business requirements is an architectural document. It should include a business data (object) model as well as major processes.
Requirements come first, before programming, before design, even before project management. When building something physical, you hire an architect to produce blueprints before you hire a contractor to build. The same is true is software applications. Hire the architect first.
At one time in my career I was focused on being the best requirements architect around. I still put a great deal of emphasis on requirements. But I've always maintained my interest and skills in technology, and I've often been "promoted" into project and team management.
