Issue link: https://wardsworld.wardsci.com/i/1488288
2 required software. However, whereas civil engineers have been constructing roads, buildings, and bridges for centuries, soft- ware has been built only since the early 1940s. For this reason, software engineering is an evolving discipline for manufactur- ing software systems that, in a typical modern configuration, have many interacting software and hardware components for accomplishing specific tasks and include, as an essential com- ponent of the final systems, documentation to substantiate the needs of the systems and how they operate (Fig. 1). Software engineering process Several techniques have been defined for developing software systems, some of which are among the most complex and difficult products ever built. As mentioned earlier, software engineering, following the lead of its most mature siblings (civil and hydraulic engineering), has adopted and adapted the strategy of "divide and conquer" to make the development of software and its ever-increasing complexity more manage- able. Therefore, to better accomplish this task, the software engineering process is divided into phases or developmental stages: requirements elicitation, design, coding, testing, debug- ging, deployment, and maintenance. The definition of these phases, their order, and their interactions are known as the software development life-cycle model. Currently, there are different models for, or approaches to, the software develop- ment process. Among the most popular ones are the Waterfall, prototype, incremental, iterative, spiral, Rapid Application De- velopment, and Agile models. In general, during the software development process, the output of each phase serves as the input to the next one. Although there may be some reiteration among some consecutive phases, the aim is that, as a result of this progressive developmental process, the final product is a correctly working system that satisfies all the requirements and the users' needs and, at the same time, is easy to understand and maintain. Requirements elicitation The purpose of the requirements elicitation phase is to record and document the customer or system requirements of the perceived system and its operating constraints. It aims to answer this question: What is the system supposed to do? A typical requirements document includes the following: a product overview; a list of functional and nonfunctional char- acteristics; an explanation of system performance; user inter- face specifications; development specifications; details about the operating and maintenance environment for the system; a high-level conceptual model of the system; error-handling specifications; a description of potential enhancements to the system; and other auxiliary information such as a user's manual, glossary, and index. This requirements elicitation phase is generally accomplished by using a combination of techniques and tools, such as interviews, questionnaires, checklists, brain- storming, workshops, focus groups, and the like. This process can become difficult because of miscommunication among the customer, the business, the requirements analyst (who acts as a go-between for the customer and the developer), and the developer. Factors that may play a major role in miscom- munication among the parties during information gather- ing are imprecision as a result of a lack of expressiveness or understanding by the customer as to what the system needs to accomplish; the customer's assumption that the requirements analyst or the developer already understands the requirements in detail without much clarification; the customer's unfamiliar- ity with the technology; or the developer's unfamiliarity with the customer's business operations, data flow, and volatility of requirements. The outcome or deliverable product of this phase is a document called the software requirements specifi- cation (SRS). The requirements elicitation process is critical, as the outcome and acceptance of the final system depends on the accuracy of the SRS. This is because each function in the system must be mapped to a system requirement for trace- ability, and vice versa. Incompleteness of the SRS can cause potential weakness in the process, resulting in a partial picture of the needed system. Design The design phase helps to answer this question: How is the system to be implemented? It uses the SRS document as its input and delivers as its output the functional specification document, technical design document, implementation plan, performance analysis, and test plan. The design phase maps the system requirements to an archi- tecture that defines the components of the system, their inter- faces, and their behaviors using modeling tools, some of which are briefly described later on. The design documents provide detailed information about programming languages, environ- ments, system architecture, algorithms, and data structures used to implement the system. During this phase, the design- ers also refer to cost estimation models such as the construc- tive cost model (COCOMO). COCOMO uses a basic regression formula that includes historical, current, and future project data as input parameters. The effort estimation is equally important. Methods such as the analysis effort method are used to esti- mate the duration of the project. Over the years, software engineers have developed different methodologies and notations to express system requirements that try to mimic, to some degree, the blueprints used by Software Engineering (continued) + ward ' s science