As VP of product development for DuckCreek Technologies, Michael Witt deals with requirements every day. He recently took time to talk with Dr. Dobb's editor in chief Jon Erickson.
Dr. Dobb's: What is the first step in implementing a requirements strategy?
Witt: A move to either introduce a requirements strategy where none currently exist or implement a different requirements strategy requires careful attention and planning to change management. As a first step it is critical to create a sense of need and urgency throughout the organization that will be affected. People know the difference between a real need and the next "silver bullet". Establish real need in the minds of everyone involved, but don't overlook capturing their hearts as well. Use both statistics & metrics and anecdotes to create a compelling case for change, and involve 20% of your organization in facilitating the change. A core group of knowledgeable and motivated individuals can facilitate change more rapidly than a single leader from a soap box. Finally, include in this opening salvo the training necessary to educate people on requirements development and management. This means that you have made some decision on the requirements model, the goals of your requirements program, the principles and best practices that you want to implement, and have at least narrowed down your tools options to no more than two or three potential vendors.
Dr. Dobb's: Who should be involved in defining and managing requirements?
Witt: The people who are going to use the software built from the requirements. That first sentence cuts to the chase, if you don't have people who will use the software involved in the requirements process then the software will not be fit for the intended business purpose. However, there are multiple skill sets required to create software requirements that are usable themselves. Requirements elicitation is a different skill from requirements engineering. It is generally a good idea to consider an out-facing product manager to be responsible primarily for requirements elicitation and a business analyst to be responsible for requirement engineering and development. The key to success is flexibility. If you have a hard and fast rule that business analysts can never talk to outside stakeholders then you lose opportunities for speed and efficiency. With these two roles covered you cannot overlook the need for the entire team to also participate on some level. If the team doesn't own the requirements, but is merely responsible for reading them and filling the order then you lose ownership and choice. Employee engagement can enable you to do more with fewer resources than an organization who lacks employee engagement. Enabling ownership and choice among the development team in building product can make the difference between getting by and being wildly successful.
Dr. Dobb's: What should a requirements set cover?
Witt: Requirements should provide insight into the major functionality, features, and non-functional characteristics of the system. There are very few companies out there that are trying to build software that human lives depend on, but a lot of companies are building their requirements that way. Requirements should provide a general direction for the software, but software is a creative enterprise. Most organizations begin with requirements out of fear. They struggle to deliver software with business value and the growing disquiet among their user base drives them to determine that developers don't know what they are doing. Implementing requirements management in order to control developers is a mistake.
Requirements management should be implemented in order to drive business value. Keeping the goal of delivering business value as priority one in your requirements effort will get you closer to the right coverage in your requirements set. Stay focused on business requirements, don't be afraid to specify technical requirements, but enable development teams to have a say in all of it.
Dr. Dobb's: Who should write, read and sign off requirements?
Witt: I believe strongly in a team-based approach. I don't think that a single person can make the kinds of decisions required to ensure that a requirements set is right. Having individuals on the team responsible for their area of professional expertise allows you to distribute sign-off responsibilities to people who know. That being said, I have to ask why it is that sign-off is important. Is sign-off a part of your process of ensuring that you are delivering business value or is it a method of protection? As a method of protection requirements sign-off stinks because it is impossible to communicate the nuances present in a massive requirements document. In the end it isn't protection at all because your "customer" still ends up angry if you forget something. If you are using requirements to hold the customer or stakeholders accountable for their decisions then you are doing requirements wrong and for the wrong reasons. It is the job of those eliciting and engineering the requirements to ensure that they capture the business needs. And it is a mistake to use sign-off as a method of holding business owners accountable, all that does is enable the team to have an escape clause. Success in software is delivering products that meet business needs, not in delivering requirements that enable you to enforce a contract.
Dr. Dobb's: Are requirements cast in stone?
Witt: The only alternative path to change is obsolescence. Requirements should reflect the business needs and goals of the software. The easiest way to answer this question is to ask, How often does your business needs for the software change? By asking this question before you begin, software projects can be setup for success. If your business requires software that meets business needs that change monthly or quarterly (Insurance software for Commercial Lines meets this criteria) then your requirements management system must enable the business need for change. Requirements are pointless in and of themselves, they serve only to delivery real software, to real people, in real businesses.