Maturity Levels of Requirements Engineering

June 11, 2014

Requirements-Engineering-Intland-Software-336x1148 Maturity Levels of Requirements Engineering requirements Requirements Management and Requirements Engineering have a vital role in the development process. Requirements are the starting point of all projects, since they define what features should be in the product. The importance of Requirements Management and Requirements Engineering has increased significantly in the past few years to minimize and eliminate potential failures of the development process. Companies often believe that defining requirements is critical to the success of the final product, the failure of defined requirements is likely to result in product failure.

Maturity Levels of Requirements Engineering Survey

Our recent survey about the Maturity Levels of Requirements Engineering was done with the aim to show how seriously companies deal with Requirements Management and Requirements Engineering.

From our experience, it is important for companies that:

– Product quality is determined by proper requirements definition and validation, this influences the final quality of the product (survey 80-90% respondents claimed this to be the case). Requirements should be defined by trained requirements engineers; however the definition of requirements should be done in a collaborative way, together with clients, product owners and business analyst.

– Since non-functional requirements (NFRs) requires more technical knowledge, 60% of the companies find it important that these NFRs should be defined by different teams (mainly by technologists) as long as the functional requirements are usually defined by the same teams (mainly by business analysts).

– Since it is less costly to detect and eliminate failures in the requirements definition phase, 70% of the companies apply four-eye principal to evaluate and approve requirements before the development starts.

– 70% of the companies have integrated requirements evaluation in their quality management to define workflow for requirements evaluation and to avoid rework of requirements. If requirements require rework it means extra costs and resources for companies. The average ratio of requirements with rework is still 10-30%.

– Collaboration has an important role in requirements management during different development phases. It is less important in the “definition process” and the most important in the “change management”. Collaboration has less importance in the final QA phase since it is done by test engineers.

– Re-use of requirements in new projects enable companies to save resource and expense. With 40% of companies already using requirements re-use; however the ration of changing requirements in new projects is 30%.

The survey confirmed that the potential source of lot of future problems is the poorly defined and the missing requirements. In many cases the false validation and the wrongly documented (or not documented) requirements are equally responsible for project failures. Ineffective change management and a lack of traceability are a key cause of failures and financial damage.

Check out the Requirements Management module of codeBeamer ALM software solution to minimize and eliminate potential failures of the development process.

facebook Maturity Levels of Requirements Engineering requirements twitter Maturity Levels of Requirements Engineering requirements google Maturity Levels of Requirements Engineering requirements linkedin Maturity Levels of Requirements Engineering requirements

Related E-Book

Requirements Management Guide

First Name

Last Name

Email Address

Company

Phone Number

Industry

Eva Johnson

Written by

Eva is an Economist (MSc) and also holds an MBA in Marketing Communications. She has over 10 years of experience in journalism, digital media communication and project management working with several multinational companies and governmental institutions. You will find her blogs posts on a variety of subjects from Agile-Waterfall Hybrid, Scrum to DevOps.

Eva Johnson has written 132 posts for Intland Software.

1 Comment. Leave new

Effort put in such kind of surveys is appreciated. The article is informative and light to read, the topics of the research (survey) are relevant.

And this is the piece about reuse of requirements information: “Re-use of requirements in new projects enable companies to save resource and expense. With 40% of companies already using requirements re-use; however the ration of changing requirements in new projects is 30%.”. This piece could benefit from an improvement to reach the level of the rest of the article:
– putting “changing requirements in new projects” after “however” seems like labelling it negatively. Would that be so because it refers to modifications (adaptations) of perhaps some “reference library stable master requirements” that were expected to be reused as-is, and then it happened they had to be adapted to a new project needs?
– as copy&paste of requirement statements is also a form of reuse, it is not clear which weight the stated “40% of companies already using requirements re-use” carries. Perhaps sharing more surveyed details would clarify.

May I hope for an elaboration on this piece of the research?

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *