This document provides an overview of the requirements analysis process. It explains that requirements come from both business and technical perspectives and describe what the system must do and how it will be implemented. Various techniques for gathering requirements are discussed, including interviews, documentation analysis, questionnaires, observation, and prototyping. The importance of user involvement and properly documenting requirements is also covered.

1. .
1
System Analysis and Design
Week 2 : Requirements Analysis

2. • Explain Requirement Analysis Process
• Prepare List of Requirements
2
Learning Objectives

3. • A requirement is a statement of what the system
must do or what characteristic it must have.
• Requirements in analysis part are written from
business person perspective ( business
requirements/ user requirements) and focus on what
of the system.
• Requirements in design part are written from
developer’s perspective (system requirements) and
describe how the system will be implemented.
3
What is a requirement?

4. • Need to understand how the organization operates at present
• Define the problems with the current system
• Define the requirements users have of a new system that are not in
the current system
4
User requirements

5. • Sections of the current system no longer meet the
needs of the organization.
• Some aspects of the organization’s work are not
covered by the current system.
• The system can no longer evolve but needs to be
replaced.
• It is important to understand current system to carry
functionality forward into new system.
• It is also important to understand it so that
shortcomings and defects can be corrected in the new
system.
5
Current System VS New System

6. • Functionality is required in new system
• Data must be migrated into new system
• Technical documentation provides details of
processing algorithms
• Defects of existing system must be avoided
• Parts of existing system may have to be kept
• We need to understand the work of the users
• Baseline information about the existing system helps
set targets for the new one
6
Reasons for investigating new system

7. • Organizations operate in a rapidly changing business
environment
• Organizations operate in a changing technical
environment
• Organizations merge, demerge, take over and get
taken over
• All these drives the needs to replace systems and
build new ones
7
Reasons for finding new requirements

8. • Functional
• Non-functional
• Usability
8
Types of Requirements

9. • A process the system has to perform and describe what the
system must do.
• Include:
• processes
• interfaces with users and other systems
• Data or information
• Example:
• The student registration system must have ability to search
selected student based on metric number.
• To report actual and budgeted expenses.
9
Functional requirements

10. • Refer to behavioral properties that the system must have.
• Concerned with how well the system performs such as usability and
performance.
• Include:
• Operational – the physical and technical environment in which the
system will operate.
• Performance - response times, capacity (volumes of data) and
reliability of the system
• security considerations
• Cultural and political – cultural, political factors and legal requirements
that affect the system
• Example:
• Any interaction between the user and the system should not exceed 2
seconds.
• Be accessible to Web user
• Only direct manager can see personnel records of staff.
• The system shall comply with insurance industry standards
10
Non-functional requirements

11. Traditional Methods
• Background Reading
• Interviewing
• Observation
• Document Analysis
• Questionnaires
Modern Methods
• Joint Application Design (JAD)
• Prototyping
11
Requirements Gathering Techniques

12. • To understand the organization and its business objectives
• Includes:
• reports
• organization charts
• policy manuals
• job descriptions
• documentation of existing systems
12
Background reading

13. • Advantages:
• helps to understand the organization before meeting the
people who work there
• helps to prepare for other types of fact finding
• documentation of existing system may help to identify
requirements for functionality of new system
13
Background reading

14. • Disadvantages:
• written documents may be out of date or not match the
way the organization really operates
• Appropriate situations:
• analyst is not familiar with organization
• initial stages of fact finding (Eg: objectives of
organization)
14
Background reading

15. • Most widely use.
• To get an in-depth understanding of the
organization’s objectives, users’ requirements and
people’s roles
• Requires most skill and sensitivity.
• Includes:
• managers to understand objectives
• staff to understand roles and information needs
• customers and the public as potential users
15
Interviewing

16. • Two forms:
• Open-ended
– conversational, questions with no specific answers in mind.
• Closed-ended – structured, questions with limited range of possible answers
16
Interviewing

17. • Advantages:
• personal contact allows the interviewer to respond
adaptively to what is said
• it is possible to probe in greater depth
• if the interviewee has little or nothing to say, the
interview can be terminated
17
Interviewing

18. • Disadvantages:
• can be time-consuming and costly
• notes must be written up or tapes transcribed after the
interview
• can be subject to bias if the interviewer has a closed
mind about the problem
• if interviewees provide conflicting information (different
interviewees) this can be difficult to resolve later
18
Interviewing

19. 19
Interviewing
How to conduct Interview

20. 20
Interview Guide
is a document
for developing,
planning, and
conducting an
interview.

21. 21
Each question
in an interview
guide can
include both
verbal and
non-verbal
information.

22. • Appropriate situations:
• most projects
• Provide information in depth about the existing system
and about people’s requirements from a new system
22
Interviewing

23. • Review of existing business document (to understand current
system)
• Can give a historical and formal view of system requirements.
• Includes:
• Paper reports
• Memorandums
• Policy manuals
• Use training manuals
• Form
• Screen shots of existing computer system
23
Document Analysis

24. • Advantages:
• for gathering quantitative data
• for finding out about error rates
• Disadvantages:
• not helpful if the system is going to change dramatically
• probing is possible only if original author is available
• Appropriate situations:
• always used to understand information needs
• where large volumes of data are processed
• where error rates are high
• where provide statistical data about volumes of transaction and
pattern of activity.
24
Document Sampling

25. 25
Business form
is a document
that contains
useful
information
regarding data
organizations
and possible
screen layouts.

26. • A set of written questions obtaining the views of a
large number of people in a way that can be
analysed statistically
• Includes:
• web-based and e-mail questionnaires
• open-ended and closed questions
• gathering opinion as well as facts
26
Questionnaires

27. • Advantages:
• economical way of gathering information from a large
number of people
• effective way of gathering information from people who
are geographically dispersed
• a well designed questionnaire can be analysed easily
• Short time
• Less bias in interpreting the results.
27
Questionnaires

28. • Disadvantages:
• good questionnaires are difficult to design
• no automatic way of following up or probing more
deeply
28
Questionnaires

29. • Appropriate situations:
• when views of large numbers of people need to be
obtained
• when staff of organization are geographically dispersed
• for systems that will be used by the general public and a
profile of the users is required
29
Questionnaires

30. • The act of watching processes being performed.
• It enables the analyst to see the reality of a
situation, rather than listening to others describe it
in interviews or JAD sessions.
• To check the validity of information gathered from
indirect sources such as interviews and
questionnaires.
30
Observation

31. • Includes:
• seeing how people carry out processes
• seeing what happens to documents
• obtaining quantitative data as baseline for improvements
provided by new system
• following a process through end-to-end
• Can be open-ended (get out to observe what happen
and note it down) or close-ended (draws up an
observation schedule/form to record data)
31
Observation

32. • Advantages:
• first-hand experience of how the system operates
• high level of validity of the data can be achieved
• verifies information from other sources
• allows the collection of baseline data (data about
performance of the existing system and users)
32
Observation

33. • Disadvantages:
• people don’t like being observed and may behave
differently, distorting the findings
• requires training and skill
• logistical problems for the analyst with staff who work
shifts or travel long distances
• ethical problems with personal/private/sensitive data
33
Observation

34. • Appropriate situations:
• when quantitative data is required
• to verify information from other sources
• when conflicting information from other sources needs to be resolved
• when a process needs to be understood from start to finish
34
Observation

35. • JAD is a technique for gathering business software
requirements. The purpose is to bring together the
technical/creative team and the business
community in a structured workshop setting to
extract consensus based software requirements.
• The client involves throughout the development
process in order to get the requirement satisfaction.
• Team members meet in isolation for an extended
period of time
• Highly focused
35
Joint Application Development (JAD)

36. • Session leader coordinator
• Users information source
• Managers information source
• Sponsor champion
• Systems analysts listeners
• Scribe recorder
• IS staff listeners
(programmer, DB analyst, IS planner, data center
personal)
36
Joint Application Development (JAD)
Team Members

37. 37
JAD session held in special-purpose room where participant sit around
horseshoe-shape table

38. • A repetitive process in which analysts and users build a rudimentary
version of an information system based on user feedback
• Still have to interview user and collect documentation.
• Repeated cycle: build, use, evaluate
38
Prototyping

39. 39

40. • Prototyping is good when:
• Users are unclear about their requirements (especially for
new system or system that support decision making).
• The system affects a relatively small number of users.
• Designs are complex.
• Communication between users and analysts needs to be
strengthened.
• Rapid application development tools (form/report
generator) are available to build system rapidly.
40
Prototyping

41. • A variety of stakeholders (all people who stand to gain from
implementation of the new system):
• senior management—with overall responsibility for the organization
• financial managers—who control budgets
• managers of user departments
• representatives of users of the system
41
User Involvement

42. • Different roles of users:
• subjects of interviews to establish requirements
• representatives on project committees
• evaluators of prototypes
• testers
• as trainees on courses
• end-users of new system
42
User Involvement

43. • Documentation should follow organizational standards
• CASE tools that produce UML models maintain
associated data in a repository
• Some documents will need separate storage in a filing
system:
• interview notes
• copies of existing documents
• minutes of meetings
• details of requirements
43
Documenting Requirements

44. • Documents should be kept in a document
management system with version control
• Use use cases to document functional
requirements
• Maintain a separate requirements list for non-
functional requirements
• Review requirements to exclude those that are
not part of the current project
44
Documenting Requirements

45. • How to document the requirements?
• The requirements must be documented in List of
Requirements.
45
Documenting Requirements

46. 46
Requirements
List
Use Case Model
Candidate
Requirements
Elicit
requirements
Project Initiation
Document
Select
requirements
Develop
use cases
Requirements
Analyst
Glossary
Activities Involved in capturing
requirements

47. Group activities
• Imagine that you are interviewing one of the staff in The Agate . Draw
a list of 5 questions that you want to ask him or her.
• What is the purpose of producing use cases
• Identifies he functional and non functional requirements of Agate
system.
47

48. Conclusion
Q & A Session
48