CSIS3600 System Analysis and Design

Lecture 7Determining System

Requirements

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.

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, 1999).

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 DesignCopyright 2001 © John Wiley & Sons, Inc. All rights reserved.

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.

CharacteristicsThe 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

Questions to AskMuch 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.

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.

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

SamplingOnce 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").

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.

Current System/Similar SystemsThe 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

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.

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.

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…

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…

Analyzing Documents continued

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

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

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.9690% 1.64580% 1.281

Acceptable error – 100% - acceptable % of certainty (100-90) = 10% or .10

Additional FormulaUsing .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

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.

Collecting Information from PeopleThe 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

InterviewingInterviewing 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

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?

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

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

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

Interview Questions continuedProbe 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.

Surveys/QuestionnairesQuestionnaires facilitate information gathering from many peopleGuidelines 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.

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

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

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

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

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.

Direct Observation continued Decide when to observe Time and event sampling

Time sampling occurs at specific intervals

Event sampling includes observing an entire event

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

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.

Selecting the Appropriate Techniques

Interviews JAD Questionnaires Document Observation Analysis

Type of As-Is As-Is As-Is As-Is As-IsInformation Improve. Improve. Improve. To-Be To-Be

Depth of High High Medium Low LowInformation

Breadth of Low Medium High High LowInformation

Integration Low High Low Low Lowof Info.

User Medium High Low Low LowInvolvement

Cost Medium Low- Low Low Low- Medium Medium

PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and DesignCopyright 2001 © John Wiley & Sons, Inc. All rights reserved.

New Approaches New approaches to fact finding

include JAD, GSS, and prototyping.

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

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

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.

JAD continued

PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and DesignCopyright 2001 © John Wiley & Sons, Inc. All rights reserved.

JAD Meeting Room

JPEG Figure 5-5 Goes Here

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.

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.

Prototyping GuidelinesThe 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.

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

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

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.

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.

Example of Requirements SpecificationExample 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.

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.

Additional Examples continued Functional Requirements Document for Uniform Resource

Names from Xerox Corporation: http://www.cis.ohio-state.edu/htbin/rfc/rfc1737.html

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 : http://www.newengland-partners.com/Files/RFP%20Flies/Attachments%20A%20-%20F%20&%20I.pdf 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: http://www.ukoln.ac.uk/metadata/pride/wp2/d221/

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.

Requirements ValidationIt 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?

Next Week Another Way to Specify User

Requirements USE CASE ANALYSIS

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