Requirement Engineering Statement Types

Loading...

Del curso dictado por University of Colorado System

Requirements Gathering for Secure Software Development

70 calificaciones

University of Colorado System

Requirements Gathering for Secure Software Development

70 calificaciones

Curso 1 de 5 en SpecializationRequirements Engineering: Secure Software Specifications

In Software Requirements Elicitation for Secure Software Development, we're going to discuss the overall software requirements process as it applies in waterfall, spiral, and agile models. You'll learn about each of these processes and your goals as a software requirements analyst. This is not an easy task! Who do you talk to, when, and what kind of knowledge are you trying to obtain, in any software life cycle? How do you handle obstacles as you go? These are the questions we will focus on answering in this specialization.

De la lección

Goals and Models for Elicitation

To increase flexibility to change in software development, the agile lifecycle was produced. The agile process much changes how we deal with requirements. We discuss these challenges and your role as a requirements analyst. We also begin to analyze the types of statements that you want to form as you elicit data to move towards clarity.

Who, when, why, and how?4:46

Requirement Engineering Statement Types4:24

Requirement Challenges3:56

Conoce a los instructores

Kristen Walcott-Justice
Assistant Professor
Department of Computer Science

The requirements engineering process involves four different types of statements.

The first set and those that are most well-known,

are known simply as requirements.

These may include both functional requirements,

system requirements, and nonfunctional requirements.

Nonfunctional requirements again, are things like usability or security.

Requirements are to be understood and agreed

upon by all parties concerned with the system to be.

Thus, vocabulary is key.

And the vocabulary of the world in which you're working should be used.

We can think of these requirements as "shall statements" for now.

Well, shall or should.

For example, if we were creating a train system,

we might have the requirement of,

"The door state output variable shall always have the value

closed when the measured speed input variable has a non-null value."

That's complex terms for,

"If the train's moving, door should be shut."

As a simpler example,

if we were writing a meeting organizer system,

a functional requirement might be,

"A request for constraint shall be emailed to the address of

every participant in the meeting invitee list."

These statements are understandable for both the customers and the developers,

and they help us to define the necessary conditions of the statement to be.

Three other types of statements that are also necessary

in your document are domain properties, assumptions, and definitions.

Domain properties hold invariably regardless of how the system should behave.

These often correspond with physical laws that cannot be broken.

For example, a train is moving if and only if its physical speed is non-null.

In our example the meeting system, in a meeting,

a participant can't attend multiple meetings at the same time.

Unless the laws of physics change,

these are set by physical truth.

They also help us to understand the world in which we're working.

The next set of statements are assumptions,

and these are much more challenging to determine.

Assumptions constrain behaviors on specific environmental components.

As one example, let's go back to that meeting system.

We might assume that participants will

promptly respond to email requests for constraints.

Okay, for any of you who have tried to set up meetings

or expect email responses from people,

we know how well that usually goes.

However, if we don't make that assumption,

we may need to add a lot more into the system.

For example, an entire side reminder system.

We might also assume that a participant is on the invitee list for

a meeting if and only if he or she is invited to that meeting.

As a more complex example,

in our train example,

a train's measured speed is non-null if and only if its physical speed is non-null.

While we want to assume this,

just like with the meeting participants actually answering emails,

it's not set by physical law, it's an assumption.

This statement places a constraint on the speedometer of the train control system.

The last kind of statements are definitions.

Definitions are a bit different in that they have no truth value.

It makes no sense to say that it's satisfied or not.

For example, a person participates in a meeting,

if he or she attends the meeting from beginning to end.

Is that definition complete and accurate?

What does it mean to participate?

We may need to redefine full participation versus partial participation.

For example, do they need to talk?

If so, what defines talking?

How much do they need to talk?

Or, do they just need to be there?

If so, for how long?

Explora nuestro catálogo

Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.

Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.

© 2018 Coursera Inc. Todos los derechos reservados.

Descargar en la App Store

Consíguelo en Google Play