This document provides an outline and overview of requirements elicitation and specifications for a system analysis and design course. It discusses key topics like the importance of requirements, types of requirements including functional and non-functional, techniques for eliciting requirements like interviews and questionnaires, prioritizing requirements, validating requirements, and managing requirements. The document is intended to educate students on properly defining what a system must do through detailed requirements.

1. CS 0124:
System Analysis and
Design
By
Mr. Bernard Julius
Bsc (Hons). Computer Science UDSM
Msc. Information Technology Development and Management
(NM-AIST)

2. REQUIREMENTS ELICITATION AND
SPECIFICATIONS
OUTLINE
 Introduction to Requirements
 Importance of Requirements
 Types of Requirements
 Requirements Elicitation/Gathering
Techniques
 Prioritization of Requirements
 Requirements Validation
 Requirements Management

3. Introduction to Requirements
 Requirements determination is performed to
transform the system request’s high level statement
of business requirements into a more detailed,
precise list of what the new system must do to
provide the needed value to the business.
 This detailed list of requirements is supported,
confirmed, and clarified by the other activities of the
analysis phase: creating use cases, building process
models, and building a data model.
 We first explain what a requirement is and discuss
the process of creating a requirements definition
statement.

4. What is a Requirement?
 A requirement is simply a statement of what the system
must do or what characteristics it needs to have or
descriptions of the services that a system must provide
and the constraints under which it must operate .
 It may range from a high-level abstract statement of a
service or of a system constraint to a detailed
mathematical functional specification
 During a systems development project, requirements will
be created that describe what the business needs
(business requirements); what the users need to do (user
requirements); what the software should do ( functional
requirements); characteristics the system should have
(nonfunctional requirements); and how the system
should be built (system requirements).

5. Importance of Requirements
 To provide system developers with a better
understanding of the system requirements.
 To define the boundaries of (delimit) the system.
 To provide a basis for planning the technical contents
of iterations.
 To provide a basis for estimating cost and time to
develop the system.
 To define a user-interface for the system, focusing on
the needs and goals of the users.

6. Types of Requirements
 User requirements
o Statements in natural language plus
diagrams of the services that the
systems provides and its operational
constraints.
o Written for customers

7. Types of Requirements
System Requirements
o A structured document setting out
detailed descriptions of the system
services.
o Written for developers
o They may be functional or non-functional
requirements

8. Functional and Non-functional
Requirements
 Functional Requirements
o Describe functionality or system
services.
o Depend on the type of software,
expected users and the type of system
where the software is used.
o Functional system requirements should
describe the system services in detail.

9. Functional and Non-functional
Requirements
 Non-Functional Requirements
o Requirements which specify that the
delivered product must behave in a
particular way, e.g. execution speed,
reliability, availability, usability, security
etc.

10. Requirements Elicitation/Gathering
Techniques
 Interviews
 Questionnaires
 Observation
 Document Analysis
 Joint Application Development
 Prototyping

11. Interviews
 The interview is the most commonly used requirements
elicitation technique. After all, it is natural—usually, if
you need to know something, you ask someone.
 In general, interviews are conducted one on one (one
interviewer and one interviewee), but sometimes, due to
time constraints, several people are interviewed at the
same time.
 There are five basic steps to the interview process:
selecting interviewees, designing interview questions,
preparing for the interview, conducting the interview, and
post interview follow-up.

12. Interviews
 An interview schedule should be created, listing who will
be interviewed, the purpose of the interview, and where
and when it will take place.
 The people who appear on the interview schedule are
selected on the basis of the analyst’s information needs.
 There are three types of interview questions: closed-
ended questions, open-ended questions, and probing
questions.

13. Interview
 Closed ended questions require a specific answer. You
can think of them as being similar to multiple choice or
arithmetic questions on an exam. Closed ended
questions require a specific answer. You can think of
them as being similar to multiple choice or arithmetic
questions on an exam.
 Open-ended questions are those that leave room for
elaboration on the part of the interviewee. They are
similar in many ways to essay questions that you might
find on an exam. Open-ended questions are designed to
gather rich information and give the interviewee more
control over the information that is revealed during the
interview
 Probing questions encourage the interviewee to expand
on or to confirm information from a previous response,
and they are a signal that the interviewer is listening and
interested in the topic under discussion.

14. Questionnaires
 A questionnaire is a set of written questions for
obtaining information from individuals.
 Questionnaires often are used when there is a large
number of people from whom information and opinions
are needed. In our experience, questionnaires are
commonly used for systems intended for use outside of
the organization (e.g., by customers or vendors) or for
systems with business users spread across many
geographic locations.
 Most people automatically think of paper when they think
of questionnaires, but today more questionnaires are
being distributed in electronic form, either via e-mail or
on the Web. Electronic distribution can save a significant
amount of money, compared with distributing paper
questionnaires.

15. Questionnaires
 As with interviews and JAD sessions, the first step is to
select the individuals to whom the questionnaire will be
sent.
 However, it is not usual to select every person who could
provide useful information. The standard approach is to
select a sample, or subset, of people who are
representative of the entire group.
 Developing good questions is critical for questionnaires
because the information on a questionnaire cannot be
immediately clarified for a confused respondent.
 Systems analysts have additional techniques to improve
responses rates inside the organization, such as
personally handing out the questionnaire and personally
contacting those who have not returned them after a
week or two, as well as requesting the respondents’
supervisors to administer the questionnaires in a group
meeting.

16. Questionnaires
 Good questionnaire Design
o Begin with nonthreatening and interesting
questions.
o Group items into logically coherent sections.
o Do not put important items at the very end of
the questionnaire.
o Do not crowd a page with too many items.
o Avoid abbreviations.
o Avoid biased or suggestive items or terms.
o Number questions to avoid confusion.
o Pretest the questionnaire to identify confusing
questions.
o Provide anonymity to respondents.

17. Observation
 Observation is the act of watching processes being
performed, is a powerful tool to gain insight into the as-is
system. Observation enables the analyst to see the
reality of a situation, rather than listening to others
describe it in interviews or JAD sessions.
 Observation is a good way to check the validity of
information gathered from other sources such as
interviews and questionnaires.
 Observation is often used to supplement interview
information
 For example, an analyst might become skeptical of
someone who claims to use the existing computer
system extensively if the computer is never turned on
while the analyst visits

18. Document Analysis
 Project teams often use document analysis to
understand the as-is system
 These documents (forms, reports, policy
manuals, organization charts) only tell part of
the story. They represent the formal system
that the organization uses.
 Thus, it is useful to review both blank and
completed forms to identify the requirements

19. Requirements Prioritization
 There are usually more requirements than you can
implement given stakeholder`s time and resource
constraints,
Lot`s of
requirements
Few
resources

20. Requirements Prioritization
... on the other hand, systems have
useless functions for the users and
customers!
Large amount of the software
functions are ”rarely” (19%) or
”never used” (45%) [Moi00]

21. Requirements Validations
 Certifies that the requirements document is an
acceptable description of the system to be
implemented
 Checks a requirements document for
Completeness and consistency
Conformance to standards
Requirements conflicts
Technical errors
Ambiguous requirements

22. Requirements Management
It is often the case that more than
50% of a system’s requirements will
be modified before it is put into
service [Kot98].
New requirements emerge and
existing change due to
o errors
o increased understanding
o change in external circumstances.

23. Requirements Management
Changes to the requirements should be
documented and controlled formally.
Change management process ensures
that
o changes are made systematically
o similar information is collected for each
proposed change
o overall analysis is made about the costs,
benefits and timing
o the requirements document is updated.

24. Requirements Management

25. The End