Code Requirements and Verification
Requirements Engineering Today
Clearly defining and understanding requirements before embarking on a large and complex software development project is key to success. The ability to establish and then fully implement all requirements demands a systematic method supported by comprehensive tools.
MARCIA STINSON, VISURE
Page 1 of 1
Requirements engineering is the process of determining user expectations for a new or modified product. That sounds so simple, doesn’t it? Of course, those who are in the field of requirements engineering—also called requirements analysis—understand the difficulty and complexity hidden within that simple statement. Anyone on a development team who has labored to deliver a project and has discovered that it wasn’t, after all, what the user really wanted, understands the difficulty and complexity even more. Requirements engineering provides a powerful tool for engineering teams to streamline development, simplify project management, and deliver results on time, on budget, and with the least possible headaches.
According to a survey by the Standish Group, about half of all software projects fail to be delivered on time and within budget. Even worse, many of those that are delivered on time are not accepted by the users and require additional rework. The most common culprit? Incomplete and changing requirements. This problem appears to be an even bigger issue than challenges like lack of user involvement and lack of resources. Especially in complex projects, there are many layers of requirements that must be understood from the very start of development. Poor requirements management can lead to the development of systems that are expensive, late to market, and missing key features. Getting the user expectations described correctly is the key to everything else. This is where requirements engineering can help.
To understand the basic concept of requirements engineering, consider the V-model in Figure 1. This model has been around for years and is still recognized and used today to understand the concept of a requirements hierarchy and a related testing hierarchy. Requirements begin at a very high level of understanding and evolve into more and more technical details. Testing, on the other hand, begins at the lowest level and builds up to finally verify that the system is providing what the users have asked for and needed.
V-curve of requirements engineering illustrates the relationship between a requirements hierarchy and related testing hierarchy.
Formally, requirements engineering activity is divided into requirements development and requirements management. Requirements development is composed of elicitation, analysis, specification, and validation. Requirements management is the control of the entire requirements process, especially handling any change in requirements. On the other hand, some practitioners just label the whole activity as requirements analysis.
Why Is This Important to Embedded Systems?
In the development of most systems today, the focus is on functionality. If the functionality meets the user needs then there is usually some acceptance on the part of the users that some of the non-functional requirements may not be completely satisfied. In most systems, as long as the functionality is met, some adjustments to the non-functional requirements are more readily accepted.
Products are systems that consist of sub-systems and their interfaces. Each subsystem is considered an independent system with interfaces to other subsystems. Each subsystem has its own system requirements, but because it is associated with a larger system, it will be subject to certain restrictions imposed by the system as a whole.
Embedded systems are subsystems of the overall system, so their requirements are derived from system requirements. The individual component merits its own requirements analysis, modeling, and further decomposition of requirements, but these activities cannot be done in isolation—they rely on the requirements they have been given. The subsystem must meet these requirements in order to fit effectively into the overall system. . These requirements can be classified as functional and non-functional. Functional requirements specify capabilities, functions or actions that need to be possible with the system. That is, what the system shall do. An example of a functional requirement would be “The missile shall hit a moving target,” or “The ground station shall be able to establish the missile’s target.”
Non-functional requirements specify the qualities that the product or its functions must have. This means that non-functional requirements not only apply constraints to the system to be built but also establish its quality and actually play a key part in the development. An example of quality aspects of a function would be “The missile shall hit a moving target in the range of 100 miles,” or, “The missile shall hit a moving target in the range of 4,000 miles.” Thus, a single non-functional aspect may not only influence the complete development of a system, but every constraint also has an associated cost. Therefore, requirements containing quality aspects are categorized as non-functional requirements, whereas requirements describing capabilities are categorized as functional requirements.
Non-functional requirements that are allocated to embedded systems normally impact the entire product, including how the system is developed and maintained. Embedded systems must be designed within the context of the environment in which they will be running since the environment imposes restrictions on how the product will behave. In embedded system development, there must be an increased focus on handling and recovering from errors that may occur. Other typical non-functional software requirements for embedded systems include synchronous vs. non-synchronous execution, safety and reliability, resource constraints and autonomy or the ability to operate without human intervention.
While the functionalities are normally prioritized by means of cost-benefit, constraints are divided into two types of non-functional requirements: hard non-functional and soft non-functional. Hard non-functional requirements are non-negotiable and must be met by the system or the system is considered to be failed. Soft non-functional requirements are negotiable with the customer and failure to fulfill these requirements will not necessarily cause the system to fail testing. In embedded systems, most of the non-functional requirements are hard requirements. There may be some room for negotiation but normally that requires a series of trade-offs with other components of the system, not with the end users. Usually the overall system requirement is a hard requirement that has to be met.
Consider a situation for a control system that is embedded in a cruise missile. The missile has to read terrain data, process the data, and update the missile’s course. The quality aspect of this capability is to do so in 30 seconds. The 30 second limit is a hard non-functional requirement. There is no wiggle room in meeting it—if the requirement is not met, the missile will likely miss an update, become lost and miss the target. On the other hand, if we establish that the update frequency shall be every millisecond, the cost of the system might become unaffordable, or not feasible with the current technology—and not add any value to the system compared to the 30 second update.
Knowing this will change the way developers will design the software. They may break the 30 seconds down into even more detailed processes, allocating a portion of the time to each process. There will be 10 seconds to read the terrain data, 15 seconds to process the data, and 10 seconds to update the missile, for example So there may be some negotiating among the three processes on how the 30 seconds is allocated. But in the end, the update must be completed in 30 seconds in order to keep the missile on track. These requirements may change the way developers look at designing and implementing the code required to make this happen. Getting the real requirements defined right and allocated to the individual components is a key factor and requires solid requirements engineering practices.
Collecting and Managing Requirements
To develop a successful project, collecting and managing requirements must begin on day one. It starts with the request that initiates the project and continues throughout deployment. During the initial phase of a project, requirements gathering begins as requirements analysts communicate with users and spend the time required to understand the problem they are trying to solve. Understanding the problem correctly is essential to building something that will meet the needs of the end-user. Misunderstanding here will result in a project that does not function as desired from the perspective of the users.
User requirements should be documented, along with business requirements (business rules) and nonfunctional requirements. Key skills to these activities are good listening skills, communication skills, and concerted effort to understand the system from the user’s perspective. These requirements are often modeled in a use case structure to help understand the flow of the requirements. Requirements must be analyzed for completeness, correctness, and feasibility. As a simple example of this, there may be a requirement for a missile to read terrain and update its location within two seconds and the updates will occur every 30 seconds. These requirements are probably based on analysis that indicates this is the minimum time required to keep the missile on track. Obviously this is a requirement that must be met and this will drive the development effort to focus on these kinds of performance requirements.
Once the user requirements are defined, the process begins to detail the steps the system must provide to meet the user needs. The system requirements are derived from the user requirements. This requires a much more technical analysis and an understanding of the system that is to be built, as well as other systems that may interact with the system being built.
The requirements may be developed in phases. Some may be reused for several different systems. These kinds of situations lead to a very complex requirements model that must be thought through carefully. Attributes are usually applied to the requirements to help understand the variants and releases of the systems in which they are used. If we refer to the missile example once again, let’s assume that a new missile is built that weighs less and goes even faster. This results in the need to update the location within one second and the updates need to occur every 15 seconds. This will be a variant of the missile that will have different requirements associated with it.
After system requirements are developed, they must be allocated to components of the system. This is typically where an embedded system picks up requirements. For example, the first missile will go through three steps to update its location. Each step will have a time associated with it and the total allocation of the time will be two seconds or less. First, it must read the terrain data which is a requirement for the altimeter. Then the missile stores the terrain data. The mission software will then store the data and compare the data to the onboard map to determine if an update is required. The missile must then perform the update. Each step will have a performance requirement associated with it, the total of which is no more than the required three seconds.
Table 1 shows a sample requirements traceability matrix (RTM) for a few requirements in a system. Now multiply that matrix by hundreds and imagine the complexity of managing that traceability. Without a requirements management tool to manage these relationships throughout the system, it is impossible to understand their effect upon one another and the impact of any changes. Think about the traceability relationships required to manage a complex system that has several layers of requirements (i.e. many subsystems). Traceability ensures that all user needs are being satisfied by the system and that no system features are added at a phase in the project that are not derived from a user need. Traceability also allows engineers to see what requirements might be impacted by a proposed change. If you consider not only the traceability, but also attributes (additional information for requirements) that must be maintained, the task grows even more complex.
Requirements traceability matrix shows the complexity and interconnectedness of the process.
Requirements and Other Development Activities
Requirements form the basis of the project information. Everything done on the project is based on the requirements. Models provide a useful tool for design teams, enabling them to better understand the system and develop requirements. A model is a representation of something real, produced to represent at least one aspect of an entity or system to be investigated by reducing complexity. Models may also be produced for testing ideas. A model may take a physical form or may be expressed in the form of a specification.
Select the type of modeling you are going to do on the project carefully. Keep in mind that a single model does not represent all aspects of the project, but usually just a single view. Usually multiple models are used to describe very complex systems and each model has a specific purpose.
Software developers rely on requirements engineers to give them the information they need to design and develop the system. Collaboration with the developers early in the process will help ensure technical issues are resolved as early as possible and then potential solutions are vetted with the users. In most organizations, there is a gap in traceability between system requirements and the design models. It is important to trace requirements to design (textual or models) to ensure all requirements are being considered in the solution. This is also necessary to do a comprehensive impact analysis when changes are proposed to the requirements. Although this takes time and effort, the benefits of maintaining some kind of traceability to design artifacts is important.
Requirements also form the basis for all testing that must take place. Part of the requirements engineering responsibility is to ensure that all requirements are tested and that the system has passed these tests. In a traceability model, all requirements should link to some kind of test to ensure that all requirements are evaluated at the correct level (Figure 2).
To ensure a successful project, requirements must be tested at various levels.
As you can see from this example, testing at the lowest level can be done quickly. The altimeter is tested outside of the missile for performance. The next level of testing is done in a laboratory environment that simulates the missile’s activity. The final test, actually shooting a missile is very costly and difficult to do. The hope is that by testing individual subsystems first the majority of bugs will be found at this level and not at the end when the missile is actually launched.
Requirements traceability provides an essential tool to ensure project success, not just in terms of performance but also in meeting time-to-market goals. With requirements traceability, everything on the project is traced back to a requirement. It ensures that there aren’t any unnecessary efforts. If the argument arises on the project about who is doing what, or why, or on whose direction, the team can always return to the requirements. Without a clear set of requirements to drive the direction of a project, we are like a ship floating in the ocean with no course.