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 requirements engineering can lead to cancelled projects, significant project 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.
Five areas of Focus for Requirements Engineering
In the requirements engineering space, often times, there is a focus on just requirements management. However, in order to manage requirements, they must be effectively elicited, documented, and approved. These three 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 five areas of Requirements Engineering. As we pass through these areas, the support CM provides will be introduced.
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.
Effectively, 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 (a.k.a., 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.
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.