Juan and Pedro Dialogue

The analysis phase defines the requirements of the system, independent of how these requirements will be accomplished. This phase defines the problem that the customer is trying to solve. The analysis phase provide a general idea of the shape of the new
system. The deliverable result at the end of this phase is a requirement document. Ideally, this document states in a clear and precise fashion what is to be built. This analysis represents the ``what'' phase. The requirement document tries to capture the requirements from the customer's perspective by defining goals and interactions at a level removed from the implementation details.


The flow of the conversation:

“Juan: The way to go about the analysis is to first examine the old system, such as reviewing key documents and observing the workers performs their tasks. Then we can determine which aspects are working well and which should be preserved.”

As Juan initialize the discussion, he said that to start the analysis for the new system, an assessment of the old or current system is needed so that he could figure out the flow and through this he could point out what part of the system is working efficiently and which is not. I think Juan wants to follow the standard in implementing this phase in which I find it proper.

“Pedro: We have been through these types of projects before and what always ends up happening is that we do not get the new system we are promised; we get a modified version of the old system.”

The manager, Pedro made an emphasis with his angst that the system Juan is planning will be just the same with their previous developed systems in which they find it unsatisfactory. I think this initial reaction must be expected from the client.

”Juan: Well, I can assure you that will not happen this time. We just want a thorough understanding of what is working well and what isn’t.”

I think Juan deserves credit for giving an assurance to the client that his fear will not knock him anymore. And it is a good strategy that Juan still insist his goal in a nice way in spite of the pressure he received from the manager.

“Pedro: I would feel much more comfortable if we first started with a list of our requirements. We should spend some time up-front determining exactly what we want the system to do for my department. Then you systems people can come in and determine what portions to salvage if you wish. Just don’t constrain us to the old system.”

In this response, I can say that the manager knows what he really wants to be done. The manager shows that he is really particular on changing the entire system they are currently using not just do some changes on it. It seems that the manager is constantly reminding Juan about this. As to the systems people, that’s very helpful for them because determination of requirements for that certain project will not be that hard anymore. And reminders will give Juan his standards.


I sympathize with the manager, because if I am the manager it is fair to set and demand what I want for the system that will be implemented soon in my company. However, I will also consider that the systems analyst is foreseeing to fill what I want. Being just particular is a big challenge for them. More than that, gathering the requirements with the cooperation of the manager will set as a catalyst to make the system analysis phase be efficient and effective, a good indication for a success.

But even if I sympathize to the manager, I think following the standard requirements analysis methods will be more suitable. Having consideration in terms of new recommended methods from clients will not be a hindrance to this phase instead gives new ideas to improve the basic methods and finally provides result that satisfies both parties.


Additional Brain Feeding…
System Analysis
In this phase, the current system is studied in detail. A person responsible for the analysis of the system is known as analyst. In system analysis, the analyst conducts the following activities.
Needs Analysis
This activity is known as requirements analysis. In this step the analyst sums up the requirements of the system from the user and the managers. The developed system should satisfy these requirements during testing phase.
Data Gathering
In this step, the system analyst collects data about the system to be developed. He uses different tools and methods, depending on situation. These are:
Written Documents
The analyst may collect the information/data from written documents available from manual-files of an organization. This method of data gathering is normally used if you want to computerize the existing manual system or upgrade the existing computer based system. The written documents may be reports, forms, memos, business plans, policy statements, organizational charts and many others. The written documents provide valuable information about the existing system.
Interviews
Interview is another data gathering technique. The analyst (or project team members) interviews, managers, users/ clients, suppliers, and competitors to collect the information about the system. It must be noted that the questions to be asked from them should be precise, relevant and to the point.
Questionnaires
Questionnaires are the feedback forms used to collect Information. The interview technique to collect information is time-consuming method, so Questionnaires
are designed to collect information from as many people as we like. It is very convenient and inexpensive method to collect information but sometimes the response may be Confusing or unclear and insufficient.
Observations
In addition to the above-mentioned three techniques to collect information, the analyst (or his team) may collect Information through observation. In this collect technique, the working, behavior, and other related information of the existing system are observed. It means that working of existing system is watched carefully.
Sampling
If there are large numbers of people or events involved in The system, we can use sampling method to collect information. In this method, only a part of the people or events involved are used to collect information. For example to test the quality of a fruit, we test a piece of the fruit.
Data Analysis
After completion of “Data Gathering” step the collected data about the system is analyzed to ensure that the data is accurate and complete. For this purpose, various tools may be used. The most popular and commonly used tools for data analysis are:
• DFDs (Data Flow Diagrams)
• System Flowcharts
• Connectivity Diagrams
• Grid Charts
• Decision Tables etc.

Analysis Report
After completing the work of analysis, the requirements collected for the system are documented in a presentable form. It means that the analysis report is prepared. It is done for review and approval of the project from the higher management. This report should have three parts.
• First, it should explain how the current system works.
• Second, it should explain the problems in the existing system.
• Finally, it should describe the requirements for the new system and make recommendations for future.




The analysis phase is the building block of a training program. The basis for who must be trained, what must be trained, when training will occur, and where the training will take place are accomplished in this phase. The product of this phase is the foundation for all subsequent development activities.
The analysis phase is often called a Front-End Analysis. That is, although you might perform analysis throughout the ISD process, such as in the design and development phases, this "front end" of the ISD process is where the main problem identification is performed.
When performing an analysis, it is best to take a long term approach to ensure that the performance improvement initiative ties in with the organization's vision, mission, and values. This connects each need with a metric to ensure that it actually does what it is supposed to do. This is best accomplished by linking performance analysis needs with Kirkpatrick's Four Levels of Evaluations, which means their are four categories of analysis (Phillips, 2002):
• Business Needs are linked to results
• Job Performance Needs are linked to behavior
• Training Needs are linked to learning
• Individual Needs are linked to reaction
Business Needs
Investigate the problem or performance initiative and see how it supports the mission statement, leader's vision, and/or organizational goals, etc. Fixing a problem or making a process better is just as good as an ROI, if not better. Organizations that focus strictly on ROI are normally focusing on cost-cutting. And you can only cut costs so far before you start stripping out the core parts of a business. A much better approach is to improve a performance or process that supports a key organization goal, vision, or mission.
When senior executives were asked the most important training initiatives, 77% cited, "aligning learning strategies with business goals"; 75% cited, "ensuring learning content meets workforce requirements"; and 72%, "boosting productivity and agility" (Training Magazine, Oct 2004). Thus, senior leadership is not looking at training to be a profit center (that is what other business units are for), rather they are looking at performance improvement initiatives to help "grow" the organization so that it can reach its goals and perform its mission.
The goal is to make an impact or get some sort of result. So once you have identified the gap between present performance and the organization's goals and vision; create a level 4 evaluation (impact) that measures it -- that is, what criteria must be met in order to show that the gap has actually been bridged?
Job Performance Needs
While the first analysis looked at business needs, this analysis looks at the job performance needs and these two needs could slightly differ. The first need, business, often has a slightly more visionary or future look to it, while the job performance need normally looks at what is needed now. Thus, business needs often tend to be more developmental in nature (future orientated), while job performance needs are normally more related towards the present.
This is perhaps the most important need to look at as it links the performer with the organization. When analyzing job performance, you want to look at the entire spectrum that surrounds the job: processes, environment, actual performance verses need performance, etc, thus it often helps to divide the analysis into three groups: people, data, and things.
Training Needs
As you assess the performance for any needed interventions, look at the Job/Performer requirements, that is, what the performer needs to know in order for the performance intervention to be successful. In addition, look at how you are going to evaluate any learning requirements (level 2). It is one thing to determine the learning needs (skill, knowledge, & self system [attitude, metacognition, etc.]), but it is quite another thing to ensure that those requirements actually take place.
Individual Needs
It ensures that the performance intervention actually conforms to the individual requirements. For example, in the Training Needs analysis, it might be determined that the job holders need to learn a new process. In this need analysis, the target population is looked at more closely to determine the actual content, context, and delivery method of the performance intervention.



The goal of systems analysis is to determine where the problem is in an attempt to fix the system. This step involves breaking down the system in different pieces and drawing diagrams to analyze the situation, analyzing project goals, breaking need to be created and attempting to engage users so that definite requirements can be defined. Requirement Gathering sometimes require individual/team from client as well as service provider side to get a detailed and accurate requirements.


During the Detailed Analysis, the Project Manager and the System Development Manager work closely together to:
a. Complete business process engineering of the functions to be supported,
b. Complete component selection.
c. Develop detailed data and process models,
d. Refine functional and system requirements that are not easily expressed in data and process models,
e. Refine the high level architecture and logical design to support the system, functional, and electronic records management requirements,
f. Continue to identify and mitigate risk that the technology can be phased-in and coordinated with the business.
There are three key reviews during the Detailed Analysis and Design Phase: the Detailed Level Requirements Review, Logical Design Review, and the Technical Design Review. This phase is completed when the Technical Review Board approves the high level architecture and system requirements, revised economic analysis, the logical design including the business process description, and the technical design. This approval is provided at these three reviews.
Detailed logical models of business data and processes needed to guide system development are created in the Detailed Analysis and Design Phase, and a description of the technical architecture is refined to guide the allocation of computing resources and capabilities. When practicable, the deployment of the new AIS should be planned to coincide with the implementation of new business processes and procedures. The Project Manager and the System Development Manager should continue to assess both business and technical risks and seek additional management support as necessary to manage those risks. Both the Project Manager and the System Development Manager may wish to document project risks and risk management activities in a risk management matrix for future reference.

The primary tasks performed during the Detailed Analysis and Design Phase are as follows:
a. Consolidate and affirm business needs,
b. Implement AIS project management infrastructure including requirements, configuration, and data management support services and utilities,
c. Revise plans to document changes in project scope including changes in business, schedule, and technical requirements,
d. Revise plans to document changes in available resources including budget, skills, staff, and training,
e. Update list of candidate reuse components, and complete reuse component selection.
f. Complete electronic records management requirements,
g. Identify data acquisition, conversion, and validation strategies,
h. Refine the technical architecture and build architectural prototype,
i. Identify design tools, techniques, and procedures,
j. Perform detailed AIS analysis and design, and
k. Continue planning for AIS testing, training, deployment, operation and business transition, and
l. Define and refine detailed requirements and allocate requirements to design.

Detailed Analysis activities and documentation requirements as summarized in the following table must conform to the indicated Technical Standard and Guidelines or other standards as noted.

Business requirements are intended to state in a concise, complete, and unambiguous manner what the system must do to meet business needs. Business requirements should not introduce unnecessary design assumptions or technical constraints. In this phase, the high level data and functions defined in the Concept Phase are transformed into a detailed description from which the system can be developed. This description will use a combination of textual and graphical representations to express the requirements in a form that users can readily understand. The functional, data, and support requirements must be approved by the Program Sponsor. Direct involvement of supported users and business area experts is essential to developing functional and data requirements. Requirements Management, for a description of the requirements definition process and documentation requirements.

Special attention must be given to reducing any adverse impact that may result from the transition process. Project Managers should prepare their organization to effectively cope with change by building consensus among key personnel in affected groups. This can be accomplished by establishing more effective communications with internal and external
customers, effectively managing labor relations through early and frequent communications, and by openly discussing anticipated changes with employees.
The Detailed Design must comply with the technical architecture:
a. Define the hardware, software, and network components in which the AIS will operate,
b. Show how functional, data, and electronic records management requirements will be allocated among these components, and
c. Describe the means used to interconnect these components.
Characteristics of the detailed design specified during the Detailed Analysis and Design Phase should establish confidence that the system components, when integrated, will meet all functional, performance, and support requirements. The detailed design establishes a level of uniformity for further AIS design and development. Architectural limitations, such as the ability to handle changing user needs, increased performance, and upward compatibility to new technologies, must be determined, and if necessary, classified as project risks.

The Detailed Design must:
a. Allow for maximum automated generation of application-specific code and databases using the CASE tool.
b. Allow for maximum reuse of existing system components.
c. Employ COTS software products wherever economically feasible.
d. Ensure that the application software can be processed on hardware and system software that is either currently available in the USPTO inventory or has been approved for acquisition and delivery in sufficient lead-time to allow for use during the test process of the Development Phase.
e. Provide for the collection of performance metrics.
f. Provide for including designer added software capabilities for internal controls to facilitate functional and technical audits of the AIS.
g. Specify functional and technical requirements for integration of the AIS with other PTO business processes, as needed.

Analysis should come early in any project, and the most important part of that analysis is the gathering of business requirements. Learn about product and process requirements and how to effectively determine and prioritize customer needs.
Most developers like to follow the Nike creed: Just do it! The customer comes to us with a business need, and we immediately move into problem-solving mode. We want to jump in and start writing code. There is no better feeling than completing an application and showing the customer. Until, of course, the customer informs us that this is not quite what he or she had in mind.

Developers can sometimes forget that the first phase of any development project is gathering business requirements to understand what the customer wants. It is only when we agree on the business needs that we can move on to the fun stuff—design and construction.

This is the first of five articles that look at some of the main concepts of the analysis phase:
• What business requirements are
• How to gather business requirements
• Process modeling
• Data modeling
• Conceptual systems design

At the end of this series, you should have a good sense of what the analysis phase of a large project might include. As always, not all of these concepts need to be applied to all projects. But once you know what the analysis phase may include, you can make a well-informed decision about what to include with your project.
It's all about requirements
Gathering business requirements is the main purpose of the analysis phase. Business requirements are statements that describe what the customer and major stakeholders need and want. If you are automating a business process, the requirements describe the way the process should work. If you are building a house, they describe the size, room layout, lot size, room color, and so on. I like to think of requirements in two groups:
1. Product requirements
2. Process requirements

Between these two types of requirements, everything the customer needs should be identified.
Sources:
www.uspto.gov/web/offices/cio/lcm/lcm2001ch4.doc
http://media.wiley.com/product_data/excerpt/87/04700747/0470074787.pdf
http://infolab.stanford.edu/~burback/watersluice/node4.html
http://www.computerfreetips.com/main_page/System_Analysis.html
http://www.nwlink.com/~donclark/hrd/sat2.html
http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle
http://articles.techrepublic.com.com/5100-10878_11-1045569.html