In the beginning of the course, the first two introductory lectures you have seen the
idea of a software development process and what the various steps or stages are going
to be in processes. Now starting today we are going to dive into
each one of these steps in greater detail and take a look at what comprises each one
of these stages. The first stage in the process of doing software development is typically
that of a requirement specification.
The person, who needs the software or the system in order to work with, is in the process
of writing down exactly what the system has to do for them, so that this can be effectively
communicated to the people who are going to build the system for the client. And that
is the process of software specification. It is a fairly well refined science.
We are going to take a look at what the different types of software specifications are that
exists, what are the different ways of going about writing down set of a précised software
specifications, and to take a look at how these things can be organized in a structured
manner in some kind of a requirements document. So the first step in the software development
process that I talked about, what is called requirements engineering. Requirements engineering
is really a process in itself.
Requirements engineering deals with the process of translating the ideas that the client of
a software system may have in their heads, down to being a specification on the paper
that can be well understood by the consultants, by the contractors, by the software developers
are eventually going to be the one's who are building the system.
So this is a process of establishing the requirements of the customer as of a system. And the different
constraints under which the system is expected to work at the customer of the client side.
The eventual artifacts that comes out of this engineering process, is the requirements document.
And the requirements document has within it individual types of requirements, there might
be functional, non functional requirements, and the different constraints that the system
would have to adhere to when it is functional at the client side.
So let's get into the notion of what exactly is a requirement itself.
The requirement can range from being a high level abstract description of what the system
is expected to do or the constraint of the system all the way to being a precise small
mathematically formulated specification itself.
The reason why this wide range exists in the definition of what requirement is because,
it can serve multiple purposes. The requirement itself can be used as a basis for putting
out a request for proposals. An RFP, as it is commonly called in the software world.
This is often done with the intent to have the contractor or the software developer put
together a bid, as to how they are going to go about developing the system for the client.
And so this may be a basis for a bid or contract and so it has to be open to a certain amount
of interpretation. The actual design or the development side of it must not be specified.
It certainly should be left open in a requirement specification. And even the requirement itself
must be left open to a certain amount of interpretation.
This may be on the basis for the contract itself, and not on the basis for RFP or the
proposal then it has to be defined a lot more rigorously. There has to be certain level
of detail, there has to be certain level of specificity that must be attached to the software
requirements. And in order that it is now not open to misinterpretation by the other
parties. Because this often results in one of the things that have to come out of the
software specification is, what will eventually be delivered to the customer or the client.
The costing methodology that will be used, as well is going to figure into this.
We have seen the range of what the software requirement can be.
It can be something that is not very precisely specified and open to interpretation all the
way down to something that is very mathematically specified, very rigorous, and something that
is understood well enough that there cannot be two opinions about it.
There are different needs for this and depending on the kind of need that you intend to address;
you will end up defining the requirement in a particular manner.
So this is in the words of a famous software engineer called Davis.
It is basically that you have to be careful not to over specify at the time that you are
putting out an RFP for contractors to prepare bids for. The requirements must never overstep
their bounds into the realm of design. They are pretty much should not be dictating how
the system is to perform, what it is to do. But it is always to confine itself to specifying
what the system is to do itself. Both of these documents can be called requirements
documents. One of them is fairly open like we talked about them, one of them is very
close, very detailed and there is no room left for interpretation. But both of the things
can be called, requirements document and they are organized based on the client needs during
the appropriate important time in the software development life cycle.
Typically there are two kinds of requirements that the requirements document will end up
containing. They can be classified along two different axes. One axis is that of the user
versus system requirements.
User requirements are typically those requirements that the end user of the system, manager of
the development process, the contractor can understand. These are the audiences for the
user requirements documents. They are typically written in a natural language. They don't
include computer jargons of any kind. And this is typically the requirement that the
users will sign off on, before the development process is to begin.
The system requirements also sometimes called functional specification is written more from
a developer's perspective, by an architect or an analyst who is intending to precisely
lay down the rules along which the software system is going to be build. So it defines
a systems function, it defines the services in the system and defines the constraints.
The précised constraints along which the system is expected to operate in the client
side. This is typically the basis on which the contract is signed between the client
and the software developer for the system requirements.
Now another axis in fact along which this can be differentiated is something called
a functional and non functional requirement specification as we shall see shortly during
this lecture.
Here is an example of a user versus system requirement specification.
The first bullet on the slide is actually referring to the requirement that states that
the system that is being put together has to provide a means of accessing external files
created by other tools.
For example, if you are on a windows system and there is a file that was downloaded which
is a PDF file or it may be a "mpg" file or it may be a "jif" file there are different
types of files. Now all this is stating that, the system that is being build, lets say the
operating system in this case, has to be able to provide a means of accessing, opening and
viewing external files that are created by other tools. So at the level of the user this
is what is expected. Now an analyst or an architect would take
this user requirement and translate it down into a series of fine grained steps. It would
precisely state what are the different pieces of functionality that has to be included as
part of the system. For example in this particular case, the requirement
of being able to access external files is boiled down to, first of all the user needs
to have facility to define a file type. So typically if you use a browser, you might
want to attach what are called mime types and associate each mime type with a type of
file that the browser some times ends up downloading. So the browser knows that when a PDF file
is downloaded, it has to launch a PDF viewer. So that definition, the capability of defining
that association between a file type and a tool which has to be used to open the file
needs to be available in the system. The second thing is that, every external file
should have an associated tool which can be applied to view the file. By which there has
to be an option given to the user to do a selection dynamically. This is also typically
seen when you try to open an application that the window system does not understand, it
will pop up a dialog box in which it will request you to make an association of an application
with the file type that it is unable to understand. So if it cannot be predefined, there has to
be a way of dynamically defining the association as well. Every external file when it gets
downloaded onto the system needs to have an associated icon that can be attached to that
file. So PDF files typically have the acrobat type of icon that gets attached to the files.
So instantly on looking at the icon you know that a PDF file can be opened with a acrobat
reader.
Finally the fourth step is when ever the user is selecting an icon, but double clicking on it, then the
effect of this double click must be to apply the associated application to the file and
open the file by viewing the user. Something as simple as a high level user requirement
which was to be able to view and open external files on the system. Files that are created
by tools other than what the system provides has been translated down to something much
more precise in this particular case and that is what really tries to bring out the difference
between a users requirement definition which gets translated down into more precise specification.
It is not a definition, but is a specification of exactly the kind of functionality that
the system was expected to provide. And also the exceptional conditions that might be encountered
and how the system is going to end up reacting to these kind of exceptional situations.
So as we see, there are three different categories of documents that can end up getting created
at the very start of software development process.
One is a set of user requirements and the audience for the user requirements that I
have mentioned before, are typically the end user; system end users themselves, the most
important audience. And certainly the managers of the customers
are going to end up buying the systems, because they may not understand engineering jargon
that goes behind the building the system. What they are interested is the end product
of the process, eventually and what they are going to get. At the same time the engineers
would be interested, the developers who end up building a system would also be interested
looking at this just to get an idea of what the users ends up expecting.
The system requirements however have a different kind of audience. The system requirements
are not by the user, not for the user, but translating the user requirements into more
precise specification, that translation is done often by system architects or by business
analysts within the software development company. And the audiences typically are meant to be
the development staff themselves. And it is some what closer to a design specification
although design specifications now get into the area of defining how to build the system
and not what the system is expected to do.
Another axis along which the requirements can be classified or categorized is that of
functional and non functional requirements.
A Functional requirement is the name indicates has something to do with what is expected
in terms of functionality of a systems behavior. So how should a system react to a particular
set of inputs, what exactly should be the series of steps that the system is to perform
in order to accomplish a particular task, how should the system behave in particular
exceptional condition? For example, a file is not present when the
user tries to open that file. So those are the kinds of a statement of services
that the system is expected to provide purely from the perspective of the functionality
of the system. Non functional requirement obviously includes
everything else. It is a catch all bucket to put in requirements that don't fit into
the functional structure of the system. And there are several sub categories of non functional
requirements; we will get to see some of them during this lecture. But roughly this has
to do with requirements that don't directly deal with the functionality of the system,
but it does end up affecting how the system behaves at the end.
A good example might be that the system is expected to run on a computer which has less
than 128 MB of RAM, which would be a non functional requirement. This is not externally visible
from the system UI or the behavior. But it is something that could have an impact of
the performance of the system which may or may not be directly perceived by the user.
And it would slow the system certainly the user is going to notice. But it is not something
that is functionally part of the system's interface.
It is a constraint on the way the system is going to end up behaving. It can also be a
constraint on the development process itself; the kind of tools, and the kind of technology
that is going to end up employed. For example, a non functional requirement
could state that, you have to conform to CMM SEI level 4 in terms of a quality process
during development. It has nothing to do with what the system
is going to end up doing. But it has something to do with the processes that you end up following
as a development organization itself and some standards that may end up using the process.
This slide essentially describes the notion of functional requirements which we have already
gone through.
So we are going to move on here.
Here is an example of functional requirement, actually the user requirements.
For a library system that provides a single interface to a large number of databases,
which can contain articles from different libraries.
The users can either search for different articles and they can search based on different
parameters such as authors, the title of the article, the area, the topic on which the
article is written and so on. They can download these articles and print them for personal
use.
Now if you take a look at such a kind of the user description of the system, when you try
to translate down these in to the functional requirements of the system, it could boil
down to one of three points.
The first point being the user should be able to search for all the articles from any one
of these databases, or select a subset of the articles based on certain search criteria
that they are going to specify. And some of the search criteria may be the
authors name; the first and the last name of the author, or it can be the year of publication,
it can be the title, or certain keywords that may be present in the article, it can be a
topic on which the article is written. For example, "Computational biology" and if
they search for articles in "Computational biology", then the system should be able to
display every article that falls into this range.
The system should also provide for appropriate "viewers" for the users to read the documents
in the store. The documents can come in several formats. In a library documents can be in
PDF, it can be in Microsoft word, it can be in Postscript, or it can be in various other
formats and the system should be able to provide the "viewers" for the formats in which it
stores the documents in.
Every order for downloading the document is going to have an order number that is unique
and that is to be associated with it, because there is certain cost that is to be borne
on the system side for this. That can be used for tracking, the purposes of the cost, and
the completion of order and so on.
So those are the examples of the functional requirements that can be given for the library
system that we are talking about here. Now when you take a look at some of this,
there is a certain degree of imprecision that you may have noticed in writing down requirements.
And certainly problems are going to arise when the requirements are imprecisely stated.
Since it is open, it is ambiguous for interpretation, what the client may think of may not be what
the developer is thinking of from his perspective when he looks at the requirements.
One of the things that you can consider from the previous slide is that, the system has
to contain all the appropriate "viewers" for the users to be able to view the documents.
Now the user intension was that there would be a special purpose "viewer" for each document
type; meaning, the acrobat reader would be used for PDF files, Microsoft word for word
files and so on. So that associations would be made by the system and appropriate viewer
would be fired upon the document being selected.
The developer interpretation could be something totally different in this case and he may
consider the fact that I can extract the content of the document into plain text, represented
in a textual viewer and display this to the user.
Both of these would satisfy the term "appropriate viewer" as was specified in the requirements
document. But the ambiguity and the imprecision with which it was laid out can create significant
problems later as is pretty obvious in this example.
So in principle, requirements have two important characteristics that they have to satisfy.
The first characteristic is that of completeness. The requirements have to be complete in the
sense of being or specifying exactly what the system is to do and it should also specify
along the same lines what the system is not to do. That is the definition of completeness.
The second characteristic that is very important when writing down requirements is the notion
of consistency. To avoid the kinds of ambiguities and the openness, which can be interpreted
in different ways that we saw in the earlier example, there has to be a certain degree
of consistency, there should not be any conflicts or contradictions in the description of the
system facilities. A good example might be one in which the system
has to perform a certain requirement, say for example, minimum number of chips that
was used to build the system. This is not a software system that is being built, but
a hardware system. And this notion of requirements could equally apply to a hardware system specification
of work. So the requirement on this particular system specification was that it would be
built with a minimum number of chips, because of the problem with size. And multiple functions
had to be put in the same chip. But in the other hand another requirement in the same
document stated that due to power considerations, each chip had to use the least amount of power.
Now there is a certain element of contradiction about these two requirements. One is stating
that you need to use the smallest number of chips, which would mean combining multiple
chips functionality onto a single one and which means the need of power is going to
go up. At the same time it is also stating that due to power constraints, you need to
be able to have chips which consume the least amount of power.
So in practice these kinds of conflicts are going to arise all the time. And it is considered
close to impossible to provide a completely consistent requirements document, although
there have been the development of formal methods which allow you to verify thru machine
verification techniques whether the requirements are complete and consistent. But that is something
that we are going to look at in the later lectures of this course.
So far we have looked at the notion of what user and system requirements mean. And we
have seen another axis along which the categorization of requirements can be done for functional
and non functional requirements. We have seen the definition of what functional
requirements are and their purpose. We will now take a look at what non functional requirements
means.
As the name implies non functional requirements have to do with system functionality that
don't exactly concern the user experience directly. So these define system properties
and constraints, it could be on processes, it can be on a development methodologies that
you end up using, it can be on technologies that can be employed to build the system,
it can be on performance, reliability, availability of the system and so on and so forth. So they
themselves can be categorized into various sub classifications.
Some of the examples that we have seen earlier are particular process that has to be adhered
during the development of the software system, for example the CMM SEI level 4 processes
or it can be the use of a particular technology. For example a web page that has to be build
should not contain frames is a kind of a requirement. Or it can be a performance requirement or
an availability requirement of the system which doesn't directly affect the user experience
of the system. One of the things that are not to be confused
is the fact that non functional requirement does not mean that they are not as important
as a functional requirement. In fact there can be many situations in which non functional
requirements are often much more critical.
Availability requirements on a system, for example if the availability requirement for
trading systems that are used by stock exchanges must be close to 99.9%, if you even had loss
of system availability to say 5% and bring it down to 95% it could translate into a loss
of 100 Crores of rupees typically for system which have very high trading volumes.
So some of these non functional requirements in turn can be much more critical than functional
requirements and if these are not met, the systems can also become quite useless in nature.
Some of the classifications that we can take a look at as far as non functional requirements
are concerned, are product requirements. Product requirements can be things like execution
speed. Let's say you are doing transactions on an
e-commerce website. E-commerce site have users coming to it to buy certain goods. In this
case, one of the non functional product requirements could be that 85% or 90% of all the transactions
that are conducted on this site should be complete under say less than five seconds.
So execution speed can be one of the product-non functional requirements. 'Reliability' or
the 'Availability' of the system is another product related non functional requirement.
Now another category that we can look at is organizational requirements. Organizational
in the sense, that there are certain policies and procedures that can be followed in a particular
organization. And those policies and procedures had to be taken into account during the development
of the software. So process standards that are used, let us say it is an ISO 9001 complaint
process that was used to produce the product, that is one of them.
Then there can be what is called external requirements, which are requirements that
arise from factors that are completely external to the system. And the process that was used
actually used to produce the system itself. So one of the examples could be that, this
software application that is being build has to work under any J2EE complaint web server.
What is trying to state is that, if I change out a piece of infrastructure from underneath
this application today, and replace it with another infrastructure that is kind of equivalent
in functionality, based on a certain standard then the application should be able to perform
in exactly the same way as has been stated by requirements document.
There can also be legislative requirements. The system has to work; especially the applications
that are developed for military for example, come under very strict laws of legislations.
They may say that this has to conform to certain standards, guidelines; it has to conform to
certain quality guidelines and so on. Those are kind of external to the system and development
process itself. This slide actually gives a more detailed
break up of the different non functional requirements.
Starting at the high level are the product non functional requirements, the organizational
non-functional requirements and the external non functional requirements. And the product
requirement itself can be classified as usability requirement, efficiency requirements, and
reliability or portability requirements. Under the heading of efficiency comes something
like performance for example. Performance need not always be in the execution speed
aspect of it. It can also be how many resources are consumed by the system in order to provide
the functionality. So for example, if the system has to fit on
a disk which has less than 10 Giga byte of disk space or it has to run on a system that
is less than 128 megabytes of memory. Those are space requirements.
Performance requirements on the other hand really have to do with, how fast the system
executes. Organizational requirements can be classified
further into delivery requirements in the sense, how the system package is is going
to be. Whether in a CD or is it going to be downloadable software, is it going to come
on a tape of some kind etc. There can be licensing requirements attached to it.
Implementation requirements such as particular standard process have to be used during the
implementation and so on. External requirements are classified typically
into interoperability requirements; you have to be able to interoperate with the other
external vendors. For example, if I am buying a system from Oracle to do a financial accounting
and we can put in a constraint saying that I have an SAP or ERP system and I have to
be able to put data into this as well as extract data out of the SAP system and be able to
interoperate with this particular system.
Then there can be legislative requirements with the advent and the explosion of web based
systems, privacy concerns have taken up very important role. So there can be privacy requirement,
for example the data that is provided to the system shall not be shared or shall not be
accessible by any other persons. There can be security requirements, safety
requirements and so on. Those are external to the system in the development process by
which the system is made by itself.
Some of the examples of non functional requirements once again are product requirements with respect
to the library system that we were talking about earlier, is that the user interface
of the system should be implemented in straight forward HTML and there can be no frames or
java applets to be in this.
This could arise from the fact that the system can be accessed on really simple client boxes,
which may not have the hardware capability of learning heavy duty java programs. As a
result of which there is a requirement that there can only be a browser on client side
and there may not be capability to run java as a result of which the user interface must
be in plain HTML. This is a product requirement and it is also not only directly concerning
the functionality of the system, it is a product non functional requirement.
The organizational requirement we talked about can be process related. The standards that
have to be followed during the development say ISO 9001, SEI CMM standards and so on.
The external requirement on the other hand is one of the privacy requirements that we
have about before. The system should not disclose any information that is given to it, especially
regarding users or any other details of the users. And only internally to the different
modules of the system shall this information be accessible, but by no other non users of
the system can this information be extracted is one of the conditions.
This may of course translate into a specification that says that any and all user data that
is captured from the system shall be encrypted and stored in 128 bit encryption and so on.
This will guarantee the security of the data.
One of the important things that we have to watch out for is to distinguish between the
notion of a goal and requirement.
Goals are typically an intension of the user. One of the goals of the system may be is to
bring down the time to process a particular document. Let us say this is an insurance
claims processing system that we building and it is taking extraordinarily long time
today to process each insurance claim. Let us say it is taking like 40 minutes to an
hour for user. One of the goals may be to bring down this time.
Now this can be translated into a requirement that says that there has to be some usability
factor that is built into it. For example the user may have to be able to
learn the system with less than two days of training and after this the user have to be
able to process insurance claims in thirty minutes or less. So this is a verifiable non
functional requirement that is being introduced into this system with the goal of trying to
improve the general productivity of the organization of the system for which the system is being
built. It is useful to have both goals and functional
requirements and non functional requirements as part of the requirements document, because
the goals convey a sense of what the user intends to do with the system and this is
always going to be useful to the software developer, the designer in putting together
the system itself. Here is an example of the differentiation
between a goal and a verifiable non functional requirement.
The goal is that the system should be easily used by experienced controllers and it should
be organized in such a way that user errors get minimized.
And how do you turn this into a verifiable non functional requirement is that, the people
experienced controllers who have a good idea of the domain, should be able to catch up
with the system functionality with less than two days of training, or two hours of training
in this particular example, and after this training, average number of errors that are
performed by the human operators during the system should not exceed two per day.
So this is a very quantified requirement, it is very precise and it's a non functional
précised requirement and that kind of takes the broad goal that has been laid out for
building a usable and human friendly system and lays it down to more precise language
of being a verifiable requirement.
We will now start taking a look at some of the techniques that can actually used to put
down these requirements. So if we take a look at user requirements, they should describe
both functional and non functional requirements in such a way that they are understood by
the system users themselves so it should be expressed in some kind of natural language
it can use diagrams it can use tables etc. But it has to be understood by users without
the detailed technical knowledge of how the system is going to work, but exactly what
the system is going to do. The problems as soon as they think of natural
language, let us say that the requirements are going to be written in English. The first
problem that comes up is that there is a certain degree of ambiguity or the lack of clarity
around natural language, because precision is difficult to achieve and something is being
written in English. Which is why English is not a computable language directly.
So there is a lack of clarity and to achieve a certain degree of precision is going to
be very difficult without making the document to be far too verbose to read. So the requirements
document can run in to hundreds of pages because every small functional requirement is being
specified to a great degree of detail.
The other issue that can arise is requirements confusion. So the level of detail gets missed
up. For example, at one level it can be conceptual but the same requirement can also be talking
of a different level of detail which is very fine grain, which is one aspect of it. Functional
and non functional requirements can tend to get mixed up that is another aspect of it.
So the requirement confusion tends to cover this notion of mixing up different levels
of detail, mixing of different types of specification, different types of requirements into a single
statement. Finally there is the notion of requirements amalgamation, which is a situation
that tends to combine multiple requirements into a single statement or is being expressed
together. For example, there can be a notion of trying
to introduce security as well as some kind of costing practice into the same system and
we will see some of the examples of this as we go along.
But these are some problems which arise from natural languages right here is going back
to the example of the library system that we were developing earlier here is an example
of requirement that causes some degree of confusion.
This statement I am going to read it out just for your reference.
LIBSYS shall provide a financial accounting system that maintains records of all payments
made by the users of the system. The system managers may configure this system so that
regular users can receive discounted rates.
Now what is the problem with this statement as you would say it?
The first thing is that, there are two requirements that are being stated in this one specification.
The first requirement is that conceptually they want the library system to now have the
notion of some kind of financial accounting package that is attached to it. So it's very
conceptual notion at this point, very high level, its not detailed or specified or specific
enough to what exactly that accounting package is going to do. But at the same time the next
sentence which talks about notion of configurability by the system's managers and users as a discounted
rate is very specific.
These two requirements which are being merged into one single specification have very widely
differing rates of specificity about them. One is quite general, quite conceptual and
the other one is quite specific and very precise. So the mixing up of these kinds of specification
which results in what is called requirements confusion is certainly something to be avoided.
It also looks at both functional and non functional requirements getting mixed up together in
this particular case. So there can be several ambiguities that results from a specification
such as this.
Here is another example which we would not go into a great level of detail which is also
mixing various kinds of requirements.
So the first example of LIBSYS system that we discussed earlier already mixes the notion
of a conceptual requirement at the notion of more detailed requirement.
And it also includes some unnecessary detail at this level. Now the fact that there needs
to be a financial accounting system and the fact that system manager must be able to configure
that particular system in a particular way is something that can be separated out clearly.
And the next example about the grid also mixes various kinds of requirement which are conceptual,
non functional, UI, backend requirements and so on, which is certainly to be avoided.
One of the things that will help in this particular case is to do a structured presentation of
the requirement. So we can start breaking it up. Let us say in grid editor example,
one requirement can be about the grid facilities where the grid itself should be laid out as
a matrix of horizontal and vertical lines, and it should always be a background to the
editor window.
That is a very specific requirement and the grid shall be a passive grid where the alignment
of the entities is the user's responsibility. That is one particular requirement.
There can be some rationale to back up this requirement as shown in the slide. And the
specification is very clear, it says 'this' particular tool shall be used to build and
'this' is the person who wrote out this specific requirement 2.6.1 about grid facilities.
So it is about a structured representation of the same requirement, instead of simply
writing it down in plain English paragraph, and breaking it up to certain set of sections.
The first section could be stating the actual requirement, the second section is rationale
for 'Why' and this provides the intent of the goal of the user which can be taken into
account by the designer of the system down the road. And then if there are any other
constraints that are to be met as far as this requirement is concerned. There can be specific
technologies that can be used to meet the requirement and there can be certain processes
to design this requirement and so on.
The source of the requirement must always be included. The reason behind is that if
there is any ambiguity about it, then the source can be contacted and the appropriate
clarifications can be sorted out.
So the guidelines for writing a set of requirements that can be easily processed, that can be
clearly understood by both parties. Party that is seeking the software system
to be built, the party that is actually building the system, should invent some kind of structured
standard format and to use it across all requirements that you end up writing.
And so along with the structured standard format there may be certain terminology that
may be defined. All the terminology is going to be defined upfront and the same standard
terminology and the language is being used in a very consistent way through the rest
of the document. The third thing is to use text highlighting.
It is a very common feature that is used to point out important text parts of the documents.
And it identifies key requirements very clearly. One another thing that we should always take
towards is to avoid computer jargon in the specification of the requirements as far as
possible. There can be situation where this cannot be avoided, for example the usage of
'frames' versus the usage of plain HTML in the UI. This is to the certain extent does
assume knowledge of technology from the users perspective. And it is a non functional requirement,
but to avoid situations which would expect the user to understand certain computer technology
in anywhere or at any level is to be avoided as far as possible in requirement specification.
The moment the requirement is translated into a specification instead of a definition, these
things are going to stop peeping in and that is okay at that point in time.
System requirements are more detailed specifications and their specification as supposed to the
requirement definition as we saw earlier and they are intended to be used as a basis for
designing the system down the road.
A high level architecture is going to be performed upon analyzing and reading these system specifications.
And these are typically used for incorporating into contract that is signed between the client
and the customer in this particular case. In principle, requirements need to stay away
from design. The requirements are meant to state what the system is to do and not how
the system is to accomplish the task. In practice, sometimes it is difficult and this distinction
gets blurred and they become inseparable in certain situations.
So the system architecture for example may be designed to structure the requirements
itself. The system may interoperate with other systems that generate design requirements
and that can also be a situation in which the line blurs. The use of a specific design
may itself be a requirement, a classy example where the notion of frames versus the plain
HTML.
So far we have primarily looked at natural language specification requirements.
Now we can take a look at some of the alternatives that may exist in using natural language or
English like language in order to specify requirements.
There are three primary categories of alternatives that we can take a look at.
One is structuring the same natural language requirement that we have been talking about.
But give a very small degree of flexibility to the requirement specification person by
using forms or templates. The forms are kind of pre-canned and they give a certain degree
of flexibility required. But mostly it allows you to specify things like modules and on
a per module basis which allows you to specify certain inputs/outputs, what the module is
expected to do and so on.
It does pre suppose a certain modularization but that is something that cannot be avoided
with this type of specification.
The second alternative is mainly that of what are called design description languages and
graphical notations are often used in these languages. So they are not textual languages,
but they are languages which have a certain degree of graphical notations. They are UML
with use cases and message sequence charts is an example which is the most popular one.
Even though UML has been used as a design language it can certainly be used to layout
certain set of requirements as well.
The third set which is a category that we are going to get into more deeply during the
next lecture are mathematical specifications. An example of mathematical specifications
is algebraic specifications. And here the emphasis obviously is on formalities on rigor
and is on trying to put together specifications that can be proven as well as systems can
be directly generated from these sets of requirements.
So structured language specifications as we have already gone through in a little bit
of detail, is the freedom of the requirements writer now gets cut down a little bit, because
of the predefined template that is now being used to specify the requirements.
And the template also serves one more purpose it tries to introduce a structured method
of the standard by which every single requirement is specified. So that one requirement is not
specified in a way that is distinct from another requirement. The terminology can also be limited,
for example these forms can be automated and they may not take in certain types of terms.
The biggest advantage really is that it is a nice blend between the expressive power
of the natural language and the freedom, the flexibility that is going to give you coupled
with the rigor that is being introduced by structured form or template that can be used
to write down the specification here.
The form based specifications like I said earlier, do lends itself to a certain degree
of modularization. So you can assume that there are a set of modules in the system,
for each one we are specifying what the module is going to be doing, not how it is going
to do it. This is typically done using a set of inputs to the module, a set of outputs
to the module is expected to generate, and if it is dependant on any other module in
the system for example, any kind of preconditioned inputs which needs to be validated by the
module, for example if we were giving a name then it usually cannot be having numerical
characters in it. This could be an example of a precondition, which will validate a piece
of input coming in. And the side effects if any, of each one of
these modules or functions within the modules themselves, are typically how forms are put
together.
Tabular specifications really supplement the form based specification and tabular specification
is especially useful when a number of conditions would have to be specified. And based on the
condition and the value of input variables any number of output actions may be taken
and alternative course of actions may be taken. An example that we will see in this slide
is for an insulin meter that is reading the sugar level and the UI for this.
If the sugar level is falling then there is a certain action to be taken. The R2 and the
R1 here refer to the two previous readings of the sugar level in this particular case
and the current reading is R0. Depending on what the previous three readings were, it
is going to take any number of different actions either change the dosage of insulin that is
going to be released or it may just keep it same or keep it constant. This is an example
of a tabular specification.
Graphical models like we discussed are primarily UML derivatives and these are essentially
use cases which are supplemented with the help of message sequence charts. The use cases
essentially details use case for every single scenario that is possible with the user of
the system. So for example if you are modeling an ATM machine from which one could extract
money or do financial transactions with the bank, then one of the use cases may be that
the card is validated upon insertion. So what exactly happens within this process
is the sequence of actions that go on and the sequence of actions can be then depicted
by the means of a diagram that we are going to see down on this sheet.
The diagram basically outlines basically four different actors in the ATM card reader.
The ATM machine itself which is like an abstract notion of what the ATM is going to be doing.
For every time the card gets inserted a session is started by the ATM which is what is indicated
here and finally there is the customer console or user console.
So what this diagram is trying to indicate is that, the card gets inserted and once the
card gets inserted then a message is sent to the ATM from the reader saying a card is
just been inserted. The ATM immediately then creates a new session, which is indicated
by the next arrow and then activates that particular session. This is denoted by the
'act' method that is being called in the session. As soon as the session is activated, it goes
ead and reads the card which is a first action that is done. So this is the Y axis
going down versus time. And in the increasing order of time, these sequences of actions
are taken by the different actors in the system. So it reads the card, then it asks the customer
console to insert a pin. The customer inserts a pin which is indicated by the dashed line
coming back from the reading the pin and then it validates the card.
So this is an example of a graphical notation that can be used to very formally specify
exactly how specifications can be put together.
The last type of specification is mathematical specifications. The mathematical specifications
are those that define requirements of the fair amount of the rigor almost in the form
of axioms which can be proved using theorems. Therefore these lend themselves to program
generation in the back end. So that's the next lecture that we are going to get into
that in a little while. But just to close out on this, the requirements
document is something that is an official statement of what is required from the system
that is being build. It should include the user requirements as well as the specification
as is going to be seen by the rest of the users of the system that goes behind the scenes.
So there are several different users of this document and it sorts all the way from the
customer who actually writing this document and reads this as a reference in terms of
what has been specified and what has to be expected to the system that is going to come
out. All the way down to the test engineers within the software development organization
we are going to read it to build the appropriate test plans and then test the system itself.
Actually there is a standard by which the requirements document can be specified is
called the IEEE requirements standard. And it defines a structure it defines the template
or the structure that we are talking about a few minutes ago. Which gives various sections
and importance is given to both general requirements as well as different kinds of requirements
such as functional and non functional requirements that had incorporated in this document.
So going forward we are going to take a look at how requirements can be specified as well
as formal methods can be used or mathematical methods can be used in order to specify, validate
and then turn the requirements that goes in to the system