Requirements
This section contains course syllabus regarding requirements. The following should be read and understood in order to create a requirement.
The Requirements Lifecycle
At different stages of the requirements lifecycle, our focus and
purposes shift. Our tasks and focus shift accordingly.

Why must we elaborate requirements?
-
Assume our team has made a great job in eliciting all
requirements as a list of keywords or short phrases.
-
We are now faced with two problems:
-
As we have seen in the introduction, it pays to improve the quality as early
on in the software lifecycle as possible.
-
But even if our requirements were perfect, they must be communicated to a
team, to programmers, to contractors, to other stakeholders etc.. We have
to make sure that everybody during the whole process understands the
requirements.
-
Also, the requirements may be in use for a long time. Will we ourselves
understand our requirements in the same way we do now in half a year?
-
So, we should try and remove all defects we can find with
reasonable effort, and we should cast our requirements in a
generally understood and durable form.
-
This process is called requirements elaboration.
-
The result is called a “Software Requirements Specification” (SRS).
-
Such specifications may easily be hundreds or thousands of pages long.
Requirements Attributes (Elicitation)
-
Probably the most frequently arising problem is incompleteness.
-
That is to say, an individual requirement dos not contain all the information
needed to work with it.
-
Yet, it is very easy to act against this problem by simply defining
explicitly all the attributes a requirement should have and
collecting them in a table.
-
This way, any missing items may be spotted directly.
-
The next to pages define the set of attributes with their names,
purpose, and sample values.
-
The table also indicates whether they may be used for sorting the
requirements by them which obviously depends on their usage and restricts
the attribute values.
-
Also, the tale defines whether the attribute is facultative (optional) or
mandatory (must be there).
-
The attributes should be filled in more or less in the order defined
by the table.

Identifier
-
A unique and persistent identifier. Identifiers never change and may never be reused
-
The simplest ID scheme is to use consecutive integers starting from 1.
-
More complex systems might encode additional information like the type, domain,
or level into the identifier.
Name
-
A short and descriptive term, possibly a phrase.
-
Usually, there are no constraints for requirement names, but with practice, people
will be aware of what the requirement will be implemented as (e g a process) and name
them according to the respective naming convention.
Description
-
A brief text of 3 10 sentences at most two paragraphs describing what is included in this
requirement.
-
If at all possible, use bullet lists or enumerations to structure the contents.
Rationale
-
A justification of this requirement: why is it being selected (1 3 brief sentences).
-
Even better is a reference to one of the goals from the goal model.
-
If a suitable goal is not readily found, adding a goal might solve the problem.
Source
-
Describes where the requirement came from
-
Typical values for this field include:
-
“interviews with users”
-
“Observation protocol #42, chief librarian Mads Tofte, 9.9.2009, 10:54:12-10:56:08”
-
“Usage scenario, line 27”
Details
-
More lengthy description without constraints, or a references to external documents
Remarks
-
Any additional comments that fit nowhere else.
Requirements Attributes (Elaboration)
-
Once the elicitation baseline has been established, the
requirements need to be elaborated somewhat further so that
they may be validated by the client.
-
After an initial validation, requirements are ready to be used for
project management purposes such as planning and scoping.
-
Using the requirements as the basis for software development will need a
further step (transition).

Aspects of Requirements: Elaboration
Type
-
A classification of requirements according to a project specific schema.
-
The most generic schema would be to distinguish between the following.
-
feature ("functional requirement")
-
quality ("non-functional requirement")
-
constraint – a project side condition
-
Additional classifications might add interface requirements, or may want to
differentiate features into crosscutting and self-contained requirements.
Acceptance test
-
Any operational procedure to check whether a deliverable satisfies a given
requirement.
-
Typical examples are tests of any kind, or observable parameters and qualities like
response times or presence of artifacts.
Derived From
-
Many requirements are split up or significantly changed. In order to keep
track of where a requirement came from, the “derived from” attribute
links such requirements to their predecessor
Level
-
The level of granularity or scope to which a requirement applies.
-
A raw collection of requirements will yield items at very different levels of
abstraction.
-
For instance, the requirements “identify book”, “return book”, and “media
lending & returning” belong to 3 different levels:
-
“media lending & returning” is a domain
containing a process “return book” which in turn
contains the activity “identify book”.
-
All of these may be fine examples of requirements, but they should be
treated rather differently.
