Problem Definition and Requirements Capture

Software System Life Cycle

What is a 'system'?
The first quest here is to define what we mean by the term system.
General examples:
Solar system,
Digestive system,
Communications system,
Computer system.
The term is used in a number of different ways, and we may define the it as follows depending
on the entities involved:

a set of objects viewed as a whole.

a set of interrelated objects, viewed as a whole.
a set of interrelated objects, viewed as a whole, with a boundary and environment.
a set of interrelated objects, viewed as a whole, with a boundary and environment, and
with a purpose (man-made).

In this course we consider the class of 'systems' covered by the last of these definitions.
System Boundaries
Our definition states that the system has a boundary. This sets whether things are regarded
as inside, or outside of the system. With information systems, it can be difficult to draw the
'boundary'. We may have a choice as to which elements we wish to consider as in the system,
and which we choose to leave outside. This will have a fundamental impact on our eventual
system design.
Issues like:

money,

time,

resources and

cost effectiveness
can have an impact on where boundary is drawn.
Part of problem definition includes deciding where the boundaries will be drawn.
Stages in System Development
We may divide the development of an information system into a number of stages. One
scheme for this is:

Problem definition,
Feasibility study,
Analysis,
System design,
Detailed design,
Implementation,
Maintenance.

Other models used include:

The Waterfall Model

The System Development Life Cycle

Each stage of the system development cycle will produce deliverables that form the working
documents for the next stage. Examples of such deliverables are:

Reports,
Models,
Specifications,
Software,
Manuals

Problem Definition
Problem definition is the first stage in the System Life Cycle and is also the first step in defining
the customers' requirements. This stage is very important as it should provide a firm foundation
for the project. At this stage we need to produce an initial description of the problem area so
that this can be agreed with the customer before proceeding to the next stage of the project.
Problem Definition equates to the first part of Requirements Definition
Importance of Problem Definition
It can be observed that majority of the errors in information systems development were
attributed to inaccurate requirement statements. As the result, system developers developed
systems which were not meeting the needs of the users. It is therefore of paramount
importance that the system analyst develops an accurate requirement statement working with
the users.
Deliverable
The deliverable from a the Problem Definition stage is a report covering:
1.
2.
3.
4.
5.

the problem, as described by customer and understood by developer

the objectives of the new system
the scope and size of the project
preliminary ideas on how system might be developed
recommended action for next stage in development of system

Attributes
Key attributes of the report are that it should:

cover what the system will do, not how it will do it

be clear
contain sufficient detail
be complete

Underlying Task
This is known as 'Requirements Capture'.
Problem Definition involves a high level view of customer requirements and not the full detail
produced during the stage 3 (Analysis). The deliverable is aimed at managers and users.

Issues
You will find that customers often do not know what can be achieved with an Information
System. This is especially true when the customers have not used an information system
previously. The customers' initial ideas on the problem are normally quite vague. We may need
to demonstrate to the customers the tasks that could be accomplished with an information
system. A precise statement of the problem is required from the customer and it is the duty of
the system analyst to obtain these statements and agree it with the customer before the main
part of the project should begin.
Types of Requirement
Requirements may be classed into two categories, functional and non-functional.
Functional

what the system will do i.e. system inputs, outputs and how these are linked
Non-functional (2 types):

System - usability, performance, reliability, security, etc.

External - methods of operation, quality control standards, physical constraints,

etc.
Requirements Capture
This involves four elements
1
2
3
4

Requirements elicitation - discussion, with emphasis on listening

Requirements analysis - thinking through the information, retaining important
Requirements specification - writing the requirements down clearly
Requirements validation - checking that a true representation has been achieved

Requirements Elicitation
Techniques used here include:
Discussion and/or interviewing
Observation
Reading
Surveying (questionnaire)
Interviewing
Observation and reading are useful in requirements capture, However, discussion is the most
effective technique. This usually takes form of an interview between the systems analyst and
customer/user. Careful preparation by the analyst is important, if all the requirements are to
be extracted and understood. Inadequate preparation for the interview will lead to the analyst
missing key points.

Preparation for Interview

Both the analyst and interviewee should be clear about purpose of interview. The analyst
should know the relevant details about the interviewee, such as their:
background
position in organization
length of time with company
special expertise

The analyst must put the interviewee at ease early in the interview. It is not uncommon for an
interviewee to feel under stress, as they fear their job is going to be changed or abolished.
They may even feel that they are being investigated.
Types of Questions
There are various forms of questions that can be asked in an interview, which each get
different levels of response. The 3 main types are:

Long answer (almost open-ended)

Short answer (more directed)
Multiple choice (heavily directed)

Generally the long answer questions result in more information, and more rich information
being given. Short answer questions can be useful in the early part of the interview to start
people talking, but they tend to get only one or two word answers. They can feel limiting for
the interviewee, who may feel they are being told what to answer, not being asked for
information. Multiple choice answers can be useful in validation, and when selecting between
options. When using these latter two forms, allow opportunity, in general, for longer and more
complete answers. An interviewer must be an active listener. The face-to-face setting gives
opportunity for direct feedback from the interviewee, verbally or by facial expression or other
body language. Make use of it.
These sorts of questions are used in questionnaires as well as interviews. The precision and
clarity of questions are primary concerns, particularly in questionnaires. There should be no
confusion about the meaning of the question or the interpretation of the response. Do not
assume a common understanding of terminology or language; ambiguity and uncertainty will
result. Be clear about the information required. If you are offering multiple choices of answer,
do you want all that apply, or only the most significant one. Watch out for conflated questions,
which should have been asked separately, and do not assume everyone is doing things the
same way. Beware of your preconceptions. When asking questions, especially in
questionnaires, do not use computer jargon, as the other person may well not understand it.
Types of Information

Structured information in lists or forms

Information about company procedures
Measurements such as number of orders
Problems with the current system
Definite Requirements for new system
Implicit information, not directly stated

Requirements Analysis
Ensure requirements specify what rather than how
- keep as many options open as possible
- allow development of original or innovative solutions
Review for clarity
- perhaps by generating some supporting diagrams
Review for completeness
- any significant omissions?
Resolve any conflicts between requirements
System Goals and Conflicts

Example Conflict
'The data should be stored on floppy disk and enquiry response times should be
less than one second.'
If the amount of data is significant, these 2 requirements will conflict with each other; both
cannot be met. Conflicting requirements should be resolved as early as possible in System
Life Cycle.
Requirements Specification
The requirements specification can use:
narrative text
diagrams
both
Diagrams usually make it easier to see the interconnections, providing they are not too
complex. A narrative text will allow more precision, but may be difficult to follow. Using both
enables each to help clarify the other.
Specification Text
The specification text can use natural language such as the language we might use in
conversation or a formal specification language, using precisely defined syntax and semantics
(usually based on mathematics). A formal language is only useful for trained systems analysis
and development staff.

Specification Content
In addition to general attributes discussed earlier, for each requirement include:
a full description of it
the source of the requirement
who will be affected by it
the priority (how important it is)
the benefits that arise from fulfilling it
a list of related requirements
alternatives to it (if any)
whether the requirement results from a change to a previous one
Requirements Validation
The central issues are:
Validity
is it really these functions that are required?
are additional functions or alternative functions required?
Consistency
no conflicts
Completeness
Realism
Other aspects are:
Verifiability
are the requirements realistically testable?
Comprehensibility
Traceability
who specified the requirement?
Adaptability
can they be changed without major impact on other parts of system?
Verification should be a continuous process run in parallel with the others, not after the
requirements specification has been written.
Techniques for validation include:
constant feedback from the analyst during interviews
taking notes during interviews and producing a summary for the interviewee
comparing information from different sources e.g. interview results and questionnaire
results
prototyping
animation of a formal specification
Additional Difficulty
'Requirements evolution' is a further problem at this stage. Discussions will often increase
customers' understanding of problems, and prompt them to change their:
view(s)
method(s)
requirement(s)
In fact, users will not necessarily present a uniform view (eg staff/managers), and the analyst
will need to try to unify and reconcile these points of view. Failure to do this can result in, for
example, a system where managers want a report based on data for which other users see
no benefit, and which may therefore not be entered, or be entered incorrectly.

Example of Evolution
In developing a scheduling system for a Press Shop with:

30 presses,

processing 300 components

most jobs were stated to be single operation,

It thus appeared that preferred machines could be identified by PRODUCT. However, it later
became clear that the multiple operation jobs were important. These might have preferred
machines for 1 or more operations, and it emerged that what was needed was to identify
preferred machines by OPERATION.
Summary
Problem Definition is the important first stage in the System Life Cycle, producing an initial
description to be agreed with customer before proceeding. It involves Requirements Capture
through elicitation, analysis, specification and validation.
Requirements Capture involves difficulties in:

focusing purely on WHAT, not HOW

achieving CLARITY
including SUFFICIENT detail
ensuring COMPLETENESS
EVOLUTION of requirements