Before I conclude this lesson, I want to say
a few additional things about the Software Requirement Specification document
or the SRS. And I want to do that because this
is a very important document and some of the projects
actually require you to produce one. So why is
the Requirement Specification such an important document? That's because a
Software Requirement Specification document is an important fundamental way to
communicate. Requirements to others. For example they represent a common
ground between analysts and stakeholders. Note however, that different
projects might require different software requirement specifications so you
need to know your context. For example, the SRS
document that you have to create for a small project
performed by a few developers can in most cases.
Be a concise and informal one. Conversely the software
requirement specification for a multi-year project, involving a number
of developers can be a fairly complex and extensive document.
So again you have to be aware of your
context and build your software requirement specification accordingly. In
order to have a common format for the SRS
document, IEEE defined a standard that divides the document in
predefined sections. And in the context of this course,
we will use a simplified version of the IEEE
SRS format that includes three main sections. An introduction,
which discusses the purpose, context, and objectives of the project.
A user requirements definition, which contains the user
requirements. And the system requirements specification, which includes both
functional and non-functional requirements. And we provide more information
about this format when we discuss the projects. So
to conclude the lesson, I want to point
out and in some cases recap a few important
characteristics that requirements should have. First of all, requirements
should be simple. Not compound. Each requirement should express
one specific piece of functionality that the system
should provide. Requirements should be testable. We mentioned
this before, but I want to stress it
because it is a very important point. Untestable requirements
such as the system should be fast, are
useless. Requirements should be organized. Related requirements should be
grouped, more abstract requirements should contain more detailed
requirements, and priorities should be clearly indicated when present.
Finally, requirements should be numbered, so
that they can be traced. For example,
numbered requirements will allow you to trace
them to design. Implementation and testing elements
and items, which is something that you might have to do for one of
the projects. And that we will discuss in more detail in a later class.