Channels ▼
RSS

Tools

Q&A: What's Behind Good Requirements



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.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video