Requirements Engineering Today
By: Marcia Stinson, senior requirements engineering consultant, Visure
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 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
(see figure 1).
Figure 1: V-curve of requirements engineering illustrates the relationship between
a requirements hierarchy and related testing hierarchy.
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.
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. Some
practitioners, contrastingly, just label the whole activity as requirements analysis.
There are many issues that requirements engineers today must deal with. Although we
tend to focus on software-intensive systems, the same issues exist for systems that are
hardware based. These issues include complex systems that involve many specialty
characteristics (mechanical, electrical, safety, regulatory). Systems are often developed
by distributed teams located around the world and communication is often weak. There
is increased pressure to deliver products quickly and the focus seems to be more on
functionality than quality. This increased pressure has resulted in attempts to use a
more “agile” approach to development and often the requirements engineering phase is
reduced or even ignored, resulting in poorly designed systems.
Why is it 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 nonfunctional 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 the quality of it 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”, “The missile shall hit a moving target in the
range of 4,000 miles”. As you will have noticed, a single non-functional aspect may not
only influence the complete development of a system, but every constraint has an
associated cost.
As a summary, requirements containing quality aspects are categorized as nonfunctional 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.
Non-functional aspects are multiple and diverse, and embedded systems typically pay
special attention to synchronous vs. non-synchronous execution, safety and reliability,
resource constraints, and autonomy (no human interaction), among many other.
While the functionalities are normally prioritized by means of cost-benefit, constraints
are divided in 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 nonfunctional 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.
The key difference between hard and soft non-functional requirements is that for hard
requirements, quality represents the least minimum constraint, below which the system
will fail and be useless. The soft requirements may be considered as desires or wishes,
which may then be negotiated and relaxed. Eventually, soft requirements may become
hard requirements during the negotiation.
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. This 30 seconds is a hard
non-functional requirement. There is no wiggle room in meeting it—if the requirement is
not met e.g. the update is not done, or is done only every minute, the missile will likely
miss the target and become lost. On the other side, if we establish that the update
frequency shall be done every milisecond, the cost of the system might become
unaffordable, or not feasible with the current technology, without adding any value to the
system in regards to the update every 30 seconds.
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.
What’s involved in the process of 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 communicates with users and spends 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 with 2 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.
These 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 1 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 (see figure 2). 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. 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.
Figure 2 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.
Requirements Traceability Matrix (RTM)
Figure 2: Requirements traceability matrix shows the complexity and
interconnectedness of the process.
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 is 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 attributes (additional
information for requirements) that must be maintained, the task grows even more
complex.
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.
Like every other tool, models must be used properly. Just because a model may be
correct does not mean that it is useful. Not every possible version has to be produced.
Modeling techniques can be particularly helpful to understand complex systems, but
models that do not accurately reflect the requirements can become a liability to a
project. The same is true for models that are not easily understood. You should make
sure the time spent on modeling is going to add understanding to the system and help
clarify the behavior of the system.
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 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 (see figure 3).
Figure 3: 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 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 direction.
Figure captions
Figure 4: V-curve of requirements engineering illustrates the relationship between a
requirements hierarchy and related testing hierarchy.
Figure 5: Requirements traceability matrix shows the complexity and
interconnectedness of the process.
Figure 6: To ensure a successful project, requirements must be tested at various levels.