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
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
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
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
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
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