ABCs of Requirements Engineering


Requirements engineering plays a fundamental role in the establishment of a release.  Requirements engineering can be described as having five key areas of focus.  This includes the ability to elicit requirements, document requirements, approve and baseline requirements, manage the requirements after approval, and trace from the requirements thru test.


A strong requirements engineering discipline is critical to the success of an application. Poor discipline can lead to cancelled projects, significant cost overruns, and inadequate release deliverables. Configuration management (CM) plays a role in many of the requirements areas by providing version control and change control processes that can help in implementing a successful requirements engineering practice.




Areas of Focus for Requirements Engineering

In the requirements engineering space, there is often a focus on just requirements management. However, in order to manage requirements, they must be effectively elicited, documented, and approved. These steps will lead to a more effective process of managing change to requirements and will enable the ability to trace to and from requirements. This section will walk us through the areas of requirements engineering. As we pass through these areas, the support CM provides will be introduced. 

·       Eliciting requirements:This is the most critical area of requirements engineering. If requirements are not articulated, there is no chance for a successful release. This area revolves around two key facets.

·       Selecting a technique: The first facet of eliciting requirements focuses on selecting a requirements elicitation technique (or techniques) that can help best articulate the requirements. There is no one technique that is best for all projects, so it is important to investigate the various techniques and select the one (or more) that is best for the release of the application.

This is the step that helps define the language that will be used to discuss the requirements amongst the team and the structure that is used to articulate the requirements. The application owner (with input from analysts) should select a technique. Once a technique is selected, consider providing training to educate those that must contribute too or work with the requirements.

There are numerous requirements elicitation techniques. Some techniques include use cases, interviewing, (executable) prototyping, process-flow, modeling, mockups (paper prototyping), and brainstorming. Often times, if the language (or technique) is not defined, people start describing the requirements from the technique they are most comfortable. This is akin to beginning the development phase without a defined coding language and allowing the developers to use the development language or technique in which they are most comfortable. The end-result can be disastrous. While not to the same extent, a lack of a defined technique can slow down the requirements elicitation process and produce less clear requirements.

·       Holding appropriate elicitation sessions:The second facet of eliciting requirements focuses on the ensuring that the requirements elicitation sessions are productive. When approaching the requirements elicitation sessions, consideration should be given to the types of requirements that need to be captured, who should attend these sessions, and holding enough sessions to ensure there is adequate time to identify requirements.

·       Including the requirements category: Give thought to the category of requirements that should be identified. By listing the requirements categories, this can help avoid missing whole sections of requirements such as security related requirements. Some examples of the category of requirements are user requirements, system requirements, performance requirements, and security requirements.

·       Identifying participants: To determine who should attend the requirements elicitation sessions, identify the people who can best identify requirements. From a customer perspective, obviously include an appropriate number of customers. Customers that are paying the most may have more representation or have more weight in the requirements they solicit. Consider inviting marketing folks since they will have insight as to what the potential customers are looking for. You should also have systems representatives (lead developers and testers) so that technology related requirements are included.



About the author

Mario  Moreira's picture Mario Moreira

Mario Moreira is a Columnist for the CM Journal, a writer for the Agile Journal, an Author, an Agile and CM expert for CA, and has worked in the CM field since 1986 and in the Agile field since 1998. He has experience with numerous CM technologies and processes and has implemented CM on over 150 applications/products, which include establishing global SCM infrastructures. He is a certified ScrumMaster in the Agile arena having implemented Scrum and XP practices. He holds an MA in Mass Communication with an emphasis on communication technologies. Mario also brings years of Project Management, Software Quality Assurance, Requirement Management, facilitation, and team building skills and experience. Mario is the author of a new book entitled “Adapting Configuration Management for Agile Teams” (via Wiley Publishing). It provides an Agile Primer and a CM Primer, and how to adapt CM practices for Agile Teams. Mario is also the author of the CM book entitled, “Software Configuration Management Implementation Roadmap.” It includes step-by-step guidance for implementing SCM at the organization, application, and project level with numerous examples. Also consider visiting Mario’s blog on CM for Agile and Agile adoption at

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!