1. CSIS3600 System Analysis and Design
Lecture 7
Determining System Requirements

2. The Beginning of Analysis
Analysis begins once permission has been granted to pursue the development of a new system.
Determining System Requirements begins the Analysis Phase of Systems Development.
Analysis includes:
Requirements Determination
Requirements Structuring
Alternative Generation and Selection
Analysis is creative work.

3. The Work of Determining System Requirements
System Requirements determination answers the question: What is the system to do?
This type of analysis primarily consists of fact-finding activities. Through this process, "the analyst learns about the vocabulary, problems, opportunities, constraints, requirements and priorities of a business and a system" (Whitten and Bentley, 1999).
The work of systems analysis is "to determine what information and information processing services are needed to support selected objectives and functions of the organization; consequently, analysis is fundamentally an intelligence activity in which analysts capture and structure information" (Hoffer, et al, ).

4. Key Ideas
The goal of the analysis phase is to truly understand the requirements of the new system and develop a system that addresses them.
The first challenge is finding the right people to participate.
The second challenge is collecting and integrating the information
PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design
Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.

5. Pre-Requisite Understanding
The business objectives that drive what and how work is performed.
Information people need to know to do the job.
Data required to support the job.
When, how and by whom or what data are moved, transformed and stored.
Sequence and other dependencies among data-handling activities.
Rules governing how data are handled and processed.
Policies and guidelines that describe the nature of the business and the market and the environment in which it operates.
Key events affecting data value and when these events occur.

6. Characteristics The characteristics of requirements determination:
Impertinence - question everything
Impartiaility - find the best solution
Relax constraints - all things are feasible
Attention to detail - every fact fits with every other fact
Reframing - look at the organization and the problem in new ways

7. Questions to Ask
Much analysis focuses on the way work is performed. Hoffer, et al (1999) lists questions that should be investigated:
How does the current system function? Is the system manual or automated?
What data are necessary for proper functioning of the supported business area?
What kinds of reports are generated?
How do people use the system to perform their work?
How should a new or replacement system function?
What data would be needed for it to operate smoothly?
How would a new system alter employees' jobs?
What new or improved information services are needed to support the future organizational goals, objectives, strategies, and functions?
If you don’t ask the right questions, you won’t get the right answers.

8. Collecting Information
In order to properly assess the appropriate requirements for the system, information should be gathered from as many sources as possible including system players (owners, users, etc.), observing users, from reports, forms, and other pertinent documentation and procedures used to carry out the work.
There are several techniques for collecting information. Analysts use a variety of these in any given project. Understanding their advantages and disadvantages as well as which one to use when is important for success in building information systems.

9. Traditional Approaches
Traditional approaches to fact finding:
Reviewing and evaluating the current system/similar systems including analyzing existing procedures
Interviewing
Questionnaires
Direct observation of the work environment and end users
Analyzing existing documentation, forms and databases
Analyzing existing procedures
Research

10. Sampling
Once you synthesize what I just said, you are probably thinking this isn't feasible. The amount of information that one could collect can be quite large and the time it takes to collect that information might be quite extensive. You run into another problem as well. Too much information is sometimes no more useful than too little information and too much analysis is not productive ("analysis paralysis").

11. Sampling continued
It is not practical to collect information from every system users and to purview every piece of relevant documentation.
Sampling is the process of systematically selecting representative elements of a population.
Sampling requires assessing who (or what) makes up the total population and then determining what would be an appropriate sample size for that population.
Using samples enhances the fact finding mission of systems analysts, making the process less time consuming and more productive.
Sampling can be employed for all types of fact finding techniques as outlined later on in these notes.

12. Current System/Similar Systems
The first place to look for information is with the current system - be it a computerized, automated or manual system.
Ways to evaluate the current/similar systems:
Model the system
Identify cause-effect relationships among system activities
Identify any business event or input to which the system responds
Identify special business policies ,processing or decisions that must be made to respond to the input
Identify normal business outputs or responses to aforementioned events or inputs
Identify any information that must be produced or made available

13. Note on Current System Evaluation
It was once popular to perform a detailed and thorough analysis of the current system – that is no longer advocated due to the dynamic changes in technology but it is still important to identify the data, information and business processes served by the current system.

14. Sampling and Current System/Similar System
A formal sampling process is not necessary. The processing of selecting similar systems to review includes researching what systems exist and choosing those that are in use in similar environments.

15. Analyzing Documents This can include most anything.
Documents that might describe the problem:
Interoffice memos, minutes of meetings, suggestion box notes, customer complaints, reports, accounting records, performance reviews, work measurement reviews…

16. Analyzing Documents continued
Documents that describe the business functions:
Mission statement, strategic plan, organizational and departmental objectives, policy manuals, standard operating procedures, job descriptions, task instructions, completed forms, manual and computerized databases, manual and computerized screens and reports…

17. Analyzing Documents continued
Documentation of previous system studies:
System diagrams, project repositories, design documents, data model, program documentation, user documentation, computer operations manuals

18. Sampling Documents Guidelines for sampling documents:
AVOID blank forms
Study enough samples to identify all conditions and exceptions
A simple Sample formula that has been cited to be reliable:
Sample size = 0.25 * (certainty factor/acceptable error)2
Certainty factor – statistical representation that sample will not include variations not in the sample (certainty values can be found in tables)
Acceptable error – user defined

19. Example of Sampling Formula
Suppose you want 90% certainty that a sample of invoices will contain no unsampled variations:
SS = 0.25(1.645/0.1) 2 = 68
Certainty factors (from table)
95% 1.96
90% 1.645
80% 1.281
Acceptable error – 100% - acceptable % of certainty (100-90) = 10% or .10

20. Additional Formula
Using .25 often results in a sample size larger than necessary. You can use an additional formula:
n = (p(1-p)/ss2) + 1
where p is an estimate of the proportion of the population containing a specified attribute
ss is the result of using the previous formula

21. Selecting the Sample Two methods for choosing the document sample:
Randomization – randomly selecting documents without any predetermined plan or pattern
Stratification – systematic sampling to reduce variance by spreading out the sample – for instance stratification by department, by customer type, etc.

22. Collecting Information from People
The input from many individuals (users, system owners, etc) can be beneficial. This can be facilitated by sampling. Sample types include the
convenience sample – those that are there and willing to be interviewed
purposive sample – selecting people who satisfy certain criteria
simple random sample - randomly picking people
stratified sample – identifying categories of people and then taking random samples from each category

23. Interviewing Interviewing is a primary way to gather information
Steps in Interviewing:
Plan the Interview
Read Background Material
Establish Interview Objectives
Decide Whom to Interview
Prepare the Interviewee
Decide on Question Types and Structure

24. Interviewing Steps continued
Conduct the Interview
Use audio recording or develop good note taking skills
Shake the interviewee’s hand
Begin with general, non-threatening questions
Let your interviewee know what kind of detail you are expecting
Don’t go beyond an hour
Listen – reflect back or summarize what the interviewee said
End with – "Is there anything else we haven’t discussed you feel is important for me to know?

25. Interviewing Steps continued
Report on the Interview
Write it as soon as possible after the interview
Identify main points
Identify your opinions versus interviewee’s opinions
Review the report with the interviewee

26. Types of Interview Questions
Open ended ("What do you think about putting all managers on an intranet?")
Benefits:
Puts interviewee at ease
Provide for richness of detail
Allow more spontaneity
Allow interviewer to pick up on interviewee vocabulary
Pitfalls:
May result in too much irrelevant detail
Chance to lose control of the interviewee
Allow for responses that take too much time and glean too little information

27. Interview Questions continued
Closed Questions ("How many subordinates do you have?")
Benefits:
Limit responses (Y/N, How many, etc)
Saves time
Gets to the point quickly
Keeps control of the interview
Pitfalls:
Can be boring
Fails to obtain rich detail
Chance to miss main idea or underlying reasons
Fails to build rapport

28. Interview Questions continued
Probe Questions ("Will you elaborate on that for me?")
Asks why and often ask for examples
Goes beyond the initial answer to get more meaning, to clarify and to draw out and expand on interviewee’s point
Important to probe to get beyond superficial answers
May seem intrusive but if built on responses given by the interviewee is a result of listening. Listening is respected.

29. Surveys/Questionnaires
Questionnaires facilitate information gathering from many people Guidelines on whether to use questionnaires:
People who need to be questioned are widely dispersed.
Large number of people are involved in the project and it is meaningful to know what portion of the group approves or disapproves of a particular feature of the proposed system.
You are doing an exploratory study and want to gauge overall opinion to set a specific direction.
You wish to be certain that problems with current system are identified.

30. Steps in Using a Questionnaire
Identify objectives
Write the questions
Carefully choose wording
Make questions simple, short, specific, free of bias, technically accurate
Decide on type of questions and measurement techniques
Quantitative scales assign numbers to response values (strongly agree = 5, etc.)
Open ended questions require qualitative analysis where responses are reviewed for patterns

31. Using a Questionnaire continued
Test questions on a small sample of respondents.
Make edits based on their recommendations.
Develop a plan for administering questionnaire
Convene all people together at one time
Personally hand out blank questionnaires and received completed ones
Mail questionnaire
Provide access to it electronically
Evaluate and interpret responses

32. Types of Questionnaire Questions
Free-format – open ended questions
Fixed Format – require specific responses
Multiple choice
Rating questions
On a scale of 1-5 (5 being the highest) rate the following
Ranking questions
Put the following in order of importance

33. Direct Observation Steps to Observation Decide what is to be observed
Work tasks
Physical space
Environmental dynamics (body language, etc).
Decide at what level or concreteness activities are to be observed
Create categories that adequately capture key activities
Brainstorm and prepare lists of activities that might be observed

34. Direct Observation continued
Prepare appropriate materials for observation
Adjective pairs
Listing of adjectives and opposites
During the observation the characteristic observed is circled
Playscript
Prepared listing of activities expected to be observed
Each time the activity occurs, it is marked
Checklist
Prepared checklist of expected observations using a scale (1-5). When activity occurs, a value is selected.
Anecdotal list
Short phrases on ongoing activities is documented.

35. Direct Observation continued
Decide when to observe
Time and event sampling
Time sampling occurs at specific intervals
Event sampling includes observing an entire event

36. Things to remember about people and their work
People don't always have a completely accurate appreciation of what they do or how they do it
People cannot always interpret their own actions
People may change their behavior when observed
Direct observation can be used to validate information obtained using other methods

37. Summing up Traditional Methods
Individually interview people informed about the operation and issues of the current system and needs for systems in future organizational activities
Survey people via questionnaires to discover issues and requirements
Interview groups of people with diverse needs to find synergies and constrasts among system requirements
Observe workers at selected times to see how data are handled and what information people need to do their jobs
Study Business documents to discover reported issues, policies, rules and directions as well as concrete examples of the use of data and information in the organization.

38. Selecting the Appropriate Techniques
Interviews JAD Questionnaires Document Observation
Analysis
Type of As-Is As-Is As-Is As-Is As-Is
Information Improve Improve. Improve.
To-Be To-Be
Depth of High High Medium Low Low
Information
Breadth of Low Medium High High Low
Integration Low High Low Low Low
of Info.
User Medium High Low Low Low
Involvement
Cost Medium Low Low Low Low-
Medium Medium
PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design
Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.

39. New Approaches
New approaches to fact finding include JAD, GSS, and prototyping.

40. JAD
The buzz these days is JAD or Joint Application Development (or Design if you prefer).
IBM is credited with starting JAD in the late 1970s.
The main idea behind JAD is to bring together key users, system owners, systems analysts and IS staff to assess desired system requirements.
The primary purpose of JAD is to collect systems requirements simultaneously from the key people involved with the system

41. JAD continued JAD sessions are structured.
JAD sessions follow an agenda and the intent is to keep the sessions focused and moving forward.
Much planning goes into these sessions and the questions to be asked are prepared well in advance.
Facilitator is assigned to monitor the session:
Keep session on track
Help with technical terms and jargon
Record group input
Help resolve issues

42. JAD continued
JAD is a formal process. JAD sessions occur in a short period of time - anywhere between 1 day and 2 weeks (all meeting times are consecutive). It is recommended that JAD sessions be held off- site to elicit the full concentration of all participants.
The main disadvantage attributed to JAD centers around the fact that JAD sessions include so many players who have diverse perspectives. Therefore JAD leaders are often trained in conflict resolution.

43. JAD Meeting Room JPEG Figure 5-5 Goes Here
PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design
Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.

44. GSS GSS are systems designed to support group work.
Such applications as Lotus Notes and Microsoft NetMeeting are often considered groupware.
These applications provide services to that facilitate group meetings and group sharing of information.
Actually, it has been suggested that GSS be considered as mechanism to facilitate JAD.
GSSs were designed to alleviate some of the problems associated with group meetings. For instance, most GSSs support the entry of anonymous comments. Anonymity helps those who fear reprisal from voicing their opinion.

45. Prototyping
Prototyping is another hot topic in the area of systems development and simple prototypes can be used effectively to determine system requirements.
Prototyping is the building of a small-scale working model of an information system.
Prototyping, as used in system requirement determination, is an iterative process whereby the working model is presented to end users for input, changes are made based on their input, and the cycle continues until a final version is agreed upon. The main consideration is that you must have a model of a working system so you would have to, at least, go through some initial fact finding activities.

46. Prototyping Guidelines
The chances are good that by using prototyping in an iterative fashion, you will end up with a system more reflective of user requirements.
A couple of words of caution.
First, you must remember that the goal of using prototyping in the determination o f system requirements is to develop specifications for the final system, not to build the ultimate system.
At this stage of the analysis process, you should be more focused on deciding what the system will do, not so much on how it will do it.

47. Prototyping Guidelines continued
The use of prototyping at the requirements stage appears to be most effective when the desired outcomes of the system are not easy to define.
Prototyping may be better used during the design phase of the development process and used to validate articulated system requirements

48. Defining the Requirements – The Structured Way
Once fact finding is completed, system requirements need to be formalized.
Requirements are cited in a report known as the requirements document. The complete requirements document would include specification and definition of requirements and models of the system (these will we investigate in the next lectures). Some organizations subdivide the document including a section just for "Functional Requirements."

49. Defining Requirements continued
Another method is to develop a requirements definition and a requirements specification. The requirements definition describes system functions in natural language with associated listings or diagrams of required services. The intended audience is system users.
The requirements specification outlines system services and is usually written as a contract between the developer and the user. This can be very detailed but when completed really assist system designers in completing their work.

50. Examples from a Requirements Document
Example of a Requirements Definition:
1. The software must provide a means of representing and accessing external files created by other tools.

51. Example of Requirements Specification
Example of a Requirements Specification:
1.1 The user should be provided with facilities to define the type of external files.
1.2 Each external file type may have an associated tool which may be applied to the file.
1.3 Each external file type may be represented as a specific icon on the user's display.
1.4 Facilities should be provided for the icon representing an external file type to be defined by the user.
1.5 When a user selects an icon representing an external file, the effect of that selection is to apply the tool associated with the type of the external file to the file represented by the selected icon.

52. Additional Examples
Below are links to some examples of Functional Requirements Documents that should give you a broader view on how different organizations approach this process:
The link, Functional Requirements Example, points you to a completed Functional Requirements document from an actual systems development project. Even though you do not have contextual knowledge about the project, the document serves as an example of how one company completes this process. The format of the document is specified in the systems methodology employed by this software development company. Note that the document includes: an Introduction, Objectives of the System, Assumptions, Description of Functions and Limitations of the System.

53. Additional Examples continued
Functional Requirements Document for Uniform Resource Names from Xerox Corporation:
Functional Requirements document for the PARTNERS Project, a multi-state initiative to develop and implement a smartcard-based delivery system to meet the client services needs of a variety of public health and human service programs : beginning on page 15
Functional Requirements for the People & Resources Identification for Distributed Environments (PRIDE) project to enable access via a single point to a global range of information resources within the library:

54. Evolving Requirements
The specification of system requirements is the primary activity of the analysis phase of systems development.
It results in a description of what the proposed system is to accomplish.
It provides the input used in the design of the physical system.
The initial development of system requirements is not an ending point.
Requirements must be validated and reviewed.
Requirements always evolve as a better understanding of user needs is developed and as the organization's objectives change.

55. Requirements Validation
It is essential to plan for change in the requirements as the system is being developed (and used). Validation checks of system requirements throughout the process include asking the following questions:
Does the system provide the functions which best support the customer's needs?
Are there any requirements conflicts?
Are all functions required by the customer included?
Can the requirements be implemented given available budget and technology?

56. Next Week
Another Way to Specify User Requirements USE CASE ANALYSIS

57. Quotes of the Week
Systems designers and end users will always live on different planets. This is one of those immutable laws of nature.
By the time any one individual has the knowledge and skills to write a complex software system, he/she - or the organization - will no longer be capable of understanding how little end users really know, or want to know, about the underlying technology .
Gantz, "The More Things Change in IT..." in Computerworld, 33(51), December 20, 1999, pg. 32).