Requirements Engineering Means Business Success
SEP 09, 2014 01:33 AM
A+ A A-

Business success means to deliver the right solutions at the right time to the right markets. Requirements Engineering is the discipline within systems and software engineering that bridges the entire life cycle and thus determines success or failure of a product or project. This blog provides a fresh look on requirements engineering, and why you need to improve it...

Imagine woodcutters in a forest. They work hard and cut tree after tree to build a street. It is a huge physical effort and their foreman drives them hard to stay on schedule. He wants to cut a certain amount of trees per day and provides the workers with all they need to achieve this objective. Suddenly the client who ordered the street to be build comes back and shouts: "wrong direction". Despite all the operational efficiency of the foreman and his team, they did not manage to deliver the intended customer experience.

Sounds familiar? Indeed, this is what we observe with many software products. Complex features must be developed at a low cost, but once they hit the market they won't sell as expected. Or customers demand many changes during the development process, thus reducing margins dramatically from initial targets. Software requirements engineering is the systematic approach to providing direction before and during software development. It provides the means to deliver the right products or solutions at the right time for the right markets.

Requirements Engineering (RE) is the disciplined and systematic approach – that is the "engineering approach" – to elicit, specify, analyze, commit, validate and manage requirements while considering user, technical, economic and business-oriented needs and objectives. The goal of RE is to develop good – not perfect – requirements and to manage them during development with respect to risks and quality. In short, good RE makes the difference between a winning product and a mere set of features.

Insufficient requirements engineering is the major contributor to software projects risks and problems. One might argue that this is an issue for all disciplines because requirements will only be clear when an artifact is finished, but certainly in software is causing much more damage due to not considering its impact and even thinking that software is "soft" and therefore changeable. Other disciplines since long have built very clear boundaries when changes are impossible or at least very costly. Take hardware, where it is clear that an ASIC has a cycle time of some weeks and each change will mean a new production circle. In civil engineering changes are possible, but rather early in the life-cycle they become expensive or impossible – without destroying the product and re-creating it.

Why is that? Why do we have such difficulties with requirements and their handling? Handling software requirements represents an ill-defined problem because within a software system, requirements are not fully known until it is practically used. Not managing this problem results in requirements instability, which means project delays. Typical results from poor RE are insufficient project planning, continuous changes in the project, delays, configuration problems, defects, and overall customer dissatisfaction due to not keeping commitments or not getting the product they expect.

Here some hard facts which show the project impacts of insufficient RE. Only half of the originally allocated requirements appear in the final released version. For each project, there is an average sum of roughly one million Euro that is spent in excess before the project is terminated – for good or bad. Most software systems use less than half of their features. 80% of all defects in test result from missing (31%) or wrong (49%) requirements. 43% of all failures of embedded systems during operations are due to insufficient system specification and analysis.

There is a clear business case for good RE. Typically only 3-6% of all project effort is spent on requirements engineering and management. Doubling this effort would yield a 20% reduction of product life-cycle cost: Less rework, shorter cycle time, efficiency. Some concrete data points have been assembled from longitudinal studies of many similar projects in almost identical environments. If the preparation effort, specifically on requirements is below 5% there will be large delays. Moving this share to 10-20% of total project effort would reduce delays to below 30%. Preparation means all activities in front of project start, that is requirements elicitation, analysis, specification, project planning, stakeholder agreements and resource allocation. Projects with 5% relative effort on RE activities would show a budget overrun of 80-200%. Doubling this effort towards 8-14% reduces the cost overrun to below 60%.

Here are some of the major take-aways from our consulting projects:

• Requirements mean team work: Winning products depend on collaboration between marketing, sales, product management, and software development.

• Focus on value: A product should create an experience, a value for its user. Look to the major use cases from a user perspective and then distill requirements and priorities.

• Avoid feature battles: Remember that your product is what the consumer perceives, and not what you sell. Use lean and agile techniques to reduce complexity and to focus on what matters.

• Systematically analyze requirements: Look to your estimates, impact analyses and planning before the project, at key milestones, and when there are changes to scope or content.

• Manage risks: Have a profound understanding of your position and product strategy. Periodically evaluate products and markets to avoid dead-ends and unnecessary features.

•        Work professionally: Follow a suitable process for developing and managing your requirements. Use templates, specify and document agreements, and work systematically. Avoid ad-hoc changes because they mean rework.

The benefits from RE are manifold. Here some major aspects, which will allow you to position your own business case:

• Improved predictability due to known requirements and clear responsibility split of the core team

• Realistic project planning and resource allocation. Faster project ramp-up. Less analysis delays before project start.

• Reduced cycle time due to knowing what to do and to focus on value-added features

• Less rework from inconsistent requirements due to impact analysis for changing requirements and traceability

• Reuse of requirements and derived work products across products (e.g., security mechanisms)

• Improved productivity. Typically 30-50% of development resources are used to correct defects rather than for development-related activities. Approximately half of defects relate to requirements engineering

• Improved customer satisfaction due to consistent understanding of the actual customer requirements. Customer needs are satisfied by product requirements.

Good requirements engineering means business success. I wish you good success with better requirements engineering. Contact me for more information…

More:

The IEEE/Wiley book "Global Software and IT" provides case studies on requirements engineering in software projects.

Directly proceed to the book…[http://consulting.vector.com/vc_books_en.html]

Read our free white papers on practical requirements engineering… [http://www.vector.com/re-publications]

Author:

Dr. Christof Ebert is managing director at Vector Consulting Services.

He supports clients around the world to improve product strategy and product development and to manage organizational changes. Prior to that, he held global management positions for ten years at Alcatel. A trusted advisor for companies around the world, member of industry boards, and adjunct professor at the University of Stuttgart, he authored several books including his most recent book "Global Software and IT" published by Wiley.

Contact him at christof.ebert@vector.com

FIRST
PREV
NEXT
LAST
Page(s):
[%= name %]
[%= createDate %]
[%= comment %]
Share this:
Please login to enter a comment:
 

Computing Now Blogs
Business Intelligence
by Keith Peterson
Cloud Computing
A Cloud Blog: by Irena Bojanova
The Clear Cloud: by STC Cloud Computing
Careers
Computing Careers: by Lori Cameron
Display Technologies
Enterprise Solutions
Enterprise Thinking: by Josh Greenbaum
Healthcare Technologies
The Doctor Is In: Dr. Keith W. Vrbicky
Heterogeneous Systems
Hot Topics
NealNotes: by Neal Leavitt
Industry Trends
Internet Of Things
Sensing IoT: by Irena Bojanova

 

RESET