Making these assumptions, learning domain properties,
and writing clear definitions lead to your ability to elaborate on correct requirements.
This is very easy to mess up and requires our constant thought,
attention, and probably a lot of revision.
You know, I had this issue in one of my courses,
where I told my students that they were required to
participate in at least one class a week.
Also, if they couldn't be present in class,
I needed to be notified,
before the class, so that they would receive
participation credit for the day and not be penalized.
Given that statement, I had a student walk in,
probably 20 minutes late, say,
"Hi," wave and walk out.
Obviously, the definitions in my syllabus were not clear enough.
Requirements are hard.
A common misconception is that the target of
investigation in our software requirements documents,
is just the software itself.
This is not the case though,
you must explore the system of which the software is a component.
Requirements engineering also doesn't amount to
just some translation of pre-existing solutions.
For example, for those of you who have used a common course management tool.
The one that we, that I've been using students say,
"Oh my, this is so annoying," for various reasons.
And they say, "Oh, we need a course project,
we're going to remake this course management software."
First, yes, that was the look on my face and
response because it's utterly unreasonable given the scope,
unless it was a huge 100 person group and they never really wanted to graduate.
But it turned out in questioning the students more
that they didn't want to make changes to,
that they wanted to make changes to the product,
but they didn't understand even a quarter of the components underlying it.
All most of them really wanted to do was to be able to submit their homework,
get a grade, see the grade.
And because of that, they had minor complaints about how the system did that.
Another misconception,
is that requirements is just about figuring out what the users want.
But, it's also actually involving system design.
We can't just view software like we did in the waterfall model.
Often, we need to make decisions that may influence the system design.
Thus, even if you never want to code a single line ever in your life,
it's good to understand coding and good to understand
design because some of your requirements are linked so closely to this,
that you can only really understand them once the design has taken place.
Security is a good example of this,
especially when certain protocols, business rules must be used.
Unlike domain properties, requirements may need to be negotiated, changed or weakened.
When we discuss precise requirements,
we mean that every statement must have a unique,
accurate interpretation without necessarily being machine processable.
You can write requirements formally,
but precise is generally sufficient.
A set of notations may be a necessary condition for requirements engineering methods,
but not a sufficient one.
A requirements engineering method should provide
systematic guidance for building complex requirements documents.