1. 1
CCHHAAPPTTEERR 88
RReeqquuiirreemmeennttss CCaappttuurree
Software System
Engineering (260CT)
2. In This Lecture You Will Learn:
ďŹThe distinction between the current and
required systems
ďŹWhen and how to apply the main fact
finding techniques
ďŹThe roles played by users
ďŹThe need to document requirements
2
3. 3
User Requirements
ďŹNeed to understand how the
organization operates at present
ďŹWhat are the problems with the current
system?
ďŹWhat are the requirements users have of
a new system that are not in the current
system?
4. Current System
ďŹMuch of the current system meets the
needs of people who use it
ďŹSections of the 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
4
5. 5
Current System
ďŹ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
6. 6
Current System
ďŹYourdon (1989) argues against spending
a lot of time analysing the existing
systemâitâs being replaced!
ďŹSSADM makes the case for modelling
the current systemâmuch of its
functionality will be required in the new
system
7. 7
Reasons for Investigating
the Current System
ďŹ 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
8. New Requirements
ďŹ Organizations operate in a rapidly changing
business environment
ďŹ Organizations operate in a changing technical
environment
ďŹ Governments and supra-governmental
organizations introduce legislation
ďŹ Organizations merge, demerge, take over and
get taken over
ďŹ All this drives the need to replace systems and
build new ones
8
9. 9
Types of Requirements
ďŹFunctional
ďŹNon-functional
ďŹUsability
10. Functional Requirements
ďŹ Describe what a system must do
ďŹ Include:
⢠processes
⢠interfaces with users and other systems
⢠what the system must hold data about
ďŹ Modelled with Use Case Diagrams. Later will
be modelled with other kinds of diagrams that
show the structure of the system (Class
Diagrams) and its behaviour (Interaction
Diagrams and Statechart Diagrams)
10
11. Non-functional Requirements
ďŹ Concerned with how well the system performs
ďŹ Include:
⢠response times
⢠volumes of data
⢠security considerations
ďŹ Documented in Requirements List or in Use
Case Model (for requirements that can be
linked to specific use cases)
11
12. Usability Requirements
ďŹ Concerned with matching the system to the
way that people work
ďŹ Sets measurable objectives
ďŹ Include:
⢠characteristics of users
⢠tasks users undertake
⢠situational factors
⢠acceptance criteria for the working system
ďŹ Documented in Requirements List. May be
tested by Prototypes
12
14. Background Reading
ďŹAim is to understand the organization
and its business objectives
ďŹIncludes:
⢠reports
⢠organization charts
⢠policy manuals
⢠job descriptions
⢠documentation of existing systems
14
15. 15
Background Reading
ďŹ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
16. 16
Background Reading
ďŹ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
17. 17
Interviewing
ďŹAim is to get an in-depth understanding
of the organizationâs objectives, usersâ
requirements and peopleâs roles
ďŹIncludes:
⢠managers to understand objectives
⢠staff to understand roles and information
needs
⢠customers and the public as potential users
18. 18
Interviewing
ďŹAdvantages:
⢠personal contact allows the inetrviewer 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
19. 19
Interviewing
ďŹDisadvantages:
⢠can be time-consuming and costly
⢠notes must be written up or tapes transcribed
after the interview
⢠can be subject to bias
⢠if interviewees provide conflicting information
this can be difficult to resolve later
20. 20
Interviewing
ďŹAppropriate situations:
⢠most projects
⢠at the stage in fact finding when in-depth
information is required
ďŹRequires skill to carry out effectively
(See Box 6.1 for guidelines)
21. 21
Observation
ďŹ Aim is to see what really happens, not what
people say happens
ďŹ 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 or based on a schedule
22. 22
Observation
ďŹ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
23. 23
Observation
ďŹ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 data
24. 24
Observation
ďŹ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
25. 25
Document Sampling
ďŹ Aims to find out the information requirements
that people have in the current system
ďŹ Also aims to provide statistical data about
volumes of transactions and patterns of activity
ďŹ Includes:
⢠obtaining copies of empty and completed documents
⢠counting numbers of forms filled in and lines on the forms
⢠screenshots of existing computer systems
26. 26
Document Sampling
ďŹ Advantages:
⢠for gathering quantitative data
⢠for finding out about error rates
ďŹ Disadvantages:
⢠not helpful if the system is going to change
dramatically
ďŹ Appropriate situations:
⢠always used to understand information needs
⢠where large volumes of data are processed
⢠where error rates are high
27. 27
Questionnaires
ďŹAims to obtain the views of a large
number of people in a way that can be
analysed statistically
ďŹIncludes:
⢠postal, web-based and email questionnaires
⢠open-ended and closed questions
⢠gathering opinion as well as facts
29. 29
Questionnaires
ďŹ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 by computer
30. 30
Questionnaires
ďŹDisadvantages:
⢠good questionnaires are difficult to design
⢠no automatic way of following up or probing
more deeply
⢠postal questionnaires suffer from low
response rates
31. 31
Questionnaires
ďŹ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
33. 33
User Involvement
ďŹA variety of stakeholders:
⢠senior managementâwith overall
responsibility for the organization
⢠financial managersâwho control budgets
⢠managers of user departments
⢠representatives of users of the system
34. 34
User Involvement
ďŹDifferent roles:
⢠subjects of interviews
⢠representatives on project committees
⢠evaluators of prototypes
⢠testers
⢠as trainees on courses
⢠end-users of new system
35. Documenting Requirements
ďŹ 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
35
36. Documenting Requirements
ďŹDocuments should be kept in a
document management system with
version control
ďŹUse use cases to document functional
requirements
ďŹMaintain a separate requirements list
ďŹReview requirements to exclude those
that are not part of the current project
36
37. Requirements
37
List
Use Case Model
Candidate
Requirements
Requirements
Analyst
Elicit
requirements
Project Initiation
Document
Select
requirements
Develop
use cases
Glossary
38. Use Case Model
38
Requirements
Team
Requirements
capture and modelling
Project Initiation
Document
Requirements
List
Interface
Prototypes
Initial System
Architecture
Glossary
39. Summary
In this lecture you have learned about:
ďŹThe distinction between the current and
required systems
ďŹWhen and how to apply the main fact
finding techniques
ďŹThe roles played by users
ďŹThe need to document requirements
39