Research Paper(s)
Technology Items
Site Map
Site Search
 It is 11:38 PST on Monday 03/01/2021



Professor Michael Shoukat
Systems Engineering
Course MSIT650 Section 9040

Design Web Applications the Systems Engineering Way

July 08, 2001

Robert D. Betterton


Many web applications have been deployed to the Internet since it went public back in 1994. Many of these applications have been developed by nothing more then fly by the seat of your pants, usually put together with cowboy heroics. It is very clear that the development of many of these web applications did not make use of CASE tools and/or even use the SDLC (System Development Life Cycle) System Engineering methods for bringing about a web application system to the Internet/intranet. This paper will show the role that CASE tools play in ensuring the success of a web application system that uses the proper systems engineering methodologies in the design and implementation of web applications.

This will be accomplished by showing how a web application will start with a vision, with this vision translated into requirements with the help of a CASE tool to capture the upper-CASE Tool events of the SDLC for this web application system. Remembering that a "system" is a purposeful collection of interrelated components that work together to achieve some objective (Sommerville 2000).


Why do we need Systems Engineering to help with Web application development? Because there is a "need" for a structured approach to everything from Human factors to a Web application that does what it is suppose/advertised to do, and does this function reliably, with ease, and user understanding. Elimination of the causes of web application systems failure lie in the application of system engineering methodologies, modeling tools, and techniques to design web application systems development and build web application systems that not only meet the needs of users but also are delivered on time and within budget.

Consumers, or end users as we more commonly refer to them, want to find information quickly and easily. Contrary to what you might conclude from observing the architectures of many large, corporate web sites and/or applications, users do not like to get lost in chaotic hypertextual web [applications]. Poor information architectures make busy users confused, frustrated, and angry (Rosenfeld 1998).

As Powell states "Web site [application] design is not graphic design. Far too many books treat Web site [application] development as simply the choice of a usable interface and an appropriate market identity, or the production of correct HTML. This is a simplistic way to describe Web development. Certain classes of sites certainly fall into such generalizations, but what about intranets? What about Web-based applications? What about transactional systems? The list goes on." (Powell 1998)

Many web applications fall into the categories listed below and their complexity just demands a Systems Engineering approach to their development and success. A "Web Systems Engineering Principle" is needed.

Here are the some of fields in which Web Applications have been developed:

  • Business-to-business E-Commerce<,/LI>
  • XML Interfaces,
  • Catalogs and Multi-vendor catalogs,
  • Data Warehousing and Archiving,
  • Data Migration,
  • Content Management,
  • Corporate Portals,
  • Application Integration,
  • Meta Searching.

Below is a diagram of the basic "Web Application Infrastructure Model":


As shown above, as a web application is delivered from a server to a an end user, client issues, server issues, database issues, and network issues will influence the user's perception of the Web Application. In short, things can go wrong everywhere. The problems are distinct, and yet part of the whole that the user sees. Thus, to minimize the possibility of failure, a rigorous approach to web application development should be adopted. The methodology defines the whole web delivery process.


When the Web first started out in 1989, and then organized in 1994 to the W3C, by the inventor Tim Berners-Lee (Berners-Lee 2002), I believe Tim didn't envision its rapid growth to what is today. That is, an Internet WWW system that has grown exponentially (Carpenter 1996) and is now the life blood of may companies world wide. With this activity has come rapid web application growth. This growth has brought with it may applications and/or Web system problems. These problems stem from poor user interfaces to poorly designed web applications that users have difficulty using.

Tim (Berners-Lee 1998) even states on the W3.org web site: "Again and again we fall back on the folklore of the principles of good design. Sometimes I need a URI for them so this is started as collection of them. I have written about some in many places. Principles such as simplicity and modularity are the stuff of software engineering"...

Tim further states "Keep it simple, stupid"... I believe with system engineering concepts, that simple to complex web applications can be kept simple and clean, well organized and maintainable with systems engineering principles and CASE tools. Systems Engineering gives us the methodologies and discipline to bring about a web application and CASE Tools give us a way to keep it all organized, tied together, and documented.


Of course the answer to structured Web Site Application design is the Systems Engineering approach along with a CASE Tool to help design and document the entire process.

Regardless of an applications purpose, as described in the above web application list, all well-implemented web applications exhibit similar characteristics, just as good software does. Quality software should be maintainable, reliable, efficient, and provide the appropriate user interface (Sommerville 1992). Web applications are no different, they should also function properly and reliably, download or execute efficiently, and provide the appropriate presentation. There are numerous aspects to the well-engineered Web application; and developers should always strive to meet the following goals:

  • Correct,
  • Testable,
  • Maintainable,
  • Portable and Scalable,
  • Reusable,
  • Robust and Reliable,
  • Efficient,
  • Readable,
  • Well Documented,
  • Appropriately Presented.


Below is an overall diagram of the SDLC using the waterfall model with feedback and Prototyping. Of course there are other SDLC process models that can be used to guide us, such as:

  • Waterfall Model
  • Modified Waterfall Model
  • Evolutionary Model
  • Incremental Model
  • Spiral Model
  • Vee Model

However, experience has shown that the waterfall model with feedback and prototyping works best for developing web applications. Using a CASE tool with the waterfall model aids in the documentation and construction of the web application as well. The SDLC phases will provide a general framework for our web applications business life cycle.



Before any coding is even considered for a Web Application. It is very important to figure out what the system is suppose to do, what problem is it trying to fix, or solve. Can it be done another way, besides using the web infrastructure? Basically what is the "vision" for the new web application, who needs it, why do they need it? This is the problem definition and explanation phase. It has been shown that software developers who spend more time planning and less time writing code finish their projects faster (Card, McGarry, and Page 1987; Card 1987).

Before deciding which technology, design, and content will be used in a web application, the purposes and goals for the application must be clearly established. Without a clear idea of the web applications purpose, the project may never get started. Even if it does, it may be working toward the wrong goals (Powell 1998).

Planning becomes the fact-finding part for the web application system, in which:

  • We need to understand the problem or opportunity,
  • What is the motivation for the web application,
  • Define the web application project scope and its constraints,
  • Perform fact-finding, where we would conduct interviews to elicit end users, managers, stakeholders, and the application owner. Remember, we just want to uncover facts,
  • Review any documentation about the desired web application, perhaps conduct a survey of individuals currently using a system that is being replaced by the new web application,
  • Confirm project feasibility,
  • Estimate the web applications benefits,
  • Estimate the web applications development time and cost,
  • Presents results to management,
  • Staff the project,
  • Launch the project.


Developing a problem definition doesn't need to be difficult as shown in the diagram above. There are a variety of general questions that can help elicit and stimulate ideas and help develop a problem definition. If the upcoming project is a modification to or upgrade of an existing application, consider the history of the web application. Consider who has been involved in creating and maintaining this application, and its original purpose. Very important, don't confuse looking at the old web application for ideas with blame placement and criticism of previous work. Web applications evolve, problems change. What appears to be nonsense now may have been appropriate in the past. Pointing out individual's past failures during the problem definition phase is guaranteed to create ill will within the project team.

We need to confirm that the web project is feasible. Many web projects are initiated as part of an enterprisewide strategic plan. Within the overall plan, each web project must stand on its own merit. Feasibility analysis investigates financial, operational, technical, and schedule feasibility. All of these areas need to bo applied to a web application regardless of its complexity.

The total plan for the web project is reviewed with upper management or directors and the web project is initiated. Initiation of the web project entails allocating funds, assigning project members, and obtaining other necessary resources such as office and development tools. An official announcement often communicates the web application project launch.


Here we are concerned about gathering the requirements for the new web application system. We need to elicit management, end users, and other stakeholders who have an interest in making the application come to life. Requirements analysis is what I like to call requirements engineering and it is a very important part of the life cycle of a web application. This is due in part because if we don't gather what an end user wants are needs for the application, it will most likely not meet the end users needs.

Thus the primary activities for this part of the Web Application System will be:

  • Gather information about the needed Web Application,
  • Define the web applications systems requirements,
  • Build prototypes for discovery of the requirements,
  • Prioritized the requirements,
  • Generate and evaluate alternatives,
  • Review the recommendations with management.

Thus, we need to learn as much as possible about the web applications problem domain -- this is usually the area of concern for the "user's business". It is the area which needs an information system solution (the web application). It is the area that is being researched. We need to state and understand the requirement characteristics, they must be:

  • Complete,
  • Correct,
  • Feasible,
  • Necessary,
  • Prioritized,
  • Unambiguous,
  • Verifiable,
  • Traceable.

Requirements Engineering lie at the heart of a well-run Web Application project, supporting many of the other technical and management activities. Changes you make in your requirements development and management approaches, will affect these other web application processes, and vice versa. The diagram below illustrates some of the connections between requirements and the other processes. (Wiegers 1999)


The diagram above shows the process of how requirements are related to other Web Application projects.

As Young States "Dealing effectively with requirements tops the list of the chanllenges to managers and practitioners developing systems and software (Young 2001)."



In the above diagram is shown a typical web application requirements elicitation process which is transferred to prototyping as the requirements are defined and allows for the construction of web prototypes. The object of creating prototypes is to assist, in some way, the development of target or delivered web application systems.

Below is another point of view regarding the requirements engineering process for generating web applications:


The importance of Prototyping:

A software prototype is a preliminary version or a model of all or part of a system before full commitment is made to develop it (IT-STARTS, 1989). A software prototype can also be part or all of a system that is developed and delivered using an iterative approach in which users are involved. Prototyping is the process creating a prototype (Smith 1991).

The objective of creating prototypes is to assist, in some way, the development of target or delivered systems, in this case a web application system. Major issues of web application development as shown in the diagram below can be addressed by prototyping are elicitation, demonstration, and evaluation of the following:

  • Data requirements and structure,
  • Function requirements,
  • Operation and performance, and
  • Organizational needs and issues.


In normal usage, a prototype is a trial model or a preliminary version of a product. In conventional engineering projects, prototyping at reduced scale, with simplified versions of products or with a pre-production product, is long-established tradition. The idea of producing a building, a bridge, an automobile, or an aeroplane without a prototype or model is almost inconceivable. Prototyping at an early stage in the development of a product allows evaluation and adjustment before the design is finalized (Smith 1991).

Caveat about Prototyping -- don't let end user's or management think that because they have experienced a web prototype that the design of the web application system is finished and deployment can proceed to the Internet/intranet. A prototype is just what the word implies and described above -- it is an example of what the web application can be like, to help elicit end user's and managers input. To help gather requirements on how they want the web application system to take shape and/or function. It is an evolutionary development process.

Below are some web application prototype examples:




The CASE Tool of choice is MacA&D or WinA&D from Excel Software. For this paper the diagrams were produced from MacA&D. This CASE Tool is used to show examples of how a Web Application can be created and stored for documentation purposes. This tool is used because it is robust enough with the required models needed to show how a web application can come together. Excel's CASE Tool suite is known as an upper- CASE Tool because it supports analysis and design and supports early phases of the software process.

The tool is capable of producing many modeling alternatives that fit both the standard structure to object oriented forms of information and system engineering modeling. Below is an example of Excel's capabilities:

  • UML Modeling,
  • Data, Process and State Modeling<,/LI>
  • Real-Time, Multi-Task Design,
  • Requirements Management,
  • Code Generation and Reengineering,
  • Bug Tracking,
  • Help Authoring,

Supported methods and notations include UML, OMT, Booch, Shlaer/Mellor, Yourdon/DeMarco, Gane & Sarson, Hatley/Pirbhai, CRC cards and Martin's Information Engineering. These tools promote an engineered approach to software development with integrated models, requirements traceability, code generation and reengineering of code to design.

Below are examples of some web application DFD, ERD, Dictionary, and Requirements diagrams:


Above is an example of the DFD of the Application Tracking System.


Above is an example of the Top level (Context) ERD of the Application Tracking System.


Above is an example of the DFD Dictionary entry for the Application Tracking System.


Above is an example of the ERC Dictionary entry for the Application Tracking System.


The phase describes in board and conceptual terms the web application system design components of several design alternatives that aim to fulfill user requirements. These alternatives can be made up of prototypes constructed during the requirements gathering phase of the project.

Why do we produce several general systems design alternatives? Constraints imposed on the project and an array of user requirements may interact in complex ways such that a number of designs are needed rather than a single design. The results of the general systems design phase are several plausible conceptual systems design deliverables compiled in the general system design report. These general systems design alternatives are ready for evaluation and selection of the optimum one for the detailed systems design phase.

Facts gathered, analyzed, and modeled during web systems analysis provide the basis on which general systems design alternatives are created.

The web system analysis phase was investigative and discovery-oriented. Now new or different features of the basic models need to be considered. The key in general web systems design is to produce updates in the CASE Tool without trying to refine the web systems design too early. The game plan: Interact with users, check with team members, check with technicians; redesign, check, check, and recheck, but don't try to develop low-level detail or mini-specs during this phase. This will come later after a general web systems design alternative has been chosen for implementation.


The evaluation and selection phase entails a process by which systems value and costs and benefits of alternative general web system designs are compared, and one is chosen for the detailed design phase. The evaluation and selection phase is an optimizing process that seeks not only a workable design, but also the best possible design for meeting the user requirements.

Decisions to replace current systems with one of the general web systems design alternatives are difficult. This phase provides a means by which management can make informed decisions during this critical point in the SDLC.


The objective of the design phase is to design a solution for the web application system. The design phase uses the information obtained during the analysis and prototyping phases as its input. High-level design consists of developing, an architectural structure for software programs, databases, the user interface, and the operating environment. Low-level design entails developing the detailed web application algorithms and data structures that are required for program development. At this phase there are seven major activities that must be done during the design phase:

  • Design and integrate the network,
  • Design the application architecture,
  • Design the user interfaces from the Prototypes,
  • Design the system interfaces,
  • Design and integrate the databases,
  • Prototype for design details,
  • Design and integrate the system controls.

Design activities are closely interrelated and generally are all done with substantial overlap.

The network consists of the computer platforms and associated equipment such tape backup, the network, and operating systems platforms that will house the new web application system. Because a web application is a network entity, design also includes configuring networking items such ODBC, security, data source connections, etc.

The web application is now a portion of the new information system that satisfies user needs with regard to the problem domain in which it was defined. The web application provides the processing functions for the business requirements. Designing the web application consists of using the model diagrams of the requirements that were developed during the analysis to design the appropriate web application.

Like with any software package, a web application is no different when it comes to the user interface. It is a critical component of any new web application. During the analysis as we discovered above, prototyping was used to define the elements and fields of the user interface. During design, these prototype elements and fields are all combined to yield an integrated user interface consisting of form, reports, screens, and sequences of interactions.

Most new web application systems must also communicate with other, existing systems elements and web applications, so the design of the method and details of these communication links must also be precisely defined.

Databases and information files are an integral part of web application systems for business. The model diagrams (ERD, Class, dictionary, etc.) that make up the new web application, came from the requirements developed during analysis. They are now going to be used to design the database that will support the new web application. At times, the database for the specific system must also be integrated with information databases of other systems already in place. A lot of times, many web applications are just front ends to existing or legacy database systems.

During design, it is often necessary to verify the correctness or workability of the proposed web design. One important verification method is to build and improve the prototypes that were created during the analysis phase of the project. Here you can also verify alternative design strategies by building additional prototypes of the new web application system. Sometimes, if the prototypes are built correctly, they can be saved and used as part of the final web system.

Final thoughts on the design of the web application system is that the application must have sufficient controls to protect the integrity of the database and the web application program. This is largely due to the highly competitive nature of the global economy and the risks associated with the technology and security, every new web application system must include adequate architecture to protect the information assets of the organization. All web application must pass through an authorization, authentication system if the web application is communicating directly with the Internet.


During the implementation phase, the final web application is built, tested, and installed. The objective of the activities of this phase is not only to have a reliable, well-working web application but also to ensure that the users are all trained and that the organization is benefiting as expected from use of the new web application. All the prior activities must come together during this phase to culminate into an operational web application. Basically there are five major actives that make up the implementation phase:

  • Construct all web application modules,
  • Verify and test the web application in a testing environment,
  • Convert data (if it applies),
  • Train users and document the system from the CASE Tool and other sources of info,
  • Move the web application to production,

The web application can be constructed through various techniques. The conventional approach is to write code using languages such as Visual Basic, ASP, PHP, COLDFUSION, TANGO, JAVA, JavaScript, HTML etc. Other techniques, based on development tools and components, such as BBEdit, Dreamweaver, UltraDev, Coldfusion Studio, etc., are becoming popular today. The web application must also be tested, and the fires kind of testing verifies that the web system meets the needs of the system's users.


The objective of the support/maintenance phase is to keep the system functioning productively during the years (in the web world this can be months) following its initial installation. The support phase is normally not included as part of the SDLC since it begins only after the system has been installed and placed into production. However, maintenance needs to be part of the SDLC even if this part of the phase is very long, lasting throughout the productive life of the new web system. The expectation for most web business systems is that the system will last for years, but in reality they may only last months due to changes made to the web system.


I believe it has been shown that the proper process's and procedures to designing Web Applications is to use the Systems Engineering approach using a CASE Tool and Prototyping. Systems Engineering gives us the SDLC that allows us to follow a process to bring order to web application development, prototyping allows and helps us in the elicitation of web application and system requirements, and the CASE Tool allows us to document the process as well as aid in the requirements gathering.

Bottom line, all of the above steps allow the other phases of the SDLC to complete with success.


Card D.N., (July/August, 1987). "A Software Technology Evaluation Program."

(pp 291 - 300), Information and Software Technology 29, No 6.

Card D.N., McGarry F.E., and Page G.T. (July, 1987). "Evaluating Software Engineering Technologies."

(pp 845 -- 851), IEEE Transactions on Software Engineering SE-13, No 7.

Carpenter B. (June, 1996). Architectural Principles of the Internet

Networking Working Group

Excel Software -- Developers of Extensive CASE Modeling Tools

Excel Software

Ince D., (September, 1989). "The software prototype", EXE Magazine. Web page Design

(pp. 61-62) IT-STARTS, Developers' Guide, National Computing Center, Manchester.

Powell T.A. with Jones D.L, and Cutts D.C., (1998). Web Site Engineering, beyond Web page Design

(pp ix, 93-94. ) Upper Saddle River, NJ: Prentice-Hall, Inc. ISBN 0-13-650920-7

Rosenfeld L. & Morville R. (February, 1998). Information Architecture, for the World Wide Web; Designing Large-Scale Web Sites

(pp 12. ). Sebastopol, CA: O'Reilly & Associates, Inc. ISBN 1-56592-282-4

Smith, M.F., (1991). Software Prototyping, Adoption, Practice and Management,

(pp 42-45. ) Shoppenhangers Road, Berkshire, England: McGraw-Hill Book Company (UK) Limited. ISBN 0-07-707241-3

Sommerville, I., (1992). Software Engineering, 4th Edition

(p4. ) Upper Saddle River, NJ: Addison-Wesley ISBN 0-20-139815-X

Sommerville, I., (2000). Software Engineering, 6th Edition

(p13, 21.) Upper Saddle River, NJ: Addison-Wesley ISBN 0-20-139815-X

Young R.R. (March, 2001). Effective Requirements Practices

(pp xxiii. ). Upper Saddle River, NJ: Addison-Wesley

Wiegers K.E. (1999). Software Requirements

(pp 56-57. ). Redmond, WA: Microsoft Press

The World Wide Web Consortium (W3C, 2001).


The World Wide Web Consortium (May, 2001). [System Engineering Mark Up Schema]


Berners-Lee T. Tim Berners-Lee (Personal Web Site, 2002).


Berners-Lee T. Principles of Design (W3C, 1998).


Back | Home | Top | Feedback | Site Search

E-Mail Me

This site is brought to you by
Bob Betterton; 2001 - 2011.

This page was last updated on 02/07/2004
Copyright, RDB Prime Engineering

This Page has been accessed "19663" times.