Anticlue

The problem with requirements

We are sitting in the conference. It's my team, and the business process owner's team. Our thought process is driven by technological innovations, their thought process is driven by some health or business related passion. Maybe the passion is for billing accounts correctly and in a timely manner, maybe the passion is create an excellect training course for nurses, medical students, or physicians, and maybe the passion is to disperse policies to everyone in a timely manner. The point is we each focus on different things, and that is good.

We are here to have a requirements meeting. What's that? There is a business process that can be streamlined by a technical process. The requirements meeting is to determine the nature of business process. For our purposes here, everyone is gung-ho to move forward with let's say the e-procurement process for laboratory supplies.

So we are sitting down together to discuss this aspect, it is a new concept and everyone is happy. "This will be great, when we get it together"

It is a state of bliss, to determine the blue print for your new house. Only thing is software requirements are not like a house's requirements. Since the building process takes time, the business process the requirements were set to solve also evolves. Users don't see the physical house, the analysis, the construction of the code, the db, the object, or web services. So when they have a relatively minor enhancement to the business process, why isn't it just inclusive in the technical solution?

Well first, there needs to be more than just one requirements meetings, and there needs to be a we heard this, is this correct? Do you understand what we mean by this? type of dialogue between the techies and the business owners. Don't be afraid to ask questions, questions are needed, essential to the process. Ask what they do now, what do they invision in the future, what changes are planned? Document the requirements.

The other item is to revisit the requirements along the software lifecycle path, or product implementation path. The requirements are going to change. It would be nice if requirements could be frozen, cast in stone, and then pointed to like the ten commandments. But have you ever tried lugging stone tablets around? just not a good way to do things. They weigh you down. In all likelihood the business process you identified the solution for in the requirements stage of implementation will be different by the release stage of the software, and it is definitely going to change in the maintenance stage. Requirements are ever changing, because no one likes to get by on just the bare minimum that they require. Just add to the document the changes, and then try to determine the easiest way to implement the change. Then talk it over with the business owners the impact of the change. Is this a cosmetic thing? or is this going to need to change the live plan?

Since the business is changing, and therefore the requirements are changing, when building an application consider how to handle the changing requirements in the analysis and proposed solution with minimal impact to the overall design. For example don't waste your time specifying canned reports for the user to run, but has no ability to change. Instead, spend some time with the user, training them in access reporting, allow the users to create their own reports. Review the reporting needs, and ensure that all of the requirement data elements are captured. Expect data elements to be added or needed in the future, and create a db schema that allows those changes. In other words, have a software architecture that anticipates and is forgiving of change.