As we did for other lessons, before starting this
lesson on requirements engineering, I want to ask a world
expert on this topic a few questions. I'm here with
Jane Cleland-Huang, a professor at the DePaul University. And Jane
is a world expert in the area of requirements
engineering, which is the theme of this lesson. So I'm
talking to Jane who is currently in Chicago and I
want to. Ask her a few questions about requirements engineering.
So hi Jane how are you?
>> Fine. Thank you Alex.
>> And thank you so much for agreeing to
be interviewed for our course, I'm sure the students
will really benefit from this. And let me start
with the first question which is what are software requirements?
>> That's an interesting question. And software requirements
basically provide us a description of what a
system has to do. So, typically they describe
the functionality of the features. That the system has
to deliver in order to satisfy its stakeholders.
And we usually talk about the requirement specification
in terms of what the system's going to
do. And we describe it sometimes formally in
terms of set of shall statements, that the
system shall do this or shall do that.
Or we can use various templates to specify
both textural requirements. But requirements can also be represented
informally in, in the form of user stories, or use cases, or more
formally in the form of state transition diagrams and even in kind of
formal specifications. Especially for critical parts of safety critical systems.
>> And another should discuss what the
requirements are. What is the requirements engineering?
>> So, that's also an interesting question because if you notice
it's it's engineering and I'm sure in the
other parts of the software engineering process that
you're discussing in your course. Parts such as
testing or coding. They don't have the word engineering
there and I think one of the reasons
requirements engineering has that term is because it covers
a number of different activities. So it includes
things such as working with stakeholders to elicit or
to proactively discover what their requirements of the
system are. Analyzing those requirements so that we
understand the tradeoffs. So you might have different
stakeholders that care about different things, and it
might not be possible to deliver all of those things, so we have to analyze the
feasibility of the requirements, explore the tradeoffs, emerge
conflicts. And then of course the specification part,
which we talked about a little bit already,
and the validation, so did we in fact get
the requirements right? Did we build a system
that actually matches our, our requirements. And then on
into the requirements management process. And the requirements
management process. Kind of like goes through things like
change management. So what if customer or stakeholders
need the system to change? How do we manage
changing requirements? And I think this is one of
the reasons that we've coined the term engineering because
that it's, has to be a systematic process which
extends across. The whole of this is life cycle.
>> And I guess my last question here is
so now that we heard about software requirements and
about software requirements engineering, why is requirements engineering so
important? So what happens if we don't do it right?
>> Well, I'm sure that, you know,
many people have probably read the kind of
report like Spanish report, and other reports of failed
project, and things like that, and are aware that
one of the major reasons for projects failing
is because we didn't get the requirements right
in the first place. So if we don't understand
the requirements then we're simply going to build the
wrong system. Getting requirements right includes all sorts of
things such as finding the right group of stakeholders so we don't exclude major
groups of stakeholders. Understanding the requirements correctly.
There will be many, many different examples of
projects that have failed. For example, in
America the healthcare.gov failure, and while we cannot
put the blame squarely in the area
of requirements, because obviously the project was challenged
for a number of different reasons. But
clearly it underperformed in many respects related to
security, performance, and reliability and these are all
parts of the requirements process. Things that should
have been discovered and the system should have
been built in order to meet those requirements,
getting the requirements right in the first place.
Puts us, a project on the right foot.
And so that gives us a much better chance
of delivering to the customer what they need. And
designing a solution that really meets those requirements. So,
it's a critical part of the overall software engineering success.
>> Okay. So that's critical. I mean, we better get our requirements right.
>> Yeah.
>> That's, that's the message.
>> Yeah.
>> Okay. Well, thank you so much Jane, for taking
the time off your busy schedule to speak with us.
I'm sure. The students really appreciate this, and we'll talk to you soon.
>> Bye Alex, thank you.
>> Bye, Jane, bye bye. Jane gave
us an interesting perspective on requirements engineering
and its importance. Let's now start our
lesson with a general definition of requirements engineering.