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?
Kristen Walcott-JusticeAssistant Professor
