4-Analyzing+System+Requirements

=Analyzing System Requirements=

Valacich et al: Chapter 4
There are **three** parts to the systems analysis phase of the systems development life cycle:
 * __**Determining requirements**__
 * Structuring requirements
 * Selecting the best alternative design strategy

When determining requirements analysts must //gather information// on what the system should do from a __variety of sources using a variety of data-gathering techniques__. Examples of sources used can be the current system's users, reports, forms, and procedures. After compiling and carefully documenting the data gathered from these resources, the system requirements are then made ready for structuring--the second part of the systems analysis phase.

In order to have a successful and thorough requirements determination, a systems analyst must possess a certain set of characteristics:
//***Impertinence, impartiality, and insight make up what's known as the "3 I's"***//
 * **Impertinence**: Question EVERYTHING; be thorough in your questioning--take into account how different circumstances and methods may affect outcomes.
 * **Impartiality**: Do not try to assume or justify a system based on just your own perspective. You must always take into consideration the issues raised by all involved parties in your efforts to find the best organizational solution.
 * **Insight**: How do YOU feel about it. Although you shouldn't go on your judgment, alone, it is important to incorporate your own thoughts as to what the system requirements should be.
 * **Relaxing of constraints**: Assume all is possible and do not assume that anything is impossible. Make sure not to focus too much on maintaining traditional ways of doing things- be open to alternative methods.
 * **Attention to details**: Every piece, every process within the system must be accurate and accounted for.
 * **Reframing**: Challenge yourself to look at the organization from other viewpoints, do not confine yourself to only one perspective.

The **Analysis Phase** ought to be the longest phase. In this phase you must: //With these findings an analyst can determine requirements for the new and/or updated system.//
 * **Analyze** the current system.
 * **Identify** its strengths and areas of opportunity in growth and improvement of processes.

===Deliverables: the primary deliverables from requirements determination are the types of information gathered during the determination process. Anything that the team collects as part of determining system requirements is included in the deliverables.=== They include:
 * DFDs, ERDs
 * Information collected from conversations with users
 * Existing documents and files
 * Computer-based information

__**What makes a good** **system requirement:**__

 * **Testable & Verifiable:** allows for independent verification that the system meets and/or surpasses the stated requirements
 * **Justifiable:** can be justified not only from the perspective of the analyst
 * **Unambiguous:** concise and specific interpretation of the requirement
 * **Consistent:** remains uniform, not in conflict with other stated requirements
 * **Understandable & Modifiable:** open and available for change and adjustments
 * **Hierarchically Traceable:** traceable back to higher level requirement

End User involvement is directly related to system success. End users MUST be INVOLVED
-- a sense of ownership -- increased familiarity and reduced inhibition -- a reduction in resistance to change -- elimination of anxiety through fostering early communication
 * __An end user's needs must be in__ __balance with the client's constraints.__
 * **End user involvement provides users with**:

__**What to avoid**__ when determining system requirements:

 * **Assuming** a functional system
 * Collecting requirements from **each end user instead of ALL end users**[[image:file:moz-screenshot-1.jpg]]
 * Asking the **wrong questions**
 * **Failing to allow refinement** through trial and error
 * **NOT being open to creativity**

__**TRADITIONAL METHODS:**__ //(see chart below)//

 * Interviews with individuals : gain insight and different perspectives, opinions/facts, speculations
 * Questionnaires: larger reach, inexpensive, easier to analyze findings
 * Observations of workers: no pressure from interviewer, people are functioning in their own environment
 * Business documents: company values, sales analysis; anything you might not get from the first 3

**Interviews vs. Questionnaires**

 * -Interviews:**
 * Very effective form of communication
 * Expensive and time-consuming; therefore, limited questions and people contacted


 * -Questionnaires:**
 * Passive, not very direct;information gathered isn't that strong
 * Inexpensive, less time-consuming
 * Larger audience is reached
 * Less Bias

__**MODERN METHODS:**__ Aside from the traditional methods used by analysts, there are additional more //modern// techniques used to collect information about the current system, the organizational area requesting the new system, and what the new system should be like. These modern methods support effective information collection and structuring while reducing the amount of time required for analysis. >
 * __Joint Application Design (JAD):__** the bringing together of key users, managers, system analysts and others for the purpose of collecting their opinions, views and information in an effort to view agreement and/or conflict amongst those involved. These sessions result in a set of documents detailing the specs of the current system in addition to any potential features of its replacement/updated system
 * Begins with the idea of the group interview and adds structure and a JAD session leader
 * Typical participants include session leader, a b, key users, managers, a sponsor, system analysts and IS staff
 * Normally held off site and can last up to a week


 * __Prototyping:__** a process where analysts and users repetitively build a rudimentary of an information system based on the feedback collected from their users. The interviews conducted by the analysts determine the likes and dislikes the users have with their current system. Using these findings, a new system is created and then given to the users to test in exchange for their feedback of the updated system. This process is then repeated until they have finally settled on the best system.
 * You still have to interview users and collect documentation.
 * Allows you to quickly convert basic requirements into a working version of the desired information system
 * Users and analysts work closely together to determine requirements