3.1.

Requirements Analysis
1. Definition

- determins what to be done, taking and analysing the problem of the user, expressing it in
a language understandable by the developer (i.e. software analysis)

Objectives:
-understand the problems of the customer’s organisation and the reason to invest in a
software
- a common vision about the problems and the solution
- collecting and update the requirements (transforming these in specific requirements that
the developers will be able to understand and transform in functionalities/capabilites
- defining the limits of the future system (important to avoid the pressure to extend too much
these limits)

The analysis gives elements for negotiation (budget, planning). The impact of the analysis to
the costs and the project is major.

Specific activities:
- interviews at the customer;
- analysis of the requirements;
- development of the requirements (=> specifications;
- management of the requirements.
.
2. Software development axioms
From practice:

A1. The requirements always change during the project. The client always asks for more
than at the beginning and tends to extend the project beyond the initial budget. The client
does not know exactly what he wants and is inclined to change his requirements. To clarify
his own thoughts, he waits to "see the application first."

A2. Unforeseen situations always occur in a software project. Unforeseen situations are not
a deviation from the rule but are the rule.

A3. People get involved in the project are not perfect. Everyone makes mistakes:
programmers produce bugs, analysts generate analysis errors and project managers,
management errors. Most of the bugs in a large software product (some say over 70%) are
introduced in the analysis and design phases. The longer a bug exists in an application, the
more expensive it is to detect and fix it.

A4. Usually, the customer does not read the software specifications or read them in a
shallow way. Moreover, the feedback received from the client in the development phase of
the project is insufficient and incomparably less consistent than the feedback received after
exceeding the deadline of the project.

A5. There are no software project with unlimited budget. All software projects have
insufficient budgets.

3.Requirements levels

A. Business Requirements: These are the highest level requirements and are the highest
level objectives (or issues) of the client. These requirements are usually described in a
document called Vision & Scope.
B. User requirements: at this level are the tasks that the user will be able to perform using
the software. These requirements are usually specified in the form of use cases.
C. Functional requirements: these are the requirements addressed directly to the future
System, the functionalities that must be developed in order for users to be able to perform
their tasks. This level is the level closest to the System design.
The problem of the client is allways related to the business. The role of the analysis is to
describe the PROBLEM as complete and correct possible, without introducing technological
restrictions, narrowing the SOLUTIONS space only from the business perspective of the
client. Generally speaking, the client’s problem is related to business, not to technology.

4. Interviews

Points of view
Definition. Points of View are a way of structuring requirements so as to represent the
perspectives of different stakeholders.

Stakeholders can be classified as different points of view. Obs. Each point of view offers a
new perspective on the system; these perspectives are not completely independent - they
usually overlap, thus proposing common requirements. This multi-perspective analysis is
important because there is no single correct way to analyze system requirements.
Types of points of view
Interactor views - People or other systems that interact directly with the system. Example:
in an ATM system, the customer's point of view, the database's point of view.
Indirect views - Stakeholders who do not use the system directly but who influences the
requirements. Example: in an ATM system, the point of view of management, the point of
view of staff.
Domain views - Domain characteristics and constraints that influences the requirements.
Example: in an ATM system, standards for interbank communication.

Organizational problems: Who does the interview? This person needs to interact directly
with many work groups . It has to do with contradictory ideas . Must have communication
skills and work with people . Must have programming knowledge . In the end, he has to
agree with the client on the requirements
There are two types of interview:
• Closed interview: answers to a set of predefined questions are sought.
• Open interview: there is no predefined agenda and a range of issues is explored together
with stakeholders.

Meetings with the client, designed to gather requirements, are key elements of the analysis
process. These meetings are the ones that bring us or validate the information that underlies
the construction of the project. Although in some projects there may be alternative sources of
information (specifications, documentation), the most general case is still the one in which
the interviews bring the greatest amount of information. This is the reason why customer
interviews should be treated with great care, maximizing, as much as possible, the
information obtained, both by organizing and by actually conducting the meeting.

From an organizational point of view, first of all, the early announcement of the objectives
and agenda of the meeting should not be omitted. In this way, participants are invited to
prepare, in order to achieve those goals, formulate realistic expectations and can develop
realistic contributions to achieving those goals.

Secondly, the analysis session must always keep the focus on the proposed objectives, the
digressions being cut as soon as possible (keep in mind that an analysis session is not good
to last more than 2-3 hours, and this time should be used as best as possible).

In order for the meeting to be directed correctly, it is very useful to use an interview form
adapted to the type of meeting.
For the organization of the meeting it should be borne in mind that the number of participants
should not exceed 6-8 people, but it is preferable that the number of participants be 3-4.
Otherwise, control over the meeting will be difficult and the participation of some people will
prove unnecessary (think that if 8 people attend a meeting and each speaks only 15 minutes,
it results in a total of 120 minutes!).

Listen to the client

Given the importance of the client's contribution, sufficiently discussed in these articles, it
must be capitalized as productively as possible. The client must be listened to, understood,
asked, listened to again, understood again ... The client must not be interrupted, he must be
allowed and even encouraged to speak. Rule number one is that the analyst must listen
more than 80% of the time.

In the 20% of the time you have left to speak, be careful what you say because the
requirements are "snatched away", not written after dictation. These 20% are almost for that
alone. In addition to organizational discussions, these 20% mean questions, scenarios, open
recaps, in which the client is invited to continue or complete something.

Everything is validated by analyzing the logical consistency with other requirements, the
raison d'être of the requirements is sought. The question "why?" returns whenever
necessary. Everything has to have an explanation and the argument "because that's what we
want" or "that's what we pay for" is not enough.

But keep in mind that a normal person can pay attention to a maximum of 7 things at once
(both you and the client are probably normal people). Don't overestimate yourself and don't
overestimate your client so as not to miss important things!

Questions
It's always good to ask. Questions are the engine with which information is intensively
collected. Most of the questions are open-ended questions, which allow a broad
development of the topic, starting with the same "why?".
For example, "Why do you think you lose money by storing products?", "Why do you do
that?" these are questions that need to be developed. Once you have launched the question,
remember that you should not interrupt your interlocutor unless he is moving away from the
subject. Let him explain, search, strive to answer!

When it comes to ambiguous points, insist on clarifying things, using, as appropriate,

recapitulation questions: "I understand that your products fall into two categories! Is that
true?", "If a cargo truck arrives, don't start unloading until document X is not drawn up. Did I
understand correctly? "," The sequence of operations is as follows ... Is it correct? ".

Remember, whenever you are suggested a solution, be sure to ask "How do you solve the
problem now?"! This question along with "How could this be solved without a computer
system?" these are valuable questions.
Also use recapitulative questions whenever you feel like moving to a new "chapter" of the
discussion. The recap will mark a milestone on the road to get there, a summary of clear
ideas that can serve as input for what follows.

Write down the steps you have already taken, the clear ideas, the things already
"established". Also note separately the outstanding points, unfinished or unclear ideas, so as
not to interrupt your interlocutor whenever such ambiguities arise, but be careful that before
the end of the discussion the list of unclear problems is empty or rescheduled for a another
meeting.
Active listening
Active listening basically means the same permanent "why?". Listening, the analyst looks for
answers to the same "why?". "Why does he ask for that?", "Why would that be a problem?"
By actively listening, you will see that it is not always necessary to interrupt your interlocutor,
let him develop an open answer, build logically, and you will see that many answers come
naturally. But, I repeat, write down separately, the suspended points, the unfinished or
unclear ideas, so that you do not interrupt your interlocutor when they appear, nor to lose
sight of them.

Do not let things get out of hand, ask to be explained the terms used. Don't pretend you
understand, it's no shame to miss something from time to time (anyway, these leaks will be
found in the specification or, worse, in the application)!
Active listening aims to encourage the interlocutor to speak more. First of all, the interlocutor
must feel listened to, understood, even before being interpreted critically.
It is very important to keep eye contact. The speaker can also be encouraged by the girl's
expression (nod, smile, amazement, joy, bewilderment) or gestures. From time to time, short
interventions are needed to energize the discussion (keep in mind, however, that a
monologue cannot go on indefinitely!).

Types of information received from the customer

In the analysis meetings with the client's representatives, the analyst is the moderator of the
discussion. He must have constant control over the conduct of the meeting, which he must
consider a valuable resource - this is where the information for the development of the
specification comes from and also where the feedback for their validation comes from.

Maintaining control over the session means not only having moderator skills, but also
knowing where you are at any given time and where you want to go. In this chapter we will
see what types of information the client sends us, which shows us at any time of the
discussion where we are and whether we should insist on having more information or,
conversely, whether we should redirect the discussion to something else.
The types of information provided by customers are:
a. Business requirements Business requirements are high level requirements, important for
Analysis. These business requirements can be, for example, related to "inventory reduction",
"customer retention", "improving cash flow" and are independent of the IT system, in the
sense that the IT system can be one of the many solutions of that problems. These
requirements are rather answers to the question "Why invest money in this computer
system?".

b. Business scenarios, tasks For most users of the future system, it is easiest to express
their requirements by talking about their own tasks and how to solve their problems. The
analyst must never forget the questions: "What are your tasks, what are the out-putts of your
activity and how is this activity evaluated?", "How do you solve problem X at present?". The
expression of these requirements takes the form of simplified Use Cases that lead to solving
the task. It shows how things are happening now or how they should happen in the future,
following the automation of some steps.

c. Business rules These requirements express some existing constraints in carrying out
business tasks. They indicate who and under what conditions can do a certain thing. For
example, if the value of a contract is negotiated and it is less than 1000 EURO, the person
responsible for negotiation is the Sales Agent and if the probable value exceeds 1000
EURO, the person responsible for negotiation is the Sales Manager. Some of these rules
become requirements for the IT system, others remain at the level of the client's internal
working procedures.
d. Functional requirements The functional requirements express as directly as possible the
way the user interacts with the system. Although user-system interaction cannot be
completely out of the question (especially if the new system is expected to change certain
customer processes), it is absolutely necessary that all these requirements are well justified -
the analyst must ensure that these requirements have a reason to be, extremely clear. The
functional requirements, as documented in the specification, must be the result of the
process of analysis and development of the requirements, not the suggestions received from
the customer directly as proposals for solutions.

e. Quality attributes The fulfillment of business tasks will largely depend, after the advent of
the computer system, on its ability to respond, not only by the existence of functions but also
by their availability and the correctness of the way it solves the requirements. In this type of
requirement, there is always the risk of being vaguely or incompletely specified. For example,
it is not enough to say that the system must run "as fast as possible", "without errors" or "be
available as long as possible". It is also important to note that these requirements, taken to
the extreme, "the system will operate 24 hours a day, without interruptions", "the system will
operate without errors", "the response time will not exceed one second even if all are
connected the 1000 employees simultaneously and operate documents or run any reports ")
means costs that an ordinary budget cannot afford and which are usually unjustified. Quality
attributes are requirements such as non-functional requirements.

f. External constraints
Here we have included all the constraints imposed by the interface of the system with other
external systems, devices or external equipment (cash registers, barcode readers),
technology constraints (the customer wants to use a certain technology), data formats,
hardware configurations, special networks or means of communication, without being limited
to the list.
The analyst must ensure that he does not introduce unjustified restrictions of any kind. Any
such constraints lead to the limitation of the possibilities of choice in the design phase of the
solution.
External constraints are requirements such as non-functional requirements.

g. Data structures (data definition)

The way in which certain entities are defined, their attributes with the possible restrictions to
be applied, are common requirements that must be taken over and included in the
specification, normally in a separate section, called a data dictionary.
In their own way, these requirements are still constraints. They are like: "field X is of type Y,
with limits a and b".

h. Possible solutions
Although the last on the list, this type of requirement expressed by customers, is very often
insinuated in the middle of the discussion and gets the most weight. Possible solutions
should be treated as suggestions (and treated carefully because they come from people who
are not software specialists), not as real requirements.
No matter how good the ideas may seem, these possible solutions can hide future
developments that are not necessary or can lead to the failure of real requirements. The
rationale for such a requirement must always be tested.