CMSI 401 Documentation: Needs Analysis

The Needs Analysis Process

This page provides some details about the needs analysis process, and will help with creating the needs analysis section of the SDF. The needs analysis section specifies the content of the preliminary needs analysis (i.e., the results of the analysis performed), which determines what system should be built to best address the needs of the customer. Once this document has been created, it should be obvious what the requirements for the project should be in terms of look and feel and overall usability. The needs analysis will then guide the team as it makes design decisions during the requirements analysis.

Needs analysis is a complex task, in part because the customer often does not know what is really needed or, worse yet, might think something is needed that is different from what they really need. A key ingredient to a successful needs analysis is effectively questioning the client in order to understand her business goals and how those goals translate into a polished system. Part of this process involves identifying who the potential users, or audience actually are. This is often called "audience analysis." It includes analyzing demographics, computer skills, age, and other attributes that help designers and developers understand for whom they are ultimately developing the system. Audience analysis is closely coupled with identifying stakeholders and their criteria for success.

The term stakeholder is used to refer to anyone one who might have some direct or indirect influence on the system requirements and on the evaluation of the success of the project. Once these people are identified, the team sits down with each individual or group and discusses what will make the project successful (the critical success factors). Often an outside expert, called a "domain expert" will be a part of this discussion. The domain expert can contribute significantly to communicating the specifics of the problem to the development team, and can help facilitate information flow back to the customer. During these discussions, it is helpful to ask:

• Who is(are) the audience(s)?
• Who are the key stakeholders?
• What are the critical success factors?

Once the audience and stakeholders are identified, the next step is to determine specifically what the system will do. This is best accomplished through job/task analysis. Using this technique, designers identify important user groups and determine what specific set(s) of tasks these users will want to accomplish. The design team analyzes those tasks and determines how the software will support them. This enables the team to answer the questions:

• What are the main user groups?
• What tasks will they perform using the system?
• What possible issues could appear if the system is used improperly?
• What ethical situations might arise while using this system?
• What interfaces are required between the parts of our system?
• What are the information needs of each department of the customer?
• What are the information needs of the development (sub)team members?
• What are some different possibilities for use access to the data?
• What are some of the hardware and software products that will be required?
• What is the contact information for each of the development team members?
• What is the development team structure?

The team addresses these questions to a limited extent as they complete their proposal. However, the team also needs to ask these questions again during the meetings to determine requirements for the project during creation of the requirements specification.

The design team must also consider what the target hardware and software platform(s) are for the system. It is important to keep in mind that the final software system demo to the LMU community might not take place in the Keck Lab. Therefore, it is essential that the system work even when it is not connected to the lab network!

Past Experiences

Below are a few projects that have been completed in the past. Some worked, and some did not. Some of the good and less-good points of each are listed. These are presented as a guide of some things to consider while performing the needs analysis for your own projects. (It is not known whether all of these projects performed a careful needs analysis prior to the design phase of their project development.)

• Nova: Semantic natural language parser
  • Generated simple graphics from NL descriptions
  • Graphical user interface
  • Very well received
• Monopoly: Complex control structures (lots of little rules)
  • Very Complex AI (bidding, trading) - Flopped
  • Lots of Graphics - Not spectacular
  • Lots of interface - turned out well
• Abalone: Great AI (over a smaller domain)
  • Audio
  • Few Graphics (looked great)
  • Very simple control
• LMU Vegas: Virtually No AI
  • Nice Audio & Graphics
  • Communication between computers ... cool
  • Very buggy
  • Lots of interface
• Carcassonne: Virtually No AI
  • Good graphics and menu system
  • Communication between computers using multicasting
  • Runs well, but not on Windows without some sys admin
  • Lots of interface
• Neon Culture: Some Limited AI
  • Ingeneous Premise
  • Well-planned and well-executed
  • Written for Xbox, also runs on Windows
  • Well-defined user interface

It is interesting to consider whether careful needs analysis would have changed or even improved the outcome of each of these projects.

This deliverable document should be structured as follows, with the sections clearly listed and numbered. (Section contents are explained in subsequent sections below)

            3.0  Needs Analysis
            3.1      Introduction
            3.2      Audience
            3.3      Stakeholders
            3.4      Critical Success Factors
            3.5      Conceptual Solution Design
         

The introduction is intended to describe the process used to complete the preliminary needs analysis. It should specify in general terms who your audience is, who your stakeholders are, and what the principle critical success factors are thought to be. All these items will then be elaborated upon in the remainder of the document.

In fact, the introduction could simply state what a needs analysis is, sort of like what the previous paragraph states. Here is an example from a previous project:

3.1 Introduction

This preliminary needs analysis was based on a small-scale bottling enterprise. The team performed brainstorming and role-playing functions, and discussed the various facets of the operation of such an enterprise. Top-level design decisions were reached by a consensus of all participants. The following sections identify the audience, stakeholders, critical success factors, and elements of risk to the project.

In the RAPID environment, a salable product item is defined as a unit. Each product is composed of the components needed to create a finished unit. RAPID is intended for use in providing both component and unit availability, referred to as tracking.

This section should identify which potential users or individuals the project team interviewed, the types of questions asked, and the information recorded. Individuals should be identified by how they will use the completed system, and what experience they have to offer that will shape the final product.

In the case that no interviewing was actually done, use projections of what the key audience would be like. What company would use the software? What departments would be most interested, and how would their input be used to determine the functionality to be implemented? Think about how could the design be made flexible so that members of other departments in the same company might be able to use the software or request additions to its functionality without imposing a major version re-write to existing customers.

Here is another example (from the same project's needs analysis):

3.2 Audience

The RAPID software is designed primarily with the small manufacturer or assembler of products in mind. RAPID can be employed by any company that uses materials as components to be combined into a finished product for sale. Intended users of the system are expected to be managers, sales personnel, factory supervisors, and supply chain management, with side benefits to financial and accounting operations. Sales personnel will be able to use the client on a portable computer from a customer location to place orders, to check order status, to query availability of products, and to provide price information. Factory supervisors can use the application to help track input and output of both components and finished units, and to supply metrics to upper management on processes and productivity. Supply chain personnel will be able to trend component usage over time and thus can more accurately predict reordering of components and stock. Managers and financial/accounting departments will have available the reports they need to ensure cost and schedules are met, which will help them cut expenses, increase productivity, and grow their businesses.

This section should identify who the primary stakeholders are and what influence they are expected to have on the project. Again, an example:

3.3 Key Stakeholders

Primary stakeholders in the RAPID project, are the members of the project development team. Successful deployment of the RAPID application will not only help the team financially but also will allow the team to develop additional features and improvements.

Equally important as stakeholders, however, are the customers who will be using the application. The manufacturer's administrative team will be very interested in the accuracy of the tracking mechanism, as well as the reliability of the usage predictions. They can take advantage of the intuitive user interface to speed up their processes and minimize training time. They can also capitalize on the robustness and predictability of the software to minimize downtime, system crashes, and software maintenance headaches.

One other stakeholder is the course instructor, who will be dispensing the grades for the project and its deliverables. This is tantamount to paying for the project.

This section should clearly outline what areas are essential to completion of the project on time. Possible risk factors should be enumerated and discussed, along with steps that can be taken to reduce risk or modify the project if an insurmountable problem arises.

This section can be subdivided into sub-sections, if desired, as in the example:

3.4 Critical Factors and Risks

As with any software project of any size, there are several risk factors that must be considered, as well as critical factors that the team must ensure do not adversely affect the outcome and productivity of the project as a whole or the segments individually.

3.4.1 Critical Success Factors

Factors that are critical to the initial and continued success of RAPID are itemized as follows:

• Ease of use
• Application speed
• Data Security
• Correct Operation
• Reliability
• Flexibility
• Portability
• Predictable Operation
• Robust Operation
• Economical Price
• Appropriateness

3.4.2 Project Risk Assessment

Areas of potential risk to the successful completion of the RAPID project are discussed in the following paragraphs.

• Schedule: Time is in short supply. Having only one semester to finish the entire project puts schedule at the top of the list of risks. The team will attempt to minimize this risk by developing a meaningful schedule early on in the development, by constantly participating in all facets of development, and by mindful adherence to the schedule.
• Users: There is no actual business client, so there is no real-world user input. All required functionality is supposed, based on the knowledge of the small business that is being modeled. The team will try to minimize this risk by defining our requirements as closely as possible to what we believe real-world functionality would be.
• Design issues: Few if any of the team members have participated in a full-scale, team-oriented software development project. While this inexperience can work to advantage by providing a fresh approach, it can also cause problems when combined with short schedule (see first bullet). Risk mitigation in this case will be accomplished by carefully defining the functionality of the overall project to realistically reflect what can definitely be accomplished in the time allotted, then adding more features as time allows.
• Communication: The short schedule and "self-definition" of this project make it imperative that team members communicate effectively. The team will lessen this risk by using the "e-group" to disseminate information, by showing up for group meetings on time, by scheduling our own "department" meetings separate from the group, and by use of a common "RAPID" log-in account in the Keck Computer Lab.

This section should provide a VERY, VERY top-level design of what the system will "look like". At least a preliminary description of the system should be given, and there should be some idea of what the major parts will be. The text is expected to be conceptual in nature, not detailed. It is, after all, very early in the development process, so it is too soon to know classes, interfaces, and other mechanisms. It is even too soon to know more than just rudimentary ideas of policies in terms of data flow/management.

The following example should help:

3.5 Conceptual Solution Design

The Remote Access Product Information Database (RAPID) project will provide the small business company with the ability to track all facets of storage, component acquisition, and availability for the products it sells. These capabilities are provided using a three-tiered system. RAPID is a client-server application, meaning multiple users can access the system through a client application, with the server providing desired product or component information in response to the clients requests. The system will be composed as follows:

• Top-tier — The top tier, or client application, will be a system of menu-driven application screens. There will be several user-levels, with each of the levels incorporating all the functions of the levels below it, and adding further functionality. Screens will be provided to query for products, and each product screen will show the components comprising that product. Users will log in to the system, and are validated before access is granted. The client application will be able to access data over the internet.
• Middle-tier — The middle tier is an intermediate layer through which the client will access the database. All functions contained in the server are accessible to the client at some user level; user levels are checked prior to any database access. The server will validate user accounts at the first access attempt, after which all access attempts from that user account are considered valid. Up to ten client connections are allowed simultaneously, from either the same or different users.
• Bottom-tier — The bottom tier is the product database itself. This database will be implemented using Microsoft Access, but will use SQL language to access the data in a relational fashion. A single connection will exist between the server program and the database. Facility will be provided to re-connect to the database from the server in the event that the connection is corrupted in some way.

It is expected that the client will be written using the Java language, and the server will be written in "C" using the National Instruments LabWindows/CVI development environment. This design will allow the use of standard Microsoft Windows platforms for the server and database. Use of Java will allow platform independence for users of the system.

Entries in the project SDF table of contents should be generated for the Needs Analysis document. These entries should match the section titles listed above and in the table of contents at the bottom of the Course Overview page.

Next Document