Software Engineering: A Methodical Approach (2014)

PART B. Software Investigation and Analysis

The next six chapters will focus on the Investigation and Analysis Phase of the SDLC. The objectives of this phase are

· To clearly identify, define and describe software system problems

· To thoroughly analyze system problems

· To identify and evaluate alternate solutions to identified software system problems. Such solutions should improve efficiency and productivity of the system(s) concerned

· To provide adequate documentation of the requirements of software systems.

Two deliverables will emerge from this phase of the software development life cycle (SDLC): the initial software/system requirement (ISR) and the requirements specification (RS).

Chapters to be covered include:

· Chapter 3 — Project Selection and Initial System Requirement

· Chapter 4 — Requirements Specification

· Chapter 5 —Information Gathering

· Chapter 6 — Communication Via Diagrams

· Chapter 7 — Decision Models For System Logic

· Chapter 8 — Project Management Aid

Chapter 3. Project Selection and the Initial System Requirements

This chapter covers a number of activities that are typical of the early stage of software requirements investigation. These activities converge into the first deliverable — the initial system requirement (ISR), also called the project proposal. The ISR contains a number of important components, which will be discussed. The chapter proceeds under the following subheadings:

· Project Selection

· Problem Definition

· Proposed Solution

· Scope and Objectives of the System

· System Justification

· Feasibility Analysis Report

· Alternate Approach to Feasibility Analysis

· Summary of System Inputs and Outputs

· Initial Project Schedule

· Project Team

· Summary and Concluding Remarks

3.1 Project Selection

For obvious reasons, let us assume that an organization stands in need of various software systems. The directors of the organization may or may not know the intricate details of their need, but hopefully are smart enough to recognize that something is lacking. At this early stage, management would invite the attention of one or more IT and/or software systems professionals (from the host organization, or a contracted software engineering firm) to conduct a needs assessment and make appropriate recommendations.

Very early in this software needs assessment exercise, the matter of project selection would become pertinent: It is often common that an organization stands in need of several software systems. Since it is impractical to attempt to acquire them all at the same time, some determination is normally made as to which projects will be pursued first. The intricacies of such determination are beyond the scope of this course; however, you should be aware of the salient factors that will likely affect such decisions:

· Backing from management

· Appropriate timing

· Alignment to corporate goals

· Required resources and related cost

· Internal constraints of the organization

· External constraints of the environment/society

If the organization in question is a software engineering firm, there are some additional factors to consider:

· Anticipated marketability of the product

· Expected impact on the industry

· Expected market position to be attained by introducing this new software

Consideration of these factors against each prospective software engineering project will lead to selection on one or more projects to be pursued. Once a project is selected, the next target is preparation of the ISR. The rest of this chapter discusses various components of the ISR, starting with the problem definition.

3.2 Problem Definition

Once the software engineering project has been selected, the first activity that is performed is that of problem definition. It must therefore be done thoroughly, accurately, and persuasively. The following are some basic guidelines:

· Define what aspect(s) of the organization is affected (recall the functional areas of an organization).

· Describe (in convincing, precise language) the effects and possible causes. Show how problems may be interrelated.

· Describe the worker attitude to the problem.

· Cite the impact the problem has on productivity and revenue.

· Identify the operating constraints.

3.2.1 Constraints of a System

In defining a system, there are certain constraints that the software engineer must be aware of. These include the following:

· External Constraints

· Customers of the organization

· Government policies

· Suppliers of the organization

· State of the economy

· State of the industry in which the organization operates

· Competitors of the organization

· Internal constraints include

· Management support

· Organizational policies

· Human resource

· Financial constraints

· Employee acceptance

· Information requirements

· Organizational politics

3.2.2 Aid in Identifying System Problems

How does the software engineer identify system problems? The following pointers should prove useful:

1. Check output against performance criteria. Look for the following:

a. Too many errors

b. Work completed slowly

c. Work done incorrectly

d. Incomplete work

2. Observe behavior of employees. Look for the following:

a. High absenteeism

b. High job dissatisfaction

c. High job turnover

3. Examine source documents. Look for the following:

a. Inadequate forms e.g. poor layout

b. Redundant information on forms

c. Information required but not included on forms

4. Examine the work process in the organization. Look for the following:

a. Inadequate/poor work management

b. Redundancies

c. Omissions

5. Listen to external feedback from vendors, customers, and suppliers. Look for the following:

a. Complaints

b. Suggestions for improvement

c. Loss of business

3.2.3 Identifying the System Void

If the organization in question is a software engineering firm, or an organization that lacks adequate software systems support, then what might be the issue is not necessarily identifying problems in an existing system, but identifying the need for introducing a new software system.

If the proposal is for a new software system for internal use, the proposal should follow a thorough internal research that involves prospective users of the product. The research should clearly outline the areas of user complaint. A few points to note:

· The research might be conducted formally, involving the use of questionnaires (see chapter 5), user forums/workshops, expert review, and other information collection instruments.

· Information could also me gathered via informal/non-conventional means, for instance brain-storming and observation (see chapter 5).

If the proposal is for a new software system to be marketed to the public, identification of the need could arise from any combination of a brainstorming session, a market research, or industry observation.

3.3 The Proposed Solution

The software engineer must propose a well thought out solution to the problem as outlined. This typically includes a system name, operating platform, and required resources. Following are a few points about the proposed solution:

· The proposed solution may be to modify the existing software system or to replace it.

· The proposal must show clearly how the problems specified will be addressed.

· It should briefly mention what areas of the organization will be impacted and how.

· The proposal must mention the chosen system platform (do not include details here as this will be required in the feasibility report).

· The proposal should mention the estimated cost of the software system and project duration.

3.4 Scope and Objectives of the System

In specifying the scope of the proposed solution, the software engineer must be guided by the following:

· Identify main components (subsystems and/or modules) to your best knowledge (which is limited at this early stage).

· Identify the principal user(s) of the system.

· Cite the organizational areas to be impacted by the system.

· State for each (functional) area, whether user participation will be data input, processing of data or access to data.

An itemized list of objectives serves to sharpen focus on the essentials of the system. Basic guidelines for stating system objectives are:

· State system objectives clearly and concisely.

· Identify primary objectives and secondary objectives where applicable.

· Ensure that the needs of end-users are addressed, especially those of the principal users.

· Align system objectives to corporate goals.

· Use corporate language in stating the objectives.

3.5 System Justification

It is imperative that the proposal underscores the benefits that the new software system brings to the table. These benefits go a considerable way to justifying the project in the eyes of management. Basic guidelines for stating software system benefits are as follows:

· Show how the system will help to improve productivity and efficiency.

· Mention advantages in the functional areas.

· Identify the benefits that the proposed software system brings to organization as a whole.

· Align the stated advantages to corporate goals of the organization.

· Use the corporate language in stating the advantages.

· If possible, do a payback analysis or break-even analysis to show how soon the organization could expect to recover the cost of the system. An amortization schedule would be useful here.

· Briefly mention risks or drawbacks (these will be discussed in the feasibility analysis).

3.6 Feasibility Analysis Report

A feasibility study is a thorough analysis of a prospective project to determine the likelihood of success of the venture. Traditionally, the analysis is done in three areas: the technical feasibility, the economic feasibility and the operational feasibility. Additionally, the alternate solutions to the defined problem must be carefully examined, and recommendation made in favor of the most prudent alternative.

3.6.1 Technical Feasibility

The technical feasibility analysis addresses the basic question of whether the project is technically feasible. The analysis must be done with respect to four main considerations. Once these four areas are addressed, the question of technical feasibility can be answered with reasonable accuracy. The areas are as follows:

· Availability of hardware required

· Availability of software required

· Availability of knowledge and expertise

· Availability of other technology that may be required e.g. telecommunication, new software development tool, etc.

3.6.2 Economic Feasibility

The economic feasibility analysis is aimed at measuring the economic results that would materialize if the project is pursued. Important considerations are

· Costs versus benefits expressed in terms of payback period, cash flow and return on investment (ROI)

· Development time and the financial implications

· Economic life — for how long the system will be economically advantageous

· Risk analysis — examining the associated risks

The matter of risk is very important, and needs some elucidation. Every business venture has associated with it, some inherent risks; software engineering projects are not excluded from this reality. The software engineer should be aware of the following:

· Generally speaking (from a financial perspective), the higher the risks are, the greater is the possible return on investment (and vice versa). However, there are exceptions.

· In many instances, taking prudent precautionary steps can reduce software engineering project risks. The software engineer must evaluate each risk and determine whether it can be reduced.

Two commonly used business techniques for evaluating and analyzing risks are payback analysis and return on investment (ROI). ROI is often facilitated by what is called a net present value (NPV) analysis. Figure 3-1 provides the formulas used in payback analysis and ROI respectively.

Figure 3-1. Formulae for Payback and ROI

3.6.3 Operational Feasibility

The operational feasibility speaks to issues such as the likely user/market response to the system, as well as the required changes on the part of operational staff. Generally speaking, user involvement in a project tends to positively impact user acceptance. The factors to be considered in assessing the operational feasibility of a project include the following:

· User attitude to (likely) changes

· Likelihood of changes in organizational policies

· Changes in methods and operations that may be necessary

· Timetable for implementation (long implementation time implies low feasibility)

3.6.4 Evaluation of System Alternatives

Evaluation of system alternatives should be based on software quality factors and feasibility factors. In the previous sub-section, we looked at the feasibility factors. Let us now examine the quality factors, explore the cost factors a bit further, and see how the evaluation is done.

Evaluation Based on Quality

The quality factors of chapter 1 are relevant here. In the interest of clarity, they are repeated:

· Maintainability: How easily maintained is the software? This will depend on the quality of the design as well as the documentation.

· Documentation: How well documented is the system?

· Efficiency: How efficiently are certain core operations carried out? Of importance are the response time and the system throughput.

· User Friendliness: How well designed is the user interface? How easy is it to learn and use the system?

· Compatibility with existing software products.

· Security: Are there mechanisms to protect and promote confidentiality and proper access control?

· Integrity: What is the quality of data validation methods?

· Reliability: Will the software perform according to requirements at all times?

· Growth potential: What is the storage capacity? What is the capacity for growth in data storage?

· Functionality and Flexibility: Does the software provide the essential functional features required for the problem domain? Are there alternate ways of doing things?

· Adaptability: How well are unanticipated situations handled?

· Differentiation: What is unique about the software?

· Productivity: How will productivity be affected by the software?

· Comprehensive Coverage: Is the problem comprehensively and appropriately addressed?

Since these factors are qualitative, weights usually are applied, and each alternative is assessed on each factor. The total grade for each alternative is then noted. The result may be neatly presented in tabular form as in Figure 3-2. In this illustration, alternative-B would be the best option.

Figure 3-2. Quality Evaluation Grid Showing Comparison of System Alternatives

Evaluation Based on Cost

The main cost components to be considered are development cost, operational cost, equipment cost, and facilities cost.

Engineering costs include

· Investigation, Analysis and Design cost

· Development cost

· Implementation cost

· Training cost

Operational costs include

· Cost of staffing

· Cost for data capture and preparation

· Supplies and stationery cost

· Maintenance cost

Equipment costs include

· Cost of hardware

· Cost of software

· Cost of transporting equipment

· Depreciation of equipment over the acquisition and usage period

3.6.5 Evaluation of System Alternatives (continued)

Facilities costs are sometimes bundled with operational cost. If there is a distinction, then facilities costs would typically include

· Computer installation cost

· Electrical and cooling cost

· Security Cost

A similar analysis may be constructed for the feasibility factors (including cost factors). When the alternatives are evaluated against these feasibility factors, an evaluation matrix similar to that shown in Figure 3-3 may be constructed. In this illustration, alternative-C would be the best option. Of course, the two Figures (Figures 3-2 and 3-3) may be merged.

Figure 3-3. Feasibility Evaluation Grid Showing Comparison of System Alternatives

Putting the Pieces Together

A final decision is taken as to the most prudent alternative, after examination of each alternative with respect to the quality factors and the feasibility factors. The rule of thumb is to recommend the alternative with the highest score. However, other constraints such as financial constraints, focus of the organization, etc., may mitigate against that option. Given the overall organizational situation, the most prudent and realistic alternative is taken.

3.7 Alternate Approach to the Feasibility Analysis

A popular alternate approach to conducting the feasibility analysis involves the consideration of the feasibility factors, the quality factors and the cost factors in a rather comprehensive way. The evaluation criteria are grouped in the following categories:

· TELOS Feasibility Factors: Technical, Economic, Legal, Operational, Schedule feasibility factors

· PDM Strategic factors: Productivity, Differentiation and Management factors

· MURRE Design Factors: Maintainability, Usability, Reusability, Reliability, Extendibility factors

The principle of weights and grades described in the previous section is also applicable here. Figure 3-4 illustrates a sample rating worksheet that could be employed.

Figure 3-4. Alternate Evaluation Matrix for Project Alternatives

3.8 Summary of System Inputs and Outputs

It is sometimes useful to provide a summary of the main inputs to a software system. Depending on the category and complexity of the software, the inputs may vary from a small set of electronic files to a large set involving various input media. Input and output design will be discussed in more detail in chapter 11. For now, and at this point in the project, a simple list of system inputs will suffice.

Additionally, a brief indication of what to expect from the system from a user viewpoint is sometimes useful in giving the potential end-user a chance to start identifying with the product even before its development has begun. Usually, a summary of possible system outputs will suffice.

In situations where visual aid is required, a non-operational prototype (see chapter 5) might be useful. For a real-time system (see chapter 13), a simulation may be required.

3.9 Initial Project Schedule

A preliminary project schedule outlining the estimated duration of project activities (from that point) is usually included in the ISR. Please note:

· The initial schedule may be detailed or highly summarized depending on information available at the time of preparation. As such, subsequent revision may be necessary (during the design specification).

· A PERT diagram, Gantt chart (see chapter 8), or simple table will suffice.

· A cost schedule is also provided showing projected costs for various activities. This may also be subject to subsequent revision.

Figure 3-5 illustrates a sample tabular representation of a project schedule. As illustrated in the figure, it is a good idea to include in the schedule, an estimate of the number of professional who will be working on the project. As more details become available, it will be necessary to revise this schedule; but for now, a tabular representation (as shown in the figure) will suffice. Chapter 8 discusses project scheduling in more detail.

Figure 3-5. Sample Initial Project Schedule

3.10 Project Team

The final component of your ISR is a proposed project team. The team must be well balanced; typically it should include the following job titles:

· Project Manager

· Secretary

· Systems Analyst(s) or Software Engineer(s)

· Programmer(s) (if different from software engineers)

· Software Documenter(s) (if different from software engineers)

· Data Clerk(s)

· User Interface Officer(s)

The number of personnel and the chosen organization chart will depend on the size and complexity of the project. Additionally, a user work group or steering committee is normally set up to ensure that the stated objectives are met. This may include the following personnel:

· Director of Information Technology (if different from Project Manager)

· Project Manager

· Representation from the principal users

· Other managers whose expertise may be required from time to time (on invitation)

· Software Engineer(s) (on invitation)

· Managing Director (depending on nature of the project)

In some instances, the project team forms a sub-committee of the steering committee; in small organizations, the two teams may be merged. Figure 3-6 shows three possible traditional configurations of the project team. As an exercise, you are encouraged to identify the pros and cons of each project team configuration. It must be pointed out however, that there may be various other configurations of a software engineering team (Chapter 19 provides more clarification).

Figure 3-6. Possible Arrangements of the Project Team

3.11 Summary and Concluding Remarks

It’s now time to summarize what we have covered in this chapter:

· Selection of a software engineering project depends on the corporate mission and objectives of the organization.

· The ISR is the first deliverable of the software engineering project. It consists of a number components such as problem definition, proposed solution, scope and objectives, system justification, feasibility analysis report, summary of system outputs, initial project schedule, and the project team.

· Problem definition sets the tone for the project. It must therefore be done thoroughly and accurately.

· The proposed solution provides a summary of how the problem will be addressed.

· The system scope defines the extent and boundaries of the software system; system objectives are also clearly specified.

· The system justification provides the rationale and main benefits of the software system.

· The feasibility analysis report analyzes and reports on the likelihood of success of the project. The feasibility study examines the technical, economic and operational feasibility, as well as other related factors such as associated risks, maintainability, usability, reusability, reliability, extendibility, productivity, differentiation, management issues, legal issues, functionality, flexibility, security, etc.

· Summary of system inputs and outputs is self-explanatory.

· The initial project schedule provides a draft schedule of the project activities that will subsequently be updated as more detailed information becomes available.

· The project team indicates the individuals that are or will be involved in the project.

Appendix 8 provides excerpts from the ISR for an inventory management system. Please take some time to carefully review the document and gain useful insights.

Once the ISR is completed, this document is submitted to the management of the organization for consideration and approval. Typically, the software engineer responsible for its preparation may be required to make a formal presentation to the organization. In this presentation, you sell the project idea to the organization. Once approval is obtained, you then start working on your next deliverable which is the requirements specification (RS). The next few chapters will prepare you for this. As you proceed, bear in mind that one primary objective of software engineering is to produce software that has a significantly greater value than its cost. We do this by building value in the areas of the software’s quality factors.

3.12 Review Questions

1. What factors are likely to influence the selection of a software engineering project? Briefly discuss these factors, and explain why they are important.

2. Discuss the importance of problem definition in a software engineering project.

3. What should the proposed solution entail?

4. What information is provided when you state system scope and system objectives?

5. How do you justify the acquisition of a new software system in an organization?

6. What is a feasibility study? Discuss the main components of a feasibility report.

7. Describe an approach that is commonly used for evaluating system alternatives and determining the most prudent alternative.

8. Identify three approaches to organizing a project team. For each approach, discuss is strengths and weaknesses, and describe a scenario that would warrant such approach.

9. Conduct an examination of an organization that you are familiar with, and do the following:

· Propose an organization chart for the organization.

· By examining the organization chart, propose a set of software systems that you would anticipate for this organization.

· Choose one of those potential systems, and for this system, develop an ISR as your first deliverable. Your ISR must include all the essential ingredients discussed in the chapter.

3.13 References and/or Recommended Readings

[Burch, 1992] Burch, John G. Systems Analysis, Design and Implementation. Boston, MA: Boyd & Fraser, 1992.

[Harris, 1995] Harris, David. Systems Analysis and Design: A Project Approach. Fort Worth, TX: Dryden Press, 1995. See chapter 3.

[Kendall, 2005] Kendall, Kenneth E., and Julia E. Kendall. Systems Analysis and Design 6^th ed. Upper Saddle River, NJ: Prentice Hall, 2005. See chapter 3.

[Long, 1989] Long, Larry. Management Information Systems. Eaglewood Cliffs, NJ: Prentice Hall, 1989. See chapters 10-12, 17.

[Peters, 2000] Peters, James F. and Witold Pedrycz. Software Engineering: An Engineering Approach. New York, NY: John Wiley & Sons, 2000. See chapter 4.

[Pfleeger, 2006] Pfleeger, Shari Lawrence. Software Engineering Theory and Practice 3rd ed. Upper Saddle River, NJ: Prentice Hall, 2006. See chapter 3.

[Schach, 2005] Schach, Stephen R. Object-Oriented and Classical Software Engineering 6^th ed. Boston, MA: McGraw-Hill, 2005. See chapter 4.

[Sommerville, 2006] Sommerville, Ian. Software Engineering 8^th ed. Reading, MA: Addison-Wesley, 2006. See chapter 4.

[Van Vliet, 2000] Van Vliet, Hans. Software Engineering 2^nd ed. New York, NY: John Wiley & Sons, 2000. See chapter 2.