The Importance of Requirements

Requirements engineering is difficult. It’s not just a simple matter of writing down what the customer says he wants. A fundamental problem in business is that requirements are inherently dynamic; they will change over time as our  understanding of the problem we are trying to solve changes. The importance of good requirements and the underlying dynamic nature of the process mean that we must be as accurate as possible, and yet be flexible. Flexible does not mean “weak,” but rather than we have a process for developing requirements and accommodating changed requirements as we clarify the real requirements of customers. Ineffective requirements practices are an industry wide problem. This is an area in which you can have a major positive impact. A more disciplined approach to requirements development and management is needed in order to improve project success rates. An alarming 53% of industry’s investment in technical development projects is a casualty of cost overruns and failed projects.

Implementation(SDLC)

Implementation

The final phase in the SDLC is the implementation phase, during which the system is actually built (or purchased, in the case of a packaged software design). This is the phase that usually gets the most attention, because for most systems it is the longest and most expensive single part of the development process. This phase has three steps:

1. System construction is the first step. The system is built and tested to ensure it performs as designed. Because the cost of bugs can be immense, testing is one of the most critical steps in mplementation.Most organizations give more time and attention to testing than to writing the programs in the first place.

2. The system is installed. Installation is the process by which the old system is turned off and the new one is turned on. It may include a direct cutover approach (in which the new system immediately replaces the old system), a parallel conversion approach (in which both the old and new systems are operated for a month or two until it is clear that there are no bugs in the new system), or a phased conversion strategy (in which the new system is installed in one part of the organization as an initial trial and then gradually installed in others). One of the most important aspects of conversion is the development of a training plan to teach users how to use the new system and help manage the changes caused by the new system.

3. The analyst team establishes a support plan for the system. This plan usually includes a formal or informal post-implementation review as well as a systematic way for identifying major and minor changes needed for the system.

                                                                                                Ref: System Analysis and Design

SDLC(Design)

Design

The design phase decides how the system will operate, in terms of the hardware, software, and network infrastructure; the user interface, forms and reports; and the specific programs, databases, and files that will be needed. Although most of the strategic decisions about the system were made in the development of the system concept during the analysis phase, the steps in the design phase determine exactly how the system will operate. The design phase has four steps:

1. The design strategy is first developed. It clarifies whether the system will be developed by the company’s own programmers, whether the system will be outsourced to another firm (usually a consulting firm), or whether the company will buy an existing software package.

2. This leads to the development of the basic architecture design for the system, which describes the hardware, software, and network infrastructure to be used. In most cases, the system will add or change the infrastructure that already exists in the organization. The interface design specifies how the users will move through the system (e.g., navigation methods such as menus and on-screen buttons) and the forms and reports that the system will use.

3. The database and file specifications are developed. These define exactly what data will be stored and where they will be stored.

4. The analyst team develops the program design, which defines the programs that need to be written and exactly what each program will do.

This collection of deliverable s (architecture design, interface design, database and file specifications, and program design) is the system specification that is handed to the programming team for implementation. At the end of the design phase, the feasibility analysis and project plan are reexamined and revised, and another decision is made by the project sponsor and approval committee about whether to terminate the project or continue.

                                                                                                         

                                                                       Ref: System Analysis and Design

(SDLC) Analysis

The analysis phase answers the questions of who will use the system, what the system will do, and where and when it will be used. During this phase, the project team investigates any current system(s), identifies improvement opportunities, and develops a concept for the new system.

This phase has three steps:

1. An analysis strategy is developed to guide the project team’s efforts. Such a strategy usually includes an analysis of the current system (called the as-is system) and its problems, and then ways to design a new system (called the to-be system).

2. The next step is requirements gathering (e.g., through interviews or questionnaires). The analysis of this information—in conjunction with input from project sponsor and many other people—leads to the development of a concept for a new system. The system concept is then used as a basis to develop a set of business analysis models, which describe how the business will operate if the new system is developed. The set of models typically includes models that represent the data and processes necessary to support the underlying business process.

3. The analyses, system concept, and models are combined into a document called the system proposal, which is presented to the project sponsor and other key decision makers (e.g., members of the approval committee) who decide whether the project should continue to move forward.

The system proposal is the initial deliverable that describes what business requirements the new system should meet. Because it is really the first step in the design of the new system, some experts argue that it is inappropriate to use the term analysis as the name for this phase; some argue a better name would be analysis and initial design. Most organizations continue use to the name analysis for this phase, however, so we use it in this book as well. Just keep in mind that the deliverable from the analysis phase is both an analysis and a high-level initial design for the new system.

                                                                           Ref : System Analysis and Design